Tech zoo sometimes considered to be an anti-pattern in microservices. By introducing a different language into your organization, you decrease the mobility of developers between code bases and dilute technical knowledge.

Everybody shouldn't pull in their favorite stack just for fun, but it seems valuable to have the option of trying out new things that could turn out to be a better way forward for the org

Rewriting a module from one tech stack to another is not much harder when that module was a part of a monolith and not a separate service, except that you haven't paid the upfront cost of bootstrapping a new service, putting in RPC calls, etc. And in any case, starting a project as microservices is already a bad practice due to a number of reasons, the most important for me is that it's hard to change module boundaries, which you will most likely get wrong in a new project.

Not worshiping the Microservice, doesn't mean that you avoid services in different languages.

Not all engineers need to move around - DS and MLEs are generally useless on the frontend, and vice versa.

> This references the "fuzzing" infrastructure hosted by the Reproducible Builds project, and doesn't show "true" reproduction of binaries. It's designed to help us figure out where impurites occur in builds.

I think the "fuzzing" approach is actually the correct one. The fact that build systems are static does not improve reproducibility on its own, as the idea is that the packages could be built on different systems and result in the same binaries. If I built some Arch PKGBUILDs from the official community repo, I should still get the same binary, despite the fact that my machine has a different setup from the Arch project's own infra.

You can always run Nix in Docker to build and run any software that uses it. Without Nix, however, I am forced to either install a bunch of bloat into my system such as Haskell compilers or libraries, or run Docker anyway.

And how does it recover incomplete tasks in case of sudden power outage? Microservices use persistent message brokers for that, which are not there in threads. Or are these monoliths all treated as pets with redundant power supply and network lines?

Thread does not imply no queue or no persistent storage. In fact, if you use something like Hangfire you already have that.

It looks a lot like XMPP with some of its flaws – too much flexibility and no principled stance on privacy and security issues. For example, I couldn't find how ActivityPub supports signatures of sent content, while Mastodon (one of ActivityPub implementation/services) specifies and requires it. And it's really disappointing that they don't solve the identity theft problem, leaving it all in hands of instances' admins.

I use Mastodon over the web-interface. Where would signatures of sent content be generated or signed? How does the receiving end verify the signature?

With XMPP+OMEMO I have verified the fingerprints of my friends by scanning their QR code.

I'm sorry, I don't have a good answer for you. While PGP-like web of trust is accessible on native desktop and mobile applications, it's certainly harder to use in browser. I don't think that it should be an argument against supporting it.

One of the widespread solutions in the cryptocurrency world is browser extensions, which store in its private storage the private key and allow you to use it to sign some transactions in the same browser window. I reckon it's possible to implement the same approach for PGP and store the private key and trusted public keys in order to sign and validate messages.

It's not difficult, but it's disrupting to your coding flow, which is bad in itself and even worse when prototyping.

More disrupting than a really slow compiler?

Yes. If Zig takes 100ms to compile, and Rust takes 2s, but you just spent 20 seconds commenting unused vars in your Zig code, then the slow compiler comes out ahead. It's a great example of how good UX can be more important than raw performance numbers.

Yes, but you comment out unused variable once per variable (you can leave those underscores in and clear them out before release). The 2s happens every time you compile. The badness of slow compiles is non-linear, too. As you start to get to 30s, the likelihood that you check Facebook, Twitter, or hn goes up. At least when you're underscoring unused vars you're doing something active.

If it gets to 2-5 minutes the likelihood that you stop writing tests and rely on the compiler for bugfreeness goes up - or the likelihood that you create debt by increasing the complexity of your code organization.

Strawman. Incremental compile times don't hit 2-5 minutes in either language, otherwise it obviously wouldn't be viable for real-world use.

And juggling variables was an ongoing ordeal when I tried. I can't imagine how you would work on code without changing any of the variables.

It's really not a problem for me. I've worked on probably about 20k LOC of zig. Probably the one time it was an issue was when I wrote some code that wrote zig -- and then it pushed me into realizing that this was a code smell, and a refactoring fixed it.

Compile times of 2-5 minutes can happen in langs that are not rust. You mentioned rust, not me. And anyways the 30s to hn thing is real.

> (you can leave those underscores in and clear them out before release)

You can leave those "unused variable" warnings and fix them before release

The difference is that warnings are visible, the underscores however suppressed the compiler's ability to help you.

allowing undefined variables doesn't slow down the compiler.