Rust's type system prevents bugs far beyond mere memory bugs. I would even go as far as claiming that the type system (together with the way the standard library and ecosystem use it) prevents at least as many logic bugs as memory bugs.

The type system was built to describe memory layouts of types to the compiler.

But I don’t think it prevents any more logic bugs than any other type system that requires all branches of match and switch statements to be implemented. (Like elm for example)

It prevents a lot more than that. For example, it prevents data race conditions through Send/Sync traits propagation.

Besides preventing data races (but not other kinds of race conditions), it is not at all unique. Haskell, OCaml, Scala, F# all have similarly strong type systems.

I’m assuming by rust’s type system they mean without lifetimes. In which case it’s existed in lots of GC languages (OCaml, Haskell) but no mainstream ones. It isn’t really related to needing a GC or not.

You still want RAII and unique references, but rely on GC for anything shared, as if you had a builtin refererence counted pointer.

I do also believe this might be a sweet spot for a language, but the details might be hard to reconcile.

I haven’t used Swift so I might be totally wrong but doesn’t it work sort of like you describe? Though perhaps with ARC instead of true GC, if it followed in the footsteps of Objective-C.

Possibly, yes. I haven't used swift either though. Does it have linear/affine types?

Edit: I would also prefer shared nothing parallelism by default so the GC can stay purely single threaded.

Without lifetimes, Pins, Boxes, Clone, Copy, and Rc (Rc as part of the type itself, at least)

I like Rust’s type system just fine but for me it’s types combined with language features like matching that draw me to Rust. When I was still learning I made an entire project using Arc<> with no lifetimes at all and it was actually a great experience, even if it’s not the textbook way to use Rust.

Honestly, I think syntax for Arc (and/or Rc or some generalization of the two) and more "cultural" support for writing in that style would have benefitted rust back when 1.0 was being finalized. But I think the cow is out of the barn now on what rust "is" and that it isn't this.

A long time ago, it did have specialized syntax! We fought to remove it. There’s a variety of reasons for this, and maybe it would make sense in another language, but not Rust.

For Arc/Rc? I don't recall that! What was it? I recall it being `&borrowed`, `~boxed`, `@garbage_collected`.

Aaaah, I'm realizing in typing this that the `@foo` syntax was actually implemented via reference counting? I think my intuition at the time was that the intention was for those to eventually be backed by a mark-and-sweep GC, which I did think was a poor fit for the rest of the language. But as just a syntax for reference counting, I honestly think it might have been an ok fit.

Or maybe not, I'm ambivalent. But the syntax thing in my comment is more of a red herring for what I think is more of a cultural "issue" (to the small extent it is an issue at all), which is that most Rust projects and programmers seem to try to write in a style that defaults to only choose reference counting when they must, rather than using a style of optimizing them out if they show up in a hotspot during profiling.

Yes, I’m referring to @foo, which IIRC maybe in the VERY old days had a GC but from when I got involved in 2012 was reference counting, iirc.

Regardless of the specifics here, the same problems apply. Namely that it privileges specific implementations, and makes allocation part of the language.

Yeah, which circles back to the thread-starter's comment. My thought-experimental different version of rust would not mind shipping with a privileged implementation of garbage collection, or having allocation be part of the language.

It wouldn't be a good fit for projects like the ones at Oxide :) I'm very glad Rust itself exists, with good support for use cases like those!

Yes, if you think about it, it's a bit weird that async gets first syntactical class treatment in the language but reference counting does not. A similar approach of adding a syntactical form but not mandating a particular impl could have been taken, I think.

Same for Box, but in fact Rust went the opposite way and turfed the Box ~ sigil.

Which I actually feel was a mistake, but I'm no language designer.

Async has to get first-class treatment in the syntax because the whole point of it is a syntax-level transformation, turning control flow inside out. You can also deal with Future<> objects manually, but that's harder. A special syntax for boxed variables adds nothing over just using Box<> as part of the type, similar for Rc<> (note that in any language you'll have to disambiguate between, e.g. cloning the Rc reference itself vs. duplicating its contents, except that Rust does it without having to use special syntax).

Yeah, but personally I think Rc/Arc is more deserving of syntax than Box!

@gc references were Arc under the hood!

Totally makes sense! Not sure if I never knew or if that knowledge got lost in the sands of the past decade (or more, I think?) of time.

That's interesting - so you used Arc even if you didn't need thread safety?

Lifetimes elision works pretty well so you don't often need to specify lifetimes

It usually pops up when you use generics / traits (what concrete type does it match to?)

> The whole point of rusts type system is to try to ensure safe memory usage.

It isn't though. The whole trait system is unnecessary for this goal, yet it exists. ADTs are unnecessary to this goal, yet they exist. And many of us like those aspects of the type system even more than those that exist to ensure safe memory usage.

It is the first and foremost goal of every language choice in rust.

I think traits muddy that goal, personally, but their usefulness outweighs the cost (Box<dyn ATrait>)

I should’ve probably said “the whole point of rusts type system, other than providing types and generics to the language”

But I thought that went without saying

> It is the first and foremost goal of every language choice in rust.

It ... just ... isn't, though.

I mean, I get what you're saying, it's certainly foundational, Rust would look incredibly different if it weren't for that goal. But it just isn't the case that it is "the first and foremost goal of every language choice in rust".

I followed the language discussions in the pre-1.0 days, and tons of them were about making it easier and more ergonomic to create correct-if-it-compiles code, very often in ways that had zero overlap with safe memory usage.

Traits don't "muddy that goal", they are an important feature of the language in and of themselves. Same thing with the way enums work (as arithmetic data types), along with using Option and Result for error handling, rather than exceptions. Same thing with RAII for tying the lifecycle of other resources to the lifecycle of values.

The memory safety features interact with all these other features, for sure, and that must be taken into account. But there are many features in the language that exist because they were believed to be useful on their own terms, not in subservience to safe memory usage.

And it's not just about "providing types and generics to the language", it's a whole suite of functionality targeted at static correctness and ergonomics. The ownership/lifetime/borrowing system is only one (important!) capability within that suite.

The whole reason I got interested in Rust in the first place was because of the type system. I viewed it as "Haskell types but with broad(er) adoption". The fact that it also has this neat non-GC but memory safe aspect was cool and all but not the main sell for me.

By "rusts type system" I mean enums with exhaustive pattern matching and associated structs, generics, conventional option and results types, and so on. None of that necessarily has anything to do with lifetimes as far as I understand.