I've found it very fruitful. I had previously spent a couple of months hacking away at a project in C++ which needed lots of fine-grained parallelism and custom data structures (metagenomics analysis tool). When we decided to shift our approach and that we wouldn't be saving any code, I started out trying Rust and fell in love. Many of the issues I faced in trying to quickly put together an application in C++ were just non-issues as a result of Rust's type system.
Yes it is :). Also, I've had mixed results with managed languages and loading 1.5 TB text indices into RAM (not even to say anything about how much of NCBI's nt database will fit into 1.5TB when using different runtimes), so using manual memory management seems like the smart move here. Also, C++ had many libraries we could lean on for manipulating very large genomics datasets, and Rust is starting to grow a little ecosystem as well. I'm not familiar with a comparable availability of open source tools in C#, although I don't have any experience in it so maybe that lack of exposure isn't reflective of the state of things.
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.
> 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..
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.
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?
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.
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.
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 :)
Yes. I'm still just learning it myself - I've got to say it's a really nice break from writing C (which is most of my day job). Having a proper type system is really nice, and having type inference makes me feel like I'm coding in a dynamic language even though I'm not.
I'm currently building a CI tool (which will hopefully be open sourced once I get approval from our legal department) with a colleague of mine who mostly chose to use Rust because he needed an excuse to learn it...
I'm just learning it, so I'm not (yet, at least ) doing anything awesome with it.
As for why Rust in particular, over the years I've convinced myself that software quality is one of the big ails of, well, anything which concerns itself with the creation of SW. Which is more or less anything these days in technical professions. Strong static typing, memory safety, data race freedom etc. are of course no panacea, but are at least IMHO a step in the right direction.
FWIW, I also think Haskell is totally awesome, but with my background in mostly procedural/OO languages and with small kids at home, I feel I cannot at the moment afford the time to become really productive in a pure lazy functional language in a reasonable time frame. It's on my someday TODO list, though. Oh, and I'm somewhat of a speed freak. So hence Rust.
Amusingly, I'm in the reverse situation: loving working in Haskell and reeally want to try Rust but I just don't have the time.
For what it's worth, Haskell can be compiled to code that's quite fast. Somewhat unfortunately, the difference between GHC's vanilla output and its speed-optimized output can be quite vast, which I think gives the impression that the language or a given program is necessarily slow.