Even with respect to dealing with JSON, good luck deserializing a structure with borrowed references. People will tell you not to use borrowed references, but sometimes you’re at the mercy of a library author and even if you’re not it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields, right after you got everything working just because you can’t figure out how to deserialize properly and no one else appears to know how either. This is one of many problems that make Rust more difficult and time consuming in practice than Go which doesn’t distinguish between owned and borrowed. Of course this borrow checker gives you a lot more thread safety than Go provides, but I write a lot less parallel code than code that must be deserialized (or any of the other areas where pernicious borrow-checker issues creep in).
Rust improves quickly so I don’t think we should discount it, but I wish Rust folks would address these concerns when talking about how Rust is going to take over $x domain.
> it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields
Some refactorings in Rust has brought back memories of refactoring struggles with highly coupled code bases, where one seemingly small change ends up requiring touching many many areas of the code.
The omniscient need to define ownership across a code base seems to make it easy to introduce high coupling, which is unavoidable unless you start using shared_ptr/RC all over the place.
Rust improves quickly so I don’t think we should discount it, but I wish Rust folks would address these concerns when talking about how Rust is going to take over $x domain.