4 ms·

You would have to start at languages that are demonstrably better than C at being C for the reasons listed as to why C is still the best language for SQLite. I

You would have to start at languages that are demonstrably better than C at being C for the reasons listed as to why C is still the best language for SQLite. In the present day context of vulnerabilities it's tempting to blame C. Yet it's still a good choice for many reasons. It's not wise to suggest that everything written in C must be re-written in some other language because of hand-waving reasons like buffer-overflows or off-by-one errors. Maybe you could prove Rust is a good choice by writing your own SQLite implementation feature for feature? Until then I don't think there's going to be a compelling reason to re-write SQLite because it's written in C.

kyberias 9y ago
But... who proposed a re-write?
- stochastic_monk 9y ago
  Exactly. At this point, the strongest reason for SQLite to remain in C is that it is in C.
peatmoss 9y ago
> Maybe you could prove Rust is a good choice by writing your own SQLite implementation feature for feature? A person undertaking that task would already have a head start in that they could likely use the extensive test suite for SQLite ;-)
imtringued 9y ago
>It's not wise to suggest that everything written in C must be re-written in some other language because of hand-waving reasons like buffer-overflows or off-by-one errors. These security vulnerabilities are trivial to fix at the language level but cause extremely negative consequences if exploited successfully. Yet the default stance of C programmers is to not adress them at all. A competitor like Rust absolutely becomes necessary because of the complacency of C programmers. They will then will strongly critizise the newcomer that is built on strong fundamentals as "language of the week" that is chosen by "dumber programmers" that are trying to ride the latest hype train.
- jmull 9y ago
  You're making some mistakes here. If the problem is complacent programmers, switching languages is going to have no effect. You're also making blanket statements about the attitudes of C programmers which have nothing to do with the C language. That probably means your generalizations are overly broad and not true, not even for a significant fraction of C programmers. I think you need to use some logic to argue your point, not wild claims.
  - irundebian 9y ago
    There is no need for arguments here. C leads to vulnerabilities. That's self-evident. See ISO/IEC TR 24772:2013 for more information.
    - tekknik 9y ago
      printf(“hello, world!”); Please, find the vulnerability in that code, or quit making wild claims
      - irundebian 9y ago
        Besides the fact that your code doesn't compile, I would argue that you should deliver real world examples to assess and then comparing it to alternativ solution. I know, theoretically it's possible to write secure code. Even in C. Experience showed, that 99,999% of people aren't able to do that. And many reasons have its origin in the design of this bad language.
- agentultra 9y ago
  Ignoring your comments about other programmers... Engineering is trade offs. I think the SQLite programmers are well aware of the risk the use of C brings in the context of security vulnerabilities. Given the statistics collected here: https://www.cvedetails.com/vendor/9237/Sqlite.html https://www.cvedetails.com/vendor/9237/Sqlite.html it seems that their choice of C was not a security disaster, because C. It actually seems well within a risk tolerance threshold that I don't sleep uneasy at night recommending its use in systems. If their choice of language came with unavoidable vulnerabilities I'd expect those statistics to be much worse. So what does a Rust implementation of SQLite offer anyone? That within 8 years there may be one less SQL injection attack or perhaps < 4 overflow vulnerabilities? Will it have better interoperability or performance than SQLite does now or will have once this new version is done? Will the market care? I'm not saying that care shouldn't given when choosing to use C in a greenfield project today. I am saying that for many problem domains the risks associated with C are tolerable given a well trained, disciplined team. And I doubt there's much of a market for an in-memory database system that is going to be feature compatible with SQLite in a few years that is also as performant as SQLite and can deployed on as many platforms. But that's just a prediction... maybe I'm wrong. I've chosen Haskell on a greenfield project recently for many of the safety guarantees it brings... who knows?

kyberias 9y ago

But... who proposed a re-write?

stochastic_monk 9y ago
Exactly. At this point, the strongest reason for SQLite to remain in C is that it is in C.

peatmoss 9y ago

> Maybe you could prove Rust is a good choice by writing your own SQLite implementation feature for feature? A person undertaking that task would already have a head start in that they could likely use the extensive test suite for SQLite ;-)

imtringued 9y ago

>It's not wise to suggest that everything written in C must be re-written in some other language because of hand-waving reasons like buffer-overflows or off-by-one errors. These security vulnerabilities are trivial to fix at the language level but cause extremely negative consequences if exploited successfully. Yet the default stance of C programmers is to not adress them at all. A competitor like Rust absolutely becomes necessary because of the complacency of C programmers. They will then will strongly critizise the newcomer that is built on strong fundamentals as "language of the week" that is chosen by "dumber programmers" that are trying to ride the latest hype train.

jmull 9y ago
You're making some mistakes here. If the problem is complacent programmers, switching languages is going to have no effect. You're also making blanket statements about the attitudes of C programmers which have nothing to do with the C language. That probably means your generalizations are overly broad and not true, not even for a significant fraction of C programmers. I think you need to use some logic to argue your point, not wild claims.
- irundebian 9y ago
  There is no need for arguments here. C leads to vulnerabilities. That's self-evident. See ISO/IEC TR 24772:2013 for more information.
  - tekknik 9y ago
    printf(“hello, world!”); Please, find the vulnerability in that code, or quit making wild claims
    - irundebian 9y ago
      Besides the fact that your code doesn't compile, I would argue that you should deliver real world examples to assess and then comparing it to alternativ solution. I know, theoretically it's possible to write secure code. Even in C. Experience showed, that 99,999% of people aren't able to do that. And many reasons have its origin in the design of this bad language.
agentultra 9y ago
Ignoring your comments about other programmers... Engineering is trade offs. I think the SQLite programmers are well aware of the risk the use of C brings in the context of security vulnerabilities. Given the statistics collected here: https://www.cvedetails.com/vendor/9237/Sqlite.html https://www.cvedetails.com/vendor/9237/Sqlite.html it seems that their choice of C was not a security disaster, because C. It actually seems well within a risk tolerance threshold that I don't sleep uneasy at night recommending its use in systems. If their choice of language came with unavoidable vulnerabilities I'd expect those statistics to be much worse. So what does a Rust implementation of SQLite offer anyone? That within 8 years there may be one less SQL injection attack or perhaps < 4 overflow vulnerabilities? Will it have better interoperability or performance than SQLite does now or will have once this new version is done? Will the market care? I'm not saying that care shouldn't given when choosing to use C in a greenfield project today. I am saying that for many problem domains the risks associated with C are tolerable given a well trained, disciplined team. And I doubt there's much of a market for an in-memory database system that is going to be feature compatible with SQLite in a few years that is also as performant as SQLite and can deployed on as many platforms. But that's just a prediction... maybe I'm wrong. I've chosen Haskell on a greenfield project recently for many of the safety guarantees it brings... who knows?