Oh I’m with you there! And otherwise totally understandable.

I think for python tooling the choice is Python Vs Rust. C isn’t in the mix either.

That seems fair. Though I recall Mumba making headway (at least in the anaconda / conda space) and it is a C++ project. AFAIU, their underlying internals have now been folded into conda, which would mean a fairly popular, and arguably successful portion of the tooling ecosystem (I tended to reach for conda and recommend the same to many) is reliant on a C++ foundation.

On the whole, I imagine this is a good thing as the biggest issue Conda had was performance when trying to resolve packaging environments and versions.

So, including C++ as part of C (which is probably fair for the purposes of this discussion), I don’t think C is out of the mix either. Should there ever be a push to fold something into core python, using C would probably come back into the picture too.

I think there’s a survivor bias going on here.

Your survivorship bias point on rust makes a lot of sense … there’s certainly some push back against its evangelists and that’s fair (as someone who’s learnt the language a bit). Though I think it’s fair to point out the success stories are “survivorship” stories worth noting.

But it seems we probably come back to whether fundamental tooling should be done in python or a more performant stack. And I think we just disagree here. I want the tooling to “just work” and work well and personally don’t hold nearly as much interest in being able to contribute to it as I do any other python project. If that can be done in python, all the better, but I’m personally not convinced (my experience with conda, while it was a pure python project, is informative for me here)

Personally I think python should have paid more attention to both built-in tooling (again, I think it’s important to point out how much of this is simply Guido’s “I don’t want to do that” that probably wouldn’t be tolerated these days) and built-in options for more performance (by maybe taking pypy and JIT-ing more seriously).

Maybe the GIL-less work and more performant python tricks coming down the line will make your argument more compelling to people like me.

(Thanks very much for the chat BTW, I personally appreciate your perspective as much as I’m arguing with you)

Yep! And likely the lesson to take from it for Python in general. The general utility of a singular foundation that the rest of the ecosystem can be built out from.

Even that it’s compiled is kinda beside the point. There could have been a single Python tool written in Python and bundled with its own Python runtime. But Guido never wanted to do projects and package management and so it’s been left as the one battery definitely not included.

I feel like this is conflating two questions now.

1. Whether to use a non-Python language where appropriate
2. Whether to use rust over C, which is already heavily used and fundamental in the ecosystem (I think we can put cython and Fortran to the side)

I think these questions are mostly independent.

If the chief criterion is accessibility to the Python user base, issue 2 isn’t a problem IMO. One could argue, as does @eraclito@feddit.it in this thread, that in fact rust provides benefits along these lines that C doesn’t. Rust being influenced by Python adds weight to that. Either way though, people like and want to program in rust and have provided marked success so far in the Python ecosystem (as eraclito cites). It’s still a new-ish language, but if the core issue is C v Rust, it’s probably best to address it on those terms.

Fair, but at some point the “dream” breaks down. Python itself is written in C and plenty of packages, some vital, rely on C or Cython (or fortran) and rust now more and more. So why not the tooling that’s used all the time and doing some hard work and often in build/testing cycles?

If Guido had packaging and project management included in the standard library from ages ago, with parts written in C, no one would bat an eye lid whether users could contribute to that part of the system. Instead, they’d celebrate the “batteries included”, “ease of use” and “zen”-like achievements of the language.

Somewhere in Simon’s blog post he links to a blog post by Armin on this point, which is that the aim is to “win”, to make a singular tool that is better than all the others and which becomes the standard that everyone uses so that the language can move on from this era of chaos. With that motive, the ability for everyday users to contribute is no longer a priority.

Cool to see so many peeps on the Fedi!

While I haven’t used uv (been kinda out of Python for a while), and I understand the concerns some have, the Python community getting concerned about good package/project management tooling is certainly a telling “choice” about how much senior Python devs have gotten used to their ecosystem. Somewhat ditto about concern over using a more performant language for fundamental tooling (rather than pursuing the dream of writing everything in Python, which is now surely dead).

So Simon is probably right in saying (in agreement with others):

while the risk of corporate capture for a crucial aspect of the Python packaging and onboarding ecosystem is a legitimate concern, the amount of progress that has been made here in a relatively short time combined with the open license and quality of the underlying code keeps me optimistic that uv will be a net positive for Python overall

Concerns over maintainability should Astral go down may best be served by learning rust and establishing best practices around writing Python tooling in compiled languages to ensure future maintainability and composability.

I mean he’s walking right into this isn’t he!

Oh for sure. All of this is clearly a situation where the law is slow to catch up.

There are obvious responses here along the lines of embracing piracy and (re-)embracing hard copy ownership.

All that aside though, this feels like a fairly obvious point for legal intervention. I wouldn’t be surprised if there are already existing grounds for legal action, it’s just that the stakes are likely small enough and costs of legal action high enough to be prohibitive. Which is where the government should come in on the advice of a consumer body.

Some reasonable things that could be done:

• Money back requirements
• Clear warnings to consumers about “ownership” being temporary
• Requiring tracking statistics of how long “ownership” tends to be and that such is presented to consumers before they purchase
• If there are structural issues that increase the chances of “withdrawn” ownership (such as complex distribution deals etc), a requirement to notify the consumer of this prior to purchase.

These are basic things based on transparency that tend to already exist in consumer regulation (depending on your jurisdiction of course). Streaming companies will likely whinge (and probably have already to prevent any regulation around this), but that’s the point … to force them to clean up their act.

As far as the relations between streaming services and the studios (or whoever owns the distribution rights), it makes perfect sense for all contracts to have embedded in them that any digital purchase must be respected for the life of the purchaser even if the item cannot be purchased any more. It’s not hard, it’s just the price of doing business.

All of this is likely the result of the studios being the dicks they truly are and still being used to pushing everyone around (and of course the tech world being narcissistic liars).

Sounds pretty conclusive to me. Thanks for going the extra mile on that!!

Oh yea it was a silly statement about Python.

FWIW, my understanding is that Mamba came out of Oliphant’s new outfit started after he left anaconda.

From the little I saw (and zero Rust, or Tokio (I think they use that) knowledge) … federation workers weren’t persisting correctly whenever it would hit certain errors or problems.

Huh. I wasn’t aware that a full separation had occurred. Is this new-ish? I recall Travis Oliphant in his Lex Friedman interview saying he thought Anaconda (which he’d left by that point) needed to build more of a community around conda. So maybe this was done after then? Still, I have wonder how closely knit the whole thing is with anaconda the company.

Otherwise, yes, Anaconda is bloat. And Hear Hear for Mamba. I told a Pythonista about it a while ago, explained that it’s written in C++ to fix condo’s performance issues. And they got a little upset that it was against the point/“dream” of doing everything in Python. I was quite curt and pointed out that everyone loved using mamba and that Python people should have cared more about there performance critiques.

Dunno really. I’ve seen P Wang post on BlueSky and there seems to be a strong “touch grass and get off of social media” message in a few of his posts, so I’d say Musk kinda burnt him out on the promises of social media (which he has always been positive on AFAICT) by creating too much cognitive dissonance.

My bet would be he let anaconda people decide from themselves where their social media presence is.

So that’s interesting. From memory, Peter Wang, Anaconda co-founder and CEO, was pretty pro-musk about Twitter in the early days of the migration, was always more of a BlueSky person and to this day doesn’t have a personal presence on masto.

So I’d have to guess something has passed his own threshold or this came from wider company many of whom may have been on the fediverse already.

It was only 0.19.0 instances, it affected outgoing federation only it seems, and it only started happening after a certain amount of time, basically when an error occurred the process would stop.

So it seems reasonable that it didn’t cause mass breakdown of the network.

The cost isn’t the software, it’s the time, energy and risk involved in using it.

The combativeness was deployed to fight off combativeness.

It doesn’t help that Mastodon has very little design considerations for dealing with popular accounts, treating every account as if you’re only following your friends and family. (Emphasis mine)

Came to the same realisation myself. The whole “just friends having lunch together” vibe that mastodon aims for simply breaks down at a certain scale, which means is essentially unsuitable as a Twitter replacement for all that looking for that.

The lack of any feed/notifications management then means that you get subjected to all the annoying randos as though they are your friends or neighbours.

Which, coupled with a culture of purism and gatekeeping and HOA-ing leads to what can be a genuinely toxic culture. Not for everyone all the time but enough of the time for some to have found it awful and left.

But not enough talk about this. It’s designed as a suburban social media where you chat to friends and neighbours. Push it beyond that and you’ll have problems.

When I can I try to bring up the idea of “pro bono” developer work with employed developers I know.

Outside of FAANG it garners confused looks because it’s so alien. But the argument never gets any logical pushback because the industry is culturally sick on this issue:

“ Do you use and rely on open source software?

If so some percentage of what your employer gains from that should be provided back, not out of some morality but to keep afloat the open source software ecosystem you and your employer are benefiting from.

What’s more, you and employer will gain more expertise in said software and can even ensure it is more reliable for your purposes.

All employers of developers using open source ought to dedicate a certain number of developer-days per month to open source maintenance and proudly make this number public.

Also, this idea isn’t new, lawyers have been doing this for decades. See this info graphic from a major Australian Law Firm showing off how 1/24th of their work is pro bono.

That’s right, the sharks might be better people for society than your industry is for itself. “

Ummm … fuck yes that’s awesome!!