Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The first year of free-threaded Python

labs.quansight.org

Post reply on HN
Print view View original

131–140 of 302 posts

Re: The first year of free-threaded Python

#131

Post by rocqua »

delusional wrote: post #71
bayindirh wrote: post #42

Earlier quoted context omitted.

Software rots, software tools evolve. When Intel released performance primitives libraries which required recompilation to analyze multi-threaded libraries, we were amazed. Now, these tools are built into processors as performance counters and we have way more advanced tools to analyze how systems behave. Older code will break, but they break all the time. A language changes how something behaves in a new revision, s…

> Software rots No it does not. I hate that analogy so much because it leads to such bad behavior. Software is a digital artifact that can does not degrade. With the right attitude, you'd be able to execute the same binary on new machines for as long as you desired. That is not true of organic matter that actually rots. The only reason we need to change software is that we trade that off against something else. Instr…

Fair point, but there is an interesting question posed.

Software doesn't rot, it remains constant. But the context around it changes, which means it loses usefulness slowly as time passes.

What is the name for this? You could say 'software becomes anachronistic'. But is there a good verb for that? It certainly seems like something that a lot more than just software experiences. Plenty of real world things that have been perfectly preserved are now much less useful because the context changed. Consider an Oxen-yoke, typewriters, horse-drawn carriages, envelopes, phone switchboards, etc.

It really feels like this concept should have a verb.

Re: The first year of free-threaded Python

#132

Post by pyronik19 »

sgarland wrote: post #48

> Instead, many reach for multiprocessing, but spawning processes is expensive Agreed. > and communicating across processes often requires making expensive copies of data SharedMemory [0] exists. Never understood why this isn’t used more frequently. There’s even a ShareableList which does exactly what it sounds like, and is awesome. [0]: https://docs.python.org/3/library/multiprocessing.shared_mem...

[dead]

Re: The first year of free-threaded Python

#133

Post by isignal »

sgarland wrote: post #48

> Instead, many reach for multiprocessing, but spawning processes is expensive Agreed. > and communicating across processes often requires making expensive copies of data SharedMemory [0] exists. Never understood why this isn’t used more frequently. There’s even a ShareableList which does exactly what it sounds like, and is awesome. [0]: https://docs.python.org/3/library/multiprocessing.shared_mem...

Processes can die independently so the state of a concurrent shared memory data structure when a process dies while modifying this under a lock can be difficult to manage. Postgres which uses shared memory data structures can sometimes need to kill all its backend processes because it cannot fully recover from such a state.

In contrast, no one thinks about what happens if a thread dies independently because the failure mode is joint.

Re: The first year of free-threaded Python

#134

Post by rocqua »

quectophoton wrote: post #7
AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

I don't want to add more to your fears, but also remember that LLMs have been trained on decades worth of Python code that assumes the presence of the GIL.

This could, indeed, be quite catastrophic.

I wonder if companies will start adding this to their system prompts.

Re: The first year of free-threaded Python

#135

Post by kstrauser »

biorach wrote: post #125
kstrauser wrote: post #73

Earlier quoted context omitted.

cough Bullshit cough * VSCode got popular and they started preventing forks from installing its extensions. * They extended the Free Source pyright language server into the proprietary pylance. They don’t even sell it. It’s just there to make the FOSS version less useful. * They bought GitHub and started rate limiting it to unlogged in visitors. Every time Microsoft touches a thing, they end up locking it down. They…

None of those were independent projects or open standards. VScode and pyright are both MS projects from the get-go. Sabotaging forks is scummy, but the forks were extending MS functionality, not the other way around. GitHub was a private company before it was bought by MS. Rate limiting is.... not great, but certainly not an extinguish play. EEE refers to the subversion of open standards or independent free software…

It’s not just EEE, though. They have a history of getting devs all in on a thing and then killing it with corporate-grade ADHD. They bought Visual FoxPro, got bored with it, and told everyone to rewrite into Visual Basic (which they then killed). Then the future was Silverlight, until it wasn’t. There are a thousand of these things that weren’t deliberately evil in the EEE, but defined the word rugpull before we called it that.

So even without EEE, I think it’s supremely risky to hitch your wagon to their tech or services (unless you’re writing primarily for Windows, which is what they’d love to help you migrate to). And I can’t be convinced the GitHub acquisition wasn’t some combination of these dark patterns.

Step 1: Get a plurality of the world’s FOSS into one place.

Step 2: Feed it into a LLM and then embed it in a popular free editor so that everyone can use GPL code without actually having to abide the license.

Step 3: Make it increasingly hard to use for FOSS development by starting to add barriers a little at a time.

As a developer, they’ve done nothing substantial to earn my trust. I think a lot of Microsoft employees are good people who don’t subscribe to all this and who want to do the right thing, but corporate culture just won’t let that be.

Re: The first year of free-threaded Python

#137

Post by bayindirh »

igouy wrote: post #129
eblume wrote: post #80

Earlier quoted context omitted.

Software is written with a context, and the context degrades. It must be renewed. It rots, sorry.

You said it's the context that rots.

It's a matter of perspective, I guess...

When you look from the program's perspective, the context changes and becomes unrecognizable, IOW, it rots.

When you look from the context's perspective, the program changes by not evolving and keeping up with the context, IOW, it rots.

Maybe we anthropomorphize both and say "they grow apart". :)

Re: The first year of free-threaded Python

#138

Post by biorach »

kstrauser wrote: post #135
biorach wrote: post #125

Earlier quoted context omitted.

None of those were independent projects or open standards. VScode and pyright are both MS projects from the get-go. Sabotaging forks is scummy, but the forks were extending MS functionality, not the other way around. GitHub was a private company before it was bought by MS. Rate limiting is.... not great, but certainly not an extinguish play. EEE refers to the subversion of open standards or independent free software…

It’s not just EEE, though. They have a history of getting devs all in on a thing and then killing it with corporate-grade ADHD. They bought Visual FoxPro, got bored with it, and told everyone to rewrite into Visual Basic (which they then killed). Then the future was Silverlight, until it wasn’t. There are a thousand of these things that weren’t deliberately evil in the EEE, but defined the word rugpull before we call…

> I think it’s supremely risky to hitch your wagon to their tech or services

OK, finally, yes, this is very true, for specific parts of their tech.

But banging on about EEE just distracts from this, more important message.

> Make it increasingly hard to use for FOSS development by starting to add barriers a little at a time. ....and now you've lost me again

Re: The first year of free-threaded Python

#139

Post by oblio »

kstrauser wrote: post #119
oblio wrote: post #100

Earlier quoted context omitted.

I actually hate this trope more because of what is says about the poster. Which I guess would, that they're someone wearing horse blinders. There's a part of me that wants to scream at them: "Look around you!!! It's not 1999 anymore!!! These days we have Google, Amazon, Apple, Facebook, etc, which are just as bad if not worse!!! Cut it out with the 20+ year old bad jokes!!!" Yes, Microsoft is bad. The reason Micr$oft…

That’s only reasonable if you believe you can only distrust one company at a time. I distrust every one you mentioned there, for different reasons, in different ways. I don’t think that Apple is trying to exclusively own the field of programming tools to their own profit, nor do I think that Facebook is. I don’t think Apple is trying to own all data about every human. I don’t think Microsoft is trying to force all ve…

Yet I only ever see these tired EEE memes for Microsoft when Chrome is basically the web, for example.

Re: The first year of free-threaded Python

#140

Post by rocqua »

txdv wrote: post #5
AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

how does the the language being dynamic negatively affect the complexity of multithreading?

Dynamic(ally typed) languages, by virtue of not requiring strict typing, often lead to more complicated function signatures. Such functions are generally harder to reason about. Because they tend to require inspection of the function to see what is really going on.

Multithreaded code is incredibly hard to reason about. And reasoning about it becomes a lot easier if you have certain guarantees (e.g. this argument / return value always has this type, so I can always do this to it). Code written in dynamic languages will more often lack such guarantees, because of the complicated signatures. This makes it even harder to reason about Multithreaded code, increasing the risk posed by multithreaded code.

Post reply on HN