"No segfaults, no uninitialized memory, no coercion bugs, no data races, no null pointers, no header files, no makefiles, no autoconf, no cmake, no gdb. What if all the problems of c/c++ were fixed with one swing of a magic wand? The future is here, people"<p>It certainly is.<p>The advantages over C++ seemingly never end. I'd add to the list: rigorous portability, non-broken macros, ADTs and pattern matching, a careful language stability protocol, standard test and doc tooling, flexible namespacing via visibility and modules, the <i>absense</i> of vast lacunas of undefined behaviour, simple numeric promotion rules, meaningful compile-time errors for generic code. Plus things already mentioned in the post like Cargo.<p>People tend to focus on the safety side of Rust, but as impressive to me is just the... solidity on all these other axes. If you stripped out lifetimes and the borrow checker you would still have an incredibly compelling alternative to C++.
I'd like to echo the author in that Cargo is the best language package manager/build system I've had the pleasure to use.<p>However, there is one serious problem with Cargo's packages: They simply aren't authenticated. Cargo's developers acknowledge this issue and there is a proposal to amend it by adopting the TUF [1]. but this issue doesn't seem to enjoy the attention it deserves.<p>As a person living in a country that increasingly edging towards going the Kazakhstan route where all secure traffic will be MITMed, simply relying on transport security as a way to secure crates is not sufficient. and that's ignoring compromises due to server security failures. At present, my only options are to include the entire dependency tree in crate or avoid dependencies altogether.<p>Even ignoring my problem (which wouldn't effect a large number of rust developers), Mixing transport security with authentication and integrity shouldn't happen in vital infrastructure like a language package system.<p>There are other problems like not representing system libraries that a crate depends on in the project manifest, but unauthenticated crates are a ar more serious problem.<p>[1]:<a href="https://github.com/rust-lang/crates.io/issues/75" rel="nofollow">https://github.com/rust-lang/crates.io/issues/75</a>
I'm working with Rust 2 months. In my opinion, pluses:<p>+ Compiler with very helpful error messages;<p>+ Cargo is the best package manager in the universe;<p>+ Result<> is the most correct way to return results from function, I dreamed about it;<p>+ Community of smart and friendly people.<p>Minuses:<p>- Functions are not first class citizens - you can't return function as result;<p>- Violation of "explicit over implicit" rule in methods declarations: argument self/&self is implicitly omitted in call, but exist in signature. Because of this, for example, you can't use method of class as request handler in Iron, you need closure wrapper with same order and count of arguments. Pure ugliness;<p>- Often you need just add lifetime definition to satisfy compiler, without doing anything with this lifetime anywhere else in code;<p>- Extremely verbose syntax;<p>- Rust has exceptions (panic), and you can't catch them. And with promised panic::recover you'll have limitations of supported structures;<p>- Errors handling encourages copy-pasting;<p>- Syntax is not intuitive, especially when traits and lifetimes comes into declaration - in such cases you can look at own code and think "I hope at least compiler can read it";<p>- Nested structures is pain;<p>- Lack of optional and named arguments, lack of predefined values in structures;<p>- Too few modules for web. Just 1 module for MySQL (thanks to it's author - actively maintained);<p>- Usage of safe code can lead to out-of-bounds errors, with thread panic (hello to vec macros).<p>And I still think it's best language we have:) Biggest advantage - most of errors can be found on compilation step. But price is all of these minuses.
I never found the borrow checker to be that hard to work with. For a start, if you're developing a systems language in a modern way, (say C++11/14) you're already used to thinking in terms of move semantics, const refs and shared vs unique pointers.<p>Secondly, Rust's compiler gives INCREDIBLY detailed explanations of what the borrow checker doesn't like, where the conflicting scopes begin and end, and helpful suggestions of what to do to make it work.
The submission and expanded discussion at /r/rust: <a href="https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_rust/" rel="nofollow">https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_r...</a>
I'm a little skeptical after first reading "Disclaimer: I'm digging Rust. I lost my hunger for programming from doing too many sad commercial projects. And now it's back. You rock, Rust!" and then seeing comparisons to Python in the text where it seems like the author might prefer writing in Python, especially with all of the Rust cons listed.<p>Is the author saying Rust is a breath of fresh air from C++ or from all other programming languages? Ruby was my breath of fresh air for a while, but lately I've not been enthusiastic about any language or framework, really, so I curious how great Rust really is these days.
I also tried rust for a couple of weeks, but holy hell is it ugly. Why improve on c++ and not improve the syntax or containers? It's like python never existed.
Nice to see rust getting along. Coming from C and C++ is really dig the new ideas for better and more save low level languages.<p>What really bugs me, is what the author describes as being'concise'. Shortcuts like fn, pub or vec, in my oppinion, hurt readability more than they help me to write code faster. But maybe thats just my brain, or lack of time using rust.
I've been experimenting with Rust for a few weeks, and I really like it, but I hope they improve how you write functions that return iterators. I can't find all the discussion now, but here is some of it:<p><a href="http://stackoverflow.com/questions/27535289/correct-way-to-return-an-iterator" rel="nofollow">http://stackoverflow.com/questions/27535289/correct-way-to-r...</a><p><a href="https://www.reddit.com/r/rust/comments/2h26cj/functions_returning_iterators/" rel="nofollow">https://www.reddit.com/r/rust/comments/2h26cj/functions_retu...</a><p><a href="https://github.com/rust-lang/rfcs/pull/105" rel="nofollow">https://github.com/rust-lang/rfcs/pull/105</a><p><a href="https://github.com/rust-lang/rfcs/pull/1305" rel="nofollow">https://github.com/rust-lang/rfcs/pull/1305</a><p>Reading those RFCs can be frustrating, where a discussion goes on for over a year and people add more and more wants to an idea until it sinks. Same thing with the discussion about a `yield` keyword:<p><a href="https://github.com/rust-lang/rust/issues/7746" rel="nofollow">https://github.com/rust-lang/rust/issues/7746</a><p><a href="https://github.com/rust-lang/rfcs/issues/388" rel="nofollow">https://github.com/rust-lang/rfcs/issues/388</a><p>It reminds me of the JCP in Java. I guess every standards committee is like this, and I actually like how careful the Rust team is about extending the language---but I think we should be prepared for it to evolve slowly. Right now I feel like Rust's pace will be more like Java than C#.
The article is comparing Rust principally to Python (a new dynamically typed language) and C++ (an old statically typed language). It's certainly plausible that it can bring benefits over these.<p>More interesting to me would be comparing it to a new-ish multi-paradigm language, of which there are many right now (e.g Swift, OCaml, Haskell, F#, Scala). It seems like in practical applications these newer FP languages will be much more productive than Rust, as memory management is much simpler. Rust's principle of zero-cost abstractions is great in theory, but can't think of many applications where it's the limiting factor except perhaps embedded devices and kernel development.
Future? well, 10 year later, quantum computer maybe come to reality which is much much faster than current computers. At that time who will care about Rust or C++? The easiest language will win.
When you've worked with languages with a garbage collector, having to worry about memory management and all that jazz seems a step backwards just to save a few cycles. You want to be focusing on the domain problem not the machine. (This is directed at people who use Rust as a general purpose lang, im sure it's good for low level systems programming).