What are some of the big reasons to avoid using Rust (including after the 1.0 release)?
Every language has flaws, so I'd like to try to learn from other people's experiences before I stumble across them on my own.
Every language has flaws, so I'd like to try to learn from other people's experiences before I stumble across them on my own.
With that in mind, here are some of the shortcomings that you may run into, along with their counterpoints:
The short version:
- It can sometimes be hard to get it to type check, but the payoff is worth it in terms of refactorability and maintainability.
- Some type system and language features are lacking, but those will most likely be added post-1.0.
- I miss some semantics from pure FP, but these have been given up for good reasons.
- The syntax is clunky, but it's not a deal breaker, and it will be more familiar to our target audience.
The long version:
You have to do more work to get your program past the borrow checker. The error messages are pretty good and you quickly develop an intuition for it, but sometimes it's not always clear why you are running into an issue. Most often though you are actually doing something subtly wrong that needs to be re-thought. The upshot is that you end up with a rock solid program at that you can refactor freely with the confidence that the compiler will help you along if and when you mess something up. This is in contrast to C and C++ where you constantly feel like you are walking on eggshells.
We don't have as much type system goodness as Haskell, especially with regard to higher order polymorphism. CTFE is also limited. Macro importing/exporting/namespacing as pretty ugly. These will all be addressed post 1.0 though.
Functions are tupled, and currying is not natural. This can make function composition harder than in languages like Haskell and ML. There is no support for guaranteed tail call optimization. There are technical reasons why implementing these are hard though without compromising the core emphasis on systems programming[2][3]. I am thankful that the core devs have chosen to be conservative on these fronts.
The syntax is curly braced, with <> for type parameter lists. Types are declared inline in function signatures (unlike in Haskell, where they are above) which can make them long and hard to read, especially when type parameters come into play - where clauses have helped alleviate this though.
[0]: https://github.com/bjz?tab=repositories
[1]: https://github.com/rust-lang/rust/graphs/contributors
[2]: http://www.reddit.com/r/rust/comments/2ejxk6/minutes_from_la...
[3]: https://mail.mozilla.org/pipermail/rust-dev/2013-April/00355...
If there are any areas in which this is still true, I urge you to value "familiarity" less. As I get older and older, I realize how long software timescales can be. In 40 years, people will still be programming in Rust, and nobody will remember why the syntax started out clunky. :-)
From a personal standpoint, the things that I dislike about Rust are the module system (too complex IMO, though it's been getting better recently) and a few places where the syntax is ugly (some of the ugly syntax has good reasoning behind it, but that doesn't mean it's not still ugly).
Furthermore, the typical downsides to working with a very young technology will apply. Tooling is minimal. Googling for answers to questions will often be futile. Precedents for how to most effectively solve problems with the language are few. The wider ecosystem has comparatively very few useful libs, and even where libs exist they will often be only partially implemented. In other words, it's going to be a wild west for a while yet.
Support for GUI toolkits will probably require some glue code. I've heard that Windows is a particular source of headaches, but I'm not clear as to why. SDL seems to work everywhere; remember that Rust is designed for seamless C interop in both directions.
It's also actually a feature if you want to do things like bare-metal runtimeless code.
I don't see why not--Rust uses LLVM as a backend, and LLVM bytecode can compile to Javascript with emscripten.
Although, I don't really see why you would want to, either.