kiitos

1h of downtime per month means you're delivering at best two 9s of availability. again that may be fine for lots of applications but it's trivial scale, and certainly a couple orders of magnitude below what aws and cloudflare provide

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

> You're going to have down time for migrations unless you're very clever with your schema and/or replicas.

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

and that your application doesn't need to be resilient to host or network faults

"setting a field to true" clearly means `x.field = value` and not `x.field.Set(value)`

> setting a field to true from potentially multiple threads can be a completely meaningful operation e.g. if you only care about if ANY of the threads have finished execution.

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!!

the distinction between "concurrent use" and "concurrent modification" in go is in no way subtle

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.

"running into memory issues" doesn't relate to memory safety as a property

> Matrix wants to be an encrypted IRC or Slack

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

this is an overly simplistic and somewhat reductive perspective on a pretty fundamental concept/primitive

> 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.

what? stone ages?

god forbid someone prioritize concrete user experience over abstract interoperability

I think you're wildly over-indexing on a statistically insignificant number of users and their expectations

you're just affirming the consequent here, listing various properties of pgp as requirements

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