Obviously Java's Reader interface does more work, and has a `close()` method, which golang lacks. Golang is forced to go with this way to write interfaces due to how they are implemented (sacrificing usability to get nominal typing, which is a very questionable design decision). Languages like Kotlin, Rust, Scala among others have superior solutions.
Can Quasar fibers be efficiently used with other (popular) Java libraries that build on top of the standard libraries? If not, I don't consider that to be good developer experience. That is more of a mistake that cannot be rectified.
Async IO is also fine. The question is, what is your current ecosystem built on top of. AFAIK the answer with Java is definitely not async IO or fibers.
Yes, structural interfaces in Go are implemented poorly. But the standard library uses them very tastefully, putting most standard libraries to shame :) Go also has Closer, and its a separate interface - interfaces are minimal which makes them much easier to implement and more generally applicable.
Green threads are not the be-all-end-all solution for concurrency. They have their place, but so do event based async io.
That being said, Java is getting green threads in the form of Fibers.
> Compare https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm....
Obviously Java's Reader interface does more work, and has a `close()` method, which golang lacks. Golang is forced to go with this way to write interfaces due to how they are implemented (sacrificing usability to get nominal typing, which is a very questionable design decision). Languages like Kotlin, Rust, Scala among others have superior solutions.