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

2017 Rust Roadmap

github.com

Post reply on HN
Print view View original

41–50 of 201 posts

Re: 2017 Rust Roadmap

#41

Post by cmrx64 »

wyldfire wrote: post #19
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…

> any nontrivial project will make use of unsafe blocks. Sure! But that's okay. Just don't use 'quantity of unsafe blocks' as a metric of quality and you'll be all set. Think of it like so: don't use it until you have to and try not to have to. For me, that means consulting experts on IRC (etc), "How can I express this goal in idiomatic rust?" No different from learning C/C++ for the first time, IMO. And if no good w…

> > any nontrivial project will make use of unsafe blocks.

I don't think that's actually true? Most projects make use of no unsafe outside of stdlib and a handful of crates.io crates.

Re: 2017 Rust Roadmap

#42

Post by catnaroek »

cgag wrote: post #37
dikaiosune wrote: post #35

Earlier quoted context omitted.

I would offer a counterpoint -- Rust's guarantees and strong typing offer a different kind of productivity to an intermediate or experienced user. One where a compiled program is much more likely to be "correct" than in any other mainstream-esque language I've used. The properties which combine to create this effect make refactoring much less scary, allow easier navigation in large codebases (IMO), and allow for othe…

This is why I think there's room for another bigtime language that hits the rust sweet spot of functional-flavored imperative programming with a GC.

GC for in-memory data structures, RAII and lifetimes for system resources, ML-style type and module systems. That would be very close to the ideal language IMO.

Re: 2017 Rust Roadmap

#43

Post by cheepin »

dikaiosune wrote: post #28
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…

> Is there an equivalent guide to the compile-time representation of important constructs for those trying to learn C/C++?

Definitely. It was taught in school and there's pretty good guides for it online (maybe not caught up to c++11 and beyond, but the fundamentals are there). You're right that it is not readily available for most languages, but when you need to get serious about performance you either are going to have a guide or spend a lot of time looking at assembly/bytecode. To be fair, I'd probably still have to inspect generated code sometimes, but it's nice to have good instincts for how things run to guide your design/implementation so you can spend less time looking at assembly.

http://www.agner.org/optimize/optimizing_cpp.pdf

Re: 2017 Rust Roadmap

#44

Post by vvanders »

cmrx64 wrote: post #41
wyldfire wrote: post #19

Earlier quoted context omitted.

> any nontrivial project will make use of unsafe blocks. Sure! But that's okay. Just don't use 'quantity of unsafe blocks' as a metric of quality and you'll be all set. Think of it like so: don't use it until you have to and try not to have to. For me, that means consulting experts on IRC (etc), "How can I express this goal in idiomatic rust?" No different from learning C/C++ for the first time, IMO. And if no good w…

> > any nontrivial project will make use of unsafe blocks. I don't think that's actually true? Most projects make use of no unsafe outside of stdlib and a handful of crates.io crates.

About the only time I end up using it is for ffi and uninitialized arrays on the stack.

Re: 2017 Rust Roadmap

#45

Post by leshow »

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…

Most crates don't make use of unsafe, the stuff that I see that does use unsafe is mostly either embedded applications or stuff like the std lib.

And even if you do use unsafe, you can still use it to build 'safe' abstractions on top of. the idea is that your unsafe code is quarantined and abstracted, and you build on top of it. std::collections is a great example of this.

Re: 2017 Rust Roadmap

#46

Post by bluejekyll »

burntsushi wrote: post #34
kjksf wrote: post #32

Earlier quoted context omitted.

It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't pai…

Arguably, programmer productivity is one consequence of safety (and productivity isn't necessarily only gained by increased safety either of course!). Are there different productivity levels between Go and Rust? Probably. But to say Rust wasn't "designed for programmer productivity" definitely isn't right from where I'm standing.

Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that.

I'm actually not buying the productivity argument, after you've learned the language. Claiming that it is less productive when you barely know it isn't fair, it's similar to saying that Italian (as an English speaker) is much more complex and hard to communicate in than English, when you've only studied the language for a month.

It does have a steep learning curve, so it's either worth it to you to learn it, or not. But once you know it, I think your overall productivity is higher or the same as other languages, and on top of that you end up with fewer production issues!

Re: 2017 Rust Roadmap

#47

Post by dikaiosune »

cheepin wrote: post #43
dikaiosune wrote: post #28

Earlier quoted context omitted.

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…

> Is there an equivalent guide to the compile-time representation of important constructs for those trying to learn C/C++? Definitely. It was taught in school and there's pretty good guides for it online (maybe not caught up to c++11 and beyond, but the fundamentals are there). You're right that it is not readily available for most languages, but when you need to get serious about performance you either are going to…

I definitely haven't seen anything as comprehensive as the linked PDF for Rust (although that shouldn't be surprising given the extreme thoroughness of that guide and the age of C++). Probably a good project!

When doing very performance sensitive things in Rust, I usually find myself asking questions a lot on IRC and looking at disassembly in perf.

To answer some specific examples you cited above: I'm pretty sure that enums are (almost?) always equivalent to tagged unions. If you have an enum which doesn't contain any data, then I believe it's representation is just the tag. Iterators are just structs with methods, the various generic functions they implement are monomorphized and then optimized by LLVM.

Re: 2017 Rust Roadmap

#48

Post by leshow »

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,…

coming from haskell too, i missed this. ghci is really fantastic.

Re: 2017 Rust Roadmap

#49

Post by burntsushi »

bluejekyll wrote: post #46
burntsushi wrote: post #34

Earlier quoted context omitted.

Arguably, programmer productivity is one consequence of safety (and productivity isn't necessarily only gained by increased safety either of course!). Are there different productivity levels between Go and Rust? Probably. But to say Rust wasn't "designed for programmer productivity" definitely isn't right from where I'm standing.

Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that. I'm actually not buying…

I'd say my experience matches this. I've written well over 50 KLOC of both Go and Rust in the last few years (I love both), and I don't personally experience a big productivity difference between them. There is one dimension where I feel like Rust makes me more productive though: when writing code that I want to go as fast as possible.

I bet there are things that would be more productive in Go, maybe building web applications, but I haven't built any in Rust yet, so it's hard to compare.

As a reference point, I feel much more productive in Rust/Go than I do in any unityped language. I suspect the same is true of C, but I've never been a heavy C practitioner.

I'll stop here though, because this is all pretty subjective and wishy washy, and it will undoubtedly vary from person to person and be dependent on what kinds of problems you're solving most frequently.

Re: 2017 Rust Roadmap

#50

Post by synparb »

coherentpony wrote: post #11

I'd also like to see a push towards applications in scientific computing.

First class multi-dimensional arrays with natural indexing syntax would be a huge draw. You get that in Numpy, Julia, Fortran and it is extremely powerful in terms of expressing the types of operations that are common across many scientific domains.
Post reply on HN