2 ms·

Well, the thing about Go concurrency is that it has been with the language since the beginning. How much library code is compatible with concurrent or streams

by NateDad 11y ago

Well, the thing about Go concurrency is that it has been with the language since the beginning. How much library code is compatible with concurrent or streams or futures or Quasar? If you choose one over the others, are you limiting yourself to only libraries compatible with others that made the same choice as you? How much of the standard library is compatible with each of those? The same thing goes for value types. In Go, everything uses value types. The standard library is littered with them. Will it be the same for Java? It seems unlikely, given that they have to keep backwards compatibility. Granted, this is all from the point of view of an outsider who only dabbled in Java, so I may be way off base.

pjmlp 11y ago
The java.util.concurrent was introduced with Java 1.5, so 2004. And there were alternatives available before for Java 1.4. Which means most Java libraries had lots of time to adapt to it. Also threads and concurrent queues are there since the early days. Java already has a kind of pseudo-value types, but it is JVM specific. Some JIT and AOT compilers do convert final classes with only accessors (think Point) to value types. But yeah, it is a JDK vendor specific optimization that one cannot control. Likewise you cannot control if a value type in Go gets stack or heap allocated, if I remember correctly. Hence why the compiler options to debug how the compiler decided to do it. Java value types will take time to get adopted surely, but in many type of applications it doesn't really matter that much. The use cases driving value type's adoption are related to HPC and HPT, many of which are trying to move away from C++ into Java, but still find themselves have to make use of com.sun.unsafe for that last mile. At least as presented by IBM and Azul on their talks about their approaches to value types in Java.

by NateDad 11y ago

pjmlp 11y ago

The java.util.concurrent was introduced with Java 1.5, so 2004. And there were alternatives available before for Java 1.4. Which means most Java libraries had lots of time to adapt to it. Also threads and concurrent queues are there since the early days. Java already has a kind of pseudo-value types, but it is JVM specific. Some JIT and AOT compilers do convert final classes with only accessors (think Point) to value types. But yeah, it is a JDK vendor specific optimization that one cannot control. Likewise you cannot control if a value type in Go gets stack or heap allocated, if I remember correctly. Hence why the compiler options to debug how the compiler decided to do it. Java value types will take time to get adopted surely, but in many type of applications it doesn't really matter that much. The use cases driving value type's adoption are related to HPC and HPT, many of which are trying to move away from C++ into Java, but still find themselves have to make use of com.sun.unsafe for that last mile. At least as presented by IBM and Azul on their talks about their approaches to value types in Java.