5 ms·

To this day, I don't understand why Google made Go instead of working off of SML. While the go ecosystem is better due to the millions of man-hours poured into

by hajile 7y ago

To this day, I don't understand why Google made Go instead of working off of SML. While the go ecosystem is better due to the millions of man-hours poured into it, the language is inferior in every way. To elaborate, CML is better than golang's channels and isn't broken (requiring mutexes over channels to avoid breaking qualifies as broken). SML syntax is simpler to learn, but still offers much more powerful abstractions with pattern matching. SML uses options instead of null pointer exceptions. Hindley-Milner types are clearly superior to Golang's type system (especially things like empty interface). SML has had generics for almost 25 years now while go languishes. SML has immutable data structures and they are the default for almost everything. Golang has implicit types, but SML's implicit types are much better -- especially structurally-typed records. SML's modules are amazing and simply have no comparison in go. Finally, SuccessorML is doing work toward adding a few new features to the language (for example, module type classes), but the language has an actual specification that anyone can implement (and many have) rather than the implementation effectively being the spec.

mumblemumble 7y ago
Your elaboration could as well be described as a list of language features that SML has, and that Go's developers have publicly said are undesirable.
- hajile 7y ago
  I know they simply cannot have several of them due to the language design choices. I know they are working on some like generics. Others like sounder typing, better type inference, and functioning concurrency primitives seem like sound goals for any language that already has those things. Which of those features have they said the don't want?
zelly 7y ago
PL theoretic superiority was not the design goal. Golang was intended to be a pragmatic, bread-and-butter language for large teams with churn. Bad code needs to be screamingly obvious. It also needs to be very easy to learn. FP langs can never fill this role because it's fundamentally more difficult to think in FP terms than imperative terms. Maybe for small internal projects. (But if it's successful, it'll get rewritten in Go/Java/C++; people simply can't handle FP.)
- cultus 7y ago
  FP is easier to reason about because humans have a hard time with implicit state. Just because you don't know it doesn't mean its hard. That's why functional-ish things like Redux are taking off, and every new language except Go has incorporated significant functional features.
  - zelly 7y ago
    > Just because you don't know it doesn't mean its hard I spent a long time learning Haskell and have written enough Clojure especially to safely call myself an expert in it. I obsess over languages (not proud of that btw). FP is hard. It's too hard for most programmers. A lot of people avoid saying this but it's true. It's hard in a way that you can't fix with experience. That's why the tooling for it sucks. Suppose you want to make an IDE or even an API for your product. Do you want a lot of people to use it? Then you use ${BLUB}. Heavily abstract stuff dies. Look at Tensorflow vs. Pytorch. Tensorflow 1.0 had this wonderful functional, declarative, immutable way of writing neural networks, but people protested because they couldn't mutate variables in a for loop and have it automagically autodifferentiate. Abstraction kills network effects. > every new language except Go has incorporated significant functional features None of them come close to the semantics of FP (except Scala, but its negative adoption rate kind of proves my point). They all allow side effects which breaks the first rule. You can say they stole some of the convenient syntactic sugar from FP, like pattern matching and lambdas (e.g., Kotlin and Rust). Great. So what advantage do FP langs have now? Making it hard to do I/O? Category theory? Having unmaintained compilers?
- hajile 7y ago
  Haskell was designed for theory. SML was designed to combine being pragmatic and easy to teach (not only the language, but how to implement). Other than syntax, SML's fundamental nature is much closer to Rust (with a GC and simpler syntax and without lifetimes, macros, or traits). In any case, let's look at those haskell "hard parts" and contrast them. Haskell treats everything as immutable. SML is NOT always immutable. It simply adds some (very sane) constraints on where mutation can occur which makes reasoning about mutation easier. Haskell forbids side effects. This is an illusion of course (you'll find high-performance libraries often use the unsafe IO stuff). SML embraces side effects though general practice is to restrict them to specific modules to make the program easier to reason about (a good practice in pretty much all languages). You can definitely write imperative pieces of code if it improves performance. Haskell is lazily evaluated. This can be a performance boon for some things, but is a bane to find and fixing performance bottlenecks. SML is eagerly evaluated like most other languages. Haskell is crazy for typeclasses. They use them everywhere, but they often complicate actually using things. SML does not have type classes, but SucessorML (the next version) is looking at adding module typeclasses instead. These will have most of the same features, but because they are in the module instead, it should put a big limit on their abuse and make their use easier to track. SML's big "ivory tower" ideas are: powerful type system, pattern matching, option types everywhere, first-class functions, and modules (essentially as a replacement for classes though that is not entirely true). SML really is the whole package. The best parts of functional programming combined with the best parts of mainstream languages (restricted to the "good" subset) all tied up in a language definition that manages to reduce the amount of syntax compared to something like Java or Go while increasing the amount of power while at the same time not turning into an unreadable mess (it's pretty hard to write unreadable SML code).
atombender 7y ago
I think it's a bit misleading to say that "Google developed Go", as if it were some kind of strategic play. Go wasn't a top down product; it was created by the engineers who had the idea to create a new language, and hope to make it a popular one at Google. But even today, Go is not one of Google's top internal languages; Java and C++ apparently still dominate on the backend. As for why Go isn't SML, just look at the original team. They had a background in languages like C (Ken Thompson , Oberon and Modula (Robert Griesemer) and Aleph, Newsqueak, and Limbo (Rob Pike). Nobody on the core Go team have ever been fans of functional languages or of complex type systems.
msvan 7y ago
I look at go and I see an admission of defeat in programming language design. The central idea of go is that the way to have a language that is productive in the large is to impair it as much as possible. Unfortunately this idea seems to have been wildly successful.
- mhh__ 7y ago
  Google hires the best engineers who somehow can't be trusted to use a modern programming language if Rob Pikes words are to be taken literally
  - CobrastanJorji 7y ago
    Have you SEEN what happens when you give an extremely clever engineer some rope?
    - mumblemumble 7y ago
      Recently, in the wake of a moment of lucidity, I decided it was time to nope out of using cats, or anything like it, in my Scala code. It's like that one year that I got myself addicted to Minecraft.
    - neilparikh 7y ago
      Haven't we got the languages swapped in this comparison? I'd argue SML gives you less footguns, since the typechecker is much more restrictive about what kind of code it will allow, whereas Go will allow you to write code that has a nil error, for example.
SaxonRobber 7y ago
Because Rob Pike is a hack
- dang 7y ago
  Could you please stop posting unsubstantive comments to HN? Also, personal attacks are not ok here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
ajb 7y ago
The go team had an explicit goal of very fast compilation - including low scaling with the number of files (avoiding the Nfiles^2 that C++ tends to have because of include files). It's not obvious to me that this is compatible with SML's module system and Hindley-Milner, although I'd love to be proved wrong.
- sikan 7y ago
  OCaml compilation is just as fast as Go.
  - deleted 7y ago
    [deleted]
  - ajb 7y ago
    Great. SML compilation was noticeably slow last time I used it, but maybe that's changed.
    - hajile 7y ago
      Ocaml has way more paid development time than SML. MLton guys can't focus on everything, so they've decided final performance is more important than compile time. SML was designed with few ambiguities to the syntax (simpler for students to implement), so theoretical compile times could be very low indeed. If they had Google money behind them, compile times would definitely be better The other thing is whole-program optimization vs method-at-a-time. A lot of SML devs use New Jersey for fast compiles when developing and MLton when deploying. You can get rid of a ton of stuff in functional languages once you do a whole program compile, but that will always take more time. MLton could really use a second, faster compiler, but I'm just appreciative of all their effort to make the current compiler output fast code.
Jtsummers 7y ago
Because Go traces its lineage to Limbo and Alef (among others). Rob Pike worked on Limbo, in particular, and was present when Alef was being developed. Those languages have some direct inspiration for the concurrency model in Go (along with CSP which they all trace to). It makes sense to continue down a path they'd already charted and believed in.
burntsushi 7y ago
> (requiring mutexes over channels to avoid breaking qualifies as broken) I've used Go channels plenty of times without any explicit mutexes, so I'm not sure what you're talking about here.
- hajile 7y ago
  https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/ https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... I'd add that these aren't just theoretical (EDIT: I forgot that his article linked to this paper). https://songlh.github.io/paper/go-study.pdf https://songlh.github.io/paper/go-study.pdf Go doesn't actually implement CSP correctly. That would require some changes. This provides a high-level overview. https://stackoverflow.com/questions/32651557/golang-main-difference-from-csp-language-by-hoare https://stackoverflow.com/questions/32651557/golang-main-dif... Threading is hard and gets a lot harder when you introduce pointers or mutable data. This is even harder when your type system is terrible. I suspect that Go trying to solve this would result in a language that looked a lot like Rust with a Garbage Collector.
  - burntsushi 7y ago
    You've gone from "Go channels are broken because they require mutexes to use" to "Go doesn't implement CSP correctly." The former is demonstrably not true and the latter is academic. (Although you did reference a good study on concurrency bugs in Go, but this seems unrelated to either of your claims.) You aren't doing your argument any favors when you're so hyperbolic. Go channels are manifestly not "broken." > I suspect that Go trying to solve this would result in a language that looked a lot like Rust with a Garbage Collector. And yet you honestly can't understand why the designers of Go didn't go down that path? Rust is significantly more complex than Go and much harder to learn.
    - jtolds 7y ago
      The latter being academic doesn't mean it is not also of practical import to correct usability.
nextos 7y ago
I'd add that the SML dialect AliceML, influenced by Mozart/Oz, has incredibly nice lazy, concurrent, distributed, logic, etc. extensions. It's really sad it's abandonware: https://www.ps.uni-saarland.de/alice/ https://www.ps.uni-saarland.de/alice/
- ptrott2017 7y ago
  ALiceML is indeed a rather nice set of extensions to SML. If you pull the code from here: https://github.com/aliceml/aliceml-alice https://github.com/aliceml/aliceml-alice and make sure you have all the dependencies installed first, it does build on linux and its fun to play with. I am currently working on a AliceML derived language and if there is any interest I'll post a note on HN - once its a bit futher down the line.
  - nextos 7y ago
    Please do post once it's ready!
erk__ 7y ago
This reminds me of a paper in the latestest edition of sigbovik [0], "Applications of Standard ML at Google" [1]. It could also use some newer things like better support for unicode strings. [0]: http://sigbovik.org/2019/proceedings.pdf http://sigbovik.org/2019/proceedings.pdf [1]: Page 170, Also here: https://github.com/solb/sigbovik/blob/master/papers/SIGBOVIK_2019_paper_19.pdf https://github.com/solb/sigbovik/blob/master/papers/SIGBOVIK...
- cannam 7y ago
  Oof! Especially cruel is the "andalso" in the closing sentence.

by hajile 7y ago

mumblemumble 7y ago

Your elaboration could as well be described as a list of language features that SML has, and that Go's developers have publicly said are undesirable.

hajile 7y ago
I know they simply cannot have several of them due to the language design choices. I know they are working on some like generics. Others like sounder typing, better type inference, and functioning concurrency primitives seem like sound goals for any language that already has those things. Which of those features have they said the don't want?

zelly 7y ago

PL theoretic superiority was not the design goal. Golang was intended to be a pragmatic, bread-and-butter language for large teams with churn. Bad code needs to be screamingly obvious. It also needs to be very easy to learn. FP langs can never fill this role because it's fundamentally more difficult to think in FP terms than imperative terms. Maybe for small internal projects. (But if it's successful, it'll get rewritten in Go/Java/C++; people simply can't handle FP.)

cultus 7y ago
FP is easier to reason about because humans have a hard time with implicit state. Just because you don't know it doesn't mean its hard. That's why functional-ish things like Redux are taking off, and every new language except Go has incorporated significant functional features.
- zelly 7y ago
  > Just because you don't know it doesn't mean its hard I spent a long time learning Haskell and have written enough Clojure especially to safely call myself an expert in it. I obsess over languages (not proud of that btw). FP is hard. It's too hard for most programmers. A lot of people avoid saying this but it's true. It's hard in a way that you can't fix with experience. That's why the tooling for it sucks. Suppose you want to make an IDE or even an API for your product. Do you want a lot of people to use it? Then you use ${BLUB}. Heavily abstract stuff dies. Look at Tensorflow vs. Pytorch. Tensorflow 1.0 had this wonderful functional, declarative, immutable way of writing neural networks, but people protested because they couldn't mutate variables in a for loop and have it automagically autodifferentiate. Abstraction kills network effects. > every new language except Go has incorporated significant functional features None of them come close to the semantics of FP (except Scala, but its negative adoption rate kind of proves my point). They all allow side effects which breaks the first rule. You can say they stole some of the convenient syntactic sugar from FP, like pattern matching and lambdas (e.g., Kotlin and Rust). Great. So what advantage do FP langs have now? Making it hard to do I/O? Category theory? Having unmaintained compilers?
hajile 7y ago
Haskell was designed for theory. SML was designed to combine being pragmatic and easy to teach (not only the language, but how to implement). Other than syntax, SML's fundamental nature is much closer to Rust (with a GC and simpler syntax and without lifetimes, macros, or traits). In any case, let's look at those haskell "hard parts" and contrast them. Haskell treats everything as immutable. SML is NOT always immutable. It simply adds some (very sane) constraints on where mutation can occur which makes reasoning about mutation easier. Haskell forbids side effects. This is an illusion of course (you'll find high-performance libraries often use the unsafe IO stuff). SML embraces side effects though general practice is to restrict them to specific modules to make the program easier to reason about (a good practice in pretty much all languages). You can definitely write imperative pieces of code if it improves performance. Haskell is lazily evaluated. This can be a performance boon for some things, but is a bane to find and fixing performance bottlenecks. SML is eagerly evaluated like most other languages. Haskell is crazy for typeclasses. They use them everywhere, but they often complicate actually using things. SML does not have type classes, but SucessorML (the next version) is looking at adding module typeclasses instead. These will have most of the same features, but because they are in the module instead, it should put a big limit on their abuse and make their use easier to track. SML's big "ivory tower" ideas are: powerful type system, pattern matching, option types everywhere, first-class functions, and modules (essentially as a replacement for classes though that is not entirely true). SML really is the whole package. The best parts of functional programming combined with the best parts of mainstream languages (restricted to the "good" subset) all tied up in a language definition that manages to reduce the amount of syntax compared to something like Java or Go while increasing the amount of power while at the same time not turning into an unreadable mess (it's pretty hard to write unreadable SML code).

atombender 7y ago

I think it's a bit misleading to say that "Google developed Go", as if it were some kind of strategic play. Go wasn't a top down product; it was created by the engineers who had the idea to create a new language, and hope to make it a popular one at Google. But even today, Go is not one of Google's top internal languages; Java and C++ apparently still dominate on the backend. As for why Go isn't SML, just look at the original team. They had a background in languages like C (Ken Thompson , Oberon and Modula (Robert Griesemer) and Aleph, Newsqueak, and Limbo (Rob Pike). Nobody on the core Go team have ever been fans of functional languages or of complex type systems.

msvan 7y ago

I look at go and I see an admission of defeat in programming language design. The central idea of go is that the way to have a language that is productive in the large is to impair it as much as possible. Unfortunately this idea seems to have been wildly successful.

mhh__ 7y ago
Google hires the best engineers who somehow can't be trusted to use a modern programming language if Rob Pikes words are to be taken literally
- CobrastanJorji 7y ago
  Have you SEEN what happens when you give an extremely clever engineer some rope?
  - mumblemumble 7y ago
    Recently, in the wake of a moment of lucidity, I decided it was time to nope out of using cats, or anything like it, in my Scala code. It's like that one year that I got myself addicted to Minecraft.
  - neilparikh 7y ago
    Haven't we got the languages swapped in this comparison? I'd argue SML gives you less footguns, since the typechecker is much more restrictive about what kind of code it will allow, whereas Go will allow you to write code that has a nil error, for example.

SaxonRobber 7y ago

Because Rob Pike is a hack

dang 7y ago
Could you please stop posting unsubstantive comments to HN? Also, personal attacks are not ok here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

ajb 7y ago

The go team had an explicit goal of very fast compilation - including low scaling with the number of files (avoiding the Nfiles^2 that C++ tends to have because of include files). It's not obvious to me that this is compatible with SML's module system and Hindley-Milner, although I'd love to be proved wrong.

sikan 7y ago
OCaml compilation is just as fast as Go.
- deleted 7y ago
  [deleted]
- ajb 7y ago
  Great. SML compilation was noticeably slow last time I used it, but maybe that's changed.
  - hajile 7y ago
    Ocaml has way more paid development time than SML. MLton guys can't focus on everything, so they've decided final performance is more important than compile time. SML was designed with few ambiguities to the syntax (simpler for students to implement), so theoretical compile times could be very low indeed. If they had Google money behind them, compile times would definitely be better The other thing is whole-program optimization vs method-at-a-time. A lot of SML devs use New Jersey for fast compiles when developing and MLton when deploying. You can get rid of a ton of stuff in functional languages once you do a whole program compile, but that will always take more time. MLton could really use a second, faster compiler, but I'm just appreciative of all their effort to make the current compiler output fast code.

Jtsummers 7y ago

Because Go traces its lineage to Limbo and Alef (among others). Rob Pike worked on Limbo, in particular, and was present when Alef was being developed. Those languages have some direct inspiration for the concurrency model in Go (along with CSP which they all trace to). It makes sense to continue down a path they'd already charted and believed in.

burntsushi 7y ago

> (requiring mutexes over channels to avoid breaking qualifies as broken) I've used Go channels plenty of times without any explicit mutexes, so I'm not sure what you're talking about here.

hajile 7y ago
https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/ https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... I'd add that these aren't just theoretical (EDIT: I forgot that his article linked to this paper). https://songlh.github.io/paper/go-study.pdf https://songlh.github.io/paper/go-study.pdf Go doesn't actually implement CSP correctly. That would require some changes. This provides a high-level overview. https://stackoverflow.com/questions/32651557/golang-main-difference-from-csp-language-by-hoare https://stackoverflow.com/questions/32651557/golang-main-dif... Threading is hard and gets a lot harder when you introduce pointers or mutable data. This is even harder when your type system is terrible. I suspect that Go trying to solve this would result in a language that looked a lot like Rust with a Garbage Collector.
- burntsushi 7y ago
  You've gone from "Go channels are broken because they require mutexes to use" to "Go doesn't implement CSP correctly." The former is demonstrably not true and the latter is academic. (Although you did reference a good study on concurrency bugs in Go, but this seems unrelated to either of your claims.) You aren't doing your argument any favors when you're so hyperbolic. Go channels are manifestly not "broken." > I suspect that Go trying to solve this would result in a language that looked a lot like Rust with a Garbage Collector. And yet you honestly can't understand why the designers of Go didn't go down that path? Rust is significantly more complex than Go and much harder to learn.
  - jtolds 7y ago
    The latter being academic doesn't mean it is not also of practical import to correct usability.

nextos 7y ago

I'd add that the SML dialect AliceML, influenced by Mozart/Oz, has incredibly nice lazy, concurrent, distributed, logic, etc. extensions. It's really sad it's abandonware: https://www.ps.uni-saarland.de/alice/ https://www.ps.uni-saarland.de/alice/

ptrott2017 7y ago
ALiceML is indeed a rather nice set of extensions to SML. If you pull the code from here: https://github.com/aliceml/aliceml-alice https://github.com/aliceml/aliceml-alice and make sure you have all the dependencies installed first, it does build on linux and its fun to play with. I am currently working on a AliceML derived language and if there is any interest I'll post a note on HN - once its a bit futher down the line.
- nextos 7y ago
  Please do post once it's ready!

erk__ 7y ago

This reminds me of a paper in the latestest edition of sigbovik [0], "Applications of Standard ML at Google" [1]. It could also use some newer things like better support for unicode strings. [0]: http://sigbovik.org/2019/proceedings.pdf http://sigbovik.org/2019/proceedings.pdf [1]: Page 170, Also here: https://github.com/solb/sigbovik/blob/master/papers/SIGBOVIK_2019_paper_19.pdf https://github.com/solb/sigbovik/blob/master/papers/SIGBOVIK...

cannam 7y ago
Oof! Especially cruel is the "andalso" in the closing sentence.