
Featherweight Go - 4ad
https://arxiv.org/abs/2005.11710
======
journeeman
There's an upcoming talk by Philip Wadler on this paper on June 8 -
[http://chalmersfp.org/](http://chalmersfp.org/)

YouTube channel where the talk will be streamed live -
[https://www.youtube.com/channel/UCiGOzKde1rlvzEB7J73gvrQ](https://www.youtube.com/channel/UCiGOzKde1rlvzEB7J73gvrQ)

------
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!

~~~
kyrra
> 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.

Required better for mobile.

~~~
bo1024
And desktop, thank you.

------
parhamn
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 reload.

~~~
fyfy18
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.

~~~
logicchains
>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.

~~~
Iwan-Zotow
how come hundred cores is only speedup of ~6?

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

~~~
uluyol
I believe that ThinLTO does most of its work in parallel and provides most of
the benefit of LTO.

------
TheDong
> Whereas most programming languages use nominal subtyping, Go is unique among
> mainstream typed programming languages in using structural subtyping.

I thought typescript also used structural subtyping? i.e. in typescript I can
define:

    
    
        interface Stringer {
          String: () => string
        }
        function takesStringer(s: Stringer) {}
    

And now I can call takesStringer with any class that happens to have a
String() method.

This seems to match structural subtyping in go.

Am I missing some reason that this isn't structural subtyping as referred to
in the paper? Do they mean to say that typescript isn't a "mainstream typed
programming language"?

~~~
ImprobableTruth
It absolutely does. It doesn't have any nominal typing at all, so even classes
are compared structurally.

I assume they're not considering it because typescript compiles to javascript,
so it doesn't have the problem Go faces of how to generate code for its
generics. The wording is definitely weird though.

------
todotask
I'm curious on this part, "Although monomorphisation is widely used, we are
one of the first to formalise it.", which are other language had formalise as
well?

------
sseth
The talk by Philip Wadler is one of the most insightful I have heard :
[https://www.youtube.com/watch?v=Dq0WFigax_c](https://www.youtube.com/watch?v=Dq0WFigax_c)

In brief, they are following a process of stripping Go to the most basic
possible syntax, and then adding generics (Featherweight). Then they will add
more features back and build up to the full language, ending with
Cruiserweight where channels will be addressed.

The generics proposal builds on interfaces rather than contracts. Wadler sees
Go occupying a unique space in terms of supporting "open supertypes" in the
sense that in Go we do not have to declare a struct to be of a particular
interface type it is automatically derived based on the methods defined on the
struct. This allows a proposal which allows Go to be extended tp solve the
"expression problem" first defined by Wadler in 98.

I really hope these beautiful ideas turn out to be workable - I am sure Go
will gain immensely if they are well thought out.

------
corty
Fingers 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")

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

~~~
jlouis
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.

~~~
pjmlp
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.

~~~
eeh
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.

~~~
pjmlp
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 problems to fix in the language.

[https://blog.golang.org/why-generics](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.

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

~~~
pcwalton
Dart's lack of popularity is indeed in spite of the Google backing. I
basically see two reasons. First, though Lars Bak has an impressive pedigree,
Strongtalk and V8 aren't as well-known as Plan 9 and Unix. Moreover, rightly
or wrongly, Dart had the appearance of "Google's attempt to kill JS", which
neither endeared it to Web developers (who were riding a wave of JavaScript
hype at the time) nor to other browser manufacturers (who were growing
increasingly distrustful of Google's initiatives).

------
bmichel
The syntax really makes me think to Zig -
[https://ziglang.org/documentation/master/#Introducing-the-
Co...](https://ziglang.org/documentation/master/#Introducing-the-Compile-Time-
Concept). I'd be curious to know if the authors of this paper have looked at
it.

------
leetrout
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-...](https://blog.tempus-
ex.com/generics-in-go-how-they-work-and-how-to-play-with-them/)

~~~
4ad
That's from the previous generics proposal, substantially different from this
one.

~~~
jhoechtl
This is the intersting discussion. What of the two proposals will receive the
Go authors blessing? Isn't the arxiv version just a Guerilla attempt?

~~~
bmichel
The former proposal was made by 2 members of the Go core team. And they are
also in the team of the latter proposal. So, no, the first proposal wasn't
good enough for the Go authors and the new proposal is in no way a guerilla
attempt.

~~~
jhoechtl
Thanks for clarification. I followed the discussion in [https://go-
review.googlesource.com/c/go/+/187317](https://go-
review.googlesource.com/c/go/+/187317) loosely, thought that this is the only
way to go and wasn't aware of a second investigation stream.

------
wwarner
Go generics without introducing contracts! This is exactly what I was hoping
for!

------
apatheticonion
For anyone interested in seeing what's possible with Generics in Go - Here is
an online playground that uses the browser-based playground and a WASM
compiler to run the generics proposal (in browser).

The example includes a simple generic `Filter` function

[https://ccbrown.github.io/wasm-go-
playground/experimental/ge...](https://ccbrown.github.io/wasm-go-
playground/experimental/generics/#A4Qwxg1iDmCmAEBbEBLAdgKAwMwK5rHgDEUAbAF1gCcAKcgT2AQBUBKeG0gbQF1mAaeMHh4CNAG7w28AEYB7OaXa9m8AN4YAkHNzlgu+AC4AvPBVqAvlq3Y5VeAH1Bkk/Cog0ceKXVbNVWABnXAojU2AJVj8UbDcgkPJ4Y1NyKlwEDU1NeBz4HT0DUxBgJjQAExp8/XJnKKyrTQatAPJcKjQ83WqMKxx8QmR0GnZMwLCzHkDU9Gg1ACIQOcE5mSX4ObA5ps1Y1xIKahpAwVEwCXgpqhn2eUVfLJj4SWT11fuslraO7BBSQNg/BZ4FpcvB/LBWu14Kl0loLHUbHZHM5xu5PAhYplNMArmhyKQ0JE4T0MEA===)

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

~~~
dddbbb
One of the authors, Philip Wadler, contributed heavily to the design of
Haskell. So I presume it's friendly joking.

------
pl1315
PLZ don't. Let's keep it C-like

~~~
jhoechtl
May be an attempt to silence the Rust-fanbois because of the touted old-
fashionism of Go. So let's sprinkle some ML topping an be good.

------
lazyjones
Thanks for reminding me how the rampant abuse of nearly unreadable
mathematical notation for things that can be easily expressed in concise
natural language contributed to (voluntarily) shortening my academic career.

But more seriously, it's interesting how this produces publications before
actual implementations.

~~~
jlouis
Closer to logic. There is a straightforward rewrite into prolog if you want a
program. Or one of the proof assistants.

The notation is abused though. Try looking up some of the work by Guy L.
Steele in the recent years.

~~~
lazyjones
> _Closer to logic. There is a straightforward rewrite into prolog if you want
> a program._

Journal papers usually don't get rewritten into Prolog or fed into proof
assistants. They're read by human beings. I've long suspected (and colleagues
used to "joke" about it) that excessive use of mathematical notation is just
employed to impress and/or confuse peer reviewers into just accepting the
paper instead of trying to comprehend it first.

~~~
Ericson2314
Stop trying to justify your own ignorance.

The sequent calculus is great—I am far from an expert and for many papers I
can skip the text at first, read the sequents, and then just go back to the
prose only if I have specific questions. No prolog conversion needed.

As programers, we should be able to _read_ , not just write, formal languages,
and appreciate the value of the precision they provide.

~~~
lazyjones
> _Stop trying to justify your own ignorance._

I am not ignorant. I tried to rationalize this in the beginning too. It's just
hostile towards the reader.

> _As programers, we should be able to read, not just write, formal languages,
> and appreciate the value of the precision they provide._

We should also be able to see where they are appropriate and where not.

~~~
Ericson2314
It's not hostile towards this reader (me). It's perfectly appropriate. I would
be annoyed if they _weren 't_ there.

------
infinity0
> The goal is to define a data type by cases, where one can add new cases to
> the data type and new functions over the data type, without recompiling
> existing code, and while retaining static type safety.

Not sure what real problem this is solving. In practise you don't just add new
cases, you delete some cases, and you re-add different cases later. Two
different people might add two different cases in parallel with each other.
Oops, now you have to re-compile anyway.

------
peter_d_sherman
Suggestion: While your paper is very intellectual and I laud that, perhaps
what would work better for mass uptake is to create your own programming
language around the concepts you propose, and let people try that language.
You could call this language "Featherweight Go" if you wish, but perhaps it
would be better to call it something else entirely, and simply state that that
this new language was inspired by Go.

This choice comes with potential business, legal, and other ramifications, for
example, should Google get all of the benefit, in terms of fame, goodwill,
users and other intrinsic bonuses from the work you've done; or could you
profit (if that was your goal) if you were to create your own company around
this new language?

You see, that's what I mean by potential business and legal issues.

Oftentimes, people who are employed by other people work extremely hard on
academic pursuits, such as academic papers, yet their work is never adequately
rewarded, compensated, or even appreciated.

Which is why I suggest you create your own language and possibly your own
company around that language. Because otherwise you'll never know nor
understand the true economic value of what you've created, and you might spend
an eternity trying to convince people who are of lesser intelligence to read
your paper, whereas they could be using, downloading, telling their friends
about the great new language you created; and maybe even paying you money, if
you played your cards right...

Note that I am not suggesting you go this route (it's your decision, maybe you
just want to bring better free open source software to the open source
community and that's highly laudable), all I'm saying is, you might be on your
bed on your 85th birthday, and you might look back at your life, and you might
wonder "boy, I wonder what would have happened had I tried to start a company
around this set of ideas; I wonder what would have happened if I had taken the
road not travelled.."

That's all I'm trying to say...

Nothing more, nothing less.

Your choice.

Make it wisely.

Your paper shows tons of intellect.

~~~
platinumrad
What are you talking about... Two members of the Go team are on the author
list.

~~~
peter_d_sherman
If I were them, I'd leave Google and start my own programming language
company. I can't speak for them of course, but that's what I would do if I
were in their position.

