Hacker News Reader

Comment by leshow | Hacker News Reader

This article casually throws around definitions of 'memory safety' that are massively different.

Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Rust includes protection from things like modifying memory from 2 different spots at the same time, among other things.

AFAIK that's perfectly fine to do in Go, you can pass around pointers between threads as much as you like. This sort of behaviour wouldn't be allowed in safe Rust.

edit: I just really don't understand the criticism against Rust here for having 'unsafe' given much of what is covered in those unsafe blocks is allowed in many other languages, including a language mentioned in the article as being 'safe'

View on HN

> I just really don't understand the criticism against Rust here

I think you are confusing two different narratives in the article: software development in general, and Rust the language/ecosystem/community.

The article raises many points about how the former as a whole does not care enough about security. How we do not have the right incentives to fix memory safety bugs (the bug bounty thing) nor treat them as the security risks that they are (the pushback from developers when you explain that something is a security issue).

That is the software industry in general though, not Rust.

There is also constructive criticism about how Rust handles these things and how it could do better. But it is clear that the author loves Rust for trying to find ways to fix this and how it aims to be a more secure and safe language. Note how the article is full of praise for how the Rust community responded to his feedback, and for the ambitions of the language.

EDIT: as I wrote in another comment, the main point regarding Rust is that "unsafe" by definition throws safety guarantees out the window, so to minimize the risks it brings, solutions outside of the language are needed (aside from hypothetical language improvements that reduce the need for unsafe, of course). This is easily forgotten in the hype about Rust's safety guarantees. Saying "but all languages screw this up in some way" is not really an excuse.

> "unsafe" by definition throws safety guarantees out the window

I wish they had chosen a different keyword, it doesn't necessarily mean that. For instance, the type checker still runs on the contents of unsafe blocks, so does the borrow checker, the only thing you can do that you can't normally is dereference raw pointers. This is potentially unsafe, and you should be careful, but it absolutely does not "throw all guarantees out the window".

> the only thing you can do that you can't normally is dereference raw pointers.

The type checker still runs by default, but unsafe allows you to opt out of it selectively (with std::mem::transmute[0]). The same way that borrows are still checked, but unsafe allows you to opt out by using raw pointers (as you mentioned).

[0]: https://doc.rust-lang.org/std/mem/fn.transmute.html

> Rust's 'memory safety' guarantee is different from Go's 'memory safety'.

Nope. Rust protects against data races, that are universally considered memory unsafe, given the usual C/C++ concurrency model. There is no ambiguity here. And yes, sequential Go _is_ memory safe, but concurrent Go is not. Deal with it, gophers - and please do not impute purposeful ambiguity and disingenuous characterization where there isn't any.

...Are you really trying to use “gophers” as a derogatory term?

Doesn't look like it. Looks like they are just using it for artistic flourish.

Many Go programmers refer to themselves as Gophers actually after the mascot the same way university students might refer to them selves as Jaguars, Titians, or Aggies.

It's hard to google a good example but here's one I found:

> A creative and passionate community of Go developers and users (“Gophers”) has grown up around the language, and today there are U.S. Go conferences, European Go conferences, […] even a group for LGBT Gophers (yes, “Gayphers”).

https://blog.newrelic.com/technology/golang-experts-follow-o...

> And yes, sequential Go _is_ memory safe, but concurrent Go is not.

You're agreeing with me, I was saying that Go isn't memory safe by Rusts definition. As you mentioned, it doesn't protect against data races, therefore, when Go claims memory safety they are using some different definition of memory safe.

Reply on news.ycombinator.com