undefined | Better HN

0 pointswhstl5mo ago0 comments

You would deal with this problem in the same way you would with, say, in a REST API.

If the transaction object is serializable you can just store it in a DB, for example. If it's some C++ pointer from some 3rd-party library that you can't really serialize and gotta keep open, you gotta keep it in memory and manage its lifetime explicitly, be it a REST web server, in Haskell or in a C++ app.

0 comments

taeric4mo ago

Right, I think a better way of stating my main assertion here is that you have to be able to partially work in a transaction. If your "shell" pretends that you can always complete the full transaction, either successfully or with a failure, then it is a brittle shell. Sometimes, you can simply make progress on an presumed open transaction.

whstlOP4mo ago

It doesn’t have to pretend anything you don’t want. If you don’t want this kind of problem/failure possibility, then you have to encode those states in the type system. Functional programming can do the same things you can do in imperative, but you gotta make it when it’s not there. Just like in any other paradigm.

taeric4mo ago

Totally fair. As I said up thread, I am comfortable saying I am imagining bad examples here. Would be interested in reading good examples. Though I couldn't find any of the bad ideas I had in my mind, I also didn't find any good ones on a quick search.

j / k navigate · click thread line to collapse

0 pointswhstl5mo ago0 comments

You would deal with this problem in the same way you would with, say, in a REST API.

0 comments

taeric4mo ago

whstlOP4mo ago

taeric4mo ago

j / k navigate · click thread line to collapse