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

91–100 of 274 posts

Re: Rust's 2017 Roadmap

#91

Post by jamwt »

vertex-four wrote: post #80
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.

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

Yep, that's what I meant about "large". If you have a large project, with many developers you're going to want types + generics to maintain it over the many-years and 100,000s to millions of SLOC life.

Re: Rust's 2017 Roadmap

#92

Post by akiselev »

steveklabnik wrote: post #55
kzrdude wrote: post #32

Earlier quoted context omitted.

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.

> "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.

How would this interact with the orphan rule? Wouldnt this mean the vocabulary traits would not have default or std library type implementations and would have to be wrapped in newtypes, defeating the purpose of having them for inter-crate exchange? I guess you could wire types explicitly with Into/From in user code. Are there any traits unimplemented in std now that these vocab traits would look like?

Re: Rust's 2017 Roadmap

#93

Post by steveklabnik »

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

Earlier quoted context omitted.

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

I am about to go into two hours of meetings so this will have to be quick.

The issue is, because this is a trait, you must conform to its signature. Which is here: https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... and specifically https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht...

So yeah, my idea won't work, because those types conflict.

> Removing the trait impl was another thing recommended by the Arc guy at work, he didn't know how or why it worked.

I'm surprised it works on first glance, as I was assuming that you were implementing the trait for a reason, not just because. If you don't need the trait, then yeah, it's much easier.

> What's different with Rust?

See my StackExchange link elsewhere in the thread for a summary.

I'll maybe poke at this after my meetings, or maybe tomorrow. We'll see how amped I am for coding after all that ;)

Re: Rust's 2017 Roadmap

#94

Post by kibwen »

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.

Then see O'Reilly's upcoming "Programming Rust" by Jim Blandy, who, despite working at Mozilla, has never been involved in Rust development, and has long years of experience developing SpiderMonkey, GDB, SVN, GNU Guile, and Emacs. It's still in early access, but 17 out of 20 chapters are available.

http://shop.oreilly.com/product/0636920040385.do

Re: Rust's 2017 Roadmap

#95

Post by lmm »

zyxzkz wrote: post #57
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!

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

Re: Rust's 2017 Roadmap

#96

Post by ainar-g »

steveklabnik wrote: post #93
ainar-g wrote: post #88

Earlier quoted context omitted.

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

I am about to go into two hours of meetings so this will have to be quick. The issue is, because this is a trait, you must conform to its signature. Which is here: https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... and specifically https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... So yeah, my idea won't work, because those types conflict. > Removing the trait impl was another thing recommen…

Okay, thank you again for your time!

Re: Rust's 2017 Roadmap

#97

Post by steveklabnik »

yarper wrote: post #90
steveklabnik wrote: post #85

Earlier quoted context omitted.

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?

http://aturon.github.io/blog/2016/08/11/futures/ is old but has some benchmarks in it; a lot has changed since then, but the blazing speed is still there.

I haven't benchmarked this particular application because I haven't had the time, and it's never going to see particularly higher load.

Re: Rust's 2017 Roadmap

#98

Post by kibwen »

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 always joke String should have been called StrBuf

Agreed, and Vec should just be Buf! Let's fork the language. :)

Re: Rust's 2017 Roadmap

#99

Post by sgentle »

I'm very excited about improvements to the maturity of the Rust library ecosystem. I'm happy with Rust's syntax, the borrow checker doesn't bother me that much, and the build tooling works well (though more speed would definitely help).

What it comes down to again and again with projects I think about using Rust for is "how much extra effort is it going to be compared to a language with good libraries for this?" Often I don't use Rust just because the cost/benefit of having to (re)write code that would otherwise be in a library doesn't make sense.

I'm still bullish on Rust. I know it takes time and it's an unfair competition against the likes of Node and Python (with a zillion library authors), or Go (with a huge company dedicated to a kickass standard library). But nonetheless that's the playing field, and I think a stronger library ecosystem is probably the most important thing for Rust adoption right now.

Well, that and not having to use nightly rust for serde, but you already fixed that.

Re: Rust's 2017 Roadmap

#100

Post by 1wd »

Manishearth wrote: post #71
sevensor wrote: post #66

Earlier quoted context omitted.

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.

In most other programming languages functions in the standard library:

* Are guaranteed to work correctly on all platforms where the language works.

* Will always work with the latest stable release of the language.

* Will be available under one single permissive license (with a single copyright holder (body) for any purposes of required notices etc.)

* Will be supported (security patches, bug fixes, etc.) with backward compatibility, more or less indefinitely (with reasonable long time frames for deprecation windows and recommended transition plans etc.)

* Are under no danger of being abandoned simply due to lost interest of the author.

* Crucial: Will only depend on other code in the standard library. (So all these guarantees are transitive!)

And anything that's not in the standard library usually implies there are no such guarantees. This is immensely more helpful and important than the comparatively trivial ease-of-installation.

If the Rust team really does explicitly extend such guarantees to non-standard library crates, that should be clearly and widely communicated. So far the focus seems more on how small the standard library is. What's the advantage for the language user? I see advantages for the Rust team, and mainly I see disadvantages for the (professional) language user. Easy-to-use cargo is nice (especially for casual language users) but is nowhere close to really making up for that.

Post reply on HN