Hide memory management under a language runtime. Make a single Fn trait/string type instead of multiple ones. Add effect polymorphism to deal with function colours. Remove async/.await and express it using algebraic effects, do the same for streams and iterators.

How it'd be designed and implemented is probably a theme for a separate blog post, not a HN comment.

So basically OCaml.

OCaml is great, but it lacks traits / type classes. That plus some syntactic tweaks would make OCaml amazing for most general purpose programming.

That is what functors and modules are for.

And then the O in OCaml is all about OOP.

Functors and modules are nice but do not have the convenience of traits and type classes. The problem with functors and modules is that you have to manually instantiate the right functors and modules when you want to use some operation. Type classes and traits build the right instantiations for you based on the types.

I want to write `toString (1,true)` not `ToStringPair(ToStringInt)(ToStringBool).toString (1,true)`.

> Which parts of Rust would you give up to make this happen? And how would this be implemented?

Traits, maybe? Switch to an OO model more closely aligned to what the majority of developers understand. Dump all of the line-noise-type syntax.

My Own Toy Language (ComingRealSoonNow)^tm that I started designing had exactly one goal - prevent the majority of memory errors, not prevent ALL memory errors. All I wanted was to indicate when/where an object will be destroyed/mutated. That's enough for me.

Traits are the one part of Rust that should definitely not be given up. It is way better than the traditional OO model.

Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages.

Also the basis for one programming language that used to be widespread in the enterprise for quick and dirty solutions, VB and its ecosystem of OCX libraries.

It is more widespread that people think, because when many argue about OOP, they miss the full spectrum of how OOP is approached.

Traits seem, to me, a lot like generic functions and methods in CLOS (Common Lisp). It's just that CLOS doesn't bundle a group of generic functions into a trait, they're a la carte.

Yes they do, they are called protocols.

> Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages.

So? Giving up Rust-Traits doesn't mean that I will give up on interfaces as a whole.

I don't like the way C++ does interfaces, for example, but that doesn't mean that my ideal language won't have interfaces.