JavaScript frameworks would be a candidate.

You aren't very familiar with Japanese corporate culture.

I worked at a Colgate manufacturing facility. They had an NJ plant that had mechanical production lines. They've been running for 40 years so by the time i was there they were running flawlessly day in and day out and no matter what went wrong the maintenance crew knew how to fix it right away.

To save costs they shut down that plant and opened up a new one in SC with fancy brand new electronic machines that were supposed to have much better throughput. It took them years to get all the machines working and even still the old machines produced more in 8 hours than the new ones made in 12 hours. And whenever the was a problem with the machine it was always some wonky issue with the relays, sensors, and timing and we'd have sometimes days of downtime and would need OEMs to come in and fix it.

They wasted millions on that move which was supposed to save money and be more efficient. Many were fired/demoted from that.

So the thought of scrapping a working factory with decades of fine-tuning already done... pains me.

I worked with one project manager who was straight out of school. I couldn't believe that the direction and management of multiple teams of engineers was coming from someone who was going to make all their rookie mistakes on our project... and all the people who hired him already left for new jobs, so no consequences for them.

Did they fire/demote the brain geniuses who kicked this off? Because the corporate stories I know like this generally involve the responsible parties getting promotions for their bravery and forward thinking, while the pain falls on the people they forced to work on it and who unaccountably failed to implement their perfect visions.

Case in point: when Russia started it's invasion of Ukraine, one of the first things they did was to pillage the industrial areas of the regions they controlled to take away industrial equipment, including farm vehicles.

The same is for metallurgy - it was consistently upgraded through the years and not outdated in any way.

Besides, if the idea is to invade the country to incorporate some separatist regions, it doesn't make sense to destroy its economic basis and end up with a huge refugee problem and a completely deserted land you just conquered.

This is basically propaganda for gullible Americans that never traveled to Eastern Europe.

I fail to see the relevance of that. Sounds like cheap propaganda.

My point was clear: when Russia started it's invasion of Ukraine, one of the first things they did was to pillage the industrial areas of the regions they controlled to take away industrial equipment, including farm vehicles.

HN had a discussion on how John Deere kill switches were rendering Russia's pillaging useless as the stolen tractors were being remotely disabled once they were moved into Russia.

Industrial equipment, even old one, is often used extensively in spite of existing latest and greatest offers.

If this is true for all of Russia why do they keep stealing toilets?.

Yes comrade, Russia is bigger and has a lot of oligarchs so off course there's much more money there, but average citizens are piss poor. Russian elites has been robbing Ukraine for three decades with their Kremlin buddy oligarchs like Medvedchuk, and not just Ukrainian oligarchs a lot of Russian ones were quite cozy there even after 2014. They robbed eastern part of Ukraine after ceasing control over the territory. It proved to be difficult to rob whole of Ukraine with just the dirty oligarchs, so they proceeded with full scale invasion in 2022.

As OP followed up, doesn't change the facts that Russian soldiers pillaged the crap out of Ukraine as soon as they got there; Russia may be resource wealthy but corruption means that only the boys at the top get the cream, seems like everyone outside of Moscow gets the shit end of the stick.

Regardless, no amount of success excuses the slaughtering of innocents, slava ukraini.

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-Z

I 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

Organizations tend to invest in their operations if there are significant improvements to be made. This includes things like dealing with problems such as the availability of cassetes, if the legacy system becomes too old to maintain in a cost effective way, if it's still possible to source parts, etc.

Digital systems are widespread because they are widespread and dirt cheap, and thus the tradeoff of increasing the complexity does add value.

They also churn, and finding people who can (and will) work on legacy systems isn't easy either. Get rid of something that worked for 40 years because everyone uses this other thing (but will use something else 10 years from now that we can't predict) is dumb unless there is a very valid reason.

They're still using modern computers, the simulation of what the actual fabric would look like was amazing and I'm sure when that old computer was new, they would've killed for something like that.

Unlike the fetishists of HN, I doubt that they romanticise their use of the old computer; it's simply the only one that works with their older equipment. You say it's "easy to maintain" but they'd still need a specialist to diagnose & fix, you can't take it to any computer repair shop. And getting certain parts would be an absolute nightmare as well. You say "everyone using the system is familiar with it" well duh...the sky is also blue, of course people that use it are familiar with it, but for an industry that is on the decline, trying to get fresh faces in to revitalise won't be helped by a computer that those fresh faces would never have even seen before. Power usage doesn't matter when the looms probably pulls tens of kilowatts or more anyway. But yeah, it is cool. Impractical, but cool and that rings true for everything that they're doing, small & bespoke manufacturing of traditional wear.

It's unfortunate, but a lot of boutique industries like this are dying in Japan at the moment.

"don't use new tech if you don't have to"

and more a case of

"These are highly specialized weaving machines that were build decades ago around using punched cards, and whatever benefit by speedup in process we would get from replacing their ancient control system with a modern one, would be dwarfed by the cost of modifying them to use that control system."

Or to say this with slightly less words:

Replacing software and a couple of computers is cheap, compared to replacing room-sized industrial machinery.

Furthermore, it’s very common for factories to run older equipment because the cost of upgrading is higher, riskier, and shutting the factory down to do the upgrades comes with its own losses as well.

It’s also worth noting that there was also modern computers in that video too. The system they used to “digitally preview” what the weave would look like. But that is a separate system from the ones that interface with the weaving machines and thus very easy and cheap to upgrade.

This should be the top comment. Cost is a critical factor. I would also stop riding the bus and drive a Ferrari to work if that option costs as much as a bus ticket. As it doesn't then I'm going to stick with the bus, but this does not make it a superior choice.

I'm not saying that having latest or newest stuff is any better, just that using old stuff can bring some problems too.

In that scenario you need to find someone completely familiar with the old model of computer to break out the multimeter and oscilloscope. That's gonna be a huge pain.

And in the meantime none of their stuff works, though I suppose they can rest on the existing library of punch cards they most certainly have. Or do it manually again.

For non-electronic parts: that's why you have a machine shop.

The electrolyte isn't milk. It doesn't go off.

Put it this way, I've replaced maybe a dozen "bad caps" in equipment in 35 years of repairing high-end musical kit, six of which were in one 1970s synthesizer made from very cheap parts.

But, I've done very well out of the fashion for "re-capping" equipment because I charge 300 quid before I even start to consider clearing a spot on the bench for stuff that's been "re-capped" before they bring it to me to fix.

> The only components that can't sit forever on a shelf

From there it seems to have spread out into a "recap everything" craze that is just silly.

The real fault is an 0.1μF disc ceramic, one of those little brown ones, that's gone leaky and now thinks it's a 1k resistor. Not that you'd know, with all the other iatrogenic faults the damn thing now has.

Awful. Just awful. The "it was circuitbent so I tidied it all up" thing was a Prophet 600 that I had to write off, it was so badly damaged.

Maybe, maybe not. If the machine uses the right "legacy" parts (a Z80 is a great example, but so is anything belt- or gear-driven, etc.), then it's a very good bet those parts and the people who are familiar with them will remain available for much longer than you or I will be alive.

Just kidding, couldn't agree more with your observation. Not a Phone in sight.