5 ms·

So, Go has message passing. Just like Erlang, since 1986. Only without per-process heaps, which make crashing processes safe. And without process linking and

by mietek 13y ago

So, Go has message passing. Just like Erlang, since 1986. Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake. But it's not enough to scorn the industry; Go's designers also look down their noses at academia. A modern, ML-derived static type system? Generics, which would enable the unwashed mashes to write their own `append`? Ain't nobody got time for that — wait, what? Oh, Rust does? Go's tooling is fantastic, and its pragmatism is commendable, but ignoring the last 30 years of programming language research is not.

sp332 13y ago
The only reason Go doesn't have generics yet is that Rob Pike hasn't found a system he likes. He's not against it being added in the future.
- mietek 13y ago
  I haven't seen him comment on generics in languages other than C, C++ and Java. See also below: https://news.ycombinator.com/item?id=5821027 https://news.ycombinator.com/item?id=5821027
  - sp332 13y ago
    My info came from this thread https://news.ycombinator.com/item?id=5792842 https://news.ycombinator.com/item?id=5792842 which, now that I think about it, appears to be a bunch of second-hand info about the golang mailing lists. rsc posts here about golang sometimes but I don't think he's mentioned generics specifically.
    - mietek 13y ago
      Perhaps Russ Cox will respond here: https://news.ycombinator.com/item?id=5796206 https://news.ycombinator.com/item?id=5796206
jmilkbal 13y ago
I recall the launch documentation specifically saying generics are "... a work in progress". Ignoring academic progress is easy when programming is far more often a trade than the application of computer science. I once saw a video comparing Go to an unnamed which matched or surpassed Go in all the ways the video compared the two. The language was Algol 60. Naturally, can't find the video now.
- mietek 13y ago
  I haven't seen the video, but here's the article: http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
  - jmilkbal 13y ago
    Yeah and this comment on another thread is probably spot on. http://news.ycombinator.com/item?id=5078276 http://news.ycombinator.com/item?id=5078276 I don't really find Go compelling, but I can understand the background some folks might be coming from that might make it compelling for them.
    - mietek 13y ago
      I completely agree with this comment.
enneff 13y ago
Erlang and Go are very different programming languages. They have a similar form of message passing, but the semantics are very different. Go's concurrency model still exists within a single process with a shared heap, which is very different to Erlang's model. > it includes null references, also known as Hoare's Billion Dollar Mistake. The very notion of null references being inherently bad is highly contentious. Just because someone gave an idea a catchy name, doesn't make it true. > Ain't nobody got time for that — wait, what? Oh, Rust does? Go and Rust have very different design goals. If you think Rust is more appropriate for you, use Rust. > ignoring the last 30 years of programming language research is not. This is a common refrain from Go haters, but it's really not true. Just because you don't do everything everyone else is doing doesn't mean you have ignored them. Go includes the language features we felt were necessary in a productive language. Your comment frames Go as this language that thumbs its nose at a lot of good ideas, but the reality is that every design decision has tradeoffs. If you don't have null pointers or generics, then you need a more complex type system. The Go designers may not have made all the decisions _you_ would have made, but they were not made in ignorance of the alternatives. And this leads back to the message of the original article: Go encourages the programmer to write simple code that is obviously correct. A more complex type system would detract from that goal.
- mietek 13y ago
  > Go's concurrency model still exists within a single process with a shared heap, which is very different to Erlang's model. I've already mentioned Go doesn't have per-process heaps, and I consider this a step backwards from shared-nothing message passing. I don't understand how can you argue that facilitating the threads-and-locks model leads to "simple code that is obviously correct". Writing correct multithreaded code is widely recognized to be difficult. > The very notion of null references being inherently bad is highly contentious. If by this you mean people keep[1] pointing[2] out[3] the problems with nulls, and other people keep ignoring them, then I fully agree. Otherwise, please direct me to a discussion offering a pro-null argument. For code to be correct in the presence of null references, the programmer must remember to check every nullable value of uncertain status, without support from the compiler. Alternatively, in a language with option types, only values explicitly marked as optional must be checked, and forgotten checks are pointed out by the compiler. Less code, more safety. Tell me again, how does allowing null references lead to "simple code that is obviously correct"? > If you don't have null pointers or [do have] generics, then you need a more complex type system. Certainly. More complexity for the language implementers; less complexity for the language users. 1. http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc... 2. http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-printable.pdf http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-prin... 3. http://www.ccs.neu.edu/racket/pubs/dissertation-cobbe.pdf http://www.ccs.neu.edu/racket/pubs/dissertation-cobbe.pdf
mwcampbell 13y ago
Is your criticism of Go based on actual experience using it, or simply the fact that it lacks certain features that you deem critical in a modern programming language?
- mietek 13y ago
  I enjoy using Go, otherwise I wouldn't waste energy discussing it.

by mietek 13y ago

sp332 13y ago

The only reason Go doesn't have generics yet is that Rob Pike hasn't found a system he likes. He's not against it being added in the future.

mietek 13y ago
I haven't seen him comment on generics in languages other than C, C++ and Java. See also below: https://news.ycombinator.com/item?id=5821027 https://news.ycombinator.com/item?id=5821027
- sp332 13y ago
  My info came from this thread https://news.ycombinator.com/item?id=5792842 https://news.ycombinator.com/item?id=5792842 which, now that I think about it, appears to be a bunch of second-hand info about the golang mailing lists. rsc posts here about golang sometimes but I don't think he's mentioned generics specifically.
  - mietek 13y ago
    Perhaps Russ Cox will respond here: https://news.ycombinator.com/item?id=5796206 https://news.ycombinator.com/item?id=5796206

jmilkbal 13y ago

I recall the launch documentation specifically saying generics are "... a work in progress". Ignoring academic progress is easy when programming is far more often a trade than the application of computer science. I once saw a video comparing Go to an unnamed which matched or surpassed Go in all the ways the video compared the two. The language was Algol 60. Naturally, can't find the video now.

mietek 13y ago
I haven't seen the video, but here's the article: http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
- jmilkbal 13y ago
  Yeah and this comment on another thread is probably spot on. http://news.ycombinator.com/item?id=5078276 http://news.ycombinator.com/item?id=5078276 I don't really find Go compelling, but I can understand the background some folks might be coming from that might make it compelling for them.
  - mietek 13y ago
    I completely agree with this comment.

enneff 13y ago

Erlang and Go are very different programming languages. They have a similar form of message passing, but the semantics are very different. Go's concurrency model still exists within a single process with a shared heap, which is very different to Erlang's model. > it includes null references, also known as Hoare's Billion Dollar Mistake. The very notion of null references being inherently bad is highly contentious. Just because someone gave an idea a catchy name, doesn't make it true. > Ain't nobody got time for that — wait, what? Oh, Rust does? Go and Rust have very different design goals. If you think Rust is more appropriate for you, use Rust. > ignoring the last 30 years of programming language research is not. This is a common refrain from Go haters, but it's really not true. Just because you don't do everything everyone else is doing doesn't mean you have ignored them. Go includes the language features we felt were necessary in a productive language. Your comment frames Go as this language that thumbs its nose at a lot of good ideas, but the reality is that every design decision has tradeoffs. If you don't have null pointers or generics, then you need a more complex type system. The Go designers may not have made all the decisions _you_ would have made, but they were not made in ignorance of the alternatives. And this leads back to the message of the original article: Go encourages the programmer to write simple code that is obviously correct. A more complex type system would detract from that goal.

mietek 13y ago
> Go's concurrency model still exists within a single process with a shared heap, which is very different to Erlang's model. I've already mentioned Go doesn't have per-process heaps, and I consider this a step backwards from shared-nothing message passing. I don't understand how can you argue that facilitating the threads-and-locks model leads to "simple code that is obviously correct". Writing correct multithreaded code is widely recognized to be difficult. > The very notion of null references being inherently bad is highly contentious. If by this you mean people keep[1] pointing[2] out[3] the problems with nulls, and other people keep ignoring them, then I fully agree. Otherwise, please direct me to a discussion offering a pro-null argument. For code to be correct in the presence of null references, the programmer must remember to check every nullable value of uncertain status, without support from the compiler. Alternatively, in a language with option types, only values explicitly marked as optional must be checked, and forgotten checks are pointed out by the compiler. Less code, more safety. Tell me again, how does allowing null references lead to "simple code that is obviously correct"? > If you don't have null pointers or [do have] generics, then you need a more complex type system. Certainly. More complexity for the language implementers; less complexity for the language users. 1. http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc... 2. http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-printable.pdf http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-prin... 3. http://www.ccs.neu.edu/racket/pubs/dissertation-cobbe.pdf http://www.ccs.neu.edu/racket/pubs/dissertation-cobbe.pdf

mwcampbell 13y ago

Is your criticism of Go based on actual experience using it, or simply the fact that it lacks certain features that you deem critical in a modern programming language?

mietek 13y ago
I enjoy using Go, otherwise I wouldn't waste energy discussing it.