5 ms·

i've sometimes heard that the JVM had best in class tooling for server troubleshooting. How does go compare to it now ?

by bsaul 3y ago

Xeoncross 3y ago
For good reason, the JVM has a ton more knobs that need adjusting. You can't just run Java code. The JVM has a lot of tricks you have to customize for based on your workload. For years until 1.19 the Go GC has had only one tuning parameter (GOGC).
- tsimionescu 3y ago
  Note that Go needs those knobs just as much as the JVM does, at least some of them. They just didn't want to expose them.
  - philosopher1234 3y ago
    Which knobs does go need?
    - tsimionescu 3y ago
      Fine-grained control over various GC phases and decisions (such as the level of parallelism, max pause times). Until Go 1.19, it was even missing a max memory limit, and even now it only has a soft memory limit. Additionally, of course it would be nice to have more GC options, such as choosing between a throughput-oriented GC design and a latency-oriented one, having the option of a compacting GC of some kind to avoid fragmentation, or even having a real time GC option. Go has chosen a very old-fashioned GC design with very few tuning parameters possible, but even so it only exposes a very basic form of control.
      - cwbriscoe 3y ago
        I would rather just write code and trust the existing GC than mess around with knobs all day. I suppose there are < 1% of projects that may see some benefit in messing with the GC.
      - kbolino 3y ago
        I agree with most of your points but how is it "old-fashioned"? To me, that means things like reference counting or long stop-the-world pauses, neither of which are true of Go.
- rileymichael 3y ago
  I don't see the connection you're making between knobs that adjust runtime behavior and tooling. As an aside, "you can't just run java code" is a bit hyperbolic, plenty of people "just run" java apps and rely on the default ergonomics. The modern JVM also offers more automated options, such as ZGC which is explicitly self tuning.
  - iamcalledrob 3y ago
    With Go, you never spend hours/days debugging broken builds due to poorly documented gradle plugins. As an example :) You really, truly, just run.
    - pjmlp 3y ago
      That is the problem right there, using Gradle without having learned why no one uses Ant any longer. As for Go, good luck doing just run when a code repo breaks all those URL hardcoded in source code.
      - philosopher1234 3y ago
        That’s not a real issue: * the go module proxy ensures repos are never deleted, so everything continues to work * changing to a new dep is as easy as either a replace directive or just find and replace the old url
        pjmlp 3y ago
        It requires work to keep things working, exactly the same thing.
        philosopher1234 3y ago
        The module proxy is used by default and requires no work. I don’t think what you’re saying makes much sense.
- Ironlink 3y ago
  > You can't just run Java code. The JVM has a lot of tricks you have to customize for based on your workload. This sounds like something you would hear 10 years ago in relation to the CMS garbage collector. Since Java 9, G1 has been the default gc for multi core workloads and is self-tuning. The CMS gc was removed 4 years ago. If you do need to tune G1, the primary knob is target pause time. While other knobs exist, you should think carefully before using them. We run all of our workloads with vanilla settings.
Thaxll 3y ago
Go is one of the best language in term of tooling, it has just one binary that contains everything, I don't know any other language that includes out of the box all of that: - testing - benchmark - profiling - cross compilation ( that work from any platform, like compiling a windows .exe from your raspberry pi for example ) - some linting - documentation - package mgmt - bug report - code generation - etc... Java is probably more advanced in some fields ( like tracing / profiling ) but it lacks others.
- neonsunset 3y ago
  [flagged]
- preommr 3y ago
  Golang also has some of the worst tooling because everything is based off of what comes builtin, and because they're not specialized projects, they're very limited in capability and configuration. Coming from ts, tooling like tsconfig has a lot of options, but sensible defaults can be set with a single flag like strict mode. If some org has some specialized needs, they can dive into the configuration and get what they need. With golang, not only would it be a lot for any single team to offer all those features at a decent level of polish, the golang culture in particular is very, very resistant to small bits of comfort because of dogma like "worse is better". It's kind of similar to Haskell's "avoid success at all cost".
  - Cthulhu_ 3y ago
    TSConfig having a lot of options isn't a selling point though; you shouldn't need any of those. That said, the flags and strict mode are intended for when you have an existing "sloppy" JS codebase or mindset. You shouldn't need anything (except strict mode) in a new TS project. That said, TS is quickly becoming the antithesis of what Go tries; every release for the past few years I've seen now are all features where I'm like, "I will never need or use this". Some conveniences have been improved on - like better type inference - but that will mainly allow for cleaning up workarounds. "some orgs with specialised needs" are going to be legacy projects, either older TS versions that didn't have the features that it does now, or JS codebases. This isn't generally an issue with Go projects, most of which are greenfield. That said, there's some X to Go conversion projects that produce less than ideal code though, like usage of the `interface{}` type that at this point is a code smell.
tsimionescu 3y ago
I think Go is catching up, but it's still significantly behind. For example, Go memory profiles are much, much worse than Java's - they don't even have them integrated with the GC to show the ownership graph (they can only show where each object was allocated, instead of which other objects are holding a reference to it). The CPU profiling parts seemed more up to par. This tracing thing is nice, I'm not as familiar with this are of Java. Also, I don't think Java has a built-in race detector (except perhaps for the detection of concurrent write and iterations in collections?). Also, the OpenJDK JVM supports live debugging and code hotswap, going so far as to de-optimize code you're debugging on the fly to make it readable. Go doesn't support live code reload even in local builds.
tptacek 3y ago
I really like Go's tooling, and while I'm fluent in Java I've never been on a full-time Java team. I've remarked to Java friends in the past that I think Go has best-in-class tooling and had my ass handed to me, in detail and at length. By many accounts, Java is the gold standard for tooling in language ecosystems. It's a compliment to Go that you'd even consider the comparison. :)
- lycopodiopsida 3y ago
  Java's tooling is indeed very good but comes with a huge downside of being bound to an IDE.
atombender 3y ago
One of the weakest areas is analyzing heap dumps. The current format has very limited tooling; "go tool" has some extremely rudimentary visualization. There is gotraceui [1], which is much better, though you need to use Go trace regions to get much useful context. There's a proposal to support Perfetto [2], but I don't know if anything has come of it. [1] https://gotraceui.dev/ https://gotraceui.dev/ [2] https://perfetto.dev/ https://perfetto.dev/

i've sometimes heard that the JVM had best in class tooling for server troubleshooting. How does go compare to it now ?

by bsaul 3y ago

i've sometimes heard that the JVM had best in class tooling for server troubleshooting. How does go compare to it now ?

For good reason, the JVM has a ton more knobs that need adjusting. You can't just run Java code. The JVM has a lot of tricks you have to customize for based on your workload. For years until 1.19 the Go GC has had only one tuning parameter (GOGC).

tsimionescu 3y ago
Note that Go needs those knobs just as much as the JVM does, at least some of them. They just didn't want to expose them.
- philosopher1234 3y ago
  Which knobs does go need?
  - tsimionescu 3y ago
    Fine-grained control over various GC phases and decisions (such as the level of parallelism, max pause times). Until Go 1.19, it was even missing a max memory limit, and even now it only has a soft memory limit. Additionally, of course it would be nice to have more GC options, such as choosing between a throughput-oriented GC design and a latency-oriented one, having the option of a compacting GC of some kind to avoid fragmentation, or even having a real time GC option. Go has chosen a very old-fashioned GC design with very few tuning parameters possible, but even so it only exposes a very basic form of control.
    - cwbriscoe 3y ago
      I would rather just write code and trust the existing GC than mess around with knobs all day. I suppose there are < 1% of projects that may see some benefit in messing with the GC.
    - kbolino 3y ago
      I agree with most of your points but how is it "old-fashioned"? To me, that means things like reference counting or long stop-the-world pauses, neither of which are true of Go.
rileymichael 3y ago
I don't see the connection you're making between knobs that adjust runtime behavior and tooling. As an aside, "you can't just run java code" is a bit hyperbolic, plenty of people "just run" java apps and rely on the default ergonomics. The modern JVM also offers more automated options, such as ZGC which is explicitly self tuning.
- iamcalledrob 3y ago
  With Go, you never spend hours/days debugging broken builds due to poorly documented gradle plugins. As an example :) You really, truly, just run.
  - pjmlp 3y ago
    That is the problem right there, using Gradle without having learned why no one uses Ant any longer. As for Go, good luck doing just run when a code repo breaks all those URL hardcoded in source code.
    - philosopher1234 3y ago
      That’s not a real issue: * the go module proxy ensures repos are never deleted, so everything continues to work * changing to a new dep is as easy as either a replace directive or just find and replace the old url
      - pjmlp 3y ago
        It requires work to keep things working, exactly the same thing.
        philosopher1234 3y ago
        The module proxy is used by default and requires no work. I don’t think what you’re saying makes much sense.
Ironlink 3y ago
> You can't just run Java code. The JVM has a lot of tricks you have to customize for based on your workload. This sounds like something you would hear 10 years ago in relation to the CMS garbage collector. Since Java 9, G1 has been the default gc for multi core workloads and is self-tuning. The CMS gc was removed 4 years ago. If you do need to tune G1, the primary knob is target pause time. While other knobs exist, you should think carefully before using them. We run all of our workloads with vanilla settings.

Thaxll 3y ago

Go is one of the best language in term of tooling, it has just one binary that contains everything, I don't know any other language that includes out of the box all of that: - testing - benchmark - profiling - cross compilation ( that work from any platform, like compiling a windows .exe from your raspberry pi for example ) - some linting - documentation - package mgmt - bug report - code generation - etc... Java is probably more advanced in some fields ( like tracing / profiling ) but it lacks others.

neonsunset 3y ago
[flagged]
preommr 3y ago
Golang also has some of the worst tooling because everything is based off of what comes builtin, and because they're not specialized projects, they're very limited in capability and configuration. Coming from ts, tooling like tsconfig has a lot of options, but sensible defaults can be set with a single flag like strict mode. If some org has some specialized needs, they can dive into the configuration and get what they need. With golang, not only would it be a lot for any single team to offer all those features at a decent level of polish, the golang culture in particular is very, very resistant to small bits of comfort because of dogma like "worse is better". It's kind of similar to Haskell's "avoid success at all cost".
- Cthulhu_ 3y ago
  TSConfig having a lot of options isn't a selling point though; you shouldn't need any of those. That said, the flags and strict mode are intended for when you have an existing "sloppy" JS codebase or mindset. You shouldn't need anything (except strict mode) in a new TS project. That said, TS is quickly becoming the antithesis of what Go tries; every release for the past few years I've seen now are all features where I'm like, "I will never need or use this". Some conveniences have been improved on - like better type inference - but that will mainly allow for cleaning up workarounds. "some orgs with specialised needs" are going to be legacy projects, either older TS versions that didn't have the features that it does now, or JS codebases. This isn't generally an issue with Go projects, most of which are greenfield. That said, there's some X to Go conversion projects that produce less than ideal code though, like usage of the `interface{}` type that at this point is a code smell.

tsimionescu 3y ago

I think Go is catching up, but it's still significantly behind. For example, Go memory profiles are much, much worse than Java's - they don't even have them integrated with the GC to show the ownership graph (they can only show where each object was allocated, instead of which other objects are holding a reference to it). The CPU profiling parts seemed more up to par. This tracing thing is nice, I'm not as familiar with this are of Java. Also, I don't think Java has a built-in race detector (except perhaps for the detection of concurrent write and iterations in collections?). Also, the OpenJDK JVM supports live debugging and code hotswap, going so far as to de-optimize code you're debugging on the fly to make it readable. Go doesn't support live code reload even in local builds.

tptacek 3y ago

I really like Go's tooling, and while I'm fluent in Java I've never been on a full-time Java team. I've remarked to Java friends in the past that I think Go has best-in-class tooling and had my ass handed to me, in detail and at length. By many accounts, Java is the gold standard for tooling in language ecosystems. It's a compliment to Go that you'd even consider the comparison. :)

lycopodiopsida 3y ago
Java's tooling is indeed very good but comes with a huge downside of being bound to an IDE.

atombender 3y ago

One of the weakest areas is analyzing heap dumps. The current format has very limited tooling; "go tool" has some extremely rudimentary visualization. There is gotraceui [1], which is much better, though you need to use Go trace regions to get much useful context. There's a proposal to support Perfetto [2], but I don't know if anything has come of it. [1] https://gotraceui.dev/ https://gotraceui.dev/ [2] https://perfetto.dev/ https://perfetto.dev/