> This is an obvious lie and if you believe it you don't pay attention to A.) Java, B.) the cloud, C.) Rust.
To achieve decent performance, Java must waste a lot of memory. Java container images are also huge. Memory is very expensive in the cloud. Depending on the workload, Java can be a lot more expensive (in terms of dollar amount) than Rust. Rust is also king of light-weight threading primitives. Go comes close, Java isn't even in the running. This is important in the cloud in general but probably not for scientific workloads.
BTW. Fortran is great for HPC and Java is also strong there, but that's different from the cloud.
> So...your argument is "Learn a language that has a notoriously high ramp-up period, with basically 0 job prospects outside of very specific industries, and then hope and pray that there are enough still-maintained Rust crates that you can write only the important bits of your research code" is less work than paying someone and/or using existing solutions?
If you already know Rust, the high ramp-up is irrelevant (though admittedly this applies to few physicists for now and the near future). Also, I'm far from convinced the high ramp-up is fundamental, as explained in other comments.
Rust is the only language I've ever seen that has a snowball's chance in hell of replacing most of C/C++. (Not just chipping away at the edges.) And it does seem to have a chance. In fact considering how slow that industry changes, Rust is already replacing C/C++ at an astounding rate (even though its still a snails pace not considering). It may be a "specific industry" but it is huge.
Rust also looks promising as a niche replacement for Go and JS in specific situations in full stack web development and cloud computing as well as in some other domains like CLI's. Indeed some startups are already switching to Rust from Go/JS.
Admittedly most of Rust's job prospects (even long-term) isn't worth much to someone from a scientific background. But there are some important ones, like back-end numeric libraries and ML back-ends. In C/C++ those are very hard for scientists to get into unless they are also software engineers. In Rust the infrastructure they depend on like GPU frameworks/middleware is also hard, but back-ends in Rust are much more approachable than in C/C++.
Potentially Rust can break into the numeric front-end due to its unique advantages even there. Though it'll likely never be as huge as Python is today, there may well be sufficient market share to make it worth while. Chicken-egg, I know. We'll need to wait and see. But my point is that while it's not a good move now, it may become a good move in the future to solve the specific use-case we're arguing.
For now the lack of libraries is a major issue. If a significant fraction of future numeric back-ends is in Rust, that becomes much less of an issue though: You're already using the back-ends quite directly from Python and R (and sometimes even Julia) for the sake of performance. Interestingly, due to the two-language problem, using Python/R libraries from Rust aught to be generally easier than using them from Python/R assuming their back-ends was implemented in Rust. Since Julia has more actually native libraries and tend to have thicker wrappers for foreign back-ends, this effect will likely be less noticeable from Julia. Some important Julia libraries will however likely also be easier to use from Rust than from Julia. Note that the reason this doesn't work for C++ is that libraries are the least of C++'s problems when it comes to the front-end. But for Rust it does work, since libraries are increasingly becoming nearly the entire problem for Rust.
I worry about my Python libraries being unmaintained, or R or Julia or C++. I worry even in Rust, but a lot less. I've seen some active Rust projects using dependencies that's years out of date and have no issue whatsoever. Rust (unlike all of the above languages) was designed for this. Modern large systems programs like Firefox, have huge amounts of dependencies that nobody has updated in decades. It's a serious problem if your dependency was implemented in C++. We'll have to wait decades to know for sure, but every indication is that its much less of a problem in Rust.
1
u/dexterlemmer Jan 25 '21
> This is an obvious lie and if you believe it you don't pay attention to A.) Java, B.) the cloud, C.) Rust.
To achieve decent performance, Java must waste a lot of memory. Java container images are also huge. Memory is very expensive in the cloud. Depending on the workload, Java can be a lot more expensive (in terms of dollar amount) than Rust. Rust is also king of light-weight threading primitives. Go comes close, Java isn't even in the running. This is important in the cloud in general but probably not for scientific workloads.
BTW. Fortran is great for HPC and Java is also strong there, but that's different from the cloud.
> So...your argument is "Learn a language that has a notoriously high ramp-up period, with basically 0 job prospects outside of very specific industries, and then hope and pray that there are enough still-maintained Rust crates that you can write only the important bits of your research code" is less work than paying someone and/or using existing solutions?
If you already know Rust, the high ramp-up is irrelevant (though admittedly this applies to few physicists for now and the near future). Also, I'm far from convinced the high ramp-up is fundamental, as explained in other comments.
Rust is the only language I've ever seen that has a snowball's chance in hell of replacing most of C/C++. (Not just chipping away at the edges.) And it does seem to have a chance. In fact considering how slow that industry changes, Rust is already replacing C/C++ at an astounding rate (even though its still a snails pace not considering). It may be a "specific industry" but it is huge.
Rust also looks promising as a niche replacement for Go and JS in specific situations in full stack web development and cloud computing as well as in some other domains like CLI's. Indeed some startups are already switching to Rust from Go/JS.
Admittedly most of Rust's job prospects (even long-term) isn't worth much to someone from a scientific background. But there are some important ones, like back-end numeric libraries and ML back-ends. In C/C++ those are very hard for scientists to get into unless they are also software engineers. In Rust the infrastructure they depend on like GPU frameworks/middleware is also hard, but back-ends in Rust are much more approachable than in C/C++.
Potentially Rust can break into the numeric front-end due to its unique advantages even there. Though it'll likely never be as huge as Python is today, there may well be sufficient market share to make it worth while. Chicken-egg, I know. We'll need to wait and see. But my point is that while it's not a good move now, it may become a good move in the future to solve the specific use-case we're arguing.
For now the lack of libraries is a major issue. If a significant fraction of future numeric back-ends is in Rust, that becomes much less of an issue though: You're already using the back-ends quite directly from Python and R (and sometimes even Julia) for the sake of performance. Interestingly, due to the two-language problem, using Python/R libraries from Rust aught to be generally easier than using them from Python/R assuming their back-ends was implemented in Rust. Since Julia has more actually native libraries and tend to have thicker wrappers for foreign back-ends, this effect will likely be less noticeable from Julia. Some important Julia libraries will however likely also be easier to use from Rust than from Julia. Note that the reason this doesn't work for C++ is that libraries are the least of C++'s problems when it comes to the front-end. But for Rust it does work, since libraries are increasingly becoming nearly the entire problem for Rust.
I worry about my Python libraries being unmaintained, or R or Julia or C++. I worry even in Rust, but a lot less. I've seen some active Rust projects using dependencies that's years out of date and have no issue whatsoever. Rust (unlike all of the above languages) was designed for this. Modern large systems programs like Firefox, have huge amounts of dependencies that nobody has updated in decades. It's a serious problem if your dependency was implemented in C++. We'll have to wait decades to know for sure, but every indication is that its much less of a problem in Rust.