Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2017 Rust Roadmap

github.com

Post reply on HN
Print view View original

141–150 of 201 posts

Re: 2017 Rust Roadmap

#141

Post by aikah »

pcwalton wrote: post #62
kjksf wrote: post #32

Earlier quoted context omitted.

It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't pai…

> It's also important to note that Go was designed for programmer productivity and Rust wasn't. Rust was absolutely designed for programmer productivity. Source: I was one of the designers. > GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. That's true, it is a productivity boost. But it also has a cost. Rust didn't want to pay that cost, especially when…

> Rust was absolutely designed for programmer productivity. Source: I was one of the designers.

If you mean productivity as "memory safe and no null pointer errors" then Yes, Rust is productive compared to C,C++ or even Go. If you mean productivity as "ease of use" then no, Rust is not easy to learn or to use compared to Go.

Re: 2017 Rust Roadmap

#142

Post by Manishearth »

unfamiliar wrote: post #137

>We asked both current and potential users what most stands in the way of their using Rust, and got some pretty clear answers: >1 in 4: learning curve >1 in 7: lack of libraries >1 in 9: general “maturity” concerns >1 in 19: lack of IDEs (1 in 4 non-users) >1 in 20: compiler performance >None of these obstacles is directly about the core language or std; people are generally happy with what the language offers today.…

Key word is "directly". Of course everything is about the language, eventually. But that doesn't mean that the solution for something exists inside the language. Learning curve can be addressed with docs and diagnostics, for example. Not everything needs to be (or can be, because stability) addressed by the language.

Re: 2017 Rust Roadmap

#143

Post by burntsushi »

bpicolo wrote: post #140
unfamiliar wrote: post #137

>We asked both current and potential users what most stands in the way of their using Rust, and got some pretty clear answers: >1 in 4: learning curve >1 in 7: lack of libraries >1 in 9: general “maturity” concerns >1 in 19: lack of IDEs (1 in 4 non-users) >1 in 20: compiler performance >None of these obstacles is directly about the core language or std; people are generally happy with what the language offers today.…

I also don't think library maturity is necessarily the only problem that makes working with libraries difficult at time. You can get burned pretty easily by someone not having e.g. Send + Sync on an essential library data structure. (Though maybe there's a way around it other than forking?) That metadata ends up being very important

Send + Sync are automatically implemented for a type X if all of X's constituents are also Send + Sync. In practice, this means that unless you're using unsafe code, Cell/RefCell or Rc, then the Right Thing will just happen automatically. If you are using Cell/RefCell/Rc/unsafe, then you need to think carefully about your synchronization story anyway, so it's typically not something you just forget to do.

For more details, see: https://doc.rust-lang.org/std/marker/trait.Sync.html and https://doc.rust-lang.org/std/marker/trait.Send.html

Re: 2017 Rust Roadmap

#144

Post by DennisP »

mitchmindtree wrote: post #55
cmrx64 wrote: post #41

Earlier quoted context omitted.

> > any nontrivial project will make use of unsafe blocks. I don't think that's actually true? Most projects make use of no unsafe outside of stdlib and a handful of crates.io crates.

This has been my experience also. I've written at least 40kloc of rust over the past couple years (including complex graphs with cycles, low-level DSP) and I could probably count the number of unsafe blocks I've needed on one hand. edit: This is not counting FFI though.

How do you handle cycles? I've seen discussions on places like /r/rust where people didn't seem to have any pleasant answers.

Re: 2017 Rust Roadmap

#145

Post by cbreeden »

shadowmint wrote: post #112
bluejekyll wrote: post #46

Earlier quoted context omitted.

Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that. I'm actually not buying…

Claiming that it is less productive when you barely know it isn't fair... I'm really quite familiar with both go and rust, and I can say straight out that go is more productive than rust. ...but because rust is in any way a worse or less productive language (that remains to be seen), but because it has an immature ecosystem with few high quality crates and virtually no tooling. Go has a lot of very polished tooling (…

No sure why you were down-voted, but it probably has something to do with connotation. I agree though -- library maturity, tooling maturity are also very important factors when it comes to productivity. A steep learning curve, however, probably has less to do with productivity and more to do with adoption, which I think is what the parent was trying to get across.

But, of course, adoption rate can indirectly impact library and tooling maturity. :)

Re: 2017 Rust Roadmap

#146

Post by unfamiliar »

gravypod wrote: post #4

> 1 in 19: lack of IDEs (1 in 4 non-users) I expected that to be higher actually, but that's still the only reason I don't use the language. I've come to rely heavily on IDEs. Whether right or not it's a huge factor in my decision to wait for the language.

What kind of IDE support do you typically use that isn't handled by a modern text editor (such as go to definition, variable renaming, find and replace, etc)? I'm starting to use CLion for my C++ work now, because "go to definition" is much more reliable than most editors can manage with C++ code, but I find that most of the fancy refactoring features like extracting functions or subclasses are not used often enough to be really useful.

Re: 2017 Rust Roadmap

#147

Post by MaulingMonkey »

shadowmint wrote: post #118
steveklabnik wrote: post #115

Earlier quoted context omitted.

> You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell... You could say something like "you're effectively saying that there is zero productivity drain from not having features like generics (which Rust currently does have); that's a pretty hard sell... Tooling matters a lot, and that's why we're investing in…

You'd have a much easier time arguing that go not having a package manager makes you less productive compared to cargo (very true); you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity. Can you build something more quickly in go right now, than in rust? For many applications, the answer is, right now: Yes. Building (using the tooling that does…

> you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity.

It doesn't appear you need to write your own AWS client - or at least, not from scratch: https://github.com/rusoto/rusoto

> Perhaps you see a different side to it from where you sit, but I do think #rust suffers from a certain degree of confirmation bias.

From the outsider perspective of one who knows neither Go nor Rust well - Rust seems to acknowledge it has problems and gaps they're working on. Poor IDE support is one close to my heart. Compile times are another. Heck, I'm just rehashing the roadmap, aren't I.

With Go I hear more about how they've intentionally avoided things in the name of simplicity, and having some opinionated stance on having one correct way to do things. I get the impression that Go will never have generics, by design. C# already covers most of the things I'd use Go for pretty well - I don't see much advantage to switching to Go.

Rust, even in it's relatively untooled state, already has me seriously considering trying my hand at nontrivial projects in it. I've been chasing static analysis and appropriate annotations to catch threading bugs, data races, iterator invalidation, potential null derefs, etc. in C++ for some time, to great effect - and who knows how much time saved - in bugs avoided. I'm convinced it's a question of when, not if, I'll try switching over properly.

Re: 2017 Rust Roadmap

#149

Post by dumindunuwan »

leshow wrote: post #52

Awesome. I have used Iron a few times to write small web services, but I can't wait for Rust to really have a strong story for the backend. If that happens it'll be the first language I reach for whenever I need to write a backend. I think it has a lot of great bonuses already. It's language ergonomics are that of a high-level language, yet it is extremely fast, and I can be very confident in my code if it compiles.…

Other than that, if we had some tool inside Rust ecosystem to support server side rendering for frontend, Rust will be the ultimate language of web.

Re: 2017 Rust Roadmap

#150

Post by dumindunuwan »

nrjames wrote: post #7
adamnemecek wrote: post #5

I would also suggest taking a page out of Apple's playbook and providing some official sample apps like https://developer.apple.com/library/content/navigation/#sect... . Reading the books is one thing, but seeing the patterns actually used is another. You don't need as many as Apple, only a couple really, but make sure they are well written and straddle a couple of use cases. And like go crazy with the idioms, I want…

I agree with the example apps. Some annotated source would be great, too. Something similar to the way dc.js annotates this example: https://dc-js.github.io/dc.js/docs/stock.html

+1 for usinf dc.js type examples. I wished many times "Rust by example" could follow this type of detailed explanations and complex examples.
Post reply on HN