Live data from Hacker News

Writing New System Software

borud.no

91–100 of 158 posts

Re: Writing New System Software

#91

Is it me or is this essay really an incoherent mess? As much as I would like to agree with the author's stern verdict (and I am saying this as a systems programmer with more than 20 years experience) I cannot make out the central argument.

The central argument is that C/C++ is not worth the trouble for new code and that using it "correctly" is a theoretical thing that even experts struggle with. C/C++ programmers keep on insisting that they've found ways to do it right, finally. Some C/C++ programmers seem to believe that, unlike everybody else, they actually have the combination of wisdom, skills, and discipline to not fall into this trap. At this poi…

> unlike everybody else, they actually have the combination of wisdom, skills, and discipline to not fall into this trap

I'm constantly reminded of the NPC in Half Life 1 who says something like "Take me with you, I'm the one man who knows everything!"

I know many programmers who think their one way of writing C++ will not cause any issues. None of them are 100% correct as I can always find a bug that a higher level language could have prevented and I'm not an "expert" in C++. I just know enough to be dangerous.

Re: Writing New System Software

#92
post #25

Language preferences and safety features aside, I for one am 100% convinced that a/the upcoming language to rule "systems programming" (in a FOSS world with community participation) MUST have strong support for dynamic linking. If you look at something like `apt-cache show podman | grep ^Built-Using:` (Output: https://paste.debian.net/plain/1225449 ) on Debian 11, you will see why. Imagine a few of those components s…

> It's got to be any package maintainer's worst nightmare.

Is this really a problem in most modern package management systems and build systems? I think Nix is a great example of handling this gracefully by just tracking the inputs and outputs of each compilation and sandboxing the compilation so we can guarantee the build definition includes all specified deps. This is something debian can build on top of apt.

Re: Writing New System Software

#93
post #36

Earlier quoted context omitted.

In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". At the point you rule out using available facilities of the language you might as well use something else.

> (...) such as Google's famous "no exceptions". If I recall correctly, Google's rationale regarding exceptions is that their legacy code is not exception-safe, and so they were faced with the choice of either rewriting critical parts of their legacy code to handle exceptions, or don't use them. Also, their "no exceptions" rule only applied to work involving their legacy code. I'm too lazy to find the source, but tha…

(Opinions are my own)

> Also, their "no exceptions" rule only applied to work involving their legacy code.

The reasons for not using exceptions are outlined in this post: https://abseil.io/tips/76

absl::Status is basically exceptions without language sugar. Or, another way of looking at it, golang err in C++. Basically, non-local control flow is dangerous as it can't be evident to the programmer when something deep in the stack will bubble up an exception.

It is super annoying to deal with sometimes but there are a lot of amazing helper macros (yuck for other reasons) that exist. More details can be found looking through here: https://cs.opensource.google/search?q=ASSIGN_OR_RETURN&sq=

Re: Writing New System Software

#95
post #2

What is System Software? Like an OS? I'm 99% settled on using Java on the server and C on the client for the rest of my life.

System programming is quite poorly defined in general. I’d call it “the kind of software usually written by people who write C instead of Python”, and leave it at that.

Re: Writing New System Software

#96
post #80

Earlier quoted context omitted.

I think the evidence outweighs opinions, and I think the evidence says that it is hard to avoid memory management problems in C++.

I do not have single explicit memory management call in my product of very decent size written in modern C++. So no , I have no idea where did you fish your "evidence" from.

I don’t understand what you’re trying to say? Do you mean that you don’t call malloc? Because that is totally not the point. For example, you could create a new object, pass a reference to it to some function that stores it in a hash table, reach the end of your function where the object is automatically deleted, and then have something try to read the object out of the hashtable. Nowhere do you need to call malloc or do any explicit memory management and yet you have a use-after-free bug. Some evidence can be found in my reply to the sibling comment which talks about chrome, a large and very well-tested C++ application mostly in a modern style. There are also surveys of security vulnerabilities that find a large percentage are due to incorrect memory management.

Maybe I’m just missing the point though as I think I’m only writing obvious well-known things and you probably mean something more nuanced?

Re: Writing New System Software

#97
I really want to rid the world of memory bugs, so you think I would agree with TFA.

But unless he includes situations where you must have zero dependencies (besides what is already expected to always exist, like a C compiler) among the situations where you have no other choice, then I disagree with him.

My last project and my current project are both in C. I hate that that's necessary, but the truth is that C is supported basically everywhere. It means that I can claim zero dependencies because it's de facto true, in that no user has to go and find other things to make my software work.

For example, if I wrote in Rust, the user would have to install Rust if they don't have it already, so I would consider that a dependency.

Of course, the fact that I am writing in C means that memory bugs can happen, so I had to have a plan for getting rid of them before release, and I do. (See [1] for an example.)

I guess what I am trying to say is that there's (unfortunately) still a place for C, and that (unfortunately) that place may be bigger than at first glance with the existence of things like Rust.

And I think that will remain true until Rust or some other competitor is as ubiquitous as C.

[1]: https://git.yzena.com/gavin/bc/src/branch/master/manuals/dev...

Re: Writing New System Software

#98

Earlier quoted context omitted.

A lot of game companies don't use STL. I assume theremust be plenty of system software companies doing the same.

https://www.youtube.com/watch?v=6hC9IxqdDDw anecdotally in the last ten years I haven't seen a single C++ codebase not using the stl, except arduino-level stuff

I assume a lot of people roll their own containers and use STL algorithms, which makes a lot of sense if you need control over allocations but still want to utilise the STL.

Re: Writing New System Software

#99
I am a professional software developer for over 16 years, and learned C in the last 3 or so years for interests sake. I would most likely fall into the category of C developers that think they know enough tricks to get by, but probably write terrible code without realizing it.

> Yes, you can write things in C and C++ that are very fast, but statistically, it is unlikely that you have the skill and discipline to do so consistently and at the same time deliver quality and robustness.

I would love to know how to get to this level. C is such an elegant language, and I really enjoy programming in it. Seems like there must be a way to get really good at C... But how?

Re: Writing New System Software

#100

> Just look at how badly Apple struggles with memory leaks now that they have switched CPU architecture and all the latent gremlins in their code start to manifest. What the hell is this referring to?

Yeah, I don't follow why the author thinks this is due to new hardware rather than software that was changed or rewritten for Monterey.
Post reply on HN