Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM as a Platform for Abstraction

adventures.michaelfbryan.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: WASM as a Platform for Abstraction

#51

Post by ptx »

xuejie wrote: post #46
moring wrote: post #25

Earlier quoted context omitted.

> some implementation even needs LLVM to perform optimizations. I'd say if this is the case, we must've chosen the wrong model. Why? Optimizing machine-independent code for a particular machine is part of the "core business" of LLVM, up to the point where a sufficiently capable bytecode/optimizer becomes comparable to LLVM. OTOH, if the main argument here is the size/speed/other weight of LLVM, then of course the hos…

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"?

Re: WASM as a Platform for Abstraction

#52

Post by BiteCode_dev »

pjmlp wrote: 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 main frames could have been it, but they never were.

Let's try if we can make it work with a different name this time.

Re: WASM as a Platform for Abstraction

#53

Post by afiori »

ksec wrote: post #44
pjmlp wrote: 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.

Not sure why there are so many replies about this being dismissive. It is just pointing out people likes to reinvent technology every once in a while with 95% of the same thing. And it is not apparent whether those doing the "reinvention" knew what the constrain or trade offs or limitation the previous technology had. Sometimes these sort of Full Circle makes me wonder if software has really moved forward at all.

This is like the reaction people had to Dropbox on this very site [1]. Even if wasm was literally the same bytecode copied from an old mainframe the possibilities that this new use allows are enough of a novelty and an invention in and of itself.

I would find a comparison of wasm with older bytecodes very interesting as for sure none of them are perfect. But this kind of reply is clearly dismissive. It contains no criticism and it offer no insight over why some failed and other succeeded.

I essentially see it as lamenting that another similar technology was/is treated unfairly. Which is a fine comment, since many technologies meet a unjust or undeserved demise. It is still irrelevant as essentially boils down to "how dare you succeed where others have failed".

This is even worse than just saying that it is bound to fail miserably the same way Java applets did.

There are for sure negative sides to wasm, the fact that many parts are similar to past ideas is simply inconsequential on the merits.

[1] https://news.ycombinator.com/item?id=8863

Re: WASM as a Platform for Abstraction

#54

Post by DagAgren »

xuejie wrote: post #20
TomMarius wrote: post #15

Earlier quoted context omitted.

What major implementations are using LLVM? Firefox is using Cranelift, Chrome is using V8, both of these shouldn't be using LLVM, AFAIK, or am I wrong?

wasmer [1] has a LLVM backend, WAVM [2] uses LLVM as the bakend, I could be wrong but last time I checked, cranelift is only meant to be the next generation WASM engine used in Firefox, it is not yet in production. And actually the argument is: all of v8, Firefox/Cranelift and LLVM used in wasmer requires non-trivial work to make WASM fast, which shouldn't be needed given a different model. [1] https://github.com/was…

I highly doubt that there is another model that would not require non-trivial work to be fast, while also being reasonably portable to different architectures.

Sure, we could be faster by just sending x86 machine code, but that isn't really the point.

Re: WASM as a Platform for Abstraction

#55

Post by afiori »

xuejie wrote: post #46
moring wrote: post #25

Earlier quoted context omitted.

> some implementation even needs LLVM to perform optimizations. I'd say if this is the case, we must've chosen the wrong model. Why? Optimizing machine-independent code for a particular machine is part of the "core business" of LLVM, up to the point where a sufficiently capable bytecode/optimizer becomes comparable to LLVM. OTOH, if the main argument here is the size/speed/other weight of LLVM, then of course the hos…

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.

Re: WASM as a Platform for Abstraction

#56

Post by afiori »

pjmlp wrote: post #22
jahewson wrote: post #11

Earlier quoted context omitted.

Google created pretty much this, called it PNaCl and shipped it in Chrome. It now has been retired in favor of WASM.

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.

Re: WASM as a Platform for Abstraction

#57

Post by namelosw »

pjmlp wrote: 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.

It's more a political thing. Sun, Microsoft or other monopolies couldn't do it despite they are powerful. The difference is WASM is more neutral than other portable execution formats.

And one of the most successful 'Portable execution format' nowadays I believe is JavaScript. WASM is just a sequel of JavaScript.

Re: WASM as a Platform for Abstraction

#58

Post by mr__y »

TomMarius wrote: post #26
pjmlp wrote: 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 we're getting mainframe-like tech into the mainstream? Isn't it good?

If this was a conscious process, that is taking solutions from mainframe, analyzing them and deciding to use some of them also analyzing the knowledge,pitfalls, problems and experiences from the past and incorporating them into the new tech then this would be a good thing.

However if this is done through a simple reinventing the wheel route, there is a high chance of hitting the same walls and repeating the same mistakes.

This is kind of similiar to a "let's rewrite this code from scratch in new shiny lang/lib/framework" with the expectation that new code will be bug-free from the start. It's not always bad, it is sometimes necessary or it may turn out to be more effective than trying to fix bloated code. But very often the new code has problems exactly the same as previous code and effectively the developers reinvent the wheel multiple times in the process of rewriting.

Re: WASM as a Platform for Abstraction

#59

Post by zzzcpan »

afiori wrote: post #53
ksec wrote: post #44

Earlier quoted context omitted.

Not sure why there are so many replies about this being dismissive. It is just pointing out people likes to reinvent technology every once in a while with 95% of the same thing. And it is not apparent whether those doing the "reinvention" knew what the constrain or trade offs or limitation the previous technology had. Sometimes these sort of Full Circle makes me wonder if software has really moved forward at all.

This is like the reaction people had to Dropbox on this very site [1]. Even if wasm was literally the same bytecode copied from an old mainframe the possibilities that this new use allows are enough of a novelty and an invention in and of itself. I would find a comparison of wasm with older bytecodes very interesting as for sure none of them are perfect. But this kind of reply is clearly dismissive. It contains no cr…

WASM is not a startup, it's a very niche tech and pushing it to other niches as a "platform" needs a lot of investment and buy in from professionals and management working in those niches. Not that the idea itself of an intermediate representation is bad, it's just WASM is not necessarily good and the odds are definitely against it.

HN top comment on dropbox wasn't really wrong either. Triviality proved to be a valid point. Plenty of companies made similar software once they saw there was a need for it. I mean who still uses dropbox today?

Re: WASM as a Platform for Abstraction

#60

Post by apabepa »

AgentME wrote: post #32
pjmlp wrote: 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.

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
Post reply on HN