taking a step back, if your application's db requirements can be satisfied by sqlite [+replication] then that's great, but that set of requirements is much narrower, and much easier to solve, than what postgres is for

probably worth stating these kinds of design considerations/assumptions up-front

i'm sure lots of applications are fine with "downtime for [database] migrations" but lots more are definitely not, especially those interested in synthetic metrics like TPS

sorry, what?

https://gaultier.github.io/blog/a_million_ways_to_data_race_...

this code is obviously wrong, fractally wrong

why would you create a new PricingService for every request? what makes you think a mutex in each of those (obviously unique) PricingService values would somehow protect the (inexplicably shared) PricingInfo value??

> the fix

https://gaultier.github.io/blog/a_million_ways_to_data_race_...

what? this is in no way a fix to the problem.

it's impossible to believe the author's claims about their experience in the language, this is just absolute beginner stuff..

this only works when the language defines a memory model where bools are guaranteed to have atomic reads and writes

so you can't make a claim like "setting a field to true from ... multiple threads ... can be a meaningful operation e.g. if you only care about if ANY of the threads have finished execution"

as that claim only holds when the memory model allows it

which is not true in general, and definitely not true in go

assumptions everywhere!!

there is this whole demographic of folks, including the OP author, who seem to believe that they can start writing go programs without reading and understanding the language spec, the memory model, or any core docs, and that if the program compiles and runs that any error is the fault of the language rather than the programmer. this just ain't how it works. you have to understand the thing before you can use the thing. all of the bugs in the code in this blog post are immediately obvious to anyone who has even a basic understanding of the rules of the language. this stuff just isn't interesting.

matrix's users want it to be a decentralized/encrypted irc/slack, but unfortunately matrix's maintainers believe their mandate is to build a next-gen tcp/ip (or something very close to that)

which dooms the project

> Grok is more right leaning than most other AIs, but it's still left of center.

https://github.com/promptfoo/promptfoo/tree/main/examples/gr...

> Universal Left Bias: All major AI models (GPT-4.1, Gemini 2.5 Pro, Claude Opus 4, Grok 4) lean left of center

if every AI "leans left" then that should hopefully indicate to you that your notion of "center" is actually right-wing

or, as you said: reality has a left bias -- for sure!

> they were designed to turn single-threaded code into multi-threaded

not really

> usually a single point of contention quickly becomes a problem.

not generally, no

> They're liable to deadlocks/livelocks,

deadlocks/livelocks are orthogonal to any specific primitive

> They're also often backed byOS primitives (with big overheads) with inconsistent behaviors between platforms (spinlocks, waiting etc).

the mutex as a primitive is orthogonal to any specific implementation...

etc. etc.

god forbid someone prioritize concrete user experience over abstract interoperability

in practice, few, if any, of your enumerated "wants" are valuable enough to outweigh their costs to complexity

this should be pretty clear from the fact that statistically nobody uses pgp

companies actually can build and ship stuff that isn't inter-operable with the world, this is Actually Good for user experience

so if you wanna talk about it you at least gotta say which definition you're using

otherwise, not sure who the audience of this piece is supposed to be, but it's written in a pretty combative tone, which will not be persuasive to anyone who isn't already persuaded, so i guess more of a rant than anything worth sharing here