For a developer tool? Genuine question, how long does the JVM take to start? It used to be slow, but I don't know what it's like now. Check out the speed comparison of a few linters on this page -> https://astral.sh. Would the JVM start before the fastest one finished?
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.
Java doesn't do cooperative multitasking (sorta aka greenthreading). That's why there are all these promise/future/whatever frameworks that do it, vs Golang, Rust, and even JS where it's just part of the runtime.
Yes it does, that is why originally there were green and red threads, the language specification doesn't require which kind exactly a JVM implementation should provide.
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.
Greenthreads were abandoned long ago and aren't present in any mainstream JVM. I don't know about Loom, seems recent (or upcoming?) and specific to OpenJDK.
I rather use tools not stuck in jurassic time of programming language design, again, Go's performance is behind most Java implementations.
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.
Your assertion that Rust isn’t well suited for command line programs contradicts reality, where developer tools for multiple languages are being rewritten in Rust. The new bundlers, linters and formatters for JavaScript and Python (the most popular languages by far) preferring Rust and gaining massive adoption tells me that Rust is pretty well suited to CLI programs.
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.
Don't mistake Rust Evangelism Strike Force, and joining the hype cycle, with the suitabitility for writing CLI developer tools there is nothing there that requires the use of borrow checker.
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.
I've been on HN for a while, I saw the previous hype cycles. I have no doubt we'll see a Zig hype cycle as well.
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.
I think a really important benefit is going to be binary size. That's what initially made me dislike Rust quite a lot.
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.
As ripgrep's author, I think binary size is important, but I think it's simultaneously a niche concern. Saying that they need to be tiny is I think a pretty big overstatement. They might need to be tiny in specific use cases, i.e., niche. But the 99% use case is probably that most users don't care. ripgrep's binary size is already pretty meh (especially compared to similar tooling that relies more heavily on dynamic linking). My guess is that if its binary size doubled even from what it is today, few would notice and even fewer would care.
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.
> But the 99% use case is probably that most users don't care.
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.
> 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.
JVM is like the Cologne Cathedral of the software world.