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

51–60 of 201 posts

Re: 2017 Rust Roadmap

#51

Post by leshow »

yazaddaruvala wrote: post #26
pcwalton wrote: post #10

Earlier quoted context omitted.

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

not the OP, but i strongly disagree. you don't need to be an expert to write rust. Many of it's features are in a huge amount of other languages; parametric polymorphism, ad hoc polymorphism, type inference, etc. there's nothing new and groundbreaking besides ownership and lifetimes, from a language syntax perspective. it really just takes a little bit to get used to ownership and you're off to the races. the compiler helps you out in a big way with writing correct programs.

i also feel fracturing the community would be terrible. i came from basically a dynamic programming background (had done java and c++ in soft. eng. in school and that's it) and I had no problem learning rust.

Re: 2017 Rust Roadmap

#52

Post by leshow »

Awesome. I have used Iron a few times to write small web services, but I can't wait for Rust to really have a strong story for the backend. If that happens it'll be the first language I reach for whenever I need to write a backend.

I think it has a lot of great bonuses already. It's language ergonomics are that of a high-level language, yet it is extremely fast, and I can be very confident in my code if it compiles.

Rust is one of my favorite languages, keep up the great work guys.

Re: 2017 Rust Roadmap

#53

Post by jdf »

jdf wrote: post #40
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…

I agree with some of your points, but think this is phrased a bit harsh. FWIW, I write both Go and Rust on a regular basis. Here's where I would agree with you: - Go makes it harder for someone to write overly abstract code (a common affliction!). - Being able to occasionally do type assertions in an ergonomic way is surprisingly nice. - I wish Rust had something in the stdlib like net/http. - I like that go fmt is s…

I forgot to add - I partially agree with you about the productivity of GC. For non-performance sensitive code, GC simplifies a lot. Otherwise, I find Go much nicer to reason about than Java since it has real arrays (value types!).

But I find it a mixed bag of whether the naive Go version of something that shares memory by GC is simpler than the naive Rust version of something that shares memory. Sometimes ref-counting (Rc in Rust) is fine, although that's more expensive than GC. Sometimes Rust's ownership model nudges you to make the code much simpler and makes it clear that something only has a single writer. Sometimes you wish you were in C and just did it yourself...

Re: 2017 Rust Roadmap

#54

Post by aturon »

catnaroek wrote: post #42
cgag wrote: post #37

Earlier quoted context omitted.

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.

The key problem: in-memory data structures can embed ownership of system resources.

Re: 2017 Rust Roadmap

#55

Post by mitchmindtree »

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.

This has been my experience also. I've written at least 40kloc of rust over the past couple years (including complex graphs with cycles, low-level DSP) and I could probably count the number of unsafe blocks I've needed on one hand.

edit: This is not counting FFI though.

Re: 2017 Rust Roadmap

#56

Post by vvanders »

leshow wrote: post #52

Awesome. I have used Iron a few times to write small web services, but I can't wait for Rust to really have a strong story for the backend. If that happens it'll be the first language I reach for whenever I need to write a backend. I think it has a lot of great bonuses already. It's language ergonomics are that of a high-level language, yet it is extremely fast, and I can be very confident in my code if it compiles.…

Yup, happy to see everything on the list.

If one thing more than any stands out it's Rust's commitment not just to building a language but building an incredible community. With how seriously the release processes are being taken to the way new people are welcomed. Serious kudos, I know it's not the most technically engaging work but it makes a huge difference.

Re: 2017 Rust Roadmap

#57

Post by vvanders »

gravypod wrote: post #4

> 1 in 19: lack of IDEs (1 in 4 non-users) I expected that to be higher actually, but that's still the only reason I don't use the language. I've come to rely heavily on IDEs. Whether right or not it's a huge factor in my decision to wait for the language.

If that's the case I highly recommend giving VSCode a spin. With racer I've got solid code complete, goto def and docs.

They've also been making leaps and bounds in terms of features so I can only imagine it improving even more.

Re: 2017 Rust Roadmap

#59

Post by sidlls »

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.

stdlib has plenty of unsafe blocks inside it, as do many crates. Claiming one doesn't use unsafe blocks because none are visible in one's lib.rs or whatever doesn't mean they aren't there.

Re: 2017 Rust Roadmap

#60

Post by dikaiosune »

sidlls wrote: post #59
cmrx64 wrote: post #41

Earlier quoted context omitted.

> > 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.

stdlib has plenty of unsafe blocks inside it, as do many crates. Claiming one doesn't use unsafe blocks because none are visible in one's lib.rs or whatever doesn't mean they aren't there.

There's certainly a difference between writing one's own unsafe blocks and relying on functionality which was implemented using unsafe in a community project (which has hopefully been vetted by some community members).
Post reply on HN