Rust's 2017 Roadmap • Hacker News Board

Re: Rust's 2017 Roadmap

#151

Post by rspeer » Tue, Feb 07, 2017, 12:58 AM UTC

steveklabnik wrote: post #149

rspeer wrote: post #143

Earlier quoted context omitted.

Another wart (in a separate post from my other wart so that replies are coherent): I understand why &str and String are different, but why do they act like they've never heard of each other? Why do they implement such different sets of methods? Why can't they be compared for equality, so I don't always have to type "literal".to_string()? Haskell has problems with too many string types as well (worse than Rust, becaus…

> Why do they implement such different sets of methods? String gets all relevant str methods from Deref; it has some additional methods, but it should largely be shared. > Why can't they be compared for equality, Hm? They both compare just fine with ==.

I mean, if I have a method foo() that returns a String, as many methods do, why can't I check if foo() == "bar"? Why do I have to check foo() == "bar".to_string()?

Re: Rust's 2017 Roadmap

#152

Post by dripton » Tue, Feb 07, 2017, 12:58 AM UTC

douche wrote: post #141

rspeer wrote: post #140

Earlier quoted context omitted.

Here's a wart. Why is reading lines from a file so hard? It's one of the first things people are going to need to do in a programming language. On top of handling errors (which I understand is necessary, and which the ? operator makes easier), it requires importing BufReader and BufRead, and wrapping a reference to a file handle in BufReader. Nobody is going to know how to do this unless they come across it in Rust B…

That's a good point. It's slightly reminiscent of Haskell, where you have to start trying to understand the IO monad and do notation to do the most trivial real-world examples. In other languages, you might do File.ReadAllLines("foo.txt"), and bam, you're done.

Unless foo.txt is too big, in which case, bam, out of memory.

Re: Rust's 2017 Roadmap

#153

Post by stusmall » Tue, Feb 07, 2017, 1:02 AM UTC

anamoulous wrote: post #137

stusmall wrote: post #102

Earlier quoted context omitted.

I've been getting early release PDFs of this book for a while now. I highly suggest it for moving from beginner to getting serious. I still think the Rust book is a better first read, but this is much more in depth and detailed. One of the sections that was most useful to me was comparing how memory is laid out in a few different languages with a few different concrete code examples. These comparisons really helped m…

Did you pre-order the print book? Does that get you early access PDFs? Or does O'Reilly charge separately for the PDF and print?

I didn't pre-order the print, I just ordered the PDF version. If I remember correctly the print order didn't come with the PDF, but you get a discount if you get both. I'd check the site for details since this was getting on a year ago and my memory is poor.

Re: Rust's 2017 Roadmap

#154

Post by rspeer » Tue, Feb 07, 2017, 1:05 AM UTC

dripton wrote: post #152

douche wrote: post #141

Earlier quoted context omitted.

That's a good point. It's slightly reminiscent of Haskell, where you have to start trying to understand the IO monad and do notation to do the most trivial real-world examples. In other languages, you might do File.ReadAllLines("foo.txt"), and bam, you're done.

Unless foo.txt is too big, in which case, bam, out of memory.

Iterators exist.

Re: Rust's 2017 Roadmap

#155

Post by dbaupp » Tue, Feb 07, 2017, 1:07 AM UTC

rspeer wrote: post #151

steveklabnik wrote: post #149

Earlier quoted context omitted.

> Why do they implement such different sets of methods? String gets all relevant str methods from Deref; it has some additional methods, but it should largely be shared. > Why can't they be compared for equality, Hm? They both compare just fine with ==.

I mean, if I have a method foo() that returns a String, as many methods do, why can't I check if foo() == "bar"? Why do I have to check foo() == "bar".to_string()?

String == &str works. Maybe you were encountering some other problem.

Re: Rust's 2017 Roadmap

#156

Post by rspeer » Tue, Feb 07, 2017, 1:09 AM UTC

steveklabnik wrote: post #150

rspeer wrote: post #148

Earlier quoted context omitted.

It would be silly and wasteful to read the whole file into memory just so I can iterate its lines. I'm not sure why that's an option you'd need to accomodate. However, many languages make a reasonable assumption that you can afford to fit each line in memory, and provide an obvious way to do this.

> I'm not sure why that's an option you'd need to accomodate. Again, it's about control. Maybe you're only loading a small configuration file, and so fetching it all in one go is better than dealing with a buffer. > an obvious way to do this. If you search for 'line' or 'lines' in rustdoc, the correct thing is right near the top, which will show you how to use it with BufRead.

> Maybe you're only loading a small configuration file, and so fetching it all in one go is better than dealing with a buffer.

If it's small, it can't be that much worse to buffer. What's wrong with reasonable defaults?

Can you tell me what it means to search for 'line' or 'lines' in rustdoc? Is this a command-line tool? I'm aware of the 'rustdoc' that generates documentation, but not of anything by that name that searches documentation, and Googling isn't turning up much of anything except the Rust book here.

It would be great to have an offline way to search Rust documentation and examples, as things like this make it very hard to write Rust on a plane, for example.

Googling often gives answers that are wrong or pre-1.0. You seem to have better luck at searching for the right things, perhaps because you are an expert in the language and know exactly what to search for.

(Amusing related anecdote: I googled for "how to return self in rust" and got a suicide prevention website. Jeez, Google, it's not that bad.)

Re: Rust's 2017 Roadmap

#157

Post by dbaupp » Tue, Feb 07, 2017, 1:09 AM UTC

munin wrote: post #120

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.

Memory management? Every ML implementation I know about uses GC, which is frequently just too slow. Along with many other reasons ( http://www.podval.org/~sds/ocaml-sucks.html )

In the context of this discussion, a lot of those reasons are... idiosyncratic, and/or apply to Rust too.

Re: Rust's 2017 Roadmap

#158

Post by Manishearth » Tue, Feb 07, 2017, 1:12 AM UTC

1wd wrote: post #112

Manishearth wrote: post #104

Earlier quoted context omitted.

Most of these are true for rand. It's in the nursery so it might (probably not though) be deprecated in favor of a different library, but it would continue to work because Rust is backwards compatible. https://github.com/rust-lang/rfcs/blob/master/text/1242-rust... has some of the motivation behind this.

Thanks, but I still don't see where such guarantees are advertised. Also it's not really clear what "the nursery" is exactly. Where is it? Why is it called that? It sounds more like "not mature = ready for prime time = don't use this". According to that link, regex is also in the nursery. According to crates.io, regex depends on other crates maintained elsewhere, by a "random" single developer, under a different lice…

Crates.io lists the authors as "The Rust Project Developers", and has the Rust libs team as an owner. The dependencies are almost all maintained by Rust libs team members or are otherwise trusted crates.

https://crates.io/crates/regex

(Regex moved out of the nursery a while back)

The nursery is more of a "These crates are officially blessed and we wish to make them part of rust-lang, unless the community comes up with something better".

The guarantees aren't advertised, they're known. We can do a better job of advertising this, some of the work this year is related to that.

Re: Rust's 2017 Roadmap

#159

Post by steveklabnik » Tue, Feb 07, 2017, 1:13 AM UTC

rspeer wrote: post #151

steveklabnik wrote: post #149

Earlier quoted context omitted.

> Why do they implement such different sets of methods? String gets all relevant str methods from Deref; it has some additional methods, but it should largely be shared. > Why can't they be compared for equality, Hm? They both compare just fine with ==.

I mean, if I have a method foo() that returns a String, as many methods do, why can't I check if foo() == "bar"? Why do I have to check foo() == "bar".to_string()?

Works just fine here: https://play.rust-lang.org/?gist=5a3228a1d42d81690458337eb77...

Maybe you were running into something else?

Re: Rust's 2017 Roadmap

#160

Post by rspeer » Tue, Feb 07, 2017, 1:13 AM UTC

dbaupp wrote: post #155

rspeer wrote: post #151

Earlier quoted context omitted.

I mean, if I have a method foo() that returns a String, as many methods do, why can't I check if foo() == "bar"? Why do I have to check foo() == "bar".to_string()?

String == &str works. Maybe you were encountering some other problem.

Oh, I guess the case of this I encountered most recently was actually Option == Option.

I get why that's different, but it would be great if the type system could figure that out, so that the literal Some("foo") could be an Option if necessary. Maybe I'm still being spoiled by Haskell's OverloadedStrings.