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

141–150 of 574 posts

Re: C Is Best (2025)

#141

Post by anthonypasq »

hu3 wrote: post #100
pie_flavor wrote: post #58

Earlier quoted context omitted.

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.

Bad analogy. If the alternative has drawbacks (they always do) or is not as well known by the team, it's perfecly fine to keep using the tool you know if it is working for you. People who incessantly try to evangelise their tool/belief/preferences to others are often seen as unpleasant to say the least and they often achieve the opposite effect of what they seek.

of course there are drawbacks to power tools. you could run out of battery for example and now its useless.

but everyone with a brain knows the costs are worth the benefits.

Re: C Is Best (2025)

#142

Post by toxik »

titzer wrote: post #125
runjake wrote: post #116

Earlier quoted context omitted.

Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages. The US government recently called on everyone to stop using them and move to memory-safe languages. Regardless, there are practices and tools that significantly help produce safe C code and I feel like more effort should be spent teaching C programmers those. Edit: T…

C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong. C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its us…

Asbestos causes mesothelioma and gruesome death. C does not. Be serious.

Re: C Is Best (2025)

#143

Post by lelanthran »

ok123456 wrote: post #138
irishcoffee wrote: post #126

Earlier quoted context omitted.

> The US government recently called on everyone to stop using them and move to memory-safe languages. The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al. Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m…

The DOD also made the Waterfall method THE standard software development process.

> The DOD also made the Waterfall method THE standard software development process.

I'm sure they also made a few bad decisions too :-P

Re: C Is Best (2025)

#144

Post by Koshkin »

titzer wrote: post #125
runjake wrote: post #116

Earlier quoted context omitted.

Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages. The US government recently called on everyone to stop using them and move to memory-safe languages. Regardless, there are practices and tools that significantly help produce safe C code and I feel like more effort should be spent teaching C programmers those. Edit: T…

C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong. C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its us…

> in exactly the same way

C is not known to the state of California to cause cancer.

Re: C Is Best (2025)

#145

Post by 112233 »

rvz wrote: post #29
grougnax wrote: post #26

C is considered harmful. They should rewrite it in Rust.

They actually should. As such a rewrite went so well for sudo-rs.

The article mentions 100% code coverage with tests as one of requirements from their users, and having "safe languages" emit defensive asserts and checks when compiling correct code means 100% branch coverage is impossible. How do you propose to address it with rust?

Re: C Is Best (2025)

#146

Post by tialaramex »

talkingtab wrote: post #75

Oh look. Something works. Lets not break it? How crazy is that? I sometimes wonder if what happens is like this: 1. Have problem. Need higher level computer language. 2. Think about problem. 3. Solve problem - 'C' 4. Think about problems with 'C' 5. Attempt to fix problems with 'C' - get C++ 6. Think about problems with C & C++ 7. Get: Go, F#, Rust, Java, JavaScript, Python, PHP, ...other etc. I tend to do this. The…

Although Mozilla's reason to pay for Rust R&D was because of problems with C++ it's probably not most helpful to think of Rust (let alone F#) as an attempt to specifically fix those problems.

C is a Worse is Better language (https://en.wikipedia.org/wiki/Worse_is_better). The bet is that if it's simpler to implement then the fact that what you're implementing isn't great will be dwarfed by that ease of implementation. And it worked for decades which is definitely a success.

You can make a similar argument for Go, but not really for Rust. The other side of the Worse is Better coin is that maybe you could make the Right Thing™ instead.

Because implementing C is so easy and implementing the Right Thing™ is very difficult, the only way this would compete is if almost nobody needs to implement the Right Thing™ themselves. In 1970 that's crazy, each Computer is fairly custom. But by 1995 it feels a lot less "out there", the Intel x86 ISA is everywhere, Tim's crap hypermedia experiment is really taking off. And when Rust 1.0 shipped in 2015 most people were able to use it without doing any implementation work, and the Right Thing™ is just better so why not?

Now, for an existing successful project the calculation is very different, though note that Fish is an example of this working in terms of full throated RIIR. But in terms of whether you should use C for new work it comes out pretty strongly against C in my opinion as a fairly expert C programmer who hasn't written any C for years because Rust is better.

Re: C Is Best (2025)

#148

Post by arghwhat »

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…

> People outside the project are allowed to say whatever the hell they want, the project doesn't have to listen.

Within reason - don't be a dick and all that. :)

Re: C Is Best (2025)

#149

Post by Koshkin »

ok123456 wrote: post #138
irishcoffee wrote: post #126

Earlier quoted context omitted.

> The US government recently called on everyone to stop using them and move to memory-safe languages. The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al. Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m…

The DOD also made the Waterfall method THE standard software development process.

You mean, "DOW"

Re: C Is Best (2025)

#150

Post by hmry »

chasil wrote: post #119
hmry wrote: post #72

Earlier quoted context omitted.

Yeah, results are what matters. SQLite's process seems to produce solid bug-free results. My only complaint would be that there's many SQL features I want to use which aren't supported. Surely some part of that is deliberately restricted scope, but some might also be dev velocity issues. DuckDB (C++) can be used like an SQLite with more SQL features, but it's also a lot buggier. Segfaults from your database are not w…

What isn't supported? After window functions were added, what else is missing?

The ones that come to mind immediately are more ALTER statements (especially adding non-virtual columns), DATE, TIME, and TIMESTAMP types and their associated functions, and ARRAY types. Although I don't wish to disparage SQLite, they do support a lot of features. Just that I constantly run into the ones they don't, with my use cases.

And beyond standard SQL, stuff like hashmap/bloom filter/vector indices, nearest neighbor search, etc...

Post reply on HN