Holy shit!

https://hackaday.com/2021/11/...

I hope they are able to incorporate this.

I have never used a multithreaded scripting language before, I'm very curious where this leads.

https://lukasz.langa.pl/5d044f91-49...

There have been various attempts at removing the GIL... It will be interesting to see if it really happens.

It will be a very very very long road with lots of hickups, don't expect it anytime soon TM.

This comment is exactly why I hate all "new" languages like python and node.

A crazy high percentage of python users don't employ multiple threads. So why the paradigm shift?

To stay relevant.

And this brings me to the kernel of my dislike for python and node, they are far too plastic in their current evolution. When I select a language I EXPECT it to be the same or as close to the same all the way through its lifespan. I expect frameworks to change though.

IMO they should just split off into another language and call it something stupid like "Cobra".

@lbfalvy I had a dev argue with me that you needed to use a multithreaded language in AWS lambda or Azure functions.

So I asked the question of what they plan to do with with second thread.

They said it was to make the function more efficient and faster.

I think there's a real misunderstanding on what multithreading is, and it's concerning that so many "Sr" devs don't understand the differences between: multithreading, fibers, parallelism, and concurrency.

@sariel yes and no.

The mistake is to disallow any evolution.

Look at Windows. It's the best example how the approach of "we must keep compatibility all the way" is digging it's own grave.

I share the resentments around how some things were handled at Python, at least partially.

But a language has to evolve and adapt.

Removing the GIL is definitely one major core change, but the majority of *hardware* is SMP.

Non SMP systems have become esoteric - even in embedded.

The GIL is a relict of the past, it clashes with the current paradigm of programming *itself* for current hardware.

Your second comment makes more sense. Python has a solution for this - ASGI. Yes, I agree with the part that most don't get the differences, but mainly because it's a difficult topic.

@IntrusionCM I'm not saying languages shouldn't evolve.

What I'm saying is that if backwards compatibility cannot be maintained, a new language branch should be made.

Paradigm shifts used to come once or twice in the lifetime of the language, now they're coming 1-2 times every couple years.

Seeing this happen more and more makes me want to go back to Java or at least go back to the MS stacks.

We're running the risk of language fatigue at which point a language has a higher chance of impactful security vulnerabilities and lower support and adoption rates.

Take a look at the frameworks that build upon any language. Angular was absolutely throttled by React when it was hoping through v1.5-4. nobody wanted to use it because they couldn't tell what community support was doing.

We pick our languages and frameworks like we pick our spouses, with future *enhancements* and stability in mind. We want to build a better future together, not constantly wonder if next year will be different.

@sariel Multithreading doesn't fit in Python's feature set by it can be used by libraries that are currently limited by the GIL. I've been developing in JavaScript with a Node backend for a while now and I can't think of any features that wouldn't have fit into JS, partially because JS wasn't a particularly thoughtful language to begin with. Can you give me an example?

@lbfalvy my point was less about what python should support and more of what it does support.

If a chosen language doesn't support a feature or requirement, the problem isn't the language and there's nothing to change.

I also think that the vast amount of python code developed was only done using python because that's what the developer knew best, not what was best for the actual solution. There's a time and place for that. As a Jr dev, it's great. As a Sr dev, it's terrible.

Stop using hammers for scalpels and scalpels for screwdrivers. Nobody should use a nosql DB in-place-of a full relational DB, so why use python for anything that needs to be multithreaded?

@sariel Most massively popular Python libraries were written for Python (note that they typically aren't written in Python) because that's what the clientele knew best. Python is a scientific tool. Since scientists need to know a lot of other things and programming is purely a means of automating menial tasks, they expect a multitool. I also disagree that languages can never miss features, which you're implying. To live with your analogy, a screwdriver is cool but a composable screwdriver set with a box full of heads (all of them magnetic), a simple and a levered handle, an extender and a pivot joint extender is definitely better, and the minor expense for all that extra functionality is that if you put together a Philips with the simple handle and stick it in your toolbelt the head can fall off if you run.

@lbfalvy to run with your screwdriver analogy. You wouldn't cut off the head of your standard Phillips screwdriver, glue on a magnet, and start hacking off other screwdriver tips for your "new" multi-tip screwdriver.

You would just go out and buy one because they exist already.

If we lived in a world where it didn't exist, make one, market it, and sell it. Keep in mind that it's never going to be a standard screwdriver though, so referring to it as a standard Phillips screwdriver will only lead to unhappy customers and loss of sales.

Point is, don't dress up a pig and call her Shelia. It's still a pig, but with a dress and lipstick.

@IntrusionCM The fact that Windows is backward compatible makes it so valuable. Windows would not be such a business success without it. I want stable systems that don't change ever 5-10 years.

@happygimp0 That is a half baked answer.

Many reasons why Windows has lost a huge deal of market share is that compatibility.

A certain grade of stability over a longer time period is always sane.

But in Windows terms, we e.g. still have the 256 path limit from DOS.

Many of these "compatibility solutions" sti exist in different forms in the OS - from networking to scheduling to ...

Stability for 5 years is something entirely different than keeping backwards compatibility for over 30 years.

Completely different.

@sariel I'd say most of the time when a language introduces a new feature it involves other changes that make sense together with the initial, so it's closer to replacing a Philips with the described set than to cutting off screwdriver heads. And if the standard part of a Philips screwdriver is the head then that set is most definitely entitled to the label, so as long as the established standards are respected a language can define undefined behavior and assign meaning to what were previously considered syntax errors.

@IntrusionCM Think about how it would be if backward compatibility would last only 10 years. We have Computers that still use Windows 98 and Windows ME because newer versions of Windows don't support the hardware we need and nobody want's to invest to redesign the system.

Without so much backward compatibility, every company would need dozens of computers with Windows 98, Windows ME, Windows XP (We still have and need some), Windows Vista and Windows 7 just for some special tasks that don't run anymore on Windows 10.

@happygimp0 You just pointed out by yourself where the actual problems lies:

"don't support the hardware we need"
"nobody wants to invest to redesign the system"

Hardware support aside, which is a problem of corporations...

The "we don't want to migrate" path is one of the reasons we suffer nowadays from many unnecessary troubles.

Which is pretty much guaranteed if you can just rely on backwards compatibility instead of being forced to migrate.

Troubles meaning anything - security, e.g. missing support for newer TLS versions, network stack, e.g. missing support for IPv6…

Cut the compatibility support.

Make people and corporations migrate.

Otherwise you'll end exactly where Windows currently is: Noone is happy with the current state of affairs, but it isn't resolvable anymore cause everyone relies on backwards compatibility.

@IntrusionCM You are stupid when you think the solution is to migrate. This is way to expensive. It is just a waste of resources and manpower to redesign everything. Do you pay for it? Do you make sure the waste doesn't pollute the environment?

To the TLS version: Guess what: This computer does not have a network connection and doesn't need it.

You are insane when you think we don't need the huge amount of work previous generations did and redo everything.

@happygimp0

You're talking about redesigning....

I said migration.

"We don't need specific thing, remove it"
- migrate and adapt

"everything must be rebuilt"

Two fundamental different things.

I had this discussion plenty of times.

What you describe, especially the problem of resources and waste, is exactly the reason why you want to migrate.

Many budgets are completely eaten up by maintenance - simply for the reason that noone wanted to reduce the solution, adding was the way to go.

Which means that you'll only end up with an ever growing pile of stuff you'll have to maintain.

The conundrum of "we must keep compatibility at all costs" is that it will end up at some point as a "we must rewrite it from scratch" cause the cost of maintenance and the risk of breakage by adding stuff that might break compatibility is too much.

The rewrite from scratch then of course is a complete nightmare, as you pointed it out.

The tactic to migrate and rather apply with careful planning many small stabs to reduce the burden is more cost effective, especially long term.

@IntrusionCM Migrate it is basically the same as rewrite it from scratch. The Hardware needs a internal Bus that does not exist anymore, there exist some adapter that don't implement everything and don't work. The software was written in a language that has no compiler on anything after Windows XP. There are many components that nobody knows how they work.

The resources to constantly migrate would be much greater than maintaining an old system. I see why you had this discussion plenty of times: You don't understand the problem.

Every major OS is backward compatible, Linux is even more extreme than Windows. The Whole Unix ecosystem is backward compatible. Backward compatibility is critical, a system without backward compatibility is useless. Imagine we had stop using ASCII and replaced everything with UTF16/UCS2, only to later replace it with UTF8 or UTF32.

@happygimp0 You're again mixing things up.

Linux is backwards compatible, yes - but it does exactly what I'm talking about.

Many of these replacements have taken course over the time in exactly the manner I've described.

https://phoronix.com/scan.php/...

As an example - migrating the ide driver to the libata driver.

You don't have to break compatibility of an alternative exists.

Migrate and adapt.

Migrate all consumers, mark it as deprecated, give time to adapt to the situation, remove it.

Lots of small stabs with the result that you have only one instead of two solutions for IDE access.

Less maintenance burden, better code.

I understand the problem fully...

... and I'm tired of people who don't understand that software compatibility cannot be a hard requirement.

You can always provide an alternative solution and aid in migration - but when an alternative solution is given and there was time to adapt, cut the crap out.

Simple as that.

I cannot make much sense of the rest of your comment...

Except for the last part...

Maybe read that:

https://en.m.wikipedia.org/wiki/...