Ask HN: Will Rust be as popular as Go or C++?
Will Rust continue to remain as a niche language that sometimes people choose as an alternative for C++ or Go, or will it see a rise in adaption soon?
C++ is an entire other beast. Asking whether a language will be as popular as "Go or C++" is like asking whether it'll be as popular as "Julia or Java".
C++ is one of the top 5, maybe one of the top 2 languages that existing software is built in. For about 15 (maybe even 20) years before Java matured, and then another 5-10 before C# became the default for new Windows projects, it was by leaps and bounds the most common language for building desktop and enterprise software. There are still billions of lines of C++ code in production and being maintained, possibly trillions. Not to mention new projects still being begun using it.
FWIW, I personally think Rust has a better chance of becoming the next C++ than Go does, but who can really predict the future anyway?
Moore's law is practically dead now, so most of the newer CPU-bound algorithms start off using GPUs (where you're stuck with GLSL), then move on to custom chips (like Google's tensor units for ML, or Bitmain's ASICs for bitcoin mining).
If we're headed back to the mainframe architecture of putting the inner-loop stuff in hardware, then this is a wonderful time to start doing more with higher-level languages.
Even as things stand, Java and some Lisps are as fast a C for many applications, and they take care of the memory issues just as well as Rust does, but without the effort or cognitive overhead that Rust requires.
Dybvig went to Cisco and open-sourced it. Last I read, Racket lang is swapping over to use Chez as its foundation: https://racket-lang.org
I've also heard that HN is written in Arc, which is a Lisp dialect that runs on top of Racket.
Clojure has immutability on top of atoms/refs/agents, so while Rust is doing Nerf mutation with the borrow-checker, Clojure avoids it in the first place.
That, and generally I think threads are overused. Mostly because spawning a new process has been needlessly slow in the past (especially on Windows). Even in C-land, I've seen so many cases where forking and IPC would be more than fast enough, yet far safer.
And getting back to the hardware aspect, having a single thread and a badass SIMD instruction is usually faster and easier to reason about than multiple threads and general-purpose instructions where your performance gets fetch-execute-cache-hierarchy-memory-bandwidthed to death.
Worst of all, I think this entire mode of computing survives primarily due to marketing reasons. Explaining how something works smarter rather than harder is a difficult sell. Printing "MORE CORES!" "MORE GIGAHERTZ!" on a brochure is an easy and effective way to make the sale.
ripgrep benefits from both having multiple threads and badass SIMD instructions.
I disagree. Currently, the best programming language for "bit twiddling" is C, and throughout the years C has essentially remained the same language that was developed four decades ago. In spite of C remaining one of the most popular programming languages in history, the language could be improved.
Graydon Hoare and the good people at Mozilla Research have decided to put in the legwork themselves and pick up the slack. They managed to do a commendable job, and the quality of their work is being increasingly recognized. The reason is quite clear: the whole world was eagerly looking for "another down-in-the-weeds language for bit twiddling" that helped circumvent the lack of progress imposed on the C programming language. Rust does just that and more.