Yes, but that comes with additional complexity. Which is not a bad thing, as I said. We could say that Java does not have an ownership model because it's garbage collected nature does not need it.
It's just a different approach that demands different things from the programmer.
I think the most important part of Rust is that its ownership model also allows thread safety without manually synchronizing access to shared memory. Java cannot do that even in theory.
It may be worth distinguishing between missing, which in context you seem to be using along the lines of 'not built in to the language or std library', and unavailable, which I would describe as a feature not being accessible at all when using the language in question.
Rust doesn't supply garbage collection in std, but if you have a specific case where you need it there are crates like gc that implement a specific form of it. Rust also doesn't supply async/await, but you can add Tokio or async-std and have that feature available if you need it. Both examples of Rust's preference for paying only for what you use and their specific approach to what is and is not included in the std library.
Java has a different approach, as far as I know.
Re the original article, talking about language replacement without talking about what the tool is being used for seems a little misguided. It's sort of the blog equivalent of making a technical decision without knowing any of the actual project constraints. Real world examples of switching to Rust (eg Discord switching certain services from Go to Rust) are specific to the use case, not just blanket 'rewrite all the things in Rust'.
Yes, but that comes with additional complexity. Which is not a bad thing, as I said. We could say that Java does not have an ownership model because it's garbage collected nature does not need it.
It's just a different approach that demands different things from the programmer.
I think the most important part of Rust is that its ownership model also allows thread safety without manually synchronizing access to shared memory. Java cannot do that even in theory.
Yeah, I just got your comment "Without garbage collection" as if that's a feature missing from Rust.
In a very literal sense it is missing from Rust, but yeah, could have phrased it better.
It may be worth distinguishing between missing, which in context you seem to be using along the lines of 'not built in to the language or std library', and unavailable, which I would describe as a feature not being accessible at all when using the language in question.
Rust doesn't supply garbage collection in std, but if you have a specific case where you need it there are crates like gc that implement a specific form of it. Rust also doesn't supply async/await, but you can add Tokio or async-std and have that feature available if you need it. Both examples of Rust's preference for paying only for what you use and their specific approach to what is and is not included in the std library.
Java has a different approach, as far as I know.
Re the original article, talking about language replacement without talking about what the tool is being used for seems a little misguided. It's sort of the blog equivalent of making a technical decision without knowing any of the actual project constraints. Real world examples of switching to Rust (eg Discord switching certain services from Go to Rust) are specific to the use case, not just blanket 'rewrite all the things in Rust'.
Great info, thanks!