51–60 of 110 posts
Earlier quoted context omitted.
Except the tooling, could be better. A language like Rust will benefit from a rich IDE a lot. But still the language is great.
I'd say the tooling is pretty great only with the exception of an IDE. Debugging, building, testing, packaging all seems pretty well handled.
I'm sorry, but much of Dropbox’s back-end infrastructure is historically written in Python, not Go. Go is a new addition to the stack. Only a small and very specific part of Dropbox is written in Rust, where things like an effectiveness of CPU caches becomes important. Other back-end code is still being written in Go.
One thing I'm really hoping to see happen in Rust is more development to make it more "functional," as in suitable for a functional programming style. It's already so close and, while I don't want to bring up the higher-kinded types discussion, things like stronger support for closures being returned from functions are just not quite there yet for me. I filled out the survey that was sent around and mentioned some of…
I think this ship sailed when Rust removed function purity. Rust is a Scala, not a Haskell.
Earlier quoted context omitted.
I'd say the tooling is pretty great only with the exception of an IDE. Debugging, building, testing, packaging all seems pretty well handled.
> Debugging, building, testing, packaging all seems pretty well handled. 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.
Earlier quoted context omitted.
Specific thought: Trait implementation pages like http://static.rust-lang.org/doc/master/std/collections/hash_... should output the first paragraph of the documentation text. That way you can easily scan/Ctrl+F through the documentation that's right next to the struct you're interested in. Reduce the number of clicks and context switches. It's just a pretty terrifying way to output right now.
Ah, just saw your edit. So, to be clear about what you mean, you want the Iterator implementation to show the summary line on this page? Seems reasonable to me! I filed a bug: https://github.com/rust-lang/rust/issues/33672 (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 :)
> While much of Dropbox’s back-end infrastructure is historically written in Go I'm sorry, but much of Dropbox’s back-end infrastructure is historically written in Python, not Go. Go is a new addition to the stack. Only a small and very specific part of Dropbox is written in Rust, where things like an effectiveness of CPU caches becomes important. Other back-end code is still being written in Go.
While you're right that it's a small and specific part, it's also the core of the whole thing, so it's a very significant part. Dropbox isn't moving away from Go generally any time soon, as far as I know: it's still very much the default.
Earlier quoted context omitted.
Except the tooling, could be better. A language like Rust will benefit from a rich IDE a lot. But still the language is great.
I'd say rustdoc is pretty rough. It's very hard to navigate the rust stdlib vs, say, Go, and when you do find what you want, it's often specified in some very cryptic manner that seems to require a PL PhD. 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/m…
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.
One thing I'm really hoping to see happen in Rust is more development to make it more "functional," as in suitable for a functional programming style. It's already so close and, while I don't want to bring up the higher-kinded types discussion, things like stronger support for closures being returned from functions are just not quite there yet for me. I filled out the survey that was sent around and mentioned some of…
We're in the process of starting up a docs subteam, and one of the things we're interested in is helping the broader ecosystem get better docs. It's also possible that part of my job writing docs will eventually move towards contributing ecosystem docs, but gotta finish up the official distribution first.
Crypto is tough: it's very, very important to get correct. Right now, most projects use wrappers over OpenSSL, but having it all in pure Rust (and maybe some asm where appropriate) is, of course, the dream...
One thing I'm really hoping to see happen in Rust is more development to make it more "functional," as in suitable for a functional programming style. It's already so close and, while I don't want to bring up the higher-kinded types discussion, things like stronger support for closures being returned from functions are just not quite there yet for me. I filled out the survey that was sent around and mentioned some of…
Earlier quoted context omitted.
Rust has been in development for almost a decade at this point; but the language changed significantly many times before 1.0. It's been one year since the 1.0 release, which is the language we know today as "Rust". All those older languages are dead and gone now. I'm actually doing a talk about the ACM's Applicative conference in NYC this year talking about the history of Rust.
For the record, I take issue with the "almost a decade" label, development on Rust didn't start in earnest until 2010 at the earliest. :P It's about as misleading as saying that Go is 40 years old just because its commit graph goes back that far ( https://github.com/golang/go/graphs/contributors ).