2017 Rust Roadmap • Hacker News Board

Re: 2017 Rust Roadmap

#21

Post by Cyph0n » Sat, Oct 22, 2016, 1:57 AM UTC

cm3 wrote: post #12

fixxer wrote: post #6

Awesome to see the learning curve addressed with such high priority. I like Rust and I'd like to use it more, but I generally lean on Go or C for writing anything that needs performance. I can't quite get past the awkward, fumbling stage with Rust. Go, on the other hand, was really easy to get acquainted with and not too substantial of an effort to get to strong expertise. I've been able to teach Go to junior devs wi…

The hard part doesn't go away with unless you pull in a GC or something similar to take care of lifetime bugs. In Go you always use a GC and circumvent the explicit lifetime management syntax of Rust. Some data structures are very hard to write without something akin to a GC, so my bets are on a few opcodes trickling down into mainstream cpus making GC easier to implement in optimal time and space. I'm surprised Andr…

Could you provide references for the claim that hardware support for GCs had been in CPUs for decades?

Re: 2017 Rust Roadmap

#22

Post by anuragsoni » Sat, Oct 22, 2016, 1:57 AM UTC

cheepin wrote: post #15

I read through the Rust book, and the problem I was having with it and the other docs is that it was hard to map the Rust concepts with what actually runs when it is compiled. For a language that touts "uncompromising performance", it was difficult for me to find performance characteristics of the underlying abstractions and std library (for example, are algebraic data structures just tagged unions or does the compil…

I am not sure if you have come across this "Rust tutorial for c/c++ programmers" https://github.com/nrc/r4cppp but I found it to be nice when I was first exploring Rust (I had prior experience with C++).

I haven't had to resort to "unsafe" blocks in the Rust I have written so far but "ffi" is one use case for unsafe blocks. Another resource that I have yet to read is "https://doc.rust-lang.org/nomicon/" which seems to explain how to write unsafe Rust code.

Re: 2017 Rust Roadmap

#23

Post by Cyph0n » Sat, Oct 22, 2016, 1:58 AM UTC

joshmarlow wrote: post #13

I would love to see Rust with a REPL. I use Python professionally a lot and have done a fair amount of OCaml in my spare time and both have excellent REPls in the form of `ipython` and `coretop`. Quick experiments with auto-complete is incredibly helpful for exploring a language. That's the only thing I really miss from those languages; when I want to wrap my head around a bit of syntax or a library feature in Rust,…

Scala does this extremely well too. Not sure whether or not a snippet will work? Run 'sbt console' and you're in a REPL with all of your code imported.

Re: 2017 Rust Roadmap

#24

Post by dikaiosune » Sat, Oct 22, 2016, 2:01 AM UTC

cm3 wrote: post #12

fixxer wrote: post #6

Awesome to see the learning curve addressed with such high priority. I like Rust and I'd like to use it more, but I generally lean on Go or C for writing anything that needs performance. I can't quite get past the awkward, fumbling stage with Rust. Go, on the other hand, was really easy to get acquainted with and not too substantial of an effort to get to strong expertise. I've been able to teach Go to junior devs wi…

The hard part doesn't go away with unless you pull in a GC or something similar to take care of lifetime bugs. In Go you always use a GC and circumvent the explicit lifetime management syntax of Rust. Some data structures are very hard to write without something akin to a GC, so my bets are on a few opcodes trickling down into mainstream cpus making GC easier to implement in optimal time and space. I'm surprised Andr…

Is this based on your experience learning lifetimes in Rust? I very rarely find myself needing to do convoluted lifetime tricks -- most of the code I write doesn't even need explicit annotations. So I'd be curious to hear what project you may have worked on as a beginner where lifetime management because a serious obstacle.

Re: 2017 Rust Roadmap

#25

Post by joshmarlow » Sat, Oct 22, 2016, 2:02 AM UTC

Cyph0n wrote: post #23

joshmarlow wrote: post #13

I would love to see Rust with a REPL. I use Python professionally a lot and have done a fair amount of OCaml in my spare time and both have excellent REPls in the form of `ipython` and `coretop`. Quick experiments with auto-complete is incredibly helpful for exploring a language. That's the only thing I really miss from those languages; when I want to wrap my head around a bit of syntax or a library feature in Rust,…

Scala does this extremely well too. Not sure whether or not a snippet will work? Run 'sbt console' and you're in a REPL with all of your code imported.

Something like `cargo shell` or `cargo repl` that automatically imports whatever crate you happen to be working in would be fantastic.

If you had something like that, I imagine you could probably write a Kernel for Jupyter which would be a huge win.

Re: 2017 Rust Roadmap

#26

Post by yazaddaruvala » Sat, Oct 22, 2016, 2:04 AM UTC

pcwalton wrote: post #10

fixxer wrote: post #6

Awesome to see the learning curve addressed with such high priority. I like Rust and I'd like to use it more, but I generally lean on Go or C for writing anything that needs performance. I can't quite get past the awkward, fumbling stage with Rust. Go, on the other hand, was really easy to get acquainted with and not too substantial of an effort to get to strong expertise. I've been able to teach Go to junior devs wi…

It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither…

What are your thought on making `rustc` poly-lingual?

Ideally, all libraries (i.e. should be written by experts) are written in Rust, but applications are allowed to be written in RustScript.

RustScript would be optimized for lower learning curve. example[0]: - No `unsafe` allowed. - Everything is implicitly an `Arc`. - All numerics are BigNum. - etc.

This is inspired by the popularity of using Rust within other languages, like Ruby. The way this would differ from using another language: All the Rust tooling would be the same. Realistically it would just be a different parser for the Rust AST. Therefore no memory layout issues, or FFI involved. Like syntax-sugar to the extreme, the compiler (except the parser) wouldn't even know the difference.

[0] I'm just listing simplifications, regardless of if they are a good idea.

Re: 2017 Rust Roadmap

#27

Post by manaskarekar » Sat, Oct 22, 2016, 2:04 AM UTC

joshmarlow wrote: post #13

I would love to see Rust with a REPL. I use Python professionally a lot and have done a fair amount of OCaml in my spare time and both have excellent REPls in the form of `ipython` and `coretop`. Quick experiments with auto-complete is incredibly helpful for exploring a language. That's the only thing I really miss from those languages; when I want to wrap my head around a bit of syntax or a library feature in Rust,…

Although not exactly a REPL, the rust playground has proven very useful to me for similar purposes. Of course, you need to be online.

https://play.rust-lang.org/

Re: 2017 Rust Roadmap

#28

Post by dikaiosune » Sat, Oct 22, 2016, 2:08 AM UTC

cheepin wrote: post #15

I read through the Rust book, and the problem I was having with it and the other docs is that it was hard to map the Rust concepts with what actually runs when it is compiled. For a language that touts "uncompromising performance", it was difficult for me to find performance characteristics of the underlying abstractions and std library (for example, are algebraic data structures just tagged unions or does the compil…

Is there an equivalent guide to the compile-time representation of important constructs for those trying to learn C/C++? I haven't seen anything like that and it seems like most devs in that realm instead rely on experience and tribal knowledge (which is, AFAICT, how it often works in Rust-land right now). I agree it'd be great for Rust to have clearer official docs about some of these things, but it doesn't seem to me like this is readily available for most languages or runtimes.

Re: unsafe, I think that's tough. My personal feeling is that many of Rust's selling points rely on minimizing the use of unsafe (i.e. limiting segfault-relevant portions of the code), and that there are frequently ways to make things work and also make them fast without using unsafe. What's an example where you found yourself thinking about using unsafe instead of a more complex safe construct?

(Somewhat related to this, and especially for anyone reading who might try Rust, I cannot recommend getting on IRC strongly enough. The Rust IRC channels are by and large incredibly friendly and helpful, and for better or worse that's where a lot of the knowledge in the community is currently collected, not as much SO or blogs)

Re: 2017 Rust Roadmap

#29

Post by threeseed » Sat, Oct 22, 2016, 2:12 AM UTC

adamnemecek wrote: post #5

I would also suggest taking a page out of Apple's playbook and providing some official sample apps like https://developer.apple.com/library/content/navigation/#sect... . Reading the books is one thing, but seeing the patterns actually used is another. You don't need as many as Apple, only a couple really, but make sure they are well written and straddle a couple of use cases. And like go crazy with the idioms, I want…

Personally I think Rust should take this one step further. Actually build templates into the platform itself.

For example one for creating a microservice complete with routes, test cases, JSON support etc. Another for a command line application.

In languages with a steeper learning curve like Rust there needs to be more of an opinionated approach to teaching users.

Re: 2017 Rust Roadmap

#30

Post by brson » Sat, Oct 22, 2016, 2:13 AM UTC

geodel wrote: post #16

Overall it looks good. When I look at this : "Production use measures our design success; it's the ultimate reality check. Rust takes a unique stance on a number of tradeoffs, which we believe to position it well for writing fast and reliable software. The real test of those beliefs is people using Rust to build large, production systems, on which they're betting time and money." I see a little bit of haste towards p…

We want rust to be successful and that means being adopted and used.

It has nothing to do with management and justifying investing in rust. We are fortunate that Mozilla invests in rust to use rust and is currently very happy doing so.