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

121–130 of 274 posts

Re: Rust's 2017 Roadmap

#121

Post by steveklabnik »

1wd wrote: post #112
Manishearth wrote: post #104

Earlier quoted context omitted.

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.

Thanks, but I still don't see where such guarantees are advertised. Also it's not really clear what "the nursery" is exactly. Where is it? Why is it called that? It sounds more like "not mature = ready for prime time = don't use this". According to that link, regex is also in the nursery. According to crates.io, regex depends on other crates maintained elsewhere, by a "random" single developer, under a different lice…

RFCs are frozen in time; regex has since moved under rust-lang, and has a pre-release for a 1.0.

That person isn't random; they're on the libs team and the primary author of regex. (there are a few crates by other people as well, but most of those crates were extracted from regex as they can be useful on their own.)

Re: Rust's 2017 Roadmap

#122

Post by JoelMcCracken »

ainar-g wrote: post #48
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?

>I can tolerate bugs You might want to rewrite that statement. Or at least clarify, what kind of software that you write that can "tolerate bugs" and what kind of bugs you're talking about.

Obviously, I do things to minimize bugs, and not all bugs are "tolerable".

1. I write many kinds of software, but specifically at that moment I was talking about web applications.

2. "Tolerating bugs" is true of literally every software, except maybe things that are proven to be correct in the mathematical sense. Web applications often have parts that may cause inconvenience if there is a bug, but data is not lost, productivity is not lost, and certainly no lives are lost.

Re: Rust's 2017 Roadmap

#123

Post by CalChris »

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.

Rust Essentials is pretty good.

https://www.packtpub.com/application-development/rust-essent...

Re: Rust's 2017 Roadmap

#124

Post by jimrandomh »

steveklabnik wrote: post #119
jimrandomh wrote: post #116

Non-Rust-user here. I tried Rust about a year ago and gave up on it as not ready. Unfortunately, I don't think this roadmap addresses the problems that made me reject it the first time around. The main problem I have with Rust is that it's not up to the task of dealing with C APIs, particularly POSIX. The issue I got stuck on was https://www.reddit.com/r/rust/comments/47a0s3/dealing_with_v... . There are two possible…

Did you try the nix crate? It looks like maybe not. It should have all of that stuff already wrapped for you. For example: https://docs.rs/nix/0.7.0/nix/sys/termios/fn.tcgetattr.html (select is in there too https://docs.rs/nix/0.7.0/nix/sys/select/fn.select.html ) rust-bindgen has been improving a ton, and it is in fact on that roadmap, under > Integration with other languages, running the gamut from C to JavaScript.

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, I think it's probably incorrect on x86-32, and this crate is definitely a major liability for portability.

Re: Rust's 2017 Roadmap

#125

Post by dbaupp »

tormeh wrote: post #79
dbaupp wrote: post #73

Earlier quoted context omitted.

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.

I'm not sure I agree with the anecdote in your first paragraph, and indeed I preemptively addressed it in my comment: one's own experience is just one way in which something can be hard to learn, whereas people who are regularly teaching and interacting with beginners have a broader view on what people find hard. My experience is, broadly speaking, good teachers are those that have had a lot of practice teaching their material.

Re: Rust's 2017 Roadmap

#126

Post by tormeh »

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.

Copying everything every time is a trivial (and very slow) solution to the memory safety problem. It just means that everything is on the stack (or at least that only one stack frame has a reference to any given object), so it is simply deallocated along with the stack frame. That's it. There's nothing unsafe about it.

What do you mean by saying mutability is for safety? That's a very unusual opinion.

Re: Rust's 2017 Roadmap

#127

Post by steveklabnik »

jimrandomh wrote: post #124
steveklabnik wrote: post #119

Earlier quoted context omitted.

Did you try the nix crate? It looks like maybe not. It should have all of that stuff already wrapped for you. For example: https://docs.rs/nix/0.7.0/nix/sys/termios/fn.tcgetattr.html (select is in there too https://docs.rs/nix/0.7.0/nix/sys/select/fn.select.html ) rust-bindgen has been improving a ton, and it is in fact on that roadmap, under > Integration with other languages, running the gamut from C to JavaScript.

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!)

Re: Rust's 2017 Roadmap

#128

Post by mamcx »

I wish it have a good history for mobile development (iOS, mainly). I think a modern language without a good foot inside the mobile is non-ideal.

Also, a nice history for UI native widgets will be a plus. This is ask a lot, I know.

Right now I have some projects where the less-worse option is .NET, swift if only iOS+Linux, Delphi is because cost (and free pascal is unfocused). Then obviously C++, but that is where I draw a line (ie: For a C-like language Rust is the only that look nice to me. I wish pascal instead or similar)

Re: Rust's 2017 Roadmap

#129

Post by JoelMcCracken »

vertex-four wrote: post #118
JoelMcCracken wrote: post #108

Earlier quoted context omitted.

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.

It's pretty much the reason for segfaults and use-after-free issues (which manifest as either memory corruption or security vulns) in reasonably sized codebases - without a good understanding of ownership, it's non-obvious when a pointer is supposed to become invalid, and if that doesn't match up with when the data is actually freed, you have an issue that's hard to track down later. If you're using a language with g…

Problems involving memory deallocation in the GC applications I've written seem to happen infrequently, certainly infrequently enough that it is one of the lowest items on my list of things I'd like to fix that cause problems in development.

> but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea.

Mostly I think this is sufficiently handled by not mutating shared state as a practice. However, since Rust has mutable borrows, it seems to me that you're still in danger of running into this.

Re: Rust's 2017 Roadmap

#130

Post by bluejekyll »

kod wrote: post #115
lmm wrote: post #95

Earlier quoted context omitted.

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

Pretty sure F# adoption dwarfs rust.

Purely out of my own curiosity, do you know how popular F# is on non-windows platforms?
Post reply on HN