ttfkam

Transactional DDL!

Or when the version is EOL, not getting security patches, and/or only compatible with an OS that isn't getting security updates.

…or you're on AWS RDS, which will automatically bump your db cluster if it goes EOL and you ignore the notices for more than a year.

Since v16, Postgres supports bidirectional logical replication out of the box. In other words, multiple writers.

It is a PITA, but I've written scripts that pg_dump just the schema, load the schema into the new db with the new version, set up logical replication between the two, wait for them to sync, reset all the sequences, and rebuild indexes before doing the handover.

It works with basically no downtime but I agree this kind of thing should definitely be easier, even turnkey.

> My experience has been that they spin up either a hideously under or over-provisioned RDS or Aurora instance, and then never touch it until it breaks

That's a true shame considering how easy it is to make a read replica of any size and then fail over to it as the new primary. Definite skill issues.

> none of them could articulate what part of its feature set they actually needed to use.

Transactional DDL: migration errors never leave the database in an intermediate/inconsistent state.

Range types + exclusion constraint: just no way to do this in MySQL without introducing a race condition.

Writeable CTEs: creating insert/update/delete pipelines over multiple tables deterministically. Seriously though, the RETURNING clause is something I use all the time both in and out of CTEs.

Filtered aggregates and grouping sets: cleanly get multiple data points for a dashboard in one shot.

Unnest: converting arrays into a set of rows. Inverse of array_agg(...).

Types: arrays, booleans, IP/subnets, UUIDs (without binary(16) hacks), etc.

Materialized views: seriously, how does MySQL not have this yet?

Statement-level triggers: another option from per-row.

Row-level security: setting data visibility based on configurable policies.

I can cite specific use cases I've deployed to production for each of these and more.

Every company has folks that don't even care sites like HN exist.

Learning how to do all of this is laudable for the same reason that learning LinuxFromScratch is a stupendous way to learn how Linux works and to get a job doing lower level maintenance work.

That said, everything on your list is provided out of the box with managed cloud vendors like AWS's Aurora DB clusters.

Replica lag: check.

Primary and replica status checks: check.

Auto-failover with strategies: check.

Split brain: I'll be honest, this is a deceptively hard problem that is strongly dependent on use cases and setting expectations. CAP theorem exists for a reason. Do NOT trust anyone who tells you they have a one and done solution to this. They're selling snake oil.

After failover recovery: check.

----

Please note that I recognize you want to learn this for yourself, and I wholeheartedly encourage you to. I think it's important to know that there are already mature solutions out there that trade money in exchange for your time to be spent in other areas.

> This is the major barrier. It's a difficult language to learn for people who've worked with a compiled, strictly typed language with manual memory management.

This was not what Google and others found when they studied it.

https://www.theregister.com/AMP/2024/03/31/rust_google_c/

> More significant, Bergstrom said, is the comparison of rewrites of C++ code into Rust.

> "In every case we've seen a decrease by more than 2x in the amount of effort required to both build the services in Rust as well as maintain and update those services written in Rust," he said.

I'd put even more concerns on C++. All the same concerns plus all the concerns that arise from the compiler not helping you nearly as much. It's easy with C++ to be lulled into a false sense of security because it compiles, and your trivial happy path works. Under load or with unforeseen input, the chance for memory corruption is massive even for experts let alone beginners because it only takes one to bring down a whole process.

C++ is better than it used to be, but it was truly atrocious in that regard for decades. It was simply the least worst option for those decades.

I do not consider it the least worst option anymore.

A garbage collector really takes away a huge amount of cognitive overhead. In doing away with it, Rust requires that you understand the borrow checker and lifetimes, even if minimally due to extensive use of .clone() in your early code. This ties into all of the different kinds of strings in Rust from str to string to vec[u8], etc.

Unlike Go that only really requires experience in general programming to become rapidly productive, Rust basically requires that you read The Book in its entirety before you even think about applying that knowledge in production. There are just to many interdependent concepts to hand wave away the prep time. It all (mostly) makes sense once you've familiarized yourself with the basic concepts, but it's a training step you simply cannot skip without inflicting a fair amount of pain on yourself and others.

If a garbage collected language can easily do the job, choose the garbage collected language. I like Rust, but it is NOT the fastest language to develop in.

Typescript, Python, Go, Swift, and even Bash depending on the situation are all quicker to code in than Rust.

If any of those languages are inadequate for the requirements whether they be memory-bound, CPU-bound, or sensitive to gc pauses, Rust is an excellent option that is far superior to C++ in 2024 and beyond.

The notion of "one true language" has always been and will always remain a fool's errand.

Another use case is when you need a systems language for a user-facing app (even if not directly connected to the internet) and would have reached for C++ previously.

Memory corruption bugs are no joke. If you've got staff that already knows C++, their ramp up time for Rust will be much shorter compared to typical devs working only in Python, JS, etc.

A shame the only two choices were Htmx and React.

Tauri is indeed heading to mobile.

https://v2.tauri.app/blog/tauri-mobile-alpha/

It's all fun and games until California employees actually experience Texas: the heat, the bugs, and open carry everywhere. Good luck with that, Musk. Theory and practice are not going to get along well, especially since a certain GOP candidate just threw you under the bus.

What do YOU mean, "You people"?

https://youtu.be/99IoN2pymfE?si=xF1me0YbEaK_bvlV

> I'm not sure there is enough pain for them to get replaced anytime soon.

https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...

https://blog.cloudflare.com/pingora-open-source

90 out of 114. 24 eluded me.

I'd rather go to Svelte for lower bundle size than Preact, better performance than Preact, and clearer code with fewer lines written than Preact.

Sure, I'd lose access to the React ecosystem, but I'd also gain access to the vast ecosystem of vanilla JS libraries without having to write/use a wrapper, so that's a wash. (bind:this is awesome!)

So how small can you get for a hello world page with a single "hello $name" component, spending an hour or less on it?

The "reconcile" (my God do geeks love making what they do sound fancier than it is) does not match the HTML5 parser "reconciliation" spec. The DOM element API "emissions" match the order triggered by the markup parsers. Y'all are tiresome sometimes.

What's the smallest "Hello ${name}" hooked up to an input field you can make deployable in React?

Svelte's is about 2.1KB last I checked. Can React get below 40KB?

So… you can use other markups seamlessly like SVG and MathML… just like XHTML. Walk like a duck, talk like a duck.

As I said, I don't like coding in C.

1. React doesn't have less boilerplate than the average let alone most.

2. You haven't seen Angular lately, have you? It's on 18 now. 15 and 16 really trimmed things down.

Do you have to close all of your tags? Yes. Is the markup based on HTML with XML rules like closing tags? Yes. Do you even have to close the tags of your custom components? Yes. When generating your createElement sequence from JSX, does it create or close tags in a different order/hierarchy than what you specified in the JSX? No. Does it emit markup or element creation calls that match the parsing behavior of HTML5? No.

Walks like an XHTML duck. Talks like an XHTML duck. It's an XHTML duck despite the JS interop and the lack of DTD preamble.

Postgres. I don't code in C if I can avoid it, since it often feels like an awful lot of extra typing while still having to worry about memory safety. But the Postgres codebase is extraordinarily well organized and respects the humans that work with it with its intelligent handling of memory and judicious use of macros.

I consider the core Postgres codebase to be the gold standard in development even though it's in a language I do not prefer to write in if given the choice.

Shout out to the pgrx folks. You're awesome! https://github.com/pgcentralfoundation/pgrx

Learn JavaScript first, then React. Far too many devs know the React APIs without any context. If you know JS/TS, any framework is learnable. If you don't, your React code will never improve past mediocre and bloated.

Strong foundational knowledge in HTML and CSS helps as well. Still amazes me how many folks put onclick handlers on div tags and freak out when margins collapse.

The fact that you have to go to often heroic measures to keep your bundle size under 500KB even for simple apps doesn't make it irrelevant or useless. It is indeed bloated: on the development boilerplate side, the bundling/deployment side, and the browser runtime experience.

With an experienced and top-notch developer, anything is possible in any language or framework. For the other 95% of devs out there—especially on a team where the lead doesn't keep a strong grip on the reins—React turns to mud awfully fast. But it's mud with an extensive ecosystem and tons of inertia helping it succeed.