It’s worrying to me that Carbon separates data races and memory safety as two distinct things when data races can easily cause both spatial and temporal memory safety issues. Similarly, type safety, can also cause spatial issues (e.g. many kernel exploits in Darwin were a result of causing type confusion for the SLAB allocator resulting in an exploitable memory safety issue).

The entire philosophy errs too much in the direction of “being reasonable” and “pragmatic” while getting fundamental things wrong.

> Over time, safety should evolve using a hybrid compile-time and runtime safety approach to eventually provide a similar level of safety to a language that puts more emphasis on guaranteed safety, such as Rust. However, while Carbon may encourage developers to modify code in support of more efficient safety checks, it will remain important to improve the safety of code for developers who cannot invest into safety-specific code modifications.

That’s really just paying lip service to Rust without recognizing that the key insight is that optional memory safety isn’t memory safety.

It is kind of neat just how much Rust has managed to disrupt the C++ ecosystem and dislodge its position.

▲

gpderetta 7 months ago | parent [-]

In principle data races can cause memory safety issues, but they are usually very hard to exploit.

Java guarantees VM integrity in the face of data races, while for example many races are UB in theory and in practice in Go. Both are considered safe languages.

Sometimes pragmatism is in fact a valid goal.

edit: from a practical point of view I don't know how realistic is to retrofit memory safety to a language that lacks it.

▲

vlovich123 7 months ago | parent | next [-]

An interesting claim to make. Do you have evidence to support that position?

I could just as easily offer a valid counter analysis to explain the data. They’re “hard” just because there’s so many easier avenues so attackers just often don’t bother not because they’re intrinsically unlikely. Let’s say you’re successful in eliminating temporal & spatial classes of failures completely (even Rust proponents do not claim this). They’ll focus on data races and type confusion next.

> Both are considered safe languages

Go is considered a memory safe language today because C and C++ are the anchor that we compare against and we have overwhelming evidence against it (but it’s also where a huge amount of value is in terms of the systems they underpin). In 50 years time, it’s not inconceivable that a lot of the languages may lose their memory safety designation if their runtimes continue to be written to C/C++ (Java) and/or data races remain unaddressed at the language level (Go) and we have overwhelming evidence that exploits just moved on to architectural defects in those languages.

It may raise costs of exploits but cybercrime is estimated to be a 10T dollar market next year so there’s clearly a lot of money to put towards exploits.

> from a practical point of view I don't know how realistic is to retrofit memory safety to a language that lacks it

I think letting people evolve into a more memory safe situation is good. I think doing it partially instead of tackling memory safety in all its forms is just asking for trouble - your attackers will be able to develop exploits more quickly than you are able to update all existing code to more secure language features.

▲

zozbot234 7 months ago | parent | prev [-]

Golang is very much not considered "safe" from data races.

	▲	gpderetta 7 months ago \| parent [-]
		I explicitly said it isn't. It is still considered a broadly memory safe language.