4 ms·

The bit about why not OOP seems a bit old. I think we're past a point where people are going for OOP as the default shape of code. Overall, it makes sense. C i

The bit about why not OOP seems a bit old. I think we're past a point where people are going for OOP as the default shape of code. Overall, it makes sense. C is a systems language, and a DB is a system abstraction. You shouldn't need to build a deep hierarchy of abstractions on top of C, just stick with the lego blocks you have. If the project had started in 2016, maybe they would have gone for c++, which is a different beast from what it was pre-2011. Similarly, you might write SQLite in Rust if you started today.

alexpadula 10mo ago
I think they would have still gone with C. I still do.
- mrweasel 10mo ago
  The author of ZMQ had an article about regretting not using C over C++. Picking Rust for a "modern" version of SQLite could easily go down a similar route in the end. https://web.archive.org/web/20250130053844/https://250bpm.com/blog:4/ https://web.archive.org/web/20250130053844/https://250bpm.co...
  - scottlamb 10mo ago
    Regret is possible with any language, but I'd be surprised if someone regretted choosing Rust for the reasons in the article you linked: * Error handling via exceptions. Rust uses `Result` instead. (It has panics, but they are meant to be strictly for serious logic errors for which calling `abort` would be fine. There's a `Cargo.toml` option to do exactly that on panic that rather than unwinding.) (btw, C++ has two camps here for better or worse; many programs are written in a dialect that doesn't use exceptions.) * Constructors have to be infallible. Not a thing in Rust; you just make a method that returns `Result<Self, Error>`. (Even in C++ there are workarounds.) * Destructors have to be infallible. This is about as true in Rust as in C++: `Drop::drop` doesn't return a `Result` and can't unwind-via-panic if you have unwinding disabled or are already panicking. But I reject the characterization of it as a problem compared to C anyway. The C version has to call a function to destroy the thing. Doing the same in Rust (or C++) is not really any different; having the other calls assert that it's not destroyed is perfectly fine. I've done this via a `self.inner.as_mut().expect("not terminated")`. They say the C only has two states: "Not initialised object/memory where all the bets are off and the structure can contain random data. And there is initialised state, where the object is fully functional". The existence of the "all bets are off" state is not as compelling as they make it out to be, even if throwing up your hands is less code. * Inheritance. Rust doesn't have it.
nicoburns 10mo ago
> The bit about why not OOP seems a bit old. I think we're past a point where people are going for OOP as the default shape of code. That section was probably written 20 years ago when Java was all the rage.

alexpadula 10mo ago

I think they would have still gone with C. I still do.

mrweasel 10mo ago
The author of ZMQ had an article about regretting not using C over C++. Picking Rust for a "modern" version of SQLite could easily go down a similar route in the end. https://web.archive.org/web/20250130053844/https://250bpm.com/blog:4/ https://web.archive.org/web/20250130053844/https://250bpm.co...
- scottlamb 10mo ago
  Regret is possible with any language, but I'd be surprised if someone regretted choosing Rust for the reasons in the article you linked: * Error handling via exceptions. Rust uses `Result` instead. (It has panics, but they are meant to be strictly for serious logic errors for which calling `abort` would be fine. There's a `Cargo.toml` option to do exactly that on panic that rather than unwinding.) (btw, C++ has two camps here for better or worse; many programs are written in a dialect that doesn't use exceptions.) * Constructors have to be infallible. Not a thing in Rust; you just make a method that returns `Result<Self, Error>`. (Even in C++ there are workarounds.) * Destructors have to be infallible. This is about as true in Rust as in C++: `Drop::drop` doesn't return a `Result` and can't unwind-via-panic if you have unwinding disabled or are already panicking. But I reject the characterization of it as a problem compared to C anyway. The C version has to call a function to destroy the thing. Doing the same in Rust (or C++) is not really any different; having the other calls assert that it's not destroyed is perfectly fine. I've done this via a `self.inner.as_mut().expect("not terminated")`. They say the C only has two states: "Not initialised object/memory where all the bets are off and the structure can contain random data. And there is initialised state, where the object is fully functional". The existence of the "all bets are off" state is not as compelling as they make it out to be, even if throwing up your hands is less code. * Inheritance. Rust doesn't have it.

nicoburns 10mo ago

> The bit about why not OOP seems a bit old. I think we're past a point where people are going for OOP as the default shape of code. That section was probably written 20 years ago when Java was all the rage.