I agree, I think the author had some thoughts in their head that they forgot to write down, because it feels like at least a few paragraphs making the connection are missing. Happens to me all the time when I'm writing something too honestly.
By the same ticket, you really also don't want elemental sodium in your ear. Don't let the fact it's commonly found in sodium chloride alongside chlorine (something else you don't want in your pocket!) lull you into a false sense of security.
Sodium is actually more reactive than lithium and explodes on contact with water. There's a few things that make the battery chemistry less likely to undergo thermal runaway, but sodium is not a safe metal...
>Sodium is actually more reactive than lithium and explodes on contact with water.
TIL
Cursory LLM powered search suggests that this is true but not a particularly relevant metric for battery safety because battery failure modes aren't "throw elemental raw material into water".
I'm no expert and LLM research is well...yeah...but overall that still sounds like I should be trusting sodium more to my layman ears.
How does the safety of sodium ion batteries compare to LiFePO4? It's not the presence of lithium that causes the problem, it's the way it's used in traditional lithium-ion cells. I've never heard of a fire being caused by LiFePO4 cells.
I’d imagine this will go a bit like the rust rewrite of sudo etc. Despite the memory safety advantages at least towards the start it still ends up more fragile because the incumbent has years of testing and fixing behind it
They're not aiming at replacing SQLite-in-C with SQLite-in-Rust, they're doing this so they can implement more additional functionality faster than with C's chainsaw-juggling-act semantics and the inability to access the proprietary SQLite test suite.
I think it's fair to say they tried using SQLite but apparently had to bail out. Their use case is a distributed DBaaS with local-first semantics, they started out with SQLite and only now seem to be pivoting to "SQLite-compatible".
Building off of that into a SQLite-compatible DB doesn't seem to me as trying to piggyback on the brand. They have no other option as their product was SQLite to begin with.
That doesn't seem very fair. It's still beta and clearly far from finished. And they do call out the compromises - they have a whole page about how they are not yet fully compatible:
IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust. Turso's Limbo announcement says exactly that: they couldn't confidently make large architectural changes without access to the tests. The rewrite lets them build Deterministic Simulation Testing from scratch, which they argue can exceed SQLite's reliability by simulating unlikely scenarios and reproducing failures deterministically.
> IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust.
I don't understand this claim, given the breadth and depth of SQLite's public domain TCL Tests. Can someone explain to me how this isn't pure FUD?
"There are 51445 distinct test cases, but many of the test cases are parameterized and run multiple times (with different parameters) so that on a full test run millions of separate tests are performed." - https://sqlite.org/testing.html
The test suite that the actual SQLite developers use to develop SQLite is not open-source. 51445 open-source test cases is a big number but doesn't really mean much, particularly given that evidently the SQLite developers themselves don't consider it enough to provide adequate coverage.
Maybe. It's hard to know what kind of issues that test suite covers. If memory safety is the main source of instability for the C implementation then the Rust implementation won't be too affected without the test suite. Same if it focus a lot on compatibility with niche embedded platforms and different OSes, which Turso won't care to lose.
"Stability" is a word that means different things for different use cases.
But the other one is not available to most and SQLite itself is "open-source" not "open-contributions" so extending SQLite is pretty much impossible at scale:
- no way to merge upstream
- no way to run full test-suit to be sure everything is tiptop
Not likely. The alternative was for them to modify SQLite without the test suite and no obvious indication of what they would need to do to try to fill in the gaps. Modifying SQLite with its full test suite would be the best choice, of course, but one that is apparently[1] not on the table for them. Since they have to reimagine the test suite either way, they believe they can do a better job if the tests are written alongside a new codebase.
And I expect they are right. Trying to test a codebase after the fact never goes well.
[1] With the kind of investment backing they have you'd think they'd be able to reach some kind of licensing deal, but who knows.
Of all the projects which may benefit from a rewrite or re-imagining in a memory-safe language, I'm really puzzled why it's heavily-tested, near-universally-deployed software such as sudo (use oBSD doas instead?), the coreutils, and sqlite.
I definitely wouldn't be surprised by bugs and/or compatibility issues over time. Especially in the near term. I'm mixed, but somewhat enthusiastic on Turso's efforts to create client-server options and replication.
In the past I've reached for FirebirdSQL when I needed local + external databases and wanted to limit the technology spread... In the use case, as long as transactions synched up even once a week it was enough for the disparate remote connections/systems. I'm honestly surprised it isn't used more. That said, SQLite is more universal and lighter overall.
Building a production app on Turso now. No bugs or compatibility issues so far. The sqlite API isn't fully implemented yet, so I wrote a declarative facade that backfills the missing implementations and parallels writes to both Turso and native sqlite: gives me integrity checking and fallback while the implementation matures
ZIRP, AI, over hiring, and a wave of boot camp labour supply I suspect all contribute.
Plus we’re also likely approaching saturation on a lot of fronts with attention and ad density saturation. Things like YouTube seem to be on the edge of how much ads they can force feed without people just not using yt because it’s unusable. Enshitification isn’t a cycle, it’s a one way trip. Combine that with over hiring and it’s bound to hit a wall
But on the other side there are countless opportunities for valuable revenue-generating products that aren't based on dopamine addiction and/or ad tech.
It's a values problem, not an opportunity problem. Tech industry management is locked in a death spiral because it lacks the ethics or the vision to create real value, as opposed to extractive predatory value.
This applies equally to consumer relationships and employee relationships. The default value is "How can I screw these people over to get more of what I want?"
And that is - ironically - a failure of brain chemistry and emotional regulation.
Because making number go up is a catastrophic addiction in its own right.
> there are countless opportunities for valuable revenue-generating products that aren't based on dopamine addiction and/or ad tech.
Perhaps a bit of a hot take but I’d be inclined to disagree. The boom in big tech is I think almost exclusive driven by dopamine, brain rot and ad tech either directly or indirectly. Meta and Google - almost entirely ad funded. Netflix - binge watching and they’re trying hard to force more ads in. Apple makes the black rectangle to watch the content and ads - without the iPhone 1 doomscrolling wouldn’t be a thing. Amazon runs an ad empire, produces video content for binge watching and has a store designed to maximise consumerism and retail therapy.
Even the portions that are more infra like AWS - I’d bet a large portion of that fulfilling demand by things that are part of the attention/dopamine economy. All those TikTok dances aren’t served off a raspberry pi.
Don’t get me wrong not trying to discount tech as not having genuine ethical value or opportunities not existing. But the explosive growth seen in tech over past 20 years specifically is I think almost exclusively driven by adtech and attention economy.
And if that reaches saturation either this changes tracks to similar on AI or the growth plateaus. Other value creation certainly exists and is valid but I don’t see it filling the shoes of adtech.
Google and meta indirectly acknowledged the problem years ago already with their balloons over Africa to connect more eyeballs to the internet plan. If you can’t force feed more ads to current user base then you need more users. It’s telling I think that a wild plan like balloons in Africa was the plan selected, rather than going for the countless other valuable opportunities as you say. Speaks to the relative profitability
It goes on about DSL and dial-up for some reason?
And yes VPS providers are affected by ram shortage. Turns out things that need ram are affected by ram shortages. 5 stars for the insight
reply