technosophos

Helm is a package manager for Kubernetes, and I am one of its maintainers.

Kubernetes objects can be defined in JSON or in YAML. Helm added a template language on top of YAML (based on Go's template system). It has always been an ugly thing, though it functions.

One thing we really wanted to do in the Version 3 release a few years ago was make it possible to write Kubernetes definitions in Lua instead of YAML. Then we wouldn't need a template language. Additionally, we got all the benefits of a procedural language and a way to do inheritance (which would have been profoundly powerful as an alternative to literally hundreds of lines of boilerplate YAML). And it made extending other people's work nearly trivial. All in all, it looked like a far superior path to YAML with text templating.

We produced a POC, defined a specification, and went a good way down the implementation path before a few people in the Helm community voiced such noisy objections that we walked it back.

Their primary objection was simply that they didn't want the procedural logic and the definition to be "the same thing." It was better, in their minds, to have a static file format with a template language layered on top, because that was an appropriate separation of concerns.

I've had a few years now to reflect. And I do think Helm would have been better with Lua.

Lounge access is a really good one. I have an AmEx as well, and it includes Priority Pass (which I like), Centurion (which my home airport has), and Delta lounges (if I fly Delta, though I usually fly either United or Southwest).

There is a CPAN tool to convert perl programs to an ASCII-art equivalent. https://metacpan.org/dist/Acme-EyeDrops/view/lib/Acme/EyeDro...

The challenges of getting an LLM to produce poetry.

(Another Fermyon person here)

On a lighthearted unscientific note: After getting absolutely bombarded with traffic today (5-10x normal, YAY!), we noticed: - No increased latency in responding to requests - Flat memory usage at 130MB per worker (we run Nomad) - Spiky CPU traffic (which is expected when starting and stopping Wasm modules hundreds of times a second), but never really over about 60% of the CPU on a small VM size on AWS - No Wasm downtime (though we did have a non-Wasm load balancer hiccup at about peak load, cause unknown)

I'm part of Fermyon (the company that created Spin), and we are definitely talking about this. There's a news signup at Fermyon.com (right at the top-right) that you can sign up for if you'd like to get early news about that. And for sure, if you have specific things you'd like to see in a hosted platform, I'd love to hear about it.

(One of the Spin authors here)

In all honesty, I think many of the concepts that we saw in early Java deserve to get another chance in a more language-agnostic ecosystem. I never did a lot of EJB, but CORBA/DCOM are definitely part of the inspiration for what Bytecode Alliance is doing with WebAssembly components.

Java sometimes gets a bad wrap (and so does .NET). Both ecosystems are full of amazing tooling and well-thought-out concepts. I think it's a great idea to look through these landscapes and ask, "Would these features be good additions to the WebAssembly ecosystem?"

When I first wrote WAGI, I just wanted to show people that WebAssembly could be run efficiently on the server. Basically, like you were saying, I wanted something to demo to people and say, "Look, Wasm can do a lot more than crypto-mine in a browser tab!"

Now with Spin we are able to go beyond those first assumptions made with Wagi and explore exactly how far we can push it. It has been so much fun to explore how to have a Wasm module handle Redis events, or try out Python on Wasm for the very first time, or build a little CMS in Wasm... it feels like the early days of Docker all over again!

Hi! (Another one of the Spin authors here)

We have been talking about the efficiency/footprint thing a lot. So many things sit idle in the datacenter, consuming electricity without a good reason. WebAssembly is so fast to startup and shutdown that we think we can actually make a sizable dent into amount of compute required (and hence, amount of electricity consumed) if we can build this tooling right.

Spin took a first pass at this, but there is more we want to do to boost that efficiency even more! Hopefully in a few months I will be able to write a blog post with some progress on this.