Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Is Best (2025)

sqlite.org

Post reply on HN
Print view View original

81–90 of 574 posts

Re: C Is Best (2025)

#81

Post by imglorp »

nialv7 wrote: post #67
kibwen wrote: post #17

Earlier quoted context omitted.

None of Rust's language features allocate; not arrays, not closures, not iterators. Everything is stack-allocated by default. Rust code doesn't malloc unless you use a library that calls malloc; in other words, exactly like C. Rust fully supports turning off the parts of the standard library that perform allocation, and this is precisely what embedded code and the Linux kernel does. So Rust already gives you full con…

well, as an example, Vec::push doesn't have a way to report allocation failure. it will just panic, which is not acceptable in the kernel.

That seems like an enormous question. Is anyone working on it?

Re: C Is Best (2025)

#83

Post by agentultra »

pie_flavor wrote: post #58
baranul wrote: post #34

Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP. If they are getting good results with C and without OOP, and people like the product, then those from outside the project should…

It should not be strange that a tool which is better in every way and makes your code less buggy by default has its praises sung by most of the people who use it. It would be odd to go around saying 'electric drills are strangely and disproportionately pushed at Home Depot over the good old hand auger', and even if I don't work at your contracting company I'd be slightly unnerved about you working on my house.

I’ve heard this analogy used to justify firing developers for not using GenAI: a cabinet maker who doesn’t use power tools shouldn’t be working as a cabinet maker.

If only programming languages (or GenAI) were tools like hammers and augers and drills.

Even then the cabinets you see that come out of shops that only use hand tools are some of the most sturdy, beautiful, and long lasting pieces that become the antiques. They use fewer cuts, less glue, avoid using nails and screws where a proper joint will do, etc.

Re: C Is Best (2025)

#84

Post by whatamidoingyo »

misnome wrote: post #59
baranul wrote: post #34

Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP. If they are getting good results with C and without OOP, and people like the product, then those from outside the project should…

> strangely and disproportionately pushed on Hacker News There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages. > then those from outside the project shouldn't really have any say on it. It…

"having a say on something", in OP's context, means authority and influence over decisions... People can say whatever they want, yes, but not everyone can "have a say on something".

Re: C Is Best (2025)

#85

Post by przmk »

nicoburns wrote: post #49
alexpadula wrote: post #32

Earlier quoted context omitted.

SQLite is never gonna be rewritten by its creators in another language. That is highly doubtful considering the age of SQLite and the roadmap for support I think until 2060 or mid 2050s based on what I’ve read.

> SQLite is never gonna be rewritten by its creators in another language. Almost certainly correct. It is however being rewritten in Rust by other people https://github.com/tursodatabase/turso . This is probably best thought of as a seperate, compatible project rather than a true rewrite.

I'm biased but when I see Discord as the only way of communication, it doesn't make for a serious project. I wish more projects would rely on IRC/Matrix + forums.

Re: C Is Best (2025)

#86

Post by pixelesque »

imglorp wrote: post #81
nialv7 wrote: post #67

Earlier quoted context omitted.

well, as an example, Vec::push doesn't have a way to report allocation failure. it will just panic, which is not acceptable in the kernel.

That seems like an enormous question. Is anyone working on it?

There's experimental/nightly support for things like: `push_within_capacity()` which is a more manual way (user-space code would have to handle the return code and then increase the capacity manually if required) of trying to handle that situation.

Re: C Is Best (2025)

#87

Post by kibwen »

nialv7 wrote: post #67
kibwen wrote: post #17

Earlier quoted context omitted.

None of Rust's language features allocate; not arrays, not closures, not iterators. Everything is stack-allocated by default. Rust code doesn't malloc unless you use a library that calls malloc; in other words, exactly like C. Rust fully supports turning off the parts of the standard library that perform allocation, and this is precisely what embedded code and the Linux kernel does. So Rust already gives you full con…

well, as an example, Vec::push doesn't have a way to report allocation failure. it will just panic, which is not acceptable in the kernel.

Sure, which is a perfectly acceptable default considering that most code is not in a position to observe allocation failures (because of OS-level overcommit, which is nearly always a good thing), and furthermore most code is not in a position to do anything other than crash in an OOM scenario. If you still want to have control over this without going full no_std, Rust has Vec::try_reserve to grow a Vec while checking for allocation errors, as well as several nightly functions coming down the pipe in the same vein (e.g. Vec::try_with_capacity, Vec::push_within_capacity).

Re: C Is Best (2025)

#88

Post by RcouF1uZ4gsC »

This makes sense with the quality and quantity of testing they do.

https://sqlite.org/testing.html

>As of version 3.42.0 (2023-05-16), the SQLite library consists of approximately 155.8 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 590 times as much test code and test scripts - 92053.1 KSLOC.

Re: C Is Best (2025)

#89

Post by simonw »

"In a more complete build, SQLite also uses library routines like malloc() and free() and operating system interfaces for opening, reading, writing, and closing files."

Whoa. TIL there's a minimal build of SQLite that doesn't even need malloc() and free() !

Presumably for embedded devices. I'd love to see examples of that being used in the wild.

Re: C Is Best (2025)

#90

Post by hu3 »

misnome wrote: post #59
baranul wrote: post #34

Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP. If they are getting good results with C and without OOP, and people like the product, then those from outside the project should…

> strangely and disproportionately pushed on Hacker News There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages. > then those from outside the project shouldn't really have any say on it. It…

I understand "shouldn't really have any say on it" as shouldn't expect to infuence the project. Not that they are not allowed to say anything.

Otherwise they would have written something along the lines of "shouldn't say anything about it".

Post reply on HN