A little bit of neuroscience and a little bit of computing
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 not too hard. There are a bunch of different platforms one might experiment with as well as instances. Some will use multiple accounts for different needs or interests. On lemmy, multi accounts are useful for have different feeds, for example. I probably have 7-10. I’ve probably forgotten about a few of them. If you’re curious, it happens.
By the same token Evan seems a bit self centred and egotistical about his projects. Of you look at his comments about BlueSky it seems he’s pretty bitter that someone dared to make an alternative protocol that so far has a decent amount of users, when a acceptance of multiple systems experimenting and borrowing from each other for the good of the open web is right there as a natural position.
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.
Suspicion is totally fair re BlueSky IMO. The system they’ve design seems to me (and others AFAICT) to have the potential to include interconnected components or sections with various degrees of independence.
The elephant in the room, which I point out on BlueSky whenever I can, is that no one seems to really be trying to build the hard parts of that out. Which is a shame because it could be interesting.
EG, there’s a chance that a hybridised system running both BlueSky’s protocol and the fediverse’s could be viable and quite useful. Add to that the integration with some E2EE, and it finally feels like an actual attempt at building something new for the modern internet.
Fortunately there is some noise around these ideas, so hopefully their system can outlast their finances. But yea, a rug pull is definitely not out of the question.
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)
Funny to only ask/report on Zendaya if she’d come back after Messiah.
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.
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.
If there is a platform that does it better, I bet people will start to notice.
Yea … I suspect it’s a protocol problem more than any one platform, because there’s just too much flexibility in the protocol and so any inter-platform transfer is necessarily noisy. Multiplied by the number of platforms, and you get quite a bit of noise.
To your point though, a new platform that kinda does it all on its own could likely take off quite well and then set a new de facto standard around how to do things. Bonfire seemed to be that, and may still be. AFAIU, they’re trying to solve performance issues right now before properly opening up.
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.
Definitely interesting idea (I hadn’t really quite seen it formalised like this)! I’ve kinda had vague similar-ish thoughts along these lines too.
Any chance you’d be willing to go into any more detail, or point to specifics? I’m not familiar with what’s going on over on bestiver or programming.dev in the way of service-type things.
Just feels like every attempt at alternative social media is dying as the internet shrinks to a few corporate websites that control everything.
Yea … it’s sort of a lens for me as I view/critique the actions and decisions of people building alt-social … this stuff is hard and fragile but also important … so not fucking around with it kinda matters (to me at least).
The hate toward BlueSky from mastodon/AP people, for example, is misguided I think. The, IMO, general lack of concern for inter-platform interop across the fediverse bothers me too, where I ask whether a platform is being a good “fediverse citizen”. And some of the “cultural purity through vigilance” culture out of the mastodon/microblogging crowd is, IMO, short sighted.
A common thread being a readiness for negative behaviour and effects rather than building and supporting.
As in a new one would be necessary to do the sorts of things I’m suggesting … or the current moment requires a sort of rebranding and pivot that is best served by a new platform?
In general, this is true of the broader population as a whole. Mastodon got the size that it’s an actual place (and I think this applies to lemmy/threadiverse too). But it’s by no means “THE place” or even categorically a big public place. More like old-school forums that have a particular user base and vibe that you visit from time to time.
For the fediverse, the “migration” was exciting and successful, but compared to big-social, a drop in the ocean. And the biggest clue for that is that the people most excited about Threads joining the fediverse are Evan (author and lead “advocate” of ActivityPub) and Gargron (masto CEO/founder) … they want to taste that big-social scale and know that they don’t have it and likely never will.
I don’t think this is true, maybe not at all.
Academia, by its nature, is socially exclusionary. So what they want/need is the ability to have flexibly closed spaces as well as very public spaces. Big-social never really provided that and in many ways I think academia is being kinda left behind by social media.
Reality for mastodon, I think, is that the “migration” is basically over, and has been for over a year now. The Brazilian move to BlueSky (and not mastodon) highlights it very well.
Recalibrating on what we want and can do with the fediverse, as well as how central we want the mastodon project to be, are the best things to do now.
For me, it seemed like Gargron didn’t really know how to speak about the lack of a Brazilian migration to mastodon in favour of BlueSky, and handle a new moment of actually dropping in popularity or perceived relevance (having been the underdog then rising start for a while), which I take as a cue that being the dominant center of the fediverse isn’t a natural fit for Gargron and his project, to the point where the fediverse may have just outgrown it.
So, random thoughts:
As for the threadiverse (lemmy, piefed, mbin, nodebb etc), it’s always struck me that group based structures (EG, lemmy communities) seem to work better over federation. Account migration from instance to instance is simpler, in part because the user is not the central organisation. Which instance you’re on doesn’t really matter that much. Also, blocking a whole community seems a useful middle ground between blocking a user and defederating a whole instance at the instance level, and ditto with community level moderation which can operate over federation. Additionally, the little technical talk I’ve seen on the issue seems to indicate that moving a community from instance to another might actually be quite viable.
If true, then community building might be best started with the group based platforms. Maybe an ecosystem of formats that involves all of them other than microblogging might work well?? Perhaps user-based content could take on a different structure from what microblogging does … perhaps something like what BlueSky does could be adapted to fuse user-based structures into group-based platforms like lemmy (IE, your content exists in a pod which you can own and which is portable, which is then sucked up into various public feeds depending on what permissions you provide)??
Things like private communities, group chats, blogs, wikis (and RSS feed management?) intuitively seem to me to pair well with group-based platforms and community building.
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.
Just to add to the many responses here with a simple quip on this issue (which I’m taking from one else)
IE: it’s about the socialising “stupid”.
Even for us techy types happy with the system here … it means we get to socialise with like minded people. The independence we have here is often secondary, I’d wager, to what we all get out of this.