5 ms·

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

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/776239 https://lwn.net/Articles/888043 https://lwn.net/Articles/888043 https://lwn.net/Articles/790677 https://lwn.net/Articles/790677

deleted 2y ago
[deleted]
e3bc54b2 2y ago
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.
- Yajirobe 2y ago
  > single greatest feature was rendered useless. Which feature are you referring to?
  - e3bc54b2 2y ago
    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-deprecation-policy-is-killing-you-ee7525dc05dc https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
    - otabdeveloper4 2y ago
      > there were real reasons to do all that No there weren't. It's just pure idiocy and incompetence.
      - e3bc54b2 2y ago
        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.
flohofwoe 2y ago
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 https://en.wikipedia.org/wiki/Second-system_effect)
poulpy123 2y ago
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).
Rucadi 2y ago
Python's "mistakes" are my weapons in my restricted corporate production system.
libwithttl 2y ago
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.
ubercore 2y ago
As most things do, it cuts both ways. Rust suffers from their very slow adoption of libraries into a standard library, imo.
spiffytech 2y ago
> 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.
- notnullorvoid 2y ago
  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.
recursivedoubts 2y ago
"mistakes" https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
- Ygg2 2y ago
  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.
pjmlp 2y ago
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.
synergy20 2y ago
golang is also battery included which seems great. i hope lua can have something similar though smaller
nindalf 2y ago
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.
- BackBlast 2y ago
  Or they think extensively about performance. Regardless, the switch shows they pay attention and are willing to change.

deleted 2y ago

[deleted]

e3bc54b2 2y ago

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.

Yajirobe 2y ago
> single greatest feature was rendered useless. Which feature are you referring to?
- e3bc54b2 2y ago
  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-deprecation-policy-is-killing-you-ee7525dc05dc https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
  - otabdeveloper4 2y ago
    > there were real reasons to do all that No there weren't. It's just pure idiocy and incompetence.
    - e3bc54b2 2y ago
      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.

flohofwoe 2y ago

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 https://en.wikipedia.org/wiki/Second-system_effect)

poulpy123 2y ago

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

Rucadi 2y ago

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

libwithttl 2y ago

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.

ubercore 2y ago

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

spiffytech 2y ago

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

notnullorvoid 2y ago
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.

recursivedoubts 2y ago

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

Ygg2 2y ago
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.

pjmlp 2y ago

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.

synergy20 2y ago

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

nindalf 2y ago

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.

BackBlast 2y ago
Or they think extensively about performance. Regardless, the switch shows they pay attention and are willing to change.