Live data from Hacker News

C meeting is over. C23 added:

twitter.com

291–300 of 363 posts

Re: C meeting is over. C23 added:

#291
post #92

Earlier quoted context omitted.

It does for a novice. But once you learn Rust, it's actually quite productive. Rust has proper collections, strings, iterators, automatic (but not GC) memory management, error propagation, etc. This eliminates a lot of busywork, and makes Rust "denser", so you write less code, but get more done.

No, the greenfield coding phase of Rust will always take longer than the same code in C: Rust will require you to think things through, while C by default accepts any morass of half-defined code. The eventual rust code+debug+maintain speed will be higher than the equivalent C speed, for the same reason. This means that rust is slower for vanity projects that won't be used in practice, or for low quality products with…

I know where you're coming from. I've felt the same when I was novice in Rust, and could not imagine how people get anything done when 10 lines of code have 10 borrow checker issues to deal with. But this obstacle completely goes away once you understand ownership and Rust idioms, instead of trying to make rustc accept C-style code.

I have many years of experience in both, and I can confidently say that for experienced programmers Rust is both quicker than C to get something useful working, and to get projects polished and production-ready.

Rust has a useful standard library (compared to C). You have hashmaps, btrees, or vectors with lots of helper methods all available in less than it takes to hand-roll a linked list.

Rust has lots of high-level crates that you can leverage. You need to fetch some JSON? It's a few lines of code to get it into a native struct, type-checked for you. You can have it running in less than it takes to craft a Makefile.

Rust is also productive for robust code. You don't fiddle with malloc, so the whole `goto cleanup` code is gone, and you don't spend any time chasing memory corruption, leaks, or unexpected NULLs. And these are often static guarantees, not something to fuzz out of a stanitizer.

If you need code to be multi-threaded, it can be as easy and high-level as OpenMP, but you get a compile-time guarantee of no data races, even in 3rd party code you use. Some errors pointed out by the Rust compiler have saved me what could have been weeks of heisenbug debugging.

It's normal that you move slower when writing an unfamiliar language, and Rust certainly has a steep learning curve. But once you learn it, Rust feels closer to high-level scripting languages than C.

Re: C meeting is over. C23 added:

#292
post #184

Earlier quoted context omitted.

Adding so-called fat pointers to C that could be bounds checked would probably instantly eliminate a large fraction of all security issues. Of course, you can emulate these yourself, it's just a struct but not everyone does.

C99 introduced variable-length array parameters and variable-length array pointers together with variable-length arrays (VLA). These take another parameter or variable as a length-parameter. These became optional in C11 together with VLAs (for some reason) but are supposed to again become mandatory in C23. However (yet, for some reason) the pointers can (in the latest published draft, still) only be inside procedures…

People don't really get the distinction you make here, which is a shame. Often any VLA's are outlawed which is tossing the baby out with the bathwater.

Re: C meeting is over. C23 added:

#293
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…

IME ObjC (unlike C++) automatically supports the latest C standards, because ObjC just adds some syntax sugar on top of C, but otherwise doesn't 'mangle' its C subset into its own dialect like C++ does.

>IME ObjC (unlike C++) automatically supports the latest C standards,

This is only true as long as the changes in C aren't conflicting with ObjC. In the future if ObjC is deemed dead by the council it won't have to worry about such things. So C58 may have tons of things that don't work in ObjC98 (or whatever the ObjC version is).

Re: C meeting is over. C23 added:

#294
post #267

For all of us that follow an "I do not want to log in to twitter" philosophy, can someone here please post an alternative link? Incidentally, I'm glad Twitter now blocks you from reading if not signed in. I'm hoping this will encourage the use of alternatives.

I'm not signed in and read it fine. My uBlock filters are twitter.com##[id^="layers"] > [class^="css-"]:has([dir^="auto"]):not(:has([aria-expanded])):has(a[href^="/"]):has-text(/Log in|Sign Up/) twitter.com##html[dir]:style(overflow: auto !important;)

[deleted]

Re: C meeting is over. C23 added:

#295
post #153

Finally C catches up with Algol 60 boolean types, it only took 60 years. Maybe in another 60 it will get proper strings and arrays.

Algol 60 pales and laughs nervously in the shadow of the Algol 68 giant and its type system towering over it.

Re: C meeting is over. C23 added:

#296

C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.

C99 is the last sane language left. The additions since then are just minor syntactic sugar.

gg

Re: C meeting is over. C23 added:

#297
post #106

Earlier quoted context omitted.

Only the standards people care about standards. We (programmers) want to just get things done. We don't care about the standards. No one reads the standards. Also no one cares about portability. All computers have been the same for the last 20 years.

We, developers, care about standards, because we want to get things done once.

[deleted]

Re: C meeting is over. C23 added:

#298
post #153

Finally C catches up with Algol 60 boolean types, it only took 60 years. Maybe in another 60 it will get proper strings and arrays.

I wonder what other string could have C used 50 years ago that would have stayed usable for that long.

I love that, thanks to C, plenty of old programs can still be used today. In these days of accelerated bit-rot and language "communities", and perpetual rewrite of everything over and over again, C stability and ubiquity is a safe harbor, and has been at least until now a good investment.

I have no idea what you mean by "proper arrays". I guess bound checks?

Re: C meeting is over. C23 added:

#299
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?

C, because I don't know how to do intrusive data structures in Rust.

Re: C meeting is over. C23 added:

#300
post #251

Earlier quoted context omitted.

How does it annoy you? Development velocity, creativity hinderance?

Visually it’s annoying. It’s like the comic sans of programming languages.

I used to code Perl in the late 90s. To me it doesn't look /that/ bad.
Post reply on HN