Related but more high level, I think we should have language sets instead of single languages with simpler interop and shared infra: <a href="https://gist.github.com/xixixao/8e363dbd3663b6729cd5b6d74dbbf9d4" rel="nofollow">https://gist.github.com/xixixao/8e363dbd3663b6729cd5b6d74dbb...</a>
Not sure if you're familiar with or heard about AssemblyScript [1]. It sounds like the goal you are trying to achieve, but with a saner approach: create a TypeScript-like language that compiles to WebAssembly. This means it gives you native access to SIMD, and eventually even threads! All while avoiding the overhead of learning a new language (well there are still some gotchas since it is actually a new language, but very close).
No need to think about whether you need to optimize X function or manually manage memory somewhere, and still get the awesome performance of Wasm.<p>[1]: <a href="https://www.assemblyscript.org/" rel="nofollow">https://www.assemblyscript.org/</a>
Hi! Author here. Really curious what you all think. It's a pretty crazy idea but maybe there's something to it! Hacker News is always a special place for ideas like this — you never know what you're gonna get ;) — so I'm looking forward to discussing this with y'all!
These two lines are worth looking at because they showcase why I am not really fond of Rust as much as people who would rewrite everything from the Linux kernel to the IMF in Rust if they could (which in itself is seriously off putting if my tone didn't tell you that):<p>type Vec2 = { x: number, y: number };<p>function avgLen(vecs: Vec2[]): number<p>versus:<p>struct Vec2 { x: f64, y: f64 }<p>fn avg_len(vecs: &[Vec2]) -> f64 {<p>There has been more than two decades between the release of Perl and Rust and you haven't learnt anything? Wow. Listen: code written in languages heavy with sigils and shorthand are hard to understand, read and most importantly: maintain. This adds a mental load which is -- as clearly visible from above -- is totally unnecessary. I have no idea why would anyone in 2010, several years after the famous "memory is the new disk, disk is the new tape" do this to save on characters in the source code. The teletype is a distant memory.<p>Thanks for letting me vent a little.
> Various articles have been written, comparing the performance of Javascript versus WebAssembly ("Wasm") in the browser.<p>Nit pick: Every word in this sentence in the article is a link. This way of linking multiple related resources is so hard to keep track of and navigate. I need to hover over or click each word to discover the resource.
I wonder if you've looked at AssemblyScript <a href="https://www.assemblyscript.org/" rel="nofollow">https://www.assemblyscript.org/</a>
Sorry for nitpick, but in the TypeScript example, should it be<p><pre><code> for (const vec of vecs)
</code></pre>
Instead of:<p><pre><code> for (const vec in vecs)</code></pre>
We briefly toyed with the reverse idea; wanted to share some code between web and native, and TypeScript / C++ already look very similar - what if we invented a subset of TypeScript that can be simply translated into C++ (as long as you stick to static use and types).<p>Worked ok for a while but broke down real quick once we brought in external npm dependencies.<p>Now we're just embedding V8 in our native apps and running the TS code through that. Not as interesting, but lets us import any random npm package (which is both good and bad).
I thought WASM was considered slower than JavaScript only for the use cases where heavy usage of DOM is necessary. Since that's not available through WASM it needs to make a call to a JS function to perform the DOM manipulation and that incurs extra overhead.<p>I think these cases will just never be good for WASM. DOM manipulation heavy Apps (which is a good chunk of JS code out there) may continue to be in JS and only the CPU intensive tasks would be computed in WASM.<p>Isn't that the best practice for WASM?
A feature that Haxe offers could help here. Abstracts are compile time only types of which the implementation is fully inlined. Meaning we could define an abstract over ArrayBuffer which has an iterator of abstracts over Float64Array which define the x and y property getters. Once compiled the code will look very similar to the example given. It's one of the things I miss the most in TypeScript, coming from haxe.<p><a href="https://haxe.org/manual/types-abstract.html" rel="nofollow">https://haxe.org/manual/types-abstract.html</a>
<a href="https://code.haxe.org/category/abstract-types/color.html" rel="nofollow">https://code.haxe.org/category/abstract-types/color.html</a>
Sounds like BorrowScript; which is TypeScript syntax, a Rust borrow checker, and Go-like coroutines. It's designed for wasm and web api targets. (not compatible with TypeScript though)<p><a href="https://github.com/alshdavid/BorrowScript" rel="nofollow">https://github.com/alshdavid/BorrowScript</a>
I've never written (or even read) JS code with ArrayBuffers. I wonder how much mileage you might get with better education and/or libs for using them? And perhaps a highly opinionated linter for things like optimal for-loop patterns?
Dumb question: Do you mean "Fast" as in speed of execution, or "Fast" as in compile times? (Or maybe you mean both? I haven't used Rust.)<p>Might be worth clarifying because I immediately got excited about a faster TypeScript compiler!
Sorry, are we saying that Typescript is as fast as Rust in general, or when Rust is compiled to WASM, or what? I am confused and don't know enough about the problem to figure it out myself.
The older I get the less I care about "expressive power" and "speed of development". I don't view these things as an advantage most of the time, actually often the opposite. The price is always paid later on, and it is high.
> <i>Toolchain integration can be daunting. You need to set up Rust in development builds, production builds, local testing, continuous integration, and so on.</i><p>Impressive that someone familiar with the usual JS development toolchains can write this and keep a straight face...