Live data from Hacker News

Rust's 2017 Roadmap

blog.rust-lang.org

41–50 of 274 posts

Re: Rust's 2017 Roadmap

#41
post #26

Does the "lower learning curve" goal include the lowering of learning curve for people who already know how to program? Because right now, the Book sometimes seems like it's aimed for people who either didn't program a lot, or didn't program in a language with types. What I actually would like is a few "Books" like "Rust for C++ people", "Rust for Go people", etc. Those would describe in many examples how things that…

You will probably like the O' Reilly book. It's a bit closer to "Rust for C++ people", IMHO. I fully agree that more of this kind of thing would be great.

What about the warts part?

Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation team ever had sessions where you just

- take a random C++/Go/Python developer

- ask them to solve a not-too-simple but not-too-hard task, something that'll generally take them less than an hour in their "native" language, in Rust

- look and take notes on their struggle with it

This might shed some light on why people (like me) have so much trouble getting into Rust.

Re: Rust's 2017 Roadmap

#42

Earlier quoted context omitted.

I've used VSCode, you have to pick the GNU abi and install a couple plugins but it works reasonably well.

I think VS Code is what the community is rallying around to become the flagship cross-platform Rust IDE, with intellij-rust as the second choice.

I don't really think that's the case. RLS is what everyone is rallying around, and VS Code has good LSP support, so that's where everything will happen initially, but I don't think it's really the "central" IDE that we want everyone to use.

Re: Rust's 2017 Roadmap

#43
post #15

That's a good list. Get the basics right. Rust has been putting much effort into "l33t features" in template land. I fear Rust may be going down the C++/Boost template metaprogramming rathole.

Which features are you thinking of, specifically? We actually just rejected an RFC for one of these features for being too complex, though it isn't a rejection of the feature entirely.

Which one is that?

Re: Rust's 2017 Roadmap

#44
This was ultimately my problem with Rust, and I am really glad this is being addressed directly.

At the end of the day, the primary thing I want from my PL is to boost my productivity. In the kinds of software that I write, I can tolerate bugs and GC. Does Rust actually make me more productive?

Re: Rust's 2017 Roadmap

#45

Earlier quoted context omitted.

I've used VSCode, you have to pick the GNU abi and install a couple plugins but it works reasonably well.

I think VS Code is what the community is rallying around to become the flagship cross-platform Rust IDE, with intellij-rust as the second choice.

I hope not, I really dislike vscode.

Re: Rust's 2017 Roadmap

#46
post #30

Earlier quoted context omitted.

I think VS Code is what the community is rallying around to become the flagship cross-platform Rust IDE, with intellij-rust as the second choice.

Ugh.

Why? Editors like vim and emacs will benefit from the work (Rust Language Server) that is making the VS Code editing environment good for Rust.

Re: Rust's 2017 Roadmap

#47
post #41

Earlier quoted context omitted.

You will probably like the O' Reilly book. It's a bit closer to "Rust for C++ people", IMHO. I fully agree that more of this kind of thing would be great.

What about the warts part? Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation team ever had sessions where you just - take a random C++/Go/Python developer - ask them to solve a not-too-simple but not-too-hard task, something that'll generally take them less than an hour in their "native" language, in Rust - look and take notes on their s…

> What about the warts part?

I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf...

I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things.

More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sample. It's one of the reasons you'll see me pushing for details in Rust threads here, for example.

Re: Rust's 2017 Roadmap

#48

This was ultimately my problem with Rust, and I am really glad this is being addressed directly. At the end of the day, the primary thing I want from my PL is to boost my productivity. In the kinds of software that I write, I can tolerate bugs and GC. Does Rust actually make me more productive?

>I can tolerate bugs

You might want to rewrite that statement. Or at least clarify, what kind of software that you write that can "tolerate bugs" and what kind of bugs you're talking about.

Re: Rust's 2017 Roadmap

#49

Earlier quoted context omitted.

Which features are you thinking of, specifically? We actually just rejected an RFC for one of these features for being too complex, though it isn't a rejection of the feature entirely.

Which one is that?

https://github.com/rust-lang/rfcs/pull/1657#issuecomment-270...

Re: Rust's 2017 Roadmap

#50

This was ultimately my problem with Rust, and I am really glad this is being addressed directly. At the end of the day, the primary thing I want from my PL is to boost my productivity. In the kinds of software that I write, I can tolerate bugs and GC. Does Rust actually make me more productive?

If your primary goal is productivity, I don't think rust will ever be the right language for you.

If you want to remain relatively productive while building things that are one or more of (large, fast, safe), it's an excellent choice.

Post reply on HN