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

71–80 of 274 posts

Re: Rust's 2017 Roadmap

#71

Post by Manishearth »

sevensor wrote: post #66
Manishearth wrote: post #35

Earlier quoted context omitted.

This doesn't answer my question, though. Most of the "fairly core programming constructs" are not in the stdlib for Rust (like regexes) The Rust stdlib is mostly core abstractions and platform-dependent stuff. Given that, why should they be in the stdlib? The rand crate is officially blessed and the one everyone uses.

In that case, it sounds like "officially blessed crates" are a second-level stdlib with weaker guarantees about availability across time and across platforms. I'm fine with that idea, but from my outside perspective this is a confused message. Better to call the blessed crates "stdlib extensions" or something like that.

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

Re: Rust's 2017 Roadmap

#72

Post by ainar-g »

steveklabnik wrote: post #69
ainar-g wrote: post #65

Earlier quoted context omitted.

This was a few months ago, so I had to dig up some code: https://is.gd/kQJ7nv Basically, I tried to create a very basic HTTP server the way I would in Go, but I kept getting all sorts of lifetime errors and kept adding stuff go get away from them. So the code has issues, lots of them. Arc > was recommended by a guy at the job, I don't even know why I need an Arc here, for example. The compiler says consider using an…

This issue is a little bit too much in the weeds (and I'm not sure what version of Hyper you were using, it's had some big releases lately) but if you're curious, I recently implemented a basic HTTP service with a router. I still have some cleaning up to do, but https://github.com/rust-lang-nursery/thanks is the repo, and the code similar to yours is https://github.com/rust-lang-nursery/thanks/tree/master/http is the…

I've actually got that error with 1.15 as well. Or by "recently" you meant "on the nightly"? I updated hyper to 0.10.4, but the issue is still there.

I will check your example app out (thanks for that!) but the problem in my code still remains and I hate the fact that I can't understand what's going on. That might be my biggest issue with Rust compared to Go. Something doesn't match and I don't know how to find the issue without going to IRC or /r/rust; with Go I've never had an issue that wasn't resolved by carefully reading the language/library docs or StackOverflow.

Re: Rust's 2017 Roadmap

#73

Post by dbaupp »

Animats wrote: post #18
adamnemecek wrote: post #13

> Plans include a new book, You should consider publishing an official, printed book. I would totally pay $30-40 for something like this. And once it's already written, the actual publishing shouldn't be too time consuming (but idk lol). I think that there's a lot of people who'd buy it just to support the project. On one hand, I do have environmental concerns, but on the other hand, I feel like my retention rate wit…

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

Why couldn't Rust's developers write "Rust for Dummies"? I feel like you're connecting dots that aren't actually connected. Obviously having more books from different authors/perspectives is great for Rust, but I don't see, prima facie, why a non-Rust-developer author would do a better job of "Rust for Dummies" than a Rust developer.

For one, I would be surprised if a non-"expert" (which is, I presume, why you're so dismissive of Rust developers) could write a book that gives an accurate/useful mental model of Rust: teaching is the true test of one's knowledge about anything. Additionally, people paid to work on Rust and on Rust documentation/teaching materials (i.e. "Rust developers") are the people most regularly interacting with all sorts of beginners, and thus are likely to have great insight into, for instance, the common difficulties people hit, rather than just anecdoata about their own personal experience/background (which is good too, but is only one point of reference for things that people find hard).

Rust developers can write beginners books (indeed, the Rust book is designed to be this, and the second edition succeeds better the first, I've heard) just as much as non-Rust-developers can write expert books.

Re: Rust's 2017 Roadmap

#74

Post by loeg »

It's good to see incremental builds and async socket support (select/kevent/epoll) on the map. Those are essential to the kind of software I work on in C.

Re: Rust's 2017 Roadmap

#75

Post by steveklabnik »

ainar-g wrote: post #72
steveklabnik wrote: post #69

Earlier quoted context omitted.

This issue is a little bit too much in the weeds (and I'm not sure what version of Hyper you were using, it's had some big releases lately) but if you're curious, I recently implemented a basic HTTP service with a router. I still have some cleaning up to do, but https://github.com/rust-lang-nursery/thanks is the repo, and the code similar to yours is https://github.com/rust-lang-nursery/thanks/tree/master/http is the…

I've actually got that error with 1.15 as well. Or by "recently" you meant "on the nightly"? I updated hyper to 0.10.4, but the issue is still there. I will check your example app out (thanks for that!) but the problem in my code still remains and I hate the fact that I can't understand what's going on. That might be my biggest issue with Rust compared to Go. Something doesn't match and I don't know how to find the i…

> Or by "recently" you meant "on the nightly"?

Yeah, it was removed literally last week, so it hasn't made it into a release yet.

Without knowing what version of postgres you're using, I can't _totally_ get this to compile, it complains that SslMode isn't there. But, I did fix your issue:

  fn handle(&self, req: server::Request, mut res: server::Response)
This compiles for me.

The issue here is lifetime elision. http://rust-lang.github.io/book/ch10-03-lifetime-syntax.html...

Specifically, rule 3:

> If there are multiple input lifetime parameters, but one of them is &self or &mut self, then the lifetime of self is the lifetime assigned to all output lifetime parameters.

So here, Request and Response both have lifetime parameters. This means that your original signature is the same as

  fn handle(&'a self, req: server::Request, mut res: server::Response)
Which says "when I call handle, I borrow myself for as long as request and response are borrowed." That won't work; user_index_handler only lives for the duration of the call.

The fixed signature says

  fn handle(&self, req: server::Request, mut res: server::Response)
"When I call handle, the request and response share one lifetime, and request also has another lifetime."

You're no longer connecting &self to the request and response, and so things are just fine.

Honestly, this isn't the simplest signature; it's not surprising that you got stuck. This is also what people mean when they say "I fought with the borrow checker for a while, but then got over it", as it took me less time to fix this error than to write out this comment explaining how to! But until you've got that intuition and understanding, it can feel like hitting a brick wall.

Re: Rust's 2017 Roadmap

#76

Post by yarper »

ainar-g wrote: post #65
gcp wrote: post #59

Earlier quoted context omitted.

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.

This was a few months ago, so I had to dig up some code: https://is.gd/kQJ7nv Basically, I tried to create a very basic HTTP server the way I would in Go, but I kept getting all sorts of lifetime errors and kept adding stuff go get away from them. So the code has issues, lots of them. Arc > was recommended by a guy at the job, I don't even know why I need an Arc here, for example. The compiler says consider using an…

https://github.com/ninjabear/nickel-bootstrap

You might be interested in this

Re: Rust's 2017 Roadmap

#77

Post by nitrogen »

ice109 wrote: post #67
leshow wrote: post #33

Earlier quoted context omitted.

Oreilly has an early release available: http://shop.oreilly.com/product/0636920040385.do I have purchased it and it's pretty good. Although it really seems to be geared more towards experienced systems programmers. The online book is much better for beginners, IMO.

I don't agree. the O'Reilly book is much gentler and pedagogically sound. many things in the online book are discussed before being introduced. not so in the O'Reilly book.

I find that I learn better and trust the resource more if earlier lessons have hooks for later topics. It helps my mind piece everything together. But to each their own.

Re: Rust's 2017 Roadmap

#78

Post by steveklabnik »

loeg wrote: post #74

It's good to see incremental builds and async socket support (select/kevent/epoll) on the map. Those are essential to the kind of software I work on in C.

We just hit beta with incremental builds! https://internals.rust-lang.org/t/incremental-compilation-be... Give it a try :)

Re: Rust's 2017 Roadmap

#79

Post by tormeh »

dbaupp wrote: post #73
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.

Why couldn't Rust's developers write "Rust for Dummies"? I feel like you're connecting dots that aren't actually connected. Obviously having more books from different authors/perspectives is great for Rust, but I don't see, prima facie, why a non-Rust-developer author would do a better job of "Rust for Dummies" than a Rust developer. For one, I would be surprised if a non-"expert" (which is, I presume, why you're so…

You're usually best able to explain something just after you learned it yourself. After a while you forget what was difficult about the thing you learned.

A C programmer, a Python programmer and a Java programmer should write the book together, with expert insight from a Rust pro.

Re: Rust's 2017 Roadmap

#80

Post by vertex-four »

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.

Add maintainable to that list. A program where its developers have a fuzzy idea of ownership of data is not in any way maintainable.
Post reply on HN