There was an article by Google about the security of their code base, and one of their core findings was that old code is good, as it gets refined and more free of bugs over time. And of course conversely, new code is worse.

https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

Generally it seems like capitalism’s obsession with growth is at odds with complex software. It’s basis in property also.

it’s the sort of tool that is really just fundamental now and should be ubiquitous and promoted and taught and talked about every where there is knowledge work. Even more so as there’s a great open source version of the tool.

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.

Cheers! Very much appreciate the love!

Cheers! Actually not sure exactly why you’re saying this (I’ll take the good vibes though) … but if you’re keen to join in in any way you are most welcome!

Cheers for the shout out! Yea the idea of that community is to be a kind of study group.

Whenever I’ve posted a thought or idea, that’s part question part experiment part pondering, I’ve gotten great replies from others.

Also two people have been running twitch streams of running through the book. Sorrybook is nearly done I think (they’ve been going for half a year now which is quite impressive).

The community is at a point now I suspect where some of us have learnt rust well enough to spread out into projects etc, so it’d be nice to work out how we can do that together at all.

Part of my initial idea with the community was to then have a study group for working through the lemmy codebase, treating it as a helpfully relevant learning opportunity … as we’re all using it, we all probably have features we’d like to add, and the devs and users of it are all right here for feedback.

Additionally, an idea I’ve been mulling over, one which I’d be interested in feedback on … is running further “learning rust” sessions where some of us, including those of us who’ve just “learned” it, actually try to help teach it to new comers.

Having a foundation of material such as “The Book” would make a lot of sense. Where “local teachers” could contribute I think is in posting their own thoughts and perspectives on what is important to take away, what additional ideas, structures or broader connections are worth remembering, and even coming up with little exercises that “learners” could go through and then get feedback on from the “teachers”.

I mean, maybe a hot take, maybe not … casual/social voice conversations at a distance were never a good idea in the first place.

Not absolutely at least. A disconnected voice that can summon your attention at any time wherever you are is a weird, uncomfortable, unpleasant and maybe unhealthy thing.

Textual communication at a distance odd much more natural, as it matches the disconnected communication with a more formal and abstract medium.

But remote development is a killer feature to me and they seem to be prioritizing it.

Which is definitely interesting and cool. (Also, before this AI “moment”, their main selling point, along with taking graphics more seriously, and rust I suppose).

Scaled all the way! I use my subscribed list (All is too much randomness.

Occasionally top 6 or 12 hours to catch up.

And occasionally All New/hot/scaled to see random new shit.

On the friends thing, doesn’t it make you wonder sometimes if they ever grew out of it or are out here acting as agents of chaos in ways we might feel but do not know =P!? Cheers!

All the time.

Hunter S Thompson once said “in a world of thieves the only final sin is getting caught”

Cheers! Yea things are all good. The way bikes are stolen is crazy though. I’ve known otherwise reasonable people that honestly believed any bike they found that was not locked was free game. Not friends with them anymore.

Yep. Fucking hate thieves

Pushbike stolen … Many times. Once was kinda my fault for leaving it out, but every other time it was some cunt working hard to get a push bike. Every time I only found out just when I was going to the bike to go some where. One time, the bike was in a secure garage with two gates and the fucker secretly tail gated a car on foot to get in and then waited for another car to leave to tailgate them.

Motorbike stolen … it was a cheap and nasty one but still

Apartment broken into … 18th birthday present fancy watch stolen along gaming console

I don’t think this is correct.

The bit you’re getting confused by, I think, is that some generations are just bigger than others. The boomers were by their name sake a big generation. Millennials are essentially boomers’ kids … and so they’re bigger than both Gen X and Gen Z.

• Most “generational” definitions span about 15 years, sometimes more. EG, Boomers: 1946-1960
• There are sensibly defined micro-generations typically at the borders between generations.
  • EG, “Jones Generation”: 1960-1965 … “young boomers” … they had a distinct life experience from “core boomers” not too different from that of X-Gens. Vietnam and 60s happened while they were children, Reagan was their 20s, not 40s, etc.
• Xennials are notable here because they’re the transition between X-Gen and Millennials (late 70s to early 80s) … probably what you’re thinking of as “older millennials”. What’s interesting though is that the relevance of Xennials is that technological changes mark the generation … they’re essentially just barely young enough to count as part of the internet generations but not old young enough to be ignorant of the pre-internet times. Which just highlights that how you talk about generations depends on what you more broadly care about. In the west, arguably not too much political upheaval has occurred since WWII and its immediate consequences (basically Boomer things) … and so the generations are distinguished on smaller and probably more technological scales.

Cheers!

I think that immunity for explicitly delineated powers makes sense purely from a logical point of view: the constitution says the president can do a thing, therefore a law saying they can’t do that thing is either unconstitutional, or doesn’t apply to the president.

Yea, it’s an interesting one. AFAIU, the delineated powers are basically command of the military and the power to pardon. I really don’t see how a Crime can generally be applicable to either of those. It’s not like “commanding the army” can just become a crime.

But regulating what the army can legally do … seems like a very natural thing. I don’t know if individuals of the military in the US can be responsible under ordinary law for anything. If so, then I don’t see why that would extend to the president should they order something that’s obviously a crime. If not, then that’s that. And again, there are probably natural exceptions to carve out regarding the very nature of military action that would lead to preposterous inconsistencies if they could possible be made generally criminal … where again, it seems to me that you don’t need immunity … it’s just the nature of the power that is amenable to falling within the meaning of legislative regulation.

Beyond all of that though … there’s the opening line of Article II:

The executive Power shall be vested in a President of the United States of America

WTF is “the executive power”?! I’m sure there have been attempts in the US to give it some shape … but I’d also wager it’s been left somewhat nebulous too, involving elements quite distinct from whatever powers Congress/Law can confer. Does that count as an enumerated power?

Otherwise … yea I’m with you. The “official acts” thing seems more than wonky to me … seems downright expansive. Excluding military action and whatever “fuzzy” powers may be considered intrinsic … I’d imagine most of the executive’s powers come from legislative laws. So the body conferring power can’t constrain it to “not doing something criminal”!!!

I’ve wondered since having a brief look at the decision that the SCOTUS is playing a game here … where they do not want Trump’s trials to affect the election and are hoping to clarify this decision and what “official” means at a later date after the election.