[jonnytran]

It's unfortunate that there's no mention that not all these languages are equally safe.

Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

[corethree]

That's fine. Safety with concurrency doesn't exist in any language. Only rust is special in that it tries to provide safety with concurrency as well. I haven't seen any other language besides rust actually do this.

The reason is obvious. There's a high cost to this type of safety. Rust is hard to use and learn and many times it's safety forces users to awkwardly organize code.

And there's still the potential for race conditions even though the memory is safe, you don't have full safety.

[NSufi]

Swift provides memory safety with concurrency as well.

[zozbot234]

It's not safe when using goroutines to access shared mutable data (and most Go code does this). If you stick to message passing a.k.a. "share data by communicating" you don't run into memory unsafety. But this kind of design is more vulnerable to other concurrency issues, viz. race conditions and deadlocks.

[Thaxll]

Go is memory safe, that post does not means anything in real life scenario.

Do you have a single example in the last 14 years of memory safety exploit using the Go runtime? I'm talking about public and known exploit not ctf and the like.

[jonnytran]

The same author has a post from 2022 [1].

> Is it possible to achieve arbitrary code execution on any Go version, even with PIE, and with no package import at all, just builtins? Yes!

Whether it's capture the flag is irrelevant, IMO, because anything that's allowed by the compiler will emerge given enough complexity.

1: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...

[slimsag]

Adding some more for other languages:

* many GC'd languages like Go, C#, Java make it harder to leak memory, while languages where reference counting is more prevalent (Python, Rust) it can be easier to leak memory due to circular references.

* Languages with VMs like C#/Java/Python may be easier to sandbox or execute securely, but since native code is often called into it breaks the sandboxing nature.

* Formally-verified C code (like what aerospace manufacturers write) is safer than e.g. Rust.

* For maximum safety, sandboxing becomes important - so WASM begins to look appealing for non-safety-critical systems (like aerospace) as it allows for applying memory/CPU constraints too in addition to restricting all system access.

[trealira]

You can also cause a segfault in Go by dereferencing a null pointer. That's another example of not being entirely memory safe.

[conradludgate]

In this case it's not memory unsafe. It is guaranteed to crash the program (or get caught). It's closer to a NullReferenceException than it is to reading from a null pointer in C. There's no memory exploitation you can pull off from this bug being in a Go program, but you could in a C program