Fork me on GitHub
#off-topic
<
2019-03-28
>
benoit00:03:30

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 🙂

gklijs09:03:15

Wasm might get pretty far especially once WASI becomes a standard. But you won't be coding wasm directly.

hipster coder02:03:22

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

👍 8
fellshard21:03:44

This is what finally got me trying Emacs; this and org-mode. If nothing else, it's a fantastic way to learn the basics of Emacs.

hipster coder02:03:32

Ya, especially since I know vim

lilactown16:03:11

anyone paying attention to the WASI stuff?

👍 5
lilactown16:03:19

seems pretty cool.

lilactown16:03:03

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

hipster coder18:03:06

I think WASM will open up a can of worms with security. Especially since it gives lower level access to the machine.

lilactown16:03:20

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

gklijs16:03:54

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

lilactown16:03:38

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

lilactown16:03:30

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

lilactown16:03:49

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

lilactown16:03:40

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

gklijs16:03:50

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.

lilactown16:03:26

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

lilactown16:03:20

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

lilactown16:03:35

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

dpsutton16:03:38

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

lilactown16:03:40

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

lilactown16:03:54

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

dpsutton16:03:13

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

dpsutton16:03:44

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

lilactown16:03:51

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

souenzzo16:03:50

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

hiredman16:03:51

the hype around this stuff is crazy

dpsutton16:03:07

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.

hipster coder18:03:29

Ya. I think I saw same talk. Rust allows shared memory threading but without locks.

hipster coder18:03:06

A lot of people are complaining that Golang is using locked concurrency model. Golang is just easier to write than C.

hipster coder18:03:37

Rust ownership is almost like the message passing idea of Elixir but Rust allows shared memory. Elixir does not allow shared memory.

hipster coder18:03:42

Elixir is better for horizontal scaling. Clojure and Rust are built for large multi core servers.

dpsutton16:03:18

you don't need immutable / mutable versions

hiredman16:03:26

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

lilactown16:03:02

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

hiredman16:03:18

wasm is the js runtime as a compiler target

lilactown16:03:29

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

lilactown16:03:45

(when in a browser)

hiredman17:03:34

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

hiredman17:03:02

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

lilactown17:03:12

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

lilactown17:03:29

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

lilactown17:03:32

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

hiredman17:03:28

there could be anything

andy.fingerhut17:03:05

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.

andy.fingerhut17:03:24

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

lilactown17:03:30

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

lilactown17:03:05

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

hipster coder17:03:22

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

hipster coder17:03:03

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

hipster coder17:03:32

But Ruby 2.0 is still locked to 1 CPU

hipster coder17:03:09

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

john19:03:55

WASM will probably eventually have native dom access

john19:03:20

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

john19:03:51

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

john19:03:29

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

john19:03:22

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.

hipster coder20:03:18

What does interuptibility mean? As in int interrupt on the bios?

hipster coder20:03:07

Int 13 interrupt that mouse, keyboard use?

john20:03:53

Java threads are interruptible

hipster coder20:03:18

Ahh, threading

john20:03:21

You can can interrupt the execution of a Java thread

hipster coder20:03:18

Does that mean V8 engine does not have interuptable threads?

john20:03:24

The webworker isolates will not be exposing interruptibility. They run on threads or OS processes that have their own interrupt semantics.

john20:03:43

So user code will not be able to interupt

john20:03:04

Two work arounds I can think of:

hipster coder20:03:10

I guess that fits the whole browser architecture

john20:03:22

1. just trash the whole isolate and start another

hipster coder20:03:23

Async architecture

john20:03:08

2. have all comms go through a switch panel where you can send an "interrupt" command prior to any "result" command

hipster coder20:03:44

In other words, WASM won't be good for data processing, math

john20:03:55

when a worker waits on a result, nothing else can interrupt its waiting on that one result, so technically, you could use that result channel to simulate interrupts.

john20:03:03

not necessarily

john20:03:32

Having non-interruptible, parallel workflows may have benefits for some workloads.

john20:03:26

But things like Clojure's STM sorta require interruptibility, so you can short-circuit logic on invalidated state.

hipster coder20:03:28

Very interesting

hipster coder20:03:57

Ya, like if a thread is processing a really long math call

john20:03:00

But again, a result/interupt switchboard may mitigate that, but that may slow things down too much

john20:03:55

Yeah, there's no checking in on that thread, unless it's chunking its steps and feeding out updates or checking some interrupt queue

hipster coder20:03:03

So its best to use batches like the clojure partition of sequences?

hipster coder20:03:26

Or you might have all threads maxed out on long running code?

hipster coder20:03:14

I do have 1 ? I thought most CPU's limit the threads to 4 per core?

hipster coder20:03:49

4 parallel threads... not talking about fake interleaving threading like node js does

john20:03:18

Interruptibility with regard to clojure sequencing - or interruptibility in any regard - is not spoken to in any clojure semantics I'm aware of...

john20:03:40

I haven't seen a lot of chatter out there on marrying those two worlds.

john20:03:16

I think one a non-interruptible, parallel worker js load, you'd probably want to have a better understanding of the length of time each of your work chunks is going to take, true... But that won't necessarily mean less performance, depending on the situation.

hipster coder20:03:15

I was reading how other languages are trying to add atomics... but Clojure STM is atomic by nature?

hipster coder20:03:06

And that Clojure comes closest to non locking concurrency... and Rust too

hipster coder20:03:46

Trying to figure out if STM or an actor model is better... maybe STM for data processing... And actors for distributed.

john21:03:48

Clojure atoms are atomic, optimistic-best-effort-synchronous (they might retry) and are "uncoordinated" with respect to other atoms or reference types, where "coordinated" means consistent semantics maintained between them.

john21:03:51

Agents hold a queue of actions and you issue work to them similarly to atoms, but act a bit more like the actor model, from what some people say

john22:03:08

But they're asynchronous

john22:03:50

Then STM is sorta different, like a set of atoms/agents where you can ensure consistent semantics across the different refs.

john22:03:59

So I think you're comparing oranges and apples with STM vs actor model

john22:03:49

Honestly, very few people have found a job for STM that a database doesn't usually end up taking care of anyway.

john19:03:02

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

respatialized20:03:33

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

hipster coder20:03:05

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

hipster coder20:03:50

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

respatialized20:03:40

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