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

131–140 of 274 posts

Re: Rust's 2017 Roadmap

#131

Post by jimrandomh »

steveklabnik wrote: post #127
jimrandomh wrote: post #124

Earlier quoted context omitted.

Happy to hear bindgen is getting attention; I didn't actually notice that when I looked through the roadmap. I didn't try the nix crate at the time, but looking at it just now - it doesn't solve the portability issue. It defines struct Termios in https://github.com/nix-rust/nix/blob/master/src/sys/termios.... , with something #ifdef-ish branching on operating system, but not on CPU architecture. On quick inspection,…

Sounds like you should open an issue; it's pretty much the crate for safe bindings, but as I'm sure you know, there's a lot of tiny details to get right. (Also, I'll stop here and only reply on our Reddit conversation, ha!)

https://www.reddit.com/r/rust/comments/5sg9d3/rusts_2017_roa...

(The first few comments are mirrored between here and Reddit.)

Re: Rust's 2017 Roadmap

#132

Post by MichaelGG »

JoelMcCracken wrote: post #108
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.

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.

One piece of software that handles a lot of traffic on phone networks has an interesting issue. A bunch of headers are added to a list on every transaction. Most of these header names are constants ("TransactionID", "SourceId", "CallingNumber", etc.). However, they can be dynamic ("x-dynamic-header-foobar"). The easiest way in C to deal with this is just to strdup all the header names, so the final consumer can safely free() them.

End result: This app spends about 30% CPU time on malloc/strdup/free.

In Rust, you simply wouldn't have this design in the first place because it's so easy to avoid. In C, it's super intrusive to fix once it's obvious this is a bottleneck.

Though this isn't necessarily a fuzzy concept of ownership, just more of a pain-to-deal-with thing.

Re: Rust's 2017 Roadmap

#133

Post by bluejekyll »

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 was mainly using Atom until a few days ago. I wanted to try out the RLS, and that meant switching to VSCode, which has been really growing on me. I'm starting to consider using it for all my non-java development needs. It's a great experience with the Rust plugin, even without the RLS. I've used it on both macOS and Linux, and it's pretty seamless between those two environments.

I highly encourage people to drop any MS misgivings and give it a try (honestly that was the biggest thing for me to get over).

Re: Rust's 2017 Roadmap

#134

Post by lobster_johnson »

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.

Aren't they closely related? Single-ownership semantics benefit concurrency and optimization by eliminating the need for locks and synchronization except in those (rarer) cases where data explicitly needs to be shared between threads, in which case Rust forces you to go through mutexes. In other languages that don't offer this safety, you're likely to lock a lot more stuff as a purely defensive measure, because the only thing preventing unsafe access is the programmer.

Since the borrow checker happens at compile time, the whole mechanism is "zero cost". This results in more efficient code, because you can do things like safely hand out references (pointers) to privately held pieces of data without needing a heap allocation to track the pointer (e.g. shared_ptr in C++); the final code needs no lifetime checks, because the compiler did all the analysis for you.

I imagine the combination of ownership and immutability also lets the compiler reorder, eliminate and simplify generated code better than most other languages (Haskell being a possible exception here). Not sure if Haskell-style automatic parallelization is planned.

Re: Rust's 2017 Roadmap

#136

Post by kbenson »

sgentle wrote: post #99

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?" Ofte…

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

On the other hand, if you're looking to fill out your resume or get some open source credentials, you can see this as another frontier opening up (depending on how popular you think Rust will be in a few years). Become the solution for that need in the Rust ecosystem, and there are probably massive reputational benefits to be reaped. In some ways, reputation is better than money, because when invested wisely can have a much higher rate of return, and depending on location and circumstance, can be levered into high-paid employment.

One person's problem is another person's opportunity.

Re: Rust's 2017 Roadmap

#137

Post by anamoulous »

stusmall wrote: post #102
kibwen wrote: post #94

Earlier quoted context omitted.

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 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?

Re: Rust's 2017 Roadmap

#138

Post by nitrogen »

steveklabnik wrote: post #81
nitrogen wrote: post #77

Earlier quoted context omitted.

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

Makes sense. I'll have to go through the rewritten parts again, as I'm having a heck of a time trying to pass the TcpStream object from Tokio into my actual service, as part of a personal learning exercise (https://github.com/mike-bourgeous/cliserver_rust/issues/6). I haven't broken down and asked online yet, partly out of sheer determination and partly because I'm in the middle of looking for a new place.

Re: Rust's 2017 Roadmap

#139

Post by carussell »

ainar-g wrote: post #41
steveklabnik wrote: post #31

Earlier quoted context omitted.

You will probably like the O' Reilly book. It's a bit closer to "Rust for C++ people", IMHO. I fully agree that more of this kind of thing would be great.

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…

When I suggested doing this last year[1], it was very well-received. Not sure if the Rust folks ever did it. I'd wager no.

1. https://news.ycombinator.com/item?id=11156266

Re: Rust's 2017 Roadmap

#140

Post by rspeer »

gcp wrote: post #59
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…

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.

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 By Example or on Stack Overflow. Shouldn't a standard library be able to abstract over fiddly details like this? Why is it my job to tell it how to buffer?

I say this as someone who is enthusiastic about Rust, but still learning.

Post reply on HN