7 ms·

Rust in Production (2018)

112 points by mromanuk 8y ago

leshow 8y ago
Things that have changed: - NLL (non lexical lifetimes) are now in stable, so working with lifetimes and references is a bit easier - stack traces: failure is still around, it's got a fairly large group using it, it seems. I prefer the std error handling route most times. - async is hard: it's still pretty hard
- WhatIsDukkha 8y ago
  Unfortunately failure and errorchain appear to not be cool anymore (ie I've noticed quite a few people are migrating away from failure just like they did from errorchain) and there doesn't appear to be any push from the Rust team as of yet. I think it's a serious problem as your code base grows and I wish we had some more work on the RFC front.
  - leshow 8y ago
    Given the vanilla error handling is my favorite of the lot, I don't really consider it a bad thing that people are moving away from it. There are some downsides, like the lack of stack traces, but it's a nice pattern. Does it have to be 'one size fits all'?
baq 8y ago
quite smart approach of having a nodejs frontend doing what it's good at (async) calling the backend via simple subprocess/stdio communication. they could almost say they invented CGI :)
- stevekemp 8y ago
  My first thought too! It seems like the speedup they gained was probably as much from the architecture change as it was rust. (That often seems to be the case when people say they saw a significant speedup due to switching to rust, go, or similar.)
- MuffinFlavored 8y ago
  > calling the backend via simple subprocess/stdio communication why is this faster/better than the frontend calling the backend through say, nginx proxy_pass or REST HTTP calls?
  - lugg 8y ago
    Overhead. Nginx/rest involves the ipstack.
    - MuffinFlavored 8y ago
      Isn't there overheard in spawning processes?
  - autarch 8y ago
    They're forking a new process for each request. Passing the request data to that process on stdin when you create it is much simpler than spawning a process, waiting for it to be ready, and then communicating with it via http.
    - apendleton 8y ago
      > They're forking a new process for each request. Hm, I don't think they are. I think they one persistent process managing the state of each document, and many requests might interact with that document, via stdin/stdout channels on that document's process. Makes the case for the rest of what you said all the stronger, though.
  - nevi-me 8y ago
    I did this recently, where I compared going through FFI from Java to Rust, vs through gRPC. gRPC wasn't that much slower than FFI, and its benefit would be that I could have 2 services in the network. FFI had overhead, but its performance profile was consistent, very little fluctuation in runtime.
    - MuffinFlavored 8y ago
faitswulff 8y ago
Anyone know if the first con listed has improved with the introduction of non-lexical lifetimes?
- glennpratt 8y ago
  I would say it has improved quite a bit, but they are still there. It varies quite a bit on what you are doing. At work we have a modest sized project, converted from C, being used and updated for about a year. I don't think it has had any significant lifetime battles; I don't think there are even explicit lifetimes in the source. Data structures exercises will be a different story.
- bfrydl 8y ago
  The specific problem he is referring to should now be fixed with NLL, yeah. That doesn't mean lifetimes aren't still hard to learn at first, though.
- amalcon 8y ago
  I'm not the author, but from my perspective: Yes. Dramatically. Non-lexical lifetimes eliminated the most common cases where the compiler was just wrong. Of course you still need to think about lifetimes, and sometimes warp your program around them. However, it is now much less common for that thinking to arrive at "The compiler is wrong; how can I convince it of that?"
deleted 8y ago
[deleted]
youeseh 8y ago
Rust seems like the right answer for a lot of things except writing servers. For that, Elixir with its Erlang VM seems like a better answer.
- staticassertion 8y ago
  I've been writing servers in Rust and I don't really agree. Granted, these may not be traditional HTTP servers - they're AWS lambdas, which puts them closer to the "some function" than "some server" depending on how you look at it. They work great, I've been able to iterate extremely quickly on a system that has had its requirements changed quite a lot over time. I haven't spent much time optimizing my code at this point but they execute extremely quickly, much faster than my Python lambdas. Regarding the author's complaints: I haven't needed any async. I use threads and it's fine. When async/await is a thing I'll use it, maybe - I really don't think it's going to make a difference but it might free up some memory that I can throw at caching. Error handing in Rust is still a bit uncomfortable. The failure crate has been working for me but it doesn't always feel 'right'.
  - dnautics 8y ago
    > they're AWS lambdas those are not servers! In fact the branding of AWS lambda is exactly "serverless". You don't have to have process restart logic, they're very transient, if a process error causes a crash (yes that happens even in rust) the entire thing is taken down. They're less of a server than a kubernetes-orchestrated container.
    - staticassertion 8y ago
      Sure, sorry, I meant services where I wrote "servers" and it's likely the person I responded to did as well. I don't think it changes anything about what I said - process restarts aren't something I'd care about the language for anyways, I'd have a sidecar for that.
      - youeseh 8y ago

112 points by mromanuk 8y ago

Things that have changed: - NLL (non lexical lifetimes) are now in stable, so working with lifetimes and references is a bit easier - stack traces: failure is still around, it's got a fairly large group using it, it seems. I prefer the std error handling route most times. - async is hard: it's still pretty hard

WhatIsDukkha 8y ago
Unfortunately failure and errorchain appear to not be cool anymore (ie I've noticed quite a few people are migrating away from failure just like they did from errorchain) and there doesn't appear to be any push from the Rust team as of yet. I think it's a serious problem as your code base grows and I wish we had some more work on the RFC front.
- leshow 8y ago
  Given the vanilla error handling is my favorite of the lot, I don't really consider it a bad thing that people are moving away from it. There are some downsides, like the lack of stack traces, but it's a nice pattern. Does it have to be 'one size fits all'?

baq 8y ago

quite smart approach of having a nodejs frontend doing what it's good at (async) calling the backend via simple subprocess/stdio communication. they could almost say they invented CGI :)

stevekemp 8y ago
My first thought too! It seems like the speedup they gained was probably as much from the architecture change as it was rust. (That often seems to be the case when people say they saw a significant speedup due to switching to rust, go, or similar.)
MuffinFlavored 8y ago
> calling the backend via simple subprocess/stdio communication why is this faster/better than the frontend calling the backend through say, nginx proxy_pass or REST HTTP calls?
- lugg 8y ago
  Overhead. Nginx/rest involves the ipstack.
  - MuffinFlavored 8y ago
    Isn't there overheard in spawning processes?
- autarch 8y ago
  They're forking a new process for each request. Passing the request data to that process on stdin when you create it is much simpler than spawning a process, waiting for it to be ready, and then communicating with it via http.
  - apendleton 8y ago
    > They're forking a new process for each request. Hm, I don't think they are. I think they one persistent process managing the state of each document, and many requests might interact with that document, via stdin/stdout channels on that document's process. Makes the case for the rest of what you said all the stronger, though.
- nevi-me 8y ago
  I did this recently, where I compared going through FFI from Java to Rust, vs through gRPC. gRPC wasn't that much slower than FFI, and its benefit would be that I could have 2 services in the network. FFI had overhead, but its performance profile was consistent, very little fluctuation in runtime.
  - MuffinFlavored 8y ago

faitswulff 8y ago

Anyone know if the first con listed has improved with the introduction of non-lexical lifetimes?

glennpratt 8y ago
I would say it has improved quite a bit, but they are still there. It varies quite a bit on what you are doing. At work we have a modest sized project, converted from C, being used and updated for about a year. I don't think it has had any significant lifetime battles; I don't think there are even explicit lifetimes in the source. Data structures exercises will be a different story.
bfrydl 8y ago
The specific problem he is referring to should now be fixed with NLL, yeah. That doesn't mean lifetimes aren't still hard to learn at first, though.
amalcon 8y ago
I'm not the author, but from my perspective: Yes. Dramatically. Non-lexical lifetimes eliminated the most common cases where the compiler was just wrong. Of course you still need to think about lifetimes, and sometimes warp your program around them. However, it is now much less common for that thinking to arrive at "The compiler is wrong; how can I convince it of that?"

deleted 8y ago

[deleted]

youeseh 8y ago

Rust seems like the right answer for a lot of things except writing servers. For that, Elixir with its Erlang VM seems like a better answer.

staticassertion 8y ago
I've been writing servers in Rust and I don't really agree. Granted, these may not be traditional HTTP servers - they're AWS lambdas, which puts them closer to the "some function" than "some server" depending on how you look at it. They work great, I've been able to iterate extremely quickly on a system that has had its requirements changed quite a lot over time. I haven't spent much time optimizing my code at this point but they execute extremely quickly, much faster than my Python lambdas. Regarding the author's complaints: I haven't needed any async. I use threads and it's fine. When async/await is a thing I'll use it, maybe - I really don't think it's going to make a difference but it might free up some memory that I can throw at caching. Error handing in Rust is still a bit uncomfortable. The failure crate has been working for me but it doesn't always feel 'right'.
- dnautics 8y ago
  > they're AWS lambdas those are not servers! In fact the branding of AWS lambda is exactly "serverless". You don't have to have process restart logic, they're very transient, if a process error causes a crash (yes that happens even in rust) the entire thing is taken down. They're less of a server than a kubernetes-orchestrated container.
  - staticassertion 8y ago
    Sure, sorry, I meant services where I wrote "servers" and it's likely the person I responded to did as well. I don't think it changes anything about what I said - process restarts aren't something I'd care about the language for anyways, I'd have a sidecar for that.
    - youeseh 8y ago