Rob Pike: Simplicity Is Complicated [video]

>Of course, we need to reach a gentleman's agreement regarding which formalism is a good “foundation” for defining everything else. My personal preference would be to define all other formal systems in terms of rules of inference.

If you are interested in defining "low cognitive load" that's a poor choice, in my opinion.

>I am fine with any, as long as the same choice is made for all languages being compared. What ultimately interests me is proving a type safety theorem, that is, a precise sense in which “well typed programs don't go wrong”, so perhaps this makes a structural operational semantics more appropriate than the other choices.

I'm not aware of any such thing, the kinds of formal semantics that academics prefer deal very poorly with the realities of finite execution speed and memory, the kinds that pratictioners use (which usually isn't referred to as "formal semantics" but rather "what does this compile to") deal very poorly output correctness.

However this has little to do with cognitive load, even if such formal semantics existed it doesn't necessarily mean it would be easy for a human mind.

> Sure, but the target languages used by most compilers are often themselves very complex. Which means a realistic compiler or interpreter most likely won't be a good benchmark for semantic simplicity.

If you agree that formal semantics is just a translation from one formalism to another, you can't claim that a formalism A is semantically more complex than formalism B without picking a formalism C as a reference point.

> This is a classic example of worse-is-better.

C won over Lisp, not because “worse is better”, but because the C's advantages over Lisp (performance on cheap machines) were more pronounced than the other way around (“safety” achieved by means of lots of runtime checking - by no means was it possible to statically rule out errors). Lispers fancy their language of choice the pinnacle of computer science, but the falsity of this claim becomes evident under close scrutiny.

> Go vs. Rust plays out quite similarly to what worse-is-better would predict.

I see a brighter future for Rust in the long run, for the following reasons:

First, Go doesn't do enough for the programmer: Haskell and Erlang are safer and easier to use, and have much better parallelism and concurrency stories. What kind of silly value proposition is “safer than C” or “less verbose than Java”? Rust offers something genuinely new: half-assed attempts at “better C++s” have existed for a while, but “safer C++s” haven't.

Second, Rust plays much more nicely with other languages. Rust is no more difficult than C to call from, say, Python. On the other hand, Go seems to be more of an all-or-nothing proposition: “If you want to use Go libraries, use them from applications written in Go.”

> If you are interested in defining "low cognitive load" that's a poor choice, in my opinion.

I'm interested in “low cognitive load without sacrificing technical precision.” It's a much harder goal to achieve than “low cognitive load if we hand-wave the tricky details.”

> However this has little to do with cognitive load, even if such formal semantics existed it doesn't necessarily mean it would be easy for a human mind.

Which is exactly my point. I only consider a language simple if its formal description is simple.

> If you agree that formal semantics is just a translation from one formalism to another, you can't claim that a formalism A is semantically more complex than formalism B without picking a formalism C as a reference point.

No disagreement here. I even stated my personal choice of C.

Reflection, downcasts and assigning `null` to pointers are completely opt-in in Java too.

With respect to type families, I'm probably being a little bit unfair. Personally, I don't have much against associated type families. (Although I think Rust handles them much more gracefully than GHC.) But very important libraries in the GHC ecosystem like vector and lens make extensive use of free-floating type families, which I find... ugh... I don't want to get angry.

I absolutely agree with all Rob Pike says. But in practice the problem is still the trade off. How limited a language should be ? what are the features a language should absolutely have to make the life of the developer easy yet still give him some room to express himself the way he wants? I think that Go failed if one considers that trade off. Often with Go, a developer ends up doing the job of the compiler, because its flat type system doesn't allow a certain degree of expressiveness ( or worse, forces the developer to use reflection , i.e. putting aside the type system all together and using a "generic" 'interface {}' type).

While C++ is something extreme in term of complexity , the other extreme, Go, is problematic as well. I've yet to find a language that has a good balance between the 2. But Go certainly showed that the tooling is as important as the language itself, and it's a great part of its success.

"Philosophically" , no question, I agree with Rob Pike. On practice, things are a bit more nuanced.