Hacker News Reader

Comment by jbergstroem | Hacker News Reader

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.

View on HN

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

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.

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)

> 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.

This is mostly a sentiment I see from people who used or heard of JS 10+ years ago and didn't bother to learn added JS language features and recent tooling.

Standard libs can be great, but they should really be reserved for baseline features, especially in a language like JS where all changes must be backward compatible. The standard JS has now is not at all what it was in the early 2010s, it's a very good set of baseline features.

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

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).

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.

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

"mistakes"

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

A thing can be both a mistake from maintainance perspective, but a great boon from user perspective, or even a horrible kludge from power user perspective.

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.

Or they think extensively about performance.

Regardless, the switch shows they pay attention and are willing to change.

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.

> single greatest feature was rendered useless.

Which feature are you referring to?

being able to type `python` and start writing a program that would work nearly everywhere.

With compatibility break there was a decade of confusion, even the simplest print statement wouldn't work. I understand there were real reasons to do all that, but it did cause damage.

Steve Yegge put it better than I can[0]:

> the thing is, every single developer has choices. And if you make them rewrite their code enough times, some of those other choices are going to start looking mighty appealing. They’re not your hostages, as much as you’d like them to be. They are your guests. Python is still a very popular programming language, to be sure — but golly did Python 3(000) create a huge mess for themselves, their communities, and the users of their communities’ software — one that has been a train-wreck in progress for fifteen years and is still kicking.

> How much Python software was rewritten in Go (or Ruby, or some other alternative) because of that backwards incompatibility? How much new software was written in something other than Python, which might have been written in Python if Guido hadn’t burned everyone’s house down? It’s hard to say, but I can tell you, it hasn’t been good for Python. It’s a huge mess and everyone is miserable.

[0] https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

> there were real reasons to do all that

No there weren't. It's just pure idiocy and incompetence.

Well, I would agree with you. But I'm no language designer nor maintainer. It could all be bollocks, but since I'm the ignorant one, they get benefit of doubt.

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

> 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

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.

> 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.

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

Reply on news.ycombinator.com