Live data from Hacker News

Featherweight Go

arxiv.org

61–70 of 169 posts

Re: Featherweight Go

#61
post #3

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".

Why is that ironic?

Re: Featherweight Go

#62
post #42

Earlier 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?

If you model your gradle (or bazel, or maven, or sbt) project as many smaller sub-projects, then the build tool can run a pool of compiler processes in parallel. In the case above, the repo I compiled was broken down into 200 gradle sub-projects. Bazel builds tend to be finer-grained still.

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

#63
post #43

Earlier 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…

Hacker News law: In every thread about Go someone will bring up rust.

Don't mind.

Re: Featherweight Go

#64
post #53

Earlier 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

I work with a ~10k line project and it takes 60s to incrementally compile on a Ryen 3990X. Rust is great, but the compile times do need to improve :-)

Re: Featherweight Go

#65
post #52
post #29

Earlier 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…

> Go's popularity is due to author's employer.

Why isn't Dart seeing the same type of success?

Re: Featherweight Go

#67
post #52
post #29

Earlier 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…

Is Dart's lack of popularity in spite of its author's employer, then?

Re: Featherweight Go

#68
post #7

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.

It's harsh to say this is due C++ fault, more likely due development culture and desire to be cool by using all the new cool features, without understanding benefits vs price. I was running medium-sized C++ project that included full GUI library - everything compiled under 2 minutes (including tests) on a single core.

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

#69
post #8
post #3

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".

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…

I think this just highlights how massive a mistake the Go developers made not including generics from Day 1.

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

#70
post #54

Earlier 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…

You're commenting on a paper by expert programming language theorists describing a design that is both complex and (in some aspects) novel. Almost certainly an element of getting these people to work on it is Go's existing popularity, it's mentioned in the second sentence of the paper.

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.

Post reply on HN