Does an underlying theory exist that meets the requirements of being analysed, understood, and refactored? If so, how does it look? Remember that it should meet the requirements of zero-cost abstractions and concurrency with thread safety, etc. No GC, VM, or interpreter language please.
The relevant parts of the first linked post are mentioned below. Expand the linked posts above to read further. Be sure to keep on-topic, remarks on the author’s style is relegated to a theoretical and general discussion here.
I think it’s a goal on the long term. We’re making great progress on that with rls, and I’m content with that for now. I think we shouldn’t rush deeper integration if it comes at a cost of slowing down progress in the language/compiler too much.
Isn’t that the fault of IDEA’s Rust plugin then? This seems to work well in rls.
I feel automatic deref is a core part of Rust’s ergonomics, and we must not sacrifice it so that it’s more convenient to write IDE integrations. Again, rls seems to deal with this just fine.
Now you’re just speculating from thin air. There are clear designs in the RFCs.
Perhaps rather than undefined behavior you mean that Rust has a steep learning curve? It does have that, at least for the time being.
On a core level, sure, there’s lambda calculus with linear/affine types and regions. Tofte et al’s papers on region-based memory management investigate some aspects of that. But even if that language were exactly defined, it doesn’t have a syntax in the sense of programming languages, and we really do need a surface syntax. The essence of Rust could be one.
That’s really annoying! It’s sad that both IDEA and IntelliJ are so bad with Rust. I wonder if the editor situation is turning away a lot of people from Rust. If it does, perhaps on the website we should list some editors that work great with Rust and some editors that are very buggy with Rust, so that at least this papercut is reduced when people try it out.