Hacker News Reader

I'm very curious about better ways to explain not just Rust pointers, but also other features that contribute to Rust's unique feel, like inherited mutability and linear types. These things are all interrelated and there are some emerging best practices, but they are still unfolding as the language evolves and people gain experience with it.

I'd recommend reading Tom Lee's post (linked previously) on the subject of pointers.

On the subject of libraries, there is a lot of work yet. The plan has been to get the language stabilized then start focusing on libraries and tooling.

The core and standard libraries are not very consistent, either in style or quality. The I/O modules (both file and network) are particularly problematic at the moment, so even a simple networking application will be difficult. Some folks have had success though by writing their own bindings to BSD sockets, ZeroMQ, mongrel, etc. (bindings for which are in cargo).

Outside of core and standard there have been a lot of graphics- and math-oriented libraries. Multimedia, particularly games, seems to be a very promising domain for Rust. There are a number of useful libraries that are not in cargo because cargo is not yet powerful enough to deal with their build requirements.

Some of the easiest, and potentially most useful, code to write when getting started are re-implementations of popular libraries, protocols, etc. in Rust. For example, I really wanted to implement mustache templates in Rust but somebody beat me to it.

Where 2012 was the year of stabilizing the language, 2013 will be for cleaning up and redesigning the libraries, and hopefully making all the tooling more usable and featureful.

"Second, how did you come to understand the memory model? I consider myself more familiar in both functional programming and memory management than average, but I found the memory model to be a bit of a conceptual hurdle (even though I'm attracted to the approach on a philosophical level). Having such a unique memory model makes it a little tough to simply get started writing code right away."

I think that if you understand the smart pointers in C++ (especially C++11) you basically understand the Rust memory model. In C++ terms, Rust has stack-allocated data, std::unique_ptr, and (non-thread-safe) std::shared_ptr built into the language. (There's a thread-safe std::shared_ptr in the library.) We also have a bunch of safety checks to make sure you use the smart pointers correctly, so you can't use non-thread-safe pointers in threaded code, you don't have iterator or reference invalidation, etc.

The tricky part is making it accessible to folks not coming from C++, which is an important goal. Any ideas would be much appreciated :)

- I don't have a good answer for you about how I started, I just got the compiler running and started writing code. A BST, as it so happened.

- I don't claim to understand the memory model entirely, but I think I have a grasp on it. This is due to my knowing C++ and having a grasp of the lambda calculus.

WRT libraries, it's not a mature language. It's not going to have the tens of thousands of libraries like Perl. I would recommend writing applications that fall into a functional programming/low level area, but that's just me. There's Servo, a research web browser.

Finally, I don't recommend comparing Rust with Go. Two languages and two different design goals. A better compare would be with D or OCaml.

How is D or OCaml more Rust-like than Go? Can you explain?

Rust is basically ML + C's lovechild. Sophisticated type inference, mostly pure variables, pattern matching lambda functions, a few other FP goodies. But it's also a fairly clean imperative language if you care to use it like that. Generics, mutable variables, {}; syntax, pointers, etc. Also, more fundamentally, I see D, OCaml, and Rust as occupying a "let's be clean" kind of space.

I see Go as occupying a "let's be scruffy" space; not really pushing the language state of the art, focused on industrial work; it's like a type-safer & compiled python, afaict. It doesn't really strive to push the state of the art, it seeks to solidify certain well-known taken ground in programming language design, and to be really focused on that.

I'm not going to apply a "better" metric, I don't think that's appropriate because they are occupying different areas in the design space with different goals. If they were posed as straight-up competitors, then it'd be appropriate to measure them against each other.

I'll have to check Rust then, seems interesting. Although I see Go as a clean language: A "better" C and D as a "cleaner C++".

RE: the memory model, I wrote a blog post on it because I had the same trouble. Folks seem to have found it pretty helpful!

http://tomlee.co/2012/12/managed-and-owned-boxes-in-the-rust...

Not the person you replied to, but I can give some idea...

>First, how did you get started?

I always find a project I kinda want to do, and apply the language to it, not the other way around. In my case, I need to read JVM .class files [1]

>Second, how did you come to understand the memory model?

The compiler is really strict and won't let you do certain things without explicitly stating (copying, changing pointer types, etc). Basically you have to ask yourself what you're doing w/ the data, then apply the box you want.

>Finally, how do you find the libraries in different areas?

Cargo is all there is [2]. Obviously the ecosystem is thin right now, but it's really easy to wrap C libs. As for what's easiest, not exactly sure, it's a pretty general purpose language, but pretty low level.

[1] - https://github.com/cretz/patina [2] - https://github.com/mozilla/cargo-central