Sandy Maguire

> Could you clarify (or provide more reading on) how the other systems like delimited continuations, algebraic effects, and monads differ from Zig async + how they could be adapted in a similarly unopinionated/low-level way?

The key requirement for all these is an ability/API to defer and resume execution (indeed, delimited continuations are sometimes described as "resumable exceptions"). In higher-level languages we'd just assume the presence of first-class functions/closures, and use those to describe these features. I'm less familiar with how that looks in a very low-level language like Zig, however these "async frames" appear (to my naïve eyes) to be analagous; hence why I'm interested whether one of those more-general primitives could be provided instead (the answer might be no!).

As for clarification on those features, here's a quick attempt. Firstly, note that all of these approaches are basically APIs to construct, consume, and combine (deferred) computations: they are unopinionated on how those computations get run (e.g. the user could supply a "main loop", or whatever).

Delimited continuations are like exceptions, except the stack (AKA continuation) is passed to the handler, which may choose to resume it. We can implement coroutines/async/yield/etc. by having handlers which put their continuation in a queue and pop off some other one to resume instead; we can get data parallelism by resuming a continuation many times; we can get backtracking by remembering old…

This is ones of those essays that pops up on Hacker News every so often, and I'm always happy to reread it. Regardless of how the technologies have changed or if the prognostications were correct, this article is about timeless and relevant themes.

Abstraction is the most powerful force within the human mind. It is perhaps solely responsible for the world we've built around us. But it is also absolutely terrifying how increasingly reliant we are on it.

"Contemporary culture is a two-tiered system, like the Morlocks and the Eloi in H.G. Wells's The Time Machine, except that it's been turned upside down. In The Time Machine the Eloi were an effete upper class, supported by lots of subterranean Morlocks who kept the technological wheels turning. But in our world it's the other way round. The Morlocks are in the minority, and they are running the show, because they understand how everything works."

We are more and more surrounded by technology that the majority of us don't understand even at a fundamental level (for the record, I include myself in the Elois). More often than not, these technologies are essentially taken for granted as magic. While no reasonable person should expect everyday people to understand the inner workings of their handheld supercomputers or their cable TV box, we would all be better off if we better understood the fundamental building blocks of the technologies we are surrounded by -- whether that's basic logic gates, the simple patterns of…

Neat, and it looks like it's under a 3-clause BSD license, too: https://github.com/isovector/reasonablypolymorphic.com/blob/master/LICENSE

And it's tackling pretty advanced material — a bunch of category-theory stuff that I have no idea about. This is exciting!

It looks like maybe it's unfinished: https://reasonablypolymorphic.com/book/tying-it-all-together.html ends, "Really, we’re just getting started," and then (the current version of) the book ends. What a cliffhanger ending!

It doesn't seem to yet cover circuitry; the hardware it discusses seems to be a two-tape Turing machine, much like BF. The author seems to have been simulating the machine by hand to generate the included execution traces.

I had a hard time finding the source at first: https://github.com/isovector/reasonablypolymorphic.com/blob/master/site/static/book/machine-diagrams.html has a bunch of attribute-embedded &-escaped SVG (including XMLPIs!) that he almost certainly didn't type like that. That file is duplicated at https://github.com/isovector/reasonablypolymorphic.com/blob/master/docs/book/machine-diagrams.html in the same format.

As it turns out, the source for that post is in https://github.com/isovector/reasonablypolymorphic.com/blob/master/site/httw/2016-11-01-machine-diagrams.markdown, with embedded Haskell to produce the SVGs. The build scripts looks like they might be in https://github.com/isovector/reasonablypolymorphic.com/tree/master/src and…

Despite being functional, Elm is quite minimalist when it comes to type system features. For example, functions can have generic type parameters, but there's no good way to require that the type be able to support certain operations, e.g. being printable as a string. Haskell's solution to this is "typeclasses", which are the same thing as Rust "traits" and Swift "protocols", and somewhat similar to Java "interfaces". Elm has a handful of builtin typeclass-like things that work by compiler magic, but there's no way to define your own. For a somewhat colorful rant about this, see "Elm Is Wrong":

https://reasonablypolymorphic.com/blog/elm-is-wrong/

Elm is also very opinionated, e.g. the compiler itself restricted the ability to bind to JavaScript libraries to only approved organizations:

https://discourse.elm-lang.org/t/native-code-in-0-19/826

The community is also fairly toxic; check out this passive-aggressive response by the /r/elm moderators to a (mildly worded) blog post complaining about the aforementioned restriction:

https://www.reddit.com/r/elm/comments/9a0hc6/elm_019_broke_us/e4sdtg0/

Personally, I decided I would never touch Elm again after reading that.

I think it probably falls more into the category of removing a restriction rather than a new feature, but I'm still waiting on HKTs - not for traits (as a former die-hard haskeller, I have been gradually converted to the side of "rust doesn't need a Monad trait") but for data types. There's a design pattern in haskell called "Higher-Kinded-Data"[0] where you parametrize a datatype on a type-constructor, and use that to generically define either partial or total versions of that data type- something like (in rust syntax):

struct Person<F> {
pub name: F<String>,
pub age: F<u32>,
}

where you can then have `Person<Option>` be a person that may or may not have all fields filled, and `Person<Box>` be a person with all fields definitely filled. This is something I find myself reaching for surprisingly frequently when writing rust, and I feel like it's a missed benefit of implementing higher-kinded types.

[0]: https://reasonablypolymorphic.com/blog/higher-kinded-data/

All that said, I'm really excited to have const generics land! Props to all the amazing work by withoutboats and the entire rust team.

This has to invoke Betteridges law of headlines.

As one who had the great fortune to be part of networking in the UK in the 70s and 80s, including a stint in UCL-CS working at the end of the SATNET/ARPANET years (UCL was the uk end of the ARPAnet of the day, with an IMP, and then a BBN butterfly, and a large tranche of addresses held I believe in conjunction with the UK signals directorate of the Ministry of Defence) -I can tell you its a bit from box A and a bit from box B.

It worked better than a lot of us (X.25!) thought.

It worked a lot better than the code a lot of us were working on (the OSI/GOSIP model)

USENET was both worse and better than online communities.

The 1984 RAND report on the social behaviours in EMail remain true to this day, discussing flaming and trolling behaviours.

https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-association-11 is an indication of how important the questions have become.

Also see https://reasonablypolymorphic.com/blog/monotonous-web/index.html which is at https://news.ycombinator.com/item?id=32348519