51–60 of 169 posts
Earlier quoted context omitted.
The thing about C++ compilation time is that if you care you can spend the time to optimize it. Our app takes ~40 seconds to compile and run tests on a decent machine (16 cores).
That only works if you can clean up slow-compiling code faster than other people are writing more slow-compiling code.
Earlier quoted context omitted.
Except that these kind of experiments contributed to Java generics, being made available 3 years before Go 1.0 was given a green light. Which is why Go had already a good example to learn from on how not to do language design.
Are you suggesting all new typed languages have generics? What makes you so sure there isn't room in the design space for a typed language without generics? As much as I like generics, Go's popularity is a success: programmers have spoken, and they value other things more than generics. Hindsight is 20/20, and even this isn't a commitment to introduce generics in Go.
Both its main influences, Oberon-2 and Limbo had zero traction on the market, and Limbo not only is quite close to Go, it had an whole OS full of the Plan 9 ideas to come along, yet it failed on the market.
Lack of generics has already been publicly acknowldge as problem.
> In three years of Go surveys, lack of generics has always been listed as one of the top three problems to fix in the language.
https://blog.golang.org/why-generics
And yes, there is no place on the 21st century for typed languages without generics, we already have enough of them from the previous century already.
CLU and ML, the first languages to support genericity are from the mid-70's, they are older than C++ and contemporary to C.
Earlier quoted context omitted.
Don't ever try Rust.
I haven’t used Rust on any significantly sized project. Could you elaborate? Is it only slow to compile release builds?
Earlier quoted context omitted.
Go is a popular language. A common criticism is lack of generics. Go has sought advice from the type theory community. This is the result. What alternative for Go do you know of that doesn't involve going back to 2001 technology?
They could have gone to 2001 technology way back. The Go FAQs say -> > " We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it." I mean if you are going to use 2001 technology, you could have found it long back.
> In three years of Go surveys, lack of generics has always been listed as one of the top three problems to fix in the language.
https://blog.golang.org/why-generics
By the way, they could have gone to 1974 (CLU), 1973 (ML), 1983 (Ada), 1986 (Eiffel), 1988 (Modula-3), 1990 (Sather & BETA), 1998 (C++), 2007 (D), 2009 (Java & Delphi).
These are just the most well known examples, CS literature in SIGPLAN and IEEE has plenty more to choose from. I bet Google employees can afford the respective subscriptions.
When there isn't any political willingness, there isn't anything to be found.
Earlier quoted context omitted.
Except that Java isn't obscure and experiments like Featherweight Java contributed to Java generics final design, introduced in November 2009, 3 years before Go 1.0 was released. What about that then?
It only strengthens your point but Java 5 was actually released way earlier, in '04.
Earlier quoted context omitted.
Don't ever try Scala. I work on a mid-sized CRUD application, and everything we need to recompile from scratch it takes 10 minutes. Typescript and Go are amazing in comparison in that department, but I miss the stronger typing of Scala.
>Don't ever try Scala. Don't ever try C++. I work on a medium-sized low-level C++ application, and every time we need to compile from scratch it takes over two hours on a single core. Even with distributing the compilation out across over a hundred cores the fastest it can get down to is around 20 minutes.
The syntax really makes me think to Zig - https://ziglang.org/documentation/master/#Introducing-the-Co... . I'd be curious to know if the authors of this paper have looked at it.
Earlier quoted context omitted.
Don't ever try Scala. I work on a mid-sized CRUD application, and everything we need to recompile from scratch it takes 10 minutes. Typescript and Go are amazing in comparison in that department, but I miss the stronger typing of Scala.
>Don't ever try Scala. Don't ever try C++. I work on a medium-sized low-level C++ application, and every time we need to compile from scratch it takes over two hours on a single core. Even with distributing the compilation out across over a hundred cores the fastest it can get down to is around 20 minutes.
Earlier quoted context omitted.
how come hundred cores is only speedup of ~6?
Linking in particular. At one stage, due to enabling LTO, our release build alone took over 20 minutes just to link. And linking cannot easily be parallelised (if at all? I'm not familiar with what the state of the art in linkers is).
There’s also a generics implementation on a branch of the go repo. I’m most curious how they perform on compilation speed assuming a big project makes decent use of generics. I doubt golang would merge anything that causes significant slowdown. And I don’t blame them, the only reason I don’t dread TypeScript dev given its slow compile times is you can typecheck async and strip the typing information for the hot reloa…
Problem with C++ template generics is that they are reinstantiated per type __per compilation unit__.
I think they can
* Use dynamic dispatch liberally - such that one instantiation per object size in order to avoid boxing. That said, I don't know how the experimental generics work. And this will obviously prevent some optimizations, notably escape analysis.
* defer compilation of generic code to the end i.e "just before linking" phase instead of eliminating duplicates at link time.
* Some kind of caching mechanism for generic code such that you `sed` the machine code / plan9 intermediate to replace it with type specialization wherever required - should work if you are willing to sacrifice some optimizations, As majority of time is spent in code generation. On the flip side, Go team can come up with different optimization strategy for that part of code because Go doesn't do many optimizations in current form.
I am no expert on compilers / optimization. But generics will obviously reduce the total code one needs to compile. And combined with some techniques I guess they can control compile times from regressing.