The irony of going back to Featherweight Java, done in 2001. At least some work is being done, even if "This is the beginning of the story, not the end".
Featherweight Go
61–70 of 169 posts
Re: Featherweight Go
#62Earlier quoted context omitted.
How many lines/files/classes split over how many targets for that 10 minute build? I just compiled around 240k lines of scala split over around 200 gradle subprojects with gradle 6.5rc1 and scalac 2.12.11. Limited to 10 gradle workers. Took 4 minutes without the gradle build cache enabled.
What’s the trick to your faster compile times?
Also gradle 6.5 fixes a scala compilation performance regression that was introduced in gradle 6: https://github.com/gradle/gradle/issues/12591
Re: Featherweight Go
#63Earlier quoted context omitted.
"programmers have spoken, and they"...'ve done quite a lot of work to get the benefits of generics without language support. You can pretty much look at any large Go project (famously Kubernetes) and see a workaround of some shape or form.
Kubernetes has lots of workarounds - I’m not sure generics are the ones I’ve worried about the most. If I had to write a list of “tools I would have preferred to have”: 1. Perfect serialization libraries - Serde is the gold standard here, and IIRC the macro system from Rust is as important a part of it as the traits part. 2. Mutability of types in shared caches - to build efficient controller patterns you need fast a…
Don't mind.
Re: Featherweight Go
#64Earlier quoted context omitted.
I haven’t used Rust on any significantly sized project. Could you elaborate? Is it only slow to compile release builds?
I started learning rust as a quarantine project, and my <5000 line project takes ~10 seconds to do an incremental development build and 1-2 seconds to typecheck
Re: Featherweight Go
#65Earlier quoted context omitted.
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.
Go's popularity is due to author's employer. 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 proble…
Why isn't Dart seeing the same type of success?
Re: Featherweight Go
#66Re: Featherweight Go
#67Earlier quoted context omitted.
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.
Go's popularity is due to author's employer. 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 proble…
Re: Featherweight Go
#68Earlier 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.
Formula known for years: keep it simple, minimal template (ab)use and know what you are putting in .h/.cpp files. Cramming everything into headers hoping compiler will inline stuff is a bed time story. Also, your build system will be grateful knowing that every compilation unit is independent as possible; it will take less time to calculate dependencies and will easily distribute compilation across cores, if requested.
Re: Featherweight Go
#69The irony of going back to Featherweight Java, done in 2001. At least some work is being done, even if "This is the beginning of the story, not the end".
I don't think this is so ironic after all. Featherweight Java is an idealized language, small enough for doing experiments. These experiments often involve the necessity of a formal proof. But being a small language, still capturing the crux of the full language, greatly simplifies the problem space. Featherweight Go serves the same purpose: find the core. Give the core generics. Then you have a good chance at implem…
It was a mistake in Java that they corrected with a lot of pain. It is a mistake in Go they are going to correct and most likely with a lot of pain. If they cannot do it seamlessly it may end up being a Python 2/3 platform split.
Those who fail to learn from history are doomed to repeat it.
Re: Featherweight Go
#70Earlier quoted context omitted.
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.
Yet, they acknowledged it was a mistake not to consider them. > 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…
If I understand you right, you are suggesting that instead of doing what they are doing now, they should have just used an existing design from your list, right from the beginning?
Is there any specific design from your list that you think would have been good to use in Go? Or, do you think it would have been better to have a less-capable generics implementation available right away instead of a more-capable one later?
For example the one you mention the most (Java) requires code duplication to work with 32 and 64 bit floats. I think even the previous proposals that have been rejected for Go have at least had that ability.