> To convert the Stream.Reader to an std.Io.Reader, we need to call its interface() method. To get a std.io.Writer from an Stream.Writer, we need the address of its &interface field. This doesn't seem particularly consistent.
That made me think of how that change would be received in Go (probably would be discarded). They way they approach changes in extremely deep analysis and taking as much time as it needs to avoid mistakes and reach a consistent solution (or as close as possible).
4 years to decide on something relatively minor, that right now can be done with a bit of a one-liner extra work. But things need to be well thought out. Inconsistencies are pointed out. Design concerns are raised. Actual code usage in the real world are taken into account... too slow for some people, but I think it's just as slow as it needs to be. The final decision is shaping out to be very nice.
Rust is the same. It grinds my goat a little how many useful features are implemented - but only available in nightly rust. Things like generators.
But when rust ships features to stable, they’re usually pretty well thought through. I’m impatient. But the rust language & compiler teams probably have the right idea.
I beg to differ. Rust async implementation is contentious and criticized often. Sometimes you just miss the mark despite pondering about it for a while. Same with Go.
Yeah async rust is definitely the exception. That and Pin, which in my opinion totally missed the mark. The feature rust needs is the ability to have self reference in a struct. Pin is a hacky, inadequate half solution.
Can we all please stop complaining about async Rust and just acknowledge that the problem they were solving was both really hard and urgent for the success of the language (particularly given priorities among the most well-resourced tech companies in the late 2010s)? All things considered, I think they did a good job. I certainly wouldn't have done any better. And the feature was well thought through, with years of work before it shipped.
The problem is really hard. But I think bringing it up is useful, because it motivates people to think about how they would solve it better. It’s certainly a question I’ve asked myself a bunch of times.
If we all stopped complaining about memory safety in C and C++, we would never have gotten rust in the first place. Rob pike would never have let generics make it into Go if people didn’t spend years pestering him about it.
I think I fail by taking for granted all the work that’s gone into languages like rust. Lots of smart people have poured themselves into these discussions and designs. Thankyou. I don’t say that enough.
But yeah, async rust seems like one of those places where people arguing it out on github didn’t converge at a great design. It’s a really hard problem - really, combining a borrow checker with stack suspension is a CS research problem. I think it’s interesting and important to acknowledge that committees don’t always do great research. Sometimes you need a bunch of iterations of an idea. And a bright cookie or two who can work without justifying their designs.
So no, I don’t think I’ll stop talking about it. Making async rust v1 was an incredible amount of work and I’m very grateful. But I also really want to seed the idea space so some bright sparks can think about what async rust v2 might look like.
This wasn't exactly the case before Go 1.0 -- it changed quite rapidly, although in a less fundamental way (for example, removing semicolons, changing error types, etc.), and they usually provided an option to transform code automatically.
It works now that way because they promised it to be stable after 1.0.
That made me think of how that change would be received in Go (probably would be discarded). They way they approach changes in extremely deep analysis and taking as much time as it needs to avoid mistakes and reach a consistent solution (or as close as possible).
This has been my favorite for a while: https://github.com/golang/go/issues/45624
4 years to decide on something relatively minor, that right now can be done with a bit of a one-liner extra work. But things need to be well thought out. Inconsistencies are pointed out. Design concerns are raised. Actual code usage in the real world are taken into account... too slow for some people, but I think it's just as slow as it needs to be. The final decision is shaping out to be very nice.