Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Featherweight Go

arxiv.org

Post reply on HN
Print view View original

21–30 of 169 posts

Re: Featherweight Go

#21

Post by ben-schaaf »

logicchains wrote: post #10
fyfy18 wrote: 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.

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

Re: Featherweight Go

#22

Post by dhash »

fyfy18 wrote: post #7
parhamn wrote: post #6

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…

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.

Switching off SBT to Bazel made writing scala so much more pleasant for this exact reason. Builds are 10x quicker, and the caching makes the initial build take 10 minutes, limited only by the speed of your internet connection!

Re: Featherweight Go

#23

Post by pjmlp »

cbolton wrote: post #14
pjmlp wrote: 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".

What about the irony of pjmlp dismissing something because it's based on an obscure language going as far back as 2001? :-)

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?

Re: Featherweight Go

#24

Post by jaco8 »

logicchains wrote: post #10
fyfy18 wrote: 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.

Just try Nim. It is fast.

Re: Featherweight Go

#25

Post by pjmlp »

jlouis wrote: post #8
pjmlp wrote: 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…

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.

Re: Featherweight Go

#26

Post by ainar-g »

From the conclusion:

  Featherweight Go is restricted to a tiny subset of Go.  We plan a model
  of other important features such as assignments, arrays, slices, and
  packages, which we will dub Bantamweight Go; and a model of Go’s
  innovative concurrency mechanism based on “goroutines” and message
  passing, which we will dub Cruiserweight Go.
Love the naming!

Re: Featherweight Go

#27

Post by eeh »

pjmlp wrote: 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".

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?

Re: Featherweight Go

#28

Post by ainar-g »

leetrout wrote: post #13

Info on the current implementation of generics in Go how to tryout the generics branch parhamn mentions is available at https://blog.tempus-ex.com/generics-in-go-how-they-work-and-...

That's the previous design based on contracts.

https://github.com/wenkokke/featherweight-go-gen

This one seems to be the new FGG one.

Re: Featherweight Go

#29

Post by eeh »

pjmlp wrote: post #25
jlouis wrote: post #8

Earlier quoted context omitted.

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…

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.

Re: Featherweight Go

#30

Post by ainar-g »

ben-schaaf wrote: post #21
logicchains wrote: post #10

Earlier quoted context omitted.

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

This is interesting. What techniques are you using? Pimpl? Custom, non-STL containers?
Post reply on HN