Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's 2018 roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

71–80 of 253 posts

Re: Rust's 2018 roadmap

#71

Post by parthdesai »

smoe wrote: post #65

I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…

That book indeed is really really good. Though i have one feedback, they should have solutions to "Extra problems" they have at the end of chapter (maybe separately). Have been stuck at closures for couple of days now, where you are supposed to implement your own cacher with hashmap.

Re: Rust's 2018 roadmap

#72

Post by skybrian »

tiuPapa wrote: post #67

Do we get the fearless concurrency part of rust on wasm?

Webassembly (and JavaScript) are single-threaded. The platform has web workers, but they are more like processes since they mostly don't share data.

There do seem to be some proposals to add threads, though. Also, it's possible (but hard) to build cooperative multithreading on top of it; apparently Go is going to do that.

Re: Rust's 2018 roadmap

#73

Post by gilmi »

harpocrates wrote: post #64
pimeys wrote: post #43

I've been spending a good majority of my work hours with Rust and especially writing network services using Tokio. When things work there, it is very reliable, fast and has a tiny footprint with resources. Now reading the promise to get a stable async/await and also having Tokio 0.2 in the pipeline, I'd say async Rust might be ready for prime time. Don't get me wrong here, I enjoy using Tokio, but I'd say if you're n…

You've changed my mind on adding special syntax for `async`, generators, and results (`?`). I previously thought it was a big mistake given that these all generalize as monads (granted, there is some ground to be covered before such an abstraction would fit in Rust). What I hadn't considered: specialized syntax leads to better error messages for the most common cases. That's probably quite a good thing, especially si…

> a common problem I have in Haskell is figuring out _which_ monad a certain `do` block is using.

Does type signatures not help in that case?

Re: Rust's 2018 roadmap

#74

Post by smoe »

steveklabnik wrote: post #69
smoe wrote: post #65

I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…

Thank you so much! Any improvement from the first to the second edition is thanks to Carol :)

I haven't looked at the first edition, just wanted to be clear which version I'm referring to. Kudos to everyone involved and Carol for the improvements to the second edition:)

Re: Rust's 2018 roadmap

#75

Post by Shoothe »

> Tooling improvements

For me that's the biggest issue currently with Rust. Type inference via "let" only makes it harder as I can't really know what type a certain variable or expression is without carefully tracking docs. I've tried two Rust plug-ins for VS Code and even though they installed required dependencies I still couldn't have proper list of members when pressing "dot" and without that I feel like programming in the 90's.

Re: Rust's 2018 roadmap

#76

Post by fnord77 »

Shoothe wrote: post #75

> Tooling improvements For me that's the biggest issue currently with Rust. Type inference via "let" only makes it harder as I can't really know what type a certain variable or expression is without carefully tracking docs. I've tried two Rust plug-ins for VS Code and even though they installed required dependencies I still couldn't have proper list of members when pressing "dot" and without that I feel like programm…

intellij's rust plugin is pretty good at type interference.

Also sometimes I just let the compiler tell me by forcing the let variable to something that it is obviously not:

`let not_a_string: String = get_something_that_I_have_no_idea();`

error [4242]: expected type String, found type &*YouWouldNeverHaveGuessed

Re: Rust's 2018 roadmap

#77

Post by tototomtoboro »

Shoothe wrote: post #75

> Tooling improvements For me that's the biggest issue currently with Rust. Type inference via "let" only makes it harder as I can't really know what type a certain variable or expression is without carefully tracking docs. I've tried two Rust plug-ins for VS Code and even though they installed required dependencies I still couldn't have proper list of members when pressing "dot" and without that I feel like programm…

Have you tried https://marketplace.visualstudio.com/items?itemName=rust-lan... ? You will need the rls from nightly but its working very nicely for me.

Re: Rust's 2018 roadmap

#78

Post by debaserab2 »

smoe wrote: post #65

I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…

I also just started learning rust over the past few weeks. While I'm still grasping with some of the core concepts of the language (like ownership), I do feel like there's adequate documentation and resources out there that I'll get there. What I really like is how helpful the compiler is. It's fast and the errors feel well explained and relevant to the problem in my code. It almost feels like I'm developing on a REPL.

Rust seems to have a very ruby-like approach in trading ceremony for conciseness, and while I feel I will eventually learn to appreciate that more, it does present a challenge while learning. It seems like there are a lot more symbols that have significant meaning in rust - where an average language might only have a few dozen or so "core" symbols that I must learn to use the language, rust has quite a lot more, and many of them follow idioms that I don't recognize from any other language (most of my experience is a pretty typical web dev background). It definitely makes learning by example hard (from actual userland code, not the excellent beginner focused hosted tutorial).

Although maybe it just feels this way because I'm on the start of a long journey of understanding and perhaps things look a little bigger than they are.

Re: Rust's 2018 roadmap

#79

Post by swfsql »

I'm an average programmer, but I honestly don't get the goal of inclusiveness [edit: from the Rust 2017 Survey Results]

> Diversity and inclusiveness continue to be vital goals for the Rust project at all levels.

I mean.. lifetime checks won't stop working if you don't consider yourself heterosexual or anything o.O The two matters simply don't mix in my head

Re: Rust's 2018 roadmap

#80

Post by lmkg »

steveklabnik wrote: post #58
zanny wrote: post #52

Heres just hoping that Mozilla is prepared to take responsibility for what they are trying to accomplish in the long haul. A lot of companies have tried to make products that are both infinitely backwards compatible and always supported while still introducing breaking changes like this. It quickly becomes a giant internal mess of trying to figure out what the most common denominator of feature requirements to implem…

So, two things: > Heres just hoping that Mozilla is prepared Rust is an open source project Mozilla contributes to heavily, it's not a Mozilla project. This is the Rust project's problem, not Mozilla's problem. (For example, Mozilla employees, of which I am one, are a minority in governance these days. We're the largest single group of people by employer, but are at 50% representation on the core team and are somethi…

Is MIR being treated as part of the language definition? Most languages would treat such a thing as an implementation detail, so defining the constraints in that fashion seems like it still looks like it may tie you to the reference implementation.
Post reply on HN