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

There is no memory safety without thread safety

ralfj.de

Post reply on HN
Print view View original

461–470 of 517 posts

Re: There is no memory safety without thread safety

#461

Post by uecker »

ralfj wrote: post #448
uecker wrote: post #291

Earlier quoted context omitted.

The point is that a segfault is not an indication for memory unsafety. It is the opposite: The OS stops some unsafe access. The problem with C implementations is that it often comes to late and the segfault does not stop a prior unsafe read or write. But this is also an implementation property, you can implement C in a memory safe way as many have shown. Rust has, unfortunately, changed the narrative so that people n…

(EDIT: removed the first part since I realized you were replying to some comment further up, not my example.) > Rust has, unfortunately, changed the narrative so that people now believe memory safety is a property of the language, when it is one of the implementation. I am not sure I agree with that (the concept of memory-safe languages looong predates Rust), but you can just define a memory-safe language as one wher…

I am not really saying the term is not useful, the idea that it is the only legitimate way of memory safety is what I am questioning.

Re: There is no memory safety without thread safety

#462

Post by cesarb »

gowld wrote: post #430
zbentley wrote: post #227

Earlier quoted context omitted.

> a segfault is completely unintentional Usually, but not always! https://jcdav.is/2015/10/06/SIGSEGV-as-control-flow/

> Faulted trying to access 0x10 - the offset in the string we were trying to read from :) Is guaranteed that every offset you can try to read is guaranteed to create a segfault?

> Is guaranteed that every offset you can try to read is guaranteed to create a segfault?

The offset is fixed as part of the compiled code; the JVM can enforce that it's less than 4k (otherwise it can use an explicit NULL check), and that the first 4k page is always unmapped.

Re: There is no memory safety without thread safety

#463

Post by jchw »

zozbot234 wrote: post #456
jchw wrote: post #454

Earlier quoted context omitted.

Look, this is pointless. I'm not learning anything new when you tell me that it can and will happen. How will it happen and how much will it happen? Hence linking to Uber's case study on the issue. The answer? Not that much. Uber started performing race detection in production over a 6 month period and found 2,000 different race conditions. Ouch, that sounds horrible! But wait, we're talking about 50 million lines of…

Identifiable "wonky" behavior and periodic crashes seem like a very real issue to me. This wouldn't fly for any mission-critical service, it's something that demands a root cause analysis. Especially since it's hard to be sure after the fact that no data has been corrupted somehow or that security invariants have not been violated due to the "wonky" behavior.

I am saying in no uncertain terms that most people here, and by most I am not talking simple majority stuff, have literally not once worked on software that is mission critical by any meaningful definition of "mission critical". Even Rust is questionable on truly mission critical software, since it does not actually prevent all runtime crashes and certainly not all correctness issues; you'd have to go further, towards something like Ada/SPARK for that. I kind of wish I could get into Ada/SPARK, too, to be honest, but it's a pretty big rabbithole it seems.

Re: There is no memory safety without thread safety

#464

Post by Ar-Curunir »

Mawr wrote: post #91
zozbot234 wrote: post #44

Earlier quoted context omitted.

> And frankly, a lot of software I write is just boring, and Go does fine for a lot of that. I try Rust periodically for things, and romantically it feels like it's the closest language to "the future", but I think the future might still have a place for languages like Go. It's not so much about being "boring" or not; Rust does just fine at writing boring code once you get familiar with the boilerplate patterns (Real…

> (Real-world experience has shown that Rust is not really at a disadvantage wrt. productivity or iteration speed). I don't believe that for a second. Even just going from Python to Go drops my productivity by maybe about 50%. Rust? Forget it. Sure, if you have a project that demands correctness and high performance that requires tricky concurrency to achieve, something like Rust may make sense. Not for your run-of-t…

I am much more productive with Rust than any other programming language, except maybe python for programs shorter than 100 lines. Does that mean every other language has terrible productivity? No, it just means that I am more experienced with Rust. In general, experienced rust devs tend to be as efficient with Rust as other devs with other languages. There’s even Google data corroborating that internally Rust teams are as productive as Go teams

Re: There is no memory safety without thread safety

#465

Post by zozbot234 »

jchw wrote: post #463
zozbot234 wrote: post #456

Earlier quoted context omitted.

Identifiable "wonky" behavior and periodic crashes seem like a very real issue to me. This wouldn't fly for any mission-critical service, it's something that demands a root cause analysis. Especially since it's hard to be sure after the fact that no data has been corrupted somehow or that security invariants have not been violated due to the "wonky" behavior.

I am saying in no uncertain terms that most people here, and by most I am not talking simple majority stuff, have literally not once worked on software that is mission critical by any meaningful definition of "mission critical". Even Rust is questionable on truly mission critical software, since it does not actually prevent all runtime crashes and certainly not all correctness issues; you'd have to go further, toward…

A meaningful definition of "mission critical" is just "serious money can be lost if this software crashes or misbehaves in problematic ways". That would seem to cover a whole lot of software that is not written in Ada/SPARK or anything comparable. I'm not talking about the "safety critical" kind where actual human lives may be at stake, only about the well known run-of-the-mill stuff.

Re: There is no memory safety without thread safety

#466

Post by pclmulqdq »

ioasuncvinvaer wrote: post #458
pclmulqdq wrote: post #420

Earlier quoted context omitted.

Excuse me, but in this thread we are bashing go, not making logical arguments.

What is the argument?

That Dropbox is very happy with unsafe languages despite the top-level comment.

Re: There is no memory safety without thread safety

#467

Post by tptacek »

zozbot234 wrote: post #459
tptacek wrote: post #457

Earlier quoted context omitted.

I quoted directly from the article.

To use your definition, that quote is clearly making a point about correctness, not necessarily about real-world security.

As long as we agree that there isn't a meaningful security implication, we don't need to keep litigating.

Re: There is no memory safety without thread safety

#468

Post by camgunz »

bobbylarrybobby wrote: post #429
camgunz wrote: post #419

Earlier quoted context omitted.

The "go" keyword is that demarcation

“go” being a necessary keyword even for benign operations makes its use an unsafety marker pointless; you end up needing to audit your entire codebase anyway. The whole point of demarcation is that you have a small surface area to go over with a fine-toothed comb.

You're free to structure code in and around goroutines however you like. No one's forcing you to spray this all over your codebase. Feel free to implement work queues, or the actor pattern, or whatever. No one's forcing you to use whatever frameworks or libraries or patterns; that's all you.

So much of all of this is weirdly entitled. Languages that do things differently exist: Erlang, Pony, Rust. They all make wildly different tradeoffs than Go does, not better, not worse, different. If you think they're better, use 'em. Let your better software win in the market. These weirdo polemics just fan language flamewars.

Re: There is no memory safety without thread safety

#469

Post by pclmulqdq »

dev_l1x_be wrote: post #304
tptacek wrote: post #168

Earlier quoted context omitted.

Right, the issue here is that the "Rust and Java sense" of memory safety is not the actual meaning of the term. People talk as if "memory safety" was a PLT axiom. It's not; it's a software security term of art. This is just two groups of people talking past each other. It's not as if Go programmers are unaware of the distinction you're talking about. It's literally the premise of the language; it's the basis for "sha…

> But: everybody understands that. I had to convince Go people that you can segfault with Go. Or you mean the language designers with using everybody?

You can segfault in Rust, too - there's a whole subset of the language marked "unsafe" that people ignore when making "safe language" arguments. The question is how difficult is it to have a segfault, and in Go it's honestly pretty hard. It's arguably harder in Rust but it's not impossible.

Re: There is no memory safety without thread safety

#470

Post by aystatic »

pclmulqdq wrote: post #415
zozbot234 wrote: post #345

Earlier quoted context omitted.

> ... it's understood that perhaps the language is vulnerable to certain errors and one should attempt to mitigate them. But more importantly, those errors are one class of bug and bugs can happen. Set up infra to detect and recover. > in Rust the code must be safe, must be written in a certain way, must be proven correct to the largest extent possible at compile time. Only for the Safe Rust subset. Rust has the 'uns…

A not-so-secret secret of Rust is that liberal use of 'unsafe' is pretty much required for certain classes of high-performance code.

imo if you're sprinkling around `unsafe` in your codebase "liberally", you're holding it wrong. In general it's really not that hard to encapsulate most unsafety into a wide-contract abstraction; I’d argue where Rust really shines is when you take advantage of the type system and static analyzer to automatically uphold invariants for you
Post reply on HN