5 ms·

And when Java gets Project Loom then Go will not have any real world advantages.

by qqssccfftt 6y ago

vips7L 6y ago
If only the JVM could get it's memory usage down.
- pron 6y ago
  I think that >75% of people who complain about Java's memory usage don't provide a heap size and use the default, which is asking Java to go ahead and take up up to 25% of RAM whether it really needs to or not. You want to use less RAM? Tell Java to use less RAM.
  - pjmlp 6y ago
    And even then, many are just doing bad stuff like using new in loops, iterators in hot loops, and most relevant not actually thinking about their data structures.
    - pron 6y ago
      Iterators and other allocations in hot loops are not universally harmful to performance and footprint. Very often they are scalar-replaced (allocated on the stack and reused)-- in fact, if they don't escape, they're almost certain to be. Escape analysis is also now significantly stronger and able to see through abstraction in JDK 14 thanks to increasing the default inlining depth from 9 to 15 (https://bugs.openjdk.java.net/browse/JDK-8234863 https://bugs.openjdk.java.net/browse/JDK-8234863).
      - pjmlp 6y ago
        Agreed, but it depends very much on which JVM one is using, and not all of them offer the same capabilities as Hotspot. And then there is that other special flavour of coffee beans out there.
  - vips7L 6y ago
    Pron while I usually agree with you when it comes to criticisms about Java I just can't here. Using 25% of available ram is just not a sane default.
    - pron 6y ago
      Because it is too high or too low? What would be a sane default? Note that native applications don't have an upper limit at all, but to Java's GCs will be happy to trade available memory for performance.
throwaway894345 6y ago
Goroutines are very, very low on my list of reasons that I prefer Go over Java. I think many people misunderstand the value proposition of Go.
- spyspy 6y ago
  Same. I can't even remember the last time I deployed code with a channel into production.
  - ProZsolt 6y ago
    You most likely did, but not explicitly. You just used a lib that used a channel.
- pron 6y ago
  What are the top reasons?
  - throwaway894345 6y ago
    Tooling and deployment are two big ones. Go doesn’t have a Turing complete DSL for it’s project files (that you have to run in daemon mode if you want a fast feedback loop); just a simple list of dependencies and a lock file. Testing is dead simple and built into the standard library and toolchain. Documentation generation is just comments; no javadoc syntax to learn, nor documentation packages to build and publish—godoc.org and friends can read any package available to them (including private repos if you host your own instance) and they automatically link to other packages’ docs without additional work. Also, static linkage by default that just works—yeah, fat jars and AOT are things in the Java world, but they take extra setup and often they aren’t feasible in practice. Meanwhile, I can send a Go binary to any Linux server and it will run. A lot of Java people love Java tooling because everything is super configurable and you can do just about everything you could ever theoretically want to do, but I rarely find this helpful—Go’s tooling generally does what I want it to do; I rarely have problems but I benefit immensely from being able to quickly figure out how to solve my problem. Different values, I guess. Another big one is the data model. Go doesn’t have object types nor inheritance; it has value types, interfaces, pointers, and closures. While in Java I don’t have to use inheritance and one day there may be value types, inheritance and objects are and will continue to be pervasively used in the Java ecosystem, which means I’ll have to interact with lots of such code. Not the end of the world, but I really don’t enjoy it—I wouldn’t spend time fighting it if I have the option of using something else. More importantly, the data model and Go’s AOT allow me to reason about code performance more predictably, although JVM’s JIT compiler would be really nice for the very few highly dynamic programs that I write. Notably, I don’t think Go does everything well or that it’s AOT model is good for everything and Java’s VM model is bad for everything. I actually would like to see a simpler, high performance JITing VM with better semantics for languages with value types (and a lower latency default GC although I hear that is improving in recent JVMs). I specifically don’t want all the bells and whistles for tuning my GC or my VM. I also want a dramatically simpler language running on it. Maybe a super simple lisp or something like Julia but geared toward general app dev.

And when Java gets Project Loom then Go will not have any real world advantages.

vips7L 6y ago

If only the JVM could get it's memory usage down.

pron 6y ago
I think that >75% of people who complain about Java's memory usage don't provide a heap size and use the default, which is asking Java to go ahead and take up up to 25% of RAM whether it really needs to or not. You want to use less RAM? Tell Java to use less RAM.
- pjmlp 6y ago
  And even then, many are just doing bad stuff like using new in loops, iterators in hot loops, and most relevant not actually thinking about their data structures.
  - pron 6y ago
    Iterators and other allocations in hot loops are not universally harmful to performance and footprint. Very often they are scalar-replaced (allocated on the stack and reused)-- in fact, if they don't escape, they're almost certain to be. Escape analysis is also now significantly stronger and able to see through abstraction in JDK 14 thanks to increasing the default inlining depth from 9 to 15 (https://bugs.openjdk.java.net/browse/JDK-8234863 https://bugs.openjdk.java.net/browse/JDK-8234863).
    - pjmlp 6y ago
      Agreed, but it depends very much on which JVM one is using, and not all of them offer the same capabilities as Hotspot. And then there is that other special flavour of coffee beans out there.
- vips7L 6y ago
  Pron while I usually agree with you when it comes to criticisms about Java I just can't here. Using 25% of available ram is just not a sane default.
  - pron 6y ago
    Because it is too high or too low? What would be a sane default? Note that native applications don't have an upper limit at all, but to Java's GCs will be happy to trade available memory for performance.

throwaway894345 6y ago

Goroutines are very, very low on my list of reasons that I prefer Go over Java. I think many people misunderstand the value proposition of Go.

spyspy 6y ago
Same. I can't even remember the last time I deployed code with a channel into production.
- ProZsolt 6y ago
  You most likely did, but not explicitly. You just used a lib that used a channel.
pron 6y ago
What are the top reasons?
- throwaway894345 6y ago
  Tooling and deployment are two big ones. Go doesn’t have a Turing complete DSL for it’s project files (that you have to run in daemon mode if you want a fast feedback loop); just a simple list of dependencies and a lock file. Testing is dead simple and built into the standard library and toolchain. Documentation generation is just comments; no javadoc syntax to learn, nor documentation packages to build and publish—godoc.org and friends can read any package available to them (including private repos if you host your own instance) and they automatically link to other packages’ docs without additional work. Also, static linkage by default that just works—yeah, fat jars and AOT are things in the Java world, but they take extra setup and often they aren’t feasible in practice. Meanwhile, I can send a Go binary to any Linux server and it will run. A lot of Java people love Java tooling because everything is super configurable and you can do just about everything you could ever theoretically want to do, but I rarely find this helpful—Go’s tooling generally does what I want it to do; I rarely have problems but I benefit immensely from being able to quickly figure out how to solve my problem. Different values, I guess. Another big one is the data model. Go doesn’t have object types nor inheritance; it has value types, interfaces, pointers, and closures. While in Java I don’t have to use inheritance and one day there may be value types, inheritance and objects are and will continue to be pervasively used in the Java ecosystem, which means I’ll have to interact with lots of such code. Not the end of the world, but I really don’t enjoy it—I wouldn’t spend time fighting it if I have the option of using something else. More importantly, the data model and Go’s AOT allow me to reason about code performance more predictably, although JVM’s JIT compiler would be really nice for the very few highly dynamic programs that I write. Notably, I don’t think Go does everything well or that it’s AOT model is good for everything and Java’s VM model is bad for everything. I actually would like to see a simpler, high performance JITing VM with better semantics for languages with value types (and a lower latency default GC although I hear that is improving in recent JVMs). I specifically don’t want all the bells and whistles for tuning my GC or my VM. I also want a dramatically simpler language running on it. Maybe a super simple lisp or something like Julia but geared toward general app dev.