[jbergstroem]

I think this position is also one of the reasons it gained attention. Batteries included is a popular and chosen route for many.

Setting up typescript can be hard. Same goes for webpack, s3, postgres, jest and more. I also find the simplified file and stream access quite interesting.

Lets wait and see how a distributed deployment provider turns out.

[homebrewer]

Which means they did not learn from Python's mistakes. You need to look further than the next couple of years. For some reason during the past 10 years or so it has become fashionable to throw away everything the industry has learned in decades prior and start anew, repeating the same mistakes. We'll never turn into proper engineering with such attitude.

https://lwn.net/Articles/776239

https://lwn.net/Articles/888043

https://lwn.net/Articles/790677

[libwithttl]

This doesn't seem like a mistake other than how it is the obvious lead to the scope creep, maintenance creep pipeline. Python having an highly capable standard lib is exactly why some people love it, specially "10 years ago" when it was very slow to rev up your machines that need to be very much isolated from other machines, and you just had to have a bright enough person on systems making sure everything was included from the get go. Python saved the ass of more than 0 people reading this discussion right now on that merit alone.

I think there's a simple solution to all this. Libraries targeting third party protocols get an expiration date and have to forcefully be replaced by name after a given number of versions. Even if they keep the same underlying code, still change the name to force developers to look up its usage and legacy. How many versions? However many equates to the threshold you use to call most systems "legacy". I don't mind some job security and some timebomb punishment aimed at dinosaurs. I have bigger and more consistent issues with that than with weter or not C++ let's me crack a .rar without extra libs.

[flohofwoe]

The opinionated batteries-included stdlib was exactly what made Python popular in the first place though (and even despite its 'weird' syntax). And tbh, most of the current problems were also only added in the Python 3.x era (e.g. 3.x looks very much like a 'second system' - https://en.wikipedia.org/wiki/Second-system_effect)

[spiffytech]

> during the past 10 years or so it has become fashionable to throw away everything the industry has learned in decades prior and start anew

This is a curious take to me. I've spent the last 10 years seeing people claim again and again that if JS just had common stuff built in like <other lang>, we wouldn't have all this library churn, node_modules bloat, and left-pad silliness. That the mistake was not including a standard library.

[Rucadi]

Python's "mistakes" are my weapons in my restricted corporate production system.

[poulpy123]

Batterie-included is one of the main things that made python great and useful before it became big enough to not need it (don't know for bun).

[pjmlp]

Batteries included mean wherever there is a fully compliant implementation, there is something available, even if it isn't the best solution in the galaxy.

Whereas the best solution in the galaxy might only work in a few selected planets, in other ecosystems without batteries.

I prefer batteries included, and not having a culture with a function per package.

[ubercore]

As most things do, it cuts both ways. Rust suffers from their very slow adoption of libraries into a standard library, imo.

[recursivedoubts]

"mistakes"

https://www.tiobe.com/tiobe-index/

[nindalf]

I think their move away from a binary lock file to a text based lock file in this release makes this pretty clear - they shoot first and ask questions later. Any of those problems they've identified with the binary lock file are kinda obvious if you think about it for a bit. A strong indicator that you should think about it is that the popular languages with package managers (npm, ruby, rust) have text based lock files. The fact that the bun team didn't think about it and thought that binary was better because it was faster and no one had thought of this idea feels like hubris to me.

It's cool that they're doing the mainstream thing now, but it's something for them to think about.

[e3bc54b2]

I despise Python's tooling and never touch it willingly.

That said, Python's 'mistake' also made it one of the most used languages ever. For nearly 2 decades, you could just type `python` in terminal and get rolling, and that was invaluable.

The only real 'mistake' that Python did was breaking backwards compatibility so spectacularly that single greatest feature was rendered useless.

[synergy20]

golang is also battery included which seems great. i hope lua can have something similar though smaller

[viraptor]

> Setting up typescript can be hard.

Node just enabled it by default. You still need the dev dependency for manual compilation and checks, but at runtime it should "just work". https://nodejs.org/en/blog/release/v23.6.0

[Shacklz]

As enthusiastic as I am about node's typescript-support, calling it "just works" is a bit of a stretch. Not entirely sure if it's still the case anymore on the latest versions but last I checked it was required to use `.ts`-suffixes for all the imports, something a standard typescript project will hardly ever have and needs to be specifically configured to be considered valid syntax (allowImportingTsExtensions:true).

But yeah, there's progress, and once this gets solid traction (which I'm sure it will) it might finally be the last drop in the bucket to convince TC39 to stop being so antagonistic to having some notion of type-support directly in Javascript.

[re-thc]

> but at runtime it should "just work"

Maybe when it doesn't use WASM and there's proper integration. Otherwise it's just like npm and people still need to look for alternatives.

[nsonha]

nothing wrong with that, but why putting it on a global object instead of a built-in module. Better yet, that module may be publishable on jsr/npm