Graydon Hoare: What next for compiled languages?

Since everybody is talking about this post,we might as well.

Key topics discussed: modules(you know, real ones); errors ("there are serious abstraction leakages and design trade-offs in nearly every known approach"); Coroutines, async/await, "user-visible" asynchronicity; effect systems, more generally (you could see that coming, couldn't you?); Extended static checking (ESC), refinement types, general dependent-typed languages; and formalization ("we have to get to the point where we ship languages -- and implementations -- with strong, proven foundations").

He goes on to discuss a whole grab bag of "potential extras" for mainstream languages, including the all time favorite: units of measure.

Feel free to link to the relevant discussions from the LtU archive...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

(BTW: I added an Effects

(BTW: I added an Effects category).

Solid, but suspiciously typed

This is a solid reply that touches several very different aspects while giving good references, and it thus displays an excellent programming language culture and a (surprisingly ?) strong background on recent PL research.

One thing is more surprising to me: I could essentially have written the same reply. More generally, it sounds like what a literate PL researcher doing a PhD on a ML-family language would also write.

There are two ways to interpret this:
- positive: (some) people "in the industry" also share our focus on correctness and thus view the way forward as using better type systems.
- negative: Graydon comes from the same scientific sub-culture as we do, so his post is much less informative (to us) than a post from someone with a radically different viewpoint.

More generally, it sounds

More generally, it sounds like what a literate PL researcher doing a PhD on a ML-family language would also write.

That would be a pretty accurate description of Graydon Hoare, except that he's shipped languages that people actually use instead of writing dissertations. :)

Beware selection bias, and

Beware selection bias, and also AFAIUI Rust 1.0 is actually radically different from what Rust was when GH stopped working on the project.

It's a fine list, and the

It's a fine list, and the references are on point, but don't you get the feeling that everything old is new again?

We once linked to an ancient

We once linked to an ancient tech report (if memory serves) about design considerations for error handling. I recall it was a nicely done document, and how pertinent the issues still are, but I can't for the life of me locate it. Ring a bell?

previously on this channel

Fwiw, we had a rather wide-ranging discussion on error handling back in 2010, which has links to various earlier stuff (e.g. there's a link to the Dylan manual's discussion on the subject, from the late 90s). Also in that LtU discussion, dmbarbour had a list of strategies.

Thanks! I seem to remember

Thanks! I seem to remember something quite a bit earlier.

Some slides on the Noether

Some slides on the Noether language has a great overview on error handling. I believe this is a follow-up covering other, related topics.

The language sounds interesting as I'd expect from capability folks, but the slides don't give enough detail to get a feel for it, and the github repo is largely empty.