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

50 years of C, the good, the bad and the ugly [video]

streaming.media.ccc.de

Post reply on HN
Print view View original

71–80 of 257 posts

Re: 50 years of C, the good, the bad and the ugly [video]

#71

Post by elcritch »

zozbot234 wrote: post #37
Decabytes wrote: post #8

Earlier quoted context omitted.

I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that mak…

SafeC and CheckedC do nothing for temporal safety. Zig is in the same boat. There's not really a simpler alternative to Rust with the same featureset, even its direct predecessor Cyclone was in fact quite a bit harder to use. Rust itself is also improving very quickly and becoming easier to use over time.

Unfortunately, Rust's core design philosophy is fundamentally opposed to much of the design philosophy that made C and C++ so popular and flexible.

It's almost the exact opposite extreme on the pendulum, where C allowed anything while Rust limits to only what the language designers conceive as proper and not just safe.

Zig can gain memory management systems like Nim's ARC which works well for system design and adds temporal safety. On the other hand Rust's trait system likely will never become an "open ended" type system like say Julia's. Heck, even overloaded function types don't seem likely in Rust.

Re: 50 years of C, the good, the bad and the ugly [video]

#72

Post by youarethejoke »

WastingMyTime89 wrote: post #67
sn41 wrote: post #61

Earlier quoted context omitted.

> that’s pretty much it. Only if you ignore 1. variadic arguments as in printf, 2. function pointers which are a very elementary (type-unsafe) form of closures, 3. a nice way of casting to void 4. setjmp and longjmp goodies (?) which allow you to code up co-routine libraries and exception handling mechanisms I'm sure there are more such facets I am missing. The elegance of the specification may be questionable, but t…

There is no elegance there. Casting to void is not a plus. That’s just C having no proper type system. Function pointers as an elementary form of closures, come on, what’s next? Closures are defined by capture. It’s nearly as fun as pretending C as coroutines because of setjmp . How can a statement like C being semantically poor even be seen as controversial? For god sake, we are talking about a language which semant…

You really don't understand, but that's okay. C is a wonderful language, and that's the end of it really. You just try to think C as a language that SHOULD HAVE all the stupid bells and whistles you find convenient. Many of us more advanced coders have found that those stupid bells and whistles are, in fact, inconvenient. Casting to void is a powerful technique and the limits are literally endless. C is semantically rich, way beyond your dull imagination.

Re: 50 years of C, the good, the bad and the ugly [video]

#73

Post by bakuninsbart »

colanderman wrote: post #59
nikbackm wrote: post #48

Earlier quoted context omitted.

C++ should be even better in those categories.

Art is often about constraint, and mastery of simple tools. I identify with @antirez's sentiment. I know both C and C++ very well. I find C definitely more artistic. C++ is utilitarian. Prolog is the other language I code in "artistically". It too is quite simple and constrained, though it is on the opposite end of the high/low-level spectrum as C.

What is your take on Perl and Ruby? They seem to be the two languages where the communities themselves talk the most about poetry and elegance.

Re: 50 years of C, the good, the bad and the ugly [video]

#74

Post by ansible »

tmtvl wrote: post #70
nousermane wrote: post #12

Earlier quoted context omitted.

> Linux kernel is written in C Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html It might take another decade for a C-free build to be possible, though.

As long as there isn't a Rust compiler written in Rust (there is a transpiler to LLVM bytecode, but that gets compiled by a C++ compiler, same for GCC-rs) I don't think a C-free (or a C++-free) build will be possible at all, so I'm guessing it'll take somewhere in the 60-100 year range.

There are some open issues and features like inline assembly that aren't supported, but a moderately complete backend exists now:

https://github.com/bjorn3/rustc_codegen_cranelift

The compiler frontend is already written in Rust.

Re: 50 years of C, the good, the bad and the ugly [video]

#75

Post by Koshkin »

nikbackm wrote: post #48
antirez wrote: post #41

A different take on the matter: I write code mainly artistically, and I found that C is one of the best languages available to code as a form of art. It allows to be both brutal and honest, or abstract and deceiving. Not many languages are so semantically powerful.

C++ should be even better in those categories.

True; on the other hand, personally, I think that normally C and C++ shouldn't be even mentioned in the same context. (My C++ code bears virtually no resemblance to my C code.)

Re: 50 years of C, the good, the bad and the ugly [video]

#76

Post by KerrAvon »

sirsinsalot wrote: post #34
hgs3 wrote: post #28

Earlier quoted context omitted.

C is the best abstraction for many problem domains and that isn't going to change. I understand why folks coming from higher-level languages would dislike it, but for anyone coming from assembly it's a godsend. The speaker discourages C for new projects, but that says more about the problem domains they work in than C itself. C is what it is because the hardware and assembly language are what they are. Folks who want…

Anyone discouraging a particular tool without actual context of the problem being solved gets zero respect from me. It's a massive red flag that they don't know enough to be useful. C is great for the things C is great for, however small that range may or may not be now and in the future. Any other stance is reductive and misleading.

Exactly what, in the year 2023 C.E., is C great for?

I’ve been writing C since 1991 and I can’t think of anything where I wouldn’t start a new project in some other language. There are many interesting choices of varying maturity in the low-level systems programming space: Zig, Rust, Crystal, D, Swift (if the standard library ever gains support for system-level programming). Even the “better C” subset of C++ will allow you to avoid certain classes of security bugs completely.

I don’t think C is even merely adequate for anything at this point; defaulting to memory safety is table stakes in any domain where C was once dominant.

Re: 50 years of C, the good, the bad and the ugly [video]

#77

Post by youarethejoke »

pjmlp wrote: post #51
AstixAndBelix wrote: post #10

Earlier quoted context omitted.

We can replace COBOL with a Java backend to keep the enterprise feeling going, but what would C's replacement be in this case?

C++ for starters, would already be an improvment, provided string, array and vector classes with bounds checking, get used instead of raw C pointers. Alongside RAII for resource management.

For most embedded stuff those are just extra hassle and not worth it. C and its raw pointers and are really all you need most of the time. The need to have some discipline and expertise to produce solid code with confidence is not a bad thing in the embedded domain. If the code truly is critical you need to dive deep into verification techniques anyway.

Re: 50 years of C, the good, the bad and the ugly [video]

#78

Post by KerrAvon »

zozbot234 wrote: post #37
Decabytes wrote: post #8

Earlier quoted context omitted.

I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that mak…

SafeC and CheckedC do nothing for temporal safety. Zig is in the same boat. There's not really a simpler alternative to Rust with the same featureset, even its direct predecessor Cyclone was in fact quite a bit harder to use. Rust itself is also improving very quickly and becoming easier to use over time.

True dat. But I want to note:

- Swift has plans to incorporate temporal safety in upcoming releases. - Zig isn’t fully baked yet.

Rust will be king of that space for a while, though.

Re: 50 years of C, the good, the bad and the ugly [video]

#79

Post by ptato »

keewee7 wrote: post #9
Decabytes wrote: post #8

Earlier quoted context omitted.

I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that mak…

Is there a reason Zig is taking so long to go 1.0? The language itself feels mature.

the self-hosted rewrite took a long time so it felt like the project had stalled for the past ~year. the team has started working on new features like the package manager, though.

Re: 50 years of C, the good, the bad and the ugly [video]

#80

Post by Koshkin »

coldcode wrote: post #63

I bought a C compiler at my job in 1984 because I thought it was the future, then spent nearly a decade writing MacOS apps in C. I even added object extensions to it (for our use) in 1989 because C++ was not an option yet. I worked with Objective-C in the late 90s and again in the 2010s, which is basically C with funky object stuff. I don't miss it at all. C is very low level and so easy to write bad code in if you d…

Only a mother could love Swift's syntax. The classic K&R C, on the other hand, was the very definition of simplicity and elegance. (Objective-C is a whole another topic, of course.)
Post reply on HN