Comment by fooker
9 months ago
Perhaps the more appropriate advice is : Use the right tool for the job.
Use C++ for writing a high performance library or a database engine.
Use Go or Java for writing a server.
Use C for writing a kernel module.
Use shell scripts for automation.
Use python for trying out ML ideas or heavier duty scripts.
Use Rust for ... I'm not quite sure what it's the right tool for yet. I suspect it's trying to become the right tool for all of the above and not succeeding much in practice.
> a high performance library or a database engine
> a server
Rust is a great tool for these. The focus on performance and reliability (versus fast iteration) is a perfect fit for these domains specifically.
Server, I think you could be right.
Database engine, no way. Look at the internals of modern ones. Very very intricate pointer based data structures that you'll pull your hair out replicating with Rust.
Again, it's not like it's impossible. You can certainly accomplish it by treating it like a puzzle but using the right tool will have better results.
Use Rust if crashes or memory bugs are not an option. For everything wasm, Rust is much more pleasant with good libraries than the competition.
Wasm seems more convincing to me than the magical 'no crashes or bugs' promise.
Here's my wasm use case: tell me how I can use Rust.
I have a command line tool written in C that ..say.. takes strings and outputs strings.
How would I go about making a usable REPL out of this in Rust and wasm without rewriting the tool?
But when you look at the disaster that was c++ for cloudflare, and the switch to rust.
This is precisely the argument given against rust for video games: too much typing induced by memory safe, which is too restrictive.
Is there any use if your c code works, the advantage of rust over wasm is the easy-to-use packages (which is a pain in c++), and the ease with which you can make a wasm project with wasm-pack that generates the wasm, js and ts interface.
There really are a lot of libraries that support wasm, it's even a problematic point raised in the article on bevy, with wasm support (so webgl) limiting the api.
It's C++ replacement just not yet there for game dev (maybe never for game dev)
A C++ replacement must have really strong and seamless C++ interop to be considered by anyone currently using C++. You can't have a C++ replacement by ignoring existing C++ users and libraries, no matter how good the the language is.
Swift from Apple and Carbon from Google are stronger contenders at this point.
No language from Apple / Google / Microsoft / whatever can ever be a serious replacement for C++. When the development of the language is dominated by a single entity, the risk that the interests of that entity override those of other users is simply too high.
Vendor-specific languages are fine, if you are developing something for that vendor's ecosystem. But if you don't want to lock your code to a specific ecosystem, an independent language such as C++ or Rust is a better choice.
4 replies →