9 ms·

I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house

by DLA 6y ago

I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house hosted and cloud. I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles of coding. Too much choice results in complexity. IMO the generics debate is overblown. The systems I've build with go tend toward heavy data processing (ETL, correlation, extraction and the like) and service (JSON APIs supporting front-ends; event some front ends with Go Templates). Never once was I like "my life sucks because I don't have generics." Fair and balanced: Processing JSON in Go takes some getting used to, especially when the JSON structure changes. However, there are some good libs to help. It's just a friction point given the typed nature of Go. The operational simplicity of Go cannot be overstated. Go's production of a deployable binary with zero dependencies is a blessing. There's an amazing deploy tool you can use called: cp. Compare that to the library version hell that is C++ (and I'm also a C fan and very experienced dev). No. Thank. You. The cross compilation of Go code works beautifully. Just 2 weeks ago I had to demonstrate a tool to a customer and due to COVID it was virtual. We had problems with MS Teams connecting to our dev platform so literally 15 minutes before the demo I cross-compiled to a Win binary and moved it to the machine hosting the Teams call. Victory. Because of go fmt, all Go code looks the same. That's a massive advantage to read/understand/use OPC (other people's code). Ditto for the automatic documentation generation -- it looks the same and behaves the same across Go projects. I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. It's my opinion, so not up for debate. If Java works for you, by all means have at it. Robust solid technology for sure. Not hating here; just choosing. So, my Go journey has been and continues to be fantastic. It is my preferred platform for pragmatic reasons--the same sort of reasons it was developed by Google in the first place. My team and I can get stuff done quickly. We can scale it. We can leverage all the CPUs on a box running big data processing flows. We can have automatic code-linked documentation and formatted code and can leverage the same from others. We have build in testing. We can make high performance services and servers with ease. We don't have to deal with ridiculous configuration nonsense. We get instant compilations. We get great tool support (vscode + Go for the win). We get a batteries very much included stdlib. And most of all we get a platform that understands and managed complexity in a favorable way. $0.02. Ok, maybe $0.05 (inflation).

dunefox 6y ago
> I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. If you can gather some energy, I'd be interested in that.
- winrid 6y ago
  Same!! Although, an experienced C++ dev might just abhor the thought of pointer chasing everywhere, even if it's not a big deal in 90% of web backends.
- 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.

by DLA 6y ago

dunefox 6y ago

> I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. If you can gather some energy, I'd be interested in that.

winrid 6y ago
Same!! Although, an experienced C++ dev might just abhor the thought of pointer chasing everywhere, even if it's not a big deal in 90% of web backends.
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.