7 ms·

Like I said there's nothing wrong with the stack. I was ONLY speaking of my personal preferences why I choose not to Java when I can Go: Just personal preferenc

by DLA 6y ago

Like I said there's nothing wrong with the stack. I was ONLY speaking of my personal preferences why I choose not to Java when I can Go: Just personal preferences. -- Compile times! -- Operational complexity vs. Go. -- Built-in tooling vs. Go. -- Verbose XML configuration files. -- Lots of libs favor XML vice JSON. -- Deeply-nested code directories. -- Class-centric model (only). -- Verbosity and boilerplate. -- Factories of factories of factories. :) -- JVM install and config (many dials = control but also complexity). -- Impractical / painful to write without an IDE. -- Concurrency model, as compared to Go. -- Std lib not matched to work I use Go for. -- Memory consumption. -- Performance (for the work I do). -- Multiple inheritance (allows unnecessary complexity). -- https://astaxie.gitbooks.io/build-web-application-with-golang/en/03.2.html https://astaxie.gitbooks.io/build-web-application-with-golan... vs. https://medium.com/@ssaurel/create-a-simple-http-web-server-in-java-3fc12b29d5fd https://medium.com/@ssaurel/create-a-simple-http-web-server-... -- Oracle. (edits: reformat pretty; compile times)

apta 6y ago
> -- Compile times! golang compile times are similar for any non-trivial project. Ironically, they're even much worse than Java's for quick changes (e.g. change a single file then recompile to run tests) since golang has to spit out a binary that is in the 10s of MBs compared to Java which just needs to change a single class file. > -- Operational complexity vs. Go. The JVM is superior for operations, observability, and monitoring to anything that golang has to offer. > -- Verbose XML configuration files. > -- Lots of libs favor XML vice JSON. > -- Factories of factories of factories. :) Nothing to do with the language. > -- Deeply-nested code directories. I've seen the same in golang code due to its packaging. > -- Verbosity and boilerplate. golang is more verbose and error prone for any non-trivial code base > -- JVM install and config (many dials = control but also complexity). The JVM is configurable and gives the user the ability to tune his program (say latency vs throughput), unlike golang which doesn't. Secondly, you can compile to native code using GraalVM. > -- Concurrency model, as compared to Go. Java is getting green threads (see project Loom), and they'll be superior to what golang offers. > -- Impractical / painful to write without an IDE. Irrelevant for any non-trivial code base, since golang needs and IDE as well. > -- Std lib not matched to work I use Go for. let's see what golang has to offer anything remotely similar to java.util.concurrent.* > -- Memory consumption. Depends on how you set up your JVM (Xmx, GC settings, etc.). Java is getting value types soon to address this even more. > -- Performance (for the work I do). They're on par, and for any non-trivial code base, Java tends to be faster. > -- Multiple inheritance (allows unnecessary complexity). Java doesn't support multiple inheritance.
- DLA 6y ago
  > -- Operational complexity vs. Go. The JVM is superior for operations, observability, and monitoring to anything that golang has to offer. >> Disagree on operations part. Take a bare machine and with various configurations (some you don't control) and be ready to drop and run. Nothing beats Go. You cannot be simpler than copy a binary. Yes, the JVM has all sorts of observability. And also a load of tuning that often needs to occur. Go just runs and generally has outstanding performance. > -- Deeply-nested code directories. I've seen the same in golang code due to its packaging. >> Go code is generally not as deeply nested. Often you have <project>/<package>/<file.go>. Not stuff like: tomcat/java/org/apache/tomcat/websocket/server/xxxx.java > -- Std lib not matched to work I use Go for. let's see what golang has to offer anything remotely similar to java.util.concurrent.* >> Friend, I'm talking about all the packages here: https://golang.org/pkg/ https://golang.org/pkg/ > -- Memory consumption. Depends on how you set up your JVM (Xmx, GC settings, etc.). Java is getting value types soon to address this even more. >> Yes, mu point (Xmx, GC settings, future things). Many dials == complexity. > -- Concurrency model, as compared to Go. Java is getting green threads (see project Loom), and they'll be superior to what golang offers. >> More Java getting/future vs. Go has today. "they'll be superior to what golang offers." Since we are predicting the future, can I also get next week's S&P500 level for my trades? >> Let me know when you can remotely close to writing <200 LOC that can handle 1m websocket connections from a laptop. There are 2 source files here. https://github.com/eranyanay/1m-go-websockets/tree/master/4_optimize_gobwas https://github.com/eranyanay/1m-go-websockets/tree/master/4_... Again as I opened with, these are my experiences. If Java and the future versions of Java and the tolling, IDEs, CI/CD tools, inspectors, etc, work for you. Great. Have at it. I will keep deploying rock solid Go applications with minimal complexity and maximal performance/reliability, out of the box. I shall enjoy flatter code trees, working without a IDE when necessary (totally possible), enjoying simple make files for builds, and solving a ton real world problems with minimal external libraries (again, dependencies ~= complexity ~= risk). Checkout some great stats from the 2019 Go Survey here: https://blog.golang.org/survey2019-results https://blog.golang.org/survey2019-results I will depart with a final thought about Go: Why are increasingly more and more web-scale infrastructure projects being written in Go? (CockroachDB, Openshift, NATS, Docker, Istio, Etcd, Docker, K8S, large parts of AWS, Azure, and CGP).

by DLA 6y ago

apta 6y ago

> -- Compile times! golang compile times are similar for any non-trivial project. Ironically, they're even much worse than Java's for quick changes (e.g. change a single file then recompile to run tests) since golang has to spit out a binary that is in the 10s of MBs compared to Java which just needs to change a single class file. > -- Operational complexity vs. Go. The JVM is superior for operations, observability, and monitoring to anything that golang has to offer. > -- Verbose XML configuration files. > -- Lots of libs favor XML vice JSON. > -- Factories of factories of factories. :) Nothing to do with the language. > -- Deeply-nested code directories. I've seen the same in golang code due to its packaging. > -- Verbosity and boilerplate. golang is more verbose and error prone for any non-trivial code base > -- JVM install and config (many dials = control but also complexity). The JVM is configurable and gives the user the ability to tune his program (say latency vs throughput), unlike golang which doesn't. Secondly, you can compile to native code using GraalVM. > -- Concurrency model, as compared to Go. Java is getting green threads (see project Loom), and they'll be superior to what golang offers. > -- Impractical / painful to write without an IDE. Irrelevant for any non-trivial code base, since golang needs and IDE as well. > -- Std lib not matched to work I use Go for. let's see what golang has to offer anything remotely similar to java.util.concurrent.* > -- Memory consumption. Depends on how you set up your JVM (Xmx, GC settings, etc.). Java is getting value types soon to address this even more. > -- Performance (for the work I do). They're on par, and for any non-trivial code base, Java tends to be faster. > -- Multiple inheritance (allows unnecessary complexity). Java doesn't support multiple inheritance.

DLA 6y ago
> -- Operational complexity vs. Go. The JVM is superior for operations, observability, and monitoring to anything that golang has to offer. >> Disagree on operations part. Take a bare machine and with various configurations (some you don't control) and be ready to drop and run. Nothing beats Go. You cannot be simpler than copy a binary. Yes, the JVM has all sorts of observability. And also a load of tuning that often needs to occur. Go just runs and generally has outstanding performance. > -- Deeply-nested code directories. I've seen the same in golang code due to its packaging. >> Go code is generally not as deeply nested. Often you have <project>/<package>/<file.go>. Not stuff like: tomcat/java/org/apache/tomcat/websocket/server/xxxx.java > -- Std lib not matched to work I use Go for. let's see what golang has to offer anything remotely similar to java.util.concurrent.* >> Friend, I'm talking about all the packages here: https://golang.org/pkg/ https://golang.org/pkg/ > -- Memory consumption. Depends on how you set up your JVM (Xmx, GC settings, etc.). Java is getting value types soon to address this even more. >> Yes, mu point (Xmx, GC settings, future things). Many dials == complexity. > -- Concurrency model, as compared to Go. Java is getting green threads (see project Loom), and they'll be superior to what golang offers. >> More Java getting/future vs. Go has today. "they'll be superior to what golang offers." Since we are predicting the future, can I also get next week's S&P500 level for my trades? >> Let me know when you can remotely close to writing <200 LOC that can handle 1m websocket connections from a laptop. There are 2 source files here. https://github.com/eranyanay/1m-go-websockets/tree/master/4_optimize_gobwas https://github.com/eranyanay/1m-go-websockets/tree/master/4_... Again as I opened with, these are my experiences. If Java and the future versions of Java and the tolling, IDEs, CI/CD tools, inspectors, etc, work for you. Great. Have at it. I will keep deploying rock solid Go applications with minimal complexity and maximal performance/reliability, out of the box. I shall enjoy flatter code trees, working without a IDE when necessary (totally possible), enjoying simple make files for builds, and solving a ton real world problems with minimal external libraries (again, dependencies ~= complexity ~= risk). Checkout some great stats from the 2019 Go Survey here: https://blog.golang.org/survey2019-results https://blog.golang.org/survey2019-results I will depart with a final thought about Go: Why are increasingly more and more web-scale infrastructure projects being written in Go? (CockroachDB, Openshift, NATS, Docker, Istio, Etcd, Docker, K8S, large parts of AWS, Azure, and CGP).