Afaik, unless their infrastructure is running in a part of the universe with different physical laws, they're claiming to provide guarantees that provably impossible. For example:

send_order_confirmation(user.email, fulfillment_order)?;

> will run to completion, regardless of failure events Can a crash be considered "running to completion"? :thinking_face: :D

💥 all done

Even faster than /dev/null!

Putting an old spin on "execution".

They did say at the start: > execute them in a way that is resilient to hardware failures, upgrades, and updates So while it's not clear, pretty sure they scope failure to only hardware level failures.

But, you know, while I'm skeptical, I think there's a good idea here somewhere. It seems to me, whenever they yield, what would say in Java cause a virtual thread to park, if they persisted all the related execution memory to some disk, and resumed it from disk when it resumed. And now, if you yield at every I/O, and Thread.sleep, and all that. Well, I think they claim that it means they can restart your app from like the last I/O and resume it

Which explains there example. It seems if you sleep for 24 hours, they just "park" your worker, but they do so to disk.

PSA: If you want to read something worthwhile about "Making reliable distributed systems in the presence of software errors", read http://erlang.org/download/armstrong_thesis_2003.pdf

Well, I was just thinking of Erlang. Because if Erlang persisted actor on disk, it could survive some level of hardware failure. And since Erlang even yield inside loops at some iteration count interval, it could resume from some iteration back

> So while it's not clear, pretty sure they scope failure to only hardware level failures. From a theoretical standpoint, it doesn't really matter what kind of failures (unless they're running programs in a magical data center without disk errors, network errors, hardware errors, software errors, power failures, clock skew, or any other type of failure).

But ya, this would not cover application level failures. Though, to be honest, it maybe could? If they captured to disk the input from all IO, could they resume your code, where it could actually be new code that fixed some issue, and replay things from the last IO ?

My guess is something like, they write to some RAID setup, obviously there could be a failure at that level. So ya, I don't deny they're exagerating when they say all hardware failures.

You would have to somehow contend with the https://en.wikipedia.org/wiki/Two_Generals'_Problem or figure out how to have https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/.

and that's just to make it even theoretically possible.

Why? They're not claiming there's no system wide issues. Just that the single threaded worker will survive a hardware failure, OS update, hardware upgrade, etc.

Which I can see being possible, if they parked the worker to some replicated disk on all I/O and yield points

ok, let's say there's an I/O call to send_email. the application initiates the network request and unfortunately, the server explodes. fortunately, the state was saved before the request was initiated and restarts. now, you've sent two emails.

maybe it's not a big deal to send duplicate emails, but it's the same problem for any non-idempotent action.

Ya, but you don't get it better solving the same problem in application code

So they're automating the best thing you can realistically achieve no?

not really. these aren't new ideas. I think the main reason this isn't normally done is there is a big efficiency cost.

There are solutions that can help in the space. In my experience, the solutions that are actually worthwhile don't use flashy marketing buzzwords.

Ya, they've made no claim of performance or anything. So that's yet to be seen.

The marketing here sounds like a webscale database that will happily throw away your data that became popular not too long ago.

I feel like if you're solving hard problems, you can just say it without including stuff like "workers deployed to Golem Cloud are reactive, invincible, and immortal."

I totally understand your skepticism here. And am also put off by marketing like that. But at least I saw an idea underneath that is interesting to explore. So I'll wait and see, maybe their marketing guy is just that kind of guy, and they have some other smart engineer.

Fair enough.

I would not rush to have a wasm target for cljs until they've got something to show though just cause of it 😂

this is from team behind Scala Zio functional effect system, deeply credible this is a top 5 software team in the world

That already makes it sound more than suspicious to me. I have worked with a "one of the most renown software development companies in the world" directly, it was abysmal. Mutual protection above all else, including their clients. > a top 5 software team in the world By which metrics?

so golem is temporal but with some generated rpc stubs, only runs wasm and is proprietary? They mention temporal but then just describe stuff temporal already is capable of. Also I Ctrl f'd durable computing and they use it 6 times but never define it, just breathlessly fellate this idea.. google is trying to get me to buy some heavy laptops