371–380 of 411 posts
“None of the safe programming languages existed for the first 10 years of SQLite's existence. SQLite could be recoded in Go or Rust, but doing so would probably introduce far more bugs than would be fixed, and it may also result in slower code.” Modern languages might do more than C to prevent programmers from writing buggy code, but if you already have bug-free code due to massive time, attention, and testing, and t…
[Cries in Ada]
Earlier quoted context omitted.
Keeping running if possible doesn't sound like the best strategy for stability. If data was corrupted in memory in a was that would cause a bounds check to fail then carrying on is likely to corrupt more data. Panic, dump a log, let a supervisor program deal with the next step, or a human, but don't keep going potentially persisting corrupted data.
What the best strategy is depends on your use case. The use case that SQLite has chosen to optimize for is critical embedded software. As described in https://www.sqlite.org/qmplan.html , the standard that they base their efforts on is a certification for use in aircraft. If mission critical software on a plane is allowed to crash, this can render the controls inoperable. Which is likely to lead to a very literal cra…
Earlier quoted context omitted.
The Sqlite team in stuck in the classic dilemma. They are stuck with their existing thing because it is so big, that you can't just stop the world for you existing users and redo it. Meanwhile some small innovator comes along and builds the next thing because why not, they don't have anything holding them back. This is classic Innovator's Dilemma and Creative Destruction. This has of course not happened yet and we ha…
You say that like SQLite is a for profit company competing for market share or one of several rival projects in a corporation trying to not be canceled. It's an open sourced project! It's public domain ! If you make an open source project that is heavily used and widely lauded for a quarter century before being supplanted by a newer solution that's better, do you know what that is? A success! You did it! You made a t…
You may think these are ludicrous prices, but think of it as market segmentation. It seems like they're only a few employees, so if they get, like, 300 companies in the entire world to sign up for email support, they earn a pretty respectable salary. Or if they get, like, four companies in the whole world to join their consortium, and nobody else buys anything. In fact, there are four consortium members on the homepage: https://sqlite.org/index.html and possibly others who chose not to be listed. So we have (it seems) two people getting paid $600k per year to work on this. This is a software SMB - they're not trying to hyperscale or squeeze every penny, just make a living selling a good product at a steady rate.
This model only works, of course, because SQLite is a genuinely good product that everyone loves and uses for free in every open-source project. It wouldn't work if a copy of SQLite cost even $10, because then we'd all be using MariaDB. It might not even work if it was proprietary but free.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
It's not like that, the compiler explicitly doesn't do compile-time checks here and offloads those to the runtime. Rust does not stop you from writing code that accesses out of bounds, at all. It just makes sure that there's an if that checks.
Ok, but you can still test all the branches in your source code and have 100% coverage. Those additional `if` branches are added by the compiler. You are responsible for testing the code you write, not the one that actually runs. Your compiler's test suite is responsible for the rest. By the same logic one could also claim that tail recursion optimisation, or loop unrolling are also dangerous because they change the…
If sqlite were to read one byte over the end of an array, it's unlikely to lose your data. Rust would guarantee that to lose data.
Earlier quoted context omitted.
Folklore.org has many stories about writing Lisa OS code in Pascal, about rewriting various pieces in assembly for the Macintosh, and developing apps in Pascal, but I can’t find any mention of actually writing any part of the original Mac system in Pascal. Nothing you’ve quoted says otherwise. The closest is the very first sentence, but all it says is that Pascal was in use at Apple when the Macintosh project began,…
Whatever makes you happy to keep your view on the matter. https://bitsavers.org/pdf/apple/mac/Inside_Macintosh_Vol_1_1...
I'm happy to change my view given evidence, but you have yet to provide a single word of evidence that there was any Pascal in the original Macintosh system.
Earlier quoted context omitted.
outside political definitions, I'm not sure "crash and restart with a supervisor" and "don't crash" are meaningfully different? they're both error-handling tactics, likely perfectly translatable to each other, and Erlang stands as an existence proof that crashing is a reasonable strategy in extremely reliable software. I fully recognize that political definitions drive purchases, so it's meaningful to a project eithe…
If the cause of the crash is in any way related to the persisted data, there's a good chance you're now stuck in a crashloop. If it can avoid crashing, other functionality may continue to work fine.
Earlier quoted context omitted.
I can’t verify those claims one way or another, but I’m interested to hear why they were downvoted.
I've worked on a couple different projects that did substantial parallel development in C++20 and Rust, which created interesting opportunities for concrete comparison. It was performance-engineered code and we needed to validate their equivalence by testing them against each other. The practical differences are larger than the theoretical differences, so I would expect the gap to diminish over time. Rust reminded me…
Earlier quoted context omitted.
"SQLite could be recoded in Go or Rust, but doing so would probably introduce far more bugs than would be fixed, and it may also result in slower code." We will see. On the Rust side there is Turso which is pretty active. https://turso.tech/
The fact that there are "cloud pricing" and "schedule a call" links already tells me all I need to know. Doesn't seem like this is a product that is really competing with SQLite at all.
Turso is arguably positioned slightly better as a standalone product seeing as it's using a more traditional open source "bazaar" model, as opposed to SQLite's source available "cathedral" model.
Earlier quoted context omitted.
Python + C . Probably C for the optimized parts.
Why not Go + C then?