Go does not need a Java-style GC

Post by thrashh » Wed, Nov 24, 2021, 4:40 PM UTC

bullen wrote: post #140

vinkelhake wrote: post #137

Earlier quoted context omitted.

The innovation in WASM is more about getting all the major players in the browser space to agree and support it as a first-class citizen in the web stack. That polyglot bytecodes existed in the early 1980's does nothing for the web.

What a perfect example, have you even tried Java? I'm guessing you are coding for the client? C++ arrogance is the problem here. About the pipe dream of WASM there are 3 problems: 1) Compile times (both WASM and the browser) 2) If you thought Applets where insecure (btw they wheren't) wait until the .js (also a VM with GC...) bindings that you are forced to go through to reach anything from WASM securely gets attenti…

Post by kaba0 » Wed, Nov 24, 2021, 5:01 PM UTC

altfredd wrote: post #171

native_samples wrote: post #162

Earlier quoted context omitted.

The JIT is getting better. Major escape analysis upgrades are a big part of where Graal (a drop-in replacement for the HotSpot JIT) gets its performance boosts. EA definitely does work well there because Truffle depends on escape analysis and scalar replacement very heavily. GraalVM CE is better than regular HotSpot at doing it and GraalVM EE is even better again.

Graal effort is over 10 years old. Jaotc, — Graal's sole mainstreamed part, — has been recently removed from OpenJDK in 17th release, and Oracle says [1], that they are "considering the possibility of using C2 for ahead-of-time" 1: https://mail.openjdk.java.net/pipermail/discuss/2020-Novembe...

Post by kaba0 » Wed, Nov 24, 2021, 5:06 PM UTC

jatone wrote: post #175

kaba0 wrote: post #135

Earlier quoted context omitted.

Comparing apples to oranges. Java has been around for multiple decades so there may be some bias on your part based on very old examples, but also, your “average” java program is more likely much more complex and larger code base than your average go one. Also, shitty code does get written by developers quite often, regardless of language — at that point the runtime can only do that much.

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…

Post by joelfolksy » Wed, Nov 24, 2021, 5:42 PM UTC

gwbas1c wrote: post #103

Skimmed this and found that a lot of claims are inaccurate and don't have data... Then realized, ugh, it's another Medium post. One particular wrong claim: > In C#, for example, reference objects and value objects live entirely separate lives. Value objects are always passed by value. You cannot take the the address of a value object and pass that around. No, you need to copy the whole object every time. In C#, there…

Post by joelfolksy » Wed, Nov 24, 2021, 5:55 PM UTC

throwaway894345 wrote: post #41

Ericson2314 wrote: post #33

This is mostly stupid. Being able to have many GCs is a good thing. The big reason for "value types" is controlling spacial locality in memory, not GCs being bad per-se. Also, they undersell the java/c# situation. C# has "ref, out, or in", but even without those, you can always make a reference wrapper that has the value type as a field. So "reference types suck because coppying" is nonsense garbage.

I mean, I’ve dabbled in all of these languages, and I much prefer Go’s value types to ref, out, in, and a half dozen GCs. It’s nice that these VM languages have a distinct thing for every eventuality, but I much prefer a single thing that works 99% of the time.

  func changeName(p *Person) {
    p.firstName = "Bob"
  }

  void changeName(ref Person p) {
    p.firstName = "Bob";
  }

?