Hacker News Reader

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.

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.

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

Have you SEEN what happens when you give an extremely clever engineer some rope?

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.

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.

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

[1]: Page 170, Also here: https://github.com/solb/sigbovik/blob/master/papers/SIGBOVIK...

Oof!

Especially cruel is the "andalso" in the closing sentence.

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/

ALiceML is indeed a rather nice set of extensions to SML. If you pull the code from here:

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.

Please do post once it's ready!

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.

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

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

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

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.

The latter being academic doesn't mean it is not also of practical import to correct usability.

Never said it doesn't. But no further explanation was offered.

Bottom line for me is that if you're going to be snotty about something, then at least be correct. Or better yet, don't be snotty in the first place.

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.

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?

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

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.

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

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

I assumed Standard ML was more like Haskell than it is. Going through OP's tour, I notice that it has enough features to actually be usable. It has primitives for concurrency and OS APIs.

It's even easier to use if you go with Poly/ML's pthread support. CML is relatively more complex and less supported from what I can tell.

'A Tour of Go' inspired this. The format and some of the material come from there. I think it ended up shorter than the Go tour, and I was hoping it would be very easy to learn Standard ML from it, as I do consider it to be very easy to learn. You can pull up the CML examples next to the Go ones, and other than syntax, they should be the same:

https://tour.golang.org/concurrency/1

https://saityi.github.io/sml-tour/tour/03-01-spawn.html

There are differences, but once you get to that point in either tour, the differences shouldn't make it hard to read; if it is hard to read or understand, that would be welcome feedback, as I have failed in my attempt to present Standard ML well. :)

(I originally posted this as a 'Show HN', hoping for feedback, so it is totally welcome.)

It is very readable. Helped me get over my initial prejudice after I actually looked at it.

Thanks for checking it out! :)

> Bad code needs to be screamingly obvious.

I'm not sure I understand why this is true for Go rather than a statically typed FP language. If anything, I'd consider languages like Haskell or ML to be better at this.

- The obvious case is handling `nil`. In Haskell, you'd treat this as `Maybe a`, and it's obvious that you're not handling the nil case since the pattern match is incomplete. In Go, you get a nil pointer exception at runtime. You could check for the nil case for every pointer, but that's too onerous, so now you're left with relying on the programmer on checking

- Go doesn't have exceptions, which removes some of the hiding of bad code (see https://devblogs.microsoft.com/oldnewthing/20050114-00/?p=36...), but you can still accidentally use a result when an error is return (in fact, you have to return something!). In Haskell, you're forced to pattern match on an `Either`, which again exposes bad through an incomplete pattern match.

I don't think these are arguments for FP per se, but I do think that statically typed FP languages (and the languages they inspire) are much better about removing footguns and making bad code hard to write, simply because the typechecker is so restrictive. As a more general principle, instead of making bad code screamingly obvious, make it impossible to write!

Now, you mention later in the thread that you've already used Haskell before, so you're probably aware of all this and I may misinterpreted what you meant. Did you mean a different form of bad code?

Because Rob Pike is a hack

Could you please stop posting unsubstantive comments to HN? Also, personal attacks are not ok here.

https://news.ycombinator.com/newsguidelines.html

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.

OCaml compilation is just as fast as Go.

Great. SML compilation was noticeably slow last time I used it, but maybe that's changed.

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.