Although I'm the first to agree with this, it is actually commendable in the sense that it breaks with the quarterly profits approach.
Like meta with the metaverse thing, I hate it with a passion, but pouring billions yearly with little return just to support your vision is at least a break with tradition...
For me the main issue with these systems is that its still seen as a special case of backend execution. I think the real value is just admitting that every POST/PUT should kick off a durable execution, but that doesn't seem to match the design, which considers these workflows quite heavy and expensive, and bases its price on it.
What we need is an opinionated framework that doesn't allow you to do anything except durable workflows, so your junior devs stop doing two POSTs in a row thinking things will be OK.
The "constraining functions to only be durable" idea is really interesting to me and would solve the main gotcha of the article.
It'd be an interesting experiment to take memory snapshots after each step in a workflow, which an API like Firecracker might support, but likely adds even more overhead than current engines in terms of expense and storage. I think some durable execution engines have experimented with this type of system before, but I can't find a source now - perhaps someone has a link to one of these.
There's also been some work, for example in the Temporal Python SDK, to overwrite the asyncio event loop to make regular calls like `sleep` work as durable calls instead, to reduce the risk to developers. I'm not sure how well this generalizes.
Ok, I'm not an expert here, you most likely are, but just my 2 cents on your response: I would very much argue to not make this magic.
e.g:
> take memory snapshots after each step in a workflow
Don't do this. Just give people explicit boundaries of where their snapshots occur, and what is snapshotted, so they have control both over durability and performance. Make it clear to people that everything should be in the chain of command of the snapshotting framework: e.g no file-local or global variables. This is already how people program web services but somehow nobody leans into it.
The thing is, if you want people to understand durability but you also hide it from them, it will actually be much more complicated to understand and work with a framework.
The real golden ticket I think is to make readable intuitive abstractions around durability, not hide it behind normal-looking code.
> The thing is, if you want people to understand durability but you also hide it from them, it will actually be much more complicated to understand and work with a framework.
> The real golden ticket I think is to make readable intuitive abstractions around durability, not hide it behind normal-looking code.
It's a tradeoff. People tend to want to use languages they are familiar with, even at the cost of being constrained within them. A naive DSL would not be expressive enough for the turing completeness one needs, so effectively you'd need a new language/runtime. It's far easier to constrain an existing language than write a new one of course.
Some languages/runtimes are easier to apply durable/deterministic constraints too (e.g. WASM which is deterministic by design and JS which has a tiny stdlib that just needs a few things like time and rand replaced), but they still don't take the ideal step you mention - put the durable primitives and their benefits/constraints in front of the dev clearly.
FWIW, I think the memory snapshotting idea isn't going to work for most stacks for a few different reasons, but to speak more broadly on API design for durable execution systems, I agree completely. One of the issues with Temporal and Hatchet in its current state is that it currently abstracts concepts that are essential for the developer to understand, like what it means for a workflow to be durable, while the developer is building the system. So you end up discovering a bunch of weird behaviors like "non-determinism error" when starting to test these systems without a good grasp of the fundamentals.
We're investing heavily in separating out some of these primitives that are separately useful and come together in a DE system: tasks, idempotency keys and workflow state (i.e. event history). I'm not sure exactly what this API will look like in its end state, but idempotency keys, durable tasks and event-based histories are independently useful. This is only true of the durable execution side of the Hatchet platform, though; I think our other primitives (task queues, streaming, concurrency, rate limiting, retries) are more widely used than our `durableTasks` feature because of this very problem you're describing.
Just to continue the idea: you wouldn't be constraining or tagging functions, you would relinquish control to a system that closely guards how you produce side effects. e.g doing a raw HTTP request from a task is prohibited, not intercepted.
This would look like a handler taking an IO token that provides a memoizing get_or_execute function, plus utilities for calling these handlers, correct?
This is not really the same level of argument. The post is arguing against the idea that software is incredibly cheap to make through AI right now, not that AI cannot ever make complete software products from scratch in the future.
Ok, well, rereading TFA again, it does seem to say that, but I took it as hyperbole. I'm not familiar with any of even the staunchest GenAI visionaries claiming:
> Why buy a CRM solution or a ERM system when “AI” can generate one for you in hours or even minutes?
Obviously that's a strawman argument that shouldn't be taken at face-value. AI-generated software is rapidly improving, but it will take some time until it can do that sort of work without human intervention. Extrapolating from METR's chart[0], we should expect a SotA AI to one-shot a modern commercial CRM in around the early 2030s. It's then up to anyone here to decide if that's something we should actively prepare for already (I personally think we should).
Although that particular claim is sensational, the main argument does not depend on sensational claims.
The article is not straw-manning the AI argument, its steel-manning it: show me any improvement in software delivery after the invention of generative AI.
I'm not sure I follow, though I agree with your definition of idempotency I think ensuring idempotency on the receiving side is sometimes impossible without recognizing that you are receiving an already processed message, in other words: you recognize that you have already received the incoming message and don't process it, in other words: you can tell that this message is the same as an earlier one, in other words: the identity of the message corresponds to the identity of an earlier message.
Its true that idempotency can sometimes be achieved without explicitly having message identity, but in cases it cannot, a key is usually provided to solve this problem. This key indeed encodes the identity of the message, but is usually called an "idempotency key" to signal its use.
The system then becomes idempotent not by having repeated executions result in identical state on some deeper level, but by detecting and avoiding repeated executions on the surface of the system.
We are saying the same thing using different words. I view this as a strategy for dealing with a lack of idempotency in handlers with a great deal of overhead. So I guess I would call it a non-idempotency key since a handler that is not idempotent will necessarily use it. I think this strays too close to a contradiction in terms.
Maybe this is a mismatch of expectations, but I generally think very few handlers are idempotent without such a key. E.g any edits or soft-deleted are impossible to handle in an idempotent way without auxiliary information (idempotency key or timestamp or sequence number).
Again stopping the execution of the handler based on an ID is not idempotency, but rather a corrective measure due to the fact that the handler is not idempotent. Idempotency is a property that says the handler can run as many times as I like, as diametrically opposed to the notion that it can run only once.
> Idempotency is a property that says the handler can run as many times as I like
.... using some input. If that input has a key and the handler bails on execution, your definition is not at all violated. Its only violated if you don't consider the check a part of the handler, which is an arbitrary limitation.
Regardless, I think your interpretation that avoids identifying the message explicitly leaves a very narrow set of idempotency candidates, which is not a useful definition. Under that definition, really only reads are idempotent, as any state setting can be later retried and give a different result if other state settings are interleaved.
You are 100% correct. UDP can be used to solve this problem, in fact, UDP can be used to solve any (software) networking problem, because its kind of what networking is.
The thing that webdevs want to solve is related but different, and whether the forest is missed for the trees is sometimes hard to tell.
What webdevs want to solve is data replication in a distributed system of transactions where availability is guaranteed, performance is evaluated horizontally, change is frequent and easy, barrier to entry is low, tooling is widely available, tech is heterogeneous, and the domain is complex relational objects.
Those requirements give you a different set of tradeoffs vs financial exchanges, which despite having their own enormous challenges, certainly have different goals to the above.
So does that mean this article is a good solution to the problem? I'm not sure, its hard to tell sometimes whether all the distributed aircastles invented for web-dev really pay out vs just having a tightly integrated low-level solution, but regardless of the hypothetical optimum, its hard to argue that the proposed solution is probably a good fit for the web dev culture vs UDP, which unfortunately is something very important to take into account if you want to get stuff done.
> in a distributed system of transactions where availability is guaranteed, performance is evaluated horizontally, change is frequent and easy,
Isn't that the situation inside a CPU across its multiple cores? Data is replicated (into caches) in a distributed system of transactions, because each core uses its own L2 cache with which it interacts, and has to be sent back to main memory for consistence. Works amazing.
Another even more complex system: a multi CPU motherboard supporting NUMA access: 2 CPUs coordinate their multiple cores to send over RAM from the other CPU. I have one of these "distributed systems" at home, works amazing.
Indeed, again you are right. I've gone through the same motions as you trying to understand why the webdev people make this so complicated.
For your specific question here: NUMA & cpu cores don't suffer from the P in CAP: network partitions. If one of your CPU cores randomly stops responding, your system crashes, and that's fine because it never happens. If one of your web servers stops responding, which may happen for very common reasons and so is something you should absolutely design for, your system should keep working because otherwise you cannot build a reliable system out of many disconnected components (and I do mean many).
Also note that there is no way to really check if systems are available, only that you cannot reach them, which is significantly different.
Then we've not even reached the point that the CPU die makes communication extremely fast, whereas in a datacenter you're talking milliseconds, and if you are syncing with a different system accross data centers or even with clients, that story becomes wildely different.
I don't think I'm qualified to answer the question, and I also think it depends on terminology where maybe 'core' is the wrong thing to say, but regardless: my general point is that the assumptions that hold for CPUs don't hold for webservices, and that's where the design ethos between them splits.
I don't think I did. The implication is that using languages with strong types (as discussed in the article) is not a solution. That's rubbish. It's at least part of the solution.
> The claim that something is hard to do properly is an argument for doing it less often
I don't even believe that you believe this.
> the benefit is unambiguously large and staying away from borderline cases
If this was easy, don't you think maybe that's what people would be doing?
> if it wants testing done then it should pay for it from general revenue
???
So if I build a car, screw it up, have to test it 500 times just to pass and be allowed to sell it, that's the governments problem? If I open a bank and take peoples money, its up to the government to take initiative on making sure I'm not screwing them over?
> instead of imposing an unfunded mandate
What? So now any test the government mandates is an unfunded mandate? Like food tests?
This is obviously getting way to political because none of the arguments are making any sense, and are completely disconnected from reality.
I don't even consider myself pro regulation but this is just the equivalent of putting your fingers in your ears and shouting LALALALALALA.
Is your position that when something is intractably easy to screw up we should do it as much as possible?
> If this was easy, don't you think maybe that's what people would be doing?
Which people? The ones with a structural incentive to not do that?
> So if I build a car, screw it up, have to test it 500 times just to pass and be allowed to sell it, that's the governments problem?
It seems like it's still your problem because you want to sell the car and therefore want it to pass.
Whereas if the test is unreasonably expensive then the government has a problem, but the problem is of its own making and it now has the incentive to fix the problem instead of burdening someone else with it.
> If I open a bank and take peoples money, its up to the government to take initiative on making sure I'm not screwing them over?
It is indeed the role of law enforcement to enforce the laws.
> What? So now any test the government mandates is an unfunded mandate? Like food tests?
Is your argument that it isn't an unfunded mandate supposed to be that the test isn't mandated or that the government is actually funding it?
> Is your position that when something is intractably easy to screw up we should do it as much as possible?
No, if that was my position, you would've found out by me saying that was my position.
> Which people? The ones with a structural incentive to not do that?
Why would they have such an incentive? This is all hyperbole.
> but the problem is of its own making
It really isn't. Its expensive to test cars, and its also necessary for safety.
> It is indeed the role of law enforcement to enforce the laws.
Yes, which get codified as regulation.
> Is your argument that it isn't an unfunded mandate
Again, if my argument was something you would find out.
I'm saying what I'm saying: your arguments don't make sense, they are hyperbole, I am not defending or attacking a specific take on regulation, other than the take that, guess what, its hard.
> No, if that was my position, you would've found out by me saying that was my position.
That was the contrary to the thing you were originally incredulous about.
> Why would they have such an incentive?
Why would members of the government have a structural incentive to pass laws at the behest of special interests? Because they get money for it.
> It really isn't. Its expensive to test cars, and its also necessary for safety.
If it's worth more to the public than it costs then the public should pay for it. If it isn't worth more than it costs then it shouldn't be done. Why would either of these be a problem?
> Yes, which get codified as regulation.
If the bank takes your money and loses it at the casino, they're going to be in trouble, and they're supposed to be in trouble.
If the bank takes your money and it's all still in the vault and was never at any risk, but the government wants to punish them for letting you open an account in the name of your dog, or for not filing enough suspicious activity reports even if it requires filing them against innocent people, the government is wrong and the bank should not be in trouble for that.
> Again, if my argument was something you would find out.
Apparently I wouldn't, because there are only three options and you're not revealing which one you believe. Is it:
a) an unfunded mandate
b) not mandated
c) the government is funding it
That is the entire solution space, it has to be at least one of those, so which one is your position?
> That was the contrary to the thing you were originally incredulous about
Indeed, and not everything or everybody in the world consists of completely contrarian opposite opinions :-)
> Why would members of the government have a structural incentive to pass laws at the behest of special interests? Because they get money for it.
Not in a functioning democratic government, i.e most of them.
> If it's worth more to the public than it costs then the public should pay for it.
I think you should write a 10 page book that solves all the worlds problem by just taking surface-level obvious directions on big nuanced topics, I'm sure it will be transformational.
> and they're supposed to be in trouble.
Again simplified, the bank doesn't do this. It does things similar to it, how similar is too similar? That's what regulation tells you.
> because there are only three options
Again, no there aren't. I understand that you feel this way, but things can differ on a case by case basis without being hypocritical. The world is complex, unique circumstances require unique responses. Overly unique responses create bureaucracy and overhead and edge cases. Neither is ideal. Walk the line, balance it out, that's governments' job. Do they always succeed? No. Can the problem be solved by a two paragraph simplified solution on an online board? Also no.
Needlessly polarizing every topic into dogmatic rules is exactly the thing you are accusing governments of, and are yourself now doing. Reality is harder than mathematical or rhetorical logic, because of ethics, because of complex interacting systems, because people don't act rationally, because people don't act in their own interest etc etc etc.
There are plenty of governments that use tools to overstep their bounds, yours included, those same governments are also using tools to protect people from harm. Both tools are the same tools.
They generally don't, because you don't need banners to store cookies that you need to store to have a working site.
In other words, if you see cookie banner, somebody is asking to store/track stuff about you that's not really needed.
Cookie banners were invented by the market as a loophole to continue dark patterns and bad practices. EU is catching flak because its extremely hard to legislate against explicit bad actors abusing loopholes in new technology.
But yeah, blame EU.
And before you go all "but my analytics is needed to get 1% more conversion on my webshop": if you have to convince me to buy your product by making the BUY button 10% larger and pulsate rainbow colors because your A/B test told you so, I will happily include that in the category "dark patterns".
Let's not deceive ourselves -- first-party analytics are much, much harder to set up, and a lot less people are trained on other analytics platforms.
They're also inherently less trustworthy when it comes to valuations and due diligence, since you could falsify historical data yourself, which you can't do with Google.
The regulation is only concerned with cookies that are not required to provide the service. It makes no differentiation between first party and third party - if you use cookies for anything optional (like analytics) you need consent. So you can have third party non-cookie analytics for example without a banner.
Do you know an analytics service that actually does this? I've seen a bunch of "consentless" analytics solutions that seem to be violating GDPR one way or another because they use the IP address as an identifier (or as part of one).
Can you actually do meaningful analytics without the banner at all? You need to identify the endpoint to deduplicate web page interactions and this isn't covered under essential use afaik. I think this means you need consent though I don't know if this covered under GDPR or ePrivacy or one of the other myriad of regulations on this.
So take the IP, browser agent, your domain name and some other browser identifiers, stick them together and run them through SHA3-256, now you have a hash you can use for deduplication. You can even send this hash to a 3rd party service.
Or assign the user an anonymous session cookie that lasts an hour but contains nothing but a random GUID.
Or simply pipe your log output through a service that computes stats of accessed endpoints.
I think this scheme still requires consent since you are processing pseudo anonymous identifiers that fall under personal information without the essential function basis. Hashing is considered insufficient under the GDPR iirc. Have you asked a lawyer about this?
> You need to identify the endpoint to deduplicate web page
You can deduplicate but you cannot store or transmit this identity information. The derived stats are fine as long as it’s aggregated in such a way that preserves anonymity
No one needs to deduplicate over a longer period than a few minutes, or a single session. If you need that, then you're doing something shady. If a user visits your site, clicks a few things, leaves and comes back two hours later, you don't need know if it's the same person or not. The goal of analytics is to see how people in general use your website, not how an individual person use your website.
So just take IP address, browser details, your domain name, and a random ID you stick in a 30 minute session cookie. Hash it together. Now you have token valid for 30 minutes you can use for deduplication but no way of tying it back to particular user (after 30 minutes). And yes, if the user changes browser preferences, then they will get a new hash, but who cares?
> No one needs to deduplicate over a longer period than a few minutes, or a single session. If you need that, then you're doing something shady. If a user visits your site, clicks a few things, leaves and comes back two hours later, you don't need know if it's the same person or not.
Sure you do if for example you want to know how many unique users browse your site per day or month. Which is one of the most commonly requested and used metrics.
> So just take IP address, browser details, your domain name, and a random ID you stick in a 30 minute session cookie.
That looks a lot like a unique identifier which does require a user's consent and a cookie banner.
> Now you have token valid for 30 minutes you can use for deduplication but no way of tying it back to particular user (after 30 minutes)
The EU Court of Justice has ruled in the past that hashed personal data is still personal data.
> And yes, if the user changes browser preferences, then they will get a new hash, but who cares?
It will also happen after 30 minutes have passed which will happen all the time.
> Not rocket science.
And yet your solution is illegal according to the GDPR and does still not fulfil the basic requirement of returning the number of unique users per day or month.
In terms of whether or not the ubiquity of cookie banners is malicious compliance or if it was an inevitable consequence of GDPR, it doesnt matter if trackers are good or necessary. GDPR doesn't ban them. So having them and getting consent is just a normal consequence.
We can say, "Wouldn't it have been nice if the bad UX of all these cookies organically led to the death of trackers," but it didn't. And now proponents of GDPR are blaming companies for following GDPR. This comes from confusing the actual law with a desired side effect that didn't materialize.
> And now proponents of GDPR are blaming companies for following GDPR.
Not really, proponents of GDPR are aware that GDPR explicitly blocking trackers would be extremely hard as there is a significant gray area where cookies can be useful but non-essential, so you'd have to define very specifically what constitutes a tracker or do a blanket ban and hurt legitimate use-cases. Both are bad.
For some reason though people think that the body that institutes laws that try to make the world a better place, when loopholes are found and abused for profit, this is somehow the standard body making a mistake, rather than each individual profit-seeking loophole-abusing entity being the problematic and blame-worthy actor.
I never understand why, I guess you work somewhere that makes money off of this.
I'm not sure how you got to this conclusion. The answer is a simple google away: smaller companies face lower taxes, lower standards of documentation on health & safety, don't need work councils, less reporting on workspace/financials, etc etc etc.
My point is these societies have the rule of law, and the vast majority of laws don't have a "unless you have 50 employees or less" or "unless your revenue is under $1 mil" qualifier. The difference in treatment is often a complex precedent of leniency in enforcement or punishment, but ultimately the rules are the same for everyone, even if you have to upset the 8 year old selling lemonade.
"I have spent more than $500 dollars on pants before, because I'm lucky to be in a position where for me these things are a matter of taste and whim, rather than budget, and don't really affect my finances too much whether I do or don't buy them."
I don't think I have to explain to you how the gap between what you said, and what I wrote above, is what is causing offense here. You likely deserve 100% of your success, but its just common sense to obscure the specifics of it if you are way out of band in relative terms.
Its like saying: "You know, I never really get ill" at the cancer ward. Sure, its true, but read the room.
Well, after all it’s HN and this is the kind of content that attracts much of the users. I’d certainly be more careful with that wording on a website that caters to a very different audience, but it’s not long ago when indiehackers posts of people “bragging” about their successes were consistently at the top of the front page.
Not convinced I misread the room, especially considering the upvotes.
> don't really affect my finances too much whether I do or don't buy them
Isn't this the same brag as before?
I can't tell how this is different than throwing some numbers in the mix, the person relating their personal experience expresses they have fuck-it-bucks either way
Not naming numbers is precisely the point, because you obfuscate the reality of the size of the gap, which in the end is what everything is about. The gap creates the offense. Everybody knows there's rich people, but being confronted by exactly how rich, to the detail of a number, is the offensive part (if done by that rich person without any clear reason).
I'm not sure why people keep piling up to pretend this is such a normal thing, this is literally why people don't discuss salaries despite it technically being in their own interest: specifics ground the fuzzy notion of inequality into reality like nothing else.
The offensive post inflates the perceived inequality from "500$ pants is too much for pants" to "10k means nothing to me" while my version leaves the specifics outside of the conversation. In my version, the person could put the level of "too expensive for pants" at 1k, still an order of magnitude lower than the offensive post.
Finally, I acknowledge that this is a privileged position to be in explicitly, because that signals that you are aware that this is an exceptional situation to be in (which I'm not sure the offensive post author is aware of, even now).
Like meta with the metaverse thing, I hate it with a passion, but pouring billions yearly with little return just to support your vision is at least a break with tradition...
reply