Featherweight Go
arxiv.org
Featherweight Go
1–10 of 169 posts
Re: Featherweight Go
#2Is that a jab at Haskell in the very first paragraph?
> Today [Go] sits at position 12 on the Tiobe Programming
> Language Index (Haskell sits at position 41).
Re: Featherweight Go
#3The 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".
Re: Featherweight Go
#4Fingers crossed: hopefully this is a step towards generics in golang.
Up to now it always seems to have been one step forward, two steps back (or rather "wait another few versions")
Re: Featherweight Go
#5Is that a jab at Haskell in the very first paragraph? > Today [Go] sits at position 12 on the Tiobe Programming > Language Index (Haskell sits at position 41).
One of the authors, Philip Wadler, contributed heavily to the design of Haskell. So I presume it's friendly joking.
Re: Featherweight Go
#6There’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 reload.
Re: Featherweight Go
#7There’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.
Re: Featherweight Go
#8The 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 implementing generics for the full language.
Most languages which end up with type parametrization do so when the language is small and somewhat pliable. Neither Java nor Go did, even though both languages had plenty of prior work in the area. Hence, you have to "reconstruct" a world in which there is such a small language such that your experiments run fast.
Re: Featherweight Go
#9There's an upcoming talk by Philip Wadler on this paper on June 8 - http://chalmersfp.org/
YouTube channel where the talk will be streamed live - https://www.youtube.com/channel/UCiGOzKde1rlvzEB7J73gvrQ
Re: Featherweight Go
#10There’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.
>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.