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

401–410 of 517 posts

Re: There is no memory safety without thread safety

#401

Post by kbolino »

jeffparsons wrote: post #242
devnullbrain wrote: post #189

Earlier quoted context omitted.

Rust checks overflow by default in debug builds

I've often thought that I'd prefer it to check by default in release builds, too, but I understand that comes with a performance penalty that a lot of folks aren't happy with. I assume this implies that common processor architectures (x86_64, aarch64) lack trap-on-overflow variants of their integer arithmetic instructions? If the explanation really is that simple, it's pretty disappointing.

> I assume this implies that common processor architectures (x86_64, aarch64) lack trap-on-overflow variants of their integer arithmetic instructions?

Yes*. But all modern instruction sets have condition flags and conditional instructions, so it's still very much possible to implement the checks robustly in machine code. However, doing so would generally require injecting at least one additional conditional-branch instruction, and in some cases, switching from non-flag-setting instructions to flag-setting instructions (which can be slower).

* = true "trap on overflow" existed in 32-bit x86 but was tricky to use and got removed when going to 64-bit

Re: There is no memory safety without thread safety

#402

Post by pizlonator »

SkiFire13 wrote: post #332
pizlonator wrote: post #263

Earlier quoted context omitted.

> By these definitions, doesn't that mean go is neither memory or thread safe? Yes, with the caveat that you can't treat "memory safe" as a binary condition. The strictest notion of memory safety is what I call GIMSO: "Garbage In, Memory Safety Out". I.e. there does not exist any sequence of bytes you could feed to the compiler that would result in a memory-unsafe outcome at runtime. Java aims for this. Fil-C does to…

In my opinion this is missing a very important different between the two approaches: using `unsafe`/`sun.misc.Unsafe` in Rust/C#/Java is a very deliberate choice which presence can easily be checked syntactically, meanwhile data races in Go are most often unintended and you can't easily check for their _guaranteed_ absence. Otherwise C/C++ are also "GIMSO" with the caveat "don't UB"!

GIMSO is defined as memory safety without caveats. The only way to get it (currently) in C/C++ is to compile with Fil-C.

You have a good point otherwise, but Go is considered memory safe anyway. And it probably makes sense that it is, since the chances of exploitation due to memory safety issues caused by races in Go are infinitesimal. It’s not at all fair to compare to the exploited-all-the-time issues of C/C++ (when you make the mistake of compiling with something other than Fil-C)

Re: There is no memory safety without thread safety

#403

Post by 9rx »

pjmlp wrote: post #280
geodel wrote: post #195

Earlier quoted context omitted.

So failures are some deep valid reasons whereas success is developers don't know any better language.

Many don't, otherwise they would not do stuff like using Python for performance workloads. Lets also not forget Rob Pike famous quote regarding simple minds, as target audience. As for Go, Kubernetes made it unavoidable, it is like UNIX for C, Web for JavaScript, and so forth.

> Many don't, otherwise they would not do stuff like using Python for performance workloads.

While you fairly point out that many fall into Python because they learned about it in school and never bother to look beyond, Go has had no such equivalent. For you to choose it, you have to actively seek it out, where you are going to also see all the other programming languages you could also choose.

> As for Go, Kubernetes made it unavoidable, it is like UNIX for C, Web for JavaScript, and so forth.

UNIX's programming interface is a set of C functions. You are right that C is the path of least resistance to use it.

The web's programming interface is Javascript. You are right that Javascript is the path of least resistance to use it.

Kubernetes' programming interface is a "REST API" – or your program running inside a container, if you want to look at it from the other direction. In what way is Go the path of least resistance to use it?

Re: There is no memory safety without thread safety

#404

Post by tsimionescu »

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…

> Kubernetes services are one of the places where you don't care about startup time.

There are some kubernetes services that scale up and down. And even for those that don't normally, if they have some kind of failure, the difference between taking a millisecond to get back up and taking a second can actually matter for a web host.

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

Go starts up much faster than Java. And Go code runs measurably faster than interpreted Java code, even though it's slower than the JITed code you'll eventually have if your JVM runs long enpigh. But un-JITed Java code is very slow, more comparable to Python than JITed Java or with Go . This has nothing to do with the GC - where I do agree Go is mediocre at best.

Re: There is no memory safety without thread safety

#405

Post by layer8 »

zozbot234 wrote: post #340
layer8 wrote: post #338

Earlier quoted context omitted.

Threads aren’t hardware, they are OS. Multihreading != multiprocessing.

Hardware threads are a thing.

Other than in the sense of SMT (Hyper-Threading)? I don't think so. Threads are a software concept.

One can distinguish between native (OS) threads and green (language-runtime) threads which may use a different context-switching mechanism. But that's more of a spectrum in terms of thread-safety; similar to how running multiple threads on a single CPU core without SMT, single CPU core with SMT, multiple CPU cores, with different possible CPU cache coherency guarantees, create a spectrum of possible thread-safety issues.

Re: There is no memory safety without thread safety

#406

Post by [deleted] »

layer8 wrote: post #405
zozbot234 wrote: post #340

Earlier quoted context omitted.

Hardware threads are a thing.

Other than in the sense of SMT (Hyper-Threading)? I don't think so. Threads are a software concept. One can distinguish between native (OS) threads and green (language-runtime) threads which may use a different context-switching mechanism. But that's more of a spectrum in terms of thread-safety; similar to how running multiple threads on a single CPU core without SMT, single CPU core with SMT, multiple CPU cores, wit…

[deleted]

Re: There is no memory safety without thread safety

#407

Post by homebrewer »

philosophty wrote: post #208
henry700 wrote: post #67

Earlier quoted context omitted.

Skill? Go? With the amount of mistakes piling up over the years comparable to PHP at this point? Really??

These guys have each forgotten 10x than you know about programming. https://swtch.com/~rsc/ https://en.wikipedia.org/wiki/Ken_Thompson https://en.wikipedia.org/wiki/Robert_Griesemer https://en.wikipedia.org/wiki/Rob_Pike

Being exceptionally talented programmers does not automatically make them good language designers. I can think of a couple of people who may not be as good at programming, but are light years ahead at designing languages (and maintaining them over long term).

Re: There is no memory safety without thread safety

#408

Post by zozbot234 »

tsimionescu wrote: post #404
qcnguy wrote: post #318

Earlier quoted context omitted.

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…

> Kubernetes services are one of the places where you don't care about startup time. There are some kubernetes services that scale up and down. And even for those that don't normally, if they have some kind of failure, the difference between taking a millisecond to get back up and taking a second can actually matter for a web host. > Go is not particularly fast. People often see that Java gets faster as it runs and t…

I wouldn't call the Go GC mediocre, it's one of the few fully concurrent GC's in common use. It probably has significantly lower memory demand than Java/NET for comparable workloads.

Re: There is no memory safety without thread safety

#409

Post by pebal »

zozbot234 wrote: post #408
tsimionescu wrote: post #404

Earlier quoted context omitted.

> Kubernetes services are one of the places where you don't care about startup time. There are some kubernetes services that scale up and down. And even for those that don't normally, if they have some kind of failure, the difference between taking a millisecond to get back up and taking a second can actually matter for a web host. > Go is not particularly fast. People often see that Java gets faster as it runs and t…

I wouldn't call the Go GC mediocre, it's one of the few fully concurrent GC's in common use. It probably has significantly lower memory demand than Java/NET for comparable workloads.

This isn't fully concurrent GC. It pauses mutators threads and delegates them to perform some of the work for the GC.

Re: There is no memory safety without thread safety

#410

Post by littlestymaar »

rurban wrote: post #327
littlestymaar wrote: post #202

Earlier quoted context omitted.

Because the other teams members (IIRC brson and pcwalton) wanted Rust to be as performant as C++, which means you must have a way to have shared memory.

Which was the ultimate failure of Rust, because as Pony benchmarks have shown, you get safety and speed by proper security and architecture. Rust just survived by lying about the its safeties. What kills performance are not memory copies, but locks. Parallel nonblocking IO and a non POSIX stdlib will bring you far away from C++ or Rust performance.

Oh yeah, the “ultimate failure of Rust”, and tell me how industrially successful Pony has been compared to Rust?

(Don't get me wrong, I liked the idea behind Pony for backend code, it's much saner than Go for the same target space. But it failed to capture that market, because Go was already there. And it was never a competitor to Rust because this model is only viable for web back end tasks, not for general computing).

Post reply on HN