Comment by pjmlp | Hacker News Reader

Comment by pjmlp | Hacker News Reader

Parent Full thread

You are doing a great job with Rust, but I think you always jump to quickly to criticize Wirth languages and push for Rust.

Mesa => RC with local GC for collecting cycles.

Modula-2 => True, does manually memory management, but avoids all other C memory corruption errors.

Modula-3 => Uses GC only for types allocated via NEW. Library contains generic RC pointers. Untraced pointers can only be used in unsafe code.

Oberon derivates => Uses GC only for types allocated via NEW. Active Oberon added support for untraced pointers only in unsafe code.

Ada => No GC. All memory allocation is controlled. Deallocation is only possible via regions or explicitly in unsafe code. There are generic RC libraries as well.

Pascal dialects => No GC. Suffer from manual memory management, but none of the other typical exploits regarding out of bounds or pointer misuse.

Yes, they may lack affine types, but had they succeed in the industry instead of C, the need of something like Rust would be greatly reduced.

As such now we have to place our hopes in something like Rust, because the new generations never heard of those languages and think C was the very first systems programming language.

However every time I look at Rust sample code I would like to see the same amount of _unsafe_ being used like in the those languages.

Instead, many Rust users seem to sprinkle it everywhere.

> You are doing a great job with Rust, but I think you always jump to quickly to criticize Wirth languages and push for Rust.

I'm not criticizing those languages. I think they're valid points in the design space. I'm simply saying that they didn't do what Rust does: memory safety with no GC (and dynamic allocation/deallocation).

Rust's approach to built on what Cyclone and ATS have done is great work.

My point is that we would be less in need of Rust, if those systems programming languages have had taken C's place.

So given that they failed to gain mindshare, except for Ada in a niche domain, we now need new alternatives.

Still be prepared for an uphill battle with C++17, as language is only part of the equation, as I learned from being in the Wirth languages side for a few years.

> new generations never heard of those languages and think C was the very first systems programming language.

That's just it. Rust looks enough like C++ to catch on. This was not an accident though I can't say I'm jazzed about it.

Rust brings a lot to the table with its type system too. I would rather be using Rust tomorrow than having had the benefits of say Pascal derivatives for the past 45 years. I'm not saying this just for effect: after the obvious ML influence, the parts of Rust I like most are the nuances.

> Instead, many Rust users seem to sprinkle it everywhere.

Is that true? You will necessarily see it in bindings, or to implement certain essential features that can't be implemented otherwise. Beyond that there is the motivation to use unsafe code for speed, hopefully this is mostly restricted to modules.

Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary?

> Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary?

They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system.

While in the languages I mentioned, unsafe constructs are related any operation that might lead to memory corruption, some Rust devs are using it for anything they assume isn't logical safe.

So you then get talks like the Session Types one at ICFP, that uses unsafe to control functions being called outside the protocol Traits that are being defined.

Which lead to discussions like this one:

https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136...

So your objection is to how certain users (notably not the core dev team) utilize "unsafe", now with the language itself. It seems like the easiest way to mitigate this is with better documentation; surely, those other languages' equivalents of "unsafe" could also have been abused similarly, no?

No, because on those languages unsafe is only related to memory integrity.

> They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system.

That doesn't sound like abuse to me, as long as the exposed interface remains safe.

> some Rust devs are using it for anything they assume isn't logical safe.

That sounds like an objection to the scope of what Rust defines as safe. Unless you mean to imply there are reasonable, Rust-safe ways to rewrite the transgressions. In the former case I have to disagree. It would be nice if we could prove more. But you can't prove everything.

I haven't seen the ICFP talk but I might watch it later if you can link to a video. I've skimmed that discussion before but you will need to point out your objections—IMO it is great that Rust devs are having that discussion.

My objection is that I see unsafe just for memory integrity.

For everything else something like contracts should be used, from my point of view.

As for voicing my objections to the Rust community, being a language geek is one of my hobbies, but it doesn't mean I will ever use those languages at work.

So I would only contribute noise to the discussions, which why I eventually moved away from Go and D forum discussions as well.

My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on.

> My objection is that I see unsafe just for memory integrity.

Either you think this way because of a sense of orthodoxy or because you think memory safety is important in a way the other kinds of safety aren't. I disagree, especially since "memory safety" may or may not imply protection against aliasing of mutable data. Those nuances I like about Rust probably wouldn't exist without the broader scope of safety concerns.

> As for voicing my objections to the Rust community,

About the discussion you linked? I meant to me, in the service of explaining your objections.

> My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on.

Well, that was important information. Thanks for making the time to share!

To be clear, we on the Rust team see 'unsafe' as being strictly about memory safety as well, and have actively fought against using it as a general "pay attention here" kind of annotation.

Eventually, effects would be nice to mark other kinds of "here be dragons" as well, but for now, unsafe == possible memory unsafety.

If you read the comment you'll see that I'm talking about different interpretations of memory safety. You can't just decide what it means in Rust applies to all languages, or that everyone knows what you mean.

I was trying hard to have a conversation while avoiding arguing about semantics, so thanks for that.

> Either you think this way because of a sense of orthodoxy or because you think memory safety is important in a way the other kinds of safety aren't. I disagree, especially since "memory safety" may or may not imply protection against aliasing of mutable data. Those nuances I like about Rust probably wouldn't exist without the broader scope of safety concerns.

Memory safety is more fundamental than most other sorts of correctness: it is a necessary (but not sufficient) condition for them. If you can't assume memory safety, you have no assurances about any other invariants, because any piece of data can be modified/outdated/invalidated at any time in the program's execution. (This is especially bad if the compiler will itself assume that memory safety can never happen, and use this undefined behaviour to optimise the program in unintended ways.)

I'm fairly sure that some definitions of memory safety that works for Rust are "there are no use-after-frees" or "the language is type-safe"; all 'other' problems with memory safety (iterator invalidation, data races, etc.) can be used to violate those and hence need to be outlawed. I'm not sure there's that much wiggle room for what memory safety means, at least in broad terms. In any case, aliasing of mutable data can definitely lead to memory unsafety, and is hence covered/controlled by Rust's guarantees. In some ways, it is really the fundamental cause of memory unsafety: remove/control either "aliasing" (e.g. Rust, many GC'd languages) or "mutable" (e.g. Haskell) and you've got memory safety.

Also, Rust definitely doesn't only try to help the programmer with memory safety, it's just memory safety (and hence type safety) is the form that has hard guarantees. Other forms are generally handled by "lints"/warnings or by building libraries on top of the type system.

Reply on news.ycombinator.com