3 ms·

Probably depends on what you want to be doing Do you want to work in systems, embedded, etc? Rust is almost certainly (at least a large part of) the future We

Probably depends on what you want to be doing Do you want to work in systems, embedded, etc? Rust is almost certainly (at least a large part of) the future Web servers (at the application level)/native apps/games? It's gotten some traction, but the jury is still out

arecurrence 6y ago
Rust is rather painful compared to alternative choices for web servers today. I’ve had to write 10x the code in some circumstances for the same result and I find it becomes hard to reason when you have several async types. However, it has attributes that match it extremely well with function as a service where memory usage, cold start times, consistent execution, and compute costs are major factors. It’s extremely well suited to that environment. I expect to see it thrive here once some aspects of rust settle down further.
- brundolf 6y ago
  Yeah, the web framework situation is also just fairly early right now. Rocket looks promising but it's not at 1.0 yet, and the current release still requires the nightly compiler. It does a whole lot to improve the ergonomics, but even then it's not as easy as Python or Go. So it depends on the usecase. The good news is that the microservices trend makes it easy to optimize the "hot services" with a different language than what you use to throw together all your normal services.
  - akiselev 6y ago
    I wouldn't call it as "easy" as Python or Go but I've been writing production services off the Rocket master branch (all async and compiles on stable rust but the API itself is rather unstable) for the last few months and it's been easily as productive as Django (sans ORM & django-admin integration). 80-90% of my logic is in request guard implementations and diesel types/helpers which get reused all over the place, making the controller logic trivially simple. Reimplementing most of the bells and whistles took less time than trying to decipher Django's magic anytime it goes wrong. Rocket's DI and middleware layer with serde, validator, Rust's error handling, etc really take the pain out of the whole affair. That said I wouldn't recommend it until the ecosystem matures and stabilizes unless you really like updating lifetimes all over rocket libraries every few months.
kingsuper20 6y ago
>Rust is almost certainly (at least a large part of) the future Can you name any design wins for Rust in a product's embedded SW, embedded OS, or device drivers? I've never seen it in the wild. How does Rust deal with hard RT? I'd be interested to see what people had to say.
- brundolf 6y ago
  I have very little direct experience with embedded but I've heard several people talk about having a good experience using Rust for it. It's not hard for me to imagine memory safety without a runtime being pretty useful in that context, if nothing else. That said, I know embedded moves slower than a lot of other areas so maybe "the future" is farther out in that case.
- Rebelgecko 6y ago
  I haven't written anything in rust, but RTIC seems like it might be roughly equivalent to a project like FreeRTOS https://crates.io/crates/cortex-m-rtic https://crates.io/crates/cortex-m-rtic
- follower 6y ago
  There does seem to be a lot of people who are very excited about the potential for Rust as a replacement for C/C++ in the embedded space. There is "Working Group" dedicated to the domain: https://www.rust-lang.org/what/embedded https://www.rust-lang.org/what/embedded & https://blog.rust-embedded.org/newsletter-28/ https://blog.rust-embedded.org/newsletter-28/ Toward the bottom of the page there's a "Production use" section with some quotes from people @ companies using it. There's also an Embedded Rust "book": https://docs.rust-embedded.org/book/ https://docs.rust-embedded.org/book/ In addition to the language itself, the surrounding tooling (e.g. for package management) contributes to the potential wins available from to moving to Rust. My impression is that there are still areas where there isn't yet an idiomatic solution as to how _best_ to represent certain embedded SW concepts in a way that allows Rust's guarantees to be maintained. So I think there's some churn around that as people experiment/learn. (Primarily in relation to some of the physical constraints of the hardware.) One of the companies prominent in the Rust embedded space is Ferrous Systems: https://ferrous-systems.com/ https://ferrous-systems.com/ While it's still early days, relatively speaking, I think a lot of people see a move to Rust as a "once in a generation" opportunity to finally move on from an embedded ecosystem built on substandard vendor C toolchains & also gain from the robustness/safety that Rust offers. In a lot of ways the embedded domain stands to gain even more from what Rust offers because unlike, say, the desktop/server space there isn't another higher level language that's really an option. I'm fairly early in my Rust learning journey but have played a bit with it on an STM32F7 dev board. But so far have spent more time on non-embedded side of things. (Although one of the appealing aspects of Rust for me is that I can use the language on platforms ranging from embedded to server/desktop to the browser (via WebAssembly). And the knowledge is transferable & even a lot of the library support too--thanks to "no_std" packages/crates that have reduced overhead.) As an aside, while learning off & on over an extended period of time, I've found this post really helpful for (re-)learning how to read Rust: https://fasterthanli.me/articles/a-half-hour-to-learn-rust https://fasterthanli.me/articles/a-half-hour-to-learn-rust The post aims to go "through as many Rust snippets as I can, and explain what the keywords and symbols they contain mean" which I've found a useful approach.

arecurrence 6y ago

Rust is rather painful compared to alternative choices for web servers today. I’ve had to write 10x the code in some circumstances for the same result and I find it becomes hard to reason when you have several async types. However, it has attributes that match it extremely well with function as a service where memory usage, cold start times, consistent execution, and compute costs are major factors. It’s extremely well suited to that environment. I expect to see it thrive here once some aspects of rust settle down further.

brundolf 6y ago
Yeah, the web framework situation is also just fairly early right now. Rocket looks promising but it's not at 1.0 yet, and the current release still requires the nightly compiler. It does a whole lot to improve the ergonomics, but even then it's not as easy as Python or Go. So it depends on the usecase. The good news is that the microservices trend makes it easy to optimize the "hot services" with a different language than what you use to throw together all your normal services.
- akiselev 6y ago
  I wouldn't call it as "easy" as Python or Go but I've been writing production services off the Rocket master branch (all async and compiles on stable rust but the API itself is rather unstable) for the last few months and it's been easily as productive as Django (sans ORM & django-admin integration). 80-90% of my logic is in request guard implementations and diesel types/helpers which get reused all over the place, making the controller logic trivially simple. Reimplementing most of the bells and whistles took less time than trying to decipher Django's magic anytime it goes wrong. Rocket's DI and middleware layer with serde, validator, Rust's error handling, etc really take the pain out of the whole affair. That said I wouldn't recommend it until the ecosystem matures and stabilizes unless you really like updating lifetimes all over rocket libraries every few months.

kingsuper20 6y ago

>Rust is almost certainly (at least a large part of) the future Can you name any design wins for Rust in a product's embedded SW, embedded OS, or device drivers? I've never seen it in the wild. How does Rust deal with hard RT? I'd be interested to see what people had to say.

brundolf 6y ago
I have very little direct experience with embedded but I've heard several people talk about having a good experience using Rust for it. It's not hard for me to imagine memory safety without a runtime being pretty useful in that context, if nothing else. That said, I know embedded moves slower than a lot of other areas so maybe "the future" is farther out in that case.
Rebelgecko 6y ago
I haven't written anything in rust, but RTIC seems like it might be roughly equivalent to a project like FreeRTOS https://crates.io/crates/cortex-m-rtic https://crates.io/crates/cortex-m-rtic
follower 6y ago
There does seem to be a lot of people who are very excited about the potential for Rust as a replacement for C/C++ in the embedded space. There is "Working Group" dedicated to the domain: https://www.rust-lang.org/what/embedded https://www.rust-lang.org/what/embedded & https://blog.rust-embedded.org/newsletter-28/ https://blog.rust-embedded.org/newsletter-28/ Toward the bottom of the page there's a "Production use" section with some quotes from people @ companies using it. There's also an Embedded Rust "book": https://docs.rust-embedded.org/book/ https://docs.rust-embedded.org/book/ In addition to the language itself, the surrounding tooling (e.g. for package management) contributes to the potential wins available from to moving to Rust. My impression is that there are still areas where there isn't yet an idiomatic solution as to how _best_ to represent certain embedded SW concepts in a way that allows Rust's guarantees to be maintained. So I think there's some churn around that as people experiment/learn. (Primarily in relation to some of the physical constraints of the hardware.) One of the companies prominent in the Rust embedded space is Ferrous Systems: https://ferrous-systems.com/ https://ferrous-systems.com/ While it's still early days, relatively speaking, I think a lot of people see a move to Rust as a "once in a generation" opportunity to finally move on from an embedded ecosystem built on substandard vendor C toolchains & also gain from the robustness/safety that Rust offers. In a lot of ways the embedded domain stands to gain even more from what Rust offers because unlike, say, the desktop/server space there isn't another higher level language that's really an option. I'm fairly early in my Rust learning journey but have played a bit with it on an STM32F7 dev board. But so far have spent more time on non-embedded side of things. (Although one of the appealing aspects of Rust for me is that I can use the language on platforms ranging from embedded to server/desktop to the browser (via WebAssembly). And the knowledge is transferable & even a lot of the library support too--thanks to "no_std" packages/crates that have reduced overhead.) As an aside, while learning off & on over an extended period of time, I've found this post really helpful for (re-)learning how to read Rust: https://fasterthanli.me/articles/a-half-hour-to-learn-rust https://fasterthanli.me/articles/a-half-hour-to-learn-rust The post aims to go "through as many Rust snippets as I can, and explain what the keywords and symbols they contain mean" which I've found a useful approach.