So, maybe add a few features to Zig and we'll have a Rust alternative for many use-cases?
For borrow checker, I still think a combo of static analysis and concurrent GC's could help. Pair a static analyzer, like Infer, with your code that doesn't borrow check. If it says it's safe, you're good to go. If part of it is safe, other parts get ref-counted or a concurrent GC by default until proven safe.
Users get benefits of all safe code in Rust. They can write their own code as fast as with a GC'd language with smaller-than-usual, performance costs. Anything proven safe by static analysis goes faster without the GC. What do you all think?
The problem with this strategy is similar to what happens with escape analysis: you make a small change, and suddenly the performance aspects can change drastically.
The errors are useful design pressure on a system, not something you actually want to just codegen in a drastically different way to fix.
That's a good point on performance. It's very nonlinear and unpredictable. Might still be OK if assessed on a case by case basis. Also, any system language should have unsafe for when performance is highest goal.
> So, maybe add a few features to Zig and we'll have a Rust alternative for many use-cases?
Always wondered why can’t there be a new compiler for C itself which addresses its shortcomings? Cyclone tried to do that and it was successful. Rust itself took the same ideas from it.
For borrow checker, I still think a combo of static analysis and concurrent GC's could help. Pair a static analyzer, like Infer, with your code that doesn't borrow check. If it says it's safe, you're good to go. If part of it is safe, other parts get ref-counted or a concurrent GC by default until proven safe.
Users get benefits of all safe code in Rust. They can write their own code as fast as with a GC'd language with smaller-than-usual, performance costs. Anything proven safe by static analysis goes faster without the GC. What do you all think?