Live data from Hacker News

C meeting is over. C23 added:

twitter.com

41–50 of 363 posts

Re: C meeting is over. C23 added:

#41

I can't tell if this is serious. Surely if you're still using C now it's for legacy reasons. And if using it for legacy reasons you are likely stuck using an old C standard. So who will use C23?

> So who will use C23 I can't say if I'd immediately jump to C23 but I'll be thrilled to give it a try. Currently I'm rewriting an entire automotive OCPP charging point and it's associated CSMS in C because the original dev (who has no experience with Edge/IoT and just Cloud/SaaS) thought it was a great idea to implement this in golang. The binary size alone is already a problem where all I have is 30MB (needs to be…

Is it a good summary that the only reason for deciding for C instead of Rust/Nim/Zig is that not enough programmers know Rust/Nim/Zig?

Re: C meeting is over. C23 added:

#43
post #37

Based on another thread - I think the following topic should be an interesting one for HN to chew on: If someone wanted to write systems type of programming (whether it be embedded or Unix tools or even writing a library), should they go for C (C23) or Rust today?

I'm going for C, because I am experienced with C and despite it being more tedious, with having to do everything yourself, I stick with it because the compile times, and in fact the compile process, are so much faster and simpler. I really enjoy the direct feedback I can get. I considered C++ but that too had terrible compile times. Ideally a debug build should simply not take longer than 100ms for a codebase that is…

I get that the compile process is faster, but simpler?

In my experience, the compile process usually consists of "cargo build"

A advantage of Rust is that usually you spend way less time debugging, because the compiler prevents many mistakes from compiling in the first place.

Re: C meeting is over. C23 added:

#45
Removing K&R style function prototypes though is kind of big. I remember when one of the Objective-C upgrades started enforcing K&R. I don't think ObjC will be upgraded to C23 (ever, as it's a language being deprecated now I presume) so it will be stuck with K&R... while the rest will move on?

Could someone also explain what this means for pure C in terms of compatibility? If there's

  void foo();
would the meaning of it depend on which C standard is activated?

Re: C meeting is over. C23 added:

#46
post #19

I can't tell if this is serious. Surely if you're still using C now it's for legacy reasons. And if using it for legacy reasons you are likely stuck using an old C standard. So who will use C23?

Many things on a Linux system is written in C, and despite the noise on HN, developers who gets stuff done are constantly writing new code in C all the time.

> developers who gets stuff done are constantly writing new code in C all the time.

The amount of new C projects being created is falling at a fast rate. C isn't going anywhere, but it's certainly losing rapidly its prominence in the systems programming area.

Re: C meeting is over. C23 added:

#47

Earlier quoted context omitted.

I feel like there’s actually a growing subculture of C programmers of late, seemingly spawned by Casey Muratori’s Handmade Hero series, Zed Shaw’s “Learn C The Hard” way and other more recent popularizations of C and low level programming ideas. There’s a whole “Handmade” software scene growing up, seemingly as a reaction against the bloat and over engineering of more recent software trends like Electron and web apps…

> seemingly spawned by Casey Muratori’s Handmade Hero series, Zed Shaw’s “Learn C The Hard” way It's kind of unfortunately, really, because both authors have very skewed viewpoints of C that are arguably quite incorrect.

also arguably quite correct

Re: C meeting is over. C23 added:

#48
post #35
post #18

So true and false keywords are the only thing that has been added, or am I missing a part of this thread? Edit: I think one of these could be a better link: https://en.cppreference.com/w/c/23 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2864.pdf

The cppreference.com link says it removes "Representations for signed integers other than two's complement" - this could be pretty significant in making many previously implementation-defined programming patterns strictly conforming, but is it true? Doesn't seem mentioned in the Twitter thread.

This is the accepted twos complement proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf

It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?

Re: C meeting is over. C23 added:

#49
post #32

Earlier quoted context omitted.

C is the best choice if you want all of: small (both language and binaries), fast (both compiler and binaries), obvious (no/minimal complex magic), close to the metal, with excellent debugging support, portability and integrations. No other language has been battle tested for longer and more extensively than C. Your kernels, OSes, drivers, databases, web servers and compilers are written in C. If some of these featur…

Languages exist that compile to C which gives them many of the above advantages and more, so why choose C over them?

Having never used such a language, I'm curious, what's the debugging experience like? Can I source level step the application in the original language or do I have to debug the generated C?

Re: C meeting is over. C23 added:

#50
post #32

Earlier quoted context omitted.

C is the best choice if you want all of: small (both language and binaries), fast (both compiler and binaries), obvious (no/minimal complex magic), close to the metal, with excellent debugging support, portability and integrations. No other language has been battle tested for longer and more extensively than C. Your kernels, OSes, drivers, databases, web servers and compilers are written in C. If some of these featur…

Languages exist that compile to C which gives them many of the above advantages and more, so why choose C over them?

One of the criteria is "excellent debugging support" which you don't get with transpiled languages, since you'll be buried in generated code when you open the debugger.
Post reply on HN