The mechanisms that Rust uses to provide memory safety require more forethought than the various forms of garbage collection that other memory-safe programming languages use. If you can happily live with a garbage collector, then Rust may not appeal to you. If you're not doing anything that benefits from concurrency, then Rust's ability to statically prevent data races won't matter to you.
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.
Well, the obvious one is your deployment options: You need to either compile binaries for the target platform, or ask the user to compile from source. As far as I know, you can't yet compile Rust to Javascript.
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.
Your first point perplexes me, Rust is a systems programming language like C, Pascal, FORTRAN, C++ and the like. Building ahead-of-time platform specific binaries is business as usual and not anything really notable about Rust itself.
It's also actually a feature if you want to do things like bare-metal runtimeless code.
Rust relies on a newer version of LLVM than Emscripten is based on (as Emscripten-fastcomp is based on the PNaCl fork of LLVM, which is lagging behind). Once the PNaCl fork is updated and Emscipten rebases, or they rebase onto LLVM proper, then it should be doable fairly easily.
Before I start, I will say that I love Rust, and more often than not find it a pleasure to work with. Pretty much all my GitHub repositories[0] are in Rust, and have contributed a reasonable amount to the Rust repository itself[1]. Despite this, I think it is important to be honest. How much these are a deal breakers depends on your perspective and the domain that you are targeting. If you are working in a space where you really need performance, control over memory layout and allocation, and value strong abstractive power and excellent maintainability properties, then I doubt you will find a better choice of language than Rust once 1.0 is released.
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.
- The syntax is clunky, but it's not a deal breaker, and it will be more familiar to our target audience.
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. :-)
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.