6 ms·
1. Rust is not C/C++ 2. Lots of software is already written in C/C++ 3. Rust follows the same convention as C/C++, that you integrate functionality by writing a
by memracom 9y ago
1. Rust is not C/C++
2. Lots of software is already written in C/C++
3. Rust follows the same convention as C/C++, that you integrate functionality by writing a library, compiling and linking it into a monolithic binary
4. Systems that rely on a monolithic binary are NP hard to replace with something different
5. Replacing a monolithic binary works best, in practice, when it is done by refactoring into services that are integrated by something other than a link editor. Although the buzz is all about web microservices, the reality is that message queuing to tie together microservice, macroservices and monolithic binaries, provides better performance more consistent with the linker/monolithic model.
6. Go with its channels and packages may be a more advanced model, and is also competing with Rust. In other words, it is not just a question of comparing Rust to C/C++
7. The JVM with its JIT has in many cases equaled or exceeded the performance of C/C++ monoliths, but languages like Clojure and Scala take it well beyond mere Java.
8. It may be that replacement of systems is driven more by economics than by technology. In other words it is not Rust that will determine the fate of Rust, but the economic sucess of companies using Rust for mission critical systems. In 20 to 30 years, the businesses that have succeeded will determine which technology is better.
- AstralStorm 9y agoJava Achilles foot has always been memory use and really compute constrained environments. Things like high end video game engines are not being written in Java, Closure or Scala for these very reason. I would be very careful about JIT performance being even close. See, the language does not even expose SIMD well. Doing anything hard realtime (heck, even more complex UI) with a JVM in the way is a big pain.