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
797 karma · joined July 22, 2023
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
vlcn-io/cr-sqlite definitely built by someone who doesn't understand the fundamentals of the space
> As of cr-sqlite 0.15, the CRDT for an existing row being update is this: (1) Biggest col_version wins
col_version is definitely something, but it isn't a logical timestamp!
--
https://github.com/superfly/corrosion/blob/main/doc/crdts.md
> Crsqlite specifically uses a "lamport timestamp" which, if you squint at from a distance, could be most concisely boiled down to a monotonically increasing counter.
lamport clocks can be boiled down to monotonically-increasing counters _per physical node in the system_, not per logical row/entity in the data model
so if you want to do conflict resolution based on logical (lamport) clocks you need to evaluate/resolve concurrent modifications according to site-specific logical clocks and their histories -- not just raw integers
which 100% vlcn.io does not do
> destroyed comes before started and so started is "bigger"
eep. good luck!
yep
because "life-saving" isn't a single well-defined boolean condition that can be determined by ER staff as part of triage
> I can't imagine a hospital waiting for an insurance company's approval to pay for a procedure to schedule a child's life saving surgery.
then I guess you've never dealt with major health issues like cancer, blood disease, etc. etc. because what you're describing here happens all the time
the point of a boxes-and-lines diagram is to express relationships between components at a single layer/level of abstraction
the best metric for the "quality" of a diagram isn't the number of boxes, rather it's the number of edge-crossings, where >0 is a pretty reliable signal that either (a) the diagram is trying to show too much, or (b) the architecture is sub-optimal
any non-trivial system will always require multiple boxes-and-lines diagrams to be accurately described, one per abstraction-layer
and not really sure that linking between diagram and code is a core requirement, diagrams will generally include identifiers that are unambiguously grep-able, i guess...
it also seems to conflate how a DAG is expressed, with how that expression is rendered
strange
the core problem with keypair-based systems is that people will lose their private keys, and that has to be accommodated, which requires trust delegation, which blah blah blah we've already worked thru these issues 1000 years ago and the result is representative government
proven for the private market(s) != proven (or even acceptable) for governments
do the risk analysis. what happens when an industry-standard quality control measure fails in whatever way for a private company? some hit to their reputation, stock price, market share, maybe they even fail. these are perfectly acceptable outcomes for a private organization. they are not acceptable outcomes for governments. governments demand (much) higher standards and more stringent processes. slowness is a feature, not a bug.
(hint: the answer is mail-in ballots)
solving problems is an outcome of programming, not the purpose of programming
how then should voters who are not physically present in their voting district cast their votes?