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

111–120 of 274 posts

Re: Rust's 2017 Roadmap

#111

Post by flukus »

tux3 wrote: post #70

I'm happy to see the focus on productivity. I saw the long awaited Non-Lexical Lifetimes tentatively mentioned in there, and I can only hope this will help move things forward, since it's pretty frustrating spending time fighting the borrow checker and refactoring correct code that really ought to run as-is. Cheers and happy 2017 to the Rust project!

As far as fighting the borrow checker goes, how familiar are you with more functional style programming approaches, mainly immutability?

I'm extremely new to rust so I don't know if fighting the borrow checker is in my near future or something I will largely avoid.

Re: Rust's 2017 Roadmap

#112

Post by 1wd »

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

Earlier quoted context omitted.

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.

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 licenses, with zero obvious guarantees.

Re: Rust's 2017 Roadmap

#113

Post by PeCaN »

lmm wrote: post #95
zyxzkz wrote: post #57

Earlier quoted context omitted.

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.

They were all garbage collected, which is a dealbreaker for some applications. Rust aims to fit that niche (though if the Rust Evangelism Strike Force is to be believed, Rust fits every niche). Substructural type systems akin to Rust's affine types have been relegated to research for a while.

Re: Rust's 2017 Roadmap

#114

Post by isaacaggrey »

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.

I can't speak to personal experience since I've only dabbled in Rust, but I have followed it for quite a while and lately I have read more and more how how Rust forces you to structure your data and program in such a way that is more maintainable.

Re: Rust's 2017 Roadmap

#115

Post by kod »

lmm wrote: post #95
zyxzkz wrote: post #57

Earlier quoted context omitted.

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.

Pretty sure F# adoption dwarfs rust.

Re: Rust's 2017 Roadmap

#116

Post by jimrandomh »

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 things Rust could do that would make me give it a second chance: either commit to maintaining bindings for all of POSIX and libc as part of Rust core, or fold rust-bindgen into core and get it into shape.

Creating higher-level libraries like Tokio is nice for some use cases, but right now Rust doesn't have a working safety valve for things C can do that Rust can't. This greatly magnifies problems like lack of bindings for select() (see http://esr.ibiblio.org/?p=7294&cpage=1 ; I too ran into that problem, and lost a few days to it.)

Re: Rust's 2017 Roadmap

#117

Post by PeCaN »

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

https://github.com/ninjabear/nickel-bootstrap You might be interested in this

Why would someone trying to learn Rust be interested in a web framework? I think they ought to learn how Rust works first, or they'll just be more confused.

Re: Rust's 2017 Roadmap

#118

Post by vertex-four »

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.

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 garbage collection, it's obviously not going to result in segfaults, 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. More generally, if your object is stored in multiple places in your code, you have to remember to clean up all references to it properly, in all the different states your system can be in, and your compiler can't verify you're doing that correctly without a borrow checker.

Re: Rust's 2017 Roadmap

#119

Post by steveklabnik »

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.

Re: Rust's 2017 Roadmap

#120

Post by munin »

lmm wrote: post #95
zyxzkz wrote: post #57

Earlier quoted context omitted.

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.

Memory management? Every ML implementation I know about uses GC, which is frequently just too slow. Along with many other reasons (http://www.podval.org/~sds/ocaml-sucks.html)
Post reply on HN