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

31–40 of 257 posts

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

#31

Post by attractivechaos »

nousermane wrote: post #12
Sakos wrote: post #11

Earlier quoted context omitted.

Is that even possible as long as the Linux kernel is written in C? I wonder if telling people not to learn C will have a long-term effect on being able to find competent contributors to the kernel.

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

The Linux kernel comes with many old drivers that modern programmers have little knowledge about. It is probably more realistic to write a new kernel in rust (like Redox), targeting modern machines only.

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

#32

Post by flohofwoe »

sylware wrote: post #14
fjfaase wrote: post #2

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

C syntax is already way too rich and complex, not to mention the bazillions of gcc extensions required to compile the linux kernel. Namely, if it has to be "replaced", that would be with something with a much simpler syntax, which will require a bit more of finger power. We don't want to find ourself locked-in by very few compiler vendors (open source or not), that only because it is not reasonable to code a real-lif…

TBH that sounds a lot like Zig (it has two loop keywords though: for and while, but those are for different use cases - for is only for iterating over ranges, and while is the 'vanilla loop' for everything else). Zig does introduce a bit of syntax pollution for its comptime features though (mainly the 'inline' variants of existing keywords), and it adds some syntax sugar for the builtin error handling and optionals - so it's essentially a dismantled C which is then slightly extended into a different direction.

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

#33

Post by chillingeffect »

ImprobableTruth wrote: post #17
unwind wrote: post #13

Earlier quoted context omitted.

Wow that sounds fantastically optimistic, or pessimistic depending on your point of view I guess. Rewriting that amount of code in ten years sounds very very hard, at least.

They said a C-free build. For that you'd need to "just" rewrite the core kernel, which will be 150-200k lines, and the drivers + arch specific parts for one system. Still a tall order, but a decade isn't unrealistic if Rust proves itself. Now, rewriting everything , including all the legacy drivers? Yeah, never happening even if Rust succeeds utterly.

Once they get to that point, a new language will be available that makes up for the things Rust is still short on.

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

#34

Post by sirsinsalot »

hgs3 wrote: post #28
fjfaase wrote: post #2

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

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.

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

#36

Post by pjmlp »

hgs3 wrote: post #28
fjfaase wrote: post #2

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

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…

Languages like PL/I, NEWP, BLISS, Modula-2 did it much better, but they didn't come with a free beer OS.

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

#37

Post by zozbot234 »

Decabytes wrote: post #8
fjfaase wrote: post #2

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

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.

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

#38

Post by Tomte »

kovac wrote: post #30
fjfaase wrote: post #2

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

Can C really completely go away as long as there's embedded programming? Are there any other alternatives for that domain?

There are embedded devices programmed in other languages, you know, and there have been for decades. In Ada, for example. Which is an even better fit to the domain than C (better ways to describe hardware idiosyncracies).

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

#39

Post by pjmlp »

> The combination of BASED and REFER leaves the compiler to do the error prone pointer arithmetic while having the same innate efficiency as the clumsy equivalent in C. Add to this that PL/1 (like most contemporary languages) included bounds checking and the result is significantly superior to C.

https://www.schneier.com/blog/archives/2007/09/the_multics_o...

"Multics B2 Security Evaluation"

https://multicians.org/b2.html

But naturally ignoring it was more fun,

> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.

https://www.bell-labs.com/usr/dmr/www/chist.html

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

#40

Post by rightbyte »

JonChesterfield wrote: post #35

I maintain that C is fine and optimising compilers converting 'bad' C into dangerously broken binaries is not fine. We don't need to replace C to make it safe, we need to take the edge off undefined behaviour justified compiler rewrites.

I believe the main culprit is that the compiler guys want to optimize away Cpp templates, where programmer intent is not as explicit as in C.
Post reply on HN