Hacker News Reader

Comment by joaodlf | Hacker News Reader

I'm saddened by some of the comments here. It's true that C is not safe. It's true you shouldn't be using it for large portions of your professional setting. It's true that these sort of libraries appear to be slapping a bandaid on a broken bone... All of those things are true, but you should learn C. And you should learn it well.

I wonder where we will be in as little as 10, 20 years. When the C dinosaurs die and universities stop teaching the basics of computers. Young programmers are being pushed away from the harsh realities of C (not to mention anything below C), who's going to be building the building blocks in the future? Who's is going to keep optimising modern languages like Go and Rust? That minority is only going to get smaller...

View on HN

It is called progress, one ludditte at the time.

C wasn't that relevant before business started to adopt UNIX workstations.

We were happily using other languages and will continue to do so.

Neither Go nor Rust are written in C.

> who's going to be building the building blocks in the future?

There will be tens of thousands of us. The prevailing media narrative will be that there is a crisis, with not enough people available to do the work. This will have less to do with the amount of work and more to do with how much employers would like to pay to have the work done.

The very definition of programmers has been already significantly expanded (and slightly contracted in the reverse direction) for decades, and it will continue to. It is natural that the past's required knowledge is only optional or even obsolete today; what's a problem with that?

I can't speak for Rust, but for Go the answer is easy: Go programmers. That is, why implementing the full Go stack in Go was such an important step, there is little C left in the toolchain, and consequently, C programmers are not needed for most of the development.

> All of those things are true, but you should learn C. And you should learn it well.

No, you shouldn't, unless you're a historian. It's not just a waste of your time, there are enough bad design decisions that using it will actively make you a worse programmer.

> Who's is going to keep optimising modern languages like Go and Rust?

Talented Rust programmers. The language is perfectly well suited to self-hosting.

I get what you're saying, but don't be so dismissive. There are a lot of industries that will probably never move off of C (aerospace, for one). Plus, C fluency is pretty much required for serious security work.

> There are a lot of industries that will probably never move off of C (aerospace, for one).

A lot of aerospace is in Ada already isn't it? And the parts that do use C use such specialized subsets of it that general-purpose C knowledge isn't very valuable (e.g. you won't be able to use any of the libraries you're used to if you're working in aerospace).

> Plus, C fluency is pretty much required for serious security work.

Only a very niche subset of security work.

(I used to work in aerospace).

Yeah it's not all C. At my Rolls-Royce we used SCADE and assembly, and we hired a guy from Raytheon in my last couple months that was used to working in Ada. In my experience, the difference tends to be civilian vs. military projects.

But those decisions are almost always based on platform. We used C because the platform we chose shipped with a C SDK, and we had a lot of tooling based around C, not to mention standards and processes (MISRA, FAA certification, etc.). The perspective is that hardware is a stricter constraint than software is, so as a software engineer you just make it work.

But what this means is that C is pretty dominant. Rare is the occasion you'll find dev kits shipped with Ada SDKs.

> And the parts that do use C use such specialized subsets of it that general-purpose C knowledge isn't very valuable (e.g. you won't be able to use any of the libraries you're used to if you're working in aerospace).

Ehh, I wouldn't say that. Depending on the product, you might even be doing such crazy things as parsing JSON/XML, running a PHP interpreter or a JS interpreter, or other non-embedded things, and you'll choose C because of hardware limitations, like running on a 32-bit 400 MHz chip.

Usually the most stringent requirement is "no dynamic allocation", but that doesn't rule anything out, you just need to know your constraints ahead of time.

Specifically on one project I worked on, we ran Redis and used MessagePack for IPC between our processors/boards. This was an embedded Linux project with essentially no certification requirements, but our hardware was so low-spec that we needed to be very focused on maintaining efficiency. C was really the only option with existing libraries, sufficient tooling, and the necessary performance profile.

But we were careful. Our codebase was under 20k LOC. We ran unit tests, integration tests, and fuzzing. We ran code through code reviews multiple times. We had a strict coding standard. We followed MISRA (mostly), even though we didn't need to. We wrote reams of requirements and specs, and documented our code meticulously (I spent more time flowcharting my code than writing it in the first place). None of that is gonna go away by switching to a memory safe language, so it's hard to say, "Hey, switch to this language that you're unfamiliar with, even though you'll still have to do all the extra 'be careful' work anyway".

You have completely missed the point. Who are going to be these Rust programmers if no one is learning low level stuff? If all you're doing is teaching young programmers how to program in a specific language, how are they ever going to get that much closer to the machine?

What makes you think you can't do (or teach) low-level stuff in Rust?

Why and how would learning C rather than Rust make them any closer to the machine? It's not like C corresponds particularly closely to the hardware (e.g. there's no way to get access to the carry flag). Learning assembly might be worthwhile, but learning C isn't.

Because C is less safe. Simple as. If I stop worrying about certain aspects of very low level programming, I will never learn how to implement the solutions that take care of that for other programmers to benefit from.

My goodness, I'm not saying C is better, or that programming needs to be harsh by default, that memory needs all of your attention or that garbage collectors are for peasants... But there are many bonuses to learning C even today. Teach a kid Rust today and he will never really know about memory safety - it's handled, don't worry about it! My concern is when EVERYONE starts their journey like this, the small group of people that can handle it can only grow shorter.

Rust has unsafe for if you need it. You can also do resource management at high level in any language, and the techniques for that generalize very directly to implementing memory management.

There's no excuse for teaching a language that doesn't have sum types or decent structured literals, a language that twists intelligent people into absurdities like http://www.tedunangst.com/flak/post/string-interfaces . The djikstra quote about BASIC applies.

Rust is certainly interesting but it's very new and it still has a way to go to achieve the breadth of hardware support it needs to replace C/C++.

C is a thin layer over hardware. There is a reason it hasn't yet been replaced despite waves of new, safer, more powerful paradigms and languages.

While its hold has (thankfully) been eroded for the higher-levels of abstraction needed in user-facing apps today, C/C++ are still king on low-level hardware because there is basically little to no overhead compared to any other safe language.

If you need to get your code on a 8/16/24 and even most 32 bits microcontrollers, there is not a lot of choice.

Maybe Rust will eventually have enough backends, debugging tools and hardware vendor support on all theses 1000s of platforms to offer a compelling alternative, but it's disingenuous to claim you have to be a historian to study C when it's still one of the most used languages today and virtually all the hardware you own has most -if not all- of its code written in C/C++.

Rust may not be able to replace all of C's niches. It will -and I hope it does- replace C/C++ in many areas of development, but it's premature to call for the death of C when the alternative is still in its infancy.

You should definitely study C, then Rust and use what your place of work will let you use because most of the time, it's not your decision anyway.

> C is a thin layer over hardware. There is a reason it hasn't yet been replaced despite waves of new, safer, more powerful paradigms and languages.

C has already been replaced in what would have been the vast majority of its use cases 20-30 years ago, especially if we're talking about new code. At this point it's mainly alive due to inertia.

> If you need to get your code on a 8/16/24 and even most 32 bits microcontrollers, there is not a lot of choice.

Rust is starting to get some microcontroller support. And in many cases the business case has shifted away from true microcontrollers - there's no longer much or any price advantage over a proper ARM (for example), battery technology is getting better all the time...

> virtually all the hardware you own has most -if not all- of its code written in C/C++.

I don't think that's true these days. My phone is running a certain amount of C in its low-level OS, sure, but that will be dwarfed by the amount of userspace code it's running that's written in Java or similar.

>I wonder where we will be in as little as 10, 20 years.

Can't you see the writing on the wall? In a javascript framework, hosted in javascript, all the way down, to some obscure operating system programmed by the ancients that it is best not to fiddle with.

I know C. I write software in C++.

C++ is better than C in pretty much every way imaginable. Imagine, for a moment, that C++ is C but with even more tools. You don't have to use those tools, but the tools are there. You could write pure C and use a C++ compiler and have very few troubles.

Structs? C++ has that.

Structs without any member functions or constructors or destructors or fancy automatic under-the-hood magic? C++ has that too.

Global functions? Don't worry.

Inline assembly? C++ has that.

The biggest trouble I've ever encountered is when ensuring portability of exported symbols. That's typically only needed when interfacing with other languages or libraries. And it's not impossible to handle (just annoying).

I could very well imagine a future where things are built with C++ instead of C. And that future will be good.

The problem is that C++ can also be worse than C in pretty much every way imaginable due to how large and complex the language is.

If you believe otherwise then you have not worked with enough C++ codebases.

C is much simpler than C++ and with C source code what you see is what you get.

"I'm saddened by some of the comments here. It's true that COBOL is not safe. It's true you shouldn't be using it for large portions of your professional setting. It's true that these sort of libraries appear to be slapping a bandaid on a broken bone... All of those things are true, but you should learn COBOL. And you should learn it well.

I wonder where we will be in as little as 10, 20 years. When the COBOL dinosaurs die and universities stop teaching the basics of computers. Young programmers are being pushed away from the harsh realities of COBOL (not to mention anything below COBOL), who's going to be building the building blocks in the future? Who's is going to keep optimising modern languages like Smalltalk and Simula? That minority is only going to get smaller..."

It would sound ridiculous then and it sounds ridiculous now.

Reply on news.ycombinator.com