V => JavaScript translation this week and other future possibilities

[medvednikov]

I'll be wrapping up the JavaScript backend this week, so that the playground can be implemented using a V compiler running in the browser.

I'm not a fan of JavaScript and I wanted to use WebAssembly instead, but I had to rely on Emscripten, since generating WA from scratch is a lot of work (the entire V compiler has to work well with it). That meant that I also had to run a C compiler via WA, but that could only be done via x86 emulation in the browser... and that's way too complicated and buggy.

The good thing is I made the compiler a lot more extendable, and adding other backends is trivial now, so we'll potentially be able to do V => Java, V => Go, V => C# etc.

And since the plan is to have translators from other languages to V (C/C++, Go, etc), V can become a lingua franca of the programming languages and allow translation between any two languages (e.g. C++ => V => C, Go => V => Java etc).

What do you think?

@elimisteve @ylluminate you'd probably be interested in this :)

[ylluminate]

Alex, I agree that this is the right move re: Emscripten. Efficient and will grow in parallel with V since it's important for other initiatives.

Personally we've looked at various other options in the past in the hopes and goal of coming to a universal language and there's always been some impediment to stop things (Ruby + Opal (esp. via Hyperstack.org) and RubyMotion for native deployment are close'ish, but not completely cohesive; Hyperstack.org + Apache Cordova are closer, but then you've got the seriously problematic performance issues on Mobile and Desktop; Unity is interesting, but there's no solid UI lib initiative to really push Unity into standardized universal UI implementation, etc. and no direct lib cohesion for the web options like Blazor and it - in other words you end up with using the same language, but you can't really have the entire project in the same repo; Dart + Flutter is not my cup-o-tea as I'm sure you can understand). Sooo, the last thing I was looking at quite some time ago was how to use Emscripten with Crystal to work with WASM, but there were Boehm GC issues at the time, and some other discouraging findings so we shelved it in hopes that a few things would be resolved.

So YES, your choice makes sense and is reasonable. Furthermore, it can only improve with time as the technologies mature. Furthermore Emscripten can also facilitate running on non-WASM browsers as well and as needed. This is a good thing.

As you know, my / our goal is to have a universally deployable language so that our apps are isomorphic - eg: same language from server to client (and preferably deployment and beyond - excited about V shell usage still 🤤). The idea of V becoming the lingua franca is extremely attractive to anyone who understands the DISadvantages that programming polyglots actually have (it's funny how people seem to miss this presently). Wouldn't it be amazing if we were all just machines ourselves and could use assembly or binary directly? 🤭

Another thing that this compiler extensibility could help with is the concept I threw out before of being able to fork projects and then being able to diff changes in from the trunk whenever commits are made. Your new approach can also make this same concept reversible and thus valuable to project origin owners. Instead of being a competitor, V can be seen as a companion or partner - TEAMWORK always trumps competition. I think this spirit of cooperation will be socially very valuable, especially with some of the idiots running around irrationally denigrating V.

So yes, this is a big win. Again: universal app development both on the server and client (ie GUI / VUI) is with absolute certainty an enormous game changer. What you're saying definitely brings this much closer and fast.

[spytheman]

Having multiple backends in general is good.

I am afraid however that it may be too early for this.

The V language itself is still changing, and supporting each additional backend will cost us development speed.

(we can already see that with all the msvc related issues/PRs, and that is not another language, just another C compiler...)

[medvednikov]

I agree, but I wanted to implement an extra backend early, because otherwise it'd be too hard in the future.

msvc issues is just Microsoft being Microsoft :)

[ylluminate]

@spytheman while I agree that adding more than WASM (+ JS) emission via Emscripten is probably too early or an extra burden, I do think that adding the general tooling for such broad facilitation, as @medvednikov has said, early is the right move. I also think that at least WASM support is essentially critical due to its desirability and far reach.

[dumblob]

For JS/WASM this C-like arithmetic library might come handy.

[nachoverdon]

If you do V -> Haxe, you'll basically have V -> C, C++, C#, Java, JavaScript, Python, PHP, ActionScript, Lua, HashLink, HashLink. Might be worth prioritizing V->Haxe and then add native support to translate to those languages directly.

[ylluminate]

That is very interesting @nachoverdon. I don't necessarily think Haxe should be a priority over direct WASM since Emscripten is carefully specialized and really fantastic for both WASM + JS generation (also, the bulk of platforms will already be covered without Haxe, but I guess we could / should explore this more: https://www.reddit.com/r/haxe/comments/7l2ehs/haxe_to_webassembly/), but this is definitely interesting...

The thing I fear, and perhaps it's entirely unfounded, is that a Haxe abstraction layer might complicate things a bit more than the current path @medvednikov is pursuing. Ie, with Haxe we'd be looking at V -> Haxe -> HashLink or Hxcpp -> WASM. Hmmm...

Also, curious, does Haxe do reverse conversion as well such as Lua, ActionScript, PHP, etc. to Haxe?

[medvednikov]

I agree with @ylluminate here

Adding another layer means more complexity, and a dependency on a not very mature application.

I made adding new backends very easy. I'm really excited and can't wait to publish my work.

Adding, say, a new Go backend, will take me about 2 hours in total.

[elimisteve]

I made adding new backends very easy. I'm really excited and can't wait to publish my work.

Excited to see it! Show it :smile: .

[dhonx]

That's a very good idea ... it looks rather difficult ... but I believe that all of you can do that ... if I have time ... I will try to help.

[dhonx]

@medvednikov Will it also involve node c/c++ addons ??

[herudi]

@medvednikov Will it also involve node c/c++ addons ??

Great idea. This is the N-Api list :

• official => C/C++.
• napi-rs => Rust.
• napi-nim => Nim.