I'm not close to Gaiman or the fandom or the story, at all ... but I did manage to pickup on some of the whisper network through mastodon, where I read a couple of posts or blog posts by people who seemed to be close to the fandom and even be friends with him (in one case). The vibe was very much he's likely a womanising guy and has been his whole life and likely has standards "below" what most would consider normal. There also seemed to be a bit of introspection about how much the fandom around him was kinda culty and that that clearly enabled whatever he did, as a common enough pattern seemed to be that someone would go through something unseemly, but because it was Gaiman and all their friends were fans, they presumed it was them or their fault and never wanted to open up about it.
Like I said though, this is essentially gossip, so don't take it seriously or anything (also I don't have any links or anything).
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.
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.
Huh. I hadn’t really thought about it before, but it would seem to indicate that size and density are mostly independent parameters of a city.
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.
@maegul
@lemmy.ml