Hacker News Reader

Comment by rybosome | Hacker News Reader

I really want Rust to succeed, but I'm not a systems programmer. Do people feel that there is still a place for Rust among those who typically work with higher-level languages? The functional aspects and type system of Rust look really appealing, and I'd love to do my part to help it do well by actually using it.

View on HN

I was exclusively a Javascript/Python/Java programmer before jumping into Rust. If you're looking to learn a systems language with real bare-metal capabilities, Rust's safety features will go a long way towards keeping you on the straight and narrow as you figure out the concepts essential to low-level programming.

And because Steve seems reluctant to plug his own book, here's Rust for Rubyists, which is an introduction to Rust geared towards users of higher-level programming languages: http://www.rustforrubyists.com/

This reminded me that I needed to actually release the 0.9 update I wrote over the weekend! Thanks :)

Thanks kibwen for the link, and thanks steveklabnik for writing this. I've been interested in Rust and this looks like a nice way to get my feet wet.

You're welcome! Feedback appreciated.

I want to thank you for a good introduction to rust and can't wait to read the 0.9 updated version.

You're very welcome. I missed one or two things, so there will be another update this weekend.

Anything like a rustforpythonistas been mentioned anywhere?

It doesn't really require a knowledge of ruby, so you might want to have a look.

From the FAQ on the front page:

Do I have to know Ruby?

Really, I love alliteration: the only thing the 'for Rubyists' really means is that I assume you don't know about pointers, concurrency, or similar things. That's okay, you've never had to think about them before! I explain this stuff in extra depth. If you program in another dynamically typed language, you'll be just fine. If you program in another systems language, you'll be more than fine.

There is nothing about the Rust language that makes it ill-suited to higher level work. It's a much easier, safer, language than C++ (which is used for higher level development in MFC) or Objective-C (which is used for higher level development in Cocoa).

At this stage though, the library support for higher level functions is lacking – mostly due to relative youth of the language. At this stage, you won't find much support for UI code and there's a relatively small number of libraries supporting HTTP servers and services.

You could write bindings for these things yourself (and they'll certainly be written over time) but you won't find it out-of-the-box right now.

FWIW, it's worth being precise on what "easier" means: Rust isn't necessarily an easier language to get started in than C++ and so on. Like Haskell, the compiler complains at you, and complains a lot. (Which can be rather discouraging for a beginner.)

However once you've satisfied the compiler, your program often runs perfectly first time (modulo logic bugs, which a compiler can help with (like warning about dead stores, and mutable variables that aren't mutated... which rustc does) but can't detect or fix in general). This is in stark contrast to C/C++ etc where a program normally needs a liberal application of gdb and valgrind to be safe.

Hence: I'd say it's harder to write code but easier to write correct code in Rust.

There'll always be some place for manual memory management - and if the languages for it get better then that space gets wider. I like the fact that they're taking typing seriously, but assuming you don't need the manual memory management I've yet to see any examples of where Rust wins over Haskell/Scala/F#, or even OCaml (though I could well believe it would perform better).

I'd say concurrency support is a big one: Rust rules out data races at compile time, eliminating the need for race detectors, while ensuring that you still have the full array of options when it comes to shared memory, locks, and so on.

What do you mean by "rules out data races"? If I have one piece of code that writes two variables and another that reads them on another thread, there's no way for the compiler to know whether those two changes need to be atomic, serialized, or uncoordinated.

I believe the "data race" definition pcwalton is using is the one from C++11: "a race condition between non-atomic variables". http://en.wikipedia.org/wiki/Race_condition#C.2B.2B

2 threads can't access the same variable in Rust without unsafe{}. I think, anyway...

Access to shared mutable memory without use of a synchronization primitive. It's the same definition data race detectors use.

I am primarily a Rubyist, but I'm head over heels for Rust. I'm pretty sure I've inculcated wycats with similar feels.

You might be interested in http://words.steveklabnik.com/rust-is-surprisingly-expressiv... , which is sort of about this.

Ditto for me, but I came from a largely C background prior to Ruby

FWIW I see a lot of people on #rust who come from a C# background.

Reply on news.ycombinator.com