[NCLUG] Some developments in Rust.

[Brian Sturgill]

I can understand your confusion.
Think of it as a much faster Node.js.
In case you're not familiar Node.js is based on the JavaScript engine from
Chrome. It does not contain browser features.
However there is Electron which is Node.js + the Chromium web pieces and is
used to make cross platform apps, such
as the Atom text editor and the Microsoft Visual Studio Code text editor
(fully open source, possibly the most popular text
editor for developers now), among many other apps.

The problem with Electron is that it uses JavaScript, which is
significantly slower than C and well, nasty.

Enter WASM.

At heart WASM is an abstract assembly language. It is made to be compact,
safe and quickly translatable to native code.
It truly runs at near C speeds.

Like modern JavaScript it has 3 forms.  A browser form, a Node-like form
and a combined form (like Electron).
The non-browser versions include an OS abstraction layer, similar in
principle to Node.js.

But this runs at C-speeds. You can get to it from many languages including
C and Rust.
This is different from JVM in that it translates from an assembly level,
not a VM level. Or to make that more clear,
it is a low-level VM that translates easily to good quality native code.
Translation is done once when it loads, from then on
it is a native program. There is no "Hot Spot"... no overhead of keeping
both VM and Native code around. This is meant to run
native, PERIOD.

The WASM runtime is designed to run independent "processes" [not sure they
use that term]... they can import libraries,
but running code is protected from other "processes".

Just as in the browser, you can be running more than one "process" at a
time in the Node-like environments.
They are working on making this a dynamic system controlled like one does
with containers.
This is much more lightweight than full containers, but still gives you a
lot of the safety.
It should be easy to see how these "apps" can be downloaded and managed
easily for edge computing.

I will likely be looking closely at this after I get caught up from being
sick with COVID-19, then Shingles for the last nearly 3 months.
So sometime in 2024? :-)

Another way of looking at this is that it makes a container-like solution
practical on RaspberryPi Zero class machines.
This is important for the consumer-level edge computing systems that will
become ubiquitous in the next few years.

There is this, but it's a bit skimpy on details.
https://webassembly.org/docs/non-web/

Brian

On Wed, Jun 3, 2020 at 8:11 PM Bob Proulx <bob at proulx.com> wrote:

> Brian Sturgill wrote:
> > Containers and WASM programs are actually very similar. Containers use
> > hardware and WASM uses software to provide isolation and an abstract
> > interface to an OS and hardware. WASM translates to native code, but is
> > carefully checked to avoid things like buffer overruns, etc. WASM has an
> > extra layer to get to allowed access to OS and Hardware. It is therefore
> > slower for some types of programs.
>
> It's the new JVM!
>
> > But consider the case of small services, or micro services. Even 10
> > containers uses quite a chunk of a system. You could easily run 1000
> under
> > WASM.
>
> So...  I always thought of WebAssembly as something that runs in a web
> browser.  And a web browser as something that runs interactively on a
> desktop.  Which means that it isn't the same as a containerized micro
> service.  I think of containerized micro services as something that
> runs on the server side of things.  They start automatically at boot
> or upon demand.  Other clients use them.
>
> But web assembly is something running in a web browser.  Which means
> the user must start up the web browser.  Then must have the web
> browser load a URL.  And that URL might run some web assembly.  That's
> not really a micro service model.
>
> Although if I am reading about COVID19 and someone has an interesting
> graphical model of the spread of disease.  It might be somewhat
> compute intensive.  Therefore distributing that to my web client as
> Javascript makes a lot of sense.  I am seeing the moving graphic.  It
> makes sense that it is my cpu being used to render the graphic.  Right
> now they are mostly Javascript.  But they could more efficiently be
> WebAssembly.  I click on the mouse and the page runs the downloaded
> code on my cpu in a sandbox.  As long as it can't escape the sandbox
> then it is safe.  It's using my cpu so it can be fairly intensive but
> scales to a lot of users.  This all makes sense to me.
>
> > Admin load is much smaller too... networking with several containers over
> > multiple physical interfaces gets complicated fast. Such problems just
> > don't exist under WASM.
>
> I am probably terribly misunderstanding it but I think that is because
> different web browsers are sandboxed off intentionally so that they
> can't talk to each other.  So of course not being able to do it is one
> way of keeping things simpler.
>
> > WASM also let's you more easily control what sorts of things the services
> > have access to.
> >
> > One will likely see a lot of edge computing solutions using WASM. The
> > approach is more amenable to embedded processors.
> >
> > No doubt both are needed, but WASM is welcome relief to someone that just
> > needs to run isolated services. In time it should be simple enough for
> > normal users to do it.
>
> I think I am not understanding something fundamental here.  I would
> enjoy it if you gave a talk or a summary or an exposé article on it.
> Because I think I am missing out.
>
> Bob
> _______________________________________________
> NCLUG mailing list       NCLUG at lists.nclug.org
>
> To unsubscribe, subscribe, or modify
> your settings, go to:
> http://lists.nclug.org/mailman/listinfo/nclug



-- 

Brian