"Batteries included" means "ossification is guaranteed", yah. "stdlib is where code goes to die" is a fairly common phrase for a reason.

There's clearly merit to both sides, but personally I think a major underlying cause is that libraries are trusted. Obviously that doesn't match reality. We desperately need a permission system for libraries, it's far harder to sneak stuff in when doing so requires an "adds dangerous permission" change approval.

The goal is not to cover everything, the goal is to cover 90% of the use cases.

For C#, I think they achieved that.

> They are going to be out of date whenever a standard changes (HTML, etc.)

You might want to elaborate on the "etc.", since HTML updates are glacial.

Why would they be out of date? The ecosystems themselves (for example .NET) receives regular updates.

Yes, they cannot include everything, but enough that you do not _need_ third party packages.

Python, .NET, and Java are not examples of batteries included.

Django and Spring

While technically true, it's so much slower that it's essentially a different thing. Third party packages being attacked is a near daily occurrence. First party attacks happens on the timescale and frequency of decades.

It's like the difference in protecting your home from burglars and foreign nation soldiers. Both are technically invaders to your home, but the scope is different, and the solutions are different.

> they just move slower so it’s not as attractive of a target.

Well, there’s other things. Maven doesn’t allow you to declare “version >= x.y.z” and doesn’t run arbitrary scripts upon pulling dependencies, for one thing. The Java classpath doesn’t make it possible to have multiple versions of the same library at the same time. That helps a lot too.

NPM and the way node does dependency management just isn’t great. Never has been.

What type of developer chooses UX and performance over security? So reckless.

I removed the locks from all the doors, now entering/exiting is 87% faster! After removing all the safety equipment, our vehicles have significantly improved in mileage, acceleration and top speed!

requests should be in the Python standard library. Hard choices need to be made.

I'm pretty sure it's really one HTTP library: urllib.request is built on top of http.client. But the very Java-inspired API for the former is awful.

> Unless you are Python, where the standard library includes multiple HTTP libraries and everyone installs the requests package anyways.

The amount of time defining same data structures over and over again vs `pip install requests` with well defined data structures.

    >  Few languages have good models for evolving their standard library

Can you name some examples?

It doesn't matter. We pulled axios out of our codebase, but it still ends up in there as a child or peer from 40 other dependencies. Many from major vendors like datadog, slack, twilio, nx (in the gcs-cache extension), etc...

People use axios or ky because with fetch you inevitably end up writing a small wrapper on top of it anyway.

Node fetch is relatively new. Wasn't marked stable until 2023, though I've used it since like 2018.

I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

It doesn't have a need _now_. Axios is more than 10 years old now, and even before axios other libraries did the same utility of making requests easier

Browsers too.

It’s not needed anymore.

This might make things worse not better.

Yes - the postinstall hook attack vector goes away. You can do SHA pinning since Git's content addressing means that SHA is the hash of the content. But then your "lockfile" equivalent is just... a list of commit SHAs scattered across import statements in your source? Managing that across a real dependency tree becomes a nightmare.

This is basically what Deno's import maps tried to solve, and what they ended up with looked a lot like a package registry again.

At least npm packages have checksums and a registry that can yank things.

> I understand why this doesn't work well with legacy projects, but it's something that the language could strive towards.

Why wouldn't that work well with legacy projects? In fact, the projects I was a part of that I'd call legacy nowadays, was in fact built by copy-and-pasting .js libraries into a "vendor/" directory, and that's how we shipped it as well, this was in the days before Bower (which was the npm of frontend development back in the day), vendoring JS libs was standard practice, before package managers became used in frontend development too.

Not sure why it wouldn't work, JavaScript is a very moldable language, you can make most things work one way or another :)(

it's muddying what a package is. A package, or a distro, is the people who slave and labor over packaging, reviewing, deciding on versions to ship, having policies in place, security mailing lists, release schedules, etc.

just shipping from npm crap is essentially the equivelant of running your production code base against Arch AUR pkgbuilds.

To the extend that Python is indeed "batteries included," that seems true. But just how "batteries included" is it? I'd argue that its batteries are pretty limited. Exhibit A: everybody uses the third-party requests instead of the stdlib urllib. Exhibit B: http.server isn't a production-ready webserver, so people use Flask or something beefier.

I'd contrast Python with Go, which has an amazing stdlib for the domains that Go targets. This last part is key--Go has a more focused scope than Python, and that makes it easier for its stdlib to succeed.

Kinda.

With Bun I use less dependencies from NPM than I used from Nuget with .NET to build minimal apis. For example the pg driver.

Why is .NET more "batteries included" than Java?

With the notable exception of cross-platform audio.

To me, I really like Golang's batteries included platform. I am not sure about .NET though

And now with NativeAOT, you can use C# like go - you don't need to ship the CLR.

I think the AI tooling is, if not completely solving sandboxing, at least making the default much better by asking you every time they want to do something and providing files to auto-approve certain actions.

Package managers should do the same thing

I work in a NIS2 compliance sector, and we basically use Go and Python for everything. Go is awesome, Python isn't as such. Go didn't always come with the awesome stllib that it does today, which is likely partly why a lot of people still use things like Gin for web frameworks rather than simply using the standard library. Having worked with a lot of web frameworks, the one Go comes with is nice and easy enough to extend. Python is terrible, but on the plus side it's relatively easy to write your own libraries with Python, and use C/Zig to do so if you need it. The biggest challenges for us is that we aren't going to write a better MSSQL driver than Microsoft, so we use quite a bit of dependencies from them since we are married with Azure. These live in a little more isolation than what you might expect, so they aren't updated quite as often as many places might. Still, it's a relatively low risk factor that we can accept.

Our React projects are the contrast. They live in total and complete isolation, both in development and in production. You're not going to work on React on a computer that will be connected to any sort of internal resources. We've also had to write a novel's worth of legal bullshit explaining how we can't realistically review every line of code from React dependencies for compliance.

Anyway, I don't think JS/TS is that bad. It has a lot of issues, but then, you could always have written your own wrapper ontop of Node's fetch instead of using Axios. Which I guess is where working in the NIS2 compliance sector makes things a little bit different, because we'd always chose to write the wrapper instead of using one others made. With the few exceptions for Microsoft products that I mentioned earlier.

Go is well known for its large and high quality std lib

These are the big ones I use, specifically because of the standard libraries:

Python (decent standard library) - It's pretty much everywhere. There's so many hidden gems in that standard library (difflib, argparse, shlex, subprocess, cmd)

C#/F# (.NET)

C# feels so productive because of how much is available in .NET Core, and F# gets to tag along and get it all for free too. With C# you can compile executables down to bundle the runtime and strip it down so your executables are in the 15 MiB range. If you have dotnet installed, you can run F# as scripts.

Ah, so you've traded the possibility of bad dependencies for certainty.

Or find the best third party library and copy the code from a widely used version that has been out long enough to have been well tested into your source tree.

The problem is not third party libraries. It is updating third party libraries when the version you have still works fine for your needs.

I agree about the culture. If I take my eye off the dev team for too long, I'll come back and we'll be using entity framework and a 20 page document about configuring code cleanup rules in visual studio.

> When you use a third-party HTTP implementation (for example), you're invariably importing more functionality than you need anyway. If you're just querying a REST service, you don't need MIME encoding, but it's part of the HTTP library anyway because some clients do need it. That library (that imports all of its own libraries) is just unnecessary bloat, and this stuff really isn't that hard to get right.

This post is modded down (I think because of the "roll your own crypto vibe", which I disagree with), but this is actually spot on the money for HTTP.

The surface area for HTTP is quite large, and your little API, which never needed range-requests, basic-auth, multipart form upload, etc suddenly gets owned because of a vulnerability in one of those things you not only never used, you also never knew existed!

"Surface area" is a problem, reducing it is one way to mitigate.

> Even cryptography

Good luck