FFI examples for Ruby, Python and Node.js in the book
This is one of the coolest things to have in the standard documentation, IMO. Rust claims to be good for replacing C/C++ where other languages can’t and shows you in detail how it could be done in a semi-realistic example.
it’s a systems language that doesn’t feel like a systems language
This is how I feel about it, too. Once you understand ownership and borrowing well enough, it doesn’t make you jump through hoops to do things the way you’d do them in higher-level languages.
Thanks! I had the embedding idea right before 1.0, and in retrospect, I’m really glad I did.
Hm, I’m not sure - for me, it feels very much like one. What I love about Rust though is that it doesn’t take the route of “You have to know all these things and things break if you don’t!”, but encodes many of them.
For example, many things are possible when you know the size of the type at hand and some are not if you don’t. Rust makes that very explicit: using the Sized trait. Coming (back) from dynamic languages, that helped me a lot. It gave me enough info to start thinking about this issue and helped me form my mental model again.
i wonder how many ocaml or haskell people have adopted rust. i keep meaning to, but i’m mostly doing application-level stuff and ocaml invariably ends up looking better for any given project
Rust seems to be attracting three camps in roughly equal proportion: systems people, dynamic language people, functional people. I think maybe more Haskell than MLer’s, but who knows…
Rust was originally implemented in OCaml, and Jane Street sponsored RustCamp, even.
As a haskeller (and ocasional ocamler), rust is very interesting (and a while back I contributed a little bit), but unless you need manual memory management (which most of my work doesn’t), it’s a pretty hard sell over haskell (and I don’t say that disparagingly - safe manual memory management is really hard! And rust does it well, but manual is manual!)
In my opinion, I wouldn’t call Rusts memory management manual - it’s static. The compiler needs some additional info here and there, but in safe Rust, you never malloc or free.
GCed languages have similar things once you work in regions where memory concerns get interesting: WeakRefs and caring a lot about references and the underlying semantics spring to mind.
What I mean by ‘manual memory management’ is needing to understand when memory is allocated, when it is copied, and when it is freed. The way Rust does it is definitely better than malloc and free, but you still have to think about lifetimes, borrowing, etc. The compiler can statically rule out all of the unsafe uses (and some of the safe ones), but it still, at least to me, feels manual. Or at least it definitely did when I was last using it (granted, a couple years ago, but my impression has been that that part of the language has actually been relatively stable).
If you are working on that level, you also have to know that in a GCed language. It is not unusual for collections in those languages to differ in their allocation strategies for example (compare the huge amount of collections in Java that differ in allocation semantics).
Rust currently has rather simple allocation/deallocation rules that more compare to refcounted languages and is completely hidden from you. It is unusual to work with them, but I don’t see anything manual about them. Maybe the term just doesn’t cut it anymore.
(Actually, as a side note - in simple terms, Rusts model is counting owners where only one owner is allowed)
I’m pretty sure rust gives me most of what I want out of a type system, but also the complexity of not being GCed. I think a GCed Rust might look pretty ideal to me, i’m starting to play with it now as I’m hopeful that the type system makes the lack of GC easy enough to swallow.
We will eventually be adding some kind of optional GC, so you may also want to try to get involved with that.
Rust used to have a GC and it was thrown out after the decision to go for a runtimeless language. Be aware that Rust operates at a space where you often implement parts of a larger program - embedding a library with a GC runtime into a language with another GC runtime makes reasoning about the memory space of the program really hard.
Also, please be aware that there is a huge project written in Rust during the whole development phase: Servo. If they can switch away from GC, so can you.
For most of what I do, OCaml is a better fit than Rust too, but hopefully I get the chance in the future to use Rust in a project where it’s the best choice.