|
Most of the early intention and excitement was the potential to replace C++, and maybe even at least a little C, in systems-level and native code. Obviously, it was first created to replace the JavaScript engine in Firefox, which was C++, but I know a lot of people working on basic utilities and libraries found all over the core components of any normal Linux distro who had hope we might get something equally performant and expressive to C++, but with a far better developer experience and language-level support for the more modern features that C++ tends to get from something like boost. Or look at things like ripgrep and what not, just trying to replace some of the common GNU coreutils, POSIX command-line things you expect a system to have. It eventually made it into the kernel, even, though only for device drivers and that's probably as far as it will get. I would say this has so far not really panned out. Partly, this is because C++ remains and has always been good enough. Partly, because POSIX component replacements were not made as drop-in replacements, so you still need GNU coreutils and existing bash built-ins and what not if you want build scripts and system scripts to still work. Partly, because so much of the modern developer ecosystem is focused on web development rather than native system-level tooling and libraries that Rust has gravitated toward that because that is who is adopting it. Look at how, for instance, Rust versus Go has become so much more common of a question to see compared to Rust versus C++. It's clearly more expressive and full of features than Go, but unless your system really depends on very predictable latency to the point that garbage collection can't be tolerated, it's not clear there's any real value-add even if it's a "better" language. Rust also suffers a bit from a problem faced by any new language on the scene. If you work in older languages like C, C++, Java, you automatically and easily interoperate with some many existing deployed systems. There's a tested, true, well-maintained library for just about anything you could ever want to do. You can start a project quite quickly by forking something similar that already exists. Languages that did well as up-and-comers had some compelling killer app they were connected to that gave them that ecosystem within some more narrow niche. JavaScript obviously runs in the browser and was the only option for a long-time if you want client-side code to execute in a user's browser. This also proved to be useful for cross-platform desktop apps when computers became powerful enough and disk space plentiful enough that just shipping a browser runtime with every application became a feasible idea. Go had Kubernetes and Docker's rewrite, so if you want to do anything related to container runtimes or orchestration, it's the obvious place to turn. Python came to dominate machine learning because it has great interoperability with native code and it could easily wrap pre-existing Fortran and C++ to get a BLAS and higher-level numerical libaries in a dynamically-typed language with a REPL that was more or less perfect for exploratory, interactive work, and the dreaded operator overloading that developers hate proved to be a great feature for attracting scientists, because it allowed SciPy and NumPy to mimic the syntax of MATLAB, giving a free version with near parity of something that normally costs five grand for a single-user license and researchers were already familiar with using. Rust unfortunately sits in this unholy middle ground for easy adoption. It comes with a very nice build tool and package manager built-in, but the ecosystem unfortunately took on the JavaScript "bring in thousands of tiny libraries that each do one thing" characteristic that is antithetical to C and C++ with gigantic libraries that do everything. The syntax is like 80/20 ML/Algol, so people coming from a functional background will see it and wonder why it's so verbose and can't do better type inference and needs brace-delimiting. People coming from an imperative background will translate the classic "writing C in C++" thing to "writing C++ in Rust" because they don't fully grok the idioms. The compile-time garbage collection thing is a great, very cool feature, not quite as good as something like Idris, but probably the best you'll get out of any language anyone actually uses, but it still sits in this weird middle ground. People coming from C and C++ will get frustrated feeling the compiler doesn't trust them but they're pretty sure they know what they're doing is correct. People coming from dynamically typed or garbage collected languages will just follow the suggestions coming from the rustc error messages until it finally compiles, but without really understanding what the hell the borrow checker is doing or why they need it. If your idea is correct, then you're talking about replacing C++, which is the current backbone for JavaScript and Python. But think about what this entails. You're talking about rewriting the Chromium JavaScript engine on the one hand, and rewriting BLAS, LAPACK, Armadillo, TensorFlow on the other. Who is going to do this? You're talking about low-level systems programmers on the one hand and scientists, applied mathematicians, and engineers on the other. But most actual uptake for Rust is application developers working on relatively greenfield projects. |
> Or look at things like ripgrep and what not, just trying to replace some of the common GNU coreutils, POSIX command-line things you expect a system to have.
This is just not true. I never made ripgrep to replace grep. And you acting like it not being a drop-in replacement being a mistake suggests you're totally missing the point. See: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...
The goal isn't "C++ has to literally die." That's just dumb. It is not going to die in the lifetime of anyone alive today no matter what anyone does.