10 ms·
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 danger
by 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 agoThe 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 agoRust 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 agoD, Ada, Eiffel, Delphi go as counter example, and C++ modules are already proving a much better experience in VC++.
- FooBarWidget 5y agoDelphi 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 agoYou 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 agoDelphi added generics in 2009 So it had them roughly as long as Go existed
- yakubin 5y agoRust 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 agoAbsolutely true. I’d add that Rust is also doing a lot more expensive optimizations in release builds.
- jcelerier 5y agoUntil 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 agoIf 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 agoA 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 agoYou 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 agoThere is tinygo with llvm backend and the build times are abysmal.
- kenniskrag 5y agoIsn'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 agoYes, with VC++ offering the best experience currently.
- throwaway2037 5y agoI am confused. Why was this downvoted? Is GCC and Clang doing better? (Or another C++ compiler?)
- Kranar 5y agoBecause 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 agoNot 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 agoThey sure do, make the most common expansions avaiable as extern templates.
- josephg 5y agoThe 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 agoIncreases 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 agoIncreased compile time compared to doing polymorphism with an extra layer of indirection, I’m guessing
- zwieback 5y agoI 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 agoAlthough 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 agoThat's not true, Rust doesn't have those headers and has the same compile time issues as C++.
- the-smug-one 5y agoRust has macros and an expensive type system though, and compilation is getting faster.
- shadowgovt 5y agoThis 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 agoGenerics exist in languages since 1976, more than enough examples than focusing on C++ and Java.
- shadowgovt 5y agogood point! What could the Go team glean from those languages to improve Go's generics implementation?
- pjmlp 5y agoLots 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 agoIf 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 agoC# also made a similar tradeoff between purely generative generics of C++ and the type-erased generics of Java.