8 ms·

Why Rust in Production?

152 points by zaphodias 3y ago

fn-mote 3y ago
The benchmark link doesn't work for me. (Blame my adblocker??) The graphics in the article are interesting but don't include a way to identify which are Rust/Java/Go/Python. Maybe you're supposed to assume they come in the order given, but the x-axis is time... could definitely be clearer. (Also apparently not from the OP, just the cited article.)
- steveklabnik 3y ago
  The first link is missing a "7" at the end, that's why it 404s. The second one works though: https://medium.com/star-gazers/benchmarking-low-level-i-o-c-c-rust-golang-java-python-9a0d505f85f7 https://medium.com/star-gazers/benchmarking-low-level-i-o-c-... "Rust, Go, Java, Python" in order, left to right, yes.
  - mcronce 3y ago
    There's an oddity in that article...the C++ p99.9 is lower than its p99. Am I crazy or should that not be possible?
    - steveklabnik 3y ago
      That is confusing to me as well, yes.
- jiehong 3y ago
  Also, this kind of throughput in Java 11 in 2021 while Java 17 was already out is a bit meh. Nowadays, with Java 21 and virtual threads, results might be quite different (and the default GC has changed as well). I agree with the graphs being unreadable. The tables in the benchmark article are easier to read.
  - ackfoobar 3y ago
    Also, not using ZGC when latency is the focus just strikes me as unserious. "Benchmarked on JDK 11, with G1"
- mre 3y ago
  Author here. The link is fixed thanks to M3t0r on GitHub: https://github.com/corrode/corrode.github.io/pull/6 https://github.com/corrode/corrode.github.io/pull/6 The source code of the blog is open source. Contributions like these are very welcome.
bandyaboot 3y ago
This is such a well written post. No fluff, gets straight to point while still offering some context, easy to skim through and get the main points. Bravo, top notch technical communication.
fusslo 3y ago
Rust looks nicer and nicer. Is anyone familiar with RAM/Memory requirements as compared to c? Every microcontroller project I've worked on, as we approach maturity, goes through a round of freeing up ram and code space. Usually deleting strings, removing debug functionality, or shortening datatypes.. etc Can I write rust code with the same footprint as c code?
- askonomm 3y ago
  You might enjoy this blog post: https://darkcoding.net/software/a-very-small-rust-binary-indeed/ https://darkcoding.net/software/a-very-small-rust-binary-ind... It illustrates the steps to take Rust from 3.6MiB executable to 400 bytes, by stripping more and more things away, and changing things.
  - fusslo 3y ago
    thank you! I am currently enjoying it
  - qweqwe14 3y ago
    Also see min-sized-rust repo[1], which also has this blog post at the bottom (along with others) [1] https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust
- steveklabnik 3y ago
  My employer does embedded Rust. We built our own little OS, Hubris, as the foundation of those projects. A no-op task in Hubris ends up at like 100 bytes, last I measured. https://hubris.oxide.computer/ https://hubris.oxide.computer/ You still have to like, actively think about binary size in order to get things to be that small. But the smallest x86_64 binary rustc has ever produced is 137 bytes. How small your program is up to you, not Rust. EDIT: Oh yeah, I left a similar comment with more details about a year ago: https://news.ycombinator.com/item?id=34032824 https://news.ycombinator.com/item?id=34032824
- inferiorhuman 3y ago
  You definitely can use rust in an embedded space. I rather liked having traits and proper types instead of a giant mess of integer constants. In general I think a lot of the so-called bloat you see with Rust binaries is due to a combination of not using a shared standard library and generics – the former is a non-issue in an embedded context and the latter is well under your control. Sure, ELF includes a lot of fluff but you're not deploying ELF on a microcontroller.
troupo 3y ago
This is a very good article that doesn't shy away from downsides. Below are my personal not-so-humble opinions. > Rust has a great developer experience. Its type system is very powerful and allows you to encode complex invariants about your system in the type system. Usually this means: we have three people doing type-level magic, no one understands it, and when they inevitable quit no one can understand how this works and why it takes weeks to add a small change. > Related to the previous point, the Rust community is still relatively small. It is hard to find developers with professional Rust experience. This directly correlates with what was written previously: "Many developers enjoy working with Rust. It is the most admired language for the 6th year in a row". Enjoyment often comes from early adopters, and people trying the language for some side projects. I'll admit, however, that Rust seems to have crossed the chasm in the adoption cycle. > Rust has a famously steep learning curve. It is a complex language with many advanced features. Combined with "It is hard to find developers with professional Rust experience" and "mostly training their developers on the job", stay away from it unless you know exactly what you are doing. > more than 2/3 of respondents are confident in contributing to a Rust codebase within two months or less when learning Rust. This is a huge amount of time. However, unclear: is this due to the language, due to being thrust into a new domain/role/job, or both.
- foobarian 3y ago
  The survey toward the bottom was interesting; ownership and lifetimes showing up as the hardest things to learn for new users. And those are exactly the things that GC solves, or that were historically been involved in majority of security vulnerabilities.
  - topspin 3y ago
    The actual data toward the top was also interesting; the cost of GC is high and Rust eliminates it.
    - foobarian 3y ago
      Easy to learn, safe, fast: pick two
greenhearth 3y ago
Are there actual jobs in Rust? This is not snark, btw. I love Rust and I am currently learning it. Genuinely curious, since I have not seen a lot of listings for it, if any.
- pornel 3y ago
  https://www.rustjobs.fyi https://www.rustjobs.fyi
- slau 3y ago
  Not a direct answer, but I do get a decent amount of contracting work for Rust. Mostly for 2-3 year old projects where the original Rust developer has moved on and they need a small fix or feature change.
  - pdimitar 3y ago
    Do you have any leads you'd be comfortable with sharing?
    - slau 3y ago
      I mostly work with local clients born out of my networking.
- paholg 3y ago
  My current and previous jobs have been in Rust. They're definitely out there.
- jokethrowaway 3y ago
  Plenty in crypto. A few others. Not enough to pay well enough, it reminds me of node.js in the early days. I'm active in the community, do rust events but I can't find something that pays more than js consulting with untouchable companies. I guess at some point I'll have to decide between money and my soul
defanor 3y ago
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
lakomen 3y ago
I had to laugh at the "great developer experience". Meaningless error messages, unreadable syntaxes, forced structures, no explanation why the solution to certain errors is importing some lib. You write backend code as of you were writing frontend code, which is not enjoyable. You always have to think about who owns what. And the whole crate terminology is just stupid. What am I, a dock worker or software designer? No, to each their own but Rust does not have a great developer experience. Compile times are long. What do you gain in performance compared to Go? Not a while lot, and you pay with wasted time aka increased development time and more complicated thought process. It's not for me, and when this blog says great dx, that means it's a propaganda post. In fact the whole article reads like it's trying to convince someone do something they don't want to.
- roarcher 3y ago
  > And the whole crate terminology is just stupid. What am I, a dock worker or software designer? Of all the reasons to complain about a programming language, the package manager not being elitist enough is certainly an original one.
- golergka 3y ago
  > What am I, a dock worker or software designer? You really must hate this thing we use instead of VMs nowadays.
- qweqwe14 3y ago
  > Meaningless error messages, unreadable syntaxes, forced structures, no explanation why the solution to certain errors is importing some lib. The compiler has pretty good error messages, `rustc --explain` exists, "unreadable syntax" is a common complaint from people that expect everything to be C-like or Python (or are just trolling), "forced structures" is explained by Rust being a statically typed programming language. > You write backend code as of you were writing frontend code, which is not enjoyable. No idea what's this about. > You always have to think about who owns what. If your code is well-structured this is a non-issue. The types of people that complain about ownership are the ones that write messy code with chaotic inter-dependencies and unclear semantics. And besides, you have to do that anyway in e.g. C++, only it doesn't enforce it, which leads to programmer error, which is worse. Or you can use reference counting if you have skill issue. > Compile times are long. Compared to what? They aren't much longer when comparing apples to apples: C++ with static analysis tools and Valgrind will have pretty much the same compile times. Again, a bold general statement that doesn't really say much. > What do you gain in performance compared to Go? Not a while lot, and you pay with wasted time aka increased development time and more complicated thought process. Performance in what? For non compute-intensive tasks you can obviously pick any language you are comfortable with. Obviously there's no point using C++ to serve a static site when a simple Python server will do. In benchmarks, Rust just murders Go in performance, so you are objectively wrong if you are talking about raw performance. > that means it's a propaganda post Based on your wacky arguments, I'd say that your comment is in fact propaganda.
pjmlp 3y ago
Going off topic, but the size of the programming language communities is a good source for shuting down the Kotlin folks on how the language is taking over the world. 17.5 million users versus about 6 million, basically the ones being driven by Google to Kotlin on Android. Back to topic, I feel Rust is a great language for production on scenarios where having automatic memory management is forbidden, like in high integrity computing, GPGPU code, micro-controllers and such. Everywhere else, a mix of automatic memory mangement, value types and eventually linear typing, are a much ergonomic approach.

152 points by zaphodias 3y ago

The benchmark link doesn't work for me. (Blame my adblocker??) The graphics in the article are interesting but don't include a way to identify which are Rust/Java/Go/Python. Maybe you're supposed to assume they come in the order given, but the x-axis is time... could definitely be clearer. (Also apparently not from the OP, just the cited article.)

steveklabnik 3y ago
The first link is missing a "7" at the end, that's why it 404s. The second one works though: https://medium.com/star-gazers/benchmarking-low-level-i-o-c-c-rust-golang-java-python-9a0d505f85f7 https://medium.com/star-gazers/benchmarking-low-level-i-o-c-... "Rust, Go, Java, Python" in order, left to right, yes.
- mcronce 3y ago
  There's an oddity in that article...the C++ p99.9 is lower than its p99. Am I crazy or should that not be possible?
  - steveklabnik 3y ago
    That is confusing to me as well, yes.
jiehong 3y ago
Also, this kind of throughput in Java 11 in 2021 while Java 17 was already out is a bit meh. Nowadays, with Java 21 and virtual threads, results might be quite different (and the default GC has changed as well). I agree with the graphs being unreadable. The tables in the benchmark article are easier to read.
- ackfoobar 3y ago
  Also, not using ZGC when latency is the focus just strikes me as unserious. "Benchmarked on JDK 11, with G1"
mre 3y ago
Author here. The link is fixed thanks to M3t0r on GitHub: https://github.com/corrode/corrode.github.io/pull/6 https://github.com/corrode/corrode.github.io/pull/6 The source code of the blog is open source. Contributions like these are very welcome.

bandyaboot 3y ago

This is such a well written post. No fluff, gets straight to point while still offering some context, easy to skim through and get the main points. Bravo, top notch technical communication.

fusslo 3y ago

Rust looks nicer and nicer. Is anyone familiar with RAM/Memory requirements as compared to c? Every microcontroller project I've worked on, as we approach maturity, goes through a round of freeing up ram and code space. Usually deleting strings, removing debug functionality, or shortening datatypes.. etc Can I write rust code with the same footprint as c code?

askonomm 3y ago
You might enjoy this blog post: https://darkcoding.net/software/a-very-small-rust-binary-indeed/ https://darkcoding.net/software/a-very-small-rust-binary-ind... It illustrates the steps to take Rust from 3.6MiB executable to 400 bytes, by stripping more and more things away, and changing things.
- fusslo 3y ago
  thank you! I am currently enjoying it
- qweqwe14 3y ago
  Also see min-sized-rust repo[1], which also has this blog post at the bottom (along with others) [1] https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust
steveklabnik 3y ago
My employer does embedded Rust. We built our own little OS, Hubris, as the foundation of those projects. A no-op task in Hubris ends up at like 100 bytes, last I measured. https://hubris.oxide.computer/ https://hubris.oxide.computer/ You still have to like, actively think about binary size in order to get things to be that small. But the smallest x86_64 binary rustc has ever produced is 137 bytes. How small your program is up to you, not Rust. EDIT: Oh yeah, I left a similar comment with more details about a year ago: https://news.ycombinator.com/item?id=34032824 https://news.ycombinator.com/item?id=34032824
inferiorhuman 3y ago
You definitely can use rust in an embedded space. I rather liked having traits and proper types instead of a giant mess of integer constants. In general I think a lot of the so-called bloat you see with Rust binaries is due to a combination of not using a shared standard library and generics – the former is a non-issue in an embedded context and the latter is well under your control. Sure, ELF includes a lot of fluff but you're not deploying ELF on a microcontroller.

troupo 3y ago

This is a very good article that doesn't shy away from downsides. Below are my personal not-so-humble opinions. > Rust has a great developer experience. Its type system is very powerful and allows you to encode complex invariants about your system in the type system. Usually this means: we have three people doing type-level magic, no one understands it, and when they inevitable quit no one can understand how this works and why it takes weeks to add a small change. > Related to the previous point, the Rust community is still relatively small. It is hard to find developers with professional Rust experience. This directly correlates with what was written previously: "Many developers enjoy working with Rust. It is the most admired language for the 6th year in a row". Enjoyment often comes from early adopters, and people trying the language for some side projects. I'll admit, however, that Rust seems to have crossed the chasm in the adoption cycle. > Rust has a famously steep learning curve. It is a complex language with many advanced features. Combined with "It is hard to find developers with professional Rust experience" and "mostly training their developers on the job", stay away from it unless you know exactly what you are doing. > more than 2/3 of respondents are confident in contributing to a Rust codebase within two months or less when learning Rust. This is a huge amount of time. However, unclear: is this due to the language, due to being thrust into a new domain/role/job, or both.

foobarian 3y ago
The survey toward the bottom was interesting; ownership and lifetimes showing up as the hardest things to learn for new users. And those are exactly the things that GC solves, or that were historically been involved in majority of security vulnerabilities.
- topspin 3y ago
  The actual data toward the top was also interesting; the cost of GC is high and Rust eliminates it.
  - foobarian 3y ago
    Easy to learn, safe, fast: pick two

greenhearth 3y ago

Are there actual jobs in Rust? This is not snark, btw. I love Rust and I am currently learning it. Genuinely curious, since I have not seen a lot of listings for it, if any.

pornel 3y ago
https://www.rustjobs.fyi https://www.rustjobs.fyi
slau 3y ago
Not a direct answer, but I do get a decent amount of contracting work for Rust. Mostly for 2-3 year old projects where the original Rust developer has moved on and they need a small fix or feature change.
- pdimitar 3y ago
  Do you have any leads you'd be comfortable with sharing?
  - slau 3y ago
    I mostly work with local clients born out of my networking.
paholg 3y ago
My current and previous jobs have been in Rust. They're definitely out there.
jokethrowaway 3y ago
Plenty in crypto. A few others. Not enough to pay well enough, it reminds me of node.js in the early days. I'm active in the community, do rust events but I can't find something that pays more than js consulting with untouchable companies. I guess at some point I'll have to decide between money and my soul

defanor 3y ago

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

lakomen 3y ago

I had to laugh at the "great developer experience". Meaningless error messages, unreadable syntaxes, forced structures, no explanation why the solution to certain errors is importing some lib. You write backend code as of you were writing frontend code, which is not enjoyable. You always have to think about who owns what. And the whole crate terminology is just stupid. What am I, a dock worker or software designer? No, to each their own but Rust does not have a great developer experience. Compile times are long. What do you gain in performance compared to Go? Not a while lot, and you pay with wasted time aka increased development time and more complicated thought process. It's not for me, and when this blog says great dx, that means it's a propaganda post. In fact the whole article reads like it's trying to convince someone do something they don't want to.

roarcher 3y ago
> And the whole crate terminology is just stupid. What am I, a dock worker or software designer? Of all the reasons to complain about a programming language, the package manager not being elitist enough is certainly an original one.
golergka 3y ago
> What am I, a dock worker or software designer? You really must hate this thing we use instead of VMs nowadays.
qweqwe14 3y ago
> Meaningless error messages, unreadable syntaxes, forced structures, no explanation why the solution to certain errors is importing some lib. The compiler has pretty good error messages, `rustc --explain` exists, "unreadable syntax" is a common complaint from people that expect everything to be C-like or Python (or are just trolling), "forced structures" is explained by Rust being a statically typed programming language. > You write backend code as of you were writing frontend code, which is not enjoyable. No idea what's this about. > You always have to think about who owns what. If your code is well-structured this is a non-issue. The types of people that complain about ownership are the ones that write messy code with chaotic inter-dependencies and unclear semantics. And besides, you have to do that anyway in e.g. C++, only it doesn't enforce it, which leads to programmer error, which is worse. Or you can use reference counting if you have skill issue. > Compile times are long. Compared to what? They aren't much longer when comparing apples to apples: C++ with static analysis tools and Valgrind will have pretty much the same compile times. Again, a bold general statement that doesn't really say much. > What do you gain in performance compared to Go? Not a while lot, and you pay with wasted time aka increased development time and more complicated thought process. Performance in what? For non compute-intensive tasks you can obviously pick any language you are comfortable with. Obviously there's no point using C++ to serve a static site when a simple Python server will do. In benchmarks, Rust just murders Go in performance, so you are objectively wrong if you are talking about raw performance. > that means it's a propaganda post Based on your wacky arguments, I'd say that your comment is in fact propaganda.

pjmlp 3y ago

Going off topic, but the size of the programming language communities is a good source for shuting down the Kotlin folks on how the language is taking over the world. 17.5 million users versus about 6 million, basically the ones being driven by Google to Kotlin on Android. Back to topic, I feel Rust is a great language for production on scenarios where having automatic memory management is forbidden, like in high integrity computing, GPGPU code, micro-controllers and such. Everywhere else, a mix of automatic memory mangement, value types and eventually linear typing, are a much ergonomic approach.