38 ms·
Writing New System Software
- bullen 5y agoWhat 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.
- samhwr 5y agoSystem 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.
- deleted 5y ago[deleted]
- incanus77 5y ago> 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?
- aastronaut 5y agoMy guess would be https://www.macworld.com/article/549755/m1-macbook-app-memory-leaks-macos.html https://www.macworld.com/article/549755/m1-macbook-app-memor...
- b3morales 5y agoYeah, I don't follow why the author thinks this is due to new hardware rather than software that was changed or rewritten for Monterey.
- wapxmas 5y ago"You can write reasonably fast software in almost any decent language (with a few exceptions)." - this is entirely wrong statement.
- rightbyte 5y agoYe I feel the author has no clue what he is talking about. "I can appreciate the “macho factor” of being able to write fast software in C or C++ (or even Objective-C), but most people aren’t going to be able to do that" I mean, C is probably the simplest tool to write fast software with, since there are so few hidden costs to know about. Like strdup does a malloc. What else? In C++ you have to know implementation details of the standard lib and calling conventions to write fast code. Java, C# and Go the same but abit more. For e.g. Haskell and Julia you need to know quite much to reason about what code will be generated and good luck doing that with complex code.
- fraktl 5y ago> I mean, C is probably the simplest tool to write fast software with The simplicity is the hard part. Fishing for compliments by "pretending" it's so trivial to you shows immaturity. The author definitely knows what he's talking about. Perhaps it's you who's doesn't?
- rightbyte 5y agoI did not mean it is 'simple' to write fast C code, but that it is 'simpler'. Simpler in the amount of knowledge you need to have to write the fast program. I mean just compare "C the programming language" with Stroustrup's "C++ the programming language". It took me years to understand even a fundamental thing as move semantics. When programming fast C++ you need to be able to see what is moved properly and optimized in the way you want. How classes are inlined into the code etc. What container do malloc on construction, what containers are cheap empty, and so on and on. There is no such knowledge needed for C.
- fraktl 5y agoFrom what you wrote, it appears you don't know the meaning of "reasonably", "decent", "exception" and that you set your mind to disagreeing with the author before even fully comprehending the post.
- 5y ago
- mem0r1 5y agoI tend to disagree. (Modern) C++ is an incredibly powerful programming language. Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer.
- stevekemp 5y agoIn 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.
- vnorilo 5y agoPractical, old languages tend to do this. In C++ or Common Lisp, which share little other than being multi-paradigm (unopinionated), it is fairly common to have house styles or accepted subsets. Languages that try to build in some "house style" are my personal dystopia - such as early Java or current Go. Which does not say they ate not effective, just that I personally hate the philosophy.
- dan-robertson 5y agoBoth C++ and Common Lisp suffer a huge accumulation of historical baggage. It is this that makes the languages problematic, not being multi-paradigm. Common Lisp has first/rest as well as car/cdr. It has streams and numbers and the functions on them seem generic but aren’t (always) generic functions. It still has rplca despite (setf car) being a valid function name.
- vnorilo 5y agoSure; but "historical baggage" is a function of multi-paradigm and outliving multiple generations of computer architecture. I would not view baggage as necessarily problematic. What makes C++ problematic is that template metaprogramming evolved in a very ad hoc way, and now we need to backwards compatible all of it.
- cjfd 5y agoI think C++ is just fine. Memory management is not that hard anymore using smart pointers. I prefer that to java at any time of the night or day. Such an ugly verbose language. The buzz word laden stuff is actually quite bad. I have seen what could be rather simple systems be very unreliable and slow because of the many microservices all in their own container. Then if one is sensible enough to avoid that there is another pitfall. The cool kids like thread pools and having everything asynchronous. So a computation migrates between different threads many times between initiation and completion. I say instead: keep as much as possible single threaded and only offload expensive computations to thread(pool)s. That way one also does not need to lock the whole world, which, by the way, is far from free. Also, there are many situations where one can split computations in threads naturally as dictated by the problem one is trying to solve instead of dumping everything in a thread pool without considerations regarding what kind of queue system one implicitly creates. E.g., if one has N input channels and N is not too large one might have N threads for that.
- rightbyte 5y agoSmart pointers has some overhead though, even unique_ptr. I like to use raii to handle normal pointers. For many programs memory leaks can just be handled by exit, too.
- Glamhoth 5y agounique_ptr has zero overhead
- cjfd 5y agoThis appears to be incorrect. I have seen a cppcon talk about that. I think it may have been this one: https://www.youtube.com/watch?v=rHIkrotSwcc https://www.youtube.com/watch?v=rHIkrotSwcc . On the other hand, it is a very, very tiny minority of programmers who have to care about an overhead as low as this. Most of us should not waste one microsecond of our thinking time on this.
- JonChesterfield 5y ago
- mikewarot 5y agoThere are multiple types of system software, and it wasn't specified which. If you're talking about Embedded or Kernel Systems, writing a layer that can efficiently and securely multiplex and abstract the hardware requires a much different set of tools than the rest of the system. Here I disagree with the author. Once you're no longer concerned with directly probing the hardware, it seems far more appropriate to worry about correctness, then complexity/performance. C/C++ are unlikely to be the best match to the needs of the system and the programmer. Here I agree with the author.
- pjmlp 5y agoAll the mechanisms provided by C and C++ to directly probe the hardware are compiler extensions. Any language can have compiler extensions. Heck we used to do it in BASIC.
- berkut 5y agoQuite often (at least in HPC) you equally care about correctness AND complexity/memory-usage and performance: there's no point being fast if the result's wrong, but equally, there's often no point being correct if the result takes ages to calculate, as the premise is calculating things in a particular time frame for the complexity budget of an algorithm.
- ithkuil 5y agoComputing wrong results is rarely ok. But what matters is not only whether something is wrong but more often what are the consequences of being wrong. For example bugs in graphics rendering in games may be annoying but may cause long lasting effects such as data corruption, so it may be argued that whatever tooling you use to program your graphics can tolerate a bit more of sloppiness than the tooling you use to program your filesystem layer.
- ezconnect 5y agoIf you're good at C or C++ why use another language you don't have deep knowledge of just to say I didn't write it on a language I know.
- dilyevsky 5y agoThere are teams over one dev out there
- mynameismon 5y ago> You may like STL, but that doesn’t change the fact that a huge number of companies have policies against using it. Sources? I haven't heard of any company disallowing it, on the contrary, have heard of companies promoting its use. edit: fixed formatting
- drainyard 5y agoA lot of game companies don't use STL. I assume theremust be plenty of system software companies doing the same.
- jcelerier 5y agohttps://www.youtube.com/watch?v=6hC9IxqdDDw 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
- drainyard 5y agoI 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.
- ncmncm 5y agoCertain game companies decades ago had a house STL.
- flumpcakes 5y agoYes. I think this is so common that Rust, positioning itself as an option for a systems programming language, has the #![no_std] macro to not link with the full standard library.
- ChrisMarshallNY 5y ago> Wait, what? Stateless systems are slower!? Yes. They can be a lot slower, because they might still need whatever it is that state brings to the table (f'r instance, caching, or argument suites). They often need to rebuild the state, each time, or make it someone else's problem. I run into this with CRUD stuff, all the time. I’m not an FP programmer (they do great stateless stuff), so I am sure I could do better. These days, I spend as little time as possible, in the backend.
- c0l0 5y agoLanguage 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 https://paste.debian.net/plain/1225449) on Debian 11, you will see why. Imagine a few of those components shared between tens of packages, and security problems discovered im some. It's got to be any package maintainer's worst nightmare.
- dilyevsky 5y agoHow does having strong support for dynamic linking prevent someone from copypasting insecure code or just linking statically with your .so? Dynamic linking just makes deployment and compatibility a pain for some very dubious advantages
- gspr 5y ago> How does having strong support for dynamic linking prevent someone from copypasting insecure code or just linking statically with your .so? It doesn't. But it gives people a real alternative to doing what you describe! And only when a real alternative to something bad exists, one can reasonably demand that people stop doing the bad thing (Debian does, so does Fedora and a few other distros I believe).
- choeger 5y agoI agree. But I also think that the following two language features are important: 1. Polymorphism 2. Specialization of code and data structures Both aspects only go well together with global compilation which basically enforces static linking, unless you either substantially improve the ABI or introduce some artificial language limits regarding composition. Personally, I think that it should be possible to extend the C-ABI with some meaningful form of specialization: You effectively only need offsets and sizes in order to specialize code. But I don't have a prototype to explore this idea further.
- 5y ago
- vodou 5y agoIt is not uncommon that older/senior developers hold an undeserved grudge against STL. STL was far from mature in the 90s, sometimes even rather bad (at least in Windows/Visual Studio). But that is simply not the case anymore. Modern STL is well-written and highly optimized IMHO. Sure, it is not as "complete" as standard libraries in Python, Go, etc. It is rather a different kind of beast than those standard libraries, not as high-level, more building blocks oriented.
- pjmlp 5y agoFrom my point of view the STL still suffers from a major flaw versus the compiler frameworks from the 1990's. The whole team needs to care about secure code to turn on checked iteration in release builds, or write their own wrappers if portability to compilers without such support is a concern.
- jstimpfle 5y agoThe allocation patterns that the STL requires / encourages, as well as the usability side (error messages) and the compile speeds, probably cannot improve unboundedly, given that they API has to stay the same.
- zarkov99 5y agoI am not an STL fan, but allocation should't be a problem anymore with the advent of polymorphic allocators. At least in greenfield projects.
- flohofwoe 5y agoIME the main problem of the C++ stdlib isn't the implementation quality, but the interface design. It must be everything to everybody, but at the same time doesn't provide much control over the internal behaviour. And the interfaces can't be changed because of source code and binary compatibility requirements. In many (most?) cases, writing your own stdlib alternatives still makes a lot of sense.
- kieckerjan 5y agoIs 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.
- jillesvangurp 5y agoThe 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 point that seems rather foolish. The author's main argument is that other languages that exclude categories of bugs that keep on popping up in the C/C++ world are good enough at this point to be used for essentially all system programming stuff. Apple, Google, Microsoft, etc. employ the best people that money can buy them. And they've each started actively discouraging the use of C/C++ for new stuff. Google actually created Go for this reason and they are now also using a lot of Rust lately. Apple created Swift to get rid of object C. And MS has been trying to move to C# (which they created) for the last two decades to put a stop to all the embarrassing issues they had with their native stuff. They too seem to like Rust lately. And obviously they each have to own up in public regularly about cases where, "oops, we did it again" despite having spent the last few decades to avoid having to do that so regularly. The usual suspects are bits of C/C++ doing things wrong with memory and bounds checking because their programmers made a mistake. It seems leaving this to humans to do "right" just is not good enough at this point. The article gets a bit messy with a rant on stateful vs. stateless and a few other things. But the main argument with that seems to boil down to the notion that depending on a lot of stuff like databases, memory caches, etc. that are often implemented using C/C++ is neither fast (because of network latency) nor safe (because of the above mentioned bugs and security issues). It's true and it's why alternatives to these infrastructure components written in other languages are a thing. They are plenty fast and in so far they are not, the network latency hides most of the issues to the point where you'd not notice much difference in terms of e.g. throughput or latency at the price of maybe slightly more CPU usage on servers that are mostly running nowhere even close to 100% CPU usage. Besides, adding more CPUs is cheap. Dealing with security problems is not. And of course using Rust for things that really need to be fast is a thing. There's growing amount of projects that are about creating drop in replacements for C/C++ things that have existed for a very long time where the goal is to actually improve their performance and safety by re-implementing them in Rust. It's the argument the article does not make. But it seems that with Rust, you can have your cake and eat it in terms of performance. So, why bother with C/C++ for new stuff? Why risk security bugs when the main argument of better performance simply does not hold true anymore? It's a solid argument. But I agree the article does a weak job of making it.
- tpoacher 5y agoI have to say, when I see new articles where the main argument is that when the author sees new projects being announced that are implemented in C or C++ they quickly lose interest, I quickly lose interest in the article.
- flohofwoe 5y agoThe Rust propaganda is getting more subtle I see ;) It's only mentioned once towards the end of the post together with Go and Java. What a clever disguise.
- gspr 5y agoStrange language choices for a Rust propagandist's GitHub repositories: https://github.com/borud?tab=repositories https://github.com/borud?tab=repositories
- flohofwoe 5y agoPart of the maskirovka no doubt ;)
- chakkepolja 5y agoAs we know from stack overflow survey, rust is most loved and one of least used language, no surprise here!
- pjmlp 5y agoThe Rust propaganda or the anti-secure software propaganda that always starts to complain about Rust when one talks about writing safe software, regardless of which languages are suitable for such use cases since 1958?
- fivea 5y ago> (...) anti-secure software propaganda (...) Enough with this cargo cult belief system. Even if your choice of bicycle has training wheels, you can still fall down and scrape your knees if you don't know what you're doing. I mean, Rust already has a few CVEs for use-after-free vulnerabilities, which this cargo cult swears are rendered impossible. Just stick with your personal choice of worktool and own it. It's not the guardrails that stop you from crashing, but the way you drive.
- pjmlp 5y ago
- doctor_eval 5y agoA little bit unrelated but this made me wince: > But I have to say that I’ve noticed a shift in culture away from having a solid basis in knowledge to fashions and dogma playing a bigger role in the design choices people make. There have long been technologists who just wanna glue stuff together, go home at the end of the day and collect their pay packet. 20 years ago, I worked as an engineer in an office where a guy from IT support did some training at night school and went off to become a SAP consultant. SAP was fashionable at the time and I’m sure it had its own dogma. He probably never once thought about memory allocation or the efficiency of his code. It was absolutely not the career path for me, but there’s nothing remotely wrong with his choices, and it’s certainly not a new thing. Just different career paths, and different interests. Now - get off my lawn!
- FpUser 5y ago>"Please don’t use C, C++ or Objective-C for system software where you have a choice. These languages are terrible choices when compared to more suitable languages." Please use whatever the fuck you like to write your software and leave people alone in their choice of tools.
- ghoward 5y agoI 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/development.md#user-content-fuzzing-1 https://git.yzena.com/gavin/bc/src/branch/master/manuals/dev...
- kristov 5y agoI 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?
- ncmncm 5y agoIt is particularly foolish to pick up C at this late date. There were reasons 40, even 30 years ago. Now, unless you are coding for the Linux kernel or Postgres, it is a boat anchor. C++ will remain a sensible choice for at least two decades. Others are a crap shoot.
- user10874967111 5y ago> Apple can’t do it. You probably can’t do it much better. This made me laugh out loud. I’m genuinely curious what compels someone to write an article like this. People write C/C++ because they’re either paid to do so or it brings them joy. Just like literally every language that has ever existed or will ever exist.
- lsferreira42 5y agoRust and web3 are the top tecnologies that i completely lost interest because of how many people spam the internet about them
- timeon 5y agoYes even if the article is not about rust (author seems to be using Go) the comments (like one you did) are Rust focused.