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

471–480 of 517 posts

Re: There is no memory safety without thread safety

#471

Post by [deleted] »

ralfj wrote: post #390
kiitos wrote: post #194

> To see what I mean by this, consider this program written in Go, which according to Wikipedia is memory-safe: The Wikipedia definition of memory safety is not the Go definition of memory safety, and in Go programs it is the Go definition of memory safety that matters. The program in the article is obviously racy according to the Go language spec and memory model. So this is all very much tilting at windmills.

Can you point me to the Go definition of memory safety? I searched all over their website, and couldn't find any. (But also, it'd be kind of silly for every language to make up their own definition of memory safety. Then even C is memory safe, they just have to define it the right way. ;)

[deleted]

Re: There is no memory safety without thread safety

#472

Post by tialaramex »

ameliaquining wrote: post #43
tialaramex wrote: post #37

Earlier quoted context omitted.

I can buy that claim for the .NET CLR but I've never seen it nailed down properly the way Java did which gives me pause. I worry about the Win95-era "Microsoft Pragmatism" at work and a concrete example which comes to mind is nullability. In the nice modern software I often work on I can say some function takes a string and in that program C# will tell me that's not allowed to be null, it has to be an actual string -…

There's a documented memory model ( https://github.com/dotnet/runtime/blob/main/docs/design/spec... ), does that not address this concern?

So, the answer is that I've read that and I wasn't as reassured as I'd like. ECMA definitely isn't enough as it acknowledges. The platforms which exist today are fine. And future platforms? Well we're told it will be difficult to change these assumptions. Yeah, it would be difficult.

For a comparison, the x86 has what that document calls TSO, a very strict "free" ordering (in fact you pay all the time, but, you can't opt out so in that sense it's free to get this ordering on Intel) so 1990s C++ written for Windows just assumes volatile means you get memory ordering -- even though that's not what that means. If you compile brand new code for x86 on Microsoft's compilers today you get the exact same promise, but if you target their ARM platforms you don't get that because it would be expensive so, too bad.

Re: There is no memory safety without thread safety

#473

Post by astrange »

singpolyma3 wrote: post #351
astrange wrote: post #290

Earlier quoted context omitted.

This is harder than it looks as soon as you start counting abandoned memory (stuff that's still referenced but not actually used.)

Well if it's still referenced it's still used from my PoV

If it's never read again then it's not used.

Re: There is no memory safety without thread safety

#474

Post by jchw »

zozbot234 wrote: post #465
jchw wrote: post #463

Earlier quoted context omitted.

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.

In that case, when we're just talking about money, it's pretty easy to reason about this then, no? You can literally determine how much risk you're willing to take on by estimating what you might have to lose from such a bug and how much it might cost you versus how often they are likely to happen. The answer for how often is "not very often", and depending on the nature of the bug the monetary cost of it may be "pretty much $0" in the easy cases. Let's be conservative and say that you might see a moderate severity Go concurrency bug every 10,000 lines of Go code or so. That's still really not much. It means that a moderate sized 50,000 line code program might see like five of said kinds of bugs, and they might wind up being benign. Computers and networks are unreliable. Dropping some requests occasionally or having a weird bug for a small fraction of requests or database records is usually not going to cause you serious financial distress as a business.

When working on Go services it is nearly the last thing I am concerned about.

Re: There is no memory safety without thread safety

#475

Post by tsimionescu »

to11mtm wrote: post #435
elcritch wrote: post #313

Earlier quoted context omitted.

Segfault sounds better than running with inconsistent data.

Well it depends on what we mean by 'inconsistent'. In C# For example, if a structure is over CPU arch Word size (i.e. 32 or 64 bits) then you could have a torn read if it's being written. However object refs themselves are always word size so you'll never have a torn pointer read on those. However, in either case there is still a need in multithreaded environments to remember the CPU's memory ordering rules and put p…

When I said "inconsistent", I was referring to things like getting a length field updated by one thread, but the actual list contents by another - if you have thread safety violations you will end up with exactly this type of issue in any language that allows unsafe threading code (Rust wouldn't outside `unsafe` blocks, for example), even in fully memory safe ones like Java or C#, and even without any bugs in the VM.

Re: There is no memory safety without thread safety

#476

Post by zozbot234 »

jchw wrote: post #474
zozbot234 wrote: post #465

Earlier quoted context omitted.

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.

In that case, when we're just talking about money, it's pretty easy to reason about this then, no? You can literally determine how much risk you're willing to take on by estimating what you might have to lose from such a bug and how much it might cost you versus how often they are likely to happen. The answer for how often is "not very often", and depending on the nature of the bug the monetary cost of it may be "pre…

> Computers and networks are unreliable. Dropping some requests occasionally or having a weird bug for a small fraction of requests

This seems to come with the obvious implication that Golang should only ever be used to implement "services" that are essentially a part of the network infrastructure, passing requests along to other parts of the backend but not implementing any "logic" themselves (since that's where the correctness issues we're discussing might have severe consequences for the business). Isn't this a rather sobering take, all things considered?

Re: There is no memory safety without thread safety

#477

Post by amluto »

comex wrote: post #181
amluto wrote: post #99

Earlier quoted context omitted.

> when was the last time you heard of a modern application backend being exploited through memory corruption, in any language? It happens all the time, but it’s a bit hard to find because “modern application backend[s]” are usually written in Go or Python or Rust. Even so, you’ll find plenty of exploits based on getting a C or C++ library on the backend to parse a malformed file.

Are these exploits publicly documented?

Some exploit authors love writing up their work. For example:

https://googleprojectzero.blogspot.com/2016/12/chrome-os-exp...

Re: There is no memory safety without thread safety

#478

Post by jchw »

zozbot234 wrote: post #476
jchw wrote: post #474

Earlier quoted context omitted.

In that case, when we're just talking about money, it's pretty easy to reason about this then, no? You can literally determine how much risk you're willing to take on by estimating what you might have to lose from such a bug and how much it might cost you versus how often they are likely to happen. The answer for how often is "not very often", and depending on the nature of the bug the monetary cost of it may be "pre…

> Computers and networks are unreliable. Dropping some requests occasionally or having a weird bug for a small fraction of requests This seems to come with the obvious implication that Golang should only ever be used to implement "services" that are essentially a part of the network infrastructure, passing requests along to other parts of the backend but not implementing any "logic" themselves (since that's where the…

No, no. It's just that boring glue software is the majority of all software. Seriously, it is. It's what most people here are writing most of the time.

Rust is surely good for when you are doing something vastly more complicated than boring web services, but if you try to write a database or message queue you are not going to pass Jepsen testing because you have a borrow checker present. Some of the most proven software in the world is written in programming languages with worse concurrency control than Go, like sqlite in C.

But, if you wanted to write something with super complex concurrency from scratch, you probably would opt to use Rust, because well, it's just good at that, and it probably is worth the up front and ongoing investment to entirely eliminate some classes of concurrency issues. But in those cases you need much more rigorous testing that will likely help to prevent menial concurrency bugs too, like running torture tests with race detection that try to ensure consistency guarantees hold up in all situations.

So are all Go programs of note just boring glue logic? Also no. I use tons of Go software every day that is a lot more than glue logic. Some examples include ESBuild, SyncThing, rclone, restic, and probably a bunch of other utilities of various shapes and sizes. People write databases and message queues and whatever else in Go too.

Still, yes most software is terribly boring. Most software is doing glue shit and basic CRUD operations and not much more. That doesn't mean that companies that write these kinds of software do nothing interesting, but even if they do, most of the software is going to be really god damned boring, because a lot of what we need to do is not super novel cutting edge stuff, and you don't rewrite a relational database or message queue system every single time you need one, you pick an off the shelf option and go on your way.

Re: There is no memory safety without thread safety

#479

Post by atombender »

dev_l1x_be wrote: post #306
tsimionescu wrote: post #288

Earlier quoted context omitted.

I don't think that's the (only) reason Go became popular. The huge thing about Go is the runtime: it's the only language runtime available today, at least in any language with a large org behind it, that offers (a) GC, (b) fast start-up time, (c) static types, (d) fast execution, and (e) multi-threading. This is a killer combination for any team looking to write code for auto-scalable microservices, to run for exampl…

F# does that too. > .NET has similar problems s/has/had/ https://blog.washi.dev/posts/tinysharp/ The issue is that some people still fighting against the concepts ML family languages (primarily SML) introduced. Go implemented go routines and channels from CSP ( https://en.wikipedia.org/wiki/Communicating_sequential_proce... ) but dragged a lot on influence from C (understandable) into the language. I think Rust opted…

OP's point is about why Go took off, which happened more than a decade ago.

Native AOT compilation didn't exist for .NET then, and .NET was, for all intents and purposes, Windows-only.

(Last I checked, the AOT story for C# is not that great even today. No idea about F#.)

Re: There is no memory safety without thread safety

#480

Post by atombender »

qcnguy wrote: post #318
tsimionescu wrote: post #288

Earlier quoted context omitted.

I don't think that's the (only) reason Go became popular. The huge thing about Go is the runtime: it's the only language runtime available today, at least in any language with a large org behind it, that offers (a) GC, (b) fast start-up time, (c) static types, (d) fast execution, and (e) multi-threading. This is a killer combination for any team looking to write code for auto-scalable microservices, to run for exampl…

Kubernetes services are one of the places where you don't care about startup time. Likewise for Docker itself. These are the things that do the scaling, normally. Go is not particularly fast. People often see that Java gets faster as it runs and thinks, oh, it must be slow at the start then. But when you compare like with like, Go ends up being stuck at the bottom of the curve that Java then sharply climbs. The diffe…

When using HPAs to quickly ramp replica sets up and down based on load, startup time is absolutely an important factor. You want services to start within hundreds of milliseconds at most.
Post reply on HN