chambers

> SQLite is really a terrible example of anything other than what you can accomplish when you pour enormous resources into a single C library.

That's quite a sweeping, even caustic, indictment.

Can you explain this statement more?

The author edited his post with a follow-up.

  [Update (2025-02-12): This post, which I thought of as a hasty update to the handful of people who followed my links, was posted to Hacker News for some reason. Yes, I should have provided evidence for the above judgment had I thought more people would read it. As ever, use your own judgment for these things.]

It covers the author's pre-judgement; he admits he didn't put in the work and he tells us to use our judgement and not his.

The part that's not addressed is "I want to reluctantly recommend even less services(/people?)." An eagerness to detract may not be hate but we're right to be wary of it.

Yup, I've tested and seen WASM SQlite's slowness myself. But I don't think it's a SQLite problem per se.

I heard WebSQL, which used SQLite, was at least 10x faster than WASM SQLite. Probably even more.

I found WASM slower than expected. I wrote some WASM logic functions recently which I thought would perform better than their native JS equivalent. For example, take a large array and "pivot" it in 10ms instead of a 100ms.

What I found was the JS version was a bit faster than the compiled WAT. Yikes.

EDIT: I think I'll try debugging it more

Converts do tend to romanticize their new side over the old one. But I think Larry's view has specific alignment with history: at the time, the most outspoken on the websites he visited were strongly Atheistic or Anti-Religious. That sentiment prevailed in websites like Reddit which, for example, had /r/atheism and its "euphoria".

StarSlateCodex describes this phenomena in detail, as well as what happened to the more drama-prone Atheists who Larry probably tussled with: https://slatestarcodex.com/2019/10/30/new-atheism-the-godles...

  “They’re cheering for you,” she said with a smile. 
  “But I could never have done it,” [Milo] objected, “without everyone else’s help.”
  “That may be true,” said Reason gravely, “but you had the courage to try; 
     and what you can do is often simply a matter of what you will do.”
  “That’s why,” said King Azaz, “there was one very important thing about your quest 
     that we couldn’t discuss until you returned.”
  “I remember,” said Milo eagerly. “Tell me now.”
  “It was impossible,” said the king, looking at the Mathemagician.
  “Completely impossible,” said the Mathemagician, looking at the king.
  “Do you mean … ,” said the bug, who suddenly felt a bit faint.
  “Yes, indeed,” they repeated together, “but if we’d told you then, you might not have gone … 
    and, as you’ve discovered, so many things are possible just as long as you don’t know they’re impossible.”

- The Phantom Tollbooth (1961)

This decisions looks well-reasoned. It acknowledges the strengths of their current implementation, and explains why another language may serve their goals even better. I can follow along as someone interested in general software decision-making, even though I'm not particularly invested in either language.

One specific thing I like is that the motivation for this rewrite is organic, i.e., not driven by an external pressure campaign. It's refreshing to see a drama-free rewrite.

This reporting feels a bit slanted. The author implies the big blockers are human beings; specific people & interactions he's called out for seemingly stalling the project.

Personally, I'm curious if there's hard technical blockers. Like, if there's features that Linux (or Rust) needs which could incur a serious burden that no team can sustainably maintain. That kind of reporting— deep insights into technical trade-offs— would be much more interesting than a play-by-play of drama.

On a side note, there's one paper on Rust in Linux that's been recommended but I've not seen it deeply discussed yet https://www.usenix.org/conference/atc24/presentation/li-hong...

It's not that the skin is thin, but that the muscle is tired. Our muscle (or sense) of guilt has been overused and abused. Now it's prone to inflammation when we hear people who intentionally or unintentionally trigger it.

I think the irritation towards guilt may look like rage but I think it's a weary hopelessness. No matter what is done, history cannot be undone. It cannot be forgotten and many people feel it can't even be made right anymore. All the guilt of recent history did not lead to a new Civil Rights Act, it did not change the Constitution. And any of the good that was done to right history in the 20th century-- many claim it only belongs to yesterday's victims.

Those with the wrong ancestors are stuck in their sin waiting for history to be twisted & jabbed into them by their neighbors, who wish to ease or to glorify their own individual conscience.

IMO, the cycle breaks only when there's hope of true, genuine forgiveness that MLK preached and LBJ effected. But that forgiveness is beyond human power.

> When we launched our independent fact checking program in 2016, we were very clear that we didn’t want to be the arbiters of truth. We made what we thought was the best and most reasonable choice at the time, which was to hand that responsibility over to independent fact checking organizations... That’s not the way things played out, especially in the United States. Experts, like everyone else, have their own biases and perspectives. This showed up in the choices some made about what to fact check and how.

This frustration with fact-checkers seems genuine. Mark alluded to it in https://techcrunch.com/2024/09/11/mark-zuckerberg-says-hes-d... which squares with how the Government used fact-checkers to coerce Facebook into censoring non-egregious speech (switchboarding) https://news.ycombinator.com/item?id=41370516

Alex Stamos pushed this initiative pretty hard outside of Facebook in 2019+, seemingly because he wasn't able to do inside of Facebook back in 2016/2018. But I haven't dug into his motivations.

Not an expert at all: I wonder if getting the perf requires trading-off some (advertised) safety. IO uring has been noted to be confusing with async in Rust, https://news.ycombinator.com/item?id=41992975

I'm reminded of how Confluent advertised Kafka as a database. They quietly externalized key guarantees of an RDBMS onto their customers, who were then saddled with implementing those guarantees in application level logic. By obscuring the trade-offs, Confluent made developers feel they could have their cake and eat it too.

One small comment: it may be worth disclaiming that one of the two cited researchers is the author's boss.

It's a small detail, but I mistakenly thought the author and the researchers were unrelated until I read a bit more

It would be nice to see how a long-time editor of Wikipedia avoids the abuses of power the GP speaks of. Would you be comfortable sharing your account? Or some other account that demonstrates non-collusive, even virtuous behavior.

How much has Turso raised so far? Rewriting SQLite sounds like it may cost a sum.

I think there's merit to the argument that Gelsinger was unwilling to kill the culture to save the business. Intel and he seemed trapped by pride, nostalgia, complacency, and fear.

But some of the points feel a tad personal. I've found Pat and Bryan to be similar as professionals, so I'm not sure how much of this is a mote in one's eye, and a beam in the other's.

Another fascinating comment by motohagiography.

I wager the movement is less a rebellion of the few, and more the unbelief of the many. That is, people just don't believe there's a personal benefit to being virtuous. It's a completely rational calculation when there's no deep spiritual or religious belief in far-off rewards or punishments. Unfortunately, our age's contempt for belief in the "deep down" turns people to worship physical characteristics & preferences instead.

On a meta note, you're right to note that unclear terms undermine our collective reasoning, despite a proper chain of propositions.

I've found Term Logic[1] to be useful for figuring out why certain discussions confuse me. I've also used to avoid unnecessary arguments by seeing if the participants are starting with clear concepts (signaled by terms).

[1] https://en.wikipedia.org/wiki/Term_logic#Basics also this explainer https://adoroergosum.blogspot.com/2015/05/the-three-acts-of-...

I kinda feel that their focus is more on building a great technology (& culture?) than a great business.

Not necessarily a bad choice; after all, for what shall it profit a man, if he shall gain the whole world, and lose his own soul?

I've witnessed how abandoning first principles undermines the evolution of a system. If our mental model of a system is not formalized into first principles (i.e. a high-level specification), then successive generations of engineers will have to re-learn those principles through trial-and-error. They'll introduce mutations and dependencies between the mutations-- and when they leave, the next generation of maintainers will repeat the process. Generations of mutations eventually create a brittle, calcified creature of a system which people fear to touch with a ten foot poll.

I imagine people who were taught SICP would be more respectful, if not inclined, towards a formal articulation of a system's principles.

This philosophy is described in depth in the original 1985 article https://gwern.net/doc/cs/algorithm/1985-naur.pdf and in more accessible language in https://www.baldurbjarnason.com/2022/theory-building/. You can also observe engineers opposing/misunderstanding the need for specification in https://news.ycombinator.com/item?id=42114874

When a company does not want to pay (or empower) a principal engineer, they hire legions of junior engineers to cover up the gap. People who focus on the joy of shipping than on the pesky questions of "shipping what?" and "who will maintain it?"

Many of us here owe our jobs to the deliberate weakening of technical authority and expertise. That debt probably blinds us to those management decisions, and the need for architects to balance them out.

I wish the contradiction you spotted was clear on their Wikipedia page. It demonstrates how far back IA's management troubles go, and how their clean image was maybe just an image.

For me, I became concerned when they fibbed about why the Internet Archive Credit Union was liquidated. IA alleged it was shut down due to onerous regulations, but the government said IA actually never lived up to their goal of allowing local, low-income folk to sign-up for their service. https://ncua.gov/newsroom/press-release/2016/internet-archiv...

I believe the monastic model would fit best. Tireless, thankless work for the greater good. Maintaining old records for decades and centuries for the sake of beyond ourselves. I imagine people who join up would eschew both profit maximizing (for profit) and moral adventurism (non profit/Internet Archive). a real vocation, not a career.

Sadly, SQlite is the only software organization I know of that has this spirit.

Knowing how people use your system to make decisions is important. I think that knowledge is vital for maintaining, extending, or building a system.

But the article suggests a higher responsibility: you should document your user's decision-making. You should tell them the context, the choices they have to make, and the consequences of their decisions.

I've worked on a "decision support system" with that responsibility and it got really messy, really fast. Humans love to argue about consequences, even 100% absolutely known ones. They also despise automated emails bearing uncertainty, as well as docs demanding binary choices when many more choices are available in reality.

I would hope the book beyond this article raises the concept of control. That is, to document a behavior, you need some guarantee (or enforcement) about that behavior so your documentation remains authoritative. IMO, the lack of authority/control is common, gaping blindspot of writing initiatives like https://www.plainlanguage.gov unfortunately.

> The INTERNETARCHIVE.BAK experiment has come to a close a number of years ago.

> Much was learned in the process, and many thanks are given to the dozens of people who donated time, space and coding efforts to make the system work as long as it did. A number of useful facts and observations came from the project.

> The Internet Archive continues to explore methods and code to decentralize the collection, to have a mirror running in various ways - these include IPFS, FileCoin, and others. The INTERNETARCHIVE.BAK project also added general mirroring and tracking code to a number of projects that are still in use.

IA called this their Postmortem, but it sounds... intentionally opaque. Also, I'm not sure if this website is affiliated with archive.org, since they say at the bottom of their homepage:

> Archive Team is in no way affiliated with the fine folks at ARCHIVE.ORG Archive Team can always be reached by e-mail at archiveteam@archiveteam.org or by IRC at the channel #archiveteam (on hackint).

Hand-holding colleagues needing help is a nice sentiment. Even better: when leadership rewards that support and when coworkers quietly pay-it-forward. It's heartwarming to see it in action.

That said, I don't think the author's main rule scales:

> “If someone asks you a question you can’t answer, take them to someone who can answer it. If you don’t know who that is, help find someone who can.”

Setting an expectation of hand-holding a request across channels would be quite unpopular with most if not all, the technical support teams I've worked with. It can be quite a bit of effort when you're getting 10+ redirects a week, especially when the requestor hasn't done their due diligence. If my own team tried this, we would quickly become the "goto" for any domain adjacent problem. A real recipe for burn-out.

A lot depends not on the process he's advocating for but on the environment which he doesn't seem to analyze. IMO, there's no results, costs, mistakes, or trade-offs shared, so I'd be inclined to chalk this up as marketing.

> Don't you find it infuriating when lawyers and accountants fail to clarify how their respective domains work, making them unavoidable intermediaries of systems that in theory you should be able to navigate by yourself? Whenever we fail to make simple things easy in software engineering, and webdev especially, we are failing society in the exact same way.

I think the better word for this is "straightforward"; see the Mythical Man Month:

> For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. Mooers's TRAC language and Algol 68 achieve simplicity as measured by the number of distinct elementary concepts. They are not, however, straightforward. The expression of the things one wants to do often requires involuted and unexpected combinations of the basic facilities. It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice.

> Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.

Kobito of the Shining Needle ~ Little Princess (https://www.youtube.com/watch?v=jv1yYDzvFtQ) is one of my favorite Touhou songs.

> It helped me develop the skill of finishing things, which is a separate skill that's hard to learn, because it only happens at the end of a process so long and hard you almost never make it there.

Great insight. The skill of finishing what you started, is something that feels elided in discussions around productivity. Is there a blogpost or article that explains it even more?

Here's a link to the previous posting of this article: https://news.ycombinator.com/item?id=36313671 (235 comments)

Coincidentally, there's another article offering a different take on the matter https://news.ycombinator.com/item?id=41635583.

On a side note: the author said he'd explain "how finishing a project is different from solving the problem you set out to solve" but I didn't see an explanation in the text. Am I missing something?

I wonder if the author's observation has something to do with the tension between Research and Development, ala R&D. YCombinator seemed effective in funding the latter, but the first half seem to be higher risk, more expensive, and much longer to market (if at all).

Is my impression correct? I recall YC Research was pitched a few years ago but I think it politely imploded into a small nonprofit.