This part is beautiful:

> Serialization Protocol: The library uses a custom "Envelope" protocol (PayloadType.RAW vs PayloadType.LIB). This allows complex objects like Mutex handles to be serialized, sent to a worker, and rehydrated into a functional object connected to the same SharedArrayBuffer on the other side.

It's kinda "well, yes, you can't share objects, but you can share memory. So make objects that are just thin wrappers around shared memory"

Some languages allow to define type alias, name of this type can be self-explanatory:

  type FullName = string;
  function combineName(first: string, last: string): FullName;

Also documentation comment for function is what specifically solves this - describes what function does and returns.

Neither really addresses the issue. Making a type for a single kind of string seems like an abuse of types just to shoehorn the documentation in. Documentation can be used directly of course, but that moots all of this -- just document? Yeah, but naming the variable is super quick compared to either.

Variable names is just documentation. Having types that can assert some condition on the underlying value is not even comparable to "having a named return variable". (just document? just name variables?) You don't care about what the name of the returned value is, you care about what *it is*.

Typescript nukes primitive aliases like this sadly. Intellisense will just infer it as "string".

Hey! This url and any search I do are blocked with 403 if I access it either with Tor or my VPN. Anyway I love kagi and continue to use this, but this aspect is pretty annoying.

Yes, deployment in Elixir is painfull. We use distillery and edeliver, but plan to try move to docker

I build releases with distillery and deploy them with Docker, the combination has worked really nicely for my projects.

Disclaimer: I'm the author of exrm and distillery, so I'm probably biased.

You are are not biased just experienced with the tools. Huge thanx for distillery.

Thank you for distillery, it's a very nice tool

I don't see why it should be painful. What were the issues you were facing?

I found that besides hot-code updates, there is not as much magic as one could think, and once you "grasp" the idea of a build machine, it should be pretty straigt-forward. Throw in an HAProxy for rolling deploys and you have a sweet zero-downtime solution!

Feel free to contact me if you need someone to help out (from some free general tips and tricks to supporting your team as a consultant).