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

Announcing WCGI: WebAssembly and CGI

wasmer.io

Post reply on HN
Print view View original

41–50 of 121 posts

Re: Announcing WCGI: WebAssembly and CGI

#41

Post by dianeb »

pjmlp wrote: post #20
joncfoo wrote: post #7

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're hea…

It is incredible how with so much Java hate, the WASM folks are doing their best to replicate everything we had in 2005.

Sure, this fits the way software evolves on the circle of dumb. It goes something like this: What a great idea!... (a little later) Hmmm. That's a problem... (later) We need something to run apps in the browser. I wonder if WASM would work... (now) What a great idea!...

Software development always goes in cycles. "Apps" were great now maybe not so much so...

In the late 80s/early 90s, the CEO of ETA Systems (a supercomputer company) had a vision that by 2000, the world would be split between supercomputers and workstations. I have seen some evidence that people are considerng that once again... The Circle of Dumb is always with us in software land.

Re: Announcing WCGI: WebAssembly and CGI

#42

Post by moonchrome »

pjmlp wrote: post #20
joncfoo wrote: post #7

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're hea…

It is incredible how with so much Java hate, the WASM folks are doing their best to replicate everything we had in 2005.

Java still doesn't have value types AFAIK. Meanwhile WASM started out as no-gc continuous memory VM.

Comparing WASM and JVM is like comparing a truck and a bus because they are relatively the same size, move at the same speed etc.

I mean sure you can load people in trucks and cargo into buses - and both have been done with JVM (eg. people built C compilers) and WASM (people are building GCed runtimes on top of it despite lack of GC support from platform).

Almost 30 years later nobody sane is running C on JVM and there were many attempts posted here over the years.

Re: Announcing WCGI: WebAssembly and CGI

#43

Post by rektide »

__MatrixMan__ wrote: post #13

I don't understand. Why not just compile to machine code and use plain old CGI?

Others have some good reasons to also consider. Also, launching new sandboxes in wasm is supposed to be extremely extremely extremely cheap.

Where-as launching a cgi-bin executable- even a very small libcgi based one-has a significant cost, requires a lot of kernel work & context switching.

With WCGI making new "processes" is nearly free & you don't have to context switch.

A lot of the excitement around wasm in general is that it could potentially enable a communicating-processes model of computing that would be inefficient today. Even current "function as a service" paradigms tend to retain processes, have warm/cold start distinctions. With wasm there is a potential to have requests spawn not just their sandbox, but to create whole graphs of lightweight sandbox/processes. Sometimes you might hear this described as a "Nano-functions" architecture.

Re: Announcing WCGI: WebAssembly and CGI

#44

Post by [deleted] »

ThePhysicist wrote: post #31
syrusakbary wrote: post #10

Earlier quoted context omitted.

Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly

Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with th…

[deleted]

Re: Announcing WCGI: WebAssembly and CGI

#45

Post by icedchai »

yazzku wrote: post #36
syrusakbary wrote: post #10

Earlier quoted context omitted.

Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly

Memory usage too, right? A C++/Rust wasm won't consume a hundredth of the memory a JVM application typically uses. I like getting the job done on a 512MB RAM VPS. JVM the language might be cool; the bloat and forced-GC can be spared.

JVM ran in relatively little memory back in the day. I remember running applets on ~16 megabyte systems. Compare that to today where you need a half gig of RAM to even launch a browser.

Re: Announcing WCGI: WebAssembly and CGI

#46

Post by chrismorgan »

> Consider the challenge of running PHP programs on servers. We have two primary options:

> 1. Wrap the PHP interpreter with a layer that instruments each HTTP call

> 2. Use the existing php-cgi program and simply compile it to Wasm

> Option 2 is not only faster, but it also enables any web application on Wasmer more efficiently.

I’m confused. This seems to be suggesting that php-cgi, which has to initialise the PHP environment every time, would be faster than the likes of php-fpm, which, well, I understand and presume it has significantly less overhead per request, though I’ve never benchmarked it.

I have PHP 5.6 installed on my VPS for one old site, and it takes around 27ms to start¹ (compared to under 30μs for just plain `echo`, as a closer indicator of actual process spawn overhead). PHP 8.2 might be faster, but it’s still going to be much slower than `echo`.

By simply compiling php-cgi to WASM, it will surely be doing all that initialisation for every request. Because CGI starts everything from scratch for each request, it’s inherently less efficient. In theory you could coordinate a time to snapshot the process/VM/whatever, forking from that point, but that’s not CGI any more.

All up, what they’re claiming is so completely contrary to what I would expect (and without any explanation or justification whatsoever), and kinda follows the “dust off something old to laugh at it again” trope, that I’m honestly having to check that it’s not the first of April any more (the article is dated the 6th).

So as I say, I’m confused. Option 2 seems very clearly slower and much less efficient, by the very nature of CGI. No one targets CGI (it’s been basically dead for… I dunno, close to twenty years?), because CGI is considerably worse than the alternatives. Can someone enlighten me? Have I missed or misunderstood something?

—⁂—

¹ Measured by running this in zsh and reading the “total” figure (across sixteen runs, I got between 2.671 and 3.032 seconds):

  time ( for i in {0..100}; do php56 '; done )
The comparative echo test uses `echo -n .` and takes one thousandth as long.

Re: Announcing WCGI: WebAssembly and CGI

#47

Post by frou_dh »

dianeb wrote: post #41
pjmlp wrote: post #20

Earlier quoted context omitted.

It is incredible how with so much Java hate, the WASM folks are doing their best to replicate everything we had in 2005.

Sure, this fits the way software evolves on the circle of dumb. It goes something like this: What a great idea!... (a little later) Hmmm. That's a problem... (later) We need something to run apps in the browser. I wonder if WASM would work... (now) What a great idea!... Software development always goes in cycles. "Apps" were great now maybe not so much so... In the late 80s/early 90s, the CEO of ETA Systems (a superc…

As long as it's refining and making at least some progress then it's more of a helix than a circle

Re: Announcing WCGI: WebAssembly and CGI

#48

Post by pjmlp »

moonchrome wrote: post #42
pjmlp wrote: post #20

Earlier quoted context omitted.

It is incredible how with so much Java hate, the WASM folks are doing their best to replicate everything we had in 2005.

Java still doesn't have value types AFAIK. Meanwhile WASM started out as no-gc continuous memory VM. Comparing WASM and JVM is like comparing a truck and a bus because they are relatively the same size, move at the same speed etc. I mean sure you can load people in trucks and cargo into buses - and both have been done with JVM (eg. people built C compilers) and WASM (people are building GCed runtimes on top of it des…

Nobody sane should be running C, regardless of the target platform.

Re: Announcing WCGI: WebAssembly and CGI

#49

Post by throwaway12245 »

pjmlp wrote: post #48
moonchrome wrote: post #42

Earlier quoted context omitted.

Java still doesn't have value types AFAIK. Meanwhile WASM started out as no-gc continuous memory VM. Comparing WASM and JVM is like comparing a truck and a bus because they are relatively the same size, move at the same speed etc. I mean sure you can load people in trucks and cargo into buses - and both have been done with JVM (eg. people built C compilers) and WASM (people are building GCed runtimes on top of it des…

Nobody sane should be running C, regardless of the target platform.

You'd have to delete your operating system and most of your libraries.

Re: Announcing WCGI: WebAssembly and CGI

#50

Post by rtml »

samstave wrote: post #18
syrusakbary wrote: post #8

Earlier quoted context omitted.

Here are the main differences with the Docker strategy: * If you want it to be usable, you will need to ship it with some mechanism that allows running CGI over http (kind of Apache or Nginx), so your container would be bigger than the Wasmer package * Regarding security: Docker containers needs to rely on hardware virtualization to run securely (via KVM or simlar), aside of a virtualization on the systemcall layer (…

Im going to ask a very ignorant question ;; Is it possible to spin-up a 'container' or whatever youre calling the VM of a site, for each individual user? So if you have a high security req on data accessible by computers, you spin up an individual container of said site that only serves that user, and is destroyed on exit... so that whatever the user does cannot affect others? ELI5?

[dead]
Post reply on HN