[HN Gopher] A world to win: WebAssembly for the rest of us
___________________________________________________________________
A world to win: WebAssembly for the rest of us
Author : nsm
Score : 132 points
Date : 2023-03-20 18:27 UTC (4 hours ago)
(HTM) web link (www.wingolog.org)
(TXT) w3m dump (www.wingolog.org)
| kumarski wrote:
| cloudflare did a piece on how WASM supports it. ~18% of all
| websites on the web run through cloudflare.
|
| https://blog.cloudflare.com/big-pineapple-intro/
|
| (I'm not a software developer)
| Animats wrote:
| Rust targets WebAssembly, which apparently works well because
| Rust is not garbage-collected.
|
| When will WebAssembly get real threads, not just shared memory
| between processes? I've seen articles from years ago talking
| about it as a future feature. Current status?
| dheera wrote:
| Could one just treat WebAssembly as virtual bare metal,
| implement a multithreaded OS in WebAssembly and then spawn
| threads inside that?
| paulgb wrote:
| Technically you could, but they'd all be run on the same CPU
| core.
|
| You could spawn a Web Workers for each core, in theory,
| although some browsers will lie about the number of cores.
| wahern wrote:
| That's basically how the Go WASM runtime works[1], except
| when calling outside the WASM virtual machine (e.g. invoking
| a JavaScript function) the entire Go runtime must block.
|
| [1] The Go compiler inserts yield calls (preemption
| opportunities) at various points in the emitted code, such as
| at function invocations and within loops.
| harikb wrote:
| Half of the article is entirely about GC.
|
| > Support for built-in GC set to ship in Q4 2023
| dboreham wrote:
| Parent is asking about threads not GC.
| duped wrote:
| What is a "real" thread? A POSIX thread?
|
| The entire notion of processes and threads is a bit weird
| inside of a WASM module. Arguably a WASM module shouldn't care
| about them at all - the host runtime should be managing
| parallelism.
| fsckboy wrote:
| what do you see as the important difference between real
| threads and interprocess shared memory?
| brigadier132 wrote:
| Never because real threads can be used to break out of the
| sandbox using spectre.
| RealityVoid wrote:
| Can what now? I was under the impression spectre gave you
| access to data, not arbitrary code execution.
|
| Also, I imagine that web assembly is a bytecode format and
| that should be _less_ susceptible to spectre.
|
| Can you expand? This seems wrong to me.
|
| Edit: read some papers, I'll be damned, it can. I don't
| understand how tho'. Would love to try playing with a POC
| that does that.
| flohofwoe wrote:
| See
| https://blog.mozilla.org/security/2018/01/03/mitigations-
| lan...
| flohofwoe wrote:
| SharedArrayBuffer had been disabled for exactly that reason
| but has been enabled again for cross-origin isolated pages
| (https://developer.chrome.com/blog/enabling-shared-array-
| buff...) - which in turn allows to have 'proper' pthreads in
| Emscripten: https://emscripten.org/docs/porting/pthreads.html
| tjoff wrote:
| > _the initial version of WebAssembly is a terrible target if
| your language relies on the presence of a garbage collector._
|
| Lack of GC was one of the appealing parts of WASM to me. Keep it
| simple. It is good to be careful about utilizing memory on your
| visitors machines, so you better spend a lot of thought on memory
| management.
| wahern wrote:
| If the WASM module has no GC'able objects, then there'd be no
| reason for the GC to run. At least in theory. Certainly the 0
| GC'able object case seems like an easy optimization.
| tjoff wrote:
| Yeah, but once GC is an option 99% of the sites you are going
| to visit will utilize it and use as much resources that they
| could ever "get away" with.
| remexre wrote:
| Isn't it more likely that if there never was first-party
| GC, everyone who wants GC is just going to bundle a bad one
| instead, making those sites _slower_?
| wahern wrote:
| Maybe. Everybody assumes that once WASM gets a GC framework
| that their favorite language, e.g. Python, will become a
| first-class citizen. But I suspect this won't come to pass
| for two related reasons:
|
| 1) There's no such thing as a universal GC. GC semantics
| differ across languages because the semantics matter;
| language developers make different choices. For example,
| some GCs support finalizers, others don't. Some with
| finalizers support resurrection, some don't; likewise, some
| languages specify a well-defined order for finalization
| (e.g. Lua defines it as the reverse order of allocation).
|
| 2) Similar to GC, there are other aspects that will prevent
| popular languages with complex runtimes from being compiled
| directly to WASM without altering language semantics or the
| runtime behavior relative to the standard, native
| environment. For example, eval.
|
| So even with GC, the choices will likely remain the same as
| they are now: if you want the full experience of your
| favorite, rapid-development language within the WASM
| virtual machine, you must incur runtime overhead, up to and
| including double virtualization. Or, alternatively, you
| must contend with a bifurcation in a language ecosystem--
| native semantics vs WASM semantics. This will all be
| compounded by how programmers typically treat even the
| slightest differences, compromises, or concessions in
| behavior or performance as ritual impurities to be shunned.
| Ultimately, I don't expect the current status quo changing
| --languages other than statically compiled, strongly typed,
| non-GC'd languages like C, C++, Rust, or similar seeing
| much more usage in WASM environments than they already do,
| either browser-side or server-side.
| aseipp wrote:
| Existing compilers for GC'd languages that target
| WebAssembly today have to use inefficient schemes to make
| their runtimes work, making the website slower than they
| would be otherwise, which is pretty much the entire point
| of OP.
|
| And anyway, regarding "lack of GC in WASM made it
| appealing" -- support for high level languages with GC
| semantics was always a long-term goal for WebAssembly and
| GC was thought about by the relevant parties long before
| the 1.0 spec was even ratified (the initial placeholders
| were added as early as 2017, 2 years before 1.0
| ratification); it was just not within scope for the earlier
| versions because it's a pretty big topic, including many
| things that aren't even wholly GC related e.g. value types.
| But this isn't surprising either; most of the earliest
| implementations and concerned parties were browsers, and
| the interactions between WebAssembly and JavaScript's
| memory models, along with the popularity of Javascript-
| targeting compilers (which suffer from many similar
| contortions), meant that GC was always a pretty obvious
| "This is a thing we need to think about in the long run"
| feature.
| quickthrower2 wrote:
| Not sure how that follows since JS exists and a lot of people
| are going to just build on a runtime anyway.
| haberman wrote:
| I'm one of the biggest GC curmudgeons, but as long as it's an
| opt-in thing that you do not pay for when you do not use, I am
| happy.
|
| I speak as the kind of developer who wants to optimize the
| memory management.
| tjoff wrote:
| As a developer, absolutely!
|
| But as someone who uses the internet for browsing, strong
| disagree.
| FpUser wrote:
| >" Where are the F#, the Elixir, the Haskell compilers? "
|
| I think it makes a lot of sense sense to target WebAssembly with
| high performance "native" languages like C/C++/Rust/Zig/etc for
| certain types of apps looking for high performance computations.
| As for the rest it is simpler to just use JavaScript as the
| browser already makes a great platform for it.
| chrisco255 wrote:
| WASM isn't just for the browser though.
| syrusakbary wrote:
| This is awesome, always great to read Andy Wingo blogposts. Eager
| to see what the future of Scheme in Wasm looks like!
|
| Here's a bit more or info on the Spritely side on why they want
| Scheme in Wasm (it's both funny and great to see how the money on
| decentralized/web3 projects is leaking back to the real world!)
| https://spritely.institute/news/guile-on-web-assembly-projec...
| DeathArrow wrote:
| Blazor had to ship the whole .NET runtime to have support for
| garbage collector and threads.
| qclibre22 wrote:
| How big is it?
| HideousKojima wrote:
| I think it's currently around 2 MB, they've been working on
| shrinking the download with each new .NET release
| mrbonner wrote:
| One question that really bugs me the the sandbox security model.
| I'm sure the model protects us from memory and IO hazards. But,
| what about CPU-time sharing protection? I have yet to know if
| WebAss (or any abstract machine out there) could provide
| protection from a rouge module, running at 100% CPU in an
| infinite loop. I'm sure a true virtual machine could limit such
| thing.
|
| Edit: spelling
| flohofwoe wrote:
| It's the same as running a Javascript infinite loop. The
| browser will kill the tab if a WASM module doesn't yield back
| to the browser's event loop after a few seconds.
| pphysch wrote:
| What's the difference between <script>WebAsse
| mbly.instantiateStreaming(fetch("cpu_waster.wasm")...</script>
|
| and <script>while (true){};</script>
| ?
| nerpderp82 wrote:
| It isn't built in but you could mitigate this by rewriting the
| wasm module to only execute for a certain number of iterations
| and then return to the outer context. This isn't currently
| handled in Js either. For Wasm engines that run outside of the
| brower, some do have the notion of cycle counting.
|
| Wasm is a true virtual machine.
| jayd16 wrote:
| Can you perhaps rephrase your question? It seems like you're
| asking if the language will handle scheduling priority of a
| library?
|
| Isn't this the job of the browser/OS? Isn't this already
| handled in most browsers where each tab is its own process?
| mrbonner wrote:
| I still stand by my question, though. If I consider WebAss is
| a VM, which I think in some extend, it already is given that
| it let the process owner control/limit memory and IO sandbox.
| But, my understanding is that a true VM also needs to provide
| CPU sandbox, right? To answer another question in this thread
| related to JS "while (true) {}", most browser would already
| warn about the script CPU time and allow us to terminate/stop
| the long running script. I could say the same for a true VM
| that would limit the number of CPUs to use or even execution
| time out. Even with the JVM, where there is no mechanism to
| limit the execution of the entire process, I can run JVM
| plugins/modules in a separate thread and set execution time
| limit in that contained thread.
| DeathArrow wrote:
| My question is when will web assembly able to access the DOM
| without the need to call Javascript to jump back and forth.
| rektide wrote:
| This depends chiefly on the component-model work shipping.
| https://github.com/WebAssembly/component-model
|
| At the heart is an longstanding wasm "interface types" idea
| (WIT), defined by a IDL,
| https://github.com/WebAssembly/component-model/blob/main/des...
|
| Once we know how bits of wasm talk to each other we can have
| browsers expose web platform "host objects" via this standard
| inter-module means.
|
| While an interesting topic to most app developers, this is
| pretty off-topic for language nerds. It will greatly level
| implementations when it becomes available, as opposed to those
| willing to pour in enormous effort writing their own
| serializing bridges... but it doesnt really alter what the
| language can do and how it will work in wasm. This talk is, to
| me, more about languages. WIT & host objects will be an
| enormous boom but they overall won't much affect language
| design.
| syrusakbary wrote:
| I disagree that the component Model or WebAssembly Interfaces
| (WAI) is what holds a standardization to the DOM access from
| Wasm.
|
| All those things can already be done via WebIDL (and in fact,
| is the standard that wasm-bindgen in Rust already uses to
| generate the Rust bindings)
| [deleted]
| rektide wrote:
| None of that is standard though.
|
| wasm-bindgen goes away after this. Objects just become
| usable directly. wasm-bindgen is a monstrously complex
| layer, and it doesn't allow wasm direct access to the DOM.
| It very cleverly installs a complex bridge that translates
| on the fly between js and wasm, making wasm think it has
| transparent access, but it's quite clear if you actually
| start debugging what's happening in the browser, there is a
| huge middle layer of code wasm-bindgen has built for you to
| present that illusion.
|
| And again, none of it is standard. There I think may be a
| creative language or two who has built atop Rust's
| painstaking cross-serialization... but these techniques are
| far from standard.
|
| The actual standard makes a raft of these ugly unsightly
| slow intermediary translation layers go away. It makes an
| actual standard for cross language communication. Not just
| rust<->js, but rust<->go or scheme<->f# or whatever else.
| flohofwoe wrote:
| That's how all browser APIs are accessed from WASM, the DOM is
| nothing special in that regard. The only way for WASM to
| interact with the 'outside world' is through import and export
| function tables, and at least in the browser all functions in
| the import table will be Javascript functions.
|
| The only alternative would be for all browser Javascript APIs
| to get a separate "native C-like API" which could be plugged
| into the WASM import table and circumvent Javascript. That's
| basically how NaCl worked, with the downside that it only
| exposed a very small slice of browser APIs, for everything else
| one had to interact with Javascript via messaging, and _this_
| was a massively royal PITA. WASM does everything right in that
| regard.
| sinistersnare wrote:
| Andy Wingo's blog is awesome. A great resource for those
| interested in PL design and development. I learned a bunch of
| stuff about delimited control from this blog, among other things.
|
| Also, Andy implements delimited control in this post! What a
| legend
| [deleted]
| Aleklart wrote:
| TIL assembler for web will have garbage collector and can't
| access web.
| acqq wrote:
| It seems this is the current doc about the GC:
|
| https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP...
|
| Looking at the "instructions" section... is it going to be slow
| again, bringing back the speed of interpreted code to the WASM?
| RjQoLCOSwiIKfpm wrote:
| All I hear when someone writes "WebAssembly is coming" is "more
| RCE exploits are coming - via the thousands of lines of new code
| I have to hook up to the Internet by using a browser".
|
| The industry has barely finished debugging the monstrosity that
| was browsers before - XML, JavaScript, CSS, WebGL, WebRTC, ... so
| now let's add another giant source of security issues to them!
|
| When will this madness stop? When will browsers actually be
| capable of doing _enough_ and be moved into maintenance-only mode
| where only security issues are fixed and no new code is added?
|
| Surely some will say "well, WebAssembly will deliver that
| precisely - browsers now can run _all_ the code ".
|
| But wasn't this the promise with JavaScript already, a Turing-
| complete language in the browser to end the need for more
| features of HTML?
|
| Anyway, to deliver some value by this comment:
|
| To disable WASM in Firefox, set "javascript.options.wasm = false"
| in about:config.
|
| Some websites say you also need to set
| "javascript.options.wasm_baselinejit = false" and
| "javascript.options.wasm_ionjit = false" but I don't understand
| what the point of disabling JIT would be if the whole of WASM is
| disabled anyway?
| ajkjk wrote:
| I feel like you're pretending like there's no value to it? If
| there was no value then yeah it would be stupid to do it. But
| it is valuable, because people want within-10%-of-native
| performance.
| RjQoLCOSwiIKfpm wrote:
| If people want native performance, they could just publish
| native software instead of websites :)
| flohofwoe wrote:
| Distributing native software is a PITA nowadays. You're
| either at the mercy of a random App Store review process,
| or you can't run the software you just downloaded outside
| an app store because the operating system doesn't allow it.
| easrng wrote:
| native gui dev sucks, and the web does a way better job of
| sandboxing than native things do.
| hutzlibu wrote:
| Yes they can, if they have the time and skills to port it
| to the many plattforms desired. But maybe you do see the
| point, that it is a bit easier to develope and test for
| only one plattform, as opposed to ... many?
|
| (have you ever released something cross plattform?)
|
| Point being, the web is a plattform now (since quite a
| while) and not anymore a static site displayer. Provide a
| technologically better alternative and people will use
| that.
| ajkjk wrote:
| And lose all the value of distributing their software via
| websites! Again, if you ignore all the value of solutions,
| then yes, the solutions seem bad.
| RjQoLCOSwiIKfpm wrote:
| Perhaps that is just the tax they ought to pay for
| wanting to squeeze out more performance? :)
|
| The alternative of not paying that tax by using WASM
| means "I want native performance but I don't want to pay
| the price of having to do native development."
|
| So what developers are doing here is creating an
| _externality_ - external cost which other people have to
| pay:
|
| Browsers for the average internet user who just wants to
| read some news get worse in terms of security because
| some people want to distribute their software more
| conveniently at zero cost.
|
| The cost is paid by the users who _all_ now have WASM in
| their browser, even if they don 't need it.
| remexre wrote:
| Then I'm running their code outside of the world-class
| sandbox the browsers provide.
| indy wrote:
| The web is the best distribution platform we currently have
| and increasing performance via WebAssembly means a wider
| variety of programs are now viable on the web.
| shortrounddev wrote:
| > But wasn't this the promise with JavaScript already, a
| Turing-complete language in the browser to end the need for
| more features of HTML?
|
| The problem is javascript sucks. We want to be able to write
| any kind of application, but we don't want to have to do it in
| javascript. Ideally, this would mean that you pick Java or C#
| instead and use one of several cross-platform UI frameworks,
| but I've never found a native UI framework that was as easy to
| work with as HTML. If C# would just let us write native UI with
| HTML and CSS (and not just using electron), then I would never
| write a webapp again
| illiarian wrote:
| > We want to be able to write any kind of application, but we
| don't want to have to do it in javascript.
|
| To make "any kind of application" on the web you need the web
| to provide sensible APIs for those applications. And
| Javascript has nothing to do with it. E.g. lack of controls
| listed over at https://open-ui.org/ has nothing to do with
| Javascript.
|
| > If C# would just let us write native UI with HTML and CSS
|
| Good luck implementing anything beyond the most basic
| controls with HTML and CSS.
| tijsvd wrote:
| Would it not be feasible to turn electron inside out, and
| have chromium as a library, with bindings for various
| languages?
| pfoof wrote:
| Rather, wasn't that the promise with Flash, Java, Sliverlight
| RjQoLCOSwiIKfpm wrote:
| Oh right, and ActiveX!
| h4x0rr wrote:
| They were all proprietary though
| [deleted]
| remexre wrote:
| The improved sandboxing model is supposed to be why this
| one's going to turn out better (and why it's worth losing
| some of the ease of development of the old ones...)
| hyperhello wrote:
| There's a cycle where something gets big because people use it.
| Say, a mushroom picker puts up a document about picking
| mushrooms. Now he can enjoy his hobby most excellently!
|
| Next the programmers get interested. They help the mushroom
| picker upgrade his site with maps and a spreadsheet you can
| search and everything. Now the programmers can enjoy their
| hobby most excellently!
|
| Then the overengineers take over and insist that it run Linux.
| Now you can compile Linux to Wasm, and it works if you just
| configure the endpoints according to an elegant scheme! The
| overengineers can enjoy their hobby most excellently!
|
| But the mushroom picker who started this thing isn't going to
| come back. No one ever picks up the thread of development
| again, and there's nothing to do except "be online." The ride
| is over.
| j-pb wrote:
| WASM makes browsers simpler, not more complex. It's much easier
| to get the implementation of a 20 page spec correct, than the
| combinatorial monster that is 200 highlevel language specs and
| APIs. The more we can push into a small formal core, the
| better. Formal verification tools call this the de Bruijn
| criterion. You create a small formal core for your proof
| system, and everything highlevel just compiles to that.
| illiarian wrote:
| > It's much easier to get the implementation of a 20 page
| spec correct
|
| JS spec was also 20 pages. Until we got modern Javascript.
|
| wasm spec _will_ grow. Just look at the roadmap:
| https://webassembly.org/roadmap/
| RjQoLCOSwiIKfpm wrote:
| Surely that is a noble goal!
|
| But isn't it a case of XKCD 927? https://xkcd.com/927/
|
| I.e. I would say the probability is zero that because WASM
| exists other existing complexity of browsers will be removed.
|
| Because the web is so vast, if you once add a feature to
| browsers you can never remove it because that would break an
| unknown amount of websites, or even intranet sites.
|
| So now we have wasm + N other subsystems, so N+1, and the
| security of N+1 systems is less than that of N.
| j-pb wrote:
| We break/deprecate the web all the time. Web backwards
| compatibility is a myth, it's just that wo don't get any
| calls from the 90s complaining that their dogs website
| broke.
| pphysch wrote:
| The current webdev paradigm is "treat JS as bytecode". We have
| enormous build processes that compiles high-level languages
| (TS, JSX, SASS etc) into "low-level" and unreadable
| JS/CSS/HTML. The latter were _supposed_ to be the high-level
| language interfaces to the browser. It 's a mess.
|
| We'll be much better off with an actual compilation target i.e.
| WASM, full stop.
___________________________________________________________________
(page generated 2023-03-20 23:00 UTC)