Dynamic typing doesn't scale in large teams, it is however great in small projects, or if optional typing is supported, which took a long time to learn from languages like structured BASIC dialects.
It is no accident that all mainstream dynamic languages now have optional typing support, either in the language directly or via linters.
Oh yeah, I'm massively in favour of gradual typing. Python's choice to not actually enforce type hints is perhaps the most moronic language design I've ever seen.
Given your nick, one of the points of 2026 roadmap is exactly trying to make Rust more Swift like, or any other language with RC as automatic resource mechanism for that matter, removing the .clone() pain.
Or the experiements Niko Matsakis is doing with Dada.
If anything all those attempts prove that for many scenarios, it is better having automated resource management + (affine, linear, dependent, effects) than the pure affine types approach taken by Rust.
Hence all the Chapel, Swift, D, Linear Haskel, Ox, Idris2, Scala Capture Checking, Koka, and probably many others, efforts going on.
This is also noticeable among rustaceans, otherwise ergonomics for all the .clone() and related machinery, wouldn't be part of the 2026 roadmap.
> it is better having automated resource management
Rust's ownership system is automated resource management. What you're asking for is dynamic lifetime determination, which Rust provides via types that opt out of the hierarchical single-ownership paradigm.
Manual memory management requires the programmer to insert calls to free at specific points in the program. That's manual static lifetime determination. A traditional garbage collector uses runtime analysis to determine when it's safe to call free. That's automatic dynamic lifetime determination. What Rust does is automatic static lifetime determination. Designing your data structures such that they're acyclic is not what anyone means when they say "manual memory management".
If you want automated resource management, automate it. I'm really not convinced that Koka-style effects-for-everything are a win relative to just passing objects that own resources through parameters so they have actual values and explicit lifetimes.
I certainly do, which is why outside some hobby coding to try out new language features, as means to understand where Rust stands, I don't have any special use case where I would pick Rust instead of one of those languages.
For me its ideal use case, are places where any form of automated resource management is either not technically possible, or it is a waste of time trying to change mindsets.
> I don't have any special use case where I would pick Rust instead of one of those languages.
Rust isn't a language for a special case, Rust is universal. Those other languages are for special cases, you're simply a special case developer.
Picking a different language for each special case is the primary problem Rust solves, it's the problem of being a jack of all trades and a master of none.
>> If anything all those attempts prove that for many scenarios, it is better having automated resource management + (affine, linear, dependent, effects) than the pure affine types approach taken by Rust.
Can you write the proof down for us please? I'm curious, how do you prove that "for many scenarios" A+B is better than B+A?
The OP is about doing A in safe Rust, which isn't even an option for many of those other languages which are, at the very least, bootstrapped from unsafe code.
The proof is the amount of research that is ongoing for plenty of people that don't consider Rust as it stands today, the ultimate answer in programming languages, including people like Niko Matsakis.
Or are you going to reply his opinion has no value, and should abandon the language ergonomic proposals from the improvements roadmap?
> Or are you going to reply his opinion has no value, and should abandon the language ergonomic proposals from the improvements roadmap?
I don't deny the existence of special cases or the value of looking for better ergonomics even at the expense of university. However, at the moment Rust is the best option for practitioners who don't have enough time to juggle multiple languages.
Meanwhile those that complained about Java, now ship a whole browser with their "native" application, and then complain about Google taking over the Web.
reply