Is there a single statement about C# in this piece that isn't a complete falsehood?
Go does not need a Java-style GC
191–200 of 226 posts
Re: Go does not need a Java-style GC
#192Earlier quoted context omitted.
Additionally he doesn't seem to know that much about C#, which also has advanced GC, while allowing for C++ like memory management, if needed.
C# makes it possible to do C (not C++) like memory management but it does not make it easy. Unsafe C# code is really, really, really unsafe, much more unsafe than equivalent C code, and does not compose well. It's improving, with Span/Memory, etc, but it remains an absolute last resort.
why is it more unsafe than equivalent C code? I always thought it's simply a way to enable C-like real pointers/native memory ...
Re: Go does not need a Java-style GC
#193Earlier quoted context omitted.
Additionally he doesn't seem to know that much about C#, which also has advanced GC, while allowing for C++ like memory management, if needed.
It's odd how most people that haven't used a VM with GC are amazed by Go (no VM) and WASM (no GC) but still fail to understand that with a GC _AND_ VM you can code something that doesn't crash even if you make a big mistake! And they haven't even bothered to try it out! To use anything other than JavaSE/C# on the server you really need very good arguments!
Most programmers use PHP, Python, Ruby, Node.js which are all GC bytecode VMs.
What language are you imagining as an argument here?
Re: Go does not need a Java-style GC
#194Earlier quoted context omitted.
this is entirely BS. if by complex you mean overly abstracted and useless boilerplate then yes. java is larger and more complex. and your assertion about the runtime only being able to do so much is just wrong here. golang will slow down your application in order to meet GC deadlines. however its incredibly rare to see GC STW pauses for longer than 10s of ms. not even sure its possible given how the GC is written. th…
Have you followed this very thread? > golang will slow down your application in order to meet GC deadlines Hardly a good thing for throughput-oriented applications. Java let’s you tune this (the default G1 collector has a target pause time parameter, and then there is also the two new low-latency GC, Shenandoah and ZGC which has > golang entirely sidesteps the issues java has requiring said systems with better memory…
> Have you followed this very thread?
indeed i am, people seem to having issues dealing with the reality of the two languages. One (golang) the problems you encounter with its GC are easily remedied using memory pools or adding compute. The other? you don't really have a choice without fighting against the language itself. or relying on improvements to the GC itself. which is precisely why java has had to spend so much effort on their GC to reduce latency while golang has been able to achieve extremely similar results with a fairly straight forward concurrent mark and sweep.
> Hardly a good thing for throughput-oriented applications.
add more compute. problem solved. its extremely rare to have situations where you can't add more compute to the problem. that's the point. you can easily solve throughput issues with compute. you can't solve latency issues as easily. if your STW GC pause ends up being 30s+ you're fucked. period.
if you're GC is the source of the problem because of garbage generation, generate less garbage. in go that's generally very easy. in java its very much not.
>beat Go by a huge margin, due to its more advanced GC, see:
you mean the advantage that entirely disappears with a memory pool added in like 4 lines of code? doesn't sound like a huge margin win to me.
I've never once asserted java's GC isn't amazing for the problem its solving. I'm asserting its completely unnecessary in golang because golang allows avoiding the garbage to begin with.
you: 'JAVA GC IS AMAZING COMPARED TO GOLANGS!' me: 'who gives a shit in practice golang memory allocation problems are trivial to resolve'
its the in practice of dealing with reality of the two languages I care about not the self inflicted problems java forces on developers.
Re: Go does not need a Java-style GC
#195Earlier quoted context omitted.
Not sure if you're in on the joke, but for those who didn't go to the repo itself: https://github.com/golang-jvm/golang-jvm It's just a copy-paste of JRuby on April 1st and the readme now includes a rickroll. Maybe it's irresponsible of them to leave it up in a way that Google still finds as a legitimate-looking search result.
LOL, I was not aware and stepped right into that. There appear to be other attempts: for example https://github.com/zxh0/jvm.go (might be the same?) Let's just say people have tried/joked about it but it never took off.
Its other way round. Implementing JVM in Go and not running Go over JVM.
Re: Go does not need a Java-style GC
#196Earlier quoted context omitted.
Or being amazed by Go's compile speed, when Turbo Pascal and Object Pascal compilers were already doing that in the 1980's, or finding WASM innovative when polyglot bytecodes with no GC also go back to the early 1980's, like Amsterdam Compiler Kit EM as one example among many.
Not to mention Turbo Pascal was compiling faster than Go, on a single-core, in-order 20Mhz PC...
With more advanced language features too.
Re: Go does not need a Java-style GC
#197Earlier quoted context omitted.
> Go users have to work around using ugly hacks when hit, because they don't have tuning knobs Yeah, Java users just have to hire Java performance tuning experts from sprawling Java perf consulting cottage industry. Can't get much simpler than that.
That's because Java is used to run huge systems (dare I say, "enterprise scale"), whereas golang, especially today with microservices" is not seen in such areas. However, we still see issues in golang like * https://blog.discord.com/why-discord-is-switching-from-go-to... * https://news.ycombinator.com/item?id=21670110
I hope it is joke. Endless Java GC problems with any large system (cassandra, hadoop, websphere and so on and on) despite decades of work from top major vendors like Oracle, SAP, IBM etc tells a different story. I have seen enough "Enterprise Scale" java systems which would die of Out of memory error before even "hello world" is served. Though "Java runs huge systems" type thing work for those who wouldn't know most of these huge enterprise systems do not run as single JVM process.
As a user of system that shits everyday except weekends on a 128GB of heap, I am not gonna buy that "oh these microservice kids do not know enterprise scale systems." I have seen both and not an uncritical fan of either.
Re: Go does not need a Java-style GC
#198Re: Go does not need a Java-style GC
#199Earlier quoted context omitted.
No, it is same reasoning as Java not needing dense memory layouts
No, Java folks never denied they were eventually needed, in fact IBM has had the object layout extension on their implementation for almost a decade now.
And Go folks denied generics need? LOL. Go hate is blinding your reasoning.
Re: Go does not need a Java-style GC
#200Earlier quoted context omitted.
Ofcourse. The point was about above snarky comment. Go devs took time to implement generics balancing with competing priorities. Java devs taking time to implement value types balancing their competing priorities.
From 1996 point of view it seemed it was a correct decision from the language landscape with Java coming from Smalltalk and Objective-C heritage, where 9 years later all languages had generics, except one created by the same authors of Go, and their newly born language. Also there have been extensions, and the work to fix it goes back to 2014, after escape analysis proving not being good enough, with IBM and Azul hav…
All said and done it is basically: "There is a nuance when people I like do not do desired thing and excuse when people I don't like do not do same desired thing"