This week (likely most of the month) I am rebuilding a backup process which appears to currently rely on Syncthing and hasn't been tested in years. Everybody got to put in their opinions, so I need to design something which has a single source of truth, also has 3-2-1 replica counts, takes snapshots of the production DBs without degrading them, and burns a monthly DVD on a workstation in the office. Once I'm done with that, I get to look at the office VPN's performance problems.
If you were creating a new programming language from scratch, there's no clear agreed answer to what error handling approach you should pick, not the way we have more or less agreed on how for, while, and so on should work.
I think that they don't talk to enough language designers. Errors-as-values is the correct model because it eventually leads to the understanding that errors are our opinions about the state of the machine rather than an actual failure of the machine's invariants, and the permanent divide between recoverable-yet-undesirable "error" states and genuine faults in the hardware. All other error models persist due to inertia and machismo.
This doesn't mean that exceptions have to be removed from languages, but rather that we should think of them as continuation-passing or stack-controlling operations which perform non-local jumps; they're part of the structured-control-flow toolbox along with break/return/continue jumps. Going in the other direction, a language designer need not add exceptions if they intend to add call/cc instead.
You'd be left to evaluate trade offs in language design and language ergonomics and to make (and justify) your choices, and there probably would always be people who think you should have chosen differently.
Yeah, but Sturgeon's Law never stops; most new programming languages are fundamentally not interesting because they are either garbage-collected Algol-descended languages or memory-unsafe. Meanwhile, sum types can always be added to simply-typed lambda calculi without invalidating any safety properties. If you argue in favor of mediocrity, you're gonna get Golang instead of something good.
Shit, I didn't realize you were so young. Back in the 90s, before 9/11, none of these disclosure requirements existed; only a customs declaration was required to enter the country, and the naturalization process consisted of paying a fee, taking a test, and swearing an oath. We used to associate this sort of disclosure requirement with petty kingdoms like Bahrain or Thailand, where there are laws against insulting the monarch and therefore a justification for thought police. We shouldn't let any of the four presidents who have slid us into fascism avoid the blame.
For what it's worth, most of your comments aren't eligible for copyright; they aren't sufficiently original or information-packed. Just like @onlinepersona@programming.dev and their licensing efforts, it's mostly a vanity to attach a license to unoriginal one-line throwaway jokes. I wouldn't say that it's arrogant so much as lacking in self-awareness; a one-liner must be deeply insightful, contain a pun or paraprosdokian, address the current zeitgeist, or otherwise be memorable above and beyond the time and place that contextualized it.
As a relatively heavy solution, you can use a container orchestrator that understands a failure to pull an image as a temporary or transient situation. The lightest orchestrator that I've used on NixOS in a homelab is k3s:
services.k3s.enable = true;
It is more-or-less a cut-down Kubernetes, and as such it will not fail to start merely because one Pod had an error pulling one Image. It will also offer a path forward if you want to continue building up software-defined networking.
That all said, I'd re-examine what you want from service isolation during OS upgrades; it's possible for routine NixOS updates to only restart affected services and not reboot. In production, nixos-rebuild switch can do things like upgrade shared libraries, switch webroots, or flip feature flags. Containerization might be unnecessary overhead, and I say that as a Kubernetes proponent.
Reading between the lines, the documentation has the key:
Generic instances … correspond to
SemigroupandMonoidinstances defined by pointwise lifting.
In more words: each generic type can be broken up into a tuple-like row of components, and the generic type admits a monoid/semigroup whenever every component in the row admits a monoid/semigroup. In your handwritten Semigroup instance, the given code is agnostic as to the types of variables and functions; all that matters is that they already have Semigroup instances of their own.
Let me answer the other question: where's the monoid in the generated Rep? Well, there isn't one! The Rep merely has a struct-like product of component types. If a monoid exists for each component, then a monoid for the entire struct exists (and is built from the obvious pointwise lifting!) but otherwise there isn't a monoid derived from the struct itself. This should be a notable contrast from generic instances for e.g. Functor, where every Rep has exactly zero or one Functor due to the algebra of the semiring of types (there is an underlying algebraic equation with at most one possible solution.)
Well, here is a very funny one-off commit, but my biggest effort was probably substantial parts of a couple AMD/ATI GPU drivers, well-summarized here. As usual, that was a team effort, with particular credit to Deucher (AMD), Glisse (radeon maintainer), and Airlie (DRM/DRI maintainer). So, put up or shut up. Or, to paraphrase the sentiment that you seem to not grok: talk is cheap; show us your code.
Let me make it clear. I call out brigading because it is useless noise that distorts and obfuscates the kernel development process. I don't care that you're salty that I'm pointing out that your "absolute crickets" comment is not only incorrect, but empty in the sense that your lack of perception is not a substitute for the actual process of kernel development. Additionally, in this case, it seems like you're still focused on personalities rather than the underlying computer science; I expect "absolute crickets" when asking you about the topic of memory safety.
You literally attach a license to every comment you post. The rules which make that license effective are the same rules which make Free Software and open-source licenses effective, too. Show some solidarity; you're part of the community too, and you should feel comfortable making the same demands as the rest of us. When you say that "open source defenders" are distinct from "developers" you are contributing to a schism for the sake of aggrandizing employment and exploitation.