I've been working on a server-side wasm impl of cpython called boomslang [1] and have been thinking a lot lately about packaging, one of the downsides of my current impl is the need to statically link all c/rust extensions. Its too bad IMO how much of the wasm ecosystem targets/depends on emscripten directly. It'd be interesting to see if a more generic ABI could be provided for non emscripten/js based wasm runtimes.
The WASI support in CPython has moved along very well and it is an early target via componentize-py[1]. Notes on WASI support in Python can be found in PEP 816[2]; CPython will be jumping from 0.1 to 0.3 (0.2 is adapted in componentize-py) which should unlock a fair bit of support, especially once cooperative threads lands (providing a pthreads impl in wasi-libc).
it’s great to see this stuff moving forward, I’m just impatient for it to all land! Plus one of the challenges IMO is that you also still need support in the runtimes, which takes time. Hopefully the state of the world will look better for WASI in a few months/years.
wasi 0.3 just came out and its fully component model based with no emscripten specific parts. also supports dynamic linking in the spec but afaik no runtime actually has it implemented in a released version.
I think one of the issues is that WASM is notoriously hard to generate code for because they decided to use an IR that's fundamentally incompatible with literally any existing native compiler backend's IR (not counting very specialized ones or toy direct-ast-to-machine-code compilers).
It feels like nobody actually consulted actual compiler writers when designing this. I'm sure that isn't true, but it definitely feels that way. (I suspect the truth is that they were consulted, but ignored.)
It means codegen needs to resort to all sorts of hacks (like the relooper) in order to target WASM, a property not shared by any other target.
And apparently, the way they handle variables also results in deoptimization, though I don't recall the details of that.
Add the fact that interacting with the browser on the web still has to go via JavaScript to this day (for the most part, at least), and, well.
---
TL;DR a combination of poor IR design that has a massive impedance mismatch with pre-existing compilers (and most new ones, because it turns out there's a reason the WASM approach isn't standard) plus WASM still being a second-class citizen in its supposed primary environment (the 'W' in WASM) --- the former ensures targeting it consumes a lot of resources/time, the latter ensures the bar for that to be worth it is much higher.
You can target most architectures with little trouble (at least a a baseline --- optimization's a hard problem regardless of target, except maybe SPIR-V due to the recommendation that pre-optimization is limited in scope). But WASM is completely out there, it's closer to trying to target e.g. Java (not JVM!) at the backend instead of machine code or some other IR.
You don't make an IR intended to be targeted by existing/native compilers by making it completely different to anything they had to target before and completely different to their own IRs and representations ... unless you're the guys behind WASM.
I don't think the controversy about Wasm's structured control flow has anything to do with any of this? It's not actually difficult to target Wasm in codegen; I've never heard of any real-world compiler project complaining that this was a major burden. ABI concerns are at a different level.
Most low-level IRs don't do structured control flow because most low-level IRs don't need to be translatable to verified-safe machine code in a single fast pass, whereas for WebAssembly that's a core design requirement.
http://troubles.md/posts/why-do-we-need-the-relooper-algorit... has a more detailed version of this argument: if WebAssembly had used a CFG as the basis for its control flow, it would have been easier to compile to and easier to efficiently execute/translate while maintaining safety, and maybe GCC would have released a WebAssembly backend by now.
The author alleges that the real reason WebAssembly uses loop/block is because that's how V8 worked internally at the time and Google didn't want to go to the trouble of implementing something different. But more recently V8 has started moving towards CFGs ( https://v8.dev/blog/leaving-the-sea-of-nodes ) so maybe there's hope in the future.
I'm familiar with that post. However, it doesn't include a convincing argument that a CFG interchange format wouldn't have performance costs for Wasm runtimes; it just handwavingly asserts this. It blames Google because Google is a popular villain, but the other three browser vendors (this was before Edge adopted Chromium), all of which initially used different Wasm runtime architectures from Google and from one another, were also in favor of structured control flow, and I assume they knew what they were talking about. Once you get past the conspiracy theory, it's clear that the real issue is just that the author disagrees with the Wasm committee's decision to trade off convenience for compiler writers in order to make things work better for runtimes.
More to the point, none of this has anything to do with ABI.
From what I remember, it was specifically chosen (among other reasons) because of experience with the JVM, where it was difficult to verify bytecode type-safety due to unrestricted jumps and branches.
So the choice was made to put the burden of regularizing the control flow on the compilers at compile time, rather than the browser engine at website load time. Which seems rational to me.
Which has a full build of python to WASM with a bunch of static libs built in already.
I will say I built this pre fable and actually the first build of the interpreter to WASM opus pretty much nailed, cpython has secondary support for WASM as a target since like 3.9 or something and it just pulled from that.
I’ve been meaning to write up a blog post about this sometime, building this has been pretty interesting, including using opus to run a full auto research like loop for days to hyper optimize it’s performance.
I’m hoping to use fable to power some even crazier WASM adventures tho.
This was just our first post FWIW, and we definitely want to follow up with more concrete demos/details/etc here. I am working on another post specifically about how we leverage our internal RPC system to make adding AI tools super easy so expect more from us.
To be fair, if you read the incident report it is a better than average one on details and it was a 20 minute outage without data loss. I've seen many major companies simply not acknowledge that level of outage on their public status page, especially lately
I work at HubSpot (on Kafka) and so I was a "user" of this migration because kafka uses Zookeeper for coordination. Its pretty amazing how convenient Kube services made this whole transition and we actually learned a lot from this that we will likely end up applying similar strategies for migrating other services onto Kube. Allowing kube services to point to either external resources or pods/internal ones is a probably the best feature I have found in Kube so far (and there are a lot of great features)
I have this exact setup (vault/consul/nomad + glusterfs and zerotier for networking) and its pretty awesome. Still dependent on letsencrypt for SSL certificates. It runs plex amazingly well (though I am using some machines which are probably overkill for this purpose), even with the data coming from a glusterfs drive. Most of my nomad tasks can just launch anywhere because of gluster.
For internal DNS at least, you can just use consul. I set up dnsmasq to forward to consul on all of my machines which is super convenient (esp when that DNS just points to a docker container ipv6 address on the zerotier network, not port remapping on networking insanity needed)
After a quick scroll-through I have a very similar setup. One thing to watch out for is that you really want to set up TLS and ACLs for Consul, Vault and Nomad as early as possible (maybe ACLs for nomad is not as critical to have in place from day one) - if you can avoid bootstrapping that on an already running cluster you save yourself a lot of head-scratching.
Integrating these three systems, with Terraform on top, is pretty time-consuming with all the policies and TLS certificates, but it seems pretty smooth to maintain after the initial setup.
I'm learning terraform/consul/nomad/vault as I build this thing, so I think the learning curve for me is extra painful compared to some of y'all.
The docs seem really good if everything is cloud-hosted and really nonexistent if you're running it all on your own metal.
I'm thinking I'll build out my test stack with vagrant. I can use Dropbox or Keybase or something similar to store and sync my terraform state if I need to. Any other hints or helpful readings?
Cheers, haven't checked out zerotier before.
I'm curious, do you run GlusterFS on nomad or standalone? Seems like it could work fine as raw_exec, but I'm not sure if that's a good idea or not.
kinda a late response (sorry) but I run it standalone, setup via ansible. I have ansible scripts that bootstrap everything "below" nomad so it sets up zerotier, then vault, then consul, then dnsmasq (pointing to consul) and then nomad. You could probably run gluster in nomad but given that I give most nomad tasks a gluster directory that feels odd.
The only thing I still need to figure out about this setup is that I currently use a single glusterfs volume for most of my nomad tasks, I would love to have a nomad integration that could provision and mount the gluster volume when I specify a volume for a docker task in nomad.
I think the generally accepted solution to this is to set the allowed origin dynamically (IIRC nginx can do this) by looking at the request host header on the options request. If the origin is in some allowed list then you return that origin in `Access-Control-Allow-Origin`
When I started reading this article I found myself a bit annoyed. The author was complaining and pointing out the fact that some tech companies do some crazy/inane stuff, while ignoring all of the positive things that comes out of tech. Plus, even the crazy/inane stuff can end up having positive impact or side effects!
At the end of the article, however, I was pleased to find that the author came to the same conclusion. Yes, tech can be weird, and it seems especially so to those outside of tech, but I strongly believe that in the long run all of this experimentation will be a good thing.
Why does being a good coder preclude code reviews? Even experts make mistakes and even when there are no mistakes an outside perspective can often be useful. People think in different ways and may have something to add even if you are all really good programmers.
The kind of mistakes that good programmers make are not normally caught in code reviews. That's pretty much the definition of a good programmer; their mistakes are rare and subtle.
> The kind of mistakes that good programmers make are not normally caught in code reviews. That's pretty much the definition of a good programmer; their mistakes are rare and subtle.
I think the opposite is true. Good programmers know where the risks of subtle bugs are, and will use the appropriate tools (e.g. good use of a decent type system, well documented code with well designed abstractions) to make completely sure they don't exist.
This just leaves simple stupid bugs in the parts of the code where any such bug will manifest itself quickly and obviously, exactly the kind of thing caught by code review.
Another way to put it would be: good programmers design their code in such a way that all bugs are catchable by code review.
> The kind of mistakes that good programmers make are not normally caught in code reviews. That's pretty much the definition of a good programmer; their mistakes are rare and subtle.
That's just arrogance. Good programmers make stupid mistakes all the time as well. It's the ability to recognize and fix such mistakes that separate "good" programmers from "normal" programmers and that's precisely where code review comes in.
[1] https://github.com/HubSpot/boomslang