3 ms·

I disagree. Go is definitely not as fast as Java for throughput. It's gotten pretty good for latency sensitive workloads but it's simply left in the dust for s

by jpgvm 5y ago

I disagree. Go is definitely not as fast as Java for throughput. It's gotten pretty good for latency sensitive workloads but it's simply left in the dust for straight throughput, especially if you are hammering the GC. Sure it can make syscalls directly but if you are going to talk about a maintainability nightmare I can't think of anything worse than trying to manipulate threads directly in Go. I had to do this in a previous Go project where thread pinning was important and even that sucked. That is just taste. Objectively collections and many other aspects of the Java stdlib completely destroy Go, I pointed out the good bits already. Again, taste. Java has a slightly steeper and longer learning curve but that is a cost you pay once and is amortized over all the code that engineer will contribute over their tenure. Using an IDE (especially if everyone is using the same one) is actually a productivity improvement, not an impairment but again - taste. Some people just don't like IDEs or don't like that you need to use a specific one to get the most out of a specific tech stack. Build systems in Java by and large fall into only 3 camps, Maven, Gradle and a very small (but loud/dedicated) Bazel camp. Contrast that to Go which is almost always a huge pile of horrible Makefiles, CMake, Bazel or some other crazy homebrewed bash build system. You don't escape CI because you used Go, if you think you did then you are probably doing Go wrong. Java runtime trades simplicity for ability to be tuned, again taste. I personally prefer it. So no, I don't think I am mistaken. I think you just prefer Go over Java for subjective reasons. Which is completely OK but doesn't invalidate anything I said.

throwaway894345 5y ago
> Go is definitely not as fast as Java for throughput. It's gotten pretty good for latency sensitive workloads but it's simply left in the dust for straight throughput, especially if you are hammering the GC. Java is better for GC throughput, but your claim was about compute throughput in general. Moreover, Go doesn't lean nearly as hard on GC as Java does in the first place (idiomatic value types, less boxing, etc), so GC throughput doesn't imply overall throughput. > Sure it can make syscalls directly but if you are going to talk about a maintainability nightmare I can't think of anything worse than trying to manipulate threads directly in Go. I had to do this in a previous Go project where thread pinning was important and even that sucked. Thread pinning is a very rare requirement, typically you only need it when you're calling some poorly-written C library. If this is your requirement, then Go's solution will be less maintainable, but for everyone else the absence of the foot-gun is the more maintainable solution (i.e., as opposed to an ecosystem of intermingled OS threads and goroutines). > That is just taste. Objectively collections and many other aspects of the Java stdlib completely destroy Go, I pointed out the good bits already. Agreed that it's taste. Agreed that Java has more collections than Go, but I think it's a good thing that Go pushes people toward slices and hashmaps because those are the right tool for the job 90% of the time. I think there's some broader point here about how Java doesn't do a good job of encouraging people away from misfeatures (e.g., inheritance, raw threads, off-heap memory, etc). > Again, taste. Java has a slightly steeper and longer learning curve but that is a cost you pay once and is amortized over all the code that engineer will contribute over their tenure. Java has a significantly steeper/longer curve--it's not only the language that you must learn, but also the stdlib, runtime, tools, etc and these are typically considerably more complicated than Go. Moreover, it's a cost an engineer pays once, but it's a cost an organization pays over and over (either because they have to train people in Java or narrow their hiring pool). > Build systems in Java by and large fall into only 3 camps, Maven, Gradle and a very small (but loud/dedicated) Bazel camp. Contrast that to Go which is almost always a huge pile of horrible Makefiles, CMake, Bazel or some other crazy homebrewed bash build system. Go has one build system, `go build`. Some people will wrap those in Makefiles (typically very lightweight makefiles e.g., they just call `go build` with a few flags). A minuscule number of projects use Bazel--for all intents and purposes, Bazel is not part of the Go ecosystem. I haven't seen any "crazy homebrewed bash build system" either, I suspect this falls into the "for all intents and purposes not part of the Go ecosystem" category as well. I've been writing Go regularly since 2012. > You don't escape CI because you used Go, if you think you did then you are probably doing Go wrong. I claimed the CI burden is lighter for Go than Java, not that it goes away entirely. > Java runtime trades simplicity for ability to be tuned, again taste. I personally prefer it. I think it's difficult to accurately quantify, but I don't think it's a matter of taste. Specifically, I would wager that Go's defaults + knobs are less work than Java for something like 99% of applications. > So no, I don't think I am mistaken. I think you just prefer Go over Java for subjective reasons. Which is completely OK but doesn't invalidate anything I said. I agree that some questions are subjective, but I think on many objective questions you are mistaken (e.g., performance, build tool ecosystem, etc).
philosopher1234 5y ago
I think your use of “subjective” is avoiding discussing things that are harder to prove but matter a great deal.
Thaxll 5y ago
> Build systems in Java by and large fall into only 3 camps, Maven, Gradle and a very small (but loud/dedicated) Bazel camp. Contrast that to Go which is almost always a huge pile of horrible Makefiles, CMake, Bazel or some other crazy homebrewed bash build system. Well Go does not need a book of 400+ pages to understand Maven.
- pjmlp 5y ago
  It needs one to understand Go modules and how they change across language versions.
  - Thaxll 5y ago
    Go module are easy to use, compiling is even more simpler: go build .
    - pjmlp 5y ago
      If you say so, "HERO: On the Chaos When PATH Meets Modules" https://cs.nju.edu.cn/changxu/1_publications/21/ICSE21_02.pdf https://cs.nju.edu.cn/changxu/1_publications/21/ICSE21_02.pd...
      - tekknik 5y ago
        I’ve been writing go since it basically came out. Every single one of you’re comments is anecdotal so here we go. I’ve never, ever, encountered an issue compiling / building go code using modules. You also said in your first argument that you get no access to raw threads then a comment later said you do. It seems like you’re just advocating for people to use java because it’s what you’re comfortable with.
        throwaway894345 5y ago
        Pretty sure it was a different commenter who claimed no access to raw threads, but yes, the parent user can be a bit abrasive on the subject of programming languages.

by jpgvm 5y ago

throwaway894345 5y ago

> Go is definitely not as fast as Java for throughput. It's gotten pretty good for latency sensitive workloads but it's simply left in the dust for straight throughput, especially if you are hammering the GC. Java is better for GC throughput, but your claim was about compute throughput in general. Moreover, Go doesn't lean nearly as hard on GC as Java does in the first place (idiomatic value types, less boxing, etc), so GC throughput doesn't imply overall throughput. > Sure it can make syscalls directly but if you are going to talk about a maintainability nightmare I can't think of anything worse than trying to manipulate threads directly in Go. I had to do this in a previous Go project where thread pinning was important and even that sucked. Thread pinning is a very rare requirement, typically you only need it when you're calling some poorly-written C library. If this is your requirement, then Go's solution will be less maintainable, but for everyone else the absence of the foot-gun is the more maintainable solution (i.e., as opposed to an ecosystem of intermingled OS threads and goroutines). > That is just taste. Objectively collections and many other aspects of the Java stdlib completely destroy Go, I pointed out the good bits already. Agreed that it's taste. Agreed that Java has more collections than Go, but I think it's a good thing that Go pushes people toward slices and hashmaps because those are the right tool for the job 90% of the time. I think there's some broader point here about how Java doesn't do a good job of encouraging people away from misfeatures (e.g., inheritance, raw threads, off-heap memory, etc). > Again, taste. Java has a slightly steeper and longer learning curve but that is a cost you pay once and is amortized over all the code that engineer will contribute over their tenure. Java has a significantly steeper/longer curve--it's not only the language that you must learn, but also the stdlib, runtime, tools, etc and these are typically considerably more complicated than Go. Moreover, it's a cost an engineer pays once, but it's a cost an organization pays over and over (either because they have to train people in Java or narrow their hiring pool). > Build systems in Java by and large fall into only 3 camps, Maven, Gradle and a very small (but loud/dedicated) Bazel camp. Contrast that to Go which is almost always a huge pile of horrible Makefiles, CMake, Bazel or some other crazy homebrewed bash build system. Go has one build system, `go build`. Some people will wrap those in Makefiles (typically very lightweight makefiles e.g., they just call `go build` with a few flags). A minuscule number of projects use Bazel--for all intents and purposes, Bazel is not part of the Go ecosystem. I haven't seen any "crazy homebrewed bash build system" either, I suspect this falls into the "for all intents and purposes not part of the Go ecosystem" category as well. I've been writing Go regularly since 2012. > You don't escape CI because you used Go, if you think you did then you are probably doing Go wrong. I claimed the CI burden is lighter for Go than Java, not that it goes away entirely. > Java runtime trades simplicity for ability to be tuned, again taste. I personally prefer it. I think it's difficult to accurately quantify, but I don't think it's a matter of taste. Specifically, I would wager that Go's defaults + knobs are less work than Java for something like 99% of applications. > So no, I don't think I am mistaken. I think you just prefer Go over Java for subjective reasons. Which is completely OK but doesn't invalidate anything I said. I agree that some questions are subjective, but I think on many objective questions you are mistaken (e.g., performance, build tool ecosystem, etc).

philosopher1234 5y ago

I think your use of “subjective” is avoiding discussing things that are harder to prove but matter a great deal.

Thaxll 5y ago

> Build systems in Java by and large fall into only 3 camps, Maven, Gradle and a very small (but loud/dedicated) Bazel camp. Contrast that to Go which is almost always a huge pile of horrible Makefiles, CMake, Bazel or some other crazy homebrewed bash build system. Well Go does not need a book of 400+ pages to understand Maven.

pjmlp 5y ago
It needs one to understand Go modules and how they change across language versions.
- Thaxll 5y ago
  Go module are easy to use, compiling is even more simpler: go build .
  - pjmlp 5y ago
    If you say so, "HERO: On the Chaos When PATH Meets Modules" https://cs.nju.edu.cn/changxu/1_publications/21/ICSE21_02.pdf https://cs.nju.edu.cn/changxu/1_publications/21/ICSE21_02.pd...
    - tekknik 5y ago
      I’ve been writing go since it basically came out. Every single one of you’re comments is anecdotal so here we go. I’ve never, ever, encountered an issue compiling / building go code using modules. You also said in your first argument that you get no access to raw threads then a comment later said you do. It seems like you’re just advocating for people to use java because it’s what you’re comfortable with.
      - throwaway894345 5y ago
        Pretty sure it was a different commenter who claimed no access to raw threads, but yes, the parent user can be a bit abrasive on the subject of programming languages.