5 ms·

Recently I decided to try Rust at work as well, after using it a little as a hobby, just to replace a basic shell script with it at first. While reliability, er

Recently I decided to try Rust at work as well, after using it a little as a hobby, just to replace a basic shell script with it at first. While reliability, ergonomics, and other positive sides either do not beat Haskell (which I use for most programs, except for a few small shell scripts or [PL/pg]SQL functions) or it does not matter here, I similarly ran into that "immature ecosystem" issue: apparently people are still supposed to run a nightly build or rustup, but not a compiler from stable system's repositories, let alone libraries. It was that way when Rust was really new, which was understandable, but it is odd to run into that now, and also as the article mentions, even with basic libraries: I ended up using eprintln! instead of a logging library (fortunately used it with systemd, which picks up stderr output, and did not really need to set syslog levels or additional fields), env.args instead of an argument parsing library. Mostly agreed with the conclusion, too: the language still looks good, especially as a C alternative, and hopefully it will be usable in a more stable setting. Gradually trying it out does not feel like a pivotal decision though, that sounds overly dramatic.

slau 3y ago
Using Rust without using the features provided by Cargo is akin to buying an electric car and asking for all the electronics to be removed. Rust libraries will never be shipped by your distro’s package manager. Maybe a few exceptions for things that also have C bindings, but it will never be the default.
- steveklabnik 3y ago
  Many Rust libraries are shipped by distro package mangers, right now. But in general, those packages are intended to be used to build the Rust programs that are packaged in the distro, and not for general use. So it is going to be a painful way to try to write programs using Rust's ecosystem, as it is with basically every other non-C or C++ language.
  - bfrog 3y ago
    It’s painful with c and c++ as well, the tool chain/libraries a distributor provides are almost never the ones you want to develop with as they are often ancient
duped 3y ago
> I similarly ran into that "immature ecosystem" issue: apparently people are still supposed to run a nightly build or rustup, but not a compiler from stable system's repositories, let alone libraries. What languages/ecosystems is this not the case? Even with C/C++ you probably shouldn't be relying on your distro's package management for library and toolchain support. Also, you do not need nightly unless there is some very shiny and new feature that you need that isn't on stable yet.
- defanor 3y ago
  With C, I comfortably rely on the distribution's package management, even though it is not a rolling release or anything of that sort (Debian stable). Actually not sure how that would be the case with C, if one does not try to make things incompatible intentionally: the language and the major libraries' APIs are pretty stable there. With Haskell (used for most tasks at work) I get the tools (GHC and Cabal) and most of the dependencies from Debian stable repositories, though loading missing ones from Hackage (but slowly moving towards not relying on Hackage at all). And keeping sources compatible with package versions from Debian repositories from version 9 to 12 (4 major versions, 6 years apart). With shell scripts, sticking to POSIX; with SQL ones, avoiding extensions and also doing fine.
  - duped 3y ago
    We have very different experiences, I haven't worked on a production C/C++ project in the last decade that didn't vendor dependencies somehow. Debian stable is especially unreliable. In fact I can't think of a time I haven't had issues when working on a team greater than 1 or shipping builds because distro packaged libraries aren't reliable. Also, why is it immature for Rust to ship a toolchain and package manager through a sidechannel, but not Haskell?
    - defanor 3y ago
      > why is it immature for Rust to ship a toolchain and package manager through a sidechannel, but not Haskell? Haskell also feels less mature to me than C, with fewer POSIX functions being readily available, but as mentioned above, with Haskell (in my experience; the experiences indeed seem to differ) it is "one or two dependencies have to be pulled from Hackage across multiple projects and system versions", while in Rust it is rather "I failed to pull common logging and argument parsing dependencies on a single up-to-date stable system, and apparently one is supposed to install and update its compiler, package manager, and libraries separately from the rest of the system". Though some use ghcup or Stack, which also aim working without a system package manager, but at least a system package manager is a viable option.
jokethrowaway 3y ago
Feel free to use stable, plenty of libraries target stable. At the beginning I was using stable without many problems. I switched to nightly to access the last language features and I have no reason not to use it (I've never encountered a nightly bug in 4 years) Haskell is my favourite language (if we forget prelude, exceptions, strings and a few other warts) but Rust wins hands down on pragmatism and getting things done. The tooling (cargo vs stack) is way better and there are more production ready libraries to do cool things.
MiguelX413 3y ago
> env.args instead of an argument parsing library. I'm sorry do you not use https://github.com/clap-rs/clap https://github.com/clap-rs/clap ?
- defanor 3y ago
  This is the one I tried to use, but failed to, since one of its dependencies required a rustc version newer than what I have here (1.63.0), and cargo was not able to pick the latest compatible version, but suggested that I do that manually instead. Which surprised me as well, since I keep hearing about it being nice, yet resolving dependencies is something other package managers (and Cabal in particular) tend to do. I tried to find what is the last version of that package supporting my compiler version, failed to do it quickly (how is one supposed to go around such a task, by the way?), and gave up.
  - steveklabnik 3y ago
    It appears both clap 2 and clap 3 have packages in bookworm. Were you trying to use them from crates.io instead of apt? Clap is on version 4 there. > how is one supposed to go around such a task, by the way? There is not great tooling for this, because most people use the latest stable when starting a new project, and then rust being backwards compatible means things Just Work into the future. A vanishingly small number of folks use builds significantly older than that, since upgrading is generally trivial, and newer compilers have faster build times and better error messages.
    - defanor 3y ago
      Oh, I have not tried using it from system repositories: I tried that with another library (in a hobby project) before, had issues with that, been told and generally gathered that it is easier to pull dependencies with cargo, so went straight to that this time. I see that librust-clap-dev would pull 157 other packages with it though, but will look more closely into it: I would actually prefer getting dependencies from system repositories, thanks for pointing it out. As for newer compilers, I prefer to depend on system repositories and package manager for updates, and to stick to stable branches, so that things do not change too often. I see the appeal of rolling release distributions and cutting edge software, but not feeling comfortable using it for things that are supposed to be reliable.

slau 3y ago

Using Rust without using the features provided by Cargo is akin to buying an electric car and asking for all the electronics to be removed. Rust libraries will never be shipped by your distro’s package manager. Maybe a few exceptions for things that also have C bindings, but it will never be the default.

steveklabnik 3y ago
Many Rust libraries are shipped by distro package mangers, right now. But in general, those packages are intended to be used to build the Rust programs that are packaged in the distro, and not for general use. So it is going to be a painful way to try to write programs using Rust's ecosystem, as it is with basically every other non-C or C++ language.
- bfrog 3y ago
  It’s painful with c and c++ as well, the tool chain/libraries a distributor provides are almost never the ones you want to develop with as they are often ancient

duped 3y ago

> I similarly ran into that "immature ecosystem" issue: apparently people are still supposed to run a nightly build or rustup, but not a compiler from stable system's repositories, let alone libraries. What languages/ecosystems is this not the case? Even with C/C++ you probably shouldn't be relying on your distro's package management for library and toolchain support. Also, you do not need nightly unless there is some very shiny and new feature that you need that isn't on stable yet.

defanor 3y ago
With C, I comfortably rely on the distribution's package management, even though it is not a rolling release or anything of that sort (Debian stable). Actually not sure how that would be the case with C, if one does not try to make things incompatible intentionally: the language and the major libraries' APIs are pretty stable there. With Haskell (used for most tasks at work) I get the tools (GHC and Cabal) and most of the dependencies from Debian stable repositories, though loading missing ones from Hackage (but slowly moving towards not relying on Hackage at all). And keeping sources compatible with package versions from Debian repositories from version 9 to 12 (4 major versions, 6 years apart). With shell scripts, sticking to POSIX; with SQL ones, avoiding extensions and also doing fine.
- duped 3y ago
  We have very different experiences, I haven't worked on a production C/C++ project in the last decade that didn't vendor dependencies somehow. Debian stable is especially unreliable. In fact I can't think of a time I haven't had issues when working on a team greater than 1 or shipping builds because distro packaged libraries aren't reliable. Also, why is it immature for Rust to ship a toolchain and package manager through a sidechannel, but not Haskell?
  - defanor 3y ago
    > why is it immature for Rust to ship a toolchain and package manager through a sidechannel, but not Haskell? Haskell also feels less mature to me than C, with fewer POSIX functions being readily available, but as mentioned above, with Haskell (in my experience; the experiences indeed seem to differ) it is "one or two dependencies have to be pulled from Hackage across multiple projects and system versions", while in Rust it is rather "I failed to pull common logging and argument parsing dependencies on a single up-to-date stable system, and apparently one is supposed to install and update its compiler, package manager, and libraries separately from the rest of the system". Though some use ghcup or Stack, which also aim working without a system package manager, but at least a system package manager is a viable option.

jokethrowaway 3y ago

Feel free to use stable, plenty of libraries target stable. At the beginning I was using stable without many problems. I switched to nightly to access the last language features and I have no reason not to use it (I've never encountered a nightly bug in 4 years) Haskell is my favourite language (if we forget prelude, exceptions, strings and a few other warts) but Rust wins hands down on pragmatism and getting things done. The tooling (cargo vs stack) is way better and there are more production ready libraries to do cool things.

MiguelX413 3y ago

> env.args instead of an argument parsing library. I'm sorry do you not use https://github.com/clap-rs/clap https://github.com/clap-rs/clap ?

defanor 3y ago
This is the one I tried to use, but failed to, since one of its dependencies required a rustc version newer than what I have here (1.63.0), and cargo was not able to pick the latest compatible version, but suggested that I do that manually instead. Which surprised me as well, since I keep hearing about it being nice, yet resolving dependencies is something other package managers (and Cabal in particular) tend to do. I tried to find what is the last version of that package supporting my compiler version, failed to do it quickly (how is one supposed to go around such a task, by the way?), and gave up.
- steveklabnik 3y ago
  It appears both clap 2 and clap 3 have packages in bookworm. Were you trying to use them from crates.io instead of apt? Clap is on version 4 there. > how is one supposed to go around such a task, by the way? There is not great tooling for this, because most people use the latest stable when starting a new project, and then rust being backwards compatible means things Just Work into the future. A vanishingly small number of folks use builds significantly older than that, since upgrading is generally trivial, and newer compilers have faster build times and better error messages.
  - defanor 3y ago
    Oh, I have not tried using it from system repositories: I tried that with another library (in a hobby project) before, had issues with that, been told and generally gathered that it is easier to pull dependencies with cargo, so went straight to that this time. I see that librust-clap-dev would pull 157 other packages with it though, but will look more closely into it: I would actually prefer getting dependencies from system repositories, thanks for pointing it out. As for newer compilers, I prefer to depend on system repositories and package manager for updates, and to stick to stable branches, so that things do not change too often. I see the appeal of rolling release distributions and cutting edge software, but not feeling comfortable using it for things that are supposed to be reliable.