Ask HN: Learn C in 2023?

It ships with pretty high-level libraries (connecting to a Wi-Fi network is ~200 lines of C code), and you'll be running on top of a small operating system (FreeRTOS). But you still have full access to hardware and all the fun of working directly with it. The dev boards are quite cheap at $3-4 per piece, and have lots of peripherals (including Wi-Fi and Bluetooth).

Have a look for ESP-WROOM-32D at aliexpress, or whatever the platform of choice in your country is. Some of the newer boards are built on RISC-V, if that's your thing.

Their SDK also has first-class Linux support (and the other two OSs, obviously).

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/

I don't think I've ever seen this criticism leveled elsewhere. Do people criticize JavaScript programming because the ECMAScript standard doesn't give you everything you could want?

I love C. As dangerous and as tedious it can be for large projects, I think it's my top choice for solo endeavors that don't require too many string manipulations. I don't think any language has come close to achieving the same balance of elegance and simplicity--maybe scheme? (zig comes close but has a substantial number of features that move it away from simplicity (e.g. payload capture))

Hard +1 on this!

I think Eskil Steenberg work in C is really top notch - the video is heavily recommended, as is an overview of his work in general, he does some awesome stuff with C.

    /* draws a point at 10, 5 */
    struct point p;
    p.x = 10;
    p.y = 5;
    draw(p);

    struct point p = {
        .x = 10,
        .y = 5
    };
    draw(p);

    draw((struct point){ .x = 10, .y = 5 });

I also recommend his book.

It's really out of date. It doesn't cover subsequent C standards; and it doesn't cover any of the best practices that have subsequently evolved to protect us from the things in C that are deeply awful (in retrospect) in the original. Or any of the evolved practical lore for writing good, portable, safe C code.

RIP me who has spent 3 weeks on this

Great project for sure though!

If you want to create your own language and want to experience what choices are subpar by modern standards - C is way to go.

If I had choice then I'd pick Rust anytime when messing with low level programming.

I don't understand fascination with C just because it's "tradition" "everywhere" or "gives you full control" - especially that, since it brought us countless security issues

Some languages like Rust and Haskell do a little better by having the compiler keep track of most of them (if you use it right) but the consequence of misunderstanding them here is accidentally coding yourself into a corner which is extremely unpleasant.

There are other things people like to talk about like automatic memory management and package management and again I'm not convinced these really improve much. The pain of allocating memory in C means people often find ways to avoid doing it altogether which results in much more predictable behavior. Same with pulling in third party libraries. It's rare using more than a couple is actually beneficial but when the package manager is there the temptation is way too much for most people and the result is both unpleasant and very vulnerable to supply chain attacks.

I'm still not convinced any of this is the improvement people think it is.

C can be dangerous, yes. No one is denying that. C is also extremely stable, fast, and a "known-known". With proper discipline that any experienced developer of ANY language will have C can be very safe. Most, if not all, dangerous errors can be found and fixed simply by understanding how to use valgrind. With the advent of modern CI/CD it's never been easier to remember to valgrind your code.

C is probably the first language I would use in an environment I cared a lot about. For example, if binary size, availability of libraries, competency of programmer, etc would be in my list of concerns I would use C. I take particular offense to the "RNG" part of your analogy. C errors are not random at all. They are always the developer's fault and are often very predictable (use-after-free, poor array hygiene, etc). Despite the ever-evolving condition of post-C religions (Go, Rust, etc) there are only a handful of languages that fit the bill for a so-called serious systems project. C, C++, Java, and C#. You simply will not find a better library ecosystem and community of highly tenured developers to draw from for at least another decade in other languages.

Confession time: I came to this thread to Ctrl-F for "Rust" to find the Rust-C fisticuffs. And this answer is like what I would expect if I said "ChatGPT, write me a reddit-style Rust defense that would rustle some jimmies."

I'm about equally capable at both Rust and C - I could pass a 1st year undergrad CS course using either, but I'm no better than that.

I know C has its place - its marketshare of embedded devices and gamedev is huuuge - and Rust... may eventually reach a similar place of importance, but isn't there yet.

I also know the very best C and Rust devs are pretty much geniuses - Ph.D. level understanding of math, that kind of thing - and would squash me in any type of fair competition.

Maybe in the year 2050, an attitude of condescending acceptance towards C might be appropriate. And also... maybe not, because C might not slip. Who knows?

And really, beyond this pretty crude but accurate-ish description, I think we're getting into unnecessary hair-splitting, among people who don't work with either and wouldn't understand the tradeoffs anyway.

If you like it you could buy the print version.

There are some things he writes that are a bit controversial but generally I think it is very thorough. Sometimes it felt a bit dry to read to me.

First, Code by Petzold to make sure you understand how a computer truly works. Then I recommend:

Understanding Microprocessors (Motorola)

8086/8088 Assembly Language Programming

Dissecting DOS

Practical Filesystem Design

FreeBSD Internals

The reason there are so many books is because it’s a big topic. The reason most are old is that things were once much simpler. Modern stuff builds on old, so if you get a good understanding of older stuff, you have an idea of what is happening. From there, I strongly recommend getting a good understanding of UEFI. UEFI will handle most of your system initialization no boot requirements, allowing you to focus on higher level stuff. Prior knowledge of systems will still be a requirement so that you can understand some of the assumptions and choices that UEFI makes.

OSDev is fun. I hope you have a good time.

Highly recommend learning CMake or Meson instead.

If you're just getting started, there's no need to tie yourself into knots learning "how to set up a project the right way". It's a waste of time. Your time would initially be better spent just calling the C compiler directly. This will help you learn a bit about the compilation and linking phase and will expose you to the C compiler's flags---useful skills for debugging automated builds later. Once you get to the point where you are working on a larger project, then you will be in a better position to decide what build tools are most useful for you.

I'd guess it is because Sturgeon's Law[1] applies to most things on the internet. In fact there is so much crap when it specifically comes to instructional material on the internet that it reaches a point where we find that Sturgeon's Law was only a linear approximation to crappiness that is only valid with the relatively limited crap levels they were capable of producing 60 years ago when Sturgeon's Law was formulated.

The internet is capable of achieving crap harmonics, and we find that something like 90% of the stuff that doesn't seem to be crap is actually crap too.

The HN answers to this question are going to have a much lower crap level which will keep them well within the linear region of the Law. Many here recognize that having someplace that answers this question with only a 90% crap level is good and so upvote it.

[1] 90% of everything is crap