There was a discussion about a "universal programming language" here a few days ago. Just encountered a relevant aphorism from Alan Perlis: "There will always be things we wish to say in our programs that in all known languages can only be said poorly." Great, as usual 🙂

@eric.d.scott recommended that I switch to spacemacs (evilmode). I love it. It’s awesome.

anyone paying attention to the WASI stuff?

seems pretty cool.

it’ll be interesting to see in 5 years how much WASM lives outside of the web

the security aspect of it is very interesting compared to the JVM

I reads the post about it, looks amazing if it works. Applications like slack could be made cross-platform and much lighter than Electron.

maybe. I think that’s already the case though 🙂

I think Slack gets a lot of leverage from being able to use web technologies. I don’t think that WASM would necessarily have e.g. a native DOM for you to work with

I think it’s more interesting to think of WASI+WASM like a more secure JVM. you can deploy your application anywhere it exists, and consume any libraries that have been built for it; whether they were written in C, Java, Rust…. Clojure? 😛

the WASM garbage collector story is still ??? so who knows what kind of leverage higher level langs might get from it yet

Kotlin can compile to wasm with a build in garbage collector, causing it to be rather big I thought. I just used it with Rust, then it's 'free'. But there are plans to add garbage collection to WASM natively.

right

I just have no idea what the characteristics of the GC will be like

I would imagine it could potentially add friction to languages like Java / Kotlin / Clojure that depend heavily on the GC and use lots of tricks (even in user-land) to optimize for GC

I also wonder how the native WASM GC will be integrated. C/C++/Rust probably don't want to deal with it

tricks in userland? like transients or what do you mean?

sure? anytime you're thinking in your head about the JVM memory model as you're writing code

maybe I'm making something up to be concerned about!

i'm not arguing or disagreeing. just making sure i understood what you meant

i had never thought about it through that lens but i suppose you are correct

transients seem general enough that they're probably a good idea anywhere

maybe #graalvm can do jar -> wasm in (a near) future

the hype around this stuff is crazy

i remember hearing a cool plus for rust that it changed how you think about that with ownership. so it didn't need to provide differences of mutable transients.

you don't need immutable / mutable versions

js sucks, its runtime model is bad, how do people get excited about it spread from the client to the server (nodejs, wasi, etc)

I’m not sure how WASI relates to JS’ runtime model

wasm is the js runtime as a compiler target

:thinking_face: I thought that it could interact with the JS runtime, but that it was something substantially more limited low-level

(when in a browser)

in order for wasm to interact with js the way it does it has to bake js's model in to it

for example, as far as I know the only way to have multiple "threads" in wasm is still to use what are basically webworkers

like I’m interested in understanding more about the tradeoffs of WASM, so I’m all ears

isn’t that just a function of lack of “threads” offered in the browser?

like, there’s no thread API for WASM to interact with in the browser. but presumably there could be some sort of capability offered in a native WASI environment that allows WASM-compiled apps to use native threads? If i understand correctly

there could be anything

adding threads like those in a JVM to a runtime that never had them often becomes visible at the language spec level, or should if you want to write any kind of thread safe programs with multiple threads. Python still has the GIL despite many people's attempts to get rid of it.

"shared nothing" threads are significantly easier, of course, interacting only through things like message queues. Is that what webworkers are like today?

I guess it seems like WASI is specifically being introduced to decouple WASM from the browser runtime

that’s mainly how webworkers are used AFAICT. I believe there are APIs now to use special shared memory buffers + atomics

there was this recent announcement: https://developers.google.com/web/updates/2018/10/wasm-threads

Ya, I realized quickly with WASM... it is run in its own environment. No interaction with the DOM or JS.... as far as I can tell

Node JS and Ruby have both been trying to move to multi threading.

But Ruby 2.0 is still locked to 1 CPU

The best use case for WASM seems to be games... or maybe a custom UI element but you'd have to talk through a web socket to interact with the DOM

WASM will probably eventually have native dom access

I'm hoping wasm bakes as little GC into it as possible

just enough for a 3rd party GC to hook into JS's GC, using weak maps or whatnot

Any GC they try to bolt onto WASM is going to be very JS centric. Otherwise it'll be sorta pointless

I'm not sure webworker-based multithreading over wasm is going to be much less efficient than parallel workloads over the JVM. JS isolates just don't have interuptability, so that may or may not impact some parallel algorithm performance.

This WASI is new to me though. I'll have to read through it

my hot take is that WASI is another thing to add to the stack of "technologies just now catching up to where Xerox PARC was 40 years ago" > "After literally decades of trying to add more and more features and not yet matching up to the software than ran on the machines the original browser was done on, they are slowly coming around to the idea that they should be safely executing programs written by others." - Alan Kay https://www.mail-archive.com/[email protected]/msg03823.html

I think WASM will add DOM support too. It will be a security nightmare. But at least I could avoid too much Javascript

E.g. Javascript payloads accessing WASM machine level code that burns a hole in your RAM

Yeah, Brannon Dorsey had a good writeup of what happens when designers fail at the "safely executing code written by others" bit: https://medium.com/@brannondorsey/browser-as-botnet-or-the-coming-war-on-your-web-browser-be920c4f718