Hacker News Reader

Comment by bsaul | Hacker News Reader

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 ?

View on HN

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.

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!

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.

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.

Porting from futures to async shouldn’t be too hard based on my experience doing it in JS.

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.

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

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/ . And then when the infrastructure is there, it'll take a while before the higher-level frameworks take advantage of it.

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).

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.

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.

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.

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.

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 ;)

IIRC actix was gettin some flack for using very unsafe code to hit those benchmarks. Still cool.

There is absolutely no shame in using unsafe!

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.

Perhaps they meant webapps:

http://www.arewewebyet.org/