Hacker News Reader

Comment by gautamcgoel | Hacker News Reader

This is potentially problematic. It creates a conflict of interest: will the GIL proposal be accepted based on technical merits and potential benefits to the Python community overall, or just because the Python foundation wanted money? The problems that Meta faces in production are not necessarily the problems faced by every Python developer. In particular, Meta might value performance more than backwards-compatibility, while other Python users might feel differently. If Meta were to offer unconditional support, that would clearly be good for Python; attaching conditions to their support makes the situation trickier to navigate.

View on HN

You not reading the thread is problematic. Meta is pledging 3 years of engineer time not money.

Time is money. Meta is pledging the salaries of three individuals.

But it is just for the nogil project. If suppose python foundation doesn't believe merit in GIL, they aren't getting any benefit out of the situation.

Never the less, the OP is incorrect. Time is money. The fact HN doesn't seem to recognize this and downvoted the comment is mystifying.

We all remember the anti-OSS 'Linux is only free if your time is free'.

Because the whole point of the thread is "It creates a conflict of interest because money" which it doesn't. Time costs money, sure, but time is not equal to money. There are many differences. Otherwise where is my money from HN.

Woah, are you kidding? I would have died to have people dedicated to OSS I worked on! Time is money. We get paid for our _time_ at the core of what we do as a profession. This should be plainly obvious.

The alternative is Meta puts in no money to salaries and benefits for up to three individual's time on this project, or Meta puts in no money at all.

Meta is paying, one way or another, for this project.

> Meta is paying, one way or another, for this project.

Did I deny this?

To put it in extreme clear example, just said time for someone to punch you != time for someone to work for you, while money is same all across. I hope you don't disagree with it.

And it's 3 years of engineer time to work on this project, so I don't get the bribery insinuation. Engineer time to work on a specific project is only valuable if you consider the specific project valuable.

You could maybe make the argument that they're trying to swing priorities if this is considered valuable but less valuable than other things, but given the PSF doesn't actually employ anyone who it can direct to work on specific projects anyway, how is this any different from the already existing prioritisation process of "things that somebody is interested enough to go through the PEP process and then work on"?

TBH having CPython internal experiance is quite a qualification. They would probably contribute at least some of thier time in the no PEP 703 case so the delta is even leass.

It doesn't really matter to the argument though, no?

Your premise is incorrect, as this is not a promise of money.

What is Meta's end game with Python? Do they genuinely just want a stable build without GIL because of some cranky in-house code piles, or is this the first step towards a bigger mission to wrangle an entire ecosystem?

They use Python as the basis for instagram, which is a large growing service.

And now Threads as well.

Would you they rather used these man years to implement it behind closed doors & never release the build?

They use Python. They want to donate engineering time. They think this is a good idea. Why does there have to be a sinister motive?

Calling it a "donation" is even too generous. They use python and would save a lot of money running it (less severs) if it could run multi-threaded. Implementing it themselves and maintaining a fork may be cheaper in the short term but due to ongoing maintenance and third-party extension incompatibility it would likely cost them more in the long run. So they are effectively investing 3 engineer/years of resources to A) ensure the project gets done and B) help it get done faster.

I don't see any charity here, this is just a smart business move by them. When you run as many servers as Meta does being able to run 1/4 as many instances is huge RAM and therefore money saving. It won't take long to add up to 3 engineer/years.

I agree charity is not the right way to frame it. But if this was a pure money decision they would save time and effort forking the language and improving it as closed source.

They have the expertise to run a language fork and because of the scale they run at they would easily save more money doing so. Meta contributing to OSS is not an economic decision. It is about branding, trying to attract technically strong individuals (who tend to contribute to OSS or want to), and sticking to their open culture.

> they would save time and effort forking the language and improving it as closed source.

Actually, experience has shown the opposite to be true. Time and time again even large organisations find their fork falling behind the community version and the pain of merging new versions from upstream grows and grows

GIL has been a major pain point when training machine learning models, where every library is Python first. The data preprocessing phase must happen quickly enough and in parallel with respect to the GPU operations. The simplest option is doing data processing in several threads other than the one driving GPU operations, but that is not possible with GIL. TensorFlow and PyTorch each has their workarounds for this problem, but many difficulties remain. Removing the GIL will be greatly beneficial to this domain at least.

Reply on news.ycombinator.com