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

91–100 of 574 posts

Re: C Is Best (2025)

#91

Post by lelanthran »

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,

And? GP didn't say that they shouldn't.

Re: C Is Best (2025)

#92

Post by bluGill »

Ragnarork wrote: post #63

> Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language. Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++…

You lose most of the advantages of C++ if you can't use vector, unique_ptr and the like in your APIs. Classes are also useful for a lot of things.

Re: C Is Best (2025)

#93

Post by publicdebates »

jll29 wrote: post #53
publicdebates wrote: post #37

> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. One of the very strange things about C is that it is designed by a committee that is inherently conservative and prefers to not add new features, especially if they have any chance of breaking any compatibility. This seems necessary before Rust ever becomes an old, boring language. But I don't see Rust ever goin…

> Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree. But the Rust team found a great way to avoid breaking backward compatibility: old code gets automatically compiled by the old version of the compiler, whereas more recent code is treated with the latest version of the compiler. That is much better IMHO t…

Sure, Rust can compile old code. But you can't upgrade that old Rust code to new Rust code very easily.

The fact that C was effectively "born old" means you can take a C89 program and compile it as C23 and it should simply work, with extremely minimal changes, if any.

That's a killer feature when you're thinking in decades. Which SQLite is.

Re: C Is Best (2025)

#94

Post by hmry »

Ragnarork wrote: post #63

> Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language. Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++…

Yeah, it's not a very convincing argument imho. You can write C libraries in C++ or Rust or D or Zig, and people do it all the time.

In fact, some popular C++ libraries don't even have a stable C++ API, only a C API. LLVM comes to mind. DuckDB is another example

Re: C Is Best (2025)

#96

Post by hmry »

bluGill wrote: post #92
Ragnarork wrote: post #63

> Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language. Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++…

You lose most of the advantages of C++ if you can't use vector, unique_ptr and the like in your APIs. Classes are also useful for a lot of things.

You can still use them inside your code, just not as arguments or return values from the API.

And it's not like that's a point in favor of C, since C doesn't have vector or unique_ptr either

Re: C Is Best (2025)

#99

Post by ziml77 »

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's why you don't use std in this case. You limit yourself to things defined in core.

Re: C Is Best (2025)

#100

Post by hu3 »

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.

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.

Post reply on HN