Conversation

Go has GC and Rust doesn't. If you were to design an explicitly C-like language with memory safety and without GC, it would look a lot more like Rust than Go. The idea that Rust was designed by a bunch of C++ fans is absurd. Most of us were ML fans more than anything. t.co/SWJhLJptY3

This Tweet is unavailable.

3

26

238

This Tweet was deleted by the Tweet author. Learn more

The issue is that generics are basically a requirement for memory safety without GC as Rust does it. Otherwise you can't create safe abstractions, which would mean that every time you want a linked list you have to write unsafe code. That would undermine memory safety.

2

1

15

Replying to

I don't follow. Do you claim this is the case if you did it the C way, i.e. without an abstraction or with macros?

1

Replying to

and

How do you write a function receiving a slice like &[Type] and returning a reference to the initial value as &Type if you don't have generics? It needs to be generic based on the lifetime of the reference even if Type is a specific type rather than a generic type parameter.

2

1

1

Replying to

and

If you don't have a way to do this, there's not much you can do without entirely copying everything over and over to do anything. If the language doesn't have nullable references by default, which is a huge design mistake, my example would also likely return Option<&T> instead.

1

1

Replying to

and

Generics and sum types are expected these days for productivity but with the focus on safety they become essential for usability for various reasons. It's very desirable for generics to specify the requirements for the types to specify the API properly and provide proper errors.

1

2

1

Replying to

and

That leads to wanting a feature for specifying interfaces, i.e. type classes. So now you have generics, type classes and sum types as baseline features. Now, how do you implement closures in an efficient way, without forcing allocation or using them solely via generic functions?

1

1

Replying to

and

Each is essentially a unique type based on their captures, with a method for calling them. Having closures implement specific interfaces (type classes) makes sense and is what Rust does but you lack a way to work with them in an abstract way rather than unique types via generics.

1

1

2

Replying to

and

So, for example, consider a use case like a work queue where work is supplied as a closure. You need to define a queue data structure with closures. A generic Queue<T> isn't enough because you don't have a specific type. Sum types don't work either, they aren't extensible.

1

1

Replying to

and

Rust allows using interfaces (type classes) as objects themselves, which is how this works for closures (the language has sugar for it) and also in general for other extensible systems where using specific types via sum types and generics doesn't work.

9:25 PM · Jul 25, 2019Twitter Web App

Replying to

and

There are clear reasons for Rust having the core features that it does. You could leave out a lot of assorted frills, but a lot like destructuring / pattern matching are really core parts of how it deals with providing a low-level memory safe language with lightweight references.

1

1

3

Replying to

and

Thanks. That actually makes it make some sense to me, on a very high level. The ugly over-complex "productivity" features I don't like just fall out as a consequence of needing largely the same thing for Rust's approach to lifetime management.