jcmfernandes

I understand what you mean by being able to fully sandbox things and guarantee determinism, a must for the workflows and not the activities (using temporal lingo).

When you say that the runtime handles, for example, retries, doesn't that require me to depend on your HTTP client component? Or do I also need to compile activities to WASM and have obelisk running them because they are essentially background jobs (that is, you have workers pulling)?

Finally, do you see the component's interface as the right layer for capturing IO? I'm imagining people attempting to run managed code (Java, python, ruby, etc.). The VMs can do thousands of syscallls before they start executing they user's code. Logging them one by one seems crazy, but I also don't see an alternative.

EDIT:

I RTFM and found the answers to my first two questions in the README :)

Somewhat similar to Golem - https://github.com/golemcloud/golem - correct?

So, I like this idea, I really do. At the same time, in the short-term, WASM is relatively messy and, in my opinion, immature (as an ecosystem) for prime time. But with that out of the way (it will eventually come), you'll have to tell people that they can't use any code that relies on threads, so they better know if any of the libraries they use does it. How do you foresee navigating this? Runtime errors suck, especially in this context, as fixing them requires either live patching code or migrating execution logs to new code versions.

I thought the same while reading it and... I felt old.

Insane effort. This sounded like a pipe dream just a couple of years ago. Congrats to everyone involved, especially to those who drove the effort.

Cool stuff! What's your current focus on, and what are your plans for the near future?

And congrats on the jump. It takes courage to go solo :)

Isn't the answer always "bugfixes and increased stability"? :)

That is correct :)

> Fun fact: you don't need CSRF protection at all if your API is strictly JSON-based, or uses any content type that isn't one of the built-in form enclosure types. The Powers That Be are talking about adding a json enclosure type to forms, but submitting it would be subject to cross-origin restrictions, same as it is with JS.

AFAIK, this is not totally accurate because the internet is a messy place. For example, the OAuth authorization code grant flow blesses passing the authorization code to the relying party (RP) in a GET request as a query parameter. The RP must protect against CSRF when receiving the authorization code.

Correct, they are a part of WASI. Indeed, different things, but well, tightly related. Made sense to talk about them given the chat on bridging gaps in bazel using WASM.

Yes, the concept is old. I may be wrong, but to me, this really seems like it, the one that will succeed. With that said, I'm sure many said the same about the technologies you enumerated... so let's see!

This is great. The future is made of libraries packaged as WASM Components.

Yes, but WASM gives you more, especially WASM Components. E.g., FFI doesn't offer sandboxing, and unloading symbols is tricky. The WIT (WebAssembly Interface Types) IDL (+ bindings codegen) makes objects' exports explicit, but more importantly, their imports too (i.e., dependencies).

Thanks for your feedback. Components and WIT seem powerful to me, though. I'm building an execution environment on top of a niche programming language, and components allow me to easily extend it with libraries written in other programming languages without having to link my application against anything and use FFI.

I see, thank you. I'm trying to get up to speed with the whole ecosystem as I have a use case for it. I would like to interact with WASM components from a go binary, but it seems like wazero doesn't and won't support the component model anytime soon. The rust tooling seems more mature ATM :(

I thought that WASI and the component model were separate specs. Am I wrong?

Gary was a visionary: https://www.destroyallsoftware.com/talks/the-birth-and-death...

You use k8s to manage the machines where wasmCloud runs, and wasmCloud to manage the WASM apps that run on top of it. That's at least my understanding.

I got to know more at your stand during last year's FOSDEM. Very cool project!

Shameless plug: I work to make this easier at https://www.slashid.dev/products/identity-protection/

And yes, you're absolutely right. Attempting to manage NHIs across multiple cloud/service providers without having proper automation in place is a total nightmare.

Give it a try and try to come back with your sanity intact. I dare you :)

It's mess.

I built a simple tool to generate binstubs and work around this problem: https://github.com/jcmfernandes/go-tools-binstubs

However, having multiple tools share a single mod file still proves problematic occasionally, due to incompatible dependencies.

I can strongly agree with you while understanding how the OP feels (and I certainly don't condone all his advice). IMO, culture plays a role in it; as an EU citizen, layoffs are effectively rare here.

I was laid off once, when I was being widely praised for my work. It's been 5 years, financially it was probably the best thing that ever happened to me, and it still hurts that it happened. So yeah...

I gave up on mine. It's more than obvious to me that it doesn't care if there's ink in the cartridge after some time and just starts malfunctioning.

I understand that, but even nixos refers to configuration.nix as a "configuration file" in its documentation.

IMO, it's totally OK that people have different opinions on what are best practices. However, I would still like to see official documentation showing beginners how to do things, comparing a few options.

On how to assemble your config. Every config I open does things a little bit different, from the get-go, when using flakes. Add package sets as overlays to nixpkgs or pass inputs downstream? How to parametrize "system"? What's stuff like flake-parts and flake-utils for? Should I use them? All these came to my mind on the first day.

I'm relatively new to nix, and this cut close:

> At this point NixOS has been around for 2 decades, but it still feels like it has not settled on good recommended workflows for incoming users.

Yes. This was a major pain point when I was getting started. The IRC community has been helpful in this regard. I also really don't like that nixpkgs serves as both a lib and a package set. Be one! I don't want "special" inputs in my config.

In the long-term, how different do you want to be from Apache Pulsar? At the moment, many differences are obvious, e.g., Pulsar offers transactions, queues and durable timers.

These things are expensive... I ended up going with a DAS, a Terramaster D6-320. It was less than half the price (270€), suits my context (network-access isn't a must; the DAS is small enough to fit behind my TV), it doesn't "force" me to upgrade my network to 10gbps (expensive!) to get reasonable performance (it's USB 3.2 gen2 - 10gbps), and I can always make a DIY NAS out of it if one day I need to.

I'm using connectrpc, and I'm a happy customer. I can even easily generate an OpenAPI schema for the "JSON API" using https://github.com/sudorandom/protoc-gen-connect-openapi

To those pointing out that it's dynamically typed, meta's rust implementation - that they use in buck2 - supports type annotations.