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

C meeting is over. C23 added:

twitter.com

Post reply on HN
Print view View original

51–60 of 363 posts

Re: C meeting is over. C23 added:

#51

Post by gefhfffh »

plafl wrote: post #36
reassembled wrote: post #20

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…

C++ requires to devote your life to it but you can learn C and spend a year using it and suddenly you have a dangerous but powerful tool in your toolbox forever.

It's not like C++ is always the only alternative, see e.g. Rust which is way simpler

Re: C meeting is over. C23 added:

#52

Post by rwmj »

diegocg wrote: post #46
rwmj wrote: post #19

Earlier quoted context omitted.

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.

[citation needed]

Re: C meeting is over. C23 added:

#53

Post by flyinglizard »

bruce343434 wrote: post #39
sgt wrote: 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…

Why does it matter if compile time is 100ms or 300ms? At even a second, that’s going to be so negligible in the context of code-compile-debug work. Especially if something like a flash download is involved.

Re: C meeting is over. C23 added:

#54

Post by dgrunwald »

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

What's being removed in C23 is the ancient K&R syntax for function definitions:

    int max(a, b)
    int a, b;
    {
        return a>b?a:b;
    }
My understanding is that C23 does not change the meaning of function declarations. So "void foo();" remains a declaration of a function accepting an unknown number of parameters.

Re: C meeting is over. C23 added:

#55

Post by flyinglizard »

uncomputation wrote: post #31
pkrumins wrote: post #6

Earlier quoted context omitted.

No one cares about the standards. We only care about getting things done by writing regular C code that works.

Huh? What do you think defines “regular C code that works”? Standards. Every compiler you have used operates at a bare minimum on the C standard. That’s why they are often advertised (if not GCC/Clang which are assumed to be up to date) as “C(89|99|11|17) compliant.” “Code that works” is code which is operates under constraints and guarantees specified by a standard, anything else is undefined or unportable.

Embedded environments are specific and esoteric enough that compiler portability is the least of your concern when migrating code from one platform to the other.

Re: C meeting is over. C23 added:

#56

Post by adrianN »

sgt wrote: 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 don't think that can be answered in general. It depends on what exactly you want to do and the maturity of the libraries in that area, and how security critical your application is.

Re: C meeting is over. C23 added:

#57

Post by pkrumins »

sgt wrote: 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?

Definitely C!

Re: C meeting is over. C23 added:

#58

Post by axiosgunnar »

rwmj wrote: post #26
pjmlp wrote: post #22

Earlier quoted context omitted.

Including plenty of new CVEs, we have to keep the security industry job market safe.

Sure, I'm certainly not arguing that C is a good language. In RHEL we turn all warnings on, compile everything with hardening flags, use valgrind during development, and feed everything through Coverity.

> In RHEL we turn all warnings on, compile everything with hardening flags, use valgrind during development, and feed everything through Coverity.

Surely the compile time is not 100ms anymore then?

Re: C meeting is over. C23 added:

#59

Post by dureuill »

sgt wrote: 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?

In general, I think they should go for Rust. See [1].

Now, embedded is a special case. You need platform support, and possibly certification, none of which are a given in Rust today. Arguably, not in C23 either at the moment, though.

[1]: http://cliffle.com/blog/prefer-rust/

Re: C meeting is over. C23 added:

#60

Post by mojuba »

dgrunwald wrote: post #54
mojuba wrote: post #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…

What's being removed in C23 is the ancient K&R syntax for function definitions: int max(a, b) int a, b; { return a>b?a:b; } My understanding is that C23 does not change the meaning of function declarations. So "void foo();" remains a declaration of a function accepting an unknown number of parameters.

According to the OP tweet though, `foo()` is now a function that takes no arguments.
Post reply on HN