Traits for interop are a prime consideration for std, even if we try to keep it small. But we can only add things when they’re ready; that’s part of the stability you desire.

Look at the Future trait, as an example. And rust has had the equivalent of io.{Reader, Writer} since 1.0.

I know. But for me personally, the `io::Reader` and `io::Writer` is still not comfortable enough. Mainly because it's return values, `io::Error` to be specific. Because I found that in many of my cases, predefined `io::ErrorKind` is not enough for me, this results my abuse of `io::ErrorKind::Other`.

In Go, `error` is an interface that can later be asserted, so I can return any `error` then deal with them as late as I need.

This gives me ability to write some complex `io.Reader` and `io.Writer`. For example, an `io.Reader` that can Decode data stream, and returns both CodecError and IoError when it encountered any.

In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down).

BUT ... Maybe it's Go's fault, it treats me too well, make me want something that I cannot have for free (performance cost) else where.

> In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down).

Well there's stuff like error-chain to take care of the boilerplate...

Also, I believe you could define the equivalent of Go error in Rust as a trait and box it (ie. a trait object). It could be used much the same way as in Go with the additional benefit of Result being a sum type. I'm personally not a big fan of this approach but I guess it might work...

> you could define the equivalent of Go error in Rust as a trait and box it (ie. a trait object).

I know this basically how Go's error handling works (Put error data on heap and pass the reference), but I'm not fan of it (the put data on heap part of it) too :(

I will try out the error-chain, thank you for reminding me that.

The “failure” crate is an alternative to error-chain as well.

> I think Rust need strong leaders to layout a clear and stable plan, so more things can be standardized across it's ecosystem (Somewhat like what Go did, for example, io.Reader && io.Writer is life changing for me). In that way I can keep my hate meter at a safe level.

Just to add my opinion, not to disagree: I followed the development of Rust for several years now (starting before 1.0). Rust's approach to language evolution is very much community-driven (like you said). But this also led to many really good ideas coming from people with different backgrounds. Today, Rust feels like a highly optimized breed of good ideas taken from many programming languages and I know of no other language that feels like that. Sure, every new language gets inspiration from older languages, but Rust appears to be more "extreme" than other languages (and I do not mean "extreme" in a negative sense). This was most visible in the pre-1.0 era. People had different ideas how the language should work and the Rust team tried different things and iterated on the things they learned. And I think this was totally worthwhile.

Let's talk about Python for a moment. I really like Python. It is a language with clear conventions and idioms. And most likely it achieved this state thanks to Guido van Rossum who had very clear ideas about what the language should be. And one of the core ideas is simplicity. Python (being inspired by ABC) was meant to be easy to learn (because of it's simplicity).

Now, let's go back to Rust. Rust also has clear ideas: "Rust is a systems language pursuing the trifecta: safety, concurrency, and speed" (Quoted from: This Week in Rust). And yes, "consistency" or "ease of learning" are not listed as the core ideas. However, when you look at the Rust roadmap for 2017 you will also see that the team has prioritized the following items:

* Rust should have a lower learning curve

* productivity (which includes easier usage of the language)

These issues are definitely on the radar of the Rust team. But I also think that these issues can only be tackled by an entire community which shares and discusses ideas. Rust tries to be much more than other languages and I think it is highly unlikely that a single leader will know how to direct the language in a specific direction. There are still a lot of things to be figured out. For example, let's see if the failure crate becomes the standard for error handling in Rust.

<quote>C++ for example, is a hard language, but the learning curve is ... progressive (rise bit by bit).

Rust on the other hand, is like climbing a cliff </quote>

c++11+ is a hill that is so freaking high that you do not see the top.. like Olympus Mons.

honestly i do not see much difference in learning c++ or rust - in order to write good programs you should know most of the c++ standard and that's a lot to absorb.

Good point about the learning curve. I don't think Rust is especially difficult overall, but you need to understand a lot before you get anywhere. Haskell kind of have the same problem, where you need to understand advanced features like monads before you can even write hello world.

> C++ for example, is a hard language, but the learning curve is ... progressive (rise bit by bit).

Except that you've always got a footgun in each hand, with no safeties and no trigger guards.

Rust keeps its footguns locked in the gun safe. You get them out with the `unsafe` keyword.