5 ms·

It's kinda sad to read as most of their arguments might seem right at first but if put under scrutiny really fall apart. Like why defend C in 2025 when you onl

It's kinda sad to read as most of their arguments might seem right at first but if put under scrutiny really fall apart. Like why defend C in 2025 when you only have to defend C in 2000 and then argue you have a old, stable, deeply tested, C code base which has no problem with anything like "commonly having memory safety issues" and is maintained by a small group of people very highly skilled in C. Like that argument alone is all you need, a win, simple straight forward, hard to contest. But most of the other arguments they list can be picked apart and are only half true.

Deanoumean 1y ago
The argument you propose only works for justifying a maintenance mode for and old codebase. If you want to take the chance to turn away new developers from complex abominations like C++ and Rust and garbage collected sloths like Java and get them to consider a comparatively simple but ubiquitous language that is C, you have to offer more.
- dangus 1y ago
  Is SQLite looking for new developers? Will they ever need a large amount of developers like a mega-corp that needs to hire 100 React engineers?
  - metaltyphoon 1y ago
    No, but as morbid as this sounds, the three(?) devs one day will pass away so now what?
    - hoppp 1y ago
      Then the rights will be sold to a FAANG or an open souce fork like libSQL will live on.
      - colejohnson66 1y ago
        SQLite is public domain (as much as is legally possible). So there's no "rights" to "sell" except the trademark.
        metaltyphoon 1y ago
        The testing suite is not open, which is one of the most important part of the project.
    - dangus 1y ago
      Well the point is that it’s not hard to find 3 people who are C experts. Yes, even young ones.
    - sgbeal 1y ago
      > No, but as morbid as this sounds, the three(?) devs... Two full-time core devs and three part-time "peripheral" devs. > ... one day will pass away ... And not a one of us are young :/.
cmrx64 1y ago
(it’s from 2017)
- deleted 1y ago
  [deleted]
mungaihaha 1y ago
> But most of the other arguments they list can be picked apart and are only half true I'd like to see you pick the other arguments apart
- scuff3d 1y ago
  > Other programming languages sometimes claim to be "as fast as C". But no other language claims to be faster than C for general-purpose programming, because none are. Not OP, And I'm not really arguing with the post, but this struck me as a really odd thing to include in the article. Of course nothing is going to be faster then C, because it compiles straight to machine code with no garbage collection. Literally any language that does the same will be the same speed but not faster, because there's no way to be faster. It's physically impossible. A much better statement, and one inline with the rest of the article, would be that at the time C and C++ were really the only viable languages that gave them the performance they wanted, and C++ wouldn't have given them the interoperability they wanted. So their only choice was C.
  - aw1621107 1y ago
    I think one additional factor that should be taken into account is the amount of effort required to achieve a given level of performance, as well as what extensions you're willing to accept. C with potentially non-portable constructs (intrinsics, inline assembly, etc.) and an unlimited amount of effort put into it provides a performance ceiling, but it's not inconceivable that other programming languages could achieve an equal level of performance with less effort, especially if you compare against plain standard C. Languages like ISPC that expose SIMD/parallelism in a more convenient manner is one example of this. Another somewhat related example is Fortran and C, where one reason Fortran could perform better than C is the restrictions Fortran places on aliasing. In theory, one could use restrict in C to replicate these aliasing restrictions, but in practice restrict is used fairly sparingly, to the point that when Rust tried to enable its equivalent it had to back out the change multiple times because it kept exposing bugs in LLVM's optimizer.
  - tialaramex 1y ago
    "Because none are" is a particularly hollow claim because to support it you have to caveat things so heavily. You have to say OK, I allow myself platform specific intrinsics and extensions even though those aren't standard ISO C, and that includes inline assembler. I can pick any compiler and tooling. And I won't count other languages which are transpiled to C for portability because hey in theory I could just write that C myself, couldn't I so they're not really faster. At the end you're basically begging the question. "I claim C is fastest because I don't count anything else as faster" which is no longer a claim worth disputing. The aliasing optimisations in Fortran and Rust stand out as obvious examples where to get the same perf in C requires you do global analysis (this is what Rust is side-stepping via language rules and the borrowck) which you can't afford in practice. But equally the monomorphisation in C++ or Rust can be beneficial in a similar way, you could in principle do all this by hand in your C project but you won't, because time is finite, so you live without the optimisations.
skywhopper 1y ago
I assume they have written this extensive document with lots of details in response to two and a half decades of thousands of “why not rewrite in X?” questions they’ve had to endure.
saghm 1y ago
At the very least, I find this argument to be fairly reasonable: > Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM. It is unclear how this could be accomplished in the current crop of safe languages. I don't think most Rust code written today has guardrails in the case of OOM. I don't think this disqualifies Rust for most things, because I happen to find the trade-off worth it compared to the things it does protect against that C doesn't, but I don't think it's a particularly controversial take that Rust still could use some ergonomic improvements around handling allocation failures. Right now, trying to create a Box or Vec can theoretically fail at runtime if no memory is available, and those failures aren't returned from the functions called to create them. Handling panics is something you can normally do in Rust, but if you're already OOM, things get complicated pretty fast. I agree that in the long run it would probably make sense to have something like this in Rust when eventually the current maintainers aren't around, but I also don't think it makes much sense to criticize them for continuing to maintain the code that already exists.

Deanoumean 1y ago

The argument you propose only works for justifying a maintenance mode for and old codebase. If you want to take the chance to turn away new developers from complex abominations like C++ and Rust and garbage collected sloths like Java and get them to consider a comparatively simple but ubiquitous language that is C, you have to offer more.

dangus 1y ago
Is SQLite looking for new developers? Will they ever need a large amount of developers like a mega-corp that needs to hire 100 React engineers?
- metaltyphoon 1y ago
  No, but as morbid as this sounds, the three(?) devs one day will pass away so now what?
  - hoppp 1y ago
    Then the rights will be sold to a FAANG or an open souce fork like libSQL will live on.
    - colejohnson66 1y ago
      SQLite is public domain (as much as is legally possible). So there's no "rights" to "sell" except the trademark.
      - metaltyphoon 1y ago
        The testing suite is not open, which is one of the most important part of the project.
  - dangus 1y ago
    Well the point is that it’s not hard to find 3 people who are C experts. Yes, even young ones.
  - sgbeal 1y ago
    > No, but as morbid as this sounds, the three(?) devs... Two full-time core devs and three part-time "peripheral" devs. > ... one day will pass away ... And not a one of us are young :/.

cmrx64 1y ago

(it’s from 2017)

deleted 1y ago
[deleted]

mungaihaha 1y ago

> But most of the other arguments they list can be picked apart and are only half true I'd like to see you pick the other arguments apart

scuff3d 1y ago
> Other programming languages sometimes claim to be "as fast as C". But no other language claims to be faster than C for general-purpose programming, because none are. Not OP, And I'm not really arguing with the post, but this struck me as a really odd thing to include in the article. Of course nothing is going to be faster then C, because it compiles straight to machine code with no garbage collection. Literally any language that does the same will be the same speed but not faster, because there's no way to be faster. It's physically impossible. A much better statement, and one inline with the rest of the article, would be that at the time C and C++ were really the only viable languages that gave them the performance they wanted, and C++ wouldn't have given them the interoperability they wanted. So their only choice was C.
- aw1621107 1y ago
  I think one additional factor that should be taken into account is the amount of effort required to achieve a given level of performance, as well as what extensions you're willing to accept. C with potentially non-portable constructs (intrinsics, inline assembly, etc.) and an unlimited amount of effort put into it provides a performance ceiling, but it's not inconceivable that other programming languages could achieve an equal level of performance with less effort, especially if you compare against plain standard C. Languages like ISPC that expose SIMD/parallelism in a more convenient manner is one example of this. Another somewhat related example is Fortran and C, where one reason Fortran could perform better than C is the restrictions Fortran places on aliasing. In theory, one could use restrict in C to replicate these aliasing restrictions, but in practice restrict is used fairly sparingly, to the point that when Rust tried to enable its equivalent it had to back out the change multiple times because it kept exposing bugs in LLVM's optimizer.
- tialaramex 1y ago
  "Because none are" is a particularly hollow claim because to support it you have to caveat things so heavily. You have to say OK, I allow myself platform specific intrinsics and extensions even though those aren't standard ISO C, and that includes inline assembler. I can pick any compiler and tooling. And I won't count other languages which are transpiled to C for portability because hey in theory I could just write that C myself, couldn't I so they're not really faster. At the end you're basically begging the question. "I claim C is fastest because I don't count anything else as faster" which is no longer a claim worth disputing. The aliasing optimisations in Fortran and Rust stand out as obvious examples where to get the same perf in C requires you do global analysis (this is what Rust is side-stepping via language rules and the borrowck) which you can't afford in practice. But equally the monomorphisation in C++ or Rust can be beneficial in a similar way, you could in principle do all this by hand in your C project but you won't, because time is finite, so you live without the optimisations.

skywhopper 1y ago

I assume they have written this extensive document with lots of details in response to two and a half decades of thousands of “why not rewrite in X?” questions they’ve had to endure.

saghm 1y ago

At the very least, I find this argument to be fairly reasonable: > Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM. It is unclear how this could be accomplished in the current crop of safe languages. I don't think most Rust code written today has guardrails in the case of OOM. I don't think this disqualifies Rust for most things, because I happen to find the trade-off worth it compared to the things it does protect against that C doesn't, but I don't think it's a particularly controversial take that Rust still could use some ergonomic improvements around handling allocation failures. Right now, trying to create a Box or Vec can theoretically fail at runtime if no memory is available, and those failures aren't returned from the functions called to create them. Handling panics is something you can normally do in Rust, but if you're already OOM, things get complicated pretty fast. I agree that in the long run it would probably make sense to have something like this in Rust when eventually the current maintainers aren't around, but I also don't think it makes much sense to criticize them for continuing to maintain the code that already exists.