If the software was originally written in C/C++ based on some performance reasons (avoiding GC/being in control of boxing/being in control of when to use vtables etc.) then what would be more reasonable options?
> Fully automatic memory-managed languages should be considered first.
Those languages have existed for 20+ years so if they were ruled out as part of the original decision making then they probably still aren't applicable.
Problem was that 20 years ago some of those languages didn't had AOT compilation options, or if they did, they were commercial, priced at ways most developers would rather not bother.
Plenty of software has been written in C or C++, only because they were the only compiled languages known to the authors.
Having said this, Go, D, Swift, OCaml, Haskell, Common Lisp, C#, F#, Java (with GraalVM, OpenJ9).
All of them offer ways to do AOT compilation and use value types, granted Java is too verbose using Panama for that, and one is better of choosing one of the others.
I've been using F# and there are actually several roadblocks for AOT F# [0]. However, a self-contained .NET JIT executable is still surprisingly small (18 MB for an ASP.NET minimal API written in F#), easy to build, and easy to deploy.
And even if the speed and memory penalties are exactly the same as they were 20 years ago, you no longer need to support a pentium 3 with 64MB of RAM. If you write code that would have performed well 20 years ago, then bloat it 300%, it'll run just fine. I'd rather have that than just about any electron app.
> Those languages have existed for 20+ years so if they were ruled out as part of the original decision making then they probably still aren't applicable.
There are huge C++ code bases that are 15+ years old and are still actively maintained because the cost of a rewrite is too high for something that still solves the problem well enough.
Most of the large C++ projects I've worked on were written in C++ because it was the most common and mainstream language given the CPU and memory constraints of that time. We have significantly more powerful CPUs now, especially considering multicore computing, and easily 5-10x more RAM than 15 years ago. Java/Kotlin, C#, Go, TypeScript, Swift etc., are perfectly applicable to many more problem domains where C++ once dominated. I can easily agree that many C++ projects would be better off transitioning to a fully garbage-collected language than to Rust.
> Those languages have existed for 20+ years so if they were ruled out as part of the original decision making then they probably still aren't applicable.
They were ruled out when the RAM/CPU budget per $SERVER could have been an expensive 4GB/2-core for a complex server processing transactions in real-time.
Today, that same complex server can cheaply run on a 48GB/6-cpu server. Those performance constraints for exactly the same $FUNCTIONALITY are such a low hurdle, dollar-wise, that it makes no sense in most applications of this heuristic.
If the software was originally written in C/C++ based on some performance reasons (avoiding GC/being in control of boxing/being in control of when to use vtables etc.) then what would be more reasonable options?
> Fully automatic memory-managed languages should be considered first.
Those languages have existed for 20+ years so if they were ruled out as part of the original decision making then they probably still aren't applicable.