Wow, I didn't know you got a spot on the board, that's a great choice on their part! Thanks for giving your time.

Yes, I was talking about Wages -- the day-to-day is surely complex, but I'm sure you'd agree that the president of the board is ultimately "above" the chief executive if push ever came to shove, at least on paper. I will grant that I used "running", which is quite unclear in hindsight! "Responsible for" or "leading" seems more accurate.

She seemed great as policymaker and person, but when I last checked her job was literally to be Microsoft's Python community liason, and that just struck me as... dangerous? On the nose? Giving the reigns to someone from a for-profit, $1.5B corporation whose entire business depends directly upon the PSF's work also seems like an odd choice. Again, I'm sure they're great as an individual, and during normal operations there's no competing interests so it's fine. It's just...

I guess I just have a vision for the non-profit org guiding the world's most popular programming language that doesn't really mesh with the reality of open source funding as it exists today, at the end of the day; the "no 2 representatives from the same company" rule seems like a comforting sign that they(/y'all!) share that general philosophy despite the circumstances.

You’re asking how money can be used to improve software?

The assertions above are my memory from pre-covid, I’d look at 2019 and before perhaps. Many things changed after that (and council too) but it takes a while to change perception.

The Linux foundation is not a nonprofit. It is registered as a 501c6, basically a business consortium, unlike the Python software foundation which is a nonprofit (501c3).

The Linux foundation also stewards way more foundations and projects that just "Linux". They are, among other things, in the business of creating foundations and making money that way. For every organization under the Linux foundation, say the CNCF, to be a part of those subprojects, you need to pay a Linux foundation tax.

The Python Software foundation I don't know much about but their scope seems to be only stewarding python. They seem to have far less corporate outreach then the Linux foundation.

Linux Foundation 990 - note page 16-17 with the salaries - there are for profit entity salaries, not nonprofit salaries.

https://apps.irs.gov/pub/epostcard/cor/460503801_201812_990O...

A foundation should invest in its technology first and resist the strong temptation to fund pet projects (of leadership) with donated money.

The problem is, people who make that decision can either spend 0.1% to support open source and get return on investment in terms of better business performance in 2-3 business years. Or they could pay themselves 0.1% in bonuses right now and get an immediate return.

How about we skip the social pressure and levy a tax on them that is used to shore up a sovereign fund for OSS.

They won’t even attempt to read ToS, you think they’ll shun companies?

> 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 "povertyware" what we call software written by people and released for free now?

What is a "economically important project"? A company that makes a lot of money?

> LLVM and Linux get more cash than they can spend. GNU stuff is comparatively impoverished because everyone assumes they'd do it for free anyway. Stuff that ships on a Canonical desktop or RHEL default install gets lots of cash but community favorites like KDE need to make their own way, etc... Also just to be clear: node is filled with povertyware and you should be extremely careful what you grab from npm.

This is often the problem with charity in general. It's hard to find good organizations that actually need your money. Great ones self-sustain on their own revenue. Good ones are saturated with donations from their own users. There's just a small sliver of projects that are awesome, and could productively use financial support. From personal experience, identifying these is often far more costly than the act of writing a check.

That clears things up, thanks!

Here the website of the author: https://nadia.xyz/

It’s interesting to see everyone advocate for open source software with permissive licenses, then get mad when companies use them.

If python wants to require money for updates or for customers over $X in revenue, they can!

If companies don’t want to donate, they don’t have to just as python contributors don’t have to if they’re annoyed at how it’s used.

Rust is static. Python is optionally static.

Python type hints are static - at the moment, they are advisory only, but there is an obvious route forward to making Python an (optionally) fully statically typed language by using static type checking on programs before execution.

I doubt that this is the selling point. Imho it is nothing special compared to Haskell, F# and the likes.

But that's not the argument here. Python type hints allow checking correctness statically, which is what matters for agents.

The best benefit depends on your problem domain.

For a lot of the business world, code flexibility is much more important than speed because speed is bottlenecked not on the architecture but on the humans in the process; your database queries going from two seconds to one second matters little if the human with their squishy eyeballs takes eight seconds to digest and understand the output anyway. But when the business's needs change, you want to change the code supporting them now, and types make it much easier to do that with confidence you aren't breaking some other piece of the problem domain's current solution you weren't thinking about right now (especially if your business is supported by a team of dozens to hundreds of engineers and they each have their own mental model of how it all works).

Besides... Regarding performance, there is a tiny hit to performance in Python for including the types (not very much at all, having more to do with space efficiency than runtime). Not only do most typed languages not suffer performance hindrance from typing, the typing actually enables their compilation-time performance optimizations. A language that knows "this variable is an int and only and int and always an int" doesn't need any runtime checks to confirm that nobody's trying to squash a string in there because the compiler already did that work by verifying every read and write of the variable to ensure the rules are followed. All that type data is tossed out when the final binary gets built.

Damn… ok, I’ll try it

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.

It's true; mypy won't make your Python faster. To get something like that, you'd want to use Common LISP and SBCL; the SBCL compiler can use type assertions to actually throw away code-paths that would verify type expectations at runtime (introducing undefined behavior if you violate the type assertions).

It's pretty great, because you can run it in debug mode where it will assert-fail if your static type assertions are violated, or in optimized mode where those checks (and the code to support multiple types in a variable) go away and instead the program just blows up like a C program with a bad cast does.

> Never had anyone "frown" towards me for not using MyPy or any typechecker either

I’ve seen it many times. Here’s one of the more extreme examples, a highly-upvoted comment that describes not using type hints as “catastrophically unprofessional”:

https://www.reddit.com/r/Python/comments/1iqytkf/python_type...

Generally you only get frowned at if you're not using type hints while contributing to a project whose coding standards say "we use type hints here."

If you're working on a project that doesn't use type hints, there's also plenty of frowning, but that's just because coding without a type checker is kind of painful.

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 your ankle and pull?" And I say this as someone who will happily grab JS sometimes (for <1,000 LOC projects that I don't plan to maintain indefinitely or share with other people).

Plus, TypeScript isn't a strict superset of JavaScript, so choice at the beginning matters; if you start in JS and decide to use TS later, you're going to have to port your code.

> It's a pretty nice best-of-both-worlds arrangement

It’s also a worst-of-both-worlds arrangement, in that you have to do the extra work to satisfy the type checker but don’t get the benefits of a compiled language in terms of performance and ease-of-deployment, and only partial benefits in terms of correctness (because the type system is unsound).

AFAIK the Dart team felt this way about optional typing in Dart 1.x, which is why they changed to sound static typing for Dart 2.