121–130 of 192 posts
They are probably trying to build influence. Why is a startup that is burning cash donating money?
Earlier quoted context omitted.
If your code is talking to an LLM, the performance difference between rust and python represents < 0.1% of the time you spend waiting for computers to do stuff. It's just not an important difference.
This is clearly not what I'm speaking about - there are only a few applications that talk to an LLM.
And just a few comments earlier you said:
> Just recently I heard that typed languages are best for agentic programming
Are we not talking about using python (or some alternative) to constrain the behavior of agents?
Earlier quoted context omitted.
> but for almost any economically important project all the major contributors and maintainers are on the payroll of one of the big tech interests or a foundation funded by them. "almost" is the load bearing word here, and/or a weasel word. Define what an "economically important project" is. > Also just to be clear: node is filled with povertyware and you should be extremely careful what you grab from npm. Is "povert…
> "almost" is the load bearing word here, and/or a weasel word. Define what an "economically important project" is. Linux, clang, python, react, blink, v8, openssl... You know what I mean. I stand by what I said. Do you have a counterexample you think is clearly unfunded? They exist[1], but they're rare. > Is "povertyware" what we call software written by people and released for free now? It's software subject to eco…
Essentially "povertyware" as you call it when you consider the trillion dollar companies built on top of them? Now that's way easier: SQLite, PostgreSQL, ffmpeg, imagemagick, numpy, pandas, GTK, curl, zlib, libpng, zxing or any other popular qr/barcode library, etc...
Earlier quoted context omitted.
> Linux, clang, python, react, blink, v8, openssl... You know what I mean. I stand by what I said. Do you have a counterexample you think is clearly unfunded? They exist[1], but they're rare. For Linux "all the major contributors and maintainers are on the payroll of one of the big tech interests or a foundation funded by them" is simply not true. It's trivial to prove this by just looking at the maintainers of the s…
> You will move the goalpost I can't move the goalpost if you won't produce a ball. Who exactly are you thinking of that needs a job but doesn't have one?
That is not your claim. Your claim is that they "are on the payroll of one of the big tech interests or a foundation funded by them". Which is simply not true.
You can easily find several maintainers of these projects doing this as their part-time hobby project, have cut a deal at work or simply don't work at place that funds Linux development.
I'm not going to call out individual I know the situation and/or their employment history.
Earlier quoted context omitted.
I have looked at 2018-2016, where the expenses are almost completely the main pycon and more local pycons. Also sponserships like "Pallets group, which maintains projects such as Flask and Jinja" (2018). Everything other than the main pycon is less than 1 million dollars combined in expenses. I feel it is important to look at the facts, not just vibes.
> Also sponserships like "Pallets group ... Those are "fiscal sponsorships" meaning the PSF holds money for other organizations. The PSF is not funding Pallets (or Boston Python or North Bay Python, etc, etc). They accept money earmarked for those organizations and provide administrative support. Details: https://www.python.org/psf/fiscal-sponsorees/
[flagged]
Perhaps you should do some research before judging the decision making of the PSF.
Believe it or not, not all researched information is accurate. And even when it is accurate it isn't always interpreted correctly. It is not sufficient to simply research something.
One must also discuss it. That allows revealing what one thinks they know, to help realize what they don't through coordination with others.
That is what discussion is for. If he already had a perfect picture, what would the point of talking about it be? There isn't one.
Earlier quoted context omitted.
As mentioned covid changed everything, so please stop pulling figures from that once in a lifetime event.
I have looked at 2018-2016, where the expenses are almost completely the main pycon and more local pycons. Also sponserships like "Pallets group, which maintains projects such as Flask and Jinja" (2018). Everything other than the main pycon is less than 1 million dollars combined in expenses. I feel it is important to look at the facts, not just vibes.
During the 2010s, the packaging group was begging for help. "We're only volunteers," a common refrain: https://news.ycombinator.com/item?id=46605018
During the 2020s, funding for packaging was provided by Mozilla and Chan-Zuck, as PSF wasn't doing enough. https://www.python.org/psf/annual-report/2019/
As we all know, Astral stepped in and solved the problem for them. I moved to their tools as soon as was possible. And not simply because they were fast, but because they work.
For example, here's one that pypa broke for my package a couple of years ago in pip, and never fixed: https://github.com/pypa/packaging/issues/774
Earlier quoted context omitted.
Really simple fix: social pressure and expectations should be that every company that uses open source pays a fixed amount of their revenue (is 0.1% low enough to be negligible for the companies). Companies that don't should shunned.
How about we skip the social pressure and levy a tax on them that is used to shore up a sovereign fund for OSS.
Earlier quoted context omitted.
https://devclass.com/2025/03/10/pypi-repository-takes-steps-... > CPython core developer Paul Moore described his involvement in the > packaging community and said: “it’s struggling under the weight of its own > popularity … the individuals involved are doing their best under what are > frankly near-impossible conditions.” > Moore questioned whether the fact that so many businesses now depend on > Python and PyPI mea…
Yes, it could use more funding. Glad to see that Anthropic is helping. It's still not an either/or situation. The PSF would not be fulfilling their mission if they only funded packaging until packaging was "solved" (whatever that might mean) and only then did they fund outreach.
> The PSF would not be fulfilling their mission if they only funded packaging until packaging was "solved" (whatever that might mean) and only then did they fund outreach.
They did the opposite. So they still didn't fulfill it, to the extent that Mozilla, ChanZuck, and astral felt compelled to step in.
Earlier quoted context omitted.
I think in the case of TS, it's more that JavaScript itself is notoriously trash (I'm not being subjective; see https://www.destroyallsoftware.com/talks/wat ), and TypeScript helps paper over like 90% of the holes in JavaScript. Python typed or untyped feels like a taste / flexibility / prototyping tradeoff; TypeScript vs. JavaScript feels like "Do you want to get work done or do you want to wrap barbed wire around y…
Typed Python vs untyped Python is literally the same as TS vs JS, don't let others fool you into thinking somehow it's different. > TypeScript helps paper over like 90% of the holes in JavaScript Always kind of baffles me when people say this, how are you actually programming where 90% of the errors/bugs you have are related to types and other things TS addresses? I must be doing something very different when writing…
I can just skip the mypy run if I want to do untyped Python. I can't skip adding types if I'm writing TypeScript in most contexts; it's not valid TypeScript syntax. Conversely, I can't add types to JavaScript; it's not valid JavaScript syntax (jsdoc tags and running a static checker over that being a different subject, and more akin to the Python situation).
> how are you actually programming where 90% of the errors/bugs you have are related to types and other things TS addresses
It's the things in the "wat" video. JavaScript, in general, errs on the side of giving you some answer when you try and do something very unusual with types (like add a boolean to a number or a string to an array) over taking a runtime error. TypeScript will fail to typecheck in most of the places where those operations are techincally correct but surprising as hell in the wrong way unless you explicitly coerce the types to match up.