The goal is indeed to support any language, but supporting any language is difficult to pull off without huge delays.

WebAssembly is currently focusing on languages that are traditionally compiled ahead-of-time, work well with on linear memory heap, and which don't require dynamic recompilation, runtime code loading, or garbage collections. Some of these constraints were there to get to a Minimum Viable Product as early as possible (this happened in February 2017), and take into account what existing in-browser compilers can do.

Note that the MVP doesn't support threads. Threads will be added shortly after.

Python, JavaScript and Ruby can easily be supported by compiling an interpreter, written in C/C++, to WebAssembly. Later versions of WebAssembly will support JIT-compilation, but engines like V8 will have to target WebAssembly as if it were a new ISA (e.g. on par with x86-64 / ARM / ...).

C# and Java require similar GC and stack manipulation primitives. That's also on the roadmap, but after MVP, threads, and dynamic linking.

Note that the languages may work just fine, but supporting all their libraries is also difficult! We (browser engineers) can work towards supporting languages well, but we need communities to build up around great library support.

Will WebAssembly replace JavaScript?

On your last sentence: yes WebAssembly should be able to do many things JavaScript can do because it'll have access to the same Web APIs. Its goal isn't to replace JavaScript though: it's to complement JavaScript, avoid adding features to JavaScript for the sake of un-naturally supporting other languages, and offer predictable near-native performance to low-level languages such as C++ / Rust.

Keep JavaScript evolution for folks who target JavaScript or compile similar languages to JavaScript (e.g. TypeScript), and evolve WebAssembly to be JavaScript's cool sidekick who likes other languages.

Eventually WebAssembly will support even more low-level features. Some of these wouldn't make sense for JavaScript to adopt, yet existing code (e.g. large C++ codebases) assumes these features exist for correctness and / or performance.

Should people stop writing JavaScript and switch to WebAssembly? No. I expect the tight integration with JavaScript means that WebAssembly modules will be used from JavaScript (say, a fast image processor), and existing C++ codebases will target the web, but I don't see JavaScript dying any time soon.

I think in this case gradually, written in javascript code will be transferred to a more preferred programming language.