Dan Gohman

Fastly has a job opening in the UK, for Compute, Fastly's serverless Wasm compute platform, using Rust.

https://www.fastly.com/about/jobs/apply?gh_jid=7736653

Happy to answer/relay any questions!

#RustLang #Wasm #job

@esoterra @nasser My understanding is that the current ASCII-only restriction is expected to be lifted in the future, once there is a proposal that includes considerations for bindings in various important source languages, at least some of which have more constraints than just the Unicode XID. The idea of using hash codes, with dictionaries providing user-readable names, is interesting, but it's not clear to me how it might work. For example, if a user writes a WIT file containing identifiers in the user's language, and distributes it, and others author components using it, at what point should the hash codes be computed?

The reason `fsync` exists in Unix is for applications to avoid calling it.

Unix could have made filesystems sync automatically, but that would have a high cost, because it would end up doing a of needless work for temporary and intermediate data. Instead of having the filesystem abstraction convey the intent of data, Unix bubbles up the responsibility to call `fsync` to higher-level application code.

In this design, tools like `sed` aren't meant to call `fsync`. They operate near the level of the filesystem abstraction and don't have the information they'd need to decide when not to call it. A script might invoke `sed` a thousand times and then do a single `sync` at the end, avoiding much needless cost while still achieving the desired end result.

In contrast, `vim` does call `fsync`. The thing that makes `vim` different is that it knows a tiny bit about where it sits with respect to a human being's intent.

So the decision to use `fsync` isn't about not letting errors pass silently. It's about whether the code you're writing has a bigger-picture understanding of the data it's processing.

@migratory@jorts.horse @esoterra@hachyderm.io @yosh@toot.yosh.is I'm listening, but I don't have a clear view on how spec'ing these features one way or the other would result in applications and products being built in a way that would support what you want to do.

@bjorn3@hachyderm.io There's a lot here that I don't have time to fully explore; here are a few quick thoughts: Debuggers are special. Debuggers can observe things that the spec says "can't" be observed. They can mutate "immutable" things. And they can break API contracts. Debuggers will have flexibility, even if the spec doesn't explicitly say so. Regular virtualization means changing what imports/exports are linked to. But there are a number of things users want to do that can't be done through linking: you can't catch traps, you can't impose CPU/memory/etc. quotas, and so on. So maybe there will need to be some additional mechanism, and this something might also be a place a builtin random facility could be controlled.

@dotstdy@mastodon.social @josh@social.joshtriplett.org @esoterra@hachyderm.io The twist there is, if you use secure APIs to get the seed, then deterministic environments will see the import of a secure API, and might not be able to run the code, because they don't know that it's ok to make it deterministic.

@dotstdy@mastodon.social @josh@social.joshtriplett.org @esoterra@hachyderm.io My understanding is, even an insecure PRNG wants at least a seed from somewhere, even if some users will chose to make the seed deterministic, others will want it to be nondeterministic. And obvious sources like clocks or other I/O aren't ideal because they could be virtualized for other purposes.

@esoterra@hachyderm.io Yes, that's the secure vs. insecure distinction I belatedly started making in this thread.

To be sure, the above is oversimplifying the situation somewhat. For example, perhaps someone doesn't trust the quality of the buitin random data, and wants to mix it with data from another source. But then, what other source would that be, in practice, and is that actually how we want secure applications to work? There are more questions here.

@esoterra@hachyderm.io @yosh@toot.yosh.is The catch is, for secure random numbers, you never want to use a static seed, outside of offline debugging, because that would make the data predictable, voiding the security guarantee. Ideally, deterministic environments should just never run programs that depend on secure random numbers. That puts a lot of weight on applications' ability to distinguish between secure and insecure random number APIs, and I don't know if it'll hold. But something has to give, somewhere.

Random numbers should be hard to predict, and they carry no inherent meaning. Once you have a source of high-quality random numbers and a good PRNG making them fast, there isn't really anything else that can be added on top. And if we allow things to be added on top, that increases the risk that information about the bytes could leak before they reach their intended destination.

The thing that makes it tempting to add a random-number generator as a Wasm component builtin is that random numbers are inherently not virtualizable, for some common meanings of "virtualizable".

@io The magic is that components are self-describing, meaning they always contain enough information to describe what world they can run in. See here for some more information: https://component-model.bytecodealliance.org/design/components.html

computers: don't confuse concurrency and parallelism!

- concurrency: non-intersecting lines of computation
- parallelism: multiple things happening at the same time

english: who's confusing what now?

- concurrency: multiple things happening at the same time
- paralleism: non-intersecting lines

@isntitvacant WASI APIs are moving to be defined using the Wit IDL, which is an IDL defined by the component model. They're all part of the same overall big picture, and i welcome questions on any part of it 😄

@isntitvacant

1. Yes. Wit and the tooling have some maturing to do, but platform teams defining their own custom interfaces and worlds with Wit are an important part of the vision.

2. Web components are a different technology, but for Wasm components, yes, jco is a great place to start!

@bryan There are people thinking about externref for Rust, but I don't know of any concrete plans right now. Fortunately, that won't be necessary for Rust to interact with the outside world. The component model encapsulates how strings and handles are implemented, so Rust can use its own string types and can use handles like it uses file descriptors on Unix, an integer index wrapped in a higher-level type.

What's the question you've always wanted to ask about #WASI but never knew who or when or where to ask?

@ricochetcode@hachyderm.io made a great video with Luke Wagner about the history of WebAssembly going all the way back to the start of asm.js!

https://www.youtube.com/watch?v=B4PPDNxeRlw

#wasm

@sdeleuze The plan for Preview2 is, sockets can be marked nonblocking, and poll-oneoff can poll them. That's sufficient to do async I/O. To address scalability and composition, we'll do Preview3.

The slides for my #WASI Roadmap presentation to the WASI Subgroup earlier today are now up:

https://github.com/WebAssembly/meetings/blob/main/wasi/2023/presentations/2023-02-09-gohman-wasi-roadmap.pdf

The super short version is:
- Preview1: Support existing users, portability
- Preview2: Rebase WASI on Wit
- Preview3: Level up Async: future and stream
- WASI 1.0: Standardization

I'll be speaking about WASI at Wasm I/O 2023 this March!

https://wasmio.tech/

#wasm #wasi

There's a new Ruby gem for using Wasmtime from Ruby!

https://bytecodealliance.org/articles/using-wasmtime-from-ruby

#wasmtime #ruby

And when we represent I/O as calls to imported functions, instead of loads and stores to mapped memory, we make the code easier to virtualize. For example, one could write an emulator for the hardware just by having an implementation of the functions.

In hardware designs, memory-mapped registers (MMRs) are widely used because they're a way to add I/O devices without making changes to the CPU.

Exposing these features to Wasm doesn't necessarily require them to be represented as memory-mapped at the Wasm level though. We can have imported host functions that do loads and stores to the desired hardware addresses.

#wasm #wasi