4 ms·

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 i

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.

tonymet 1y ago
[flagged]
turtlebits 1y ago
Easy to deploy, usually single static binaries. Same goes with Golang projects. Polar opposite of java (which I'll totally ignore).
- serbuvlad 1y ago
  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.
  - nirvdrum 1y ago
    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/ https://www.graalvm.org/jdk24/reference-manual/native-image/ There’s a new LTS release with improvements coming out next week.
    - turtlebits 1y ago
      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.
      - nirvdrum 1y ago
        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.
    - sureglymop 1y ago
      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.
      - nirvdrum 1y ago
        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.
- WhyNotHugo 1y ago
  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.
metaltyphoon 1y ago
Maybe it’s a way to attract contributors?
bschwindHN 1y ago
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.
- test6554 1y ago
  It’s the mark of a good programming language that you can, with sufficient effort, write bad code.
jen20 1y ago
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.
mrugge 1y ago
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"

tonymet 1y ago

[flagged]

turtlebits 1y ago

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

serbuvlad 1y ago
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.
- nirvdrum 1y ago
  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/ https://www.graalvm.org/jdk24/reference-manual/native-image/ There’s a new LTS release with improvements coming out next week.
  - turtlebits 1y ago
    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.
    - nirvdrum 1y ago
      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.
  - sureglymop 1y ago
    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.
    - nirvdrum 1y ago
      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.
WhyNotHugo 1y ago
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.

metaltyphoon 1y ago

Maybe it’s a way to attract contributors?

bschwindHN 1y ago

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.

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

jen20 1y ago

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.

mrugge 1y ago

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"