Gemini (3.0 Thinking) solves it too.

I strongly disagree with this: calling your thing that serves webhooks “webhooks” or “webhook-service” sounds nice and neat when you’re looking in a repo list but you immediately impose a tax on everyone in the org: now everyone in a conversation has to distinguish between “webhooks” as the proper name of a particular service and “webhooks” as the name of a particular pattern. Multiply this by all the various components of a modern software ecosystem, and you turn your companies infrastructure into a private language piecemeal and, what’s worse, it’s a private languages outsiders and newcomers think they understand and so they often take much longer to discover what the actual services are.

I wish people would stop promoting the singleton pattern: in almost every case I’ve seen, singletons are unnecessary tech debt and solve a problem that’s better solved with some form of dependency injection (and I don’t mean the XML/YAML monstrosities various frameworks force on you but rather constructor arguments or factory functions)

The site is not "promoting" the singleton pattern. In fact, there is a "Tradeoffs"[1] section that calls it an anti-pattern in JavaScript.

In spite of that, there are plenty of reasonable use cases for singletons in many languages, including JavaScript. For example, ES Modules are effectively singletons. If you import the same module in multiple places, it only gets evaluated once.

Let's not turn the singleton pattern into forbidden knowledge.

[1]: https://www.patterns.dev/vanilla/singleton-pattern/#tradeoff...

Why pose DI as replacing singletons when they're used together all the time? Injecting dependencies to create a singleton repository or service class, which is shared across requests.

Singletons are globals and should be treated the same as every other global (that is, used sparingly and with care).

Worse is that singletons enfurece a single instance which is almost always unnecessary. It’s trivial to only create as many instances as you need.

Off the top of my head, rails (currentattributes), Laravel (facades) especially, and most iOS apps use singletons quite well. It’s all in moderation and depends highly on how it’s used, much like every other design pattern.

I think people just don’t like Singletons because they’ve been especially misused in the past but I guarantee the same argument stands for any other design pattern.

Yes, I have to admit my interest was piqued by the banner, and I then scrolled down, saw the first example was singletons, and closed the tab.

Yeah, the liberating thing for me in CL is that things just don’t break as much as they do in other ecosystems. So, when I get breaking changes I look for an alternative that doesn’t break.

But how the data got sorted is irrelevant to the speed of the algorithm: for example, you could use binary search as part of an algorithm to find the insertion point of a new element in an always sorted data structure, meaning that sorting the data is never necessary.

The overall journey matters. For example, for some flight journeys, the flight-time is only a fraction of the overall time taken by the journey, which could makes it faster if you use road or rail transport. Flight speed doesn't matter.

But that is an unanswerable question which depends on how the data structure is used. The reasonable thing is to calculate the cost for the operations separately and let whoever uses the algorithms figure out what that means for their use case.

The thing that got me was always referring to Scaleway in the third person. e.g. this read like the response I get when I ask AI to review code:

> Scaleway’s solution to that problem was ingenious: embedding a Raspberry Pi module with each Mac mini.

(I realize this may be an artifact of a corporate style guide, but I'd much prefer "Our solution to that problem was embedding . . ." Both because the "was ingenious" doesn't add a ton and reads like puffery and because this is Scaleway's own blog and referring to yourself in the third person is grating.)

To me, it just reads like their marketing person's first language is not English. Which tracks because I believe the whole company is based on France.

Every several years people reinvent serializable continuations

Yupp, making that same point in the post :)

> You could think of [Durable Execution] as a persistent implementation of the memoization pattern, or a persistent form of continuations.

Haha so true. Shame image based programming never really caught on.

Janet lang lets you serialize coroutines which is fun. Make this sort of stuff trivial.

unfortunately they've never really taken off so folks reach for explicit state machines instead. there have been a handful of options on the jvm over the years (e.g. quasar, kilim) but they're all abandoned now, the loom continuation API is internal with no hint of it becoming public, kotlin's aren't serializable and the issue is inactive (https://github.com/Kotlin/kotlinx.coroutines/issues/76), etc.. such a shame

The C in CDE is “common” because it was a collaboration between the major Unix vendors on a standard for how Unix desktops worked.

On the other hand, Java's tooling for correctly refactoring at scale is pretty impressive: using IntelliJ, it's pretty tractable to unwind quite a few messes using automatic tools in a way that's hard to match in many languages that are often considered better.

I agree with your point, and I want to second C# and JetBrains Rider here. Whatever refactoring you can with Java in JetBrains IntelliJ, you can do the same with C#/Rider. I have worked on multiple code bases in my career that were 100sK lines of Java and/or C#. Having a great IDE experience was simply a miracle.

The language Kotlin is actually developed by JetBrains

I've found that IntelliJ's refactorings don't work as well for Kotlin as Java but, also, I've avoided Kotlin because I don't like it very much.

This shouldn’t be hard to deal with if the timestamp is always serialized with the offset: I’m much more picky about always persisting the offset than about always persisting UTC