I consider myself reasonably competent in Rust but the webassembly stuff always trips me up, and so do most cross-language tools. You might've just had an unfortunate experience. I'm not sure if I'd pick Rust for WASM unless you already know it, but I suppose it's a good reason to learn the language.
The problem with Rust is that to write good Rust, you need to accept that you can't use the same approach to solve a problem you could use in other languages. The borrow checker and its implications aren't necessarily difficult, but they're different.
I'd compare the experience to someone who started in Python learning Haskell for the first time: it can take weeks or more before one can truly understand a monad. If you start with basic functional programming you can be quite productive before you need such code structures, but when you open a code base where monads are mixed liberally, your head will be spinning.
Rust may be a lot closer to traditional imperative languages, but the implications of the safety mechanisms in the language are something you can't just skip over. It'll take time and practice to write code that the Rust compiler likes.
If you're getting started, I'd recommend writing some toy programs for the CLI instead. I also recommend using "clippy" to warn you of code smells (it'll suggest improvements when it can!) and to get links to specific problems you might not be aware of. As for the IDE, I recommend the rust-analyser plugin over the native "Rust" plugins found in most IDEs, because the basic ones fail to do proper macro expansion and leave you guessing on how to use libraries.
What would be an alternative if I plan to develop a high-performant data analysis tool for WASM(similar to Perspective[0])? I looked at the list of supported languages[1] and Rust seems to be a good choice.
I can't say I'm too experienced in writing code for WASM, but I have to say I was pleasantly surprised when I experimented with Go.
It has to be said that I have many (mostly subjective) problems with the Go language and the ecosystem, but with the help of GoLand I was productive in minutes. The layer for exchanging arguments between the browser and the "native" code is a bit weird, but once you get passed that, it's easy to get going.
The Rust problem with WASM is more about learning Rust well and picking the right libraries (many of them have dependencies that don't work well in the browser!). Setting up tools like cargo to compile usable WASM files also takes a little practice, but that's at most an afternoon of messing around before you should be reasonably comfortable with it. In my opinion, the main improvements Rust brings to the table are the (memory) security features and the fearless multithreading, but neither of them are of much use within the WASM runtime. The borrow checker will still help you write correct code, but it can be an unnecessary pain in the ass when it doesn't need to be. Rust is a great systems programming language, but I'm not so sure about it becoming the de-facto WASM standard.
Of course, if you already know Rust, or know a library that would be super useful to you, it's great that Rust can Just Work (TM) with the right setup. First-party tooling support is pretty great for a language to have!
If I had to choose, I think I'd pick a language that I'm comfortable with (C#, Kotlin, Java) and has the necessary libraries easily available, and see if the tooling works well for my use cases.
I'm also watching Zig evolve with interest; it's not quite there yet, but it's integration with C libraries and some of its more modern language features are very promising. WASM code doesn't need many of the complexities modern languages bring, but older languages like C can lead to dangerous programming paradigms, so I think a mix between the two can produce clean, performant and fully-featured code. I wouldn't recommend it for production use yet, though, as the language is still in constant development with breaking changes between point releases!
To be honest, I would even consider C for WASM despite my usual rants, after all with the security sales pitch for Webassembly it shouldn't matter after all.
Agreed, without the risk of memory corruption and the associated security risks, C can be used without too much hesitation (as long as your complicated pointer code doesn't break your own data structures and mess up your program, of course!).
I think it would be a challenge to compile all dependencies for a fully features C program into WASM, but if you pick your libraries well, C could be an excellent language for speeding up complex calculations in Javascript.
The problem with Rust is that to write good Rust, you need to accept that you can't use the same approach to solve a problem you could use in other languages. The borrow checker and its implications aren't necessarily difficult, but they're different.
I'd compare the experience to someone who started in Python learning Haskell for the first time: it can take weeks or more before one can truly understand a monad. If you start with basic functional programming you can be quite productive before you need such code structures, but when you open a code base where monads are mixed liberally, your head will be spinning.
Rust may be a lot closer to traditional imperative languages, but the implications of the safety mechanisms in the language are something you can't just skip over. It'll take time and practice to write code that the Rust compiler likes.
If you're getting started, I'd recommend writing some toy programs for the CLI instead. I also recommend using "clippy" to warn you of code smells (it'll suggest improvements when it can!) and to get links to specific problems you might not be aware of. As for the IDE, I recommend the rust-analyser plugin over the native "Rust" plugins found in most IDEs, because the basic ones fail to do proper macro expansion and leave you guessing on how to use libraries.