[pdpi]

I'm building a music synthesiser in Rust, and it's a joy to work with.

If you're used to writing systems languages, you might want to learn it because it's the highest-level language I know that prays to the gods of zero cost abstraction. You still get all the control from C/C++ while gaining several convenient features. ADTs and pattern matching are personal favourites. It's widely known that Rust automates a lot of manual memory management without a GC, but it's not as widely known that the same language features also provide very very good assurances for concurrency: it forces you to acquire locks before you can touch synchronised data, it ensures that good behaviour around multiple consumers or single producers for shared memory, etc.

If you're used to writing in the likes of javascript, python or ruby, Rust is a wonderful gateway drug to systems programming, and it's probably the most accessible alternative. Instead of seeing the compiler/borrow checker as bitching and moaning at _everything_, you should see it as holding your hand and helping you navigate some of the trickier bits in writing safe code. As a bonus, it's probably one of the sanest languages you can use for writing FFI code for your language of choice when you just need the extra performance.

If you're a functional programming fan, you'll soon get the sneaking suspicion that Rust is a wolf in sheep's clothing. It's an expression based language with immutability by default, it features Algebraic Data Types and Pattern Matching, uses Result<> (think Haskell's Either) for error signalling instead of exceptions. The closest thing to "object orientation" are traits, which are actually much closer to type classes.

[jabl]

> If you're used to writing in the likes of javascript, python or ruby, Rust is a wonderful gateway drug to systems programming, and it's probably the most accessible alternative.

So what do you think of productivity in Rust vs python/ruby/js? Is it a lot slower to implement something in Rust? While it has a lot of high level features, it doesn't strike me as particularly concise compared to, say, haskell or python..

[Manishearth]

I used to program in python a lot. A few months after I started programming in Rust, I realized that I was still more productive in python for small things, but for nontrivial applications (both writing one and changing an existing one), the type system lets me grok a lot of stuff very quickly (I don't have to figure out how an API can be used, the signature makes it obvious), and the safeguards let me program in a way that "If my code compiles, it probably works". This is less so the case with python, since you have to write a lot more tests and debug code. Of course, Rust still needs tests, just ... fewer (often). And as far as APIs go in python, I would often have to google how to do a specific thing. In Rust I often can copy the basic example, open the docs for the method call, and follow the strongly typed arguments in the doc page till I find the tweak I'm looking for. I have never felt the need to google how to do X with library Y in Rust, but after years of Python I still google this even for libraries I am familiar with since I dread trawling through the docs.

Conciseness isn't really an issue IMO. You can type fast, and your IDE can probably autocomplete. Note that the explicitness in Rust also makes it harder to make mistakes, so I feel that some extra code here and there isn't a bad price to pay.

[jabl]

That's nice to hear (python (and C) are my strongest languages ATM), and what you describe is one thing which irks me when programming with python.

As for conciseness, I do think it matters; it's not about how fast you type really, but how fast you can read what you wrote a week later. But conciseness is perhaps a bit of a blunt term, and maybe needs a bit of qualifiers. Now, take this with a large grain of salt due to my very limited knowledge of Rust. But, say, for a short program/script I guess python "wins" clearly since you can just let it bomb out with a stack trace if something goes wrong, whereas in Rust you have more explicit type conversions (.to_string() etc.), and you have to handle errors somehow, even if it's just with try!/unwrap() etc. which adds clutter. But for a larger program, maybe the difference isn't so big anymore, since Rust, unusually for a "close-to-the-metal" language, has a lot of higher-level functional-style features, and for python you probably want to handle errors in some way anyhow?

[Manishearth]

Yeah, so I find that "how fast you can read what you wrote a week later" is easier in Rust for larger codebases, but for small codebases python is a very clear win.

Eventually you'll learn to glance over unwrap() and try!() (well, unwrap() less so, since it's a bad idea to keep it around in your code) and the code you're reading becomes pretty straightforward to read.

My one annoyance in reading Rust code is that because of type inference (which is a super awesome feature otherwise and this annoyance is nowhere close to being enough to make me dislike it) you sometimes don't know the type of the thing being worked on, so getting an idea of what the code is doing is harder (of course, python has the same issue with dynamic types). I've recently started using YouCompleteMe, though, which has pretty decent "Jump To Definition" support which lets me quickly jump around the types and figure out what's happening in such cases.

[steveklabnik]

I have a lot of experience with Rust, so take this with a grain of salt, but as long as a library exists, I feel about 85% as productive with Rust as I do Ruby. While it takes slightly longer initially, I save a lot of time writing less tests and virtually never debugging.

It's a much younger ecosystem, so there's not always a library though. Then it clearly takes longer, because there's a lot more to do. We do have a pretty respectable number of libraries for our age though, I'm constantly surprised at what DOES exist.

[pdpi]

On the contrary, your response is much more useful than anything I say, because your terms of comparison are much more apples-to-apples than anything my paltry rust experience can provide :)

[steveklabnik]

Yeah but "Just code in Rust for three years and then it's easy!" needs a caveat.