Here on HN there is plenty of announces of new things “like X but in Rust” - even when X would be fine in Python or Bash.
The reason Rust and Go tooling is getting popular is because they are appropriate for the job.
C and C++ are riddled with footguns and non-ideal for this kind of tooling, Ruby and Python provide only disadvantages compared to current JS tools, Haskell and OCaml are good but too niche. And so on.
And the reason Rust and Go are getting usage in WASM is because they have a good WASM story. They are static, compiled and born at the right time. Other than C and C++, they're the only ones that put the effort.
The reason people are making projects in Rust and Go is because they are accessible to those people. For me both hit a sweet spot that none of the languages above do.
JVM is like the Cologne Cathedral of the software world.
And supposing you took start time out of it, how long would an equivalent Java program take to run?
Memory isn't as much of an issue, but all other things being equal users do prefer the program that consumes less memory.
That wouldn't be true for gccgo implementation, but then again, it is now abandoned in pre-generics Go, stuck at version 1.17, no one seems to care to update it.
Java doesn't even have null safety or ergonomic algebraic data types.
Besides people here sometimes have a hard time understanding English, given that I acknowledged Rust being faster.
And the success of ripgrep, mcfly/atuin, zoxide, hyperfine and starship, just reinforces the feeling that yeah, CLIs written in Rust can succeed.
So yeah, strongly disagree with you about Rust’s place.
But from your previous comments I also know you’re very knowledgeable about Rust so I’m surprised you came to this conclusion.
Depending on how many years into the past of HN headlines we would search for, it would be Go, Scala, Haskell, Ruby,...
Maybe all those Rust CLIs will be all being rewriting into Zig, as soon as version 1.0 gets out.
Roc language is already one of the first.
One of the reasons Rust succeeded, especially in CLI was
1. Low fixed memory overhead (compared to most popular VM based language - Python, Ruby, Java).
2. Startup time is nearly instantaneous, compared to the same languages. Don't have to wait 50-100ms or so just to start executing code.
3. Run time is faster as well, especially so for programs like ripgrep that use SIMD.
4. Single static binary with no dependencies. Didn't need a VM or toolchain to be installed on the user's computer.
Having a great CLI library like clap.rs brought it all together.
If you think this is simply a cycle and Zig will replace Rust, I'm slightly skeptical. Rust had an easier time competing with the status quo because of the 4 advantages it had.
Zig however, will have to compete with Rust. Sure, you can start ziggrep, but it'll be about equal in all these 4 factors. So why would anyone adopt something that has fewer features than ripgrep and about the same performance, memory consumption and ease of use? Just hype? Some people will, but not enough to get the critical mass ripgrep has.
That's why I'm bullish about Rust - the performance of existing codebases means that in many cases, it's hard to migrate away from it, or replace Rust programs with reimplementations. You'd have to be getting something really unique that Rust doesn't offer. You said Roc, and Roc is actually a great example of benefiting from something unique. Roc plans to reuse the Zig compiler's library that emits LLVM bitcode. There's no Rust equivalent.
But I'd argue that that's pretty niche. How many other examples are there of Zig libraries that have no Rust equivalent? Something that would make Zig the no-brainer choice over Rust, even if you had to reimplement in Zig.
Again, I'm sure people will try to rewrite things in Zig. But I'll confidently assert -> the most popular toolchain for Python in 5 years will be Rust based, not Zig or any other language. $10 on that.
And for CLI tools, you need those to be tiny. You're going to many of them, and you'll want to build a whole distribution, which you'll want to be small (for small images, small containers, etc).
Another benefit (that Zig won't offer) is good shared library support, which distribution maintainers will always prefer. I don't think there's a good language for that, but if one will appear, it will definitely be favored.
AFAIK, ripgrep's biggest deployment is through VS Code, by far. Nobody is going to notice that some part of VS Code is now using 8MB instead of 4MB (or whatever it is, I think it's around that). It's largely a non-issue from my perspective.
Now, compile times... That's a different story. I'll happily complain about that one.
For 1 really good utility like ripgrep, yeah. You'll convince many people to use it based on its merits. You might even have 5 or 10 of these utilities, if they're really good.
But for Linux system builders, for the things that go into standard distributions, where you need hundreds of such utilities, Rust CLI binaries are simply not sustainable. Not for size, not for security, not for simplicity of bootstrapping, nor, as you said, for compiling an OS from sources.
You will be able to get ripgrep into many distributions, but it will be more unlikely to become one of the tools installed by default for that reason.
Oh I don't agree with that all. It might be a factor, but it isn't going to be installed by default because grep will already be there. Unseating a POSIX user land in a Linux distro is not going to be blocked just on binary size IMO.
I also think what you're saying is not inconsistent with what I'm saying. The default tools installed on a Linux distro is a niche use case. ripgrep doesn't need to be installed by default in any Linux distro in order to be successful.
If you're setting out to build tools to replace, say, a GNU user-land to fulfill POSIX (or provide an entirely different sort of user experience), then binary size is probably the least interesting thing to overcome. And if you "try" hard enough, Rust binary sizes can be reduced quite a bit. ripgrep being 4MB is the result of me not caring at all about binary size (beyond stripping debug info). But this is a niche goal IMO, and IMO does not support your initial claim:
> And for CLI tools, you need those to be tiny.
Notice how if you instead said:
> And for CLI tools that are installed by default on a Linux distro, you need those to be tiny.
then it takes almost all the air out of your comment.
Pretty sure JVM is also a lottt more overhead.
Also since Java Loom project, it has virtual threads.
Additionally, since at least a decade you could your own thread scheduling if feeling so inclined to do some low level coding, as the scheduling architecture is customisable.
There is probably no language in existence that "ticks all the boxes". And this is good.
Fashion and hype has always played a big role in software and our industry has at times unwisely abandoned good technology in favor of the 'New hotness'. We gyrate between local apps and cloud apps, thin and thick clients, static and dynamic typing, micro-services and monoliths, relational databases and keyval stores. Our industry is not very rational and the best tools don't always win. Marketing and market effects (winners keep winning) play a big role.
Recognizing the role hype plays in our industry is not myopia.
The things people are shipping in Rust are stuff Rust is good for. As far as JS goes: mostly tooling.
Notice how virtually nobody is shipping websites in Rust. Sure there's frameworks and async, but we're not there yet.
The fact people are building libraries for servers, websites, gamedev, etc, in it is something that is required for experimentation.
People don't deserve the disrespect shown here for exercising their curiosity and trying to advance the field.
We all know that rust has a lot of merits, in that it is trying to establish a different, ambitious new trade off wrt. safety ganranties vs expressive power, and as a result is one a the few serious contender to replace C++ in the very areas where C++ is king, trading just a bit of performance for a vastly more sane language and better static garanties.
But it is also fair to acknowledge that more often than not, in the many "old_thing but in rust" that are being posted on HN, the old_thing at hand does not actually fall in that very important but also very small subset of programs that can not tolerate automatic memory management.
In other words, rust was not the good choice from a technical stand point.
Maybe it's particularly obvious to me because I have tried to promote rust before it became cool? At that time my coleagues could only tolerate Python or Go. These days the same people probably program in rust (or are at least considering it), and that's not because rust improved that much, or because they have sudenly learned to use the right tool for the job.
A lot of the things being posted in HN are not products but rather small-to-mid-size programs written by (quite often) experienced developers trying out a new language and somehow managing to scratch theirs or someone else's itch. On top of that, they are learning and we as a community are also learning from their hits and their misses.
A lot of things, such as WASM frameworks, are heavily experimental, and in this very thread there is an example of an author of those saying they're back to working JS. This is fine.
I would be totally fine with comments like "Rust is not good for this" or "Go is not good for that", and I have given some examples myself above. But this is clearly not what's happening here. It's ok to not want to participate on something, but the vitriol and flamewar-bait on those topics is not that.
To me the actual target of those critical comments are not the projects at hand but rather that trend in our industry to let popularity lead our decisions, and how easily we form small chapels that fight each others instead of encouraging learning and practicing several competing techs. Not that it will change anything, though.
And the top level comment about "cool kids" I answered to definitely doesn't have the nuance you suggest it has, nor does the flagged comment comparing it to a religion, or the comments calling people "hipsters". And this thread here is actually better than average.
It is no different than those folks, now 20 years later, that adopt Typescript, but really the only thing they do is to rename the file extension, and keep writing plain old JavaScript as always.
It has been the Most Loved/Most Admired language on Stack Overflow’s developer survey for 9 years in a row. I know that’s a relatively short amount of time for a programming language, but to me it seems like it has some serious staying power.