Of course, using Rust is even cooler.
C++ is used by research algorithms used in HPC context or by the device drivers for the readers.
In this case the data sets are around 1GB, but I don't know what they are actually loading into memory.
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.
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..
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.
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.
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?
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'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...
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.
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.
On my case, just dabbling given my background as language geek.