there is already an sqlite port in Go :) https://gitlab.com/cznic/sqlite
That's not a port. That's an extremely impressive machine translation of C to Go. The output is a non-portable half-a-million LoC Go file for each platform.
And it works very well both as SQLite and as a pure go entity. I have used it for few years to do async backups of an in memory counting database (read from only at start up, written to by worker go routine that batches writes) without incident. Doesn’t really show up in the profiler.
Yeah, Steve has been "just" a well-informed third party for a while now. I would be curious if he has commented on that specific issue before; usually when unsoundness comes up it's cve-rs which is mentioned. > but even current official sources like https://rust-lang.org/ say things like "Rust’s rich type system and ownership model guarantee memory-safety" that are only true of the vague-ideal "Rust language" and are…
I agree that it's a tough situation. "The type system guarantees memory safety" is an extremely important pillar of Rust's identity. They kind of have to portray all soundness issues as "more compiler bugs than something broken in the language itself" (see eg https://news.ycombinator.com/item?id=21930599 which references a GitHub label that AIUI would've included the trait coherence thing at the time) to keep making…
> They kind of have to portray all soundness issues as "more compiler bugs than something broken in the language itself" [] to keep making that claim.
That's part of the "interesting question" I referred to in my comment. There's probably multiple factors that go into the decision of what to put onto the front page, and the presence/absence of soundness issues is just one of those factors.
This begs the question of why Rust evangelists keep targeting existing projects instead of focusing writing new, better software. In theory these languages should allow software developers to write programs that they would not, or could not, attempt using languages without automatic memory management Instead what I see _mostly_ is re-writes and proposed re-writes of existing software, often software that has no netwo…
: This begs [sic] the question why copyleft evangelists keep targeting existing projects instead of focusing writing new, better software. Few things in this life are novel. Regardless, when I wrote ripgrep, I was focusing on writing new and better software. I perceived several problems with similar tools at the time and set out to do something better. Imagine if people actually listened to whinging like your comment…
Good analogy with copyleft rewrites - most of those Rust rewrites tend to use permissive licenses, so it is clear they aim to destroy civilizational achievements.
Yes, compilers will take some time to implement the new standards. C23 seems to have decent support from a few compilers, with GCC leading the pack: https://en.cppreference.com/w/c/compiler_support/23.html gcobol supports (or at least aims to support?) COBOL 2023: https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcobol/gcobol.html . Presumably there are other compilers working on support as well. Intel's Fortran compiler an…
Flang does already support warnings for features that have breaking changes in F’2023.
Glad to hear it! Didn't turn up anything obvious in my brief search, but I was expecting some work towards newer standards at least.
I think beyond the historical reasons why C was the best choice when SQLite was being developed, or the advantages it has today, there's also just no reason to rewrite SQLite in another language . We don't have to have one implementation of a lightweight SQL database. You can go out right now and start your own implementation in Rust or C++ or Go or Lisp or whatever you like! You can even make compatible APIs for it…
> there's also just no reason to rewrite SQLite in another language
But think about all those karma points here and on Reddit, or GitHub stars!
: This begs [sic] the question why copyleft evangelists keep targeting existing projects instead of focusing writing new, better software. Few things in this life are novel. Regardless, when I wrote ripgrep, I was focusing on writing new and better software. I perceived several problems with similar tools at the time and set out to do something better. Imagine if people actually listened to whinging like your comment…
Good analogy with copyleft rewrites - most of those Rust rewrites tend to use permissive licenses, so it is clear they aim to destroy civilizational achievements.
> there's also just no reason to rewrite SQLite in another language. […] But why would we want to throw away the perfectly good C implementation, and why would we expect the C experts who have been carefully maintaining SQLite for a quarter century to be the ones to learn a new language and start over? The SQLite developers are actually open to the idea of rewriting SQLite in Rust, so they must see an advantage to it…
My theory is they wrote this just to get the ‘rewrite everything in Rust’ crowd off their backs.
I find it a bit too specific, because it won't get rid of the `rewrite everything in (Go|Zig|…)` crowds. But who knows…?
Good analogy with copyleft rewrites - most of those Rust rewrites tend to use permissive licenses, so it is clear they aim to destroy civilizational achievements.
That doesn't make any sense.
Close to 100% positive that comment was tongue in cheek
I think beyond the historical reasons why C was the best choice when SQLite was being developed, or the advantages it has today, there's also just no reason to rewrite SQLite in another language . We don't have to have one implementation of a lightweight SQL database. You can go out right now and start your own implementation in Rust or C++ or Go or Lisp or whatever you like! You can even make compatible APIs for it…
Thanks for this, I fully agree. One frustration I have with the modern moment is the tendency to view anything more than five years old with disdain, as utterly irrelevant and obsolete. Maybe I’m just going old, but I like my technology dependable and boring, especially software. Glad to see someone express respect for the decades of expertise that have gone into things we take for granted.
I think we owe an equally proportionate measure of respect to the authors of boring old sqlite who, given the depth of their experience, recognize that there may in fact be benefits to be gained from the rewrite and are open to exploring the possibility. The blockers as stated, I have no doubt, were carefully considered with a level of insight few of us could match. If and when the time is right, if they choose to undertake the effort I'm sure the juice will be worth the squeeze. The fact that they're not jumping in blindly today is telling. Even more telling will be if they do eventually go that route.