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

Rust's 2017 Roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

51–60 of 274 posts

Re: Rust's 2017 Roadmap

#51

Post by moosingin3space »

Manishearth wrote: post #42
moosingin3space wrote: post #12

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.

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.

I stand corrected, however I have started promoting VS Code for Rust because of the LSP support and the promise of RLS, despite being an Emacs user.

Re: Rust's 2017 Roadmap

#52

Post by moosingin3space »

leshow wrote: post #45
moosingin3space wrote: post #12

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.

I hope not, I really dislike vscode.

What do you prefer? With RLS, it will probably be supported.

Re: Rust's 2017 Roadmap

#53

Post by ainar-g »

steveklabnik wrote: post #47
ainar-g wrote: post #41

Earlier quoted context omitted.

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 sampl…

I see. I hope to see more better docs soon. Thank you for answering and for generally being open.

Re: Rust's 2017 Roadmap

#54

Post by Animats »

gcp wrote: post #27
Animats wrote: post #18

Earlier quoted context omitted.

Rust needs a Rust book not written by the Rust developers. "Rust for Dummies", if you will.

There's several external books. I started from this one (via Safari): https://www.amazon.com/Programming-Rust-Fast-Systems-Develop...

"This title has not yet been released."

Re: Rust's 2017 Roadmap

#55

Post by steveklabnik »

kzrdude wrote: post #32
steveklabnik wrote: post #5

Earlier quoted context omitted.

What advantage would putting an RNG into the language do? Are there any languages where an RNG is a language construct?

Relieve crates of version coupling stress. I effectively can't release an 1.0 crate if I have rand as a public dependency; if it has a new major version, I need to have that too to keep in sync and do versioning right. Rand is a vocabulary crate (traits Rng and Rand are used for inter-crate exchange), so it's very sensitive to version coupling.

Interesting, thanks. That does seem valuable; I'm not sure that rand is gonna shoot for a 2.0 any time soon after its 1.0, but that is something being in-tree would prevent.

"vocabulary traits" like this are a good candidate for the stdlib for exactly this reason, maybe a good compromise would be putting _those_ in the stdlib, but leaving the implementation outside.

Re: Rust's 2017 Roadmap

#56

Post by gcp »

Animats wrote: post #54
gcp wrote: post #27

Earlier quoted context omitted.

There's several external books. I started from this one (via Safari): https://www.amazon.com/Programming-Rust-Fast-Systems-Develop...

"This title has not yet been released."

You can get early access to it via various places, e.g. http://shop.oreilly.com/product/0636920040385.do

Re: Rust's 2017 Roadmap

#57

Post by zyxzkz »

moosingin3space wrote: post #9

> fast, reliable, productive--pick three I love it. Short and simple, describes what Rust is. Between that and "an anti-sloppy programming language", pretty sure the marketing is there. Well done community leads, this is exciting.

Man, if developing programming languages was this easy, we should have done it years ago!

Re: Rust's 2017 Roadmap

#58

Post by gcp »

jamwt wrote: post #50
JoelMcCracken wrote: post #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?

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.

I'm not sure. I'm tempted to say I'm about as productive (in orders of magnitude) in any language that I'm very familiar with and has a large enough "batteries included" component (yes, crates would count, as does npm). Even C++ as long as the extras from boost are there.

I can type reasonably correct code much faster than I can reason about how the program should work.

Re: Rust's 2017 Roadmap

#59

Post by gcp »

ainar-g wrote: post #41
steveklabnik wrote: post #31

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…

Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.

Re: Rust's 2017 Roadmap

#60

Post by junk_disposal »

GolDDranks wrote: post #8
DeepYogurt wrote: post #3

Don't change the language to make it easier (unless that can be a free lunch), but get someone doing a "Today in rust" or "Doing X in rust" blog/vlog. Also please get some sort of RNG into the main language (not as a crate).

The Rust's goals of high performance, safety and pay-what-your-use and you-couldn't-hand-code-better won't be sacrificed for sure. The point in ergonomics improvements is to identify "free lunches" that aren't yet taken advantage of. That being said, lifetimes and traits being both complex and unfamiliar features, there's always going to be quite of a learning curve. But one can always reduce the amount of papercuts.…

Can you say that traits are like Go interfaces?
Post reply on HN