Hacker News Reader

Comment by munificent | Hacker News Reader

I think Go should have shipped with generics from day one as well.

But you breezily claiming they made the same blunder as Java omits the fact that they didn't make the same blunder as Rust and Swift and end up with nightmarish compile times because of their type system.

Almost every language feature has difficult trade-offs. They considered iteration time a priority one feature and designed the language as such. It's very easy for someone looking at a language on paper to undervalue that feature but when you sit down and talk to users or watch them work, you realize that a fast feedback loop makes them more productive than almost any brilliant type system feature you can imagine.

View on HN

This is a very good point, fast compilation times are a huge benefit. The slow compiler is a downside of languages like Rust, Scala, and Haskell. Especially if you have many millions of lines of code to compile like Google.

However, OCaml has a very fast compiler, comparable in speed to Go. So a more expressive type system is not necessarily leading to long compilation times.

Furthermore, Scala and Haskell incremental type checking is faster than full compilation and fast enough for interactive use. I would love to see some evidence that Golang devs are actually more productive than Scala or Haskell devs. So many variables probably influence dev productivity and controlling for them while doing a sufficiently powered experiment is very expensive.

Take a look a the kubernetes source code. It's millions of lines, and almost all of it is generated. In a language like C++ or Rust, the vast majority of it would be template or macro instantiations.

For an apples-to-apples comparison of compilation speed, you should either include the time it takes go generate to run, and the IDE to re-index all the crap it emits, or you should count the number of lines of code in the largest intermediate representation that C++ or Rust has.

> For an apples-to-apples comparison of compilation speed, you should either include the time it takes go generate to run

But that would be unfair to the very design choice of omitting metaprogramming while exposing the go/ast library to users to foster code generation.

What makes you think Rust’s compile times are related to its type system?

The way the type system interacts with the rest of the language leads you down the path to monomorphization as the compilation strategy. Monomorphizing is what gives you huge piles of instantiated code that then has to be run through the compiler back end.

Blaming it on LLVM like another comment does misses the point. Any back end is slow if you throw a truck-load of code at it.

I'm not saying monomorphization is intrinsically bad. (My current hobby language works this way.) But it's certainly a trade-off with real costs and the Go folks didn't want their users to have to pay those costs.

Monomorphization has got nothing to do with type system though. If you have a GC (as go does), you can automatically box your references and go from a `impl Trait` to a `&mut dyn Trait` with the GC taking care of value vs reference semantics. Monomorphization is orthogonal to how you define the set of valid arguments.

Except if your traits are not dyn-compatible. Which I believe a lot of Rust's traits are not. That restriction is specifically why Go does not allow methods to have extra type parameters: To make it possible for the language implementation to choose its own tradeoff between monomorphization and boxing.

So I don't think you can say that this has nothing to do with the type system. Here is a restriction in the Go type system that was specifically introduced to allow a broad range of implementation choices. To avoid being forced to choose slow compilers or slow code: https://research.swtch.com/generic

The Go type system and the way it does generics is directly designed to allow fast compile times.

> you can automatically box your references

Yes, but that is now a different runtime cost which Go also didn't want to pay.

The language goes to great pains to give you pretty good control over layout in memory and avoid the "spray of tiny objects on the heap with pointers between them" that you get in Java and most other managed languages.

I think Swift maybe does something more clever with witness tables, but I don't recally exactly how it works.

It's not an easy problem.

> I think Swift maybe does something more clever with witness tables, but I don't recally exactly how it works.

Pestov actually wrote a long explanation of what it is that Swift does there[1,2]. And I’m almost sure you’ve already seen it, but it’s been on my reading list forever and I’m hoping that maybe if I can’t get myself to read it, than somebody else will see this comment, get interested and do it.

[1] http://download.swift.org/docs/assets/generics.pdf

[2] https://github.com/apple/swift/tree/main/docs/Generics

Yeah, I've had that PDF sitting on my hard drive for years. I'm definitely interested but it's 600 pages.

You realize that having a generics and having monomorphization are two orthogonal things, right?

If you're not aiming for the highest possible performance, you can type erase your generics and avoid the monomorphization bloat. Rust couldn't because they wanted to compete with C++, but Go definitely could have.

People keep mistaking languages with implementations.

OCaml and Haskell don't suffer from similar pain points, because interpreters, and JIT like tooling is also available.

One can happily develop with one toolchain, and press the red button for an optimised compiled build, when it actually matters.

Also both Swift and Rust have made the mistake to make used of the compiler backend that everyone avoids when they care about build performance, LLVM.

This has been a lazy excuse/talking point from the Go team for a while, but in realitiy Generics aren't the reason why Rust and Swift compile slowly, as can be easily shown by running cargo check on a project using a hefty dose of generics but without procedural macros.

Last time I checked, Rust's slow compile times were due to LLVM. In fact, if you want to make Rust faster to compile, you can compile it to wasm using cranelift.

Not just LLVM in itself but the Front-end codegen: AFAIK the rust front-end emits way too much LLVM IR and then counts on LLVM to optimize and they have been slowly adding optimizations inside the front-end itself to avoid IR bloat.

And there's also the proc macro story (almost every project must compile proc_macro2 quote and syn before the actual project compilation even starts).

Thanks for the clarification.

Reply on news.ycombinator.com