Live data from Hacker News

WASM as a Platform for Abstraction

adventures.michaelfbryan.com

71–80 of 85 posts

Re: WASM as a Platform for Abstraction

#71
post #60
post #32

Earlier quoted context omitted.

Sure it's been done before. The point is that WASM is a good, efficient, sandboxed, modern example of it that's usable now with a large software ecosystem around it.

What does modern mean in this context? I see this word being used a as a positive adjective a lot recently to describe rewrites etc but it is unclear to me what it actually implies

The term is overused, yes, but one way it can be understood in wasm's context is that there is now a generic platform/target and we have consensus on it. It's hyped, the inertia is there, so all of it is going to happen. And in this particular case it's a good thing. :) Probably soon we can stop rewriting everything in javascript.

Re: WASM as a Platform for Abstraction

#72
post #16
post #13

Strange. Something like node.js for running server side WASM programs, maybe. But hard real time? That's a strange application for this. Why add the additional layer?

Where does it say hard real time?

Where it says: "While this section will be fairly specific to my use case (creating some sort of programmable logic controller that people can upload code to), it should be fairly easy to adapt to suit your application."

Re: WASM as a Platform for Abstraction

#73
post #23

Earlier quoted context omitted.

Open source LLVM IR is machine specific, it doesn't have to be, as proven by watchOS bitcode, or PNaCL.

Both of the examples you gave were very carefully architected to make sure that was the case.

Which doesn't prevent the case of someone contributing back such kind of variants.

Re: WASM as a Platform for Abstraction

#74
post #56
post #22

Earlier quoted context omitted.

Because Mozilla went political and came up with asm.js as counter technology.

Or as some other (like, eg Google itself) would say: > Because Mozilla went political and came up with asm.js as better technology.

I am pretty sure that asm.js would not happened if Chrome already had the market share it enjoys nowadays.

WASM is still catching up to PNaCL in performance, hardly better.

Re: WASM as a Platform for Abstraction

#75
post #19

WASM advocates keep rediscovering the benefits from bytecodes as portable execution format, while presenting them as something great made possible only by WASM. Reading a bit of mainframe history would do some good it seems.

Yeah but WASM is an open standard that big names in the industry agreed on, including Foss advocates, with a design to accomodate many popular languages and the most popular plateform in the world: the web. So it has actually a chance to not be limited to one ecosystem or one company. In fact, the simple idea that it's going to have a monopoly in the browser pretty much guaranties a broad attempt of adoption. JVM and…

Ancient bytecode formats were mostly about multiple languages support, also here WASM is hardly innovative.

And some of them, also with multiple vendor offerings.

Chrome already has preview features available, that other browsers might adopt, or not.

Re: WASM as a Platform for Abstraction

#76
post #60
post #32

Earlier quoted context omitted.

Sure it's been done before. The point is that WASM is a good, efficient, sandboxed, modern example of it that's usable now with a large software ecosystem around it.

What does modern mean in this context? I see this word being used a as a positive adjective a lot recently to describe rewrites etc but it is unclear to me what it actually implies

By that I mainly meant that it runs on today's systems and maintained languages and toolchains today can target it. Sometimes in discussions about WASM, I see people bring up ancient bytecode formats in a way that makes them sound like usable alternatives.

Re: WASM as a Platform for Abstraction

#77
post #38
post #19

WASM advocates keep rediscovering the benefits from bytecodes as portable execution format, while presenting them as something great made possible only by WASM. Reading a bit of mainframe history would do some good it seems.

So what? A lot of people are also complaining that it resembles the JVM. Do you think that historical mainframe bytecodes would have been a good match for web applications? I don't know, I know nothing about mainframes. I do not understand if your criticism is that they are making mistakes that have already been solved half a century ago (which is a good criticism, if true) or that they are not giving proper recognit…

Not even when talking about the Web alone, WASM is innovative, PNaCL did it first.

Chrome PNaCL SDK came with C, C++ and OCaml support, with an open source version available, which Mozilla refused to use and came up with asm.js instead.

Re: WASM as a Platform for Abstraction

#78
post #23

Earlier quoted context omitted.

No, LLVM IR is machine specific. Any "native" language is since the ABI of a struct will depend e.g. on the size of pointers for that platform. E.g. Consider in C int foo[sizeof(void*)];

Open source LLVM IR is machine specific, it doesn't have to be, as proven by watchOS bitcode, or PNaCL.

> it doesn't have to be, as proven by watchOS bitcode, or PNaCL.

Both of those have fixed 32-bit pointer sizes and are little-endian. When you compile for watchOS bitcode or PNaCL you just target a single virtual machine & "system" ABI. LLVM IR or any related techniques won't ever allow you to produce a 32 / 64 bit or ARM / x86 app that is able to leverage the whole feature set of the platform from the same bitcode.

Re: WASM as a Platform for Abstraction

#79
post #55
post #46

Earlier quoted context omitted.

There's nothing wrong with LLVM itself, my point is we could've picked a lower level model which don't need a complicated setup like LLVM. Or one that you can direct shipped optimized compiled result of LLVM, that will be a much better world

I believe that you are looking at wasm with a different priorities than intended. The two fundamental properties are that it must be fully portable and fully secure by default (as in any insecurity needs to be explicitly and statically declared in the bytecode). Performance comes only after those two. LLVM as far as I know, has a completely different order of priorities.

Personally I don't see why we cannot get all three.

Re: WASM as a Platform for Abstraction

#80
post #51
post #46

Earlier quoted context omitted.

There's nothing wrong with LLVM itself, my point is we could've picked a lower level model which don't need a complicated setup like LLVM. Or one that you can direct shipped optimized compiled result of LLVM, that will be a much better world

Doesn't ARM code emulated on x86 (and vice versa) perform even worse than WebAssembly? Isn't that essentially what you would get with a lower-level "optimized compiled result of LLVM"?

Does the fact that ARM is a bad choice disproves all other choices other than WASM? I'm not sure this is a good argument here. Lower-level bytecodes are more flourishing than just ARM.
Post reply on HN