Comment by j1elo

Comment by j1elo a day ago

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

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.

josephg a day ago

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.

Reply View 3 replies

hu3 a day ago

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.

Reply View | 2 replies
- josephg 16 hours ago
  
  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.
  
  Reply View | 1 reply
  
  mwcampbell 9 hours ago
  
  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.
  
  Reply View | 0 replies

dchest 20 hours ago

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.

Reply View 0 replies