Cool: "Therebve been some improvements to interop - you can now host windows applications inside tmux and screen without them destroying the rest of the window!"

Nonetheless, docker (not necessarily k8s; you don't need k8s to do
docker) is the new standard and in most respects, our consultants
dragged us kicking and screaming into the new reality. And they were
right.

Right ... I've deployed Docker containers on "regular Linux" a few times.

But if you're building a dedicated environment to run Docker stuff, k8s seems to be the most popular way to do it?

Dunno why someone would do that when they could just run Qt everywhere. (It even works with Python now!)

Well...

1. Qt requires learning Qt, at the very least. Which only really works with Qt. Whereas an Electron app can be easily turned into a web page.
2. Qt requires the Qt libs, which may mean dealing with FOSS stuff. Electron does, too, but isn't as fussy as Qt about it.

For my needs, at least, Qt is not an option.

Concern #1 there, though, kind of makes me sad in some ways. We're turning JavaScript into the language of choice for GUI development. Is this really a good idea?

JavaScript is becoming the language of choice for pretty much everything, actually. Except for the Gotards who think they're going to replace C with Go. We call those people "future C programmers"

Maybe, I dunno... JavaScript is just... er... strange in certain ways.

k8s may well be the most popular, but it is more complex than its competition and it's not as well-integrated into the amazon environment in particular. (that's starting to change with EKS but it's still less of an AWS-native solution, in my view, as it wants to do things its own way.)


long and short, docker is the standard but for the underlying docker-compliant deployment cluster there are at least 3 competing alternatives. ECS is my choice in an Amazon environment.

JavaScript was a hack, just like PHP was. It just happens to have evolved into a real language somewhat more elegantly than PHP did.

There's that.

You can't retcon a language. You have to build with whatever came before.

And nobody can anticipate where programmers will want to go with a language.
At least, not perfectly. So, yeah, sometimes the language goes absolutely south, but sometimes it just kinda gets weird, but manages to hang on.

C++... heh... to consider a language that's grown weird thanks to evolution.

k8s... that's that... what... kuberknocknees thing or whatever?

I've been curious about that. We could benefit from something that lets us build out a full virtual environment in one place, then deploy it to this cloud engine, or that one (AWS, or Google Cloud, or some local customer site without internet access, or whatever). I'm lead to believe k8s could do that, but I haven't had time to research it well enough.

We do that with Openshift and Kubernetes.

So yeah, my new shop runs node.js. I'm not a huge fan. Seems like a toy environment. But that's what we said about Java back in 2000-2004.

TypeScript makes it less horrible, but the underpinnings are weak. Absolutely no preemptive scheduling, so you have to resort to hacks if you're doing anything cpu-intenssive. Cluster mode is really suboptimal - 1 heap per cpu core. and so on.

People complain a lot about threaded languages, but I never had a huge problem with Java. You do have to keep a close eye on your junior programmers to make sure they don't mutate the class variables of service classes, but it's not usually a big problem.

A lot of the thread-hostile languages take their hostility just a little too far. It would be nice to have a language where state is shared-nothing *by default* but can easily be shared...

You can't retcon a language. You have to build with whatever came
before.

yeah, PHP tried retconning (php5) and look where it got them. python3 broke everything too, but at least they were a lot more explicit about separating the versions and the migration path.

you can get about 90% of the way to this cloud-independence nirvana with just docker-compose... ECS command-line tools accept docker-composse files as input...

retcon? was is das?

I was able to learn as much from a quick DDG search. I'm trying to understand how the word applies to programming languages.

I took his usage of that word to mean, "changing the semantics of a language in a highly backwards-incompatible way, because of better-design-remorse on the part of the language designer"

Yeah, LS got it.

In my mind, when you retcon a comic book, you're changing the character's backstory to fit some other direction that you want to take the character.

But you can't do the same thing with a computer language... you can't just change the language to make it go in new direction (at least, if it is a well-used language), because all the old code relying on the broken semantics of the old language constructs requires it continue to work that way. You'd impose a ridiculous amount of work on so many people, they'd most likely abandon the language rather than embrace the change.

Which is kind of funny, as people might abandon the language eventually anyway if it continues to make their job harder.

I wish I could research that right away.

We continue to embrace a particular vendor that I kind of despise (because of the way they have treated us in the past). I would prefer us to prepare our product in a way that would allow us to jump to a better vendor should one arise (or to our own version of what the vendor does, should we ever decide to put up the money to do it). The more stuff we build in that vendor's environment, the worse the situation gets, to my view.

Besides, there is value in keeping the vendor on their toes. A vendor who needs us, but thinks we need them, doesn't react as well to problems as one that needs us, but doesn't think we need them.