cakoose

The Linus "work of art" quote is slightly misleading. Here it is with more context:

Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn’t perfect, but I’ve skimmed it, and compared to the horrors that are OpenVPN and IPSec, it’s a work of art.

Even with an index, counting the number of rows is an O(N) operation in most DBs.

Why?

1. DBs typically store data in some flavor of b-tree. Determining the number of elements in a sub-range of a b-tree (or any "standard" search tree) is O(N).

2. You can improve that to O(log N) if each b-tree node stores the size of its subtree. But this also increases the cost of add/remove operations.

3. And things get more complicated for DBs that support concurrent transactions, since the count is different for each transaction, depending on when it began running. You'd need something more complicated than just a size-of-subtree integer per node.

It's all doable, but isn't trivial and increases the cost of all add/remove operations.

There have been times where I really wished it existed, though... :-)

City buses seem like a great use case for battery swapping!

Depends a lot on the exact bus system, but thinking loosely about San Francisco: maybe retrofitting ~10 terminals with swap+recharge capabilities means most routes only need 1-2 hours of juice between swaps?

These charts should have the y-axis start at zero. As they are now, I have to convert the bars into numbers, then mentally compare the numbers, which defeats the point of charting them graphically.

Though I guess I can compare the confidence intervals visually :-P

"Some opinionated thoughts on SQL databases" (2021): https://blog.nelhage.com/post/some-opinionated-sql-takes/

There are many factors to take into account, but this article focuses on the "operating reliably in production" factor and says that MySQL has fewer surprises:

As for Postgres, I have enormous respect for it and its engineering and capabilities, but, for me, it’s just too damn operationally scary. In my experience it’s much worse than MySQL for operational footguns and performance cliffs, where using it slightly wrong can utterly tank your performance or availability. In addition, because MySQL is, in my experience, more widely deployed, it’s easier to find and hire engineers with experience deploying and operating it. Postgres is a fine choice, especially if you already have expertise using it on your team, but I’ve personally been burned too many times.

Not always at the cost of the users?

If dceddia is able to add features and fixes more quickly, that's good for users too.

And if Svelte on the desktop becomes popular, people will likely come up with more efficient options. For example, a more efficient Electron or something like "Svelte Native", which could be a good thing.

I'd love if all software were more efficient, but getting up to speed on a new platform has a huge opportunity cost too.

The first idea -- generating the reverse delta while applying the forward delta -- seem obvious. The second idea is clever, but Chrome did it in 2011: https://news.ycombinator.com/item?id=2576878

Even if the ideas aren't novel, getting this thing built and rolled out for Windows is not at all trivial, so good job there. But calling it "new compression technology" is misleading.

Maybe it's because they know some sites will use the title as-is?

KeyDB is a multithreaded fork of Redis. According to their benchmarks, the performance difference is large: https://docs.keydb.dev/blog/2020/09/29/blog-post/

The beginning of article acknowledges that Redis can do a bunch more things and explicitly scopes things down to caching use case:

> None of the the above are going to be covered in any detail. If you do need any of the above functionality, then the answer is use Redis, don't read any further and go for a walk outside.

Does anybody here understand the argument they're making? The language is vague and most examples seem to apply to un-nested transactions as well.

> Additionally, nested transactions can amplify performance anomalies...

This is a function of a transaction's duration and volume of writes, right? Does it matter whether there is nesting?

> It is not just the database state that must be rolled back; all the possible side effects performed by the components holding the transaction must also be rolled back.

Doesn't this apply to un-nested transactions as well? Having external API calls run "within" a DB transaction is common source of inconsistency.

The original was Dijkstra's "Go To Statement Considered Harmful". Many considered that title unnecessarily provocative, but it ended up creating a new CS/programming meme.

Now, I see "Considered Harmful" as just a concise way of alluding to that style of article, basically saying "here are the not-well-known downsides of a commonly-used thing". Many "Considered Harmful" articles do not live up to that promise, but I think this one does.

Another title meme: "Zen and the Art of ...".

Yup, ignoring the costs of memory/storage access (cache, main memory, disk) can hurt an algorithm's real-world performance. Laying your data out in chunks that match the memory/storage blocks sizes (cache line size, disk block size) can yield much better performance.

And while having the algorithm be aware of the chunk sizes in every layer of your memory hierarchy is optimal, it can be inconvenient to get all that set up. But what's cool is that you can often lay your data out in a fractal-like pattern, and get pretty good performance no matter what the various chunk sizes are: https://en.wikipedia.org/wiki/Cache-oblivious_algorithm

Whether P = NP is a long-standing problem. Like many long-standing problems, it's deceptively difficult, which results in many people incorrectly claiming they have solved it: https://www.scottaaronson.com/blog/?p=458

A lot of cryptography relies on NP problems being difficult to solve. If someone figures out a way to solve NP problems in polynomial time, they may keep that technique to themselves rather than publish it. The rest of us might only become aware of this after we see real-world crypto being broken.

In this particular case though, it was just another P = NP paper that was rejected, but accidentally got published.

I think the difference is the all-or-nothing mentality. Nothing is 100% trustworthy.

Even if you write "unsafe"-free Rust that only relies on the Rust standard library, you need to trust:

- The Rust compiler and everything it uses to be correct (not just memory safe), e.g. LLVM.

- The Rust standard library, and everything it calls in to, e.g. system libraries, the kernel, the CPU.

That's a ton of code. By calling into an additional library that uses the "unsafe" keyword, you're just adding that library to your set of things you need to trust.

Naturally, you probably have higher trust in the Rust compiler and OS kernel then you do in some Rust library on GitHub, but nothing is 100%.

And the GitHub Rust library probably only uses a few small blocks of "unsafe" code. That makes it easier to audit and increase your confidence than if it were written in C.

Plus, the Rust safety guarantees don't cover everything. You're still trusting that the library doesn't have a bug that accidentally writes to the wrong file, or sends the wrong value over the network.

C++ defines a memory model, allowing programmers to "rely" on certain guarantees from the compiler and runtime library. But you're still trusting the C++ compiler, the runtime library, the OS kernel, and the CPU to work the way they're supposed to. That doesn't mean the C++ memory model is useless.

This article convinced me to go managed for Postgres: https://rbranson.medium.com/10-things-i-hate-about-postgresq... (2020)

> The good news is that the pain caused by many of the issues brought up in this post can be reduced or eliminated by using a managed database service like Heroku PostgreSQL, Compose PostgreSQL, Amazon RDS for PostgreSQL, or Google Cloud SQL for PostgreSQL. If you can use one of these services, for the love of all that is holy, please do!

Tink seems similar to Plaid, except focused on Europe?

The US DoJ got in the way of Visa's attempted acquisition of Plaid last year.

https://sifted.eu/articles/plaid-visa-tink-europe/

Adding to the confusion is this often-cited article: https://medium.com/@Rich_Harris/tree-shaking-versus-dead-cod...

That article claims that "tree shaking" is different because:

> Rather than excluding dead code, we’re including live code.

That's a misunderstanding of the term "dead code elimination". Classic dead code elimination techniques have always worked by first identifying potentially live code and then eliminating the rest.

This was great!

Reminds me a lot of this classic CS paper: Improving IPC by Kernel Design, by Jochen Liedke (1993)

https://www.cse.unsw.edu.au/~cs9242/19/papers/Liedtke_93.pdf

This looks like an SSH client feature that is invisible to the server. Does the server operator (GitHub) even have to do anything?

As others have said, changing the Bitcoin protocol can be tricky.

Another issue with replacing Ed25519: the best "post-quantum" asymmetric crypto we have so far is a lot less efficient and compact: https://en.wikipedia.org/wiki/Post-quantum_cryptography#Comp...

That'll probably make it more disruptive than, for example, swapping out SHA-1 for SHA-256.

I actually started with Ava for a new project because it did a few things better than Jest. But ended up switching away because of this issue: https://github.com/avajs/ava/issues/2385

Basically, if an assertion fails in the middle of an individual test, most test runners stop executing that test. Ava (by design) continues on with the rest of that test. This makes it harder to debug issues.

(This not be a problem for everyone. I'm only mentioning it because it was a deal-breaker for me and wish I knew that going in.)

I was surprised that every Jest+TypeScript guide says to use ts-jest. I already have my IDE, the TypeScript watcher, and ESLint parsing/compiling all the code! I don't want to add fourth one :-P

I ended up just pointing Jest at my build output folder and that works. There are a couple minor annoyances but whatever.

(I actually started with Ava because it more directly supports using the existing build output, but I ran into another issue and had to switch back to Jest: https://github.com/avajs/ava/issues/2385)

Yes, Rust checks a lot of things at compile time, but not all. For example, dynamic bounds checks (indexing into a Vec or slice).

I need to run Postgres in production soon and have been trying to decide between AWS RDS multi-AZ (non-Aurora) and Google Cloud SQL HA. I have some experience with RDS, and from the documentation, Cloud SQL seems very similar.

What's worse about Google Cloud SQL?

I need to run Postgres in production soon. I've used AWS RDS (MySQL) in the past, but am also considering Google Cloud SQL.

Things that seem similar in AWS:

- For major version upgrades, you need to bring up a new instance from a snapshot and catch it up with replication.

- HA failover results in a few minutes of downtime. (They claim using their SQL proxy will reduce this.)

- Lag in providing the latest Postgres versions. GCP seems to be a bit ahead of AWS here.

Is there a managed Postgres offering that you prefer? Aiven looks nice, feature-wise.

I use 1Password (and the browser extension) for all my passwords, but I still choose "Sign-in with Google" when that's an option.

The "Sign-in with Google" button is makes it much quicker to create an account and slightly quicker to log in.

Also, I can rely on my Google 2FA rather than setting up and filling in a different TOTP for each site. Something like U2F or WebAuthn would make the filling-in part more convenient, but even sites that offer 2FA usually don't offer those. (And many sites don't even offer 2FA.)

Using 1Password's 2FA feature would make TOTP more convenient, but I'm a little nervous about putting 2FA in 1Password. This might be overly-conservative thinking, though.

The neat thing about Swift's ABI compatibility is that it's almost as flexible as its API compatibility, e.g.

- A library can add new fields to a struct.

- A library's parameterized types can be instantiated with new arguments.

Skimming over the D ABI docs, the compatibility seems much more rigid.

Some similar work:

The GCC compiler for Java (GCJ) started out doing whole-program compilation, but that couldn't handle Java's flexible ABI and dynamic loading. In 2004 they introduced a compilation mode with an additional layer of indirection similar to Swift's: <ftp://gcc.gnu.org/pub/gcc/summit/2004/GCJ%20New%20ABI.pdf>. They didn't have to deal with monomorphizing, though.

Go's does something similar to Swift to avoid code bloat in their built-in polymorphic map: <https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...>. It's just a one-off manual thing, though.

That's the part they sold in the title, but there's a bunch of other useful stuff for someone operating Postgres in production, something I'll need to do in a few months.