I am not familiar with what you're talking about (but Cliff may already know), I'll have to look into it. But Hubris is a synchronous system, and also, these faults aren't catchable, so I'm not sure how directly relevant it is. What's the specific issue you're worried about?

Your Erlang vibes are there for good reason, it's certainly an influence.

Reaching out and nuking other... whatever you call them, "execution contexts" is what I go for to be maximally generic (thread/async task/continuation/generator/etc.), can particularly cause problems if the context was going to do X, Y, and Z and expected to be able to be guaranteed to run Z, but Y killed it. The standard example is for X to be taking a lock and Z to release it, but there are a lot of ways to get into trouble and the obvious first solutions don't work.

Erlang solves it by locking what things it has that can have that problem behind other execution contexts that don't get killed when the main one dies, so they can still clean up. ("Ports", in their terminology.) Haskell solves it by being a functional language and beating the collective community's head in it for several years. (Immutability helped a lot, laziness took out back.)

If that sounds impossible... hey, great! Then I just pattern matched on something that wasn't a match. If that doesn't sound impossible, then it may be worth a look around.

Synchronousness may not really matter, I've kind of thought that "asynchronous exception" is not a good name for the issue for a while, but it's what it gets called. It's really about one execution context lobbing errors/exceptions into others. Although being synchronous would avoid the worst timing issues.

Ah, that problem in general I am familiar with, yes.

Tasks in Hubris are independently compiled programs, not threads in a shared context. So I don't believe that it's an issue. You don't share locks between tasks, you create a task that holds the shared resource, and have the two tasks that want to share it talk to that task, patterns like that.

>Recommended languages are Java (ultimately a failure despite vast effort)

Why is Java a failure? Recent JVMs have come a long way, and GraalVM makes it somewhat comparable to Go-like languages.

I understand the historical hate and how Oracle bought it, but it really isn’t that bad of a language if you’re using modern Java.

They're referring to that specific feature of Java being a failure, not the language in general.

The parent was talking about async exception in java -- like the InterruptedException . They are hard to work or reason with.

huh? Do not see anything asynchronous in author's work. It's all synchronous, because IPCs in hubris are synchronous too.