this is nice
I definitely think a language that has room for abstractions that aren't zero cost, while still having a borrow-checker makes sense. Using rust to make that language also makes sense. I think implementing a vm or interpreter entirely in safe rust would effectively force borrow checking on the resultant language wouldn't it?
Ruby seems like a good place to start the experiment. I'd prefer it end up with something more like julia or python just for my own use cases.
As for having both, I rather take Swift memory ownership or Linear Haskell approach, or even D/C#/Nim/Go.
The productivity of automatic memory management, with the tooling to go low level C and C++ style, if and when it is really needed.
If the idea is for a safe but more ergonomic language at the cost of performance, I think you'd be focused on making clone and copy implicit when a move doesn't work, getting rid of explocit borrows/references, and perhaps figuring out mutability without needing to annotate it. The absolute type safety is probably the biggest speedbump I hit in daily usage though, not the borrow-checker. A strong but duck/dynamic type system might solve that?
Borrow checker alone makes several algorithms and data structures quite hard to implement.
Swift memory ownership model, Linear Haskell, Hylo (née Val), Chapel, Ada formal proofs, D's ownership model, are all examples where language designers decided borrow checker alone is too much to ask for.
No UB to worry about.
> requisite time trudging through the lifetime swamp
Rust really isn't like that. It gets a bad rap.
> I couldn't couldn't imagine running my whole life on the stack
Most of the things you touch in Rust are heap allocated.
> this would be a really nice language if it were garbage collected
It is a nice language, and all of your complaints go away once you start using the language idiomatically.
Oh you can absolutely say that.
It's just a dumb take. Because there are already languages which have a solid type system, a functional bent, and a GC. And you can probably bang out one yourself if you want.
If that was what Rust was, it probably wouldn't have existed in the first place, Mozilla would not have been interested in it in the second place, and no community would have gelled around it in the third place. Hell, it was specifically dragged further downstack by the people who coalesced around its potential in that space.
If OCaml/StandardML/Haskell/etc had anything close to the ergonomics and convenience of cargo for testing, setting up projects, adding deps, deploying them to any OS/platform, I would probably write about 30-40% less Rust.
I'm not saying we should add GC to Rust - but I think there is space for a Rust+GC language (or just improved ecosystem and tooling for other functional langs)
I rather have one package that does it right, than 20 doing a different set of 80% from what is needed.
As just one example: there are no OCaml or Haskell packages for natively reading or writing parquet files. There are at least 2 such packages for Rust.
Likewise, despite crates.io, Rust is missing lots of stuff I miss from Java, C# and C++.
Plenty of stuff isn't there yet.
Ahem... Excuse me, sir, do you have time to talk about our lord and savior Robert Pike?
Politely closes door in your face
https://github.com/golang/go/issues/57644
Although I'm curious, what is your use case that cannot be fulfilled by interfaces, but can with sum types?
Sum types allow you to express type-level OR. Structs/tuples etc are AND (product types). I like to be able to use both OR and AND at both the expression and type level.
But that doesn't mean Rust with GC wouldn't be a nice language! I don't know of any language that really fits that description.
In fact, I'll pick just four things I like about Rust: a good type system, a supportive, productive community with a focus on doing real stuff, enough mindshare and buzz not to be irrelevant, and being not totally insane.
The first criterion rules out all untyped languages, Go, and the blue collar languages like Java and C#. The second rules out all existing functional languages. The third rules out whatever niche language you're about to suggest. The fourth rules out C++.
There really isn't a mainstream managed language which has managed to thread both the design and community needles the way Rust has.
Rust as a midpoint between Haskell and C, so really C with a nicer type system, combined with momentum/meme status is more important today than it's memory safety story. Memory safety just isn't the buzzword that it was even in 2019 let alone 2015.
> And you can probably bang out one yourself if you want.
I've written my own dataflow analysis code, aimed at lifetime checking, too, but that's not really the point is it?
Rust is C++ with stronger typing and a better memory management model. Comparisons between Rust and C aren't really accurate because Rust is the modern stainless steel kitchen sink that C++ can't be. Without its lovely ADTs and borrow checker it's just C++ with a better package management story. Nothing wrong with that. It won't replace C.