High speed travel in Europe is quite affordable. A 3h train trip (~360 miles, like the distance between Toronto and Montreal) costs about 40€ in Italy or in France if you buy in advance.
I would love to be able to use Rust in my professional project. Unfortunately, I am doing high performance scientific computing. Rust doesn't even come close to offer any good alternative to cross-plateform, cross-device (CPU/GPU) libraries such as OpenMP Target, Kokkos, SYCL, ... I believe we need Nvidia/AMD to take Rust seriously (I'm not sure it is even possible without unsafe everywhere) to be able to offer good libraries.
In my world, using C++ is the modern language, because most project are stuck with Fortran.
Also cross-platform libraries, if you want to be everywhere, from computers and phones to set top boxes to weird Japanese rtoses you haven't even heard of, Rust just won't cut it.
Fortunately there are other languages that are more available cross-platform than Rust with its tiny Tier 1 list.
Unless ofc you're contractually obligated to use vendors half-arsed kludget together patchy version of GCC of unknown provenance that they compiled with barely half C support, let alone other GCC languages.
Besides Swisscom, internet is very reasonably priced in Switzerland. I had 1gbit symmetrical without contract or install fee and free equipment (including a standalone fiber to Ethernet converter) for 49.- a month.
Many cities or communities have built a municipal fiber network that any provider can lease and they’ve also wired up all buildings (inside) at the time. Only Swisscom (owned by the govt) is doing everything they can to get in the way of these municipal rollouts and keep the prices high.
Mathematica is still unparalleled in computer algebra. Yes, you can do computer algebra with Matlab or sympy, but I know a few theoreticians who use Mathematica to derive complicated equations.
The thing is, compared to some of the scientific codes out there, GPU are quite recent. Sometimes, slapping OpenMP pragma on the code is not sufficient to take advantage of accelerators, and thus you would need a significant rewrite.
But rewriting a scientific code is a daunting task. Often you have a code where there have been two decades of PhD and Postdocs fine tuning the scientific code, and the numerical schemes in the code do not correspond to the original article anymore. Nobody knows anymore exactly how the code works, and rewriting the code would require that the rewrite matches all the features of the original code (and reproduces the same results). It is basically an impossible task, especially when the labs don't have the resources to hire software engineers.
In practice, nobody wants to rewrite scientific codes for GPU (and sometimes, the problem is fundamentally incompatible with GPU architecture). So as a compensation, they slap some OpenMP pragmas on some parts of the code, hope for the best, and anyways Nvidia clusters are more common than AMD (at least in the scientific world), so OpenMP barely compiling for AMD is not a problem.
This means that legacy scientific codes are pretty much stuck with the CPUs. And in the scientific world, Fortran for HPC CPUs is still the language of choice.
OpenMP support in Fortran will improve as flang matures. In OpenMP 5.0 "#pragma omp requires unified_shared_memory" was introduced. At LLNL, they are are currently building El Capitan (https://www.datacenterknowledge.com/supercomputers/lawrence-...), a supercomputer using AMD MI300A accelerators which support this concept. LLNL is also one of the OpenMP ARB members (https://www.openmp.org/about/members/).
Correction: most PhDs in scientific fields don't know what unit tests are. Nobody ever taught/told them to write unit tests, and they have never heard of them, have never seen one, let alone written one.
It's because all these jobs using Fortran are scientific research projects. It is not explicitly asked, but if you are doing high performance computing, chances are you will be using Fortran. Scientific codes live for decades.
For example, I'm using a code that has been started in 1981. It is still very relevant and performant. Of course I wish I could use C++ or even Rust, but the fact is that (high performance) numerical computing is first class citizen in Fortran, which is not the case in C++ or Rust. I wish however that the tooling around Fortran wasn't stuck in the nineties.
I was curious about `soup`, clicking on it, the author states:
>soup is a programming language I've been working on for a few years that is designed to make it easier for the programmer to write fast, robust programs with no bugs.
>Availability
>I'm sorry to say soup is not yet available for general use.
Exactly the same thing with trains. I live in Switzerland, and they are adapting the capacity of the trains route by route, and to the time of the day.
The train I take every day to work has 12 cars in rush hour, and 4 cars off-peak, sometime 6 cars in the middle of the day, or 10 cars just after rush hour. They put extra trains in rush hour, have trains in standby is case of a breakdown of other trains, and they even introduce special trains dedicated for events (football games, big concerts, sports event). How is this "not flexible" ?
The only valid point is that the US forgot how to efficiently build huge infrastructure projects. But it is not an impossible thing to solve. Sent some experts to France, Spain and ask them how to manage high-speed project within reasonable costs. France is building the Grand Paris Express (a lot of tunneling, more than 200km of tracks) for a reasonable cost, and is now reusing tunnel boring machines to build another project in Toulouse.
It's not a technical issue with the costs in US; it's a political issue. On one hand, any construction project gets mired in massive amounts of red tape even when things go well. And then you have all the people who see public transit and similar projects as a threat to their neighborhood's "character" (i.e. who gets to live there), and who have mastered the art of using said red tape for their advantage.
