jack_squat

Like most online forums, HN discussions are dominated by people who like to spend all their time online arguing with people. It's the 80:20 principle, or the 90-9-1 principle. Largely these are early-20s, politically ignorant men, with a long tail of socially stunted "greybeards" who have not managed to find greater fulfillment in life than what online discussion forums provide. The technical topics here are frequently recycled and the quality of discussion is not that notable. I'm embarrassed it took me over a decade to reach this conclusion.

I don't think the readership of HN leans RW, but the commentary and moderation does, largely due to the fact that RW commentators are quick to flag views they disagree with, in contravention of the stated moderation standards, while "normal people" can't be bothered to engage with this kind of platform, and the moderation team is content to let this dynamic persist. Witness the flagging on this very article as an example.

My prediction is it'll be Cruise in red states and Waymo in blue states. I think they are done in SF but this will endear them in TX.

I've done the Postgres skip locked thing at least three times and I'm currently doing it, but IMO it is actually more maintenance and overhead, not less -- at least when compared with the queues made available by the major cloud providers. Compared with Pubsub or SQS you need to handle,

* Metrics, monitoring, alarming on depth, message age

* Autoscaling on your custom metrics

* Managing retries, dead lettering, backoff

* Managing the DB workload: it's update-heavy and may easily be more intensive than the rest of your app. You may need to repeatedly scale your tiny, startup-scale DB, causing customer disruptions, because of your homemade queue.

The arguments for it are either avoidance of lock-in, or the hand-wavy one in this article/many comments: "we're a small startup, we need to minimize complexity, and make things as simple as possible, maintenance will kill us!".

Lock-in makes sense (though other queue alternatives should still be considered), but the latter argument gets used to justify all kinds of harebrained, superficially-simple but actually-complicated engineering schemes. I generally put the PG skip locked approach in that bucket, particularly when the alternative on hand is Pubsub or SQS. If it's between a Postgres table and ActiveMQ I might feel more conflicted.

Typically you try and avoid closing a connection on each request, you hand it back to a connection pool. The underlying session stays open and associated with the connection (if you have your pooler set up right), so subsequent requests still use the cache.

I agree with the original commenter about ANY as well: using IN for dynamic lists of parameters makes viewing useful information in e.g pg_stat_statements impossible, though it's possible there's been some recent work around normalizing these.

The author's site is primarily poorly-researched and hyperbolic BS, mostly to provide cover for his political hot takes.

Example: https://scottlocklin.wordpress.com/2021/11/20/us-public-heal...

No piece of software has influenced my career and my thinking on design, user interfaces, and software quality as much as VIM. VIM made learning to code as fun as playing a game. Thank you Bram, you changed my life.

When you use a surrogate key, you should still put a unique constraint on an alternate key. Multiple records for the same thing is a fundamental problem in a database.

I also tend toward surrogate keys, and would also point out that the overhead concerns frequently weigh in favor of them as well (though not always).

If your natural key is bigger than the appropriately sized surrogate key, and it will be referenced across the database in other tables, the overhead of referencing it everywhere (and indexing it in those places -- potentially in much larger tables) can easily outweigh the overhead of the extra bytes on the original table.

Additionally, surrogate keys can realize much better performance WRT cache locality.

Atomicity doesn't mean "doesn't fail", it means "either fails or succeeds, but does not succeed halfway".

There is nothing about what you are describing that is different from the behavior you'd get from a regular insert or update. If two transactions conflict, a rollback will occur. That isn't violating atomicity. In fact, it is the way by which atomicity is guaranteed.

The behavior of sequence values getting incremented and not committed, resulting in gaps in the sequence, is a separate matter, not specific to Postgres or to upsert.

1NF bans relation-valued attributes, not repetition of attribute value across tuples in a relation. Mainstream SQL databases don't support relation-valued attributes, so any table you make in a relational database is 1NF.

You can push back on this a little - for instance maybe you consider an array-valued attribute to be enough like a relation to argue array-valued attributes violate 1NF. But if you do that you must also explain what makes arrays different from strings, since strings are pretty similar to arrays of characters and can be treated the same way in most respects (for instance characters in a string can be addressed by index or split into substrings).

From the Postgres docs,

ON CONFLICT DO UPDATE guarantees an atomic INSERT or UPDATE outcome; provided there is no independent error, one of those two outcomes is guaranteed, even under high concurrency. This is also known as UPSERT — “UPDATE or INSERT”.

https://www.postgresql.org/docs/current/sql-insert.html

What are you referring to?

Am I alone in feeling there is nothing left to be said on this topic? Correct application design, and balancing that against the constraints of getting a product out the door, the requirements of a particular application, and the resources on hand (skill-sets, developers, infrastructure) does not in my opinion boil down to "microservices vs monolith".

Both strategies have tradeoffs, both have produced successes and failures, and choice of approach seems (obviously) too specific to a given context and application for general advice to apply.

FTS is not the same as regex.

RI has the same approximate population as AK. What people mean when they say land votes, is AK compared to NY. AK has a population of < 1M while NY has a population of > 8 million. Proportionally, Alaskans have > 8x the representation in the senate that New Yorkers have.

what the comment describes is actually a central point of the "Easy Way" book mentioned many other places in this thread.

If something is "likely", I would assume it's more likely than not.

Regarding trains anyway, a) there have been autonomous trains for decades and the numbers are increasing. b) there are 100x as many professional drivers as train conductors in the US - so it's easy to see why the focus on driving. That's where the money is.

IMO if a solution requires users to address data by page, it's a sign that the search functionality is not good enough.

In general a user doesn't want to find "page 3", they are looking for a record that has certain characteristics. They shouldn't need to think about pages, just search terms.

I would suggest quitting coffee if you are curious about that. Do it on a Thursday and you will probably be fine by Monday. Try it for a couple weeks and evaluate, most likely your productivity will be unaffected. Your boss won't notice.

On the more general question of whether stimulants are necessary for work... my experience is this idea is bizarre and out of line with professional programmers more than a few years out of university (where desperate students take adderall to cram for exams, and thus come into the workforce with that somewhat normalized).

Once a few years out you will have so many employment options that the idea of risking your heart health for a programming job will seem asinine... like biking to school without a helmet.

Do you think that's how it works? I have no idea, what's your evidence?

California's actions seems pretty consistent with this to me: https://storage.courtlistener.com/recap/gov.uscourts.cand.31...

Proxy war means no boots on the ground. The two of you agree.

In my opinion "infinitesimal" is too small. I think at this point a nuke strike is a bigger risk than covid, for most.

This is the R resource I recommend: https://www.amazon.com/Using-Introductory-Statistics-Chapman...

Takes a weekend to work through the book and you get a statistics refresher as a bonus.

The responses in this thread were unusually crazy/crass/rude before moderation apparently stepped in. I dunno if that was a glimpse of "unmoderated HN" or if this topic in particular draws out emotions.

My understanding is cardiac deaths early in life are mostly caused by congenital issues that are more likely to shake out under stress, and those late in life are dominated by issues acquired via lifestyle.

Among people under 35 (most athletes) athletes are at significantly higher risk. It's possible tables turn later in life, can't really find a source. Anecdotally I knew two people growing up who died suddenly of congenital heart issues, and both were athletes.

Doesn't that all make sense? I'm not sure what the issue is here.

The statistic that vaccinated people 18-59 are dying at twice the rate presumably true, so of course the reuters article doesn't deny it. The Reuters article presents a totally believable explanation, which is also in the original article's comments. What they are saying is that this can be true for the age range 18-59, but simultaneously not be true for any specific age brackets within that range.

This is called Simpson's paradox. The explanation is that vaccination rates are higher among the elderly than among the young, and that the elderly have a higher baseline rate of death, and the Reuters article breaks out the numbers to demonstrate this. What's the big mystery exactly?

https://en.wikipedia.org/wiki/Simpson%27s_paradox