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

161–169 of 169 posts

Re: Featherweight Go

#161

Post by Ericson2314 »

lazyjones wrote: post #90
Ericson2314 wrote: post #80

Earlier quoted context omitted.

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.

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

It's not hostile towards this reader (me). It's perfectly appropriate. I would be annoyed if they weren't there.

Re: Featherweight Go

#162

Post by pjmlp »

throwaway34241 wrote: post #158
pjmlp wrote: post #145

Earlier quoted context omitted.

As proven by the lack of progress, that invitation has just political value, it allows posts like yours when these discussions take place. For example, while Valhalla has taken several years so far, OpenJDK team has experimental builds that you can go and play around with value types in Java. Where are the experimental builds for generics support in Go?

> For example, while Valhalla has taken several years so far, OpenJDK team has experimental builds that you can go and play around with value types in Java. Actually Valhalla is pretty interesting to think about. For what I'm currently working on, the inability to have a list of points without individually heap-allocating each one makes a language much more of a non-starter than the lack of user-defined parameterized…

The difference being that Java teams deliver language improvements and go on the stand acknowledging where to improve and setting roadmaps, Go not so much.

Even stuff like error handling improvements and type alias were almost shot down.

Re: Featherweight Go

#163

Post by benhoyt »

tptacek wrote: post #148
pcwalton wrote: post #114

Earlier quoted context omitted.

I went out of my way to make the point without condescension. Evidently I didn't succeed, and I'm sorry for that! Let me put it another way: Virtually all languages that have become popular recently have done so because of the backing of some large organization or another. There was a time when languages like Perl, Python, and PHP could arise out of basically nowhere and become popular. That time is gone, and now lan…

After a week (my first week, to be fair) of hacking on a serious Rust codebase, I'll give you one reason lack of generics might have been a marketing win for Go: I have never appreciated Go's compiler speed more than I do now. But the bigger problem is just that Rust programmers use generics absolutely everywhere (my early impression is you basically can't avoid it, because of lifetimes), and it simply does make ever…

What are your complaints about Go? I'm curious to know whether they match mine.

Re: Featherweight Go

#164

Post by throwaway34241 »

pjmlp wrote: post #162
throwaway34241 wrote: post #158

Earlier quoted context omitted.

> For example, while Valhalla has taken several years so far, OpenJDK team has experimental builds that you can go and play around with value types in Java. Actually Valhalla is pretty interesting to think about. For what I'm currently working on, the inability to have a list of points without individually heap-allocating each one makes a language much more of a non-starter than the lack of user-defined parameterized…

The difference being that Java teams deliver language improvements and go on the stand acknowledging where to improve and setting roadmaps, Go not so much. Even stuff like error handling improvements and type alias were almost shot down.

> The difference being that Java teams deliver language improvements

Sure, I think it's fair to say they've focused a lot more on implementation and library changes and not language changes up until recently. Things like rewriting the compiler from C, improving code generation / escape analysis / GC, more platform / architecture support, improving the standard library, getting a reasonable package manager, etc.

So it seems a little premature to read some secret anti-generics stance into it (and it not just being a matter of priorities) since there were all these other areas that they were also way behind Java in.

After package management was in generics started showing signs of life again, so it all seems reasonably consistent with the Go team just wanting to clear other stuff off their plate first before tackling it. Hopefully we see it in a similar timeframe to major Java/C++ features now that it's being worked on more.

If there's any silver lining the actual proposals seem pretty ambitious, seems like they want to enable a lot more than just new type safe collections if they add the feature.

Re: Featherweight Go

#165

Post by zdragnar »

therealdrag0 wrote: post #144
zdragnar wrote: post #133

Earlier quoted context omitted.

Functions can be given semantic names (I.e. have meaning); block statements cannot. If writing a function that can take an array or slice of any type of data requires providing a generic argument (I.e. so you can specify that the function returns a slice of the same type of data as it was given), then you can name it "reverse" if it reverses the array, write it only once, and every timr you use it, you read "reverse"…

Sorry I meant to say “why do genetics make things harder to read?”. Tbh I can’t tell if you’re responding to that or not

I did misread your post, but I will also say that generics are a double edged sword when it comes to readability. Needing to declare genetic types in function signatures can add irrelevant detail and heavy syntax. For example, look at the interpreter interface in this typescript file:

https://github.com/gcanti/io-ts/blob/master/src/Schema.ts#L2...

Granted, genetics don't need to be done that way, but it is among the more common and popular approaches. The type information is tangled up in the implementation, making focusing on either more challenging. Perhaps we need modes for syntax highlighting- one for types, one for implementation?

Re: Featherweight Go

#166

Post by jlouis »

lazyjones wrote: post #40
jlouis wrote: post #35

Earlier quoted context omitted.

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.

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

Well, some journals have demanded proof assistant-level proofs of the work they present. This helps the rigor of the notation a lot since you can't cheat on the proof assistant, and if you confuse it, you are in trouble :)

The problem is that getting the notation right is actually quite hard. People write, to the best of their effort, to make the description succinct and understandable. But the notation is pliable, in the same way much mathematics is written: it isn't as rigorous as we would like.

Writing the same thing in regular prose is much much harder and there are many more ways things can go wrong.

So the state-of-the-art demands formal proof which can be verified by a machine. And it shows in the precision of the notation, which often leaves little to no room for wrong interpretation.

Re: Featherweight Go

#167

Post by thesz »

skybrian wrote: post #115
voidfunc wrote: post #69

Earlier quoted context omitted.

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.

It's not at all clear that it was a mistake. Go has had eight years of being one of the more successful languages. If they had tried implementing generics right away, it may have taken longer and it's unclear whether Google would have supported the work for so long? Maybe the timing would have been different enough that they didn't succeed, or the lack of experience would have resulted in a design that's worse? It's…

It was successful due to massive amount of money spent by Google.

Because there were languages that are much better suited for what Go was designed for. To name a few: Erlang (concurrency that is better than Go's, "channels" and types on par with Go with Dialyzer), Haskell (thread concurrency better than Erlang's, channels, transaction memory, etc and types well beyond Go) and many others.

Go was successful despite mistakes.

Re: Featherweight Go

#168

Post by sseth »

The talk by Philip Wadler is one of the most insightful I have heard : 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.

Re: Featherweight Go

#169

Post by [deleted] »

TheDong wrote: post #105

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

[deleted]
Post reply on HN