I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI. But at this early stage, there's no common stdlib for all languages to share.
Uhhhhh. This sounds like a kind of silly thing to say, when you just described the jvm. Except for the part where there is a common stdlib.
However since Java 8, the java.lang numeric classes do support unsigned arithmetic.
Yes it is a bummer that byte is signed, requiring extra math to simulate unsigned.
Yeah, and it's huge and interconnected (just see how much they had to do to get a java.base module and how large that still is). And the JVM has lots of specifics around threading, GC, OOP, classes, security model, etc. And many of those specifics don't translate to the needed safe-by-default, minimal-by-default bytecode for the web and other targets.
I could really go on for a long time about why applets failed and why JVM bytecode and the JVM runtime are terrible for the web (and any generic bytecode that doesn't target the web can't really be that generic). What is silly is ignoring all of this. Think about why there are already C++-to-WASM compilers after such a short time and no reasonably-usable and maintained C++-to-JVM compilers.
That is how many maninframes work, and the original idea behind the CLR.
CLR was designed to be able to support multiple kinds of languages, including C and C++.
At the release event there were about 40 languages being supported by multiple vendors.
The SDK being offered across multiple developer magazines had samples for several languages.
CLR was born from Ext-VOS project, formelly known as COM Runtime, the idea being that Windows would eventually be fully .NET based.
The idea never came to be, because .NET belongs to DevTools and Windows team was never happy with it.
The biggest example being the sabotage during Longhorn development and how the Phoenix, Singularity and Midori projects were received by them.
Also CLR always had the option of AOT compilation.
Initially via NGEN, Bartok in Singularity later adopted in Windows 8 for store apps, Project N from Midori later .NET Native for UWP apps.
And also in addition to a stdlib, maybe a great package management system. Is there a popular crate / maven / npm etc equivalent out there for wasm yet?
I haven't dug deeply but it seems from the documentation that the project is trying to do things the 'right' way (mapping instructions to JVM bytecodes at a low level)... as opposed to, say, trying somehow to compile to Java code.
1) There is no way to allocate in a function's variable stack continuous memory space that spans more than 8 bytes. This implies that if a function has as a local variable compound data structure such as an array or a struct, you have to a) have a global virtual stack pointer, b) manipulate the stack pointer to allocate space for the data structure in the virtual stack on the memory, c) read from or write to the allocated memory space, and finally d) restore the stack pointer before the function exits. This is exactly like what resulting assembly code of C compiler does. Why do we have function locals as a WASM primitive, then, if we have to end up with manipulating the stack pointer?
2) Currently a function can only return one value even though it is trivial to add support to mutiple return values taking advantage of the fact that WASM is stack-based. And what puzzles me is that mutiple return values is actually mentioned as a possible feature in the future, in several places in the spec. WASM reached the MVP before adding it, which means that we will have to stick with one-return-value functions for quite a long time even if it is added in the future.
>Avoid unrelated controversies and generic tangents.
“TeaVM is for you, if:
- You are a Java developer and you are going to write web front-end from scratch.
- You already have Java-based backend and want to integrate front-end code tightly into your existing development infrastructure.
- You have some Java back-end code you want to reuse in front-end.
-You are ready to rewrite your code to work with TeaVM.“
Transpilation: text to text (eg: Scheme to C)
Compilation: anything to anything but usually it implies text to binary code
transpilation is compilation but compilation is not necessary transpilation (the all squares are rectangles but all rectangles ...)
But you can see the term of the day, "translator", here, and it isn't much of a leap to see how that evolved into translator-compiler, and then shortened itself.
 XLT86, 8080 to 8086 Translator http://www.s100computers.com/Software%20Folder/Assembler%20C...
 Pg. 47, Trans Z80 to 8086 Translator http://www.patersontech.com/dos/Docs/86_Dos_usr_03.pdf
The first is a generic "translating from one source programming language to another, producing translated source code in the other language". This is basically compiling, except that it excludes "non-source" languages from the output.
The second, which looks more rigorous to me, is "taking source code written in one language and transforming into another language that has a similar level of abstraction" (found for example here: https://www.stevefenton.co.uk/2012/11/compiling-vs-transpili...).
Both are totally unnecessary because if you mention or know the source and target languages of your compiler, then you already know if it fits those definitions or not.
For example, "Transpile Java Bytecode to WebAssembly" adds exactly zero information to "Compile Java Bytecode to WebAssembly", because the word "transpile" only carries information about the relation between the languages you are processing and that is an already-known variable. As it is every time I see this word.
> For example, “Transpile Java Bytecode to WebAssembly” adds exactly zero information to “Compile Java Bytecode to WebAssembly”
No, the point is that ‘transpile’ more narrowly defines the action being undertaken. While all transpiling is a form of compiling, the reverse is jot true. Specifically from the second definition you cited transpiling connotes that a similar level of abstraction is retained. Often this means that type level information is retained. It’s similar to the distinction of lossy vs lossless compression.
Guess how he reacted when someone used the phrase "isomorphic js"...
Oh, this is nice. I finally have a reason to give Kotlin a go. I have some time off and want to write something basic. Pretty excited about this, Rust, and all things wasm popping up.
I am, in no way, excited about debugging it, though.
With the release of other ahead of time compilers/VMs/features for the JVM/Java9, I cannot fathom this produces a small enough payload for a web app over a mobile connection.
Im probably totally missing something; could someone educate me on practical or even useful but novel applications of this?
Performance is not too shabby either
Should someone want another VM to run their code in; how, good is this at reducing the size of the std lib or the JVM itself? Can I depend on useful packages with this, or will they immediately shit the bed? Will the payload be something like 150mb?
And even more in 0.6.x (including Stream API)
In other words, this is enabling a subset of well behaved applets, while excluding the naughty (or advanced) applets.
As for Java libraries, TeaVM is able to throw away unused parts of it, producing relatively small binaries.
I always here these arguments, but if you develop an angular application and somehow can't turn on AoT you need to download a ton of stuff, too.
I haven't used applets in the time, but if the user experience would be improved (nice looking UI, respecting modern UX conventions, etc.), I imagine your average applet from circa 1999 would run circles around Gmail, for example :)
Not amazing, but decent.
The browser won't have to re-download on each page load because the browser has a cache, which can be validated on each page load to check for updates.
So - since a quick research did not turn up anything - is there a WASM to C "transpiler" that generates readable C?
I'm not aware of one, though it would probably be trivial to write. https://github.com/WebAssembly/binaryen has the helping code for things like parsing. Both https://github.com/kanaka/wac and https://github.com/WebAssembly/wasm-jit-prototype interpret WASM. The latter even JITs into LLVM IR.
Is it of the stop-the-world kind?
Because, as we all know, web development you never compile things... /s
We're fresh and new and iterating quickly on our MVP, so we don't have time to wait for long compilation time. Instead we transpile our code and run it in a serverless environment, a docker container or a browser.
... Waiting for tens of seconds, or minutes, until all the JS libs are loaded into their GB's of RAM by their GHz multicore processors while those old veterans compiled all their stuff within a second on their ancient Turbo Pascal on their ancient MHz CPU's with barely noticable 64K RAM :-)
for those who aren't familiar with transpiling, in this case it's kind of a legitimate use of the term: taking one flavor of compiled code (java bytecode, binary stuff that runs on a jvm) and translating that directly to another type of compiled code (wasm, binary stuff that runs in a browser)
My (less sarcastic) understanding was that "compiling" means translation from a "high-level"/"humans-first" to a "low-level"/"machines-first" language while "transpiling" is translation from one high-level to another high-level language.
That would make gcc, clang (mostly) and javac clear examples of compilers while GWT, coffeescript and the C preprocessor would be transpilers.
I guess TeaVM would fit neither by those definition but it would definitely be closer to a transpiler.
Then again, I believe GWT calls itself a compiler, so I got nothing...
Here, we start with Java byte code which isn't exactly human-readable, hence the use of the term "transpile". But then again, you're right that on some abstract level, it all is just a translation process from one representation to another.
"A rose by any other name would smell as sweet."
> A compiler is computer software that transforms computer code written in one programming language (the source language) into another programming language (the target language).
Later on it lists some classes of compilers that could be called by more specific names than just "compiler".
"Compilation means taking one type of compiled code and translating it into another type of compiled code."
Actually, there is no such thing as a "transpiler". There are only compilers which are programs which translate from one regular language A into another regular language B. It doesn't matter whether B is a high-level language or low-level machine code.
In any event, is it so bad to have another word for source-to-source compilation? What is it that angers you about it?
If you compile C to Assembler then you compile from one code (C) to another code (Asm, or machine code which is the compact form of Asm). What's the difference to a "transpiler"?
Wikipedia states that the difference is just the (almost) equal level of abstraction. I would call such a thing a high-level source-to-source compiler. The word "transpiler" is uncertain and barely known, hence the people here who ask what a transpiler is.
Cross-compilation is another thing since it means compiling on one platform for another platform. In all three cases we deal with compilers from one regular language A into another regular language B.
cross-compile: convert from one language to another that will be executed on another platform (e.g. compiling something on a linux box to be ran on a windows machine)
transpile: convert from one (typically high level) source language to another (high level) source language
Btw deactivating WebAssembly support in Chrome 63 (up-to-date) doesn't work anymore!!
Just wait until it gets a bit more mature.
That said, it will lead to more closed commercial sites, but the JS outputted from webpack+babel+uglify is already unbelievably difficult to wade through without source maps. It's not significantly different imho.
WASM is portable binaries.
I agree with you that we've lost though: no amount of protest is going to make people stop using the word "transpiler".
It is generally assumed that a compiler goes from high level to low level, a decompiler low-to-high and a transpiler high-to-high. I guess in this case the transpiler is low-to-low, so maybe "transpiler" is just used to mean "samey-to-samey"
> At the point where we are calling things that compile to assembly "transpilers" I don't think there is any distinction left
"Transpiler" is grating (apparently).
does this seems like another instance of the annoying practice in our field of someone giving a name to a thing because they think it's new, though it's not (ie, source-to-source compilers have been around as long as source-to-bytecode compilers)--no need to re-name them
wish they would just stop it and get the hell off my lawn
Thankfully in most jurisdictions it is forbidden by law to do as such.
 - https://news.ycombinator.com/item?id=16076823
 - https://hackernoon.com/moving-to-es6-babel-and-transpilers-3...
The frustrating bit is that this is absolutely not true. A compiler is anything that parses some text according to some grammar, manipulates it, and emits it in a different format. While the most well-known and popular compilers are for C, to emit machine code, there's nothing inherent in the definition of a compiler that means it can't emit something human-readable.
Then the JS world came along and decided to use a new word to make it look more hip and cool.
A friendly FYI... the old word "transpiler" has been around since at least the 1960s. See the 2nd-to-last paragraph on the last page:
edit: Apparently 60's.
Is it YACT now?
Just ask folks how this term differentiates from Compile and you'll get wildly varying answers and definitions.
Using the term for anything where the source is JVM bytecode is plain wrong, and it's also dubious for anything targeting WebAssembly (though if the target is specifically .wat/.wast, it may perhaps be arguably defensible.)
so i guess one might use "transpile" wrt bytecode in the spirit of that. but i guess asm source files are still "human readable", where bytecode generally isn't considered as such.
 P47, "TRANS": http://www.patersontech.com/dos/Docs/86_Dos_usr_03.pdf
I don't see why the existence of a grey area should be enough to question the utility of the term.
If compile/decompile are used for a transformations along one axis, transpile is used for transformations that are predominantly orthogonal to that axis.
Given the large inconsistency and incompatibility between all these definitions and the existence of a well-accepted term that comprises all of these definitions, is it a mystery why people question the utility of the term? After all, what use is a nuanced term if it can't reliably convey that additional information.
I would recommend the general term "A/B compiler" where A and B are arbitrary regular languages. That way it would be pretty clear what a Pascal/C compiler is, or a JVM/Webasm compiler, for instance. Or a x86/C compiler which would also make the word "decompiler" obsolete.