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

101–110 of 274 posts

Re: Rust's 2017 Roadmap

#101

Post by kibwen »

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…

> I once said that Rust would never become really, Java-level, popular.

I like Rust, but IMO no language will ever again be Java-level popular (not even Java!) in the same way that e.g. there will never again be a band as big as the Beatles. Technological contexts have changed such that niche languages can now successfully thrive and counteract the lower switching cost that comes with a monoculture; while certain languages "in the middle" will still dominate, the long tail will get longer and subsequently lower any dominant language's market cap.

Re: Rust's 2017 Roadmap

#102

Post by stusmall »

kibwen wrote: post #94
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.

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

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 me "get" borrowing.

Re: Rust's 2017 Roadmap

#103

Post by epage »

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.

stdlib or in a crate for just the trait similar to log?

Re: Rust's 2017 Roadmap

#104

Post by Manishearth »

1wd wrote: post #100
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.

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

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.

Re: Rust's 2017 Roadmap

#105

Post by alkonaut »

monk_e_boy wrote: post #10
doesnotexist wrote: post #2

I'm impressed with the direction they've laid out. It is great to see a deliberate effort is being made to make the language easier to learn and to strengthen the community's ability to leverage shared code.

Is there an good IDE for windows? Something that will step through debug?

I tried IntelliJ and VS code and found ItelliJ to be more polished. Can't remember about debugging but I know the visual Rust project (For VS proper) will do nice debugging it although I still find it too alpha and too quickly changing to be usable for daily use.

Re: Rust's 2017 Roadmap

#106

Post by steveklabnik »

epage wrote: post #103
steveklabnik wrote: post #55

Earlier quoted context omitted.

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.

stdlib or in a crate for just the trait similar to log?

The parent is worried about 2.0, so that would imply in stdlib. No reason it couldn't be done as a crate just for the trait as well, but that at least leaves the possibility of a 2.0 open.

Re: Rust's 2017 Roadmap

#107

Post by flukus »

mdzn wrote: post #89
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.

Doesn't having less reliance on indirection help speed?

Re: Rust's 2017 Roadmap

#108

Post by JoelMcCracken »

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.

This is one of those things that seem plausible, but I have no idea if its really true. I'm not disagreeing, I just can't see it as being obviously true. Can you give me an example of how a fuzzy idea of ownership causes, ideally, a real problem, or a less ideally a simplified example problem? I'm 100% genuinely interested in this.

Re: Rust's 2017 Roadmap

#109

Post by steveklabnik »

akiselev wrote: post #92
steveklabnik wrote: post #55

Earlier quoted context omitted.

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…

It helps with the orphan rule, as everyone would be importing the trait from std. From/Into are the same kind of traits. That is, the idea is that the rand crate would implement std::rand::Random, and so would some rand2 crate, and then I could write my own crate saying

    fn random(r: R)
and it would work with either one. No need for newtypes.

I also might be missing something.

Re: Rust's 2017 Roadmap

#110

Post by JoelMcCracken »

jamwt wrote: post #91
vertex-four wrote: post #80

Earlier quoted context omitted.

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.

Rust is hardly the only language to have a type system that supports generics.
Post reply on HN