Hacker News Reader

Comment by pentracchiano | Hacker News Reader

Why is "written in Rust" as important as what the software is about? I noticed this tendency of specifying when something is written in Rust.

Should it be an indicator of better stability? Or performance? And if so, am I interested in the performance of a dotfile tool?

Genuinely curious.

View on HN

Easy to deploy, usually single static binaries. Same goes with Golang projects. Polar opposite of java (which I'll totally ignore).

Very funny to me that Java's initial appeal: it's easy to deploy "everywhere"; is now it's disadvantage (you need a whole Java setup with JAVA_HOME and God knows what else).

Now the bar for GUI apps is cross-compilation to deployable web, Windows, Linux (Electron), Android, iOS (? I don't know I don't use/develop for Apple products) versions from running a simple command.

And for the CLI world, well, almost everyone is on Linux x86-64, or maybe arm, so a few static binaries (or "virtually" static -- depending only on glibc) are king for deployment.

I don’t find installing a JVM a massive amount of work (no more so than any other interpreted language), but nowadays you can AOT compile Java to a native binary if that’s your hang-up:

https://www.graalvm.org/jdk24/reference-manual/native-image/

There’s a new LTS release with improvements coming out next week.

It's not as painless as you make it seem though. Among other things, the compiler needs to know reflectively accessed program elements ahead-of-time.

Unfortunately people writing libraries do all kinds of things just because they can and as such I've almost never been able to just simply AOT compile something without more manual efforts.

There are trade-offs using Native Image, for sure. Part of eliminating the JVM is that you won't have the JVM at runtime so you can dynamically load classes. Consequently you need to AOT compile any code you'd dynamically load as well. Release-over-release the tooling and support for dealing with reflection have become more user friendly. More of it is auto-detected during native image build and the remainder can be generated by a runtime agent (at least in my experience). I expect it'll be even easier with the new 25 release.

We've been shipping TruffleRuby as native image builds for years. Other Truffle languages have as well. And it's been quite popular with microservice frameworks. Recently I saw someone on the GraalVM Slack say they AOT compiled a large JavaFX application.

It's work, but probably far less than a rewrite in another language and the tooling is getting better. Obviously I can't speak to your experience, but if you haven't looked at it in a while it might be worth giving newer releases a shot.

Thank you for the insight. It has been a while and now I do want to give it a try again! Maybe it could be nice for small CLI applications instead of using Go.

How is it performance wise? Are there some big things/roadblocks to be aware of?

Half the battle is figuring out which JDK (or is it JRE??) version to install. I still have nightmares navigating the maze which is Oracle's site and trying to find the right download, only to have installed the wrong thing.

Installing the latest OpenJDK LTS release will almost certainly work for you. Java is pretty good about backwards compatibility. I'm not sure when you last tried, but you probably don't need to muck around with Oracle JDK builds at at all.

A standalone POSIX shell is far easier to deploy. Something in Rust needs to be packaged for your distro. Want to use another distro where it isn't packaged? Build it from source.

In fact, I'm gonna rewrite my dotfiles manager from Rust into POSIX sh.

It means I can install it easily and it's probably going to work well on the first try, and it'll likely start up and run fast.

It also uses clap for argument parsing so I know I can run it with `--help` to discover its options, and that the parsing of flags is likely not buggy, and consistent with other Rust tools I use.

None of this is _guaranteed_ with Rust, but the tooling and libraries make it so much easier for you to succeed at making a fast and robust piece of software. So for me "written in Rust" is usually a quality indicator of sorts. It's not 100% though, there will always be misses because it's still very possible to write bad software in any language.

It’s the mark of a good programming language that you can, with sufficient effort, write bad code.

Maybe it’s a way to attract contributors?

It can also serve an indicator of being in the know and with the times while also being performance-, close-to-the-metal oriented. "A dot file manager not written in Fortran, but one that could have been written in Python, but actually written in Rust"

Likely no dependency hell in pip or npm. Likely fast and well thought out. Not sure fire things, but given the choice between a program written in Rust (or Go) vs one written in JavaScript or (especially) Python, the former two win every time.

Reply on news.ycombinator.com