9 ms·
This Week in Rust
- bjz_ 13y ago> 89 pull requests were merged this week. This is the most pull requests merged in a week, ever. The activity of this community never ceases to amaze me. Contributions and improvements are coming in thick and fast, and yet still we still seem to be keeping on top of it. Only 54 PRs are currently open on Github, despite the churn.
- theknown99 13y agoReinventing the first 90% of the wheel is quick. It's that last 10% that takes all the time.
- bjz_ 13y agoIndeed. There is a ton of polish that has to be sunk into the language and the libraries to get them to a state where 1.0 can finally be declared.
- Pacabel 13y agoBut when is that sort of stability going to be achieved by Rust? We keep hearing about how "it's happening" or it'll be there "soon". But yet we still see a language and standard libraries that are evolving significantly on an ongoing basis, breaking existing code along the way. If Rust wants to be a viable option, at some point this indiscriminate change needs to stop. It may mean that this initial version of the language has some flaws, but at least it may also be usable for serious development at that point. The sooner that happens the better. The longer Rust delays stability, the greater traction we see competitors like Go or even existing languages getting. Rust is starting to get a Perl 6-style reputation, where there's great promise and lots of hype, but never a version we can confidently use for software that's remotely serious.
- heydenberk 13y agoThere are already a lot of programming languages that made it to x.0 without making all the breaking changes they should have, leaving warts all over the language and the standard libraries. The fact that Rust is still making lots of breaking changes is good, IMO. They seem very cognizant of the fact that they should make all the breaking changes they can while they still can.
- Pxtl 13y agoAbsolutely. I'd hate to see Rust go through a Python 3 debacle, or deal with the .NET approach where half the framework libs are completely superseded by new libs in every major release.
- Pacabel 13y agoPython 3 wasn't a "debacle" in any sense. In fact, it has proven to be an excellent approach. Users with large Python 2.x code bases haven't experienced any disruption. Users who needed Python 3's features were free to upgrade as soon as they wanted. Libraries and frameworks have gotten Python 3 support when it becomes feasible and worthwhile to do so. It may not be the fastest adoption possible, but it has been quite pain-free, and totally optional for those who have no need for it. Besides, Rust should be happy to get anywhere near the number of users that Python and .NET have. That surely won't happen until there's a version of Rust that's stable for more than a couple of months. And what makes you think that Rust still won't end up in a situation where some desired future functionality requires backward compatibility to be broken, regardless of how much effort they put in now?
- pcwalton 13y ago> Python 3 wasn't a "debacle" in any sense. In fact, it has proven to be an excellent approach. That's… not an opinion shared by anyone else I've heard of. Python 3 has been a disaster, mainly because it didn't offer enough of a reason for users to upgrade. In other words, Python's so entrenched that Python 2's warts are effectively staying with the language forever. That is hurting every user of the Python language, and is actually an argument for fixing Rust's flaws now, while we still have a chance to. > Besides, Rust should be happy to get anywhere near the number of users that Python and .NET have. That surely won't happen until there's a version of Rust that's stable for more than a couple of months. We explicitly don't want so many users right now that we can't break things. That's not to say we don't want users—we do, of course—but we need them to know that the language will be unstable until 1.0. > And what makes you think that Rust still won't end up in a situation where some desired future functionality requires backward compatibility to be broken, regardless of how much effort they put in now? You're arguing that we shouldn't bother fixing anything because Rust will not be perfect. Yet in many of your other comments you criticize the Web stack for its lack of forward thinking design in many areas. Do you see the cognitive dissonance here? The time to fix things that can't be fixed later is now. Just because Rust will not be perfect at 1.0, and there will be things we wish we could have changed, doesn't mean we shouldn't do the best we can.
- ilaksh 13y agoI am not associated with nimrod in any way, just an enthusiastic new user. Before I found out about nimrod I thought Rust was the best new language.
- Ygg2 13y agoWhat does this have to do with Rust?! Especially to the This week in Rust column?
- coldtea 13y agoIt's about putting Rust in perspective and learning about alternatives. The same way when a critic reviews a movie, he also mentions and compares to other movies.
- Ygg2 13y agoEh? It doesn't do that. It doesn't provide any context or assertions why one is better over the other. It comes of as a way to market a different language in a thread about Rust. Here is example how I see OP in lieu of your analogy: "I liked movie Gravity until I watched movie Her ..." and continues to ramble about movie Her.
- dbaupp 13y agoWell, it'd be more accurate to not even have the "...", given the original comment.
- bjz_ 13y agoNimrod, like D, does great things in terms of metaprogramming and static code generation whilst providing a GC that abstracts away from memory management. Rust on the other hand thrusts memory management into the programmers face, excelling at providing safe, deterministic control over allocation and a relatively advanced type system compared to the incumbent systems programming languages. Nimrod and D seem like worthy alternatives to Go and C#, where as Rust is providing a much needed alternative to the venerable C and C++ languages that have dominated systems progamming for the last forty years. It seems to me like a marketing failure that Nimrod and D seem to be attempting to go after the low level systems programming domains when they should really be competing at a higher level of abstraction.
- gmjosack 13y agoI've been learning Rust lately and people like cmr and the rest of the guys over at #rust have been super helpful. While Rust is moving fast the This Week in Rust posts make it very easy to keep up. Overall I'm loving the language and the community and can't wait to see more wide adoption.
- sanderjd 13y agoTheir IRC room is the best I've lurked / asked questions in. They frequently discuss way-over-my-head language design proposals and even more frequently answer noob questions in a friendly and patient manner. It's a great community, and I hope it stays that way!
- vanderZwan 13y agoThat looks like quite a list of breaking changes (although I don't know how much real code is affected). I guess that's good in the sense of being willing to fix things. Does the Rust community have a gofix-like tool to keep up with this?
- dbaupp 13y agoNope; just the IRC channel, these newsletters and http://www.rust-ci.org/ http://www.rust-ci.org/ to inform people when things break (it triggers Travis CI builds each day, when a new nightly package is built). The language moves too fast for maintaining a gofix tool to be feasible or a productive use of time (IMO much better to spend all the effort on getting the language nicer and nicer as fast as possible).
- bjz_ 13y agoWell, the language is still pre-1.0. It is better to fix things now than be stuck with supporting poor design decisions years into the future. The good thing is that the semantic changes to the language have decreased significantly over the past year, and feature flags are now provided to force users to opt-in to experimental parts of the language. Much of the churn is is now on the library front. There is no gofix tool, but you can use http://rust-ci.org/ http://rust-ci.org/ to get immediate feedback when things break.
- coldtea 13y agoI don't know about the gofix tool, but I sure believe the language needs a standard gofmt tool before it's 1.0. It saves the Go community so much bikeshedding and BS, and I've never seen anyone (except an insignificant minority bent on "freedom of expression" on their brace style) not like it.
- Ygg2 13y agoThat's a moot point. Many languages go without any kind of formatting tools. I definitely think a format and test coverage tools are HUGE productivity boosts, but I don't think it's time to spend on them when things like DateTime are still missing from language.
- shadowmint 13y agoHmm... is the removal of std::to_bytes something that's been pending for a while? The commit (https://github.com/mozilla/rust/commit/efaf4db24c92e119e26dc575ffd6bfd3b91fb87d https://github.com/mozilla/rust/commit/efaf4db24c92e119e26dc...) is recent and it breaks a bunch of libraries (eg rust-sdl2). Feels like it deserves a mention.
- dbaupp 13y agoThat commit is "just" clean-up after https://github.com/mozilla/rust/pull/11863 https://github.com/mozilla/rust/pull/11863 But yeah, probably worth an explicit mention.
- kzrdude 13y agoyes, to_bytes was just a feeder into the hashing system and it was known to need refactoring for a long time.
- erickt 13y agoYep, you are right. I just mailed rust-dev an announcement of the new Hash framework: https://mail.mozilla.org/pipermail/rust-dev/2014-February/008766.html https://mail.mozilla.org/pipermail/rust-dev/2014-February/00...
- drbawb 13y agoFYI I've got a pull request pending[0] that fixes the `rust-sdl2` breakage :) [0]: https://github.com/AngryLawyer/rust-sdl2/pull/46 https://github.com/AngryLawyer/rust-sdl2/pull/46
- moron4hire 13y agoThe progress being made on Rust is amazing. I'm not sure I've ever seen a language developed in such earnest before. The tutorial on rust-lang.org is pretty good, but I find myself confused about the exact nature of the utility of some of the features. The Linked List example is certainly better than any old Foo/Bar/Baz one, but it's still pretty limited. Are there any suggestions for existing Rust applications that can be read to get a better handle of how the language is intended to be used "in the wild"? It'd be great if there were, say, a CRUD website, or a user-options config GUI utility, something really basic that does stupidly simple work of a non-trivial nature. I feel like the added overhead of learning how compilers in general are supposed to be designed would make reading the Rust compiler source anti-productive.
- Codas 13y agoThe rust compiler itself would certainly not be the best resource, but I thing servo[1] would do just fine. Also, you can just look at some rust repositories[2] on github. [1]: https://github.com/mozilla/servo/ https://github.com/mozilla/servo/ [2]: https://github.com/trending?l=rust https://github.com/trending?l=rust
- sanderjd 13y agoThis is a few entries down in the trending list you linked, but rust-http[1] is currently my favorite example of a very non-trivial and actively developed rust library. 1: https://github.com/chris-morgan/rust-http https://github.com/chris-morgan/rust-http
- namelezz 13y agoWhat kind of problems are Rust trying to address?