Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Mature technologies are proven.
Yes, but somebody had to do the proving. As that great fount of wisdom, John Wooden, once said; when we are young we tend to see all change as progress, but as we mature, we can forget that there is no progress without change. It's not easy to know when you should take on a new technology, but that doesn't mean you shouldn't take on a new technology.
Depends what you mean by resolve. Rust does static checking that data is only owned by one thread at once. If you need shared state then you are back to manual memory management again, as far as I know (Rust is a rapidly moving target so anything I say today might be out of date tomorrow).
Just as an addendum: This is the feature that is missing from all current programming languages that I am familiar with, and the principle reason why threads suck as a general concept. I can't look at any data object and know it's thread ownership. I have to infer that by understanding the rest of the program. This is why we end up with elaborate task based libraries, wrapping threads in "contexts" and being careful not to cross boundaries. What Rust is doing here sounds awesome, but I'd need to try it on some real project to see if it's actually useful. Still I greatly appreciate your critique.
need a-few-milliseconds-or-less pause times
That may as well be an eternity in any hard real-time application, or various finance systems as an example. The point isn't that you can't use Java/.NET in many many applications, it's just that there is a reason why C++ is still necessary for certain situations. This Rust thing looks like a potentially better systems level language (or it want's to be); addressing a number of issues that no language in this same space currently does.
I've never used Rust or even heard of it prior to this article, but your post here makes me hope that it gains mainstream acceptance. Modern Garbage Collectors are fine and work well in a large majority of uses cases but they fall down badly when the majority of your allocations are transitory objects of intermediate lifespan. Objects that last the length of the application run - fine, objects that are created and destroyed quickly - fine, objects that exist for the duration of an async I/O operation? Not fine. The GC becomes a scaleability bottleneck; the parallel processing eventually being throttled by that GC that can only run as a single thread (more or less). So systems that need high performance, large scalability and distributed networking etc are invariably written in C++. But in these C++ systems, ownership design is one of the most vexing issues and must be very carefully considered at all points, without any compiler support. The whole concept of threads and data ownership has exactly zero level built in conceptual support, and that sucks. It sounds as though Rust has been designed to resolve these issues for systems programmers. Which is a great idea.
Your argument here seems to imply that Rust is this great replacement for Java, and then argue why that make no sense. But it seems to me that Rust is really a great replacement for C++, and the kinds of systems that cannot suffer the burden of a GC.