5 ms·

Serious question: why Rust? Sounds like this is not exactly systems level programming or any user would suffer from or even notice garbage collection latency.

Serious question: why Rust? Sounds like this is not exactly systems level programming or any user would suffer from or even notice garbage collection latency. Is Rust building up a decent ecosystem now for application programming? When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?

terminaltrove 2y ago
Rust is a popular choice for CLI tools as well as Go and I do think the ecosystem is picking up. In fact there are a bunch of them for the terminal. https://terminaltrove.com/language/rust/ https://terminaltrove.com/language/rust/ https://terminaltrove.com/language/go/ https://terminaltrove.com/language/go/
- sepositus 2y ago
  I've used both, and they are comparable in library support. I happen to write _much_ faster in Go, so it's usually my default choice for CLIs, unless I specifically need to bridge with another Rust program.
pkolaczk 2y ago
Rust is a general purpose programming language not just systems programming language.
lionkor 2y ago
I find Rust super ergonomic for any kind of app. The memory management aspect is trivial and second nature to anyone used to unmanaged languages, and the type system equally is not difficult to understand. It's a general purpose language, but it does give you full control. Plus, of course, you can encode a large amount of program states in the type system and borrowing checks enforce rules that programmers usually have to check in their head. I find that when I write Rust, I have to worry about an order of magnitude less about silly things like lifetime bugs, reference bugs, resource cleanup, all of which are 80% of my job when I write C#, or other similar managed languages. Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime.
- pjmlp 2y ago
  As someone used to unamaged languages since 1986, and with a major focused on systems programing, it isn't that clear cut. Rust executables are only 100% static on OSes that expose system libraries as static libraries, and there are not many of those around, outside embedded systems.
  - jcelerier 2y ago
    After years navigating this issue, I think the common understanding of "static" binary is just "something that won't give me a dll / dylib error on startup when I copy it to my friend's computer"
    - pjmlp 2y ago
      Which is a possibility, given that ldd/Dependency Walker result won't be an empty list. Even shipping the whole computer on a container, might not do it, because most containers are leaky abstractions the way their Dockerfiles are written.
      - Aeolos 2y ago
        Yet in practice this works fine for all intents and purposes. Sure, you might get a loading error if you try to run your Ubuntu 24.04-compiled executable on Ubuntu 18.04 if you use the default toolchain. tTat’s exactly the same as C or C++, only much easier to fix in rust by rustup-installing the right tool chain. Compiling on Ubuntu 18.04 and running on 24.04 is absolutely not an issue. Same for windows. In practice this is really not a problem, especially for cargo libraries that you anyway build from source.
        pjmlp 2y ago
        I would say the same regarding dynamic linking, which is why most OSes have moved away from being static linking only executables, except embedded in the cases where it is a single blob uploaded into the device. Not even modern 3D graphics APIs, none of them, work with static linking, yet another area static linking advocates have to accept the industry has moved on.
tempay 2y ago
Good dependency management, a rich package ecosystem, defaults to static binaries which are easy to distribute and a tendency to be fast (even if it’s just the lack of startup overhead) make it a popular choice. It also helps that rust attracts the kind of devs that make nice tools.
spoiler 2y ago
Honestly, Rust is a breeze to make CLI/TUI apps in. Some crates worth looking into: tokio (mostly for stuff built on top of it), clap, promptly, colored, ratatui. These are just a few ones to get you started, but there's lots more depending on what you need to accomplish!
- deleted 2y ago
  [deleted]
K0nserv 2y ago
Two things: 1. Historically a CLI like this would often be written in C, so Rust isn't that strange of a choice. 2. Rust is know for the borrow checker and being a great low level language. However, it's also an excellent modern general purpose language with a great ecosystem. People end up using it for all kinds of things because it's a joy to use. "When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?" Rust is tricky to grasp initially, the learning curve goes pretty much vertical immediately, but once you "get it" it's very nice. When I started out I overused borrowing and ran into heaps of lifetime problems. I think limiting yourself to only using references for function arguments and, rarely, return values is a good place to start. As soon as you are start adding references to struct you should stop and think about who owns the data and what its lifetime is. Thinking properly about ownership is the big shift from GC languages. Once you've gotten into that habit, lifetimes are downstream from that.
- oguz-ismail 2y ago
  >Historically a CLI like this would often be written in C *Perl
m11a 2y ago
Syntactically it's a pretty nice language, with a nice and sane ecosystem (crates, etc), and it's fun to write (which is a pro especially for unpaid hobby projects). If you get used to it, it's nice to write various things in it. I'd probably use it for CLI tools at this point. You do pay a bit in syntactic overhead (lifetimes, borrow checking perplexities), though you get used to it. I'd still not use it for a standard product-y web app. For CLI tools though, it's pretty good.
- pinoy420 2y ago
  [dead]
Starlevel004 2y ago
The primary purpose of Rust is to write Rust. It is only the secondary purpose to actually write useful things.
- OtomotO 2y ago
  One thing your comment has in common with it then ;-)
deleted 2y ago
[deleted]
HackerThemAll 2y ago
Serious question: why not, if the author just knows Rust? Are you so allergic to anything written in Rust? Then get some new pills and ointments because there's going to be more and more of it.
- jvanderbot 2y ago
  The antibodies are probably to the "written in rust" addendum, which seems unnecessary unless rust adds something to the product. Much of the answer above to "why Rust" concerns the developer, and we are potential customers, so who cares? Just drop the "in Rust" and don't worry going forward. Honestly though I thought we were past the "written in Rust" phase.
  - MyOutfitIsVague 2y ago
    It works. Including on me. I'm much more likely to pay attention to a tool that I know is written in Rust. This is both because I love the language and really enjoy using it, and because I've gotten conditioned to believing that tools written in it will be extremely robust, fast, useful, and stable. I can easily rattle off a dozen tools I use on a regular basis written in Rust that are significantly better than their non-Rust counterparts (starting with ripgrep, which is extremely fast). It's effective marketing still.
- goku12 2y ago
  As a Rust developer, let me point out that this is certainly the wrong way to respond when someone criticizes or makes an observation about Rust. Especially when they aren't hostile at all. It's clear from the commenters' question that they have a some preconceptions about Rust for which they are seeking clarifications from other Rust users. This sort of response will only make them give up on Rust due to the toxicity of the community, rather than address any real issues they may be facing.
  - HackerThemAll 2y ago
    I am not a Rust programmer and barely know it. It's just wherever you go, here, Phoronix, Linux Kernel Mailing List for example, the forums are full of haters that just ask "not again, why?" anytime Rust is mentioned. Maybe I've become biased because of that. Rust helps with performance and security, lots of examples are evidence of that. It's not 100% bulletproof, but nothing is. But it helps. And yet IT people just yell on it for some reason. Like we all should just get stuck forever with C, C++, praise Go, and hate everything else.
goku12 2y ago
Rust is my main programming language and Python the second. Rust is very much useful for application programming - especially these sort of applications. In fact, Rust is the language I sometimes reach for when my shell scripts cross a certain threshold of complexity. Rust even has some tools and an RFC to address the use case of using it like a scripting language (I believe that Go has something similar too). I don't face much friction from the borrow checker to consider it a 'heavy price for not having a garbage collector'. There are even tools like bacon [1] that can give your real-time feedback on your code. It's even better with the default language server. I sometimes train other developers in Rust - mostly people who are not even into systems programming (JS, Python programmers). However, they don't seem to struggle too much with the borrow checker either. Could you elaborate a bit on what you consider as 'the heavy price'? What sort of issues were you facing frequently? [1] https://github.com/Canop/bacon https://github.com/Canop/bacon
zsoltkacsandi 2y ago
I am a huge Rust fan and I work with Rust at my job. I also recently started some open source projects (mostly CLI tools) where I picked Go for one reason: Rust’s learning curve is super steep. In order to make my projects approachable for other developers Go seemed to be a better choice over Rust.
ForTheKidz 2y ago
It's BEEN built so the price has been paid. I'm not going to complain that someone over-engineered a useful tool and got away with it. I will say that rust is pretty damn productive once you organize your brain around ownership. I haven't had to mark a lifetime in over a month.
thiht 2y ago
As a user, if I have the choice between 2 apps, I’ll strongly favor a Go, Rust or ANSI C app over a Python, Ruby, Shell or C++ app. This is because empirically, they usually work better, feel more polished, faster and I can easily contribute patches if I need. If a tool is written in Python, I’ll go out of my way to find a rewrite in another language.
atoav 2y ago
I write a lot in Python, but I love to write small utilities in Rust as well. The tooling around command line stuff is just really good in Rust and the distribution (just a binary) is just simpler. On top of that Rust forces you to handle errors with IO, like paths correctly to a degree that gives you much more confidence in the resulting tool. Give it a try.

terminaltrove 2y ago

Rust is a popular choice for CLI tools as well as Go and I do think the ecosystem is picking up. In fact there are a bunch of them for the terminal. https://terminaltrove.com/language/rust/ https://terminaltrove.com/language/rust/ https://terminaltrove.com/language/go/ https://terminaltrove.com/language/go/

sepositus 2y ago
I've used both, and they are comparable in library support. I happen to write _much_ faster in Go, so it's usually my default choice for CLIs, unless I specifically need to bridge with another Rust program.

pkolaczk 2y ago

Rust is a general purpose programming language not just systems programming language.

lionkor 2y ago

I find Rust super ergonomic for any kind of app. The memory management aspect is trivial and second nature to anyone used to unmanaged languages, and the type system equally is not difficult to understand. It's a general purpose language, but it does give you full control. Plus, of course, you can encode a large amount of program states in the type system and borrowing checks enforce rules that programmers usually have to check in their head. I find that when I write Rust, I have to worry about an order of magnitude less about silly things like lifetime bugs, reference bugs, resource cleanup, all of which are 80% of my job when I write C#, or other similar managed languages. Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime.

pjmlp 2y ago
As someone used to unamaged languages since 1986, and with a major focused on systems programing, it isn't that clear cut. Rust executables are only 100% static on OSes that expose system libraries as static libraries, and there are not many of those around, outside embedded systems.
- jcelerier 2y ago
  After years navigating this issue, I think the common understanding of "static" binary is just "something that won't give me a dll / dylib error on startup when I copy it to my friend's computer"
  - pjmlp 2y ago
    Which is a possibility, given that ldd/Dependency Walker result won't be an empty list. Even shipping the whole computer on a container, might not do it, because most containers are leaky abstractions the way their Dockerfiles are written.
    - Aeolos 2y ago
      Yet in practice this works fine for all intents and purposes. Sure, you might get a loading error if you try to run your Ubuntu 24.04-compiled executable on Ubuntu 18.04 if you use the default toolchain. tTat’s exactly the same as C or C++, only much easier to fix in rust by rustup-installing the right tool chain. Compiling on Ubuntu 18.04 and running on 24.04 is absolutely not an issue. Same for windows. In practice this is really not a problem, especially for cargo libraries that you anyway build from source.
      - pjmlp 2y ago
        I would say the same regarding dynamic linking, which is why most OSes have moved away from being static linking only executables, except embedded in the cases where it is a single blob uploaded into the device. Not even modern 3D graphics APIs, none of them, work with static linking, yet another area static linking advocates have to accept the industry has moved on.

tempay 2y ago

Good dependency management, a rich package ecosystem, defaults to static binaries which are easy to distribute and a tendency to be fast (even if it’s just the lack of startup overhead) make it a popular choice. It also helps that rust attracts the kind of devs that make nice tools.

spoiler 2y ago

Honestly, Rust is a breeze to make CLI/TUI apps in. Some crates worth looking into: tokio (mostly for stuff built on top of it), clap, promptly, colored, ratatui. These are just a few ones to get you started, but there's lots more depending on what you need to accomplish!

deleted 2y ago
[deleted]

K0nserv 2y ago

Two things: 1. Historically a CLI like this would often be written in C, so Rust isn't that strange of a choice. 2. Rust is know for the borrow checker and being a great low level language. However, it's also an excellent modern general purpose language with a great ecosystem. People end up using it for all kinds of things because it's a joy to use. "When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?" Rust is tricky to grasp initially, the learning curve goes pretty much vertical immediately, but once you "get it" it's very nice. When I started out I overused borrowing and ran into heaps of lifetime problems. I think limiting yourself to only using references for function arguments and, rarely, return values is a good place to start. As soon as you are start adding references to struct you should stop and think about who owns the data and what its lifetime is. Thinking properly about ownership is the big shift from GC languages. Once you've gotten into that habit, lifetimes are downstream from that.

oguz-ismail 2y ago
>Historically a CLI like this would often be written in C *Perl

m11a 2y ago

Syntactically it's a pretty nice language, with a nice and sane ecosystem (crates, etc), and it's fun to write (which is a pro especially for unpaid hobby projects). If you get used to it, it's nice to write various things in it. I'd probably use it for CLI tools at this point. You do pay a bit in syntactic overhead (lifetimes, borrow checking perplexities), though you get used to it. I'd still not use it for a standard product-y web app. For CLI tools though, it's pretty good.

pinoy420 2y ago
[dead]

Starlevel004 2y ago

The primary purpose of Rust is to write Rust. It is only the secondary purpose to actually write useful things.

OtomotO 2y ago
One thing your comment has in common with it then ;-)

deleted 2y ago

[deleted]

HackerThemAll 2y ago

Serious question: why not, if the author just knows Rust? Are you so allergic to anything written in Rust? Then get some new pills and ointments because there's going to be more and more of it.

jvanderbot 2y ago
The antibodies are probably to the "written in rust" addendum, which seems unnecessary unless rust adds something to the product. Much of the answer above to "why Rust" concerns the developer, and we are potential customers, so who cares? Just drop the "in Rust" and don't worry going forward. Honestly though I thought we were past the "written in Rust" phase.
- MyOutfitIsVague 2y ago
  It works. Including on me. I'm much more likely to pay attention to a tool that I know is written in Rust. This is both because I love the language and really enjoy using it, and because I've gotten conditioned to believing that tools written in it will be extremely robust, fast, useful, and stable. I can easily rattle off a dozen tools I use on a regular basis written in Rust that are significantly better than their non-Rust counterparts (starting with ripgrep, which is extremely fast). It's effective marketing still.
goku12 2y ago
As a Rust developer, let me point out that this is certainly the wrong way to respond when someone criticizes or makes an observation about Rust. Especially when they aren't hostile at all. It's clear from the commenters' question that they have a some preconceptions about Rust for which they are seeking clarifications from other Rust users. This sort of response will only make them give up on Rust due to the toxicity of the community, rather than address any real issues they may be facing.
- HackerThemAll 2y ago
  I am not a Rust programmer and barely know it. It's just wherever you go, here, Phoronix, Linux Kernel Mailing List for example, the forums are full of haters that just ask "not again, why?" anytime Rust is mentioned. Maybe I've become biased because of that. Rust helps with performance and security, lots of examples are evidence of that. It's not 100% bulletproof, but nothing is. But it helps. And yet IT people just yell on it for some reason. Like we all should just get stuck forever with C, C++, praise Go, and hate everything else.

goku12 2y ago

Rust is my main programming language and Python the second. Rust is very much useful for application programming - especially these sort of applications. In fact, Rust is the language I sometimes reach for when my shell scripts cross a certain threshold of complexity. Rust even has some tools and an RFC to address the use case of using it like a scripting language (I believe that Go has something similar too). I don't face much friction from the borrow checker to consider it a 'heavy price for not having a garbage collector'. There are even tools like bacon [1] that can give your real-time feedback on your code. It's even better with the default language server. I sometimes train other developers in Rust - mostly people who are not even into systems programming (JS, Python programmers). However, they don't seem to struggle too much with the borrow checker either. Could you elaborate a bit on what you consider as 'the heavy price'? What sort of issues were you facing frequently? [1] https://github.com/Canop/bacon https://github.com/Canop/bacon

zsoltkacsandi 2y ago

I am a huge Rust fan and I work with Rust at my job. I also recently started some open source projects (mostly CLI tools) where I picked Go for one reason: Rust’s learning curve is super steep. In order to make my projects approachable for other developers Go seemed to be a better choice over Rust.

ForTheKidz 2y ago

It's BEEN built so the price has been paid. I'm not going to complain that someone over-engineered a useful tool and got away with it. I will say that rust is pretty damn productive once you organize your brain around ownership. I haven't had to mark a lifetime in over a month.

thiht 2y ago

As a user, if I have the choice between 2 apps, I’ll strongly favor a Go, Rust or ANSI C app over a Python, Ruby, Shell or C++ app. This is because empirically, they usually work better, feel more polished, faster and I can easily contribute patches if I need. If a tool is written in Python, I’ll go out of my way to find a rewrite in another language.

atoav 2y ago

I write a lot in Python, but I love to write small utilities in Rust as well. The tooling around command line stuff is just really good in Rust and the distribution (just a binary) is just simpler. On top of that Rust forces you to handle errors with IO, like paths correctly to a degree that gives you much more confidence in the resulting tool. Give it a try.