But still the language is great.
It is a really big barrier to adoption because it's very hard to find out what functionality is or is not offered. Here's an example: I want to iterate over a set. Easy, right?
No.
http://static.rust-lang.org/doc/master/std/collections/hash_...
Look at the signature for Cycle. It's really hard to know what this does even though it's trivial:
fn cycle(self) -> Cycle<Self> where Self: Clone
When you click through to the real documentation, it describes a useful use case for this. But that's not how programmers think. They think "I need to do X right now so I'll find something that looks right" not "I'm going to click through the documentation... oh X looks interesting I'll remember that later". There's no way to infer what Cycle really does without having actually clicked through or used it.
Rustdoc isn't perfect, but it's pretty easy to find things imo.
I agree that a summary would be good, but this doesn't require a PL Ph.D. It means "cycle is a method that moves its receiver and returns a Cycle object of the same type of the receiver, and only works if the receiver is cloneable". The trickiest thing here, IMHO, is move semantics, which is something fundamental to Rust in general.
If you've spent more than a cursory time with Rust this is pretty straightforward.
You'd represent this in Java(minus move semantics, because Java has nothing like that) via:
class IntoIter {
public Cycle<T extends Clone> { ... }
...
}
I think the point still holds. Maybe just not for that one.
I guess I've just had a different experience. I come from almost no PL/ML background and I've found the Iterator interface in Rust(along with Option/Result) to be some of the most impressive, clear things about the language.
This kind of thing seems silly to experts but could raise the rate at which folks make it through language learning funnel.
> I want to iterate over a set. Easy, right?
yes, it is easy, `for value in &set {}`. Not sure why you went all the way down to `Cycle`
In this case I agree that perhaps rustdoc should note that a full description should be alluded to (the full description of Cycle is on the Iterator trait's docs), but it's still IMO much better than go
It's just a pretty terrifying way to output right now.
(Also, that page is a bit sparse because I haven't gotten around to writing any docs for it yet, so it's just the autogenerated stuff.)
Thanks for the bug ticket :)
I tried to pickup Rust, but I was super frustrated by the code/compile/run cycle with the current plugin. But, hopefully more users will make that better.
To clarify: I'm not author of this plugin.
And I tried Racer with Microsoft Visual Code plugin - it works without any lags, very fast. Just fails sometimes :)
I agree however that it would be nice to have ie lifetimes visualized and stuff like that, hopefully sometime soon...
Eh, debugging is a mess, at least on OS X. Rust advertises LLDB support, but it seems semi-broken. Listing source is non-functional and just setting a break-point requires a lot of hand-holding.
$ cat hello.rs
fn main() {
println!("Hello world!");
}
$ lldb -v
lldb-350.0.21.9
$ uname -a
Darwin mycomp 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
$ rustc --version
rustc 1.8.0
$ rustc -g hello.rs
$ ./hello
Hello world!
$ lldb hello
(lldb) target create "hello"
Current executable set to 'hello' (x86_64).
(lldb) source list
(lldb)
(lldb) b 2
error: No selected frame to use to find the default file.
error: No file supplied and no default file available.
I'll copy and past this into a Github issue when I have a sec.
To be extra clear, a crate is the unit of compilation in Rust, so changing your code means that the whole crate it's in needs recompiled; your dependencies won't be. Or, if your project is split up into multiple crates, the other ones won't. Incremental recompilation will reduce this level of granularity such that the whole crate won't need to be recompiled.
I think we are likely to see better incremental support with the recent development of MIR, but I'm not sure what the current plans are. Should help tooling around the language generally!
I just found this link[1] for a pretty complete Emacs IDE-like setup the other day. I'm not a Rust programmer, but it seemed promising enough that it made me want to give it a spin.
[1] http://julienblanchard.com/2016/fancy-rust-development-with-...
I'm actually doing a talk about the ACM's Applicative conference in NYC this year talking about the history of Rust.
No one would say those commits show he was working on Go as a "personal project" during that time.
No, it won't. Rust has been stable since 1.0, as the article itself mentions.
One of the big advantages of Go is that it comes with a coherent set of libraries from a single source (Google) that do most of the things you'd want to do on a server. Rust is more like Python; many people write libraries, many of which overlap and some of which work.
But I do want to emphasize that Rust libraries follow semver, and the lock features of Cargo mean that your builds are always reproducible and you upgrade only when you want to. Your code will never stop compiling one day just because some library "churned".
Odd comparison, Python actually has quite a comprehensive, well used standard library, which usually gives you enough to get going.
Using NodeJS as an example would've made more sense, where most libraries/modules are user written.
If it is true, please file bugs. We do our best not to break people's stuff, going to pretty extreme lengths compared to many other ecosystems.