Don't get me wrong, it's a great library! You can do pretty darn fast systems with it, all type-checked and correct. Just don't try to fit in too many things into one thread yet, wait for async/await and non-statical lifetimes in the core.

I hope async programming doesn't become the standard in Rust. So much work has gone into allowing clean and safe threading, but people seem to be led towards the async libraries, which IMO solves a scaling problem only 1% of users will have. It's great that they exist, but if you're not expecting to have a c10k class problem, you can use threads and you'll probably have a better time.

If you're a library, creating threads causes side effects for the host program, and doing async when called doesn't. For instance, in a single-threaded program, it's always safe to call malloc() after fork(). In a multi-threaded program, another thread might have called malloc() and picked up a global lock; since only the thread that called fork gets copied (since you don't want to do the other threads' work twice!), there's now a copy of that global lock being held by a thread that doesn't exist, so calling malloc() will deadlock.

My personal interest in Rust is as a C replacement, including as a replacement for existing libraries that are written in C. While I agree threads can be very efficient (after all, the kernel implements threading by being async itself, more or less), they're annoying for this use case.

I just want to be able to say "do this thing or time out in 5 seconds", and that's like all the 'async' I need in rust. Everything else, nah.

But that's just me - many people need these 0 cost abstractions, this is Rust's focus, and I'll have to wait for the higher level stuff for my projects.

> less to do with Rust itself, and more to do with this seemingly horrible futures library

Doesn't almost every major programming language have Futures though? (C++, Java, Python, Ruby, JavaScript, Go).

It seems a fair criticism for so common a building block.

For a long time C++ and Javascript did not have futures. Rust is relatively new, and futures aren't part of the language proper yet. The problem is that the author's criticism of Rust seems to all hinge around a bleeding edge feature.

I would agree with the author's criticism if it was "futures are in the lang nursery and still not ready to use," rather than: Rust is bad, because I got nasty errors when using this work-in-progress library.

Rust's futures leverage the type system to have extremely minimal overhead; many of those languages don't try to do that. That's where the difficulty comes in.

If we'd all start programming in stable, mature languages instead of letting peer pressure goad us into using betaware and worse, work would be a lot simpler.

It would also encourage organizations large and small to start releasing complete, polished products instead of the "move fast and break things" crap that has infected the industry.

Imagine if car makers worked the same way.

Your "stable and mature" languages were the crazy research projects of old. No one is forcing you to do anything, but let us not forget the nature of our "mature" technologies and the process by which they form.

By that logic, programs written in C are the most polished. Yeah, that checks out. /s

Ask a COBOL programmer about this...

Ask an assembly programmer about this...

Ask a machine code programmer about this...

Ask a Minecraft machine programmer about this.... (errr, couldn’t resist)

Isn't that what Uber is doing? :/