Rust bandwagon

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,
Wol

In Rust language side Google develops libraries and scientists verify that those libraries (to be used in Android phones)
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?

Azure CEO Mark Russinovich wrote last year, that C/C++ should be deprecated over Rust with new projects.
Stroustrup defended C++ at https://www.theregister.com/2022/09/20/rust_microsoft_c/.

Container images in Cloud are being developed (hopefully) to contain less components with memory safety issues,
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.

RedHat recommends that the container images should contain only the necessary components:
https://cloud.redhat.com/blog/container-image-security-be...

I found "This week in Rust"
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/...

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.

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!