3 ms·
For a language that's supposed to have its 1.0 release later this year, these sure sound like pretty significant breaking changes.
by Pacabel 12y ago
For a language that's supposed to have its 1.0 release later this year, these sure sound like pretty significant breaking changes.
- iopq 12y agoWell it can have all the breaking changes it wants, since it's not 1.0 yet. Which is kind of the point - show a unified, logical interface to the programmer that still covers memory safety without mandatory GC, concurrency without data races, speed, functional programming.
- exDM69 12y ago> For a language that's supposed to have its 1.0 release later this year, these sure sound like pretty significant breaking changes. And that is why I think Rust is one of the most exciting new languages out there. They have not been stubbornly sticking to their original plan when they found out that it wasn't really a good idea after all. For example the change from N:M thread scheduling to native threading. The language and the compiler have been serving as pretty nice research vehicles for advancing practical and useful programming language and compiler design.
- Pacabel 12y agoDon't get me wrong, change to make things truly better is probably worth it. But I'm not convinced that's what we're really seeing with Rust any longer. Many of the recent changes seem to be what I'd call "oscillation". So a problem is noted with some specific functionality or feature of an existing programming language. A different approach is initially taken when implementing something similar for Rust. Yet problems are found with this new approach, so a different approach is tried. And problems are found with this, so something else is tried. The matter discussed in the article appears very much to be yet another example of this. Continually searching for some vague "optimal" solution seriously impacts the usability of the language, especially when there might not even be a solution with satisfactory trade-offs. It's disappointing when code written a week ago suddenly needs significant updates due to language and library changes, especially when the language is supposedly "stabilizing". Rust doesn't exist in a bubble. It's facing some stiff competition from languages like C++11, C++14, Go, Scala, and even Java. Maybe they aren't as "perfect" as Rust aims to be, but they offer many of its core benefits, and they let people get work done today, while still undergoing improvement. Rust, on the other hand, appears to be stumbling around, searching in vain for some vague notion of "perfection", while being unusable to real-world developers who need at least some stability.
- sanxiyn 12y agoYou are not convinced, but most Rust users are convinced. I guess time will tell. I started using Rust from Rust 0.5 (December 2012). I saw zero oscillation so far. From what I can see, Rust is converging, rapidly. Consider this: you can observe these at all because Rust is developed in the open. I think you would have similar reaction if you could observe Go development done behind the closed door before the release.
- chrismorgan 12y agoActually, there are a few things in which Rust has recently gone back to old behaviour (though “oscillation” would be a bit strong as a description of it). Nested block comments is one that was removed a year or two back as unnecessary and reinstated a few months ago. I can’t think of any of the bigger ones off the top of my head; calling them oscillations could also be a bit strong too, as they tend to end up subtly different when they come back—different and superior.
- hga 12y agoI think to be "oscillation" they'd have to change their minds three times or more. chrismorgan in this subthread mentions "Nested block comments is one that was removed a year or two back as unnecessary and reinstated a few months ago. That's trying out something both ways, and after experience deciding one is best. That they changed their minds twice just means their initial first cut turned out to be "right" after all. Now, if they're doing X -> Y -> X -> Y that would be cause for concern. I think your concern for "stiff competition" is perhaps overblown, I only see C and C++ as being a real competitor, I don't see Go or anything based on the JVM as being even in the same category, you're a lot further from the metal. Personally, after doing plenty of C++ in the '90s I've decided it's no fun at all (a supremely dangerous language), am defaulting to C at the moment and will at some point decide if Rust meets my requirements and is likely to be viable for a long time. I gather I'm not the only one.
- ben0x539 12y ago> Now, if they're doing X -> Y -> X -> Y that would be cause for concern. and even then I think it would be defensible since different choices for one aspect might make sense given a different rest of the language.
- keeperofdakeys 12y agoMost of the changes that have happened in the last year have been either to simplify the language, or to remove superfluous features. This is a good thing, especially for a language that is carving out a new domain. By the time 1.0 is out, the developers will be confident that the language is good, and they'll be less likely to change it down the line.