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

101–110 of 158 posts

Re: Writing New System Software

#101

Post by pjmlp »

PaulDavisThe1st wrote: post #90
jillesvangurp wrote: post #71

Earlier quoted context omitted.

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…

> Apple created Swift to get rid of object C. But even Apple still notes that you should not write audio processing code in Swift, and if you use Objective C for this purpose, to avoid the Objective parts of it.

If I recall correctly from WWDC sessions, they note to prefer value types and avoid any kind of allocations, while the samples where shown in Swift.

Re: Writing New System Software

#102

Post by pjmlp »

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

Earlier quoted context omitted.

This feels like Stockholm syndrome to me. 1. I’m amazed that you call Java ugly and verbose but recommend C++. Apart from files not needing to be classes in C++, they feel similarly verbose to me with C++ slightly winning on ugliness. 2. I basically don’t believe that memory management is not hard. The reason is that plenty of programs written in ‘modern’ or ‘safe’ C++ in the style you recommend continue to have plen…

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

Also known as MFC, PowerPlant, Turbo Vision, CSet++, Taligent, OWL, ATL, Symbian, Motif++,... all on average 5 years old when Java came into the world.

Re: Writing New System Software

#103

Post by pjmlp »

FpUser wrote: post #80
dan-robertson wrote: post #58

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.

Grep AOSP source code then.

Re: Writing New System Software

#104

Post by c0l0 »

gravypod wrote: post #92
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…

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

I guess one can work around the lack of dynamic linking in a language like Go on the package manager and/or distro level (though some established distros and package management ecosystems, which I very much hope will not go away, will have it harder to adapt than others), but I really would like to make everyone think about whether we should...

Imagine a Debian archive (that is, a few tens of thousands of packages with source, build recipies and binaries for multiple architectures available) with only static linking on the table. You got a few hundreds to thousands of those packages installed on typical, real-world Debian machines. Then, a central component like zlib or OpenSSL gets an important patch. This triggers hundreds, if not tens of thousands (transitive library .so dependencies are a thing after all, and you want to have all your supported arches covered) of rebuilds across the archive. All users will have to re-download and re-install all resulting upgraded packages they have installed.

With increased sharing of source code (i.e., when following "don't build your own crypto!" and other generally useful mantras by re-using existing codebases) and only static linking on the table, this kind of problems gets really, really bad really quickly for large-ish software archives. Kinda like with log4j in the Java ecosystem, where each app is used and event expected to dragging all its runtime dependencies along on its own.

In the dylib world we are living in right now however, users get a single updated package, and upon the next restart of an application linking against it, they're immunized against the bug. The reduction of churn is nigh-unfathomably massive.

If your systems generally only run a single application, and there's a dedicated ops team at the top (or bottom - it's a matter of perspective, I guess :)) of a monorepo world with each dependency fully vendored in, and an "intelligent" build and deployment system atop it all that will take care of gracefully upgrading everything everywhere upon such routine patching, I can see how statically linking everything reduces the amount of potential pain points upon deploying stuff. For the significant portion that makes up the rest of the world, they generally don't have such luxuries, and will be a lot worse off. Especially established and wonderful Free Software communities like Debian or Fedora. I think that would be a huge sacrifice to make.

Re: Writing New System Software

#105

Post by fivea »

gravypod wrote: post #93
fivea wrote: post #36

Earlier quoted context omitted.

> (...) 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 i…

> Basically, non-local control flow is dangerous (...)

This is the crux of the error you're making. Exceptions are not about control flow. Exceptions are a transparent and clean way to handle exceptional events. Exceptions are not intended to, say, handle the status code of a HTTP requests. Exceptions are intended to handle exceptional and potentially unrecoverable errors in a safe and controlled manner, such as failing to allocate memory, regardless of where and how they pop up.

Therefore, suggesting classical C-style return codes or specialized monadic types to handle results as alternatives to exceptions completely misses the whole point of exceptions and, more importantly, all the classes of problems they are designed to eliminate.

Re: Writing New System Software

#106

Post by FpUser »

pjmlp wrote: post #103
FpUser wrote: post #80

Earlier quoted context omitted.

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.

Grep AOSP source code then.

WTF is AOSP and why would I grep it?

Re: Writing New System Software

#107

Post by user10874967111 »

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

Re: Writing New System Software

#108

Post by FpUser »

dan-robertson wrote: post #96
FpUser wrote: post #80

Earlier quoted context omitted.

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 o…

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

Emplace constructs copy of object in the container. You should be fine.

Re: Writing New System Software

#109

Post by FpUser »

naasking wrote: post #85
mem0r1 wrote: post #6

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

> Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer You seem to be implying that's a good thing. It's literally not. Imagine if I created a programming language where every random string of characters was a valid program (cue the Perl jokes). Clearly this language permits even more freedom than C++, but this would be a nightma…

>"You seem to be implying that's a good thing. It's literally not."

I think it is.

Re: Writing New System Software

#110

Post by jstimpfle »

dan-robertson wrote: post #72
zarkov99 wrote: post #65

Earlier quoted context omitted.

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.

> chrome See https://www.cvedetails.com/vulnerability-list/vendor_id-1224... for a list of RCE vulnerabilities. I see a bunch of memory management problems there. Also note that chrome is likely much better tested than some other C++ project, and lots of tools are used to search for potential vulnerabilities or invalid memory use as well as fuzzing and crash reports from a large install base. I don’t know how this co…

Never contain programs so few bugs, as when no debugging tools are available - Niklaus Wirth

Fuzzers and testing can detect bugs but I don't see how they can make a contribution to a reasonable software structure (I believe that bad structure is the prime cause of bugs).

Post reply on HN