6 ms·
Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an
by nradov 8mo ago
Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using Java for certain purposes).
- zokier 8mo agoGo has gc too and arguably worse one than Java
- zadikian 8mo agoYeah but I do like not having to give Go several flags to do something reasonable with its memory
- oblio 8mo agoThat's a very shallow argument.
- zadikian 8mo agoIf it were shallow, it'd be easy for them to fix
- oblio 8mo agoBackwards compatibility, every vim and emacs and bash enthusiast should know about it. It's easy for the USER to fix, since there are flags available. In the day of LLMs it's also easy to find out about those flags and what they do. And if it's so important, testing shouldn't be supremely hard, either.
- zadikian 8mo agoDo you mean backwards compatibility for things that rely on the default settings? The defaults have already changed across Java versions and also depend on the system. Normally when you run a non-Java binary, it uses very little memory to start, doesn't have a limit, and returns memory to the system when it frees things. Supposedly you can set JVM flags to do all that, but performance probably suffers, otherwise they would've just done that. So in practice users are always setting the flags carefully.
- gf000 8mo agoThe "reasonable" thing go does is pausing core threads doing the actual work of your program, if it feels they create too much garbage so it can keep up, severely limiting throughput.
- mknyszek 8mo agoI think this is a misunderstanding. If the program out-paces the GC because the GC guessed the trigger point wrong, something has to give. In Go, what gives is goroutines have to use some of their time slice to assist the GC and pay down their allocations. In Java, I believe what you used to get was called "concurrent mode failure" which was somewhat notorious, since it would just stop the world to complete the mark phase. I don't know how this has changed. Poking around a little bit it seems like something similar in ZGC is called "allocation failure"? The GC assist approach adopted by Go was inspired by real-time GC techniques from the literature and in practice it works nicely. It's not perfect of course, but it's worked just fine for lots of programs. From a purely philosophical point of view, I think it results in a more graceful degradation under unexpectedly high allocation pressure than stopping the world, but what happens in practice is much more situational and relies on good heuristics in the implementation.
- adgjlsfhk1 8mo agoA lot of the answer is that if you can do more work while generating less garbage (lower allocation rate) this problem basically solves itself. Basically every "high performance GC language" other than Java allows for "value type"/"struct"s which allow for way lower allocation rate, which puts a lot less pressure on the GC.
- rossjudson 8mo agoAnd yet Java outruns pretty much all of them, because it doesn't actually allocate everything on the heap all of the time. And you've been able to declare and work with larger structures in raw memory for ... 20 years? You mostly don't need to, but sometimes you want to win benchmark wars. And of course it's getting value types now, so it'll win there too. As well as vectors.
- vips7L 8mo agoYou don’t have to do that with Java either.
- deepsun 8mo agoAre you sure about Go's garbage collector doesn't have pauses? AFAIK they are worse than modern Java's garbage collector [1]. I'm not sure it's even better than Java's, especially for modern ZGC (and you can choose your GC in Java). Definitely less configurable. I would say most of online comments about Java's GC are long outdated. For example, in web servers a lot of work is request-response, so it's convenient to utilize generational GCs (so that each request data would fit into "young" generation). Similar to arenas, but without code changes. Go's GC is not generational though, so you should care about allocations. https://codemia.io/blog/path/The-Evolution-of-Garbage-Collectors-From-Javas-CMS-to-ZGC-and-a-JVM-vs-Go-vs-Rust-Latency-Shootout https://codemia.io/blog/path/The-Evolution-of-Garbage-Collec...
- gf000 8mo agoJava's GCs (plural) are hands down better.
- Tostino 8mo agoHell, I even had a use case where serial GC was actually the correct choice (small job runner process that needed to be extremely low memory overhead). It's nice having options, and most of those options are extremely good for the use cases they were designed for.
- Mawr 8mo agoOk, which one do I choose then, with what configuration? How much time do I need to spend on this research? How do I verify that they are actually better? Is the overall performance of my program better? Because that's what I care about. I of course do include memory usage in "performance".
- gf000 8mo agoDo you need extra-low latency, even at very high percentile and are willing to give away a bit of throughput for it? ZGC At almost every other case: G1 (the default, just don't add any flags). Do you want to trade off using less memory at the price of some throughput? Decrease heap size, otherwise don't add anything. That's it, in most cases just use the default.
- spullara 8mo agoGC pauses on modern JVMs are < 1ms (ZGC & Shanandoah)
- peterashford 8mo agoGo's GC is orders of magnitude behind Java's.