is failing in one of my example programs and I don't see this mentioned in the changelog.
Edit: OK, need to add "core::" in front, thanks dbaupp. There's another little Rust 0.5 program I'm trying to unbreak here - suggestions appreciated: https://gist.github.com/graue/5282602
As a haskeller who's now stuck doing mostly nodejs, I've been eagerly watching Rust's development. One thing keeping me from using it is its immaturity and ecosystem. Is there any chance of a rustfix tool, akin to Go's gofix tool, being developed to lower the risk of using Rust today?
I would actually prefer a more general fix tool like Java's Jackpot[1] (now also a part of NetBeans[2]), that would allow automatic upgrade of any API, not just those that are part of the language.
I'm only a big fanboy of Rust, I only have two patches in, and pay more attention than many, but I'm not aware of an existence of rustfix.
Personally, I don't think there's enough code 'in the wild' to justify this at the moment. With Go, Google was putting it into production from the first release, no?
I know its not there, was wondering if there were any plans. Its very much a chicken and the egg issue with "enough code 'in the wild' to justify this"
There's plenty of Rust code out there, even if much of it is in the Rust compiler itself :). I suspect the problem has been that many of the changes have been of a nature that don't make automated fixes easy (or necessarily desirable).
Yeah, it's hard to automate the fixes; most of the things gofix was used for is things like adding semicolons and changing method names. That said, I would definitely welcome a rustfix for the easier changes.
I follow development a bit, but am not yet involved heavily.
From what I gather, one of the goals of a 1.0 release is that any subsequent releases will have enough tooling to painlessly upgrade to a new version. Something like a 'rust fix' command is surely how you'd want to implement that.
Making such a tool shouldn't be enormously painful, given the infrastructure to pretty-print your code exists in the rust compiler.
As an aside, I have been using Go a lot lately, and I have come to really appreciate the clean, simple syntax. (Go isn't pretty, but it's simple and really readable.) With that in mind, I'm a bit apprehensive about the way Rust's syntax has been going, to be honest.
Some of the things I hated about earlier versions have been resolved (such as lower case type names now being mixed case), but there are a lot of lingering stuff that I think make the language needlessly gnarly, in a Perl kind of way. For example, "::" just isn't a very good separator, visually; it litters the code with dots. The semicolon issue still irks me. Overall it's the proliferation of punctuation (the pointer prefixes, -> and =>, the new lifetime-ownership syntax, etc.) I consider problematic. Using underscore_separated_identifiers instead of camelCaseIdentifiers certainly works in Ruby, but Ruby has so little punctuation that it doesn't overwhelm, whereas with Rust it's just one more point off readability.
Looking at parts of the standard lib makes me unsure of whether it's just written in an obscure way (for example, getopts.rs [1]), or this is the way that Rust code will be written. I guess I'm apprehensive because modules that should be "simple" don't look simple, but remind me of unhappy hours spent reading Boost's source code. I know Rust is supposed to be lower-level than Go, but I always hoped that it would balance itself so that high-level stuff would feel appropriately high-level, but you could always dip lower into the metal to get the C-like feel.
Please pardon my wet blanket, the right thing would obviously have been to join rust-dev years ago. I'm still looking forward to doing something in Rust when it's production-ready.
Are you talking about the speed of the compiler itself, or the speed of the code produced by the compiler? If you're talking about the speed of produced code, then I think the compiler is actually fairly decent, since they rely LLVM to optimize the code. Maybe not performance equivalent to C, but still very decent performance.
Speed of the compiler itself. I understand it's not related to the benchmark discussion as such but it's the first thing someone will notice new to rust. Compiling rust itself takes for ages.
Yes, I would like to spend time in the next release cycle working on compiler performance. To start with, I have a patch that improves performance of translation by 15%.
brson and I have been discussing using stage0 LLVM for subsequent stages, so that LLVM itself won't have to be compiled. This should reduce the amount of time required to compile Rust by a lot.
Ouch. Did you run the build with multiple jobs? (Parallel builds have been a bit messed up because of fetching the bootstrap, but you can coax it into working.)
I don't think I've actually tried that, except on my netbook (conclusion: don't try to build Rust on a netbook.) I have made a habit of typing supplying `-j 8` to make. Note: if it hasn't been fixed yet, you'll need to fetch the bootstrap compiler before that will work.
A lot of the changes for 0.6 are removing keywords from the grammar. In this case, the `static` keyword has been removed, so there must be another way to tell if a method is static.
Another reason might be so that self can be passed in a way the programmer prefers. Usually this appears to be `&self`, but it can also be passed in other ways.
Disclaimer: I work for Mozilla on Servo, and am still getting fully up to speed on Rust.
What apprehensions about the MPL do you have? It seems to me you can use MPL (2.0, at least) code in everything from GPL projects to proprietary software.
Disclaimer: I know practically nothing about Rust outside of observing from the HN side lines.
Looking at the change log, it seems that they also removed the "static" keyword, so that class vs member methods are distinguished by the presence of a first argument named self. A little further down, they mention ~self, &self, and @self. Those prefixes differentiate types of special purpose pointers.
So it seems the goal was not explicit self, so much as it was explicit pointer type annotations for self.
The old "self" was a reference type like C++—it behaved like a pointer but wasn't really a pointer (you didn't use * to access it). This was unneeded complexity in the language.
It was also not obvious that the implicit self type was immutable.
Finally, it let us remove "static" in a few places ("static" methods), reducing noise. It makes type implementations (impl Type { ... }) the same as regular modules, except that you can use "&self" and friends to declare methods.
> I'm curious to know the reasoning behind removing the implicit self?
Less confusing for a user of when self is there and when it's not. Now it's always there and you don't have to know what the absence of self would indicate.
