4 ms·

Many comments in twitter mentions rust still not being ready for server code ( which i start to feel strange since concurrency is the only major issue on the se

by bsaul 8y ago

Many comments in twitter mentions rust still not being ready for server code ( which i start to feel strange since concurrency is the only major issue on the server side, and supposed to be rust strength). Anyone can confirm ?

d33 8y ago
Perhaps they meant webapps: http://www.arewewebyet.org/ http://www.arewewebyet.org/
- markdog12 8y ago
  Latest news: 11 Aug 2017
steveklabnik 8y ago
Wargroove, a recent game by Chucklefish, has its matchmaking server in Rust. Many people are waiting for async/await before saying “please come try this”, as it makes the enterprise far easier. We’re quite close!
n_t 8y ago
I have used rust but I think it has another year before it really shines. 2020 is the year of Rust - async/await, tool ecosystem, various crate stability, etc is happening fast.
- pornel 8y ago
  While you'll hear Rust community often say "just wait until this new hotness", I'd like to clarify it's not like a perpetual "it will be the year of Linux Desktop". Rust has already shipped everything it needed to be production ready. We're just always excited for the next big thing. Two years ago it was incremental compilation, last year it was a new borrow checker, this year it's async/await, etc.
  - steveklabnik 8y ago
    This is also true. It really is about what you’re doing. Async/await in particular enables you to write idiomatic code, right now you have to twist it a bit and can’t do certain things. Other features? I agree with you.
deleted 8y ago
[deleted]
pornel 8y ago
There's a new async/await syntax coming, which will make working with network-heavy code much more pleasant. Currently, it's ready in the sense you can write robust, high-performance network code. It's still easier than in C or C++, but it's not noob-friendly compared to Node.js or Go yet. Code based on Futures uses owned closures a lot, so you need to "get" ownership in order not to fight the compiler. With the async/await syntax, the compiler will be able to relax some of the memory ownership restrictions, and you'll be able to write "normal" code instead of chains of callbacks.
jabl 8y ago
Concurrency, as in multiple OS threads communicating is nicely done, with the borrow checker being able prevent some fairly common multi-thread pitfalls. So for things like data parallelism etc. Rust is already looking pretty good. For server-side stuff, what's not yet done is some infrastructure and improved ergonomics for writing asynchronous or non-blocking code. See https://areweasyncyet.rs/ https://areweasyncyet.rs/ . And then when the infrastructure is there, it'll take a while before the higher-level frameworks take advantage of it.
Dowwie 8y ago
Microsoft is using actix libraries and creating many new rust libraries for their Azure IOT platform. Azure IOT is all about safety at very high speeds, making Rust a great fit for their work. I don't work there.
masklinn 8y ago
Multithreading and multiprocessing work fine, however they may be referring to m:n (aka "async"), which is a story still being written and which the borrow checker currently can make much more frustrating than expected by other languages with m:n threading support (e.g. you can't just close over a lexical variable then use it in multiple steps of an asychronous processing pipeline).
fzzzy 8y ago
This is because of the removal of the fat runtime and green threads about 5 years ago. Since there was no blessed way to do high concurrency in the language any more, some code started using normal threads, some code (tokio) started using normal callbacks. Callbacks in rust are tricky because of the type system. Around a year ago, async/await became possible due to the development of the Pin idea. async with the await! macro is usable now, but the rust community has been bikeshedding over built-in await syntax and last time I looked that discussion was still raging. So you can write scalable servers using normal threads, normal callbacks, and async with the await! macro, but not the final async/await syntax because the community hasn’t even finished deciding what it is. Porting code between these approaches is also not particularily easy. I have seen example code for rust networking libraries that uses all of the different approaches, but mixing the different approaches is also difficult. So that’s probably why people say it’s not ready even though you can write code right now that will work just fine. The “final” way of writing it isn’t ready yet, and if you write one of the current forms, porting to the final form will be a pain.
- woah 8y ago
  Porting from futures to async shouldn’t be too hard based on my experience doing it in JS.
  - fzzzy 8y ago
    Sure, but js doesn’t have rust’s type system. It will probably be straightforward once everything is settled down, but right now Future 0.1 (tokio) and Future 0.3 (async/await) aren’t comptatible and you’ll find examples that use one or the other, or plain threads, or plain callbacks. It’s possible to get up and running quickly with the examples from various libraries, but when you try to mix them, if they use different styles, it becomes very challenging. Once async/await is finalized and everything moves to it this won’t be a problem, but that’s probably going to take at least a year or possibly years.
    - pimeys 8y ago
      I did a test and converted one of my libraries to async/await and it was not that hard. There are easy converters between the future versions for the transition period. https://github.com/pimeys/a2/pull/30/files https://github.com/pimeys/a2/pull/30/files
fxfan 8y ago
https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/ https://www.ageofascent.com/2019/02/04/asp-net-core-saturati... That actix you see appearing in most lists and mostly nearly top is written in Rust btw. Fun fact- frameworks managed by microsoft dominate the space ;)
- woah 8y ago
  IIRC actix was gettin some flack for using very unsafe code to hit those benchmarks. Still cool.
  - fxfan 8y ago
    There is absolutely no shame in using unsafe!
    - JesseWright 8y ago
      The issue was that the author uses unsafe code unsafely and often for questionable performance or ergonomics gains that didn't actually need unsafe anyway. Fortunately, he cleaned up pretty much all of it, as I understand it, with the help of some involved community members when people freaked out about it all.
TheCoelacanth 8y ago
It's pretty nice for server code, but still has one major shortcoming which is that's it's kind of tricky to write high-performance IO-heavy code (it's easy if you want to have a thread blocked on every IO request, but that's bad for performance if you have many concurrent requests). This will improve a lot once async/await stabilizes. It already works great in nightly if all of the libraries you want to use support it.

by bsaul 8y ago

d33 8y ago

Perhaps they meant webapps: http://www.arewewebyet.org/ http://www.arewewebyet.org/

markdog12 8y ago
Latest news: 11 Aug 2017

steveklabnik 8y ago

Wargroove, a recent game by Chucklefish, has its matchmaking server in Rust. Many people are waiting for async/await before saying “please come try this”, as it makes the enterprise far easier. We’re quite close!

n_t 8y ago

I have used rust but I think it has another year before it really shines. 2020 is the year of Rust - async/await, tool ecosystem, various crate stability, etc is happening fast.

pornel 8y ago
While you'll hear Rust community often say "just wait until this new hotness", I'd like to clarify it's not like a perpetual "it will be the year of Linux Desktop". Rust has already shipped everything it needed to be production ready. We're just always excited for the next big thing. Two years ago it was incremental compilation, last year it was a new borrow checker, this year it's async/await, etc.
- steveklabnik 8y ago
  This is also true. It really is about what you’re doing. Async/await in particular enables you to write idiomatic code, right now you have to twist it a bit and can’t do certain things. Other features? I agree with you.

deleted 8y ago

[deleted]

pornel 8y ago

There's a new async/await syntax coming, which will make working with network-heavy code much more pleasant. Currently, it's ready in the sense you can write robust, high-performance network code. It's still easier than in C or C++, but it's not noob-friendly compared to Node.js or Go yet. Code based on Futures uses owned closures a lot, so you need to "get" ownership in order not to fight the compiler. With the async/await syntax, the compiler will be able to relax some of the memory ownership restrictions, and you'll be able to write "normal" code instead of chains of callbacks.

jabl 8y ago

Concurrency, as in multiple OS threads communicating is nicely done, with the borrow checker being able prevent some fairly common multi-thread pitfalls. So for things like data parallelism etc. Rust is already looking pretty good. For server-side stuff, what's not yet done is some infrastructure and improved ergonomics for writing asynchronous or non-blocking code. See https://areweasyncyet.rs/ https://areweasyncyet.rs/ . And then when the infrastructure is there, it'll take a while before the higher-level frameworks take advantage of it.

Dowwie 8y ago

Microsoft is using actix libraries and creating many new rust libraries for their Azure IOT platform. Azure IOT is all about safety at very high speeds, making Rust a great fit for their work. I don't work there.

masklinn 8y ago

Multithreading and multiprocessing work fine, however they may be referring to m:n (aka "async"), which is a story still being written and which the borrow checker currently can make much more frustrating than expected by other languages with m:n threading support (e.g. you can't just close over a lexical variable then use it in multiple steps of an asychronous processing pipeline).

fzzzy 8y ago

This is because of the removal of the fat runtime and green threads about 5 years ago. Since there was no blessed way to do high concurrency in the language any more, some code started using normal threads, some code (tokio) started using normal callbacks. Callbacks in rust are tricky because of the type system. Around a year ago, async/await became possible due to the development of the Pin idea. async with the await! macro is usable now, but the rust community has been bikeshedding over built-in await syntax and last time I looked that discussion was still raging. So you can write scalable servers using normal threads, normal callbacks, and async with the await! macro, but not the final async/await syntax because the community hasn’t even finished deciding what it is. Porting code between these approaches is also not particularily easy. I have seen example code for rust networking libraries that uses all of the different approaches, but mixing the different approaches is also difficult. So that’s probably why people say it’s not ready even though you can write code right now that will work just fine. The “final” way of writing it isn’t ready yet, and if you write one of the current forms, porting to the final form will be a pain.

woah 8y ago
Porting from futures to async shouldn’t be too hard based on my experience doing it in JS.
- fzzzy 8y ago
  Sure, but js doesn’t have rust’s type system. It will probably be straightforward once everything is settled down, but right now Future 0.1 (tokio) and Future 0.3 (async/await) aren’t comptatible and you’ll find examples that use one or the other, or plain threads, or plain callbacks. It’s possible to get up and running quickly with the examples from various libraries, but when you try to mix them, if they use different styles, it becomes very challenging. Once async/await is finalized and everything moves to it this won’t be a problem, but that’s probably going to take at least a year or possibly years.
  - pimeys 8y ago
    I did a test and converted one of my libraries to async/await and it was not that hard. There are easy converters between the future versions for the transition period. https://github.com/pimeys/a2/pull/30/files https://github.com/pimeys/a2/pull/30/files

fxfan 8y ago

https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/ https://www.ageofascent.com/2019/02/04/asp-net-core-saturati... That actix you see appearing in most lists and mostly nearly top is written in Rust btw. Fun fact- frameworks managed by microsoft dominate the space ;)

woah 8y ago
IIRC actix was gettin some flack for using very unsafe code to hit those benchmarks. Still cool.
- fxfan 8y ago
  There is absolutely no shame in using unsafe!
  - JesseWright 8y ago
    The issue was that the author uses unsafe code unsafely and often for questionable performance or ergonomics gains that didn't actually need unsafe anyway. Fortunately, he cleaned up pretty much all of it, as I understand it, with the help of some involved community members when people freaked out about it all.

TheCoelacanth 8y ago

It's pretty nice for server code, but still has one major shortcoming which is that's it's kind of tricky to write high-performance IO-heavy code (it's easy if you want to have a thread blocked on every IO request, but that's bad for performance if you have many concurrent requests). This will improve a lot once async/await stabilizes. It already works great in nightly if all of the libraries you want to use support it.