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

531–540 of 574 posts

Re: C Is Best (2025)

#531

Post by sylware »

paul_ch wrote: post #516
sylware wrote: post #299

Earlier quoted context omitted.

I am talking about C syntax, not absurdely grotesque ultra-complex syntax like the ones from c++, java and similar (is that true that rust syntax is not that much less worse than c++ one now?). We need a new C, fixed, leaner and less complex: primitives are all sized (u64, u8, f64, etc), only one loop primitive (loop{}), no switch, no enum, no typedef, no typeof and other c11 _generic/etc, no integer promotion, no im…

New C is old B? https://en.wikipedia.org/wiki/B_(programming_language) I implemented some examples using B language. I like its typeless and simplicity. It would be nice if there was a modern and mature implementation of this language, it's a true portable assembler.

This "new C" would be severely different than B, and way closer to C... this new C is more a "sane and explicit oriented" subset of C than anything B.

Re: C Is Best (2025)

#532

Post by gpm »

lelanthran wrote: post #506
gpm wrote: post #464

Earlier quoted context omitted.

You can't really on linux. There's no way to do sparse allocations then because when you turn off overcommit MAP_NORESERVE still reserves memory ... It's a place where windows legitimately is better than linux.

> You can't really on linux. There's no way to do sparse allocations then because when you turn off overcommit MAP_NORESERVE still reserves memory... Sure, but ... what does that have to do with this thread? Using `mmap` is not the same as using `malloc` and friends. If you turn off overcommit, malloc will return NULL on failure to allocate. If you specifically request mmap to ignore overcommit, and it does, why are…

> If you specifically request mmap to ignore overcommit, and it does, why are you surprised?

You misunderstand, you specifically request mmap to ignore overcommit, and it doesn't, not does.

What it has to do with this thread is it makes turning off overcommit on linux an exceptionally unpalatable option because it makes a lot of correct software incorrect in an unfixable manner.

Re: C Is Best (2025)

#533

Post by gpm »

lelanthran wrote: post #505
gpm wrote: post #391

Earlier quoted context omitted.

> Are you saying that checking the result of malloc (and others) is not the default way of allocating memory? In C - yes. I've said that repeatedly now...

>> Are you saying that checking the result of malloc (and others) is not the default way of allocating memory? > In C - yes. I've said that repeatedly now... Well, that's just not true. The instances of unchecked allocations are both few and far between, *and* treated as bugs when reported :-/ Maybe you should program in a language for a little bit before forming an opinion on it :-/

I have programmed in C plenty. Your assertion that unchecked allocations are few and far between is simply entirely incorrect. That they are treated as bugs when reported is incorrect in most C software.

For good reason. Most C software is not designed to run in a situation where malloc might fail.

I, unlike you, have provided evidence of this by pointing to major pieces of the linux desktop that do not do so.

Re: C Is Best (2025)

#534

Post by pjmlp »

gf000 wrote: post #438
baranul wrote: post #216

Earlier quoted context omitted.

But oddly enough, Zig is not a memory-safe language, and yet still heavily pushed on here. There are a number of measures, comparatively, that can be taken to make C safer too. The story on what can be done with C is still evolving, as Fil-C and other related projects shows. For that matter, there are a number of compiled memory-safe and safer languages: Dlang, Vlang, Golang, etc... who could be discussed and are equ…

Pushed != interested in/talked about. People really like to mash together a bunch of random individuals into a single actor/agenda. Golang is not playing in the same niche as C/C++/Rust/Zig, but we have had countless memory safe languages that are indeed a good fit for many uses where C was previously used.

Depends on the point of view, for Reversec, it does.

https://reversec.com/usb-armory

> In addition to native support for standard operating environments, such as Linux distributions, the USB armory is directly supported by TamaGo, an Reversec Foundry developed framework that provides execution of unencumbered Go applications on bare metal ARM® System-on-Chip (SoC) processors.

Re: C Is Best (2025)

#535

Post by pjmlp »

paulf38 wrote: post #517
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…

OOP is pretty much has-been. Value semantics is the hot thing now I'd say.

That is why all major operating systems GUIs don't use it, yep.

Re: C Is Best (2025)

#536

Post by steveklabnik »

irishcoffee wrote: post #526
steveklabnik wrote: post #188

Earlier quoted context omitted.

https://ferrocene.dev/ DO-178C isn’t there yet, but I believe I heard that it’s coming. In general, Ferrous Systems works with customer demand, which has been more automotive to start.

I believe is may come, that would be really neat. Actually having it happen, someone is going to be out 10-30 million bucks. And again for each new compiler version.

Qualifying Ferrocene was way, way, way less expensive than that, and they've already had multiple versions of Rust qualified. The incremental qualifications are even easier and cheaper than the initial one is.

Re: C Is Best (2025)

#537

Post by Ragnarork »

vrighter wrote: post #527
Ragnarork wrote: post #120

Earlier quoted context omitted.

> Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics? If the interface itself has or leaks those features, no that's not easy indeed. But if those do not leak, then they can be used internally yes. My point was not that it's easy to wrap a currently existing C++ library that has modern features in its interface in a C interface, especially post-C++11.…

Then the statement "Stuff can't interoperate with c++" is true. Nothing from c++ ever gets exposed. You have to explicitly write a C interface yourself, or avoid using c++ features (write C in c++) so everything looks like C in the first place and all you need is #ifdef __cplusplus extern "C" #endif. But then you're not writing c++ either.

> Then the statement "Stuff can't interoperate with c++" is true

Where is that statement? The statement I reacted to (and with some caveats) was the following: "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++."

Which in my opinion is not true for the reason I mentioned.

> Nothing from c++ ever gets exposed

Depends what's your definition for "getting exposed". If you mean "no C++ feature from the language gets exposed" then it's mostly true (you can still wrap certain things like allocators, though painful, but there's certain C++ features that have no real equivalent in some target languages indeed). But you can definitely expose the functionality of C++ code through a C interface.

Re: C Is Best (2025)

#538

Post by steveklabnik »

irishcoffee wrote: post #525
monocasa wrote: post #382

Earlier quoted context omitted.

> With developments such as the Ferrocene-qualified compiler, Rust can now meet all the analysis requirements under DO-178C, one of the most stringent safety-critical standards worldwide.

“Can meet” vs “has met” is the entire difference. Clearly C “can meet” and “has met” DO-178. So, I posit that more languages than C “can meet” this standard. Proving it is the very hard, very expensive part. Oh, and whatever version of the rust compiler that gets certified will be locked down as the only certified toolchain. No more compiler updates every 6 weeks. Unless you go though the whole process again.

Ferrocene has qualified Rust 1.68.2, 1.76.0, 1.79.0, 1.81.0, 1.83.0, 1.86.0, 1.87.0, 1.89.0, with 1.91.0 in the upcoming release.

It's not every six weeks, but it's far faster than once every three years.

Re: C Is Best (2025)

#539

Post by irishcoffee »

steveklabnik wrote: post #536
irishcoffee wrote: post #526

Earlier quoted context omitted.

I believe is may come, that would be really neat. Actually having it happen, someone is going to be out 10-30 million bucks. And again for each new compiler version.

Qualifying Ferrocene was way, way, way less expensive than that, and they've already had multiple versions of Rust qualified. The incremental qualifications are even easier and cheaper than the initial one is.

26262 is a lot less expensive than DO-178.

Re: C Is Best (2025)

#540

Post by lasgawe »

C is the first language where I actually felt like I was programming. After using C and assembly for a few projects, every other language started to feel extremely slow. Even now, when programming with TS, my mind always goes to legacy features that offer better performance at the nanosecond level.
Post reply on HN