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

171–180 of 274 posts

Re: Rust's 2017 Roadmap

#171

Post by steveklabnik »

gphilip wrote: post #163
steveklabnik wrote: post #161

Earlier quoted context omitted.

> Can you tell me what it means to search for 'line' or 'lines' in rustdoc? Rustdoc has a search bar at the top. with 'line' it's the third result, 'lines' is the first https://doc.rust-lang.org/stable/std/?search=lines and the short description makes it clear that the first two results are irrelevant in this case. > It would be great to have an offline way to search Rust documentation and examples, It all works offl…

> It would be great to have an offline way to search Rust documentation and examples, >> It all works offline. These docs are pre-installed for you when you install Rust, and 'cargo doc' will generate them for your whole project. Not by default, anymore[0], as I found out when I wanted to read the book offline. To set up offline documentation, do: rustup component add rust-docs # One-time thing Now to open the docs i…

Gah, I always forget. I want that switched back.

Re: Rust's 2017 Roadmap

#172

Post by steveklabnik »

rspeer wrote: post #162
steveklabnik wrote: post #161

Earlier quoted context omitted.

> Can you tell me what it means to search for 'line' or 'lines' in rustdoc? Rustdoc has a search bar at the top. with 'line' it's the third result, 'lines' is the first https://doc.rust-lang.org/stable/std/?search=lines and the short description makes it clear that the first two results are irrelevant in this case. > It would be great to have an offline way to search Rust documentation and examples, It all works offl…

> I copy-pasted my search term exactly in the previous post. I'm bringing up a problem with how the language presents itself to beginners, not asking you to solve a specific problem for me. If searching is the answer to everything, then there needs to be a concerted effort to take Google-juice away from bad or deprecated answers. Incidentally, the search result you're describing for "lines" says "An iterator over the…

No no, I very much appreciate it!

I think we have two searches confused. When I meant "my exact query, when we were taking about Google, here: https://news.ycombinator.com/item?id=13585902

I find it interesting that we got different results.

I thought "an iterator over lines" would be enough; maybe not.

Re: Rust's 2017 Roadmap

#173

Post by steveklabnik »

rspeer wrote: post #170
steveklabnik wrote: post #161

Earlier quoted context omitted.

> Can you tell me what it means to search for 'line' or 'lines' in rustdoc? Rustdoc has a search bar at the top. with 'line' it's the third result, 'lines' is the first https://doc.rust-lang.org/stable/std/?search=lines and the short description makes it clear that the first two results are irrelevant in this case. > It would be great to have an offline way to search Rust documentation and examples, It all works offl…

> Rustdoc has a search bar at the top. Let me assure you that I mean only the best for this language and I appreciate your persistent willingness to help, but I want to help debug your use of internal terminology that doesn't help beginners. "rustdoc" is not how you should be telling beginners to look for documentation. As far as I can tell, "rustdoc" is the tool for generating documentation, not searching it. I assu…

As I said in the other thread, I truly appreciate it. :)

Sorry, as I mentioned elsewhere I was in a meeting; I should have just waited to apply to you. It's true that "rustdoc" is overloaded, people use it to mean "rustdoc's output" which would mean the standard library docs in this case. My bad!

Re: Rust's 2017 Roadmap

#175

Post by [deleted] »

carussell wrote: post #139
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…

When I suggested doing this last year[1], it was very well-received. Not sure if the Rust folks ever did it. I'd wager no. 1. https://news.ycombinator.com/item?id=11156266

[deleted]

Re: Rust's 2017 Roadmap

#176

Post by jeffdavis »

lmm wrote: post #95
zyxzkz wrote: post #57

Earlier quoted context omitted.

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

We did. The ML family has been around for about 4 decades now. Not sure why they never caught on until Rust.

It's about the runtime. I think that's probably the most important reason, even more so than memory management or performance.

If you need to write a library to implement the latest protocol, or render the latest image format, or parse the latest serialization format, then Haskell seems great. Unfortunately, the resulting library will be useless except to other Haskell programmers. Nobody wants to link in libXYZ.a and get the entire Haskell runtime, starting threads and doing GC and sending and catching signals.

I tried implementing a handler in postgresql so that you could write user-defined functions in Haskell. I made little progress, even with help on IRC and elsewhere. Any non-trivial function would need to define its own types and use some libraries, but it was far from clear how to do that and the best advice I got was to dig into ghci and try to use some ideas from that. I started down that path, ran into runtime issues, and that was the last straw and I ran out of steam. And that was only to get the most basic functionality: call into haskell to do some computation and return.

Re: Rust's 2017 Roadmap

#177

Post by Ericson2314 »

jeffdavis wrote: post #176
lmm wrote: post #95

Earlier quoted context omitted.

We did. The ML family has been around for about 4 decades now. Not sure why they never caught on until Rust.

It's about the runtime. I think that's probably the most important reason, even more so than memory management or performance. If you need to write a library to implement the latest protocol, or render the latest image format, or parse the latest serialization format, then Haskell seems great. Unfortunately, the resulting library will be useless except to other Haskell programmers. Nobody wants to link in libXYZ.a an…

Honestly for most programmers, no GC is a red herring.

Re: Rust's 2017 Roadmap

#178

Post by Manishearth »

sevensor wrote: post #165
Manishearth wrote: post #71

Earlier quoted context omitted.

Why "weaker guarantees across platforms"? These crates have the same guarantees about platform support. Availability across time is also similar, really.

It speaks to my confusion about the role of these "blessed" crates that I assumed the reason for not including them in the standard library was that they were not supported on all platforms, or that you didn't want to commit to having them in stdlib forever. If neither of these is the reason, and you intend for these crates to persist indefinitely and be available on all supported platforms, surely they belong in the…

The idea is that these can evolve separately from the language; they are not tied to language versions. Contrast that with Python where you have the urllib urllib2 urllib3 issue; with people going and using requests anyway.

There's no inherent reason to put them in the stdlib aside from "other languages do it".

And yeah, folks don't want to commit to sticking them in the stdlib forever. If a better library turns up people can switch to that; without being tied to the language version. These libraries will still be maintained, but may no longer be the recommended way to do things. Being outside the stdlib gives some liquidity to the crate.

Re: Rust's 2017 Roadmap

#179

Post by nostrademons »

Ericson2314 wrote: post #177
jeffdavis wrote: post #176

Earlier quoted context omitted.

It's about the runtime. I think that's probably the most important reason, even more so than memory management or performance. If you need to write a library to implement the latest protocol, or render the latest image format, or parse the latest serialization format, then Haskell seems great. Unfortunately, the resulting library will be useless except to other Haskell programmers. Nobody wants to link in libXYZ.a an…

Honestly for most programmers, no GC is a red herring.

That may be true, but for programmers that can use GC, there are already very good solutions out there.

New products succeed based on how much better they are than the other solutions in their market. Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still beholden to backwards-compatibility, which makes it unable to adopt several of Rust's more interesting features.)

Re: Rust's 2017 Roadmap

#180

Post by pjungwir »

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…

So I'm only a Rust amateur (I mean I don't get paid to use it), but I'm on my third round trying to build something with it, and I feel like I'm finally starting to get it. A couple warts I've encountered:

- No support for default struct fields: https://github.com/rust-lang/rfcs/issues/1594

- Terrible signatures for functions that return iterators: https://www.reddit.com/r/rust/comments/2h26cj/functions_retu...

If the next push is going to be for ease-of-use, those would be two nice things to fix.

Post reply on HN