Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing New System Software

borud.no

Post reply on HN
Print view View original

61–70 of 158 posts

Re: Writing New System Software

#61

Post by doctor_eval »

A 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!

Re: Writing New System Software

#62

Post by zarkov99 »

jstimpfle wrote: post #46
vodou wrote: post #35

It 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 librarie…

The 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.

I am not an STL fan, but allocation should't be a problem anymore with the advent of polymorphic allocators. At least in greenfield projects.

Re: Writing New System Software

#63

Post by flohofwoe »

vodou wrote: post #35

It 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 librarie…

IME 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.

Re: Writing New System Software

#64

Post by pjmlp »

flohofwoe wrote: post #60

The 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.

The 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?

Re: Writing New System Software

#65

Post by zarkov99 »

dan-robertson wrote: post #58
jstimpfle wrote: post #56

Earlier quoted context omitted.

> 2. I basically don’t believe that memory management is not hard. If you try to write Java in C++ then probably the result is verbose. With some practice though, memory management needn't be hard - if memory management is hard that hints lack of organization. Smaller, script-like programs where there is no place for large-scale organization, are a different story (especially in C and C-like C++) and GC'ed languaged…

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

I think it depends a lot on experience and wether the code base is post C++ 11. Modern codebases like clang or chrome do not seem to have any more memory management issues than something like Intellij. Personally I wrote system software in C++ for 10 years and memory management was a problem maybe once or twice.

Re: Writing New System Software

#66

Post by gspr »

flohofwoe wrote: post #60

The 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.

Strange language choices for a Rust propagandist's GitHub repositories: https://github.com/borud?tab=repositories

Re: Writing New System Software

#67

Post by pjmlp »

fivea wrote: post #36
stevekemp wrote: post #9

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…

I guess we can consider AOSP legacy code then, given how they use C++.

Re: Writing New System Software

#68

Post by pjmlp »

jeffreygoesto wrote: post #50
jstimpfle wrote: post #45

Earlier quoted context omitted.

Are there any usable linters around to enforce such rules?

Static Analysers like Coverity, KlocWork, QA-C++ will do. Usability is... Well... Subjective.

More than the usability, the biggest problem is getting everyone onboard.

Re: Writing New System Software

#69

Post by choeger »

c0l0 wrote: 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…

I 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.

Re: Writing New System Software

#70

Post by ithkuil »

berkut wrote: post #52
mikewarot wrote: post #16

There 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 worr…

Quite 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.

Computing 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.
Post reply on HN