ak39

I read "man months".

Off-topic: TIL wal2 mode in the works. Wow. That's a no-brainer feature, IMHO.

Is the 300x performance boost attributable to the threading model vs process model?

Was the code for the threading model written by hand or was it translated from the WIP threading model the human PG team is busy with as part of the 2028 roadmap?

Chuckled at the anti-climactic sentence ending! lol

Unlikely. It goes further by also using the word "exploit".

If they needed permissions for conversion, they'd have made a specific mention of that and thereafter confirmed legal ownership.

Genuine question: how did you figure this was AI generated? (If that is what you meant.)

Nice.

Is if a one thread per request model?

Does it support async await type of architecture?

By definition, a FK has to reference a PK in the “parent”.

Same

Shouldn't there be a unit test to confirm landlock is on/off? (I mean, this seems a crucial aspect of the code which needs 100% test coverage.)

Yip, this was impressive. Only a copy & paste into VSCode (Windows) revealed the rectangle around the "c" in the second line.

Impressive.

Thank you. Also, what database was in use?

Thanks for the easily understandable TLDR!

And here I thought Snowflake was for the data model!

Indeed. It's by no means "straightforward"

I didn't say we should ignore splits. To reiterate: most third-party data providers include splits by restating historical prices. This only works if you want to analyse performance at individual stock level by ignoring holdings. But if you want to do performance analysis for your own portfolio of stocks, relying on restated prices is incorrect.

Eg. If you bought say 10 stocks at the old price, you cannot take the restated historical price with your 10 stocks and you cannot take the units held of 10 stocks with the new prices. You have to account for this via transactions to increase your holdings (for splits) by leaving the prices historically the same.

Valuations are straightforward in a world without corporate actions like splits, consols, dividends etc.

Most (all?) data providers rerate historical prices after corporate actions that affect prices and this is not really the correct way to do continuous valuations using the restated prices.

ORMs and NoSQL were a direct result of the desire to have an object-oriented data worldview in a programming landscape dominated by OO languages. They were not introduced because programmers didn’t want to learn SQL (implying incompetence etc).

Node might not, but Javascript (even on the server) will mostly be.*

* assuming that the 100 years hyperbole is accepted

Please don't stop there! How did the conversation go? How did he convince you that you won't be double-crossed?

Terminating a bus factor 1 employee is not the problem. The real problem is not recreating BF1 reloaded with the new hire. Even a team of two is not completely ideal.

Many, mostly small, companies just cannot justify an IT department to mitigate Bf1/2 risks. Also, most times this bus factor problem manifests in non-IT jobs too: sales, contract law, accounting functions.

Small companies need to first become big companies to afford de-risking from BF1. Part of the growth story really.

Nice!

Finally: https://youglish.com/pronounce/been/english?

"Been" pronounced "bin" is slowly moving to "ben" (mostly in the US usage).

LOL. What did this comment (no pun!) do for your HN karma points?

SQLite not supporting "stored procedures" is a deal-breaker for me. The idea for stored procs is not to "put the process as close to the data" but simply that we have a single place for language-agnostic encapsulation of data procedures.

Paul MM Cooper's podcasts and video essays on YT are excellent. There's info on Mansa Musa in this episode: https://www.youtube.com/watch?v=GfUT6LhBBYs

A whole new generation of developers is learning what the previous generation termed "briefcase applications". When client-server applications were the thing late 90s and early 2Ks, internet speeds were a serious limitation. This forced many architectures to work with "local-first", disconnected dataset, eventually-synchronised desktop applications. Microsoft ADO famously touted the "disconnected dataset" for this after Borland's "client dataset" pioneered this concept for the Windows desktop. Eventually even Java got disconnected datasets. All these techs more than two decades ago had real practical problems they solved: one of them I worked on involved collecting water flow data from several thousands of rivers in Southern Africa. Hundreds of users had mobile laptops that fired up desktop apps with authentication and business rules. Users then came back to head office to synchronise or used a branch with network to upload.

They worked and they were necessary.

Things changed when internet connectivity eventually became cheap and ubiquitous and the complexity of developing such applications then didn't merit the effort.

Now, the swing back to "local-first" is mainly for user-experience reasons. The same theoretical complexities of "eventually synchronised" that existed for the "briefcase app" are still present.

Is the complexity worth it though?

Slightly off-topic:

The top Reddit response cites some good reasons why this may be so. The writer mentions they needed to move from Node to improve "throughput" (and .NET was suggested). In what way would .NET improve performance that Node can't satisfy. (Isn't Node's worker thread sufficiently close to ASP.NET, ISAPI multi-threaded scenarios?)

Does it handle stock splits, consolidations, dividends etc? Calculating returns (basically tracking growth) is a non-trivial problem.

Always use surrogate primary keys. Use alternate keys (AK) for your "natural keys". Modify the AK business rules as and when needed. There are several advantages to using meaningless random integers, sequential integers or UUIDs as your table's PK. The most important one is that if the PK participates (or is expected to participate) as a foreign key in other tables, it's crucial to us a design where you never ever have to change the PK!

I’ve never truly used DISTINCT and felt comfortable for using it. Always felt using it revealed a design smell in my query. (Been doing SQL for 30 years and still!)