https://www.scattered-thoughts.net/writing/against-sql

That particular post ends with a wish-list of items so it's the most similar to the OP. But there are others on the site that I quite enjoy (click on the home icon and search "SQL" on the page).

My personal take is that SQL will continue to reign for a long time because of the how monumental the task of replacing it is due to the inherent complexity of databases. LLMs make this worse because they're really good at translating prose to SQL. Now that it matters less how annoying SQL is to programmers, SQL will become more like assembly over time: something mostly computers write because it's complicated for humans to deal with directly. This is deeply ironic given that SQL was ostensibly designed to read like prose, i.e. to be easy for humans.

I'd love to evidence what I'm saying with specific numbers since this kind of discussion would benefit from being as objective as possible. Sadly I don't have them. But I still believe what I'm saying and I have a few guesses about some of the causes:

1. Immutable data - so, so many bugs are caused by data mutating out from under you in subtle ways. If you write `x = 1` in your Elixir function, nothing can change the value of `x` except an explicit rebinding. You can then write e.g. `y = f(x)` and know `x` remains unchanged after. Note: this is also true even if the variable is a composite type. `my_struct = blah()` will remain the same in it's entirety no matter what you do with `my_struct`. This is different than in JS where e.g. you can change the contents of an object even if it's declared `const`.

2. Assertive style - the Elixir community favors writing things in an "assertive" fashion [1]. Briefly, this a way of writing code that will fail the moment an assumption is broken rather than letting the issue propagate.

3. Pattern matching (somewhat like destructuring in JS) - Elixir code actually ends up feeling "typed" with pattern matching. E.g. `%Time{} = today = Date.utc_today()` will attempt to bind `today` to the result of `Date.utc_today()` and will raise a `MatchError` when the result, a `%Date{}` struct, fails to be a `%Time{}` struct. Or `[a, b] = [1, 2, 3]` will raise a `MatchError` because `[1, 2, 3]` isn't a list of length exactly 2. You can use pattern matching to write very assertive code quite tersely.

These reasons are all local properties of code. But when all its parts are written in this way, a program as a whole gains a level of correctness that's hard to achieve in a dynamically typed language without them.

Also these reasons aren't exhaustive, but they're top of mind when thinking about this topic.

[1]: https://dashbit.co/blog/writing-assertive-code-with-elixir

It's the same with tough on crime. "What, you want criminals to keep getting away with it?!"

> The primary trade-off observed is the increased calculation time for OLS and SVD steps. Consequently, the next phase of this work involves implementing these operations within custom Triton kernels to amortize latency. By viewing the cache through the lens of reconstruction fidelity rather than just memory capacity, we can develop more sustainable architectures for long-context inference.

Reading between the lines, the increase in latency was so significant that they didn't want to include it before they had a chance to try and optimize the problem away first.

Still interesting research. Hope they get good results!

Your reasoning relies on this being true:

> [CRQCs] will be slow, expensive, and power hungry for at least a decade

How could you know that? What if it was 5 years? 1 year? 6 months?

I predict there will be an insane global pivot once Q-day arrives. No nation wants to invest billions in science fiction. Every nation wants to invest billions in a practical reality of being able to read everyone's secrets.

https://en.wikipedia.org/wiki/Whey_protein#Microbial_product...

It's not theoretical either. You can buy vegan dairy products made from this method today.

https://www.youtube.com/watch?v=dO6ApZlxqo8

Sidenote: is that Clancy Brown doing the voice over on the 'Home' commercial?

I have the technical background to write Latex and Typst documents but I honestly didn't want the headache. Plus I'm the type to futz with styling all day long instead of putting down actual content. RenderCV was simple to use and did exactly what I wanted.

I have the power to do it. Why would I not?

As a PR reviewer I frequently pull down the code and run it. Especially if I'm suggesting changes because I want to make sure my suggestion is correct.

Do other PR reviewers not do this?

Though I think it's more of a hobby language. The last commit was > 1 year ago.

[1] https://news.ycombinator.com/item?id=40211891

The 2nd link seems reasonable to me? Why does a study about 25k workers in Denmark (11 occupations, 7k workplaces) not count as evidence? If there was a strong effect to be found globally, it seems likely to be found in Denmark too.

Also, what about the other links? The discussions about the strange accounting and lack of profitability seem like evidence as well.

If anything, this article struck me as well-evidenced.

E.g. the debugging question: I use all of those methods to some degree. But I "think logically about the code" (or whatever that choice was) nearly 100% of the time, so I felt compelled to pick that one even though I didn't feel like it represented me all that well.