> I'd say it probably depends on the kind of work you do - if the low level details are exciting then that's totally understandable.
Even those who work with CRUD apps need to know things like computational complexity of standard container types, and how to pick basic data structures or choose which basic algorithms to use. Otherwise you'll end up implementing things that have an unreasonably high computational cost that will rear its head at the wrong time.
> That said, AI will probably saturate most CRUD work first, which doesn't make for great job prospects.
I think so too. Today's AI models excel at makeshift plumbing. The boring CRUD jobs are the first ones to go with a prompt.
> Durable execution looks a bit like a buzzword in general. If your state is defined in the execution graph then it's just an umbrella term for a group of pre-existing algorithms and patterns.
If you first approach a tool because of buzzwords, don't be surprised that you think of the buzzwords instead of the tool.
Durable executions greatly simplify how workflows can be implemented and audited, and they literally allow eternal workflow executions that are not tied to the lifetime of an instance assigned to execute them. Durable executions do not require fancy infrastructure, only a terribly simple database.
If you understand continuations, you understand durable executions. Otherwise, you'll be stuck with the excuse that they are buzzwords.
Well, you have to either capture/eliminate/persist side effects and control the environment tightly, or it's limited in what it can do.
In a distributed or concurrent system, for full granularity, that can require specialized timing or virtualization techniques up to ensuring fully atomic snapshots and deterministic execution environments (and whether or not that properly models the SUT in real environments, or introduces bias/breaks the reproducibility in a way you care about)
Otherwise if you're only running against fixed checkpoints you have something closer to traces that maybe you could re-run or test against, in some cases, if you put in the work to set it up. In distributed systems that can be a lot of work so it's a bit vague if left unspecified. Because it's not enough to merely replay something if things can drift or don't accurately model the real system
> Well, you have to either capture/eliminate/persist side effects and control the environment tightly, or it's limited in what it can do.
You really need to read up on durable executions before commenting. Your comment reads as if you are completely oblivious to them. Their whole point is benefiting from an execution model where your workflow is comprised of idempotent pure functions whose inputs and outputs are tracked by the durable task persistence.
It's a problem I've spent a lot of time on, just not through the products marketed like temporal. I commented on the article because it's about program replay with checkpointing which is similar to what I worked with/mentioned.
I didn't see the article mention idempotency anywhere, and you didn't in the original response to the guy who said it just sounded like a buzzword; atomic snapshotting with deterministic execution is literally how you make a program continuation an idempotent function!
And the article is about solving the problem at the language runtime level so it doesn't even do that. So it would be reasonable to assume it is a buzzword if it does not have the essential property you mentioned and I was referring to. I was not even intending to disagree with you but just add what would make it less of a buzzword in this kind of case.
For the sort of architecture described in the blog post, you're persisting the program rather than a log, so you only need idempotency between any two checkpoints. For a lot of apps that's easy to achieve if write the snapshot into the same transaction the user is using for application data, and if you create/propagate idempotency tokens to other services.
You don't need specialized timing or virtualization techniques.
The last batch of open weight models releases by Chinese companies are on par with the performance of US-based frontier models, even though they are designed to run on pretty unimpressive hardware.
This is very misleading. There is no Chinese model currently that is on par with Fable or Astra. Kimi K3 is pretty good, but it's not that good.
Furthermore the Chinese models in that class are appropriately large. K3, for example, is a 2.8T-parameter model. Qwen 3.8 Max, another comparable model, is 2.4T params. Even with MoE, these are not "designed to run on pretty unimpressive hardware". Stuff like Qwen3.7-27B is, but it is also not even in the same ballpark as Opus, never mind frontier.
> This article doesn’t present much motivation for why you would do this.
For those working with databases, it's easy to come up with a bunch of reasons. ORM is a necessary evil when working with RDBMS, as are things like schema migrations that can easily result in loss of data (I.e., dropping columns or tables).
What if all we need is dumping a big old JSON in a container?
This idea is very enticing. The scale of this whole NoSQL thing is pretty telling.
The blog presents a thought provoking question: what if we don't actually need a full-blown database, and instead we only care about things like unique constraints, transactions, indices, and history tables.
> ORM is a necessary evil when working with RDBMS, as are things like schema migrations that can easily result in loss of data (I.e., dropping columns or tables).
Hmm, neither of those been necessary for me. ORMs is a choice, you can choose not to and still have a proper design and architecture and not suffer from that choice. Requires you have programmers who know how to use SQL, which seems less and less common as the days go by though, so understandable most reach for an ORM.
Schema migrations that can "easily result" in data loss is even easier to avoid though. Don't drop the column/table in the same step you copy data to the new place, or do the migration via application code which gets cleaned up later, to catch most of the stuff before one bigger copy, and then the eventually DB cleanup.
Guess it depends on how careful you want to be, or how careful your agent lets you be, I guess. But it's definitely possible to avoid both of those "necessary evil", which I guess makes them just "evil".
> The blog presents a thought provoking question: what if we don't actually need a full-blown database, and instead we only care about things like unique constraints, transactions, indices, and history tables.
This sound like: what if we dont actually need a table and instead we only care about four legs and a wooden plate.
That's the problem. Hitting a tied up animal until it breaks is clearly a violent affair, similar how hanging puppets in nooses or putting a doll in a guillotine.
I'm sure that there are kids growing up in places where bullfights are common thinking that torturing and killing a bull in a party-like atmosphere is fine.
I mean yeah, absolutely. But a child growing up in a western society is unlikely to encounter either of those. But generally I do see Pokemon as violent and I wouldn't let my 5 year old watch it quite yet. When he's a bit older I hope he enjoys playing through the original games and the OG tv show with me, but I see parents playing the TV show for their 4-5 year olds and I think that's just too young. Same with Spidey and friends and few other shows made "for children" which absolutely promote violence despite the colourful aesthetic.
Not necessarily, in C++ you'd still drop from smart pointers to raw pointers, from virtual dispatch to switches/computed gotos, from std::function to function pointers and so on. These abstractions all come at a cost.
> "Making money" is the incentive system of society. Technology has now aligned society's incentive systems to promote climate action.
This personal belief is grounded on an assumption that all mankind follows a neoliberal or even libertarian economic model.
Back to reality, west Europe is firmly a social democracy where states impose behavior through law, regulation, and policy, which is topped by a federal system that coordinates policies. Countries such as China are totalitarian with a centrally managed economy that's guided by N-year strategic plans.
My supposed "personal belief" is not normative it is descriptive.
Misconstruing this as normative, and attributing it to a political belief, is your cognitive dissonance trying to reconcile where actual climate action is coming from.
We must understand the world as it is, if we are to effectively change it to a better state.
> My supposed "personal belief" is not normative it is descriptive.
No, it is a expression of your personal and unsupported beliefs. Asserting that the whole world enforces a libertarian economical system is simply out of touch with reality. I mean, China alone is a totalitarian regimes that still manages it's economy through central planning.
> Back to reality, west Europe is firmly a social democracy where states impose behavior through law, regulation, and policy, which is topped by a federal system that coordinates policies.
And yet, air travel continues to grow (after a small hiatus due to COVID) and state and EU money will be dumped into a new airport near me, to support more than doubling current capacity, much further away from the city (adding tens of millions of car trips to and from the airport).
I'm simply the looney for not taking the kids on low cost European city escapes.
It starts from the “bottom”: people will talk about it, but will pretty much continue to do whatever the fuck they can afford to do. And Europeans, like Americans, can simply afford to much, while harping about what will happen to the world once the BRICS can afford the same.
Seriously, we have the US threatening to sanction (and has) politicians and judges that want to regulate US technology companies. The idea that neoliberalism doesn't have a massive influence on the world is straight up delusional.
Did we forget that EU took an austerity approach following 2008 and all that did was immiserate their population enough where they are voting for fascist/nationalist political parties?
Yes, although I wouldn’t blame the US solely, London also carries a fair amount of responsibility for it. Perhaps not as much as the US, but Thatcherism was certainly the Trojan horse for European entry of neoliberalism in the 1980s.
> This personal belief is grounded on an assumption that all mankind follows a neoliberal or even libertarian economic model.
This personal belief is usually coupled to people who have become wealthy following this belief. So it tracks that they would declare any solution that doesn't allow them to continue their plundering impossible.
Even those who work with CRUD apps need to know things like computational complexity of standard container types, and how to pick basic data structures or choose which basic algorithms to use. Otherwise you'll end up implementing things that have an unreasonably high computational cost that will rear its head at the wrong time.
> That said, AI will probably saturate most CRUD work first, which doesn't make for great job prospects.
I think so too. Today's AI models excel at makeshift plumbing. The boring CRUD jobs are the first ones to go with a prompt.
reply