I can remember something like this a few years ago when a customer emailed our helpdesk with their own internal IT support desk in copy. Our helpdesk at the time sent a complete new email acknowledging the request, which the customer's desk ALSO acknowledged in a new thread...

I think it took us a good hour and a few hundred tickets to get the helpdesks to stop fighting with each other!

Ah, mailing loops are great.

I remember working for an ISP in the mid 90s. We never really had problems with 1 to 1 mailing loops bouncing back and forth, but we ended up with a large circular mailing loop involving a mailing list, and bad addresses on it getting bounced to the previous server which sent a reply to the mailing list, which got bounced and sent to everyone in the group which caused someone else's mailbox to fill up that was in a forward, which for some reason sent a bounce to the mailing list that really started to set off the explosive growth.

Needless to say the bounces seemed to be growing quadratically and overwhelmed our medium sized ISP, a decent sized college, and a large ISPs mailing system in less time than anyone could figure out how to get it to stop.

One thing that is real is companies using LLMs to fill roles they couldn't afford to spend on before. Like the tourist who uses Google Translate on a trip to Japan: in principle they are saving 10k on the cost of a professional interpreter. On the other hand they never would have had the resources for a professional interpreter.

Came across hocon recently and prefer over both yaml and kson. https://learnxinyminutes.com/hocon/

I've been looking at this a lot, for ourselves (multitenant saas app running on gcp) and for our customers, who are starting to be curious about something between fully self-managed (too costly) and centralized/multi-tenant/american cloud.

One thing that strikes me is the relationship with architecture. A monolithic, vertically scaled app can run ANYWHERE where I can rent a VM, whether in Norway with Upcloud or on a VPS in Kenya. It's only when you start stitching together managed DBs with autoscaled instance pools etc that vendor lock in begins.

All of these nice toys make our service highly available. But while the overall risk is lower, it is far more correlated between customers. If our service would go down because of a political event, it would go down for all our customers at once.

What about a control plane that manages a fleet of per-customer VMs across an array of cloud providers? Has anyone ever tried this?

This a very early draft I'm following: https://wicg.github.io/local-peer-to-peer/

You are off by one f.

A record's fields are final, so records are immutable (though they can include immutable pointers to mutable objects)

This honestly sounds like a nightmare: multimegabyte wasm downloads, data corruption in production and byzantine hacks to coordinate writes between tabs. I am very grateful that we chose IndexedDB instead for our application!

The primary point of the article is to compare two compilation targets for a single codebase: JS and WasmGC.

It's an extremely timely and interesting topic.

The performance of a third compilation target - JVM bytecode provides a useful baseline.

You just wrote out a series of true statements. But you aren't engaging with the comment that I wrote. <https://en.wikipedia.org/wiki/Grice's_maxims>

You're right: the article is comparing compilation targets for Java programs (or rather, one specific Java program in this case study). That's my point: despite that being what the article actually is, it's written like it's comparing Java programs to JS programs—the performance that a Java program can achieve versus the performance of a comparable JS program written to give the same results. But again, it's not comparing those. It's comparing how well they can compile Java, in Java source files, to JVM bytecode (or Wasm) and execute it on the corresponding VM versus how well they can get those Java source files to compile and run on v8 and various other JS runtimes. It's an analysis that simply doesn't show what is suggested by the authors' comments (e.g. "The challenge: JavaScript" and "Why is JavaScript slower than Java?" or anywhere that they refer to the (nonexistent) "JavaScript version").

Very sloppy and irresponsible use of language throughout. The whole article is a mess of confused thinking (at best, that is—the alternative is deliberate malfeasance).

I'd encourage you to take another look at the article because I don't think your criticisms are well founded.

The javascript version does exist! The fact that it's produced by a compiler doesn't undermine it's existence.

What's interesting here is not that it's slower than the equivalent running on the JVM but that it was _faster_ than a version compiled to wasm.

Well written and useful article if you would like to learn about what type of optimizations are effective in targeting the wasmgc runtime.

I have read it closely no fewer than three times. It's junk and filled with sleights of hand like I already mentioned, which you don't pick up on by not paying enough attention.

Ok, I have to ask: are you a Random Number Generator (RNG) supplier, or a Renewable Natural Gas (RNG) supplier, or some other kind of supplier??

Considering they mentioned working with gambling/casinos, I would assume random number generator. Which may seem somewhat trivial to build a business around, except if you’re in a highly regulated industry like gambling that regulates the implementation of randomness (and probably requires auditing and other complicated things like that). I would love to read a blog post on all the complexities at here.