Hacker News Reader

Comment by p-e-w | Hacker News Reader

> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages

Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half.

For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice.

And now imagine, in reaction to this revolutionary development, thousands of anesthesiologists publicly said things like "what matters is not the technique but the skill of the physician", "good anesthesiologists don't make mistakes like that in the first place", "but this new technique takes 1%-3% longer than the previous one" or similar.

Utterly unthinkable, isn't it?

Yet in software engineering, this is exactly what has been happening every day for more than a decade.

View on HN

> Utterly unthinkable, isn't it?

No. Ignaz Semmelweis faced it in the 1800s for daring to suggest (what we know know as germs) made people sick and hand washing could drastically reduce medical complications. He was able to prove it too.

By the end was locked up in an asylum for his ‘crimes’.

Want more recent?

How many stories have you heard of instruments or gauze or whatever left in surgical patients? Of operating on the wrong part or person?

People are fallible. But checklists help a ton. We know that for sure. Why is aviation obsessed with following them? Because they work to increase safety.

Surgeons have resisted them. I don’t know the current state of it, but they were making that exact “good surgeons don’t need it” argument. I remember it being a plot point on an episode of a medical drama (ER? Or maybe Grey’s Anatomy).

There are probably tons of other examples in other fields.

Semmelweis is ancient history. He was active at a time when regulations and "best practices" simply weren't a thing anywhere.

Surgeons resisting checklists is new to me. Do you have a reference other than a TV show? My understanding until now was that checklists are extensively used in medicine.

Here are a couple articles to start pulling threads on

> Despite all the evidence, Gawande admits that even he was skeptical that using a checklist in everyday practice would help to save the lives of his patients.

> "I didn't expect it," Gawande says with a chuckle. "It's massively improved the kind of results that I'm getting. When we implemented this checklist in eight other hospitals, I started using it because I didn't want to be a hypocrite. But hey, I'm at Harvard, did I need a checklist? No."

https://www.npr.org/2010/01/05/122226184/atul-gawandes-check...

Not sure if this supports the reluctance idea since it says 93% use checklists, but most surgeons don't think it improves safety.

> Of the 353 survey respondents, 93.6% use SSCs and 62.6% would want one used in their own child’s operation, but only 54.7% felt that checklists improve patient safety.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6221594/

That first quote (as well as the rest of the article) supports the view that people tend to underestimate the usefulness of procedures they are not yet using and especially to overestimate their own abilities. It also shows that social pressure is the opposite of what it was in Semelweiss time, even people who feel they are above such things start using them (and then some of them get convinced that they were wrong).

The part you quoted from your second link directly contradicts your claim that most surgeons don't think it improves safety (even if the 54.7% is among the 93.6% that use it that still gives 51% that think it improves safety).

The usefulness of checklist in medical and the resistance to it is mentioned several times in The Checklist Manifesto.

https://en.wikipedia.org/wiki/The_Checklist_Manifesto

That IS the central issue though, processes, techniques, and so on are not a THING until they are. And something has to change for that to happen.

We have smaller version of that with masks in pandemic. Cheap and easy means to reduce problem by a bit ? Nah, let's not do that /s

Well, not exactly. There have been plenty of advancements in bridge / highrise construction over the past 100 years, but in practice we don't go around tearing down old infrastructure that is still functional because it was built with outdated designs and technologies, even when it could theoretically save lives. Buildings get "grandfathered" into meeting code all of the time.

Software is not terribly different from that. The cost of replacing foundational software is tremendous, much higher than just "adopting a new protocol".

Of course, new software should still take heed of this and try to improve.

This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. New projects written in C are being started every day.

This is the exact equivalent of physicians continuing to use unsafe medical procedures, and what's worse, many of those engineers defend their dangerous practices by claiming there is no real danger in the first place if the programmer is "smart enough".

I'm one of those people who still write in C, and I like the experience. I've had a lot of fun, and haven't been burned by it, although statistically it's likely that I will be at some point.

I've tried a lot of languages in the past, and am currently not willing to dive into a whole new ecosystem, re-learn all the best practices, and unlearn what's worked very well for me with sometimes no good replacement. Best practice for Rust seems to be to avoid linked lists for example. I don't know what's the safe replacement for memset and memcpy to anonymous data structures (void pointers -- generic code) but I have a sense that it is more painful. The general recommendations seem to be to switch to different, more complicated datastructures with more failure modes, or to put boxes and Arcs around things.

I don't think this fits me - I like the feeling of understanding what I'm doing, and once in a while coming up with something that compiles and runs fast and robustly. If you can do that in Rust, good for you.

Another part is that it still seems easier to interface with existing ecosystems in C. I tried writing some Win32 Rust code once in an evening and I have to admit I failed. Maybe I picked the wrong bindings library or whatever. At this point in my life, I have little patience to spend my time like this.

I appreciate the work that is being done, and I feel it's not unlikely that at some point we all will switch. At this point though I feel I'm way more productive staying in my current habitat. And that's not only on me, but also that the ecosystem and developed practices likely are not quite ready for a complete switch.

Comparing the investment to simply washing hands and putting on gloves or following a checklist as a surgeon feels unfair to me.

It's not even about languages. Just using valgrind or sth similar as a part of CI would solve A LOT of issues.

Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise. Luckily you don't have to, there's one in the standard library: https://doc.rust-lang.org/std/collections/struct.LinkedList....

The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.

This isn't an intrusively linked list.

Probably not the Clone trait but the Copy trait.

> The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.

If you type "memcpy" into the documentation search, rustdoc will point you to

* https://doc.rust-lang.org/stable/std/primitive.slice.html#me...

* https://doc.rust-lang.org/stable/std/intrinsics/fn.copy_nono... (Though it should really point to the reexport at https://doc.rust-lang.org/stable/std/ptr/fn.copy_nonoverlapp... )

The latter will also mention

* https://doc.rust-lang.org/stable/std/ptr/fn.copy.html

> Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise

Implementing linked list in any language that is not memory-safe is challenging because of safety issues. Rust just points it out.

My limited experience with Rust was that I need to know exactly what I want to do in the code and compiler is there to make sure I write that intent as actual code, not my assumptions about how the code will work.

I don't feel that I am less in control, just that all of that needs to be put in code and not just go "okay, I know this part don't need a lock coz I will never call it concurrently" and hope for best.

Even writing for embedded (as in no os, tens of kilobytes of RAM microcontrollers) haven't been too bad althought I haven't managed to convince borrow checker to borrow non-contigous block of bits from a register yet... althought that's what unsafe{} is for after all

> Comparing the investment to simply washing hands and putting on gloves or following a checklist as a surgeon feels unfair to me.

The closer one would be "read that 300 pages of how to do stuff safely and apply it". Once you get into good habits it's not a problem but investment is there

> This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages.

> New projects written in C are being started every day.

But it is mostly about existing software, even if its not about replacing existing software. I write C++ code every day. I hate it, and I'd rather not. But I use C++ libraries written by my teammates, and reference implementations in prior C++ work in our past projects, and have a set-up C++ toolchain, and my company even has all sorts of written C++ docs and style guides and linters and macros and ... and ...

Even if we wanted to stop, there's so much extra stuff to consider. I get your point, <<why start a new thing knowing there's a better way?>> and I would want to stop using c++ but most software isn't one-and-done like a surgery. It is a continuous commitment and ongoing operation, it is the tools used, and the knowledge learned, and the libraries built.

> This is the exact equivalent of physicians continuing to use unsafe medical procedures

Plenty of platforms don't support rust. Just because you've improved knee surgery, doesn't mean it works on an elbow... yet. And sometimes you still gotta perform surgery on elbows.

> if the programmer is "smart enough".

Can't defend this, but tbh I've never heard it.

> > if the programmer is "smart enough".

> Can't defend this, but tbh I've never heard it.

Take a look at this comment: https://news.ycombinator.com/item?id=33824934

> Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them.

It is a somewhat common attitude in this type of thread.

> It is a somewhat common attitude in this type of thread.

Except the safety features are often a lot easier to use than the original C isms that tend to cause the most issues. So it is less an issue of smart and more one of bad habits. C strings instead of std::string, plain arrays instead of std::vector, implicit ownership instead of smart pointers, ... .

The stats come from Google project(s) - you can be sure that they've used the best practices. If they've failed, rest assured that 90%+ of the rest of the devs will fail, and much worse.

> he stats come from Google project(s) - you can be sure that they've used the best practices

The first Google Style Guide for C++ I ever came across in the wild espoused C with classes, had "standard" in scare quotes and banned most of boost for encouraging functional programming. I almost threw a fit when someone unironically tried to push that POS at work because "Google", it was entirely nonsensical especially given that we made heavy use of boost and math libraries with operator overloading.

> someone unironically tried to push that POS at work because "Google"

Especially since Google has a ton of automated tools to perform tests and analysis on code, and enforces certain behavior before you can merge your code in. Something that is probably missing from a smaller organization that’s simply adopting their style guide. Also probably missing is googles alternative stdlib they use.

And yet, you can happily have a UAF through a string_view.

This is not about C++ developers using old school C approaches. The language is fundamentally dangerous. There were huge efforts within Chrome to get all memory managed by smart pointers even more powerful than those offered by the standard, and they still have UAFs all the time.

> take a look at this comment

It’s hacker news. People say all sorts of inflammatory crap here. I discount anything said here, especially in response to an article about said topic.

If my c++ writing coworker shared that opinion with me, or someone at a conference, that’s be different.

> Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them

I will admit I vaguely agree with this. My company has all sorts of tools that perform basic checks for memory safety and a style guide that is very opinionated. Just because we can’t switch easily doesn’t mean we can’t try to improve as an org.

I don’t avow the belief that any program is truly smart enough/too dumb to make bugs, but I do think the organization maintaining the code has a responsibility to improve. Especially a large organization. Whether that’s better code review processes, automated tooling, or even soft-banning the use of certain unsafe practices.

>> This is the exact equivalent of physicians continuing to use unsafe medical procedures

> Plenty of platforms don't support rust. Just because you've improved knee surgery, doesn't mean it works on an elbow... yet. And sometimes you still gotta perform surgery on elbows.

That's a non-argument, obviously if it isn't even applicable it's not a discussion. Also most of what people code on does support Rust

>> if the programmer is "smart enough".

>Can't defend this, but tbh I've never heard it.

Programmer is never smart enough. Decades of bugs showed that

> There are plenty of engineers that argue for continuing to use memory-unsafe programming languages

And why do you think it's wrong, per se?

> This is the exact equivalent of physicians continuing to use unsafe medical procedures

You mean with different safety tradeoffs?

Because what you propose is exactly like forcing very expert physicians to switch to a procedure they are novice of and that it's not been battle tested like the old one, that proved to be very effective in most cases.

It's the same reason why patients prefer to be treated with established procedures and to undergo experimental treatments they need to sign a document that proves their informed consent.

I mean if you want to use that comparison, C/C++ bridge would have random holes dropping the cars off the cliff below.

The issue is not "bridge is suboptimally designed" or "bridge will need some extra maintenance because something started to break".

The memory safety issues are "some cars randomly explode when passing that bridge" or "when driver breaks 6 seconds after entering the bridge, every other driver dies.

> Software is not terribly different from that.

It is MASSIVELY different, especially anywhere near anything security-related. Most buildings don't have a group of people with hammers trying to find a weak point that will never happen in any actual use conditions and then hit that weakpoint in every similar building built in every place of the world.

Please don't make horribly useless comparisons like that

> we don't go around tearing down old infrastructure

All the time! And the stuff we don't tear down, we retrofit.

> Yet in software engineering, this is exactly what has been happening every day for more than a decade.

Not really. Rust is the first major attempt to achieve c/c++ performance & capability while also being safe.

Prior to that nearly every memory safe language came with crippling tradeoffs, and that is why people rejected them. Especially as performance and efficiency took center stage again with the massive increase in battery powered devices & the general plateau of single core CPU performance over the last decade

More than a decade? It started back in the 1970's when Pascal and C were duking it out. Early programmers were mathematicians and they took their craft seriously, including safety. They designed Algol which Pascal and C came from but Pascal had the safety and C didn't. C won the battle because programmers felt saving a few CPU cycles was more important than safety. Unfortunately, Pascal had a few other issues that kept it from beating C. Wirth later came out with Modula-2 in the late 1970's, which was vastly superior to C, but it was too late to compete with C's popularity. We've been hamstrung by C and its derivatives ever since. The importance of safety became much more apparent when networking became popular but there was no turning back at that point. Now, finally, 50 years later, Rust is pulling us back toward safety in a C-syntax language.

> Utterly unthinkable, isn't it?

> Yet in software engineering, this is exactly what has been happening every day for more than a decade.

Consider what happened to poor Semmelweis when he discovered in the middle of the 19th century that hand-washing improved medical outcomes: doctors of the time were too proud to accept his results and drove him out of the profession (and to his early grave) rather than change their practices.

All these people who insist on continuing to write new C programs have the same mentality as those doctors who refused to wash their hands.

Woah.

A bit much, eh? I write programs in whatever I want as an hobby. Why does that make me a murderer? Everyone needs to chill about this.

That seems to be a very limited view on the issue, since the stakes with ansthesia related issues are much higher (a human life).

Every human life is directly or indirectly impacted by software. Software controls transport, food and energy production, and all human communication. If all software suddenly stopped working, society would collapse instantly and hundreds of millions of people would die within a year.

The attitude "it's just computers, nothing truly important like medicine" might have been viable 40 years ago, but it certainly isn't anymore.

It's not like you make a bad git commit and suddenly the world stops working. There are checks and processes and redundancies that reduce the impact of human error dramatically.

The earth is still spinning, despite so many things not working everywhere. That's not just in software. In every system, there's relatively few single points of failure. As you zoom out, failure points disappear and new ones appear.

Sure, still sometimes someone notices a critical security flaw that's been in there for a while, and that had found its way into large parts of the infrastructure already. (The last one I heard of was not a memory vulnerability).

>It's not like you make a bad git commit and suddenly the world stops working.

https://qz.com/646467/how-one-programmer-broke-the-internet-...

Sure, I know this. I don't think this contradicts my argument. It didn't suddenly make running infrastructure exposed. But yeah, people needed to find a replacement to continue development (which I hope wasn't hard)?

If this breakage is an argument for anything, it is against depending on lots of code that you don't even know. The last Rust projects I tried to build all had on the order of 500 transitive dependencies, by the way.

I assume you're not familiar with https://en.wikipedia.org/wiki/Therac-25 ?

Reply on news.ycombinator.com