Hacker News Reader

Comment by kelnos | Hacker News Reader

As someone who spent many years writing C, every time I go back to it, I wonder why people still write things in C.

(I'm exaggerating; of course I know why people still write things in C, but I would have a hard time justifying starting a new project in C these days.)

View on HN

I can name a couple a new projects I'm using heavily myself where using C makes sense (to me at least).

Portability might be the most reasonable argument, which is understandable when you're writing things like build systems, e.g.:

https://git.sr.ht/~lattis/muon

Then there are small tools when using anything else just doesn't buy you much, and if you're familiar with C, why bother? e.g.

https://git.sr.ht/~kennylevinsen/wlsunset

And situations like this one where you need both C API (for maximum compatibility), and manual memory management is a much for various reasons (read the blog post)

https://news.ycombinator.com/item?id=19778738

https://news.ycombinator.com/item?id=24753626

C is just fun. I do t know how else to say it. It feels like you get to really think about what you want the computer to do.

Kinda like riding a fixed-gear bike. To some, the sheer simplicity is a joy of its own. To others, little besides literal tooth-pulling even compares.

I love this analogy! (Being a fan of C and of bikes).

How does it continue? Assembly=walking, fixie=C, regular bike=fortran, electrically assisted bike=C++, electric wheelchair=python, ...

> electric wheelchair=python

:_D You made my day! I'd continue like this: barely moving eye-popping-graffiti-painted squeaky wheelchair with no bearings mounted with duck tape inside a rusty sea container, that is chained to a heavy truck with broken exhaust and flat tires = (you guessed it! :) )

> barely moving eye-popping-graffiti-painted squeaky wheelchair with no bearings mounted with duck tape inside a rusty sea container, that is chained to a heavy truck with broken exhaust and flat tires

If you add a solid rocket booster to this contraption (so that it actually moves) that would be exactly javascript.

I feel it gives a fresh taste of freedom and simplicity. Like, comparatively no magic involved.

It is alot easier to reason about performance. The code does somewhat translate to the machine instructions you anticipate.

But the greatest advantage is all the fancy pants idioms you don't feel compelled to use.

Real-mode assembly is even more fun. I highly recommend something like http://www.sizecoding.org/wiki/Getting_Started if you're into that sort of thing.

System instability and security issues are just fun! That is all I'm hearing. At this point I think we should have some sort of vetoing power on when a new kid comes in and says "I'll write it in C". He should give very convincing arguments on why he can't use a higher level, safer language. Too many people are allowed to "write it in C because it's fun" and here we are.

> That is all I’m hearing As alien as it might be to you to not use Rust or Go or Python, people really do write C because they like it — and they are aware of “system instability” usually :) This argument just makes its users seem worse off for projecting their righteousness onto other peoples’ personal choices.

I don't find it fun at all. I want to focus on what I want my program to do, not on how the computer does it, as long as its doing it reasonably efficiently. I want a successful compile to give me a decent amount of confidence that my program is correct, and is free of some classes of bugs.

Life is too short to waste time tracking down double frees, out-of-bounds writes, memory leaks, and weird concurrency issues.

I used C++ for some time, but then went back to C. Why? Fast compilation, lower complexity, long-term stability, wide support.

Definitely agree. For me these days it's Zig all the way. The flawless and painless C interop is insanely good.

Outside of UNIX clones due to symbiotic nature with C, and embedded anti-C++ cargo cult which won't even consider C99 in some cases, there is hardly a reason.

However this is hardly going to change outside the domains where corporations push for blessed languages on their platform SDKs, people keep being educated that C maps 1:1 to Assembly language and thus the myth continues.

Even Microsoft with all their security talk only allows on Azure Sphere OS and Azure RTOS, the reasoning being their target market doesn't wan't anything else.

C is the scripting language of the kernel and low-level system libraries. Other languages have approached that status, but in my experience none have gotten to the point of zero-friction integration with libc and kernel syscalls. I understand why (for one thing, not having a real string type is painful) but it helps keep C around for low-level system-call-centric code which doesn't hit on any of the things C does really poorly.

I think that when the code base is small it can be really fitting. Ones I find my favorite do almost no memory allocations. Or allocations are done only for the workset. I do not like that nowadays it seems customary to heap allocate everything and tie object's lifetime to where it keeps its state. Modern C++ with unique_ptrs sprinkled everywhere is like that.

>and tie object's lifetime to where it keeps its state

What's the objection there? I want the state to be freed when the object's lifetime ends. For something only needed during a function, a local value variable makes sense. For something that needs to last longer, either give it a move operator, or put it on the heap and use unique_ptr.

If your point is that people sometimes use unique_ptr<std::string> instead of std::string or std::optional<std::string>, then yeah I agree, that's generally not good.

That’s not his point, but you demonstrated it quite well. C++ use leads to developers that conflate memory allocation and initialization. For contrast, objective C also differentiates between the two.

Allocation and initialization should be atomic. Otherwise, the rest of the program has to deal with uninitialized objects and no invariants hold.

In well written modern C++ there are rarely memory allocations outside of STL containers. I have worked on big embedded projects that only use unique pointers in very few locations, you can do a lot of stuff without using the heap if you really want.

Can confirm. My latest backend C++ server of decent size has just a single explicit allocation happening upon startup.

In my C firmware projects I do not allocate memory at all. Everything is predetermined.

I guess I mostly wrote postmodern C++ then. The stl containers aren't lock free, and std:strings allocation behaviors are too confusing for me.

Having said that, "delete" hardly showed up at all.

When it comes to build systems, creating lightweight and efficient binaries that integrate with libraries and couple nicely with package managers... I think C is still one of the best options, although Go has come a long way and Rust isn't too far behind. In terms of security, I believe Rust has an advantage, but I've yet to find any exploits in the C programs that I use that would have somehow been mitigated completely with Rust, and there are a lot of unsafe Rust programs out there as well.

After working years in Java, C#, Python, Ruby, and others, I would have a hard time justifying starting a new project without C these days.

I write firmware for microcontrollers in C and frankly for these relatively small project C feels just right.

On desktops / servers I prefer other languages and would not want to mess with C, at least for the types of products I do.

What would you have used to write a Window Manager?

Rust, or maybe I'd try something new (to me) like Zig or Nim.

Window managers don't do all that much most of the time; I bet you could even write one in Python and not see performance issues. Hell, Go would be more than performant enough.

> and not see performance issues

And energy efficiency?

Reply on news.ycombinator.com