I really love traits in Rust. It's in my opinion the best way to implement interfaces. I'm really thinking about writing a toy language that looks like Rust 99% but without the borrow checker. The ownership thing annoys me. I know it helps creating secure programs but I'd be fine with a language that has Rust syntax/generics/traits/pattern matching with garbage collection. My goal isn't to create a C replacement, but a better Go. Go gets concurrency and syntax right but its type system is shitty. Go is a missed opportunity.

I'm actually a huge fan of their ownership model. I find that in languages where you can't enforce it(Java, etc) architecture tends to suffer. Single owner(with tools to break out when you have to) is a fantastic model.

I feel that lazy ownership gets really gnarly when you start associating large native resources with objects and then can't clearly be sure who's owning a reference to what(see Activity/Context leaking in Android).

All of this stuff is solveable with proper diligence but I prefer my language to enforce it.

> All of this stuff is solveable with proper diligence but I prefer my language to enforce it.

This is why I love Rust in a nutshell (okay, there are actually a lot of reasons, but this is a big one). Given the choice between my ability to write perfectly bug-free code and the compiler to make sure that my code is correct, I'll pick the compiler any day of the week. And that's before taking into account the fact that like most programmers, I have to work with code that's not mine as well.

> All of this stuff is solveable with proper diligence but I prefer my language to enforce it.

Exactly. Everyone trying to defend C always makes this argument, well you just need perfect programmers who write code without mistakes! Why can't everybody just write good C? But some of us live in the real world where those mistakes mean huge vulns.

(Not hating on C in general, just in any security-sensitive context)

Rust's concurrency story is built on top of ownership. Its how Rust prevents data races.

>My goal isn't to create a C replacement, but a better Go. Go gets concurrency and syntax right but its type system is shitty. Go is a missed opportunity.

Have you considered forking Go and replacing the type system? If such an experiment was successful this could be the fabled Go 2.0...

Have you looked at Swift? In some ways, it's a bit like Rust without strict lifetimes Swift has GC (ref counting under the hood) and a fairly expressive type system.

Type classes in Haskell are similarly awesome and where Rust's traits originate from. It's way more flexible and expressive than OO interfaces.