4 ms·

> Rust is usually the least reasonable option If the software was originally written in C/C++ based on some performance reasons (avoiding GC/being in control o

> Rust is usually the least reasonable option 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.

pjmlp 1y ago
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.
- TJSomething 1y ago
  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. [0] https://github.com/dotnet/fsharp/issues/13398 https://github.com/dotnet/fsharp/issues/13398
  - pjmlp 1y ago
    Yeah, I listed it, because it is kind of possible, even if there are issues currently.
- Dylan16807 1y ago
  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.
  - pjmlp 1y ago
    In fact, in what concerns most of the languages, they scale down to computers much weaker than most of my 1990's PC desktops. Some examples, one per language, there are others I could list. https://www.wildernesslabs.co/ https://www.wildernesslabs.co/ https://tinygo.org/ https://tinygo.org/ https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.swift.org/get-started/embedded/ https://www.swift.org/get-started/embedded/ https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded...
thw_9a83c 1y ago
> 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.
lelanthran 1y ago
> 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.

pjmlp 1y ago

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.

TJSomething 1y ago
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. [0] https://github.com/dotnet/fsharp/issues/13398 https://github.com/dotnet/fsharp/issues/13398
- pjmlp 1y ago
  Yeah, I listed it, because it is kind of possible, even if there are issues currently.
Dylan16807 1y ago
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.
- pjmlp 1y ago
  In fact, in what concerns most of the languages, they scale down to computers much weaker than most of my 1990's PC desktops. Some examples, one per language, there are others I could list. https://www.wildernesslabs.co/ https://www.wildernesslabs.co/ https://tinygo.org/ https://tinygo.org/ https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.swift.org/get-started/embedded/ https://www.swift.org/get-started/embedded/ https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded...

thw_9a83c 1y ago

> 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.

lelanthran 1y ago

> 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.