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

61–70 of 363 posts

Re: C meeting is over. C23 added:

#61

Post by dureuill »

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…

You could get productive in Rust in 3 months max, and then the productivity gains would quickly outweigh the initial investment

Re: C meeting is over. C23 added:

#62

Post by Didah »

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

> 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.

Out of curiosity: why do you consider Casey's viewpoint incorrect?

Re: C meeting is over. C23 added:

#63

Post by dureuill »

adrianN wrote: post #56
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.

> the maturity of the libraries in that area,

While true for C++ which is not very interoperable, C being very interoperable means that there is no advantage into using a C API from C rather than from Rust.

> how security critical your application is.

Rust also has productivity and general "correctness" advantages that go beyond security (although yes that alone is a factor)

Re: C meeting is over. C23 added:

#64

Post by kaba0 »

10x-dev wrote: post #32
mungoman2 wrote: post #2

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?

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…

C isn’t that small, compare it to a Zig hello world. Fast is relative — due to C not having good expressive/abstracting powers, it will leave you to inferior solutions, eg. counting string length multiple times at call sites, vs C++’s small string optimization, which is simply not possible in a user-ergonomic way in C. Regarding obviousness, I would add UB here, so Zig for example would beat it.

C is not any closer to the metal than other system level programming languages, this myth should just die. Your code at -O3 gets mangled to oblivion, unless you are a compiler writer of the respective compiler, you will have no idea on the generated code. This is the exact same as with C++, Rust, etc, hell, C doesn’t have proper simd support, so in a way the former two is closer to the metal.

But I do agree on portability and integrations - so C will not die, but I really have a hard time seeing why should I choose C over any of the listed languages, unless I target some obscure CPU architecture.

Re: C meeting is over. C23 added:

#65

Post by bruce343434 »

gefhfffh wrote: post #43
bruce343434 wrote: post #39

Earlier quoted context omitted.

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.

I have an IDE with clang-lint and I find that it can spot pretty much every mistake. It can even detect some lifetime issues. Other than that my programming style is very much pass-by-value, trust the compiler to inline it, so the typical memory safety issues are simply not relevant to me.

Re: C meeting is over. C23 added:

#66

Post by wartijn_ »

rwmj wrote: post #25
NotSoVeteran wrote: post #21

Earlier quoted context omitted.

The linked tweet is the 4th in a sequence. If you scroll up you should see 3 more tweets with more info.

Thanks - Twitter UI is terrible. I'm glad the terrible "defer" suggestion didn't make it, but unfortunate that they didn't standardise the existing and widely used attribute cleanup.

This is off topic, but I don't think the problem is just that the Twitter is terrible.

If you want to link to a thread, you should click on the first tweet of that thread and copy its url. It's easy to see the rest of the thread: just scroll down.

If you want to link to one tweet in a thread you should click on that tweet and copy its url.

The person who posted the link to HN did the latter, while they should have done the former.

Twitter could make it easier to see that a tweet is part of a thread though.

Re: C meeting is over. C23 added:

#67

Post by bruce343434 »

flyinglizard wrote: post #53
bruce343434 wrote: post #39

Earlier quoted context omitted.

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.

0. it is a noticeable delay and impinges my momentum

1. A flash download is not involved

2. I hardly debug. I seem to be in a minority here, but my linter really does catch pretty much everything. I don't blindly write code, I always ponder my approach first.

So basically, the compile times pull me out of the flow.

Re: C meeting is over. C23 added:

#68

Post by jesprenj »

mojuba wrote: post #60
dgrunwald wrote: post #54

Earlier quoted context omitted.

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.

Wouldn't int foo(void) be a function that takes no arguments and int foo() a function that takes an unknown number of arguments?

Re: C meeting is over. C23 added:

#69

Post by kaba0 »

dkjaudyeqooe wrote: post #10
mungoman2 wrote: post #2

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?

C is a portable alternative to assembly language.

I don’t see my SIMD instructions anywhere.

Re: C meeting is over. C23 added:

#70

Post by suprjami »

mojuba wrote: post #60
dgrunwald wrote: post #54

Earlier quoted context omitted.

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.

That's a different thing. That's implied `foo(void)`.
Post reply on HN