[kzvezdarov]

It's rather that Rust's standard library and third party library support is incomplete. E.g.:

- last time I checked there was no option to have non-blocking IO which is a pain.

- custom JSON serialization/deserialization from/into custom data structures is extremely painful (for reference, rustc_serialize's Decodable trait).

- thread::scoped leaking destructors under certain conditions. This is more of an example of how a complex language gives rise to complex issues that very are difficult to debug and fix.

This will get better in time obviously but this is the current state of the language. Nonblocking IO in particular is really unfortunate to see in a 1.0 version tag.

[pcwalton]

There are mio and serde respectively for your first two points, and mio in particular is really popular.

Regarding thread::scoped, I think that kind of issue isn't unique to Rust (Java, a language with a simpler memory model, has had all kinds of weird corner case bugs, especially around memory and concurrency). It's also, again, more an issue of "safe manual memory management is hard": the simple ways to avoid that issue would have been "GC everything", "sacrifice memory safety", or "remove reference counted smart pointers", which contradict Rust's goals.

[xxs]

>>(Java, a language with a simpler memory model, has had all kinds of weird corner case bugs, especially around memory and concurrency<<

Can you point something in particular?

[pcwalton]

CVE-2012-0507 for example.

[arielby]

The leakapocalypse is rather blown-up - I don't think you could observe it unintentionally. Besides, `thread::scoped` is something no other mainstream-imperative language tries to offer - parallelism with essentially no risk of race conditions.

[Manishearth]

> thread::scoped leaking destructors under certain conditions.

Note that this problem is one that has no analogue in other languages.

In most languages, including Rust, you can already "leak" things by putting them into a static hashmap and forgetting about it or sending them to a blocked thread or whatever.

Rust is unique in that it can demarcate types which are bound to a scope. Which gives the auxiliary guarantee that the object would be destroyed in that scope regardless of what happens next (because such objects cannot be returned from the scope or placed into a global hashmap or whatever). There is no analogue for this in other languages. Rust is not "incomplete" for not having this.

The current scoped API depended on this guarantee, but it turns out that there are convoluted ways to bypass the guarantee (so it's not a real guarantee). There's a new design that's been proposed which doesn't need this guarantee.

non-blocking io can be done via mio, and I think using serde for json is easier.