8 ms·

As a hobbyist with only limited C++ and Rust experience, reading things like the abstract of this paper push me towards Rust a bit. The snark is really offputt

As a hobbyist with only limited C++ and Rust experience, reading things like the abstract of this paper push me towards Rust a bit. The snark is really offputting. As a user of software trying to protect my personal information in an increasingly threatening world, I would like memory safety in more places. From the outside looking in it feels like there are a lot of C and C++ programmers trying to deflect from how poorly their attempts at memory safety have gone and just snarking at the people trying to fix it. I will say that the point about FFI boundaries needing more care is a valid one I had not considered. Is there a name for people who don't work in C++ and never, ever hear "rewrite it in Rust" except from programmers who seem like they're a bit hurt that their language has a competitor?

lesuorac 3y ago
The other part I find amusing is that the issues found in the paper is that not enough was rewritten into Rust!! The first F in FFI [1] means that you have an interaction of non-Rust and Rust. (Or two non-Rust languages but that's moot). [1]: https://en.wikipedia.org/wiki/Foreign_function_interface https://en.wikipedia.org/wiki/Foreign_function_interface
- cogman10 3y ago
  Yeah, it's a bit like saying "See, Java isn't memory safe! Look what happens when we expose native methods and calls between the JVM and C!" FFI is inherently unsafe regardless of language.
JohnFen 3y ago
> their language has a competitor? I take issue with the notion that languages can have competitors. Languages are tools, and some languages are more suited to some tasks than others, but each has their place. Saying languages compete with each other is a bit like saying different kinds of hammers compete with each other. They don't, each is just optimized for a different kind of hammering.
- nindalf 3y ago
  Thinking of languages as hammers or screwdrivers is too simplistic. Instead, think of languages as platforms. Your productivity in any language is directly proportional to your time and effort investment in it. It's in your best interests to pick the language that's likely to thrive and spend time learning its ins and outs. On the flip side, betting on a horse that doesn't win could mean the loss of months or years of effort. This is why people evangelize the platforms they're invested in - convincing other people to join improves the health of the platform, increasing their return on investment. More adoption => more libraries => more projects => more jobs => more adoption. A virtuous cycle. This evangelizing can sometimes become contentious if others perceive it as an attack on their platform. People defend their language mostly because they don't want to see it lose popularity. If it did, their language's viability is threatened and their investment is in jeopardy. It's also partly because they've spent so working with this language that it's become a part of their identity. A critique of the tool is perceived as an attack on the person.
  - JohnFen 3y ago
    I suppose my views are skewed because I have become competent or better in a large number of languages. I have my favorite general-purpose language, of course (it's C++-as-a-better-C), but I view choosing a language for a particular project to be an engineering decision that I make according to the demands of the project, not based on what language I personally enjoy the most. Developers do get emotionally invested in their tools, and I've seen an uncountable number of holy wars because of that. But all of them strike me as being ludicrous. If another dev uses a language I would not have chosen, that's not a personal affront to me. I assume they made an engineering decision that made sense for their situation. It's all good. > If it did, their language's viability is threatened and their investment is in jeopardy. I sorta see this, but in my experience, it's very easy to overstate this case. If a language is viable enough to develop in initially, it's viable. How popular it is or becomes isn't really that important except in terms of being a business decision ("is it possible to hire people in the future who know this language?")
- FrustratedMonky 3y ago
  This isn't true, there are different hammer manufacturers, and they market their products to steal market share from each other. There is a history of languages as locked in walled gardens with real competition. Java v .NET ring any bells?
__s 3y ago
There isn't a name for you, but what you're experiencing is strawman attacks Like the strawman argument where it creates a flawed argument to declare victory over, the strawman attack picks out the most extreme case to declare victory over You'll see this done on left/right political debates where instead of recognizing that most people can find agreeable common ground on 80% of issues, extreme advocates will pick out the opposing extreme advocates to vilify each others' groups I think a lot of Rust programmers appreciate where C is the right tool, & a lot of C programmers can admit that memory errors are a pain in the ass
- carlmr 3y ago
  >I think a lot of Rust programmers appreciate where C is the right tool, & a lot of C programmers can admit that memory errors are a pain in the ass That's true, however IME C++ programmers are the most in denial. And yes, RAII has helped a lot. But still we see way too many memory errors coming from C++ code bases.
- avgcorrection 3y ago
  Arguing isn’t a game of diplomacy and middle grounds.
- uecker 3y ago
  A a C programmer, I think Rust got memory correctness right. Unfortunately, I do not like the rest of the language ;-(
prpl 3y ago
it’s important to note that memory safety is only one kind of bug. Plenty of go and java programs are memory safe with a litany of bugs - and are probably directly protecting an order or two magnitude more of your personal data than Rust and C++ - even without discussing relatively safe languages (interpreted but with various implementations) like Python, PHP, and Ruby.
- nordsieck 3y ago
  > it’s important to note that memory safety is only one kind of bug. Plenty of go and java programs are memory safe with a litany of bugs While that's true, memory safety bugs are particularly dangerous from a security perspective.
- kimixa 3y ago
  In my experience a memory error is often the result of a logic bug - that is the "first failure" of an existing issue in C++ is a memory error, but the originating logic error still exists and would just cause a different issue under "memory safe" languages. It would still be a bug, and may cause security issues. IMHO the big advantage here is not languages that are memory safe, so much as catch many of those misunderstandings at compile time, or runtime in a better way than "Crash" or worse - silent corruption (Much of this is available for c++ in static analysis and sanitizers and other runtime checks, but them being non-default options seems to make them oddly ignored). I feel them being non-default also means there isn't the same focus on performance - and it's an everything-debug-and-slow-as-hell with a UX purely designed around the dev debugging their own code, or no-checking-at-all-no-brakes rather than in between. The classic "memory errors" that are purely local and just not checking the bounds of an array or similar have been pretty much eliminated if you actually use the features (containers, iterators etc.) of the c++ standard library.
  - Verdex 3y ago
    The problem with memory unsafe languages isn't that they can crash. It's that they won't crash. And instead allow an attacker to load up malicious code into the application.
pkulak 3y ago
"Rewrite it in Rust" is another class of "I use Arch, BTW"; one of those phrases no one has ever actually heard unironically, and that is only used to attack the strawman who supposedly said it.
- hxugufjfjf 3y ago
  Sorry to disappoint, but try searching for that on Github and see the amount of projects where this has been unironically suggested.
marcosdumay 3y ago
Not long ago surgeons didn't have a rule of washing their hands before doing an intrusive surgery, and lots and lots of people died because of that. At a point, one surgeon discovered that, with incontestable proof, and started advocating for hand-washing. When almost all surgeons noticed that something so simple and easy had that much impact, they immediately adopted it and saved a lot of suffering from their patients... Ok, of course they didn't. Almost everybody fought the few wand-washing advocates, tried to shame and discredit them, tried to generate bullshit evidence saying that it didn't help, tried to convince everybody that it didn't matter, all the time denying to themselves that it worked. Surgeons only started washing unanimously their hands when that generation of them retired.
- akprasad 3y ago
  https://en.wikipedia.org/wiki/Ignaz_Semmelweis https://en.wikipedia.org/wiki/Ignaz_Semmelweis > Despite various publications of results where hand-washing reduced mortality to below 2%, Semmelweis's observations conflicted with the established scientific and medical opinions of the time and his ideas were rejected by the medical community. He could offer no theoretical explanation for his findings of reduced mortality due to hand-washing, and some doctors were offended at the suggestion that they should wash their hands and mocked him for it. In 1865, the increasingly outspoken Semmelweis allegedly suffered a nervous breakdown and was committed to an asylum by his colleagues. [...] His findings earned widespread acceptance only years after his death, when Louis Pasteur confirmed the germ theory, giving Semmelweis' observations a theoretical explanation, and Joseph Lister, acting on Pasteur's research, practised and operated using hygienic methods, with great success.
- fasterik 3y ago
  This analogy seems pretty disingenuous. Static memory safety isn't an unambiguous good like handwashing; it has tradeoffs. There are many projects where control over memory is critically important and using a language like Rust is a non-starter. Also, the implication that developers who don't switch to Rust are negligently harming people is unnecessarily moralistic and divisive.
  - 3y ago
vpastore 3y ago
it look like you can use this. https://www.youtube.com/watch?v=cWSh4ZxAr7E&t=1578s https://www.youtube.com/watch?v=cWSh4ZxAr7E&t=1578s This talk is what convinced me to move to Rust definitely. The audience is the perfect representation of the C++ community.
lohnjemon 3y ago
How does memory safety allow you to protect your personal information? How many binary exploits have actually lead to the exposing your personal information? I can count with my fingertips exactly zero times that has happened to me. The times my personal information was compromised happened to me is when I downloaded malicious software. Malicious software doesn't care whether your process has "memory safety", it'll extract anything from the processes memory it wishes. Sure memory safety would at least rule out simple binary exploits, but to be targeted by one is not exactly common. I don't get the narrative of an ever increasingly threatening world. If anything things have only been getting better, at least for the individual users. I remember individuals getting pwned very frequently in the old days. Now, not so much, with DEP, ASLR, and stack canaries. The attacks on businesses have increased, but those attacks are mostly just phishing or otherwise human error related. Attack vectors for actual PI retrieval rarely incorporate some obscure memory bug in a program allowing RCE or remote access. Unless you're a high value target.
- insanitybit 3y ago
  > How many binary exploits have actually lead to the exposing your personal information? It happens with some frequency. WhatsApp was exploited due to a memory safety vulnerability, for example. Chrome 0days for memory unsafe vulns are definitely exploited in the wild. Typically companies have much much larger attack surface, so a technique like phishing is going to be far cheaper to execute. But even still, I've seen a memory safety vulnerability used in an attack against a company. The thing is that most companies' attack surface isn't in C/C++ because... that would suck, so they don't do it. Or if they do they use a specific codebase that's been heavily invested in over decades and they sandbox and isolate the services. So on the one hand, yes, most attacks on companies are not due to memory safety issues but that's in part because of the investments into memory safety. > I remember individuals getting pwned very frequently in the old days. Yep, significant efforts were made to make the internet a safer place. Primarily the sandboxing and disabling of third party plugins in browsers. But this doesn't really matter. Yes, there are other issues like phishing and those are being addressed with other techniques. There are issues like sql injection and those are also being addressed. That doesn't mean that memory safety isn't an issue.

lesuorac 3y ago

The other part I find amusing is that the issues found in the paper is that not enough was rewritten into Rust!! The first F in FFI [1] means that you have an interaction of non-Rust and Rust. (Or two non-Rust languages but that's moot). [1]: https://en.wikipedia.org/wiki/Foreign_function_interface https://en.wikipedia.org/wiki/Foreign_function_interface

cogman10 3y ago
Yeah, it's a bit like saying "See, Java isn't memory safe! Look what happens when we expose native methods and calls between the JVM and C!" FFI is inherently unsafe regardless of language.

JohnFen 3y ago

> their language has a competitor? I take issue with the notion that languages can have competitors. Languages are tools, and some languages are more suited to some tasks than others, but each has their place. Saying languages compete with each other is a bit like saying different kinds of hammers compete with each other. They don't, each is just optimized for a different kind of hammering.

nindalf 3y ago
Thinking of languages as hammers or screwdrivers is too simplistic. Instead, think of languages as platforms. Your productivity in any language is directly proportional to your time and effort investment in it. It's in your best interests to pick the language that's likely to thrive and spend time learning its ins and outs. On the flip side, betting on a horse that doesn't win could mean the loss of months or years of effort. This is why people evangelize the platforms they're invested in - convincing other people to join improves the health of the platform, increasing their return on investment. More adoption => more libraries => more projects => more jobs => more adoption. A virtuous cycle. This evangelizing can sometimes become contentious if others perceive it as an attack on their platform. People defend their language mostly because they don't want to see it lose popularity. If it did, their language's viability is threatened and their investment is in jeopardy. It's also partly because they've spent so working with this language that it's become a part of their identity. A critique of the tool is perceived as an attack on the person.
- JohnFen 3y ago
  I suppose my views are skewed because I have become competent or better in a large number of languages. I have my favorite general-purpose language, of course (it's C++-as-a-better-C), but I view choosing a language for a particular project to be an engineering decision that I make according to the demands of the project, not based on what language I personally enjoy the most. Developers do get emotionally invested in their tools, and I've seen an uncountable number of holy wars because of that. But all of them strike me as being ludicrous. If another dev uses a language I would not have chosen, that's not a personal affront to me. I assume they made an engineering decision that made sense for their situation. It's all good. > If it did, their language's viability is threatened and their investment is in jeopardy. I sorta see this, but in my experience, it's very easy to overstate this case. If a language is viable enough to develop in initially, it's viable. How popular it is or becomes isn't really that important except in terms of being a business decision ("is it possible to hire people in the future who know this language?")
FrustratedMonky 3y ago
This isn't true, there are different hammer manufacturers, and they market their products to steal market share from each other. There is a history of languages as locked in walled gardens with real competition. Java v .NET ring any bells?

__s 3y ago

There isn't a name for you, but what you're experiencing is strawman attacks Like the strawman argument where it creates a flawed argument to declare victory over, the strawman attack picks out the most extreme case to declare victory over You'll see this done on left/right political debates where instead of recognizing that most people can find agreeable common ground on 80% of issues, extreme advocates will pick out the opposing extreme advocates to vilify each others' groups I think a lot of Rust programmers appreciate where C is the right tool, & a lot of C programmers can admit that memory errors are a pain in the ass

carlmr 3y ago
>I think a lot of Rust programmers appreciate where C is the right tool, & a lot of C programmers can admit that memory errors are a pain in the ass That's true, however IME C++ programmers are the most in denial. And yes, RAII has helped a lot. But still we see way too many memory errors coming from C++ code bases.
avgcorrection 3y ago
Arguing isn’t a game of diplomacy and middle grounds.
uecker 3y ago
A a C programmer, I think Rust got memory correctness right. Unfortunately, I do not like the rest of the language ;-(

prpl 3y ago

it’s important to note that memory safety is only one kind of bug. Plenty of go and java programs are memory safe with a litany of bugs - and are probably directly protecting an order or two magnitude more of your personal data than Rust and C++ - even without discussing relatively safe languages (interpreted but with various implementations) like Python, PHP, and Ruby.

nordsieck 3y ago
> it’s important to note that memory safety is only one kind of bug. Plenty of go and java programs are memory safe with a litany of bugs While that's true, memory safety bugs are particularly dangerous from a security perspective.
kimixa 3y ago
In my experience a memory error is often the result of a logic bug - that is the "first failure" of an existing issue in C++ is a memory error, but the originating logic error still exists and would just cause a different issue under "memory safe" languages. It would still be a bug, and may cause security issues. IMHO the big advantage here is not languages that are memory safe, so much as catch many of those misunderstandings at compile time, or runtime in a better way than "Crash" or worse - silent corruption (Much of this is available for c++ in static analysis and sanitizers and other runtime checks, but them being non-default options seems to make them oddly ignored). I feel them being non-default also means there isn't the same focus on performance - and it's an everything-debug-and-slow-as-hell with a UX purely designed around the dev debugging their own code, or no-checking-at-all-no-brakes rather than in between. The classic "memory errors" that are purely local and just not checking the bounds of an array or similar have been pretty much eliminated if you actually use the features (containers, iterators etc.) of the c++ standard library.
- Verdex 3y ago
  The problem with memory unsafe languages isn't that they can crash. It's that they won't crash. And instead allow an attacker to load up malicious code into the application.

pkulak 3y ago

"Rewrite it in Rust" is another class of "I use Arch, BTW"; one of those phrases no one has ever actually heard unironically, and that is only used to attack the strawman who supposedly said it.

hxugufjfjf 3y ago
Sorry to disappoint, but try searching for that on Github and see the amount of projects where this has been unironically suggested.

marcosdumay 3y ago

Not long ago surgeons didn't have a rule of washing their hands before doing an intrusive surgery, and lots and lots of people died because of that. At a point, one surgeon discovered that, with incontestable proof, and started advocating for hand-washing. When almost all surgeons noticed that something so simple and easy had that much impact, they immediately adopted it and saved a lot of suffering from their patients... Ok, of course they didn't. Almost everybody fought the few wand-washing advocates, tried to shame and discredit them, tried to generate bullshit evidence saying that it didn't help, tried to convince everybody that it didn't matter, all the time denying to themselves that it worked. Surgeons only started washing unanimously their hands when that generation of them retired.

akprasad 3y ago
https://en.wikipedia.org/wiki/Ignaz_Semmelweis https://en.wikipedia.org/wiki/Ignaz_Semmelweis > Despite various publications of results where hand-washing reduced mortality to below 2%, Semmelweis's observations conflicted with the established scientific and medical opinions of the time and his ideas were rejected by the medical community. He could offer no theoretical explanation for his findings of reduced mortality due to hand-washing, and some doctors were offended at the suggestion that they should wash their hands and mocked him for it. In 1865, the increasingly outspoken Semmelweis allegedly suffered a nervous breakdown and was committed to an asylum by his colleagues. [...] His findings earned widespread acceptance only years after his death, when Louis Pasteur confirmed the germ theory, giving Semmelweis' observations a theoretical explanation, and Joseph Lister, acting on Pasteur's research, practised and operated using hygienic methods, with great success.
fasterik 3y ago
This analogy seems pretty disingenuous. Static memory safety isn't an unambiguous good like handwashing; it has tradeoffs. There are many projects where control over memory is critically important and using a language like Rust is a non-starter. Also, the implication that developers who don't switch to Rust are negligently harming people is unnecessarily moralistic and divisive.
- 3y ago

vpastore 3y ago

it look like you can use this. https://www.youtube.com/watch?v=cWSh4ZxAr7E&t=1578s https://www.youtube.com/watch?v=cWSh4ZxAr7E&t=1578s This talk is what convinced me to move to Rust definitely. The audience is the perfect representation of the C++ community.

lohnjemon 3y ago

How does memory safety allow you to protect your personal information? How many binary exploits have actually lead to the exposing your personal information? I can count with my fingertips exactly zero times that has happened to me. The times my personal information was compromised happened to me is when I downloaded malicious software. Malicious software doesn't care whether your process has "memory safety", it'll extract anything from the processes memory it wishes. Sure memory safety would at least rule out simple binary exploits, but to be targeted by one is not exactly common. I don't get the narrative of an ever increasingly threatening world. If anything things have only been getting better, at least for the individual users. I remember individuals getting pwned very frequently in the old days. Now, not so much, with DEP, ASLR, and stack canaries. The attacks on businesses have increased, but those attacks are mostly just phishing or otherwise human error related. Attack vectors for actual PI retrieval rarely incorporate some obscure memory bug in a program allowing RCE or remote access. Unless you're a high value target.

insanitybit 3y ago
> How many binary exploits have actually lead to the exposing your personal information? It happens with some frequency. WhatsApp was exploited due to a memory safety vulnerability, for example. Chrome 0days for memory unsafe vulns are definitely exploited in the wild. Typically companies have much much larger attack surface, so a technique like phishing is going to be far cheaper to execute. But even still, I've seen a memory safety vulnerability used in an attack against a company. The thing is that most companies' attack surface isn't in C/C++ because... that would suck, so they don't do it. Or if they do they use a specific codebase that's been heavily invested in over decades and they sandbox and isolate the services. So on the one hand, yes, most attacks on companies are not due to memory safety issues but that's in part because of the investments into memory safety. > I remember individuals getting pwned very frequently in the old days. Yep, significant efforts were made to make the internet a safer place. Primarily the sandboxing and disabling of third party plugins in browsers. But this doesn't really matter. Yes, there are other issues like phishing and those are being addressed with other techniques. There are issues like sql injection and those are also being addressed. That doesn't mean that memory safety isn't an issue.