Go does not need a Java-style GC • Hacker News Board

Re: Go does not need a Java-style GC

#11

Post by Yoric » Tue, Nov 23, 2021, 5:55 PM UTC

bitwize wrote: post #4

What it needs is Rust style static lifetime management.

As a Rust developer, contributor and generally a big fan of Rust, I'd tend to disagree. Having a garbage-collector is a lifesaver for many algorithms. Static lifetime management is great but isn't something you want to force developers to use when they're more interested in coming up with solutions quickly.

Also, I really don't see how it would work in Go. You require a pretty strong type system to make static lifetime management work. Unless something has changed radically in the recent past, that's not something that the Go community had much interest in (yes, I know that generics are one step in that direction, but I'm not aware of further steps being discussed).

Re: Go does not need a Java-style GC

#12

Post by jeffbee » Tue, Nov 23, 2021, 5:55 PM UTC

There are very few falsifiable statements in this article but the extant ones are all demonstrably false, starting with this whopper:

"This typically causes Java programs to have complete freezes of several hundred milliseconds where objects get moved around"

Yeah, i mean, definitely not. The only language I regularly work with that has this property is, surprise, Go.

The proof is in the tasting, as they say. Go look at the gRPC daily benchmarks if you want hard data. Java beats Go latency at the median and at the tail while having substantially better specific throughput. In other words the Java GC has no tradeoff versus the Go GC; it is better in every way.

Re: Go does not need a Java-style GC

#13

Post by majou » Tue, Nov 23, 2021, 5:56 PM UTC

natanbc wrote: post #6

> In a multithreaded program, a bump allocator requires locks. That kills their performance advantage. Java uses per-thread pointer bump allocators[1] > While Java does it as well, it doesn’t utilize this info to put objects on the stack. Correct, but it does scalar replacement[2] which puts them in registers instead > Why can Go run its GC concurrently and not Java? Because Go does not fix any pointers or move any o…

ZGC[4] in particular has me excited, enough so to want to pick up a JVM language.

Re: Go does not need a Java-style GC

#14

Post by IceWreck » Tue, Nov 23, 2021, 5:58 PM UTC

Yoric wrote: post #11

bitwize wrote: post #4

What it needs is Rust style static lifetime management.

As a Rust developer, contributor and generally a big fan of Rust, I'd tend to disagree. Having a garbage-collector is a lifesaver for many algorithms. Static lifetime management is great but isn't something you want to force developers to use when they're more interested in coming up with solutions quickly. Also, I really don't see how it would work in Go. You require a pretty strong type system to make static lifeti…

> You require a pretty strong type system to make static lifetime management work

Go is strongly and statically typed.

Re: Go does not need a Java-style GC

#15

Post by Thaxll » Tue, Nov 23, 2021, 6:00 PM UTC

jeffbee wrote: post #12

There are very few falsifiable statements in this article but the extant ones are all demonstrably false, starting with this whopper: "This typically causes Java programs to have complete freezes of several hundred milliseconds where objects get moved around" Yeah, i mean, definitely not. The only language I regularly work with that has this property is, surprise, Go. The proof is in the tasting, as they say. Go look…

The Java gRPC SDK is heavily optimized by Google, much more than the Go one. Until recently Java pauses were a real issue,

I worked with a lot of Java based solutions ( elastic search, hadoop etc ... ) and was never impressed by the GC.

Re: Go does not need a Java-style GC

#16

Post by bestinterest » Tue, Nov 23, 2021, 6:03 PM UTC

avita1 wrote: post #10

Cool article, I'm not sure I agree with the headline. I used to write low-scale Java apps, and now I write memory intensive Go apps. I've often wondered what would happen if Go did have a JVM style GC. It's relatively common in Go to resort to idioms that let you avoid hitting the GC. Some things that come to mind: * all the tricks you can do with a slice that have two slice headers pointing to the same block of memo…

How have you found Go in contrast to Java. Is the simplicity worth it?

Re: Go does not need a Java-style GC

#17

Post by jeffbee » Tue, Nov 23, 2021, 6:05 PM UTC

Thaxll wrote: post #15

jeffbee wrote: post #12

There are very few falsifiable statements in this article but the extant ones are all demonstrably false, starting with this whopper: "This typically causes Java programs to have complete freezes of several hundred milliseconds where objects get moved around" Yeah, i mean, definitely not. The only language I regularly work with that has this property is, surprise, Go. The proof is in the tasting, as they say. Go look…

The Java gRPC SDK is heavily optimized by Google, much more than the Go one. Until recently Java pauses were a real issue, I worked with a lot of Java based solutions ( elastic search, hadoop etc ... ) and was never impressed by the GC.

Maybe, but it's still not possible that the Java test has a median latency of 150µs, a tail latency of 350µs, and a regular need to stop the world for hundreds of milliseconds. That statement is simply not compatible with reality.

Re: Go does not need a Java-style GC

#18

Post by Yoric » Tue, Nov 23, 2021, 6:06 PM UTC

IceWreck wrote: post #14

Yoric wrote: post #11

Earlier quoted context omitted.

As a Rust developer, contributor and generally a big fan of Rust, I'd tend to disagree. Having a garbage-collector is a lifesaver for many algorithms. Static lifetime management is great but isn't something you want to force developers to use when they're more interested in coming up with solutions quickly. Also, I really don't see how it would work in Go. You require a pretty strong type system to make static lifeti…

> You require a pretty strong type system to make static lifetime management work Go is strongly and statically typed.

It's a spectrum. Rust is further than Go in the direction of "strong type system", and somewhat lateral wrt Haskell, F# or OCaml, for instance (each is more strongly typed in different directions). Idris or Coq are further than Rust in most directions, etc.

Re: Go does not need a Java-style GC

#19

Post by lucian1900 » Tue, Nov 23, 2021, 6:06 PM UTC

IceWreck wrote: post #14

Yoric wrote: post #11

Earlier quoted context omitted.

As a Rust developer, contributor and generally a big fan of Rust, I'd tend to disagree. Having a garbage-collector is a lifesaver for many algorithms. Static lifetime management is great but isn't something you want to force developers to use when they're more interested in coming up with solutions quickly. Also, I really don't see how it would work in Go. You require a pretty strong type system to make static lifeti…

> You require a pretty strong type system to make static lifetime management work Go is strongly and statically typed.

For some value of "strongly". It has nil and lacks sum types, so it is comparatively much weaker than even Rust/Swift.

Re: Go does not need a Java-style GC

#20

Post by masklinn » Tue, Nov 23, 2021, 6:07 PM UTC

IceWreck wrote: post #14

Yoric wrote: post #11

Earlier quoted context omitted.

As a Rust developer, contributor and generally a big fan of Rust, I'd tend to disagree. Having a garbage-collector is a lifesaver for many algorithms. Static lifetime management is great but isn't something you want to force developers to use when they're more interested in coming up with solutions quickly. Also, I really don't see how it would work in Go. You require a pretty strong type system to make static lifeti…

> You require a pretty strong type system to make static lifetime management work Go is strongly and statically typed.

Go's type system is much, much weaker than what is needed for safe static lifetime management be even remotely close to workable.

Static typing is not an on-off, there are statically typed languages with extremely weak type systems (e.g. C), languages with somewhat weak type systems (e.g. Java, Go), languages with strong type systems (e.g. OCaml, Haskell) and languages with extremely strong type systems (e.g. ATS, Idris).

And that's a simplification because it's not linear either.