7 ms·

Disclaimer: I only very occasionally touch Go code. Hasn't this been a very long time coming? Iirc there has been much dispute over this in the community. Can

• endymi0n 5y ago
  In a nutshell, torn between the extreme ends of high compile-time cost and large code size of a C++ flavored implementation and the high runtime cost and dangers of boxing/unboxing (Java), Golang opted for "none of the above" and tried to limit complexity drivers / powerfulness / expressiveness / usefulness instead, keeping the impact on both compile time and run time low. About how well that decision will turn out in practice, we'll start to know soon.
  • kevin_thibedeau 5y ago
    The compile time issues for C++ are entirely because of the creaky header mechanism that doesn't permit efficient parsing. Generics have worked fine in Ada since its inception. Any modern language can adopt the same process of tracking a formal abstract interface that is parsed once and expanded into concrete code as necessary.
    • FooBarWidget 5y ago
      Rust also has (relatively) bad compile times due to generics. Not as bad as C++, but you can notice it's significantly worse than Go.
      • pjmlp 5y ago
        D, Ada, Eiffel, Delphi go as counter example, and C++ modules are already proving a much better experience in VC++.
        • FooBarWidget 5y ago
          Delphi didn't have generics. Not sure about more modern versions, but the power of the generics also impacts compile times. Java generics barely impact compile times at all but they're also nowhere as powerful as Rust and C++ ones.
          • pjmlp 5y ago
            You stop using Delphi long time ago, I would say. To pick one of my examples, D templates and compile time metaprogramming are even more powerfull than Rust and C++ ones, yet it compiles just as fast.
          • benibela 5y ago
            Delphi added generics in 2009 So it had them roughly as long as Go existed
      • yakubin 5y ago
        Rust does compile slower than Go, but it's not due to generics. It's mostly due to LLVM codegen and procedural macros. Go has the benefit of not relying on LLVM and not having procedural macros.
        • codeflo 5y ago
          Absolutely true. I’d add that Rust is also doing a lot more expensive optimizations in release builds.
          • jcelerier 5y ago
            Until recently Go didn't even use registers for passing arguments, it just put everything on the stack like in a 1965 textbook (https://go.googlesource.com/proposal/+/refs/changes/78/248178/1/design/40724-register-calling.md https://go.googlesource.com/proposal/+/refs/changes/78/24817...)
            • eloff 5y ago
              If you mean for function calls, I believe you're correct, not taking into account inline functions. However, for code generation Go obviously uses registers since way before the 1.0 days.
        • edflsafoiewq 5y ago
          A lot of the IR comes from expanding huge stacks of generic functions. I don't think the issue can't be neatly partitioned up like that.
        • geodel 5y ago
          You are right of course about LLVM being source of slowness. In general discussion I see around is that all Rust's perf optimizations are to Rust's credit (nothing about LLVM optimization) while all woes around Rust's compile time lay at step of LLVM and Rust is not be blamed.
      • vyskocilm 5y ago
        There is tinygo with llvm backend and the build times are abysmal.
    • kenniskrag 5y ago
      Isn't that solved with c++ modules [1]? [1] https://en.cppreference.com/w/cpp/language/modules https://en.cppreference.com/w/cpp/language/modules
      • pjmlp 5y ago
        Yes, with VC++ offering the best experience currently.
        • throwaway2037 5y ago
          I am confused. Why was this downvoted? Is GCC and Clang doing better? (Or another C++ compiler?)
          • Kranar 5y ago
            Because the answer is false, modules do not solve the problem of having common/shared template instantiations. As for the comment about MSVC, it's mostly off topic, doesn't relate to the question that was asked (which had nothing to do with which compiler provides the best experience), and even if you accept that MSVC provides the best module experience, it's support for it is still very buggy and not suitable for anything other than experimenting and beta testing.
      • Kranar 5y ago
        Not really, in C++ templates still need to be instantiated in every module but modules don't have to each repeat the parsing of template definitions. The module that declares the template will do the job of parsing the template and producing some intermediate representation of it that other modules can consume. Okay that does save some amount of time but the overwhelming majority of time spent compiling templates is in instantiating them, not parsing them from literal text into an AST. Modules don't make instantiating templates any faster, it only makes parsing them faster.
        • pjmlp 5y ago
          They sure do, make the most common expansions avaiable as extern templates.
    • josephg 5y ago
      The process of expanding genetic code into concrete code based on the types (monomorphizing) can also be an expensive process. At least, people in the rust world point to it a lot as a reason why some crates compile slowly. Monomorphizing multiplicatively increase how much code LLVM needs to process (and optimize). Mind you, C/C++’s ridiculous header system is probably still a much bigger issue. Especially because C++ templates usually need to go in header files.
      • deleted 5y ago
        [deleted]
      • xigoi 5y ago
        Increases compared to what? If you don't use generics and write the code for each type manually, you'll end up with exactly the same thing.
        • pshc 5y ago
          Increased compile time compared to doing polymorphism with an extra layer of indirection, I’m guessing
        • zwieback 5y ago
          I often wonder about that - if I was going to write by hand I might end up extracting a simple interface, do some type coercion/promotion or some other trick to reduce the number of functions I need to write. I read about how .Net does Generics at the VM level and was very impressed, a good compromise between C++ "macro expansion" and Java "type erasure", both of which seem extreme. At the end of the day, though, when generics are present I stop worrying and just use List<int>, List<float>, List<char>, etc. without a second thought. The compiler, VM or runtime can deal with it although I might get punished in some way.
      • yakubin 5y ago
        Although monomorphization takes a significant chunk of a typical Rust compilation, it pales in comparison to LLVM codegen and execution of procedural macros. So although it's academically worthy of note, optimization-wise it's not where the focus should be. Personally, I'd like to see someday a Rust compiler which is not based on LLVM. Both Zig and Jai compile much faster when using their non-LLVM backends than when using LLVM, so Rust is not the odd one here either.
    • nicoburns 5y ago
      That's not true, Rust doesn't have those headers and has the same compile time issues as C++.
      • the-smug-one 5y ago
        Rust has macros and an expensive type system though, and compilation is getting faster.
  • shadowgovt 5y ago
    This summary concisely captures the key thing about generics that has kept them out of Go for so long: they weren't created in a vacuum. Go's developers had the flaws in C++ and Java's approaches to draw on in their attempt to find a better approach. Many people calling for generics to have been implemented sooner were fine with those flaws in the other languages, but the Go team wanted to do better than that.
    • pjmlp 5y ago
      Generics exist in languages since 1976, more than enough examples than focusing on C++ and Java.
      • shadowgovt 5y ago
        good point! What could the Go team glean from those languages to improve Go's generics implementation?
        • pjmlp 5y ago
          Lots of things, here is their acknowledgement that it was a mistake to ignore them. > we were biased too much by experience with C++ without concepts and Java generics. https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
    • kaba0 5y ago
      If they wanted to avoid problems they would have implemented the feature right away, instead of making it a second thought for a supposedly modern language.
  • Banana699 5y ago
    C# also made a similar tradeoff between purely generative generics of C++ and the type-erased generics of Java.
• qbasic_forever 5y ago
  > Hasn't this been a very long time coming? That's a feature not a bug of golang. Major language changes like this by design are supposed to take a lot of time and thought to land.
• klodolph 5y ago
  I only occasional do language design / compiler writing projects, or work with compiler internals. Most people are really bad at estimating the implementation complexity and tradeoffs inherent in various language features. I'd say that C++ serves as a warning to others... think before you add features to your language, or you'll end up a total mess, like C++. Java and C# gave us some interesting and subtle lessons about what does and does not work about language features like generics. C++'s templates are just a total mess, all around. Java's generics are kind of a funny compile-time feature and have a ton of limitations. C# generics have some downright nasty interactions with other parts of the type system, like operator overloading. IIRC the designers of C# have some regrets about how generics and other features were implemented. This is from an in-person talk, I don't have anything to cite. You should take almost nobody at face value when they talk about language features like generics, because there is almost nobody with direct experience both designing and implementing those features. You should be pretty skeptical about what I'm saying too, IMO. But do believe that the design tradeoffs for generics are a complicated enough to justify the wait. The Golang approach seems to strike a balance between extreme approaches. The C++ approach is "pay for what you use" which, in practice, is actually an extremist language design philosophy. In C++ / Rust, you are supposed to pay for templates only in code size and not in runtime. Everything is fully instantiated. The Haskell approach is "one abstraction fits all, everything is a pointer, use an implementation dictionary, monomorphization is an optimization". Again, something of an extremist approach (similar to Java's, but the comparison with Go / Haskell is better because Go / Haskell both use implementation dictionaries). A middle approach is actually somewhat novel, believe it or not.
  • shadowgovt 5y ago
    C++ still has the dubious honor of being the only language where I encountered code that I could not compile because my machine lacked enough memory. I'm sure that's possible in other languages, but the program I was trying to compile wasn't that complicated... It had just been written by someone who believed every concrete class needed an abstract interface it was implementing.
    • klodolph 5y ago
• deleted 5y ago
  [deleted]