This strikes me as incredibly unlikely from an evolutionary psychology perspective. Or even from a perspective that acknowledges the relative complexity between whatever system you are envisioning and the simple (mostly) monogamous couple.
We will never know, but maybe they receive some governmental pressure to never publish and pretend the research lead nowhere so that their country only gets the benefit.
But the rogue scientist wanted to share it with the entire world.
What kind of madman tries to deploy pytorch? If it's a product, convert the finished model to onnx. Otherwise it's probably for a dev and you can tell them to have fun because installing all the gpu libs sucks no matter what. In theory mambaforge should make most of these scenarios less painful (mostly portable faster version of anaconda), but you'll still need the right cuda runtime, rocm, etc.
What makes this stuff so hard? I could probably find a Python tutorial to render a spinning cube in like 5 minutes, but as soon as you want to do ML you spend an hour just getting libraries to work?
Is there ever going to be standardization, the way a WebGL shader just works everywhere?
There is another point to consider: more and more people are writing code without being experienced programmer, thanks to easier languages, better IDE, more streamlined lib API, and now, even ChatGPT.
A geographer scripting her GIS in Python or a quant doing some pandas analysis has a very limited programming experience, since her expertise is in her job.
And so we see more and more code produced by people that don't know what is slow and fast, what is safe or dangerous, what is maintainable or not. This code is popular, because it solves a real problem by people deeply familiar with the problem, way more than a programmer would be.
I have an example at $current_client, where they have some matlab code that handles tremendous amounts of money, with no comments, no doc, no tests, side effect everywhere and some interesting quadratic behaviors. They solved by loading balancing the thing on 6 servers with 17 processes, and manual testing.
I do data engineering, and I'm working on carving out a niche for myself in optimizing code. Whereas most others want to solve sexy problems as soon as possible, it ends up biting us in the end because it doesn't scale down the road and/or costs tremendous amounts of money.
Our OKRs often include "reduce cost of X by 8%", which is nice but isn't achieved half the time. But if you have deep experience or are thinking outside the box, you can (as I have) reduce by 95%.
Sometimes it's concretely a specific amount faster because you're replacing some other workflow with the software, but yes sometimes you're enabling something which would otherwise just not happen. Colleagues in our sister group, which doesn't have any actual software engineers, helped some academic librarians build a tool to automate something they knew they couldn't otherwise do at scale. They want to teach students how to use a library effectively, and while any of them could walk say, one student per hour through this, there are thousands of new students every year, it's not manageable. Midway through the presentation the specialist explaining it said "It's not a program" and I was glad to find I wasn't the only person who wanted to interrupt, because duh, of course it's a program. They've built a program. It's a bunch of instructions, for how the computer does stuff, it's a program.
Yes these people wouldn't have attempted Python, let alone Rust, but what they've built is a program, in a visual programming language. Is that intimidating and so they might struggle to maintain it? Yes, a little bit maybe, but pretending it isn't a program won't help. And that might mean sometimes you need a software engineer, the same way that if we want a bike shed (and sometimes we do, students like bicycles), sometimes we might need the staff architects down the corridor from me, don't just throw up a few brick walls and hope you got it right.
Well, it's a wild guess, of course. But does it sound even remotely possible, that thanks to that messy matlab code $current_client now has money to hire you to look into it?
I tried to come up with something that would convey in a few words that the GIL was going to be removed for sure this time. But as a Frenchmen, I couldn't find better.
"GIL will be removed" was the closest, but it's very long, and it sounds like all those times we had the promise it would be, but it never did.
So the Prophetic perfect tense is the best compromise: it asserts near certainty, it's short, and worst case scenario the article remove ambiguity.
Plus the news popped up this week in HN front page, so a lot of people knew the context.
That is not really a thing in normal English. I had to look up what it even means, and it apparently exists only in the translation of a few passages of Biblical Hebrew (and now, apparently, the title of your post).
- take no risk, and people will blame the project for being static.
- take risks, and people will blame the project for being reckless.
E.G:
- don't adopt a new feature, and your language is old, becoming irrelevant, and a wave of comments will tell you how they just can't use it for X because they don't have it.
- break compat, and you will have a horde stating you don't care about users that need stability. You got one comment in this thread talking about "the python treadmill"!
And all that for an open source project most don't contribute to and never paid a dime for.
World would need one more language which would have very barebone core something like very minimal go or python but strong metaprogramming features so you could expand language if you need.
Maybe the next generations will evolved in ways that means they are very happy without the structure of the couple.
Other structures exist.