Kinda sad how the industry settled on Python. The performance is not the best and the integration with native languages is far my ideal.
Yesterday I tried to create a Zig library for Bun using bunffi and it was mindblowing how easy it was. You can get pretty much the best of both worlds without obscure bindings. But yeah, both projects are still fairly young.
I use Zig and C with Python regularily and I think the interoperability is excellent. It's one of the coolest part about Python in my opinion, but the ecosystem is a nightmare to navigate. It's easy to use C structs for more efficient "classes" with libraries like msgspec, but chances are you've never heard about msgspec because there are at least 10 other libraries which do something similar, and there is also __slots__.
Even your package and project manager isn't straight forward. With Javascript you're basically going to use either Deno or Bun, but with Python you're going to use what? I'd argue that UV was the only "real" option (come at me!) but like 90% of the Python programmers I work with tend to have never heard about it. Maybe it's just my part of the world, but when you enter a Python shop that does web-api's you're 95% sure to find Flask, FastAPI or ninja-django (might be django-ninja), all of which are ok. The internet is full of recomendations on these, but they are all so underperformant compared to Litestar.
Then you have the actual language design where it is ridiculously easy to shoot yourself in the foot. As an example there is a massive difference in how you can loop over collections with Lists and Generators. It's not that different (in concept) from C# where you have IEnumerable and IQuerable, but it sort of is different in the way that almost every C# developer will know the difference while many Python programmers will never have heard of generators.
Over all though, I think there is a reason Python is everywhere. It's very productive, and it's also very easy to deal with bottlenecks when you run into them. I think the philosophy of designing code to be perfect from the get go is flawed. Partly because you're likely not going to know where bottlenecks will show up, but mainly because 95% (I pulled this out of my ass, but I'd wager it's accurate) of all software will never succeed enough to have scaling issues. Stackoverflow didnt even get CDN's until something like 2018ish, and during it's early days it was just a couple of IIS and SQL servers. Python fits perfectly into this sort of YAGNI philosophy because almost everyone can get things working well enough, and then you can always use actual engineering to deal with performance once you need to. Sure, I tend to write performant and type safe Python from the get go, but in a world of too few software engineers, it's very handy to have non-SWE personal build software which is "good enough". Especially in non-SWE industries, and Python is, the, language every non-SWE programmer uses.
While not rocketscience, a lot of its features requires to know how to recompile the project with passing certain variables. Also you need to properly format prompts for each instructor model.
s3 is pretty much a de-facto standard, just like json like or not. Postgres also makes sense, it is the most widespread and community-liked db. What is the point of "optional libraries" tbh? It was a PITA in PHP back in the days and very inconvenient, prob most devs would prefer this way.
I feel like HN is on cognitive dissonance, they complain JS projects having too many dependencies and they also complain now when things are more integrated into the runtime because it increases vendor-lock and few extra megabytes (actually kilobytes according to the devs) to the binaries :/.
Lastly, big companies also prefer less dependencies, it is not just devs.
It probably looks very wrong to people who still think lots of "modularity" and small packages is a good thing.
I'm all for it, and lots of Bun APIs are purely practical. Bun.stringWidth, for example, exposes code Bun already has internally. Nodejs probably has the same thing, but instead of us being able to use it, it gets reimplemented in 10 different versions in node_modules. How is that better?
I doubt the Bun team will have to change the S3 code very much over the years. The test runner, bundler, Postgres client, sure, I can see those being harder to maintain. But I'm also tired of everyone assuming everything needs to change all of the time. DX aside, my team is still on Webpack and we've only needed one new feature from it in the last ~5 years. Why can't Bun's bundler reach maturity and only receive a few updates?
Node does have the same thing, and you can access it with `--expose-internals` from `const { getStringWidth } = require("internal/util/inspect");`. They don't expose it for some reason.
I'm also still using webpack. Not sure why the community abandoned it. Haven't had any issues. Everything seems to use babel under the hood anyway and they all have their little wrappers over top.
Back in what days of PHP? I've been using PHP and MySQL since... Probably 2003ish and never had a problem. I think you need the extension but most providers had it.
Yesterday I tried to create a Zig library for Bun using bunffi and it was mindblowing how easy it was. You can get pretty much the best of both worlds without obscure bindings. But yeah, both projects are still fairly young.