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

81–90 of 274 posts

Re: Rust's 2017 Roadmap

#81

Post by steveklabnik »

nitrogen wrote: post #77
ice109 wrote: post #67

Earlier quoted context omitted.

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.

In this case, it wasn't so much "deliberate hooks" as it is "I took a lot of care to not do this, but then when pull requests came in to add things that were left out, sometimes they introduced forward references that we didn't realize at the time."

Re: Rust's 2017 Roadmap

#82

Post by vertex-four »

XorNot wrote: post #14
Manishearth wrote: post #6

Earlier quoted context omitted.

Any particular reason rng must be in the stdlib? It's an "official" crate, maintained by the Rust developers. In general Rust tries to keep things out of its stdlib instead opting for crates. It lets these evolve independently of the stdlib (not tied to rustc releases), and also lets them have their own versioning (none of that urllib2 urllib3 nonsense)

I would say random numbers are a fairly core programming construct for a standard library. They're important, difficult to get right, and have huge implications if you get them wrong.

So's encryption, possibly moreso, and yet that probably shouldn't be in the standard library.

Re: Rust's 2017 Roadmap

#83

Post by tormeh »

I once said that Rust would never become really, Java-level, popular. Mostly because I thought it focused too much on performance to the detriment of elegance and productivity. I'm not so sure anymore. This is a step in the right direction. That said, what makes me most nervous about Rust is pointers and mutability being mandatory for certain things, rather than the absence of books. Maybe that's just me, though. Anyway, in my opinion, pointers and mutability should be something I think about once I'm optimizing the program, not something I do while figuring out the logic. As long as copying everything every time fits in my compute budget I don't get why I should be forced by the stdlib to do otherwise.

Anyway, huge fan of what the Rust devs are doing. It's truly awesome.

Re: Rust's 2017 Roadmap

#84

Post by yarper »

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…

Why not use Iron or Nickel?

Re: Rust's 2017 Roadmap

#85

Post by steveklabnik »

yarper wrote: post #84
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…

Why not use Iron or Nickel?

They don't have support for async IO yet; this is using hyper master.

Re: Rust's 2017 Roadmap

#86

Post by [deleted] »

Animats wrote: 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.

[deleted]

Re: Rust's 2017 Roadmap

#87

Post by jamwt »

gcp wrote: post #58
jamwt wrote: post #50

Earlier quoted context omitted.

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.

I'm not saying unproductive. I'm saying, we need to be realistic. Compared to, say, Python, it's nowhere close.

Compared to C++, Java, or even Go, it's anywhere from competitive to significantly better.

Re: Rust's 2017 Roadmap

#88

Post by ainar-g »

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

Earlier quoted context omitted.

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. htt…

Wow, thanks for the reply. I copied the signature directly from your post and... it didn't work. I still got `user_index_handler` does not live long enough. But! If I replace

    impl server::Handler for UserIndexHandler
with

    impl UserIndexHandler
it does compile. Removing the trait impl was another thing recommended by the Arc guy at work, he didn't know how or why it worked. Here is the code that doesn't compile with updated Postgres: https://is.gd/fjYDIG.

Which brings me to a question, how does implementing a trait prevent this code from compiling? Sorry for comparing apples to oranges again, but in Go implementing an interface is an invisible operation, that doesn't affect compilation. What's different with Rust?

Re: Rust's 2017 Roadmap

#89

Post by mdzn »

tormeh wrote: post #83

I once said that Rust would never become really, Java-level, popular. Mostly because I thought it focused too much on performance to the detriment of elegance and productivity. I'm not so sure anymore. This is a step in the right direction. That said, what makes me most nervous about Rust is pointers and mutability being mandatory for certain things, rather than the absence of books. Maybe that's just me, though. Any…

References (lifetimes and borrow checking) and mutability are there for safety, not speed.

Re: Rust's 2017 Roadmap

#90

Post by yarper »

steveklabnik wrote: post #85
yarper wrote: post #84

Earlier quoted context omitted.

Why not use Iron or Nickel?

They don't have support for async IO yet; this is using hyper master.

getting a bit off topic now - but I'm curious as to if async/io has improved performance by much? Do you have any benchmark comparisons?
Post reply on HN