I've been a full-stack web developer for over a decade across multiple companies and this is the first time I've seen the phrase "discriminated unions".
And the wikipedia article is horrendous. It starts with the following sentence and gets worse from there.
> In computer science, a tagged union, also called a variant, variant record, choice type, discriminated union, disjoint union, sum type or coproduct, is a data structure used to hold a value that could take on several different, but fixed, types.
It uses lots and lots of words to explain something that's very simple. If you don't already know what it is, you can't figure out which words are important.
Then after all of the theory, it dives into a binary tree example which has to be the worst possible way to explain it. If you haven't implemented a binary tree before, you don't know any idea what you're looking at. It didn't help that I implemented a linked list in college.
Also, the choice of language ensures you have no idea what the types are. I completely missed the first example was self-referential.
It's like parody of a function programmer writing an explanation for anyone who isn't a functional programmer.
I've been programming in some form or another since the late-80s. I've been paid to write code for other people for over twenty years. I haven't gone to university.
Maybe it's because I started back in BASIC, assembler, and later C that I know what that term is and have encountered it in various languages and forms several times since?
The problem with wikipedia definitions is that they have to be the definition. Some one like me would expect a link to the definition and not a tutorial. They're not written to take into account that you've been a professional programmer and have never been exposed to a computer science curriculum nor are they written for laypersons who don't know anything about programming.
It's a similar problem for functional programmers trying to explain functors, monoids, and monads: these are not terribly complicated abstractions but catering your explanation to the various audiences out there is incredibly difficult. The definitions sounds like gibberish... but with effort and education it is possible to understand and appreciate it.
https://basarat.gitbook.io/typescript/type-system/discrimina...
I'm sincerely sorry for confusing you! Discriminated unions are nice but above I was exaggerating excessively to make a point :)
10 DEFINT A-ZI also enjoy piling on Rust fanboys,but those of us who had to go through late night troubleshooting sessions to track issues that were ultimately caused by use-after-free issues do tend to be vulnerable to Rust's memory safety siren's song
In any other situation I firmly believe the benefits Typescript brings very quickly outweigh the small amount of added complexity.
(But this may be addressed by a more cooperative attitude, compare: https://www.masswerk.at/pet/?prg=wannapet&clr=white or https://www.masswerk.at/pet/?prg=petrabbit&clr=white)
enthusiast: if you'll migrate service X from a small sets of VMs to K8s cluster (which will take N man-moths because of reasons) it will auto-scale
Old grumpy man: but the the load is low and predictable we don't need autoscale and if load will grow we will just create two more VMs
enthusiast: auto-scaling will save time in the distant and unlikely future and CTO agrees that K8s is the best way to run software so you have to migrate anyway
Because then it won't scale.
And the moment you do you run into other bottlenecks.
We're not running the DB in Kubernetes though.
For DR, Entire stack is being continually synced with a set of hot server in separate datacentre. We run a fully DR exercise yearly and it works well. It's a fairly proprietary AIX / DB2 method though so not sure you'd find value unless you're using the exact same technology stack :-/
That's perfectly ok, if your deployment costs are irrelevant and/or your company gladly pays up your infrastructure costs without a second thought.
This is not the case in some organizations, and toggling a setting to auto scale a deployment can automatically save you thousands of dollars per month.
Would you still be so casual about infrastructure costs if you had to bankroll the extra capacity you need to add to your baseline to support peaks?
The decision process involved in managing your single-box deployment is not the same that goes in managing global deployments with dozens of instances per region. Cloud providers charge a premium, and that premium is a lot.
It's like the thermostat in your office. If you're just running an AC in a single room then you can just set it to full blast to keep it day and night at a certain temperature. Once there's a decision to cut costs then you start to talk about the best time to turn off/turn on a AC unit.
Also, deploying a new build on VMs is extremely manual compared to k8s, unless again you set up some sort of home brew rube Goldberg machine to auto deploy. It's just way better to use k8s in tandem with a simple GA workflow.
Definitely not an expert, but I get the impression that this point is a lot higher that most people assume it is.
K8s makes little sense unless you run on bare-metal. Once you jump to vms you are injecting another abstraction layer and take on a herculean level of ops without understanding what you're getting into.
I'm not sure where the check points are now, but typical points where cost jumps are desktop -> server socket, single socket -> two sockets, two sockets -> four sockets, four -> eight sockets. AFAIK, AMD EPYC isn't offered at more than two sockets, and going to four sockets used to be possible off the shelf but very expensive, and eight sockets was very expensive if off the shelf or very expensive because custom engineering. Sometimes ram costs go way up for the highest density too.
[1] From Walden: read at https://www.gutenberg.org/files/205/205-h/205-h.htm