Rust bandwagon
Rust bandwagon
Posted Jan 2, 2023 22:20 UTC (Mon) by summentier (guest, #100638)Parent article: Welcome to 2023
I am currently teaching C++ to physics undergrads. This make me moderately miserable: teaching C++, to me at least, feels like trying to explain how precisely the "Zone" in Tarkovski's STALKER works.
At the same time I want to make sure the language I swirch to does not fall into oblivion a decade from now. Tethering Rust to the largest open-source project in history would give me a lot more confidence to look into it. I conjecture that I am not alone with this strategy...
Posted Jan 3, 2023 4:49 UTC (Tue)
by himi (subscriber, #340)
[Link] (15 responses)
It's not that Rust /can't/ do that kind of thing, but much of what you do when writing computational code is fiddling around and experimenting with ideas, and the things that make Rust valuable for systems coding can get in the way of that kind of fiddling and experimentation. I've had some success in my (small, pretty simple) projects doing the experimental phase in straight Python and then once I had a successful model replacing the kernel (and potentially other hot paths) with Rust, but when I've tried to start out from scratch with Rust it's not been much fun . . . Julia is trying to find a middle ground that lets you have a lot of the flexibility of Python, but the performance characteristics of a fully compiled language - I haven't done more than dabble with it yet, so I can't say how successful it is with that.
Of course, if you take that multi-language approach it ends up not mattering that much what your components are written in, as long as they can interoperate - that's one thing where Rust is both good /and/ bad (as the recent discussions about ownership of buffers across the Python/Rust boundary shows). In that case, Rust instead of C++ is definitely a win (for your sanity, if nothing else) . . .
Posted Jan 3, 2023 5:17 UTC (Tue)
by rsidd (subscriber, #2582)
[Link]
C++ is just too clumsy for scientific programming, in my opinion.
Posted Jan 3, 2023 15:08 UTC (Tue)
by summentier (guest, #100638)
[Link] (13 responses)
I have recently switched from Python to Julia, and minor language warts aside, I really like it: it gets the performance–productivity tradeoff exactly right. I have used Julia for two medium-site projects now, both of which would have been nigh-impossible for me to do in a two-language, Python+X, setup (despite 10+ yrs of eyperience).
So I agree with you insofar: if I were teaching students who will soon become computational physicists, Julia, no questions asked. The problem is, I am not. In the ballpark of 9/10 of students will leave for industry before or at graduation and 8/9 of the remainding scientists will do so as they fail to secure a permanent position in academia. Physicists are in a bit weird spot when it comes to industry since there are few dedicated positions – the most consisistent career I could make out was sort of a "specialized computational problem solver". So it feels prudent to at least keep this in mind.
The upshot is that I am faced with a trilemma performance–productivity–popularity. We agonized over the weight of each pole in multiple faculty meetings. If we neglect performance, Python is the clear winner. Eventually, you will need to make your program fast, which is where vectorization and native/JIT extension come into play. Only after starting to teach Python, I came to realize that for vectorization to make sense, you first have to rewire your brain in a weird way, which leads often to convoluted code and confused students. The two-language setup is too tall an order, particularly because of how difficult is to teach the "compiled" side. Neglegt the productivity side, and you arrive at C(++) and, perhaps surprisingly, Fortran, all three of which make me unhappy.
That brings us back to Julia and Rust. I become more and more confident that both languages will survive, but with both I still have feeling that they're not quite out of the woods yet. That's why I am monitoring the Rust progress in the kernel quite closely.
Hope this clarifies things. (Thanks for sharing your Rust expericence BTW.)
Posted Jan 3, 2023 15:37 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (8 responses)
Out of curiosity, why Fortran? Okay, I've used nothing newer that Fortran-77, but I thought newer versions had a lot of maths operators that made life easy(er).
Cheers,
Posted Jan 3, 2023 16:34 UTC (Tue)
by summentier (guest, #100638)
[Link] (7 responses)
Posted Jan 3, 2023 17:30 UTC (Tue)
by fenncruz (subscriber, #81417)
[Link] (6 responses)
Perhaps its biggest strength (and weakness) is its backwards compatibility. Fortran versions are more of a guideline than a rule. So in your projects, you can combine different versions of Fortran, even in the same file. After living through the python 2 to 3 transition, Fortran's ability to still run code from the '60s unmodified is a miracle. Of course, we get stuck with language constructs that we would rather leave in the 60s, but I guess that is the price to pay.
Posted Jan 3, 2023 18:49 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (5 responses)
Just watch out for that FOR LOOP. (I think I've got the right construct.)
The semantics between FORTRAN and Fortran is subtly different which can do serious damage if you don't realise the FORTRAN guy relied on it.
Namely
FOR I = 10 TO 1
will execute the code in the loop if compiled with FORTRAN, but will skip it if compiled with Fortran.
So be careful, boys and girls :-)
Cheers,
Posted Jan 3, 2023 19:15 UTC (Tue)
by fenncruz (subscriber, #81417)
[Link] (4 responses)
Fortran does not have have for loops is has do loops, there is no NEXT statement, nor do you use TO, to sepcify a range. All versions of fortran would use: do I=10,1 which would not execute. The difference with between versions is modern fortran would recommend an end do statement to terminate a loop while older fortran would use a numbered label to specify the end of the loop.
Perhaps you have some very non standard vendor extensions but that is not standard fortran in any version.
Posted Jan 3, 2023 20:26 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (3 responses)
FORTRAN *would* execute the body of the loop. Once.
Fortran, as you say, wouldn't.
(Unless you use compiler specific extensions - the F77 compiler I used had a switch to enable the old FTN behaviour.)
I'm old enough to remember the difference between FORTRAN and Fortran :-) I've never heard of fortran.
Cheers,
Posted Jan 3, 2023 20:46 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
DO I=10,1 would probably do an implicit STEP -1
J=10
Cheers,
Posted Jan 7, 2023 9:31 UTC (Sat)
by joib (subscriber, #8541)
[Link] (1 responses)
DO I=m1, m2
then m1 must be <= m2. So the loop in your example is invalid. You're most likely describing some compiler-specific extension (or accidental behavior later documented by the compiler developers as expected behavior. :) ).
Posted Jan 7, 2023 17:25 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Fortran allows a lot of (specified) behaviour in the name of optimisation, that can lead to unexpected results. Like storing the index of a do loop in a register, such that it can only safely be read, and not relied on when the loop exits. It seems highly likely that most FORTRAN compilers (and certainly the one I was using in 1983, iirc) did not bother to check the loop limits. Given that I understood that FORTRAN explicitly said the index,limit check was done at the *end* of the loop, I would be surprised if there was a special check on entering the loop.
When Fortran moved the check to the start of the loop, then it makes sense that loops can execute zero times.
Cheers,
Posted Jan 3, 2023 19:17 UTC (Tue)
by ma4ris5 (guest, #151140)
[Link] (1 responses)
In Rust language side Google develops libraries and scientists verify that those libraries (to be used in Android phones)
Azure CEO Mark Russinovich wrote last year, that C/C++ should be deprecated over Rust with new projects.
Container images in Cloud are being developed (hopefully) to contain less components with memory safety issues,
RedHat recommends that the container images should contain only the necessary components:
I found "This week in Rust"
Posted Jan 4, 2023 8:24 UTC (Wed)
by jem (subscriber, #24231)
[Link]
The original is at: https://doc.rust-lang.org/book/
Posted Jan 4, 2023 2:16 UTC (Wed)
by ianmcc (subscriber, #88379)
[Link]
In the case of the high performance computing course, it is actually run by the computer science faculty, so they are "real" computer science students, and I find it astonishing that they have been taught a really ancient style of C code, basically K&R. Introducing scoped variables in OpenMP already runs counter to what they've been taught. Although we expect that in practice most of the students will end up using TensorFlow or some other toolkit in the real world, we're trying to teach them some computer architecture, so we cover AVX intrinsics, OpenMP, MPI, and CUDA from a relatively low level, so they learn a bit about how the CPU actually executes instructions, and how memory hierarchies work etc, the difference between the various different CUDA memory allocation functions, etc. Given the aims of the course, I think C++ works fairly well, and they write some simple CUDA kernels, which are C++ code anyway.
Using C++ for computational physics is more controversial, and I expect that will switch to Julia eventually. A blocker is that it should be coordinated with the prerequisite course also shifting to Julia. Now I quite like C++, and my career has been doing numerical simulations using code I've written in C++. But it is a really huge language, and few (if any) computational physics students have the time and inclination to properly learn it, even if they go on to a professional career. 20 years ago the decision to use C++ was very clear; for serious scientific computing (back then) you need to use a systems programming language, or something with comparable facilities (Fortran might qualify, but barely), because you need to do your own memory management, and compared with most other options, C++ would let you do that but also use a high level of abstraction in the actual numerical algorithms. This became a very powerful approach with the advent of generic programming. A big disadvantage of C++ is that you need to find (or write your own) libraries for linear algebra etc. The early foray into high performance computing in C++ with valarray was not a success, but there are now some HPC people from Sandia National Lab and other places on the C++ standards committee, so that will hopefully lead to some interesting developments.
In the past I've taught the computational physics course using Matlab, Python, and for a couple of years own-choice of language. For a while students all learned a bit of Matlab in some earlier courses, and these days they should all have done a bit of Python. But those languages are OK for some things, they are terrible for things like Monte Carlo, where you want to have a tight loop that runs as fast as possible. Own choice of language was a bit of a mess; one year a student used Haskell, which I was initially OK with, expecting some elegant one-line (or a few-line) solutions, but his code ended up way longer than anyone else's, and was totally unreadable.
I think in the longer term, if C++ is going to survive then it needs to become a smaller language, eg by compiler enforcement of the C++ core guidelines, and perhaps a language dialect that removes as much unsafe stuff as possible, eg get rid of char* (or maybe get rid of all bare pointers) and just make string literals an std::string. The barrier to entry to learn how to write safe C++ is just too big.
Rust is certainly an interesting alternative, and it may well end up as match up between Julia and Rust, for scientific computing in cases where Python won't cut it.
Posted Jan 4, 2023 5:51 UTC (Wed)
by himi (subscriber, #340)
[Link]
In that kind of context it probably makes sense to be moderately aggressive about moving away from C++ towards something like Rust, given the trends that seem to be developing. There's also maybe a case to be made for the Rust community working to help find ways to make the language more practical for the kind of exploratory development that Python is so good at - I don't know whether that's really viable, though, given the nature of Rust. Alternatively, pushing for Julia to give more consideration to systems development might be an option, though again I'm not sure how realistic that might be.
Good luck with your probably thankless educational challenge!
Posted Jan 3, 2023 11:32 UTC (Tue)
by beagnach (guest, #32987)
[Link]
great analogy
Posted Jan 3, 2023 22:56 UTC (Tue)
by eean (subscriber, #50420)
[Link] (10 responses)
Rust getting immense credibility from its use in Linux is very real though. You'd be able to tell your students "it's used by Linux now" and folks in the workforce will be able to tell their managers the same.
Posted Jan 5, 2023 20:59 UTC (Thu)
by acarno (subscriber, #123476)
[Link] (9 responses)
In short, I've become a huge Ada evangelist, but I'm sadly aware that it'll never see the meaningful uptake that Rust and other "modern" languages will.
Posted Jan 5, 2023 21:43 UTC (Thu)
by khim (subscriber, #9252)
[Link] (8 responses)
For a longest time Ada looked like insane contradiction: it offered tools to control stuff above and beyond what even Rust may offer while simultaneously refusing to even attempt to solve the biggest issue of them all, memory safety. Eventually it took page from the Rust's book and is now, apparently, safer than Rust, but it's still no-community language (does it even have any popular non-trivial libraries?) which makes it non-starter for most projects.
Posted Jan 7, 2023 9:06 UTC (Sat)
by joib (subscriber, #8541)
[Link] (7 responses)
I guess people developed an instinctive dislike for it because they were forced to use it, thanks to DoD contracts requiring it's use. Then the Ada toolchain vendors took the opportunity to fleece the captive users as hard as possible, killing Ada usage except for DoD contracts. And for civilian usage C came to dominate thanks to Unix and compilers being free or at least cheap.
And eventually when the DoD stopped requiring Ada it all but died.
Sometimes I wonder about an alternative history where Ada instead of C became the 'standard' systems programming language. Oh, how much less security vulnerabilities would we have to endure. *sigh*
Posted Jan 7, 2023 13:57 UTC (Sat)
by khim (subscriber, #9252)
[Link] (6 responses)
I don't think so. Ada, for years, covered the remaining 30% well, but never had an answer to the main problem of these pesky 70%. Today… it borrowed the solution from Rust, sure, but before that… it was only “safe” in a limited world of “no dynamic memory”. Thus we could have had somewhat smaller number of vulnerabilities, but hard to say how much.
Posted Jan 9, 2023 22:50 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (5 responses)
[1]: All of the bugs documented in https://youtu.be/9xE2otZ-9os?t=189 are the result of reusing statically-allocated memory. In fairness, this technique is technically equivalent to using a fixed-size (block) allocator with a very small heap. But then you can describe almost any use of non-stack memory as "technically" some kind of dynamic allocation.
Posted Jan 9, 2023 23:38 UTC (Mon)
by khim (subscriber, #9252)
[Link] (4 responses)
Well… affine types (which Rust and now Ada are using to solve handling of dynamic memory issues) were, initially, invented by mathematicians and adopted by GC-based functional languages. Not to manage memory, but to manage external resources (in that case “they would be freed but we have no idea when, precisely” is bad answer). Rust discovery (as with TMP it was discovered, not designed into the language from beginning) was surprising and somewhat startling and it's not even mathematical fact, but a social one: if you give people an easy-to-use affine type system then they can solve almost all practical memory handling problems without GC, just with a small amount of It's still not clear whether you can rewrite piecemeal any old code with similar results (which is what Linux Rust project is, essentially, trying to do) or whether you have to design everything from scratch for that phenomenon to work, but the whole thing wasn't pre-planned when Rust was first imagined. But yes, heap is definitely not the only resource which you need to manage… just, probably, the most important one. And it's scary how many really profound, important results are not designed, but discovered when people design something entirely different… are there similarly simple things which could have changed our computing (or maybe more than just computing) world as profoundly and which were just simply not discovered in time?
Posted Jan 10, 2023 12:12 UTC (Tue)
by kleptog (subscriber, #1183)
[Link] (3 responses)
The thing I found most amazing was its impact on some junior developers. They'd start with C and pointers and get themselves tangled into knots keeping the ownership/concurrency/etc straight. But after using Rust for a while they'd internalised the model such that after that coding C became much less scary because they had a model that they knew that worked, and all C needed was some boilerplate that the Rust compiler handles for you (i.e. working without guardrails).
The resulting programs became better simply because they understood the ownership of the objects they're manipulating, rather than just throwing pointers around. Some of us had to learn that the hard way using debuggers on segfaulting programs.
Posted Jan 10, 2023 17:08 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (2 responses)
One thing I've seen time and time again with junior developers is that they've not yet internalised the rules of programming (in any language, not even the one they're working in), and are reliant on the computer telling them that they've made a mistake. Having this happen at compile time is better, but even a runtime exception (like in Java or C#) is an enormous help, since it means you get feedback that you've written something illegal.
In this context, C's thing of "if it's UB, the computer can silently do the wrong thing" is really bad for a developer's education, since the computer will often appear to work even though the developer has done the wrong thing (buffer overflow, use-after-free). Rust's move to "in order to even have UB, you need the unsafe keyword" means that junior developers know to stay away from potential UB, and thus avoid the C problem, since it's obvious to them that they're potentially making a mistake.
Posted Jan 10, 2023 19:36 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
This complicates life with junior developers, but they are not the most problematic case. Look on that whole discussion. Wol is most definitely is not a junior. It's not easy to educate junior developers, but it's almost impossible to educate senior ones… because often they firmly believe they know in this or that undefined language construct does. Even if documentation says something else.
Posted Jan 10, 2023 19:46 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
(Not helped because C is not my language of choice.)
Cheers,
Rust bandwagon
Rust bandwagon
Rust bandwagon
Rust bandwagon
Wol
Rust bandwagon
Rust bandwagon
Rust bandwagon
...
...
NEXT
Wol
Rust bandwagon
Rust bandwagon
Wol
Rust bandwagon
K=1
DO I=K,J would not execute in Fortran, but would execute once with I set to 10 in FORTRAN.
Wol
Rust bandwagon
Rust bandwagon
Wol
Rust bandwagon
either using Julia's runtime for Rust, or using for example Tokio for Rust: https://github.com/Taaitaaiger/jlrs.
Currently Rust can't guarantee memory safety in some cases with Julia runtime there.
are memory and data race safe: Compilation will fail, if safety rules are not met.
I don't like with Julia's current status "you have to be careful to avoid data races with mutexes and threads":
Should I validate each Julia library for possible thread safety issues?
Stroustrup defended C++ at https://www.theregister.com/2022/09/20/rust_microsoft_c/.
because every memory safety issue is a security issue (may or may not have a CVE).
https://www.csoonline.com/article/3599454/half-of-all-doc...
So C/C++ has higher post deployment security maintenance cost, compared to Rust.
https://cloud.redhat.com/blog/container-image-security-be...
http://this-week-in-rust.org useful to see that what's new there.
Also MIT book could be useful for learning Rust:
http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/...
Rust bandwagon
>http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/...
Rust bandwagon
Rust bandwagon
Rust bandwagon
Rust bandwagon
Rust bandwagon
Rust bandwagon
Rust bandwagon
> Oh, how much less security vulnerabilities would we have to endure.
Rust bandwagon
Rust bandwagon
Rust bandwagon
unsafe code.Rust bandwagon
Rust bandwagon
Rust bandwagon
Rust bandwagon
Wol