3 ms·
> I've seen a lot of people fiddle with JVM settings without doing the controlled experiments That's a problem with what the people are doing then, not the JVM
by apta 7y ago
> I've seen a lot of people fiddle with JVM settings without doing the controlled experiments
That's a problem with what the people are doing then, not the JVM. Furthermore, the new low latency JVM GCs only have 2-3 knobs to tune.
golang likes to pretend that complexity doesn't exist, and goes for the most simplistic approach, at the cost of things like throughput, code size, speed, code maintainability, etc. The JVM is suited for a much wider range of tasks.
- hu3 7y agoThat's not the impression I get from Go literature at all. Go authors tend to be quite humble about Go being targeted mostly to a specific class of software, read servers. And Go is pretty darn successful at it. The lack of GC knobs is an informed decision within that context.
- apta 7y ago"Servers" refers to a broad range of software. If you're writing a simple app that parses JSON and handles REST, it can be an ok fit. Now if you're writing server software that needs to be high-throughput, then that's where you hit golang's limitations.
- hu3 7y agoHigh throughput servers you say? I'll just leave this here: > How We Built Uber Engineering’s Highest Query per Second Service Using Go https://eng.uber.com/go-geofence/ https://eng.uber.com/go-geofence/ And that was in 2016. Go's GC performance characteristics improved quite a bit since then.
- apta 7y agoThis doesn't negate the fact that I stated. You can throw more hardware at the problem to reach higher throughput if your problem domain allows for it (such as the use case you link to). It goes without saying that this is an inefficient approach, not to mention that this won't apply if you're running batch jobs for instance where you need high throughput (e.g. on individual nodes).