5 ms·

Java is not really superior in standard library design. There is too much architecture astronautics going on. Standard interfaces are too complicated. Nominal i

by spion 8y ago

Java is not really superior in standard library design. There is too much architecture astronautics going on. Standard interfaces are too complicated. Nominal interfaces kinda suck. Java also lacks green threads. There is baggage in the design of many libraries related to previous lack of lambdas that is now annoying. The Go documentation as well as standard interfaces are tastefully and minimally done (for an imperative language): https://golang.org/doc/ https://golang.org/doc/ - e.g. https://golang.org/pkg/io/ https://golang.org/pkg/io/ ... To my knowledge there is no equivalent of this for Java that comes close. Compare https://golang.org/pkg/io/#Reader https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.html https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm... Java has pretty nice generics. With Java 10 the language is now decent too.

Gibbon1 8y ago
I'm under the impression that Java implements generics via type erasure.
- spion 8y ago
  Thats not an entirely bad way to do it.
apta 8y ago
> Java also lacks green threads 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 https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm.. 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.
- spion 8y ago
  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.
  - pjmlp 8y ago
    From Loom talks it appears that fibers will also be able to consume Runnable and Completable.
    - spion 8y ago
      Loom is still WIP. Remains to be seen how easy / performant it is going to be adopt in practice with the existing ecosystem.
tedunangst 8y ago
> Java also lacks green threads. So weird. Java used to only have green threads. The very name, "green threads", comes from the fact that's what the JVM called them. Literally invented the name.
- spion 8y ago
  Too bad they were removed. I don't see why a non-system language should use anything other than green threads nowadays.
  - pjmlp 8y ago
    Because Java also runs bare metal and in those scenarios, it is indeed a systems language. The HN community is too focused on OpenJDK/Oracle when talking about Java, when there are as several JDKs toolchains across the industry, some with very specialized deployment scenarios.
    - spion 8y ago
      The lesson from that being, the extreme of "write once run anywhere" is not necessarily a good idea. Sometimes its best to implement specialized libraries and runtime (green threads) for specialized environments (servers) that are not available in others.

by spion 8y ago

Gibbon1 8y ago

I'm under the impression that Java implements generics via type erasure.

spion 8y ago
Thats not an entirely bad way to do it.

apta 8y ago

> Java also lacks green threads 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 https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm.. 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.

spion 8y ago
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.
- pjmlp 8y ago
  From Loom talks it appears that fibers will also be able to consume Runnable and Completable.
  - spion 8y ago
    Loom is still WIP. Remains to be seen how easy / performant it is going to be adopt in practice with the existing ecosystem.

tedunangst 8y ago

> Java also lacks green threads. So weird. Java used to only have green threads. The very name, "green threads", comes from the fact that's what the JVM called them. Literally invented the name.

spion 8y ago
Too bad they were removed. I don't see why a non-system language should use anything other than green threads nowadays.
- pjmlp 8y ago
  Because Java also runs bare metal and in those scenarios, it is indeed a systems language. The HN community is too focused on OpenJDK/Oracle when talking about Java, when there are as several JDKs toolchains across the industry, some with very specialized deployment scenarios.
  - spion 8y ago
    The lesson from that being, the extreme of "write once run anywhere" is not necessarily a good idea. Sometimes its best to implement specialized libraries and runtime (green threads) for specialized environments (servers) that are not available in others.