11 ms·

Idk.. the alternative seems like a Python 3 nightmare. People start depending on things and then you’re faced with two choices: (1) break lots of people, (2) ho

Idk.. the alternative seems like a Python 3 nightmare. People start depending on things and then you’re faced with two choices: (1) break lots of people, (2) hold on to every bit of ugly broken legacy stuff in the name of backwards compat. At this point, I feel like the entire solution space has been explored between all the different languages and there is not a great solution from any of them. Personally, I’m much happier with Go breaking things than becoming a C/C++ hole of legacy going back like 50+ years. On the timing and speed (only one version warning before removal): we can debate the right speed until the cows come home. But, Python 3 took longer than a decade to kill Python 2 as they were trying to give people “plenty of time”. In the end (IMHO), people don’t change unless they’re aggressively forced to because there is always something better to do with your time than upgrade software to prevent some possible future hypothetical breakage. That calculus changes when it’s not hypothetical at all.

ryandvm 5y ago
Agreed. Python 3 and IPv6 are case studies in how not to do an upgrade. While I can appreciate the care and engineering skill involved in upgrading a technology while still having backward compatibility, it turns out just to enable the worst possible behavior on the consumer end. I think I like Apple's way of just forcing breaking changes down everyone's throats (e.g. removing CD/DVD, PowerPC->x86, 30-pin->Lightning, dropping headphone port, etc.). Sure the tech media complain for a cycle, but then everybody adapts and the world's a better place.
- XorNot 5y ago
  There was literally no choice when it came to IPv6. Everyone who thinks they've got a clever compromise is forgetting that it's not a software problem where it matters.
  - drran 5y ago
    Embrace Extend Extinguish I vote for IPv5 protocol, which will allow to cal any IPv4 host via IPv5-IPv4 NAT transparently at nearest bridge. WHY I cannot do `ping6 127.0.0.1`? WTF? Is IPv6 is too small for whole IPv4 address space?
    - tialaramex 5y ago
      You've listed a command line you'd like to run, but have you spent any time to decide what it is that you think it should actually mean? Maybe you think it should just be exactly equivalent to ping6 ::1 - your ping6 could be updated to allow this but, like, why? That's not an improvement at all. OK, so maybe it should be equivalent to ::127.0.0.1 - but that's very strange, an operating system could choose to have this do what you expect locally but it's not clear to what end and again it doesn't offer any wider improvement. IPv6 is big enough that it contains the entire IPv4 address space - in several different places in fact although ::a.b.c.d is the most transparent. But, that's completely irrelevant to the problem, which I suspect means you still haven't quite grasped what the problem even is.
      - slownews45 5y ago
        You're wrong here. Folks actually deploying wanted better co-existence options for folks on IPv6, and it's shown up. You basically route ipv6 as IPv6 until you hit a network border that doesn't support IPv6, then go over to IPv4 for the rest. This let's me do IPv6 only devices without giving up IPv4. As it is, they locked the upgrade cycle, because you can't do IPv6 only without losing access to IPv4 (historically). In the end folks did get work arounds going using 464XLAT https://datatracker.ietf.org/doc/html/rfc6877 https://datatracker.ietf.org/doc/html/rfc6877
      - drran 5y ago
        I expected (20+ years ago), that IPv6 address space will be extension of IPv4 address space, so `ping6 IPv4_ADRESS` will use IPv4 protocol internally, bind6(IPv4_ADDRESS, IPv4_PORT) will use IPv4 socket internally, and so on. It's easy to implement: an_ipv6_function(address) { if (address & 0xffffffffffff0000 == 0) { // Use legacy ipv4 protocol ... } else { // Use modern ipv6 protocol ... } } Actual result: I cannot ping an ipv4 address using an ipv6 tool, or connect to an ipv4 server using an ipv6 only tool.
        cesarb 5y ago
        That already exists, it's called an "IPv4-mapped address". The IPv4 address 198.51.100.15 can be represented in IPv6 as ::ffff:c633:640f (normally shown as ::ffff:198.51.100.15). See in particular at https://man7.org/linux/man-pages/man7/ipv6.7.html https://man7.org/linux/man-pages/man7/ipv6.7.html the IPV6_V6ONLY option which can be used to disable that mapping.
  - tialaramex 5y ago
    Right. The specific problem is that 2^32 isn't enough. The most naive "solutions" were from people who hadn't even recognised why it's 2^32. For example, let's just have numbers bigger than 255 between the dots ... why can't we do that? But once you get past those, another layer of "solutions" see the immediate technical consequences of 2^32 not being enough but don't grok the bigger picture. For example let's just turn existing 32-bit IP addresses into a 64-bit IPng address by adding zeroes, and then all the old addresses are now networks with up to 4 billion nodes. But wait, all those addresses are assigned too now, so we still have an address shortage. Oops. The least stupid people saw the new address scheme itself as logical but just felt like surely IPv6 should have resisted the urge to fix anything else. Sure, you're embarking on a multi-decade project that likely cannot ever be repeated, but let's just leave all the sharp edges and weird anomalies exactly as they are to minimise upgrade costs. This belief is less stupid, but it is still pretty stupid, that cost difference is a drop in the bucket, and this was our only chance to fix some pretty huge mistakes made when the Internet was newborn. It would actually be cheaper for a lot of big outfits to go IPv6-only today (and then use edge translators) than drag their heels and try to stay on IPv4 as long as possible, but contrary to popular belief almost nobody really does "cost-benefit analysis" to decide what to do - they make a decision based on emotion and any such analysis is purely there to support that decision. Buying more addresses is a budget line item you can see, but a lot of big IPv4 costs are hidden in existing practices that "always" have cost money but would vanish under IPv6, and some IPv6 costs are only there if you did no preparation. If you just count the need to replace those IPv4-only printer-copiers you purchased a year ago across the company, and forget that you intentionally chose not to ask bidders if they were IPv6 capable you're going to persuade yourself that it's cheaper to keep waiting.
  - toast0 5y ago
    IPv6 could have been a straight forward expansion of the address field without replacing ARP (which could easily have been extended for v6 addresses, just need to define an address type value) and header processing and address autoconfig and X and Y and Z. It still would have taken a long time to deploy, because you still need hardware and software support in lots of places, but it might have been a little less long, and a little less bad along the way. I don't think we got much of use from the new ways either. I can announce IPv6 ranges to my LAN from two different ISPs, but my clients will use an IP from one and send to the gateway from the other, so that doesn't help me.
    - tialaramex 5y ago
      ARP is a broadcast protocol, so that's pretty bad news, whereas IPv6 Neighbour Discovery gets to use (link local) multicast. On the cheapest budget cobbled together network, either one turns into a network broadcast. But even a bargain basement 1990s Ethernet chipset does onboard multicast filtering, so irrelevant neighbour discovery packets needn't wake up your OS whereas every ARP query must be drawn to the attention of every host's OS to confirm it's not for them. However, spend a little more money and the network switch understands multicast, so now the data isn't even sent across links which don't have anybody listening to that address, whereas of course nothing can be done about broadcasts. You couldn't have easily done this trick in IPv4 because the address space is too small, but in IPv6 choosing the Ethernet multicast addresses to make this work falls out very easily.
- kungito 5y ago
  I feel like Apple's way of forcing is because you cannot buy new Apple products with old features. In software you can keep using the old version and complain about the new one. This problem is especially visible in poorly designed ecosystems like Go and Python. Do you think introducing generics to a language like Go won't cause a great divide in the community? Sure, it won't be a breaking change but it will still divide people into the "old way" and "new way" camps. I guess the language which changed the most along the years without breaking things is C# but then again .NET actually introduced a lot of breaking changes unrelated to the C# language.
  - pjmlp 5y ago
    Bad example actually. Lots of us on Windows are still stuck with .NET Framework, because no matter how Microsoft keeps pushing it, even their own products aren't fully ported to Core, let alone 3rd parties.
    - kungito 5y ago
      That's what I said as well. C# good, .NET bad
      - pjmlp 5y ago
        One doesn't go without the other.
- jacquesm 5y ago
  Ah, and don't forget FireWire.
- ajsnigrutin 5y ago
  IPv6 is great... the only problem is, that IPv4 has be patched enough with workarounds, to make IPv6 unecessary for most "normal users", and there is nothing to sell there. Yes, a simple voice call might use STUN, through two nats, fail to puncture a hole, and then be proxied over a server somewhere, but "it works". Noone is willing to may 1$/€ more per month to get IPv6, noone really needs it, half of IoT doesn't support it (ahem, esp8266/32), it's costly to implement and costly to educate users (especially those, relying on nat for "security"). Most of the IPv6 progress is because the governments mandate it for many stuff, big cloud providers are running out of addresses to buy, vendors want to sell new routers and switches... basically, everybody except the users.
vbezhenar 5y ago
In my opinion it's quite simple. Upgrade cycle should be one major version per year (may be less, but not more). N+1 version does not break compatibility with N version, but introduces warnings for things that's going to be removed. Every warning must have very easy and clear way to resolve it, ideally automatic way, if language and tools support it. Developer must not redesign his application to get rid of warning, but rather just make few obvious mechanical moves. N+2 version removes previously deprecated things and breaks compatibility with N version. So you're going to spend few hours once a year to migrate to newer dependency and resolve their warnings. If your software was rotting for 10 years, you're going to spend a week to gradually upgrade, resolve warnings, etc. That should be acceptable to everyone. And those who prefer to live in rot, should pay someone to maintain those outdated libraries (or just live with bugs and vulnerabilities, that's their choice). With programming languages and foundational frameworks it might be worth to be a little bit more conservative and extend that deprecation period to a few years. Just don't keep deprecated things infinitely.
- lugged 5y ago
  > That should be acceptable to everyone. I used to build things with frameworks and languages with yearly upkeep requirements. > And those who prefer to live in rot, What rot? If my application didn't change I'm not sure why my dependencies should need to. Regarding golang, I hated go get and the go workspace idea when I first started with go. Then I got over it, now I try to use modules and I just get annoyed, the whole system is confusing and flaky. All this change is doing is pushing me further into rust. It has problems too but they tend not to do this kind of hand wringing.
  - Thaxll 5y ago
    The change does not affect either the Go language or the way that you compile the code or fetch dependencies, what's the problem? Go is much more stable than Rust, you know how many Rust libs need nighlty to work?
    - stouset 5y ago
pcx 5y ago
This exaggeration of Python3 migration is ridiculous and frankly has become boring. Yes, Python 3 broke compatibility. But we had more than a decade to migrate. It definitely does not deserve to be the poster child for migrations gone wrong.
- whatshisface 5y ago
  The python language developers did not do it wrong. The community of python users, which include companies with ten year old unmaintained scripts, did not want it invest to transition until the absolute last second. The "Apple Solution" is to make the last second the first second. Who knows if that's the right thing to do.
  - fnord123 5y ago
    The python language developers absolutely did do it wrong. You could not run mixed python2 and python3 code. Either all your dependencies were migrated and you could flip the switch and try things out, or some stragglers kept you running code with compatibilities for 2 and 3 while you waited. And if one of your dependencies started using new features from 3.x it would break everyone stuck on 2.7, so you can't even use the new features in your library. So why would you bother migrating? So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment.
    - ric2b 5y ago
      > So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment. Clearly not, as most libraries are now Python 3 only, so the switch did happen. I do see a lot of people complaining but I see no practical solutions being suggested. "Just don't do a breaking change" isn't a practical solution when the problem being fixed was such a core feature of every language, strings.
      - fnord123 5y ago
jonnytran 5y ago
This tells me that you've never used a well-managed language or framework. Those aren't the only two options. Ruby 1.9 was released around the same time as Python 3, with a similar amount of large breaking changes, and no one was holding on to Ruby 1.8 the way the Python community held on to Python 2.7. You could keep using it if you wanted to, but no one did. Ember.js is another example that I've used that was refreshingly well-managed, with a clear (oftentimes automated) upgrade path between minor releases. Using semver and LTS versions, it didn't just break backward compatibility without a significant deprecation period. Those are just a few examples off the top of my head, but I'm sure other good examples exist. When things are well-managed, you as a developer have the freedom to upgrade when it's a good time for you. When you have production software with real users or a business that depends on it, you can't always just drop whatever you're doing to upgrade, which is why backward compatibility is needed. If it's done right, there's a self-imposed drive to want to move to the latest with all its improvements. On the other hand, with Python 3, they took away things that people cared about, leaving developers not only with no drive to upgrade, but an irrational impetus to hold on to what they had, even when the situation was fixed at a technical level.
dwheeler 5y ago
> But, Python 3 took longer than a decade to kill Python 2 as they were trying to give people “plenty of time”. I disagree, I think you're learning exactly the wrong lesson from the Python3 debacle. It took a long time for Python 2->3 because the Python3 developers ignored the need for easy backwards compatibility, just like the Go developers are doing. Python3 required all software, including all your transitive dependencies, to be simultaneously updated. Python3 was dead-on-arrival for many years until there were finally concessions made in Python3 to make backwards compatibility less painful (in this case, so that code could more easily be written to work in both Python2 and Python3). If the go developers want people to use "install" instead of "get", sure! But give time so that the change can be distributed across the ecosystem before removing the functionality. There's no hurry.
- barsonme 5y ago
  I mean, the Python2 vs Python3 split was primarily caused by language changes, not tooling. And Go’s 1.x comparability promise is rock solid. It seems difficult to compare the two.
- kortex 5y ago
  Except py3 needed to be a breaking change, because unicode handling. It doesn't matter if the API rearranging was delayed and the only change 2->3 was string/bytes handling, it still would have taken a decade. What's the alternative? Deprecate warning old-style string handling and slowly nudge it out? Great, that's not actually decideable, since you need to know how a str is being used. str are at the very heart of python. This would be a gargantuan task just to write the linter.
  - rst 5y ago
    Ruby made a similar change in character encoding starting at roughly the same time; it's (barely) remembered now as a non-event because they didn't take the "opportunity" to bundle in a bunch of other breaking changes which collectively required much more pervasive dinks to pre-existing code than the encoding issues.
bjt 5y ago
In the language proper, the Go authors have made very clear commitments about backward compatibility. (See https://golang.org/doc/go1compat https://golang.org/doc/go1compat.) What's notable about this situation is seeing that their compatibility commitment extends only to the stuff inside the language, and not to the tooling provided to work with the language.
samuell 5y ago
I tend to agree. I'm one of those developers maintaining a few open source projects on the side and sometimes struggle to keep up with updates to the tooling and best practices. For me, it has caused more confusion than help that the old way of using go get still works, even without any warnings to tell me I should start using the new way. I wanted to upgrade myself to using the latest best practices ASAP, but struggled to learn the proper new way, because all the old ways I do almost automatically still work. As long as the messages about how to do instead are really clear and helpful, I find it should be better to help people move in the right direction as soon as possible.
Egoist 5y ago
To be fair, python way of handling versions is the worst and that even goes to the package maintainers. Especially what happened to python 2 -> python3. I don’t like the logic of no version specified = python 2. I have made the mistake of thinking i have the right python binary only to realize it gives syntax error for being python 2
jacquesm 5y ago
This is an interesting side effect of open source. Companies can not afford to break their customers deployments and so tend to bend over backwards to guarantee backwards compatibility. But in open source that link is much more tenuous and project reputation does not directly translate into monetary value in most cases, especially if there is no commercial model attached to a particular solution. This is made worse by the fact that open source is typically developed with a very early public release to drive adoption, rather than that the first decade or so the solution is battle tested in-house and only released when most of the kinks have been worked out.
- ferdowsi 5y ago
  Any type of backwards compatibility breakage provides a decision point to either decide: * do I put in the work to upgrade all my code so that it works with this new version? * do I jump ship to some other library/language that I've been interested in? In the Python 3 breaking case, it provided good reason for engineers at major enterprises to start building in Go instead of investing in the Python 3 upgrade. Another debacle was Angular being completely backwards incompatible, giving an opportunity for React to gain mindshare.
paulddraper 5y ago
> Python 3 took longer than a decade to kill That was an inevitable conclusion from two facts: 1. Python 2 was EXTREMELY well adopted. Like, Java-level, but even deeper in the stack. 2. Python 3 had fundamental changes. (namely byte/string) The only way for a shorter migration is a change to one of those two facts.
mohaba 5y ago
Go has repeatedly chosen "(1) break lots of people". Not for the language itself, but the tooling around it.

ryandvm 5y ago

Agreed. Python 3 and IPv6 are case studies in how not to do an upgrade. While I can appreciate the care and engineering skill involved in upgrading a technology while still having backward compatibility, it turns out just to enable the worst possible behavior on the consumer end. I think I like Apple's way of just forcing breaking changes down everyone's throats (e.g. removing CD/DVD, PowerPC->x86, 30-pin->Lightning, dropping headphone port, etc.). Sure the tech media complain for a cycle, but then everybody adapts and the world's a better place.

XorNot 5y ago
There was literally no choice when it came to IPv6. Everyone who thinks they've got a clever compromise is forgetting that it's not a software problem where it matters.
- drran 5y ago
  Embrace Extend Extinguish I vote for IPv5 protocol, which will allow to cal any IPv4 host via IPv5-IPv4 NAT transparently at nearest bridge. WHY I cannot do `ping6 127.0.0.1`? WTF? Is IPv6 is too small for whole IPv4 address space?
  - tialaramex 5y ago
    You've listed a command line you'd like to run, but have you spent any time to decide what it is that you think it should actually mean? Maybe you think it should just be exactly equivalent to ping6 ::1 - your ping6 could be updated to allow this but, like, why? That's not an improvement at all. OK, so maybe it should be equivalent to ::127.0.0.1 - but that's very strange, an operating system could choose to have this do what you expect locally but it's not clear to what end and again it doesn't offer any wider improvement. IPv6 is big enough that it contains the entire IPv4 address space - in several different places in fact although ::a.b.c.d is the most transparent. But, that's completely irrelevant to the problem, which I suspect means you still haven't quite grasped what the problem even is.
    - slownews45 5y ago
      You're wrong here. Folks actually deploying wanted better co-existence options for folks on IPv6, and it's shown up. You basically route ipv6 as IPv6 until you hit a network border that doesn't support IPv6, then go over to IPv4 for the rest. This let's me do IPv6 only devices without giving up IPv4. As it is, they locked the upgrade cycle, because you can't do IPv6 only without losing access to IPv4 (historically). In the end folks did get work arounds going using 464XLAT https://datatracker.ietf.org/doc/html/rfc6877 https://datatracker.ietf.org/doc/html/rfc6877
    - drran 5y ago
      I expected (20+ years ago), that IPv6 address space will be extension of IPv4 address space, so `ping6 IPv4_ADRESS` will use IPv4 protocol internally, bind6(IPv4_ADDRESS, IPv4_PORT) will use IPv4 socket internally, and so on. It's easy to implement: an_ipv6_function(address) { if (address & 0xffffffffffff0000 == 0) { // Use legacy ipv4 protocol ... } else { // Use modern ipv6 protocol ... } } Actual result: I cannot ping an ipv4 address using an ipv6 tool, or connect to an ipv4 server using an ipv6 only tool.
      - cesarb 5y ago
        That already exists, it's called an "IPv4-mapped address". The IPv4 address 198.51.100.15 can be represented in IPv6 as ::ffff:c633:640f (normally shown as ::ffff:198.51.100.15). See in particular at https://man7.org/linux/man-pages/man7/ipv6.7.html https://man7.org/linux/man-pages/man7/ipv6.7.html the IPV6_V6ONLY option which can be used to disable that mapping.
- tialaramex 5y ago
  Right. The specific problem is that 2^32 isn't enough. The most naive "solutions" were from people who hadn't even recognised why it's 2^32. For example, let's just have numbers bigger than 255 between the dots ... why can't we do that? But once you get past those, another layer of "solutions" see the immediate technical consequences of 2^32 not being enough but don't grok the bigger picture. For example let's just turn existing 32-bit IP addresses into a 64-bit IPng address by adding zeroes, and then all the old addresses are now networks with up to 4 billion nodes. But wait, all those addresses are assigned too now, so we still have an address shortage. Oops. The least stupid people saw the new address scheme itself as logical but just felt like surely IPv6 should have resisted the urge to fix anything else. Sure, you're embarking on a multi-decade project that likely cannot ever be repeated, but let's just leave all the sharp edges and weird anomalies exactly as they are to minimise upgrade costs. This belief is less stupid, but it is still pretty stupid, that cost difference is a drop in the bucket, and this was our only chance to fix some pretty huge mistakes made when the Internet was newborn. It would actually be cheaper for a lot of big outfits to go IPv6-only today (and then use edge translators) than drag their heels and try to stay on IPv4 as long as possible, but contrary to popular belief almost nobody really does "cost-benefit analysis" to decide what to do - they make a decision based on emotion and any such analysis is purely there to support that decision. Buying more addresses is a budget line item you can see, but a lot of big IPv4 costs are hidden in existing practices that "always" have cost money but would vanish under IPv6, and some IPv6 costs are only there if you did no preparation. If you just count the need to replace those IPv4-only printer-copiers you purchased a year ago across the company, and forget that you intentionally chose not to ask bidders if they were IPv6 capable you're going to persuade yourself that it's cheaper to keep waiting.
- toast0 5y ago
  IPv6 could have been a straight forward expansion of the address field without replacing ARP (which could easily have been extended for v6 addresses, just need to define an address type value) and header processing and address autoconfig and X and Y and Z. It still would have taken a long time to deploy, because you still need hardware and software support in lots of places, but it might have been a little less long, and a little less bad along the way. I don't think we got much of use from the new ways either. I can announce IPv6 ranges to my LAN from two different ISPs, but my clients will use an IP from one and send to the gateway from the other, so that doesn't help me.
  - tialaramex 5y ago
    ARP is a broadcast protocol, so that's pretty bad news, whereas IPv6 Neighbour Discovery gets to use (link local) multicast. On the cheapest budget cobbled together network, either one turns into a network broadcast. But even a bargain basement 1990s Ethernet chipset does onboard multicast filtering, so irrelevant neighbour discovery packets needn't wake up your OS whereas every ARP query must be drawn to the attention of every host's OS to confirm it's not for them. However, spend a little more money and the network switch understands multicast, so now the data isn't even sent across links which don't have anybody listening to that address, whereas of course nothing can be done about broadcasts. You couldn't have easily done this trick in IPv4 because the address space is too small, but in IPv6 choosing the Ethernet multicast addresses to make this work falls out very easily.
kungito 5y ago
I feel like Apple's way of forcing is because you cannot buy new Apple products with old features. In software you can keep using the old version and complain about the new one. This problem is especially visible in poorly designed ecosystems like Go and Python. Do you think introducing generics to a language like Go won't cause a great divide in the community? Sure, it won't be a breaking change but it will still divide people into the "old way" and "new way" camps. I guess the language which changed the most along the years without breaking things is C# but then again .NET actually introduced a lot of breaking changes unrelated to the C# language.
- pjmlp 5y ago
  Bad example actually. Lots of us on Windows are still stuck with .NET Framework, because no matter how Microsoft keeps pushing it, even their own products aren't fully ported to Core, let alone 3rd parties.
  - kungito 5y ago
    That's what I said as well. C# good, .NET bad
    - pjmlp 5y ago
      One doesn't go without the other.
jacquesm 5y ago
Ah, and don't forget FireWire.
ajsnigrutin 5y ago
IPv6 is great... the only problem is, that IPv4 has be patched enough with workarounds, to make IPv6 unecessary for most "normal users", and there is nothing to sell there. Yes, a simple voice call might use STUN, through two nats, fail to puncture a hole, and then be proxied over a server somewhere, but "it works". Noone is willing to may 1$/€ more per month to get IPv6, noone really needs it, half of IoT doesn't support it (ahem, esp8266/32), it's costly to implement and costly to educate users (especially those, relying on nat for "security"). Most of the IPv6 progress is because the governments mandate it for many stuff, big cloud providers are running out of addresses to buy, vendors want to sell new routers and switches... basically, everybody except the users.

vbezhenar 5y ago

In my opinion it's quite simple. Upgrade cycle should be one major version per year (may be less, but not more). N+1 version does not break compatibility with N version, but introduces warnings for things that's going to be removed. Every warning must have very easy and clear way to resolve it, ideally automatic way, if language and tools support it. Developer must not redesign his application to get rid of warning, but rather just make few obvious mechanical moves. N+2 version removes previously deprecated things and breaks compatibility with N version. So you're going to spend few hours once a year to migrate to newer dependency and resolve their warnings. If your software was rotting for 10 years, you're going to spend a week to gradually upgrade, resolve warnings, etc. That should be acceptable to everyone. And those who prefer to live in rot, should pay someone to maintain those outdated libraries (or just live with bugs and vulnerabilities, that's their choice). With programming languages and foundational frameworks it might be worth to be a little bit more conservative and extend that deprecation period to a few years. Just don't keep deprecated things infinitely.

lugged 5y ago
> That should be acceptable to everyone. I used to build things with frameworks and languages with yearly upkeep requirements. > And those who prefer to live in rot, What rot? If my application didn't change I'm not sure why my dependencies should need to. Regarding golang, I hated go get and the go workspace idea when I first started with go. Then I got over it, now I try to use modules and I just get annoyed, the whole system is confusing and flaky. All this change is doing is pushing me further into rust. It has problems too but they tend not to do this kind of hand wringing.
- Thaxll 5y ago
  The change does not affect either the Go language or the way that you compile the code or fetch dependencies, what's the problem? Go is much more stable than Rust, you know how many Rust libs need nighlty to work?
  - stouset 5y ago

pcx 5y ago

This exaggeration of Python3 migration is ridiculous and frankly has become boring. Yes, Python 3 broke compatibility. But we had more than a decade to migrate. It definitely does not deserve to be the poster child for migrations gone wrong.

whatshisface 5y ago
The python language developers did not do it wrong. The community of python users, which include companies with ten year old unmaintained scripts, did not want it invest to transition until the absolute last second. The "Apple Solution" is to make the last second the first second. Who knows if that's the right thing to do.
- fnord123 5y ago
  The python language developers absolutely did do it wrong. You could not run mixed python2 and python3 code. Either all your dependencies were migrated and you could flip the switch and try things out, or some stragglers kept you running code with compatibilities for 2 and 3 while you waited. And if one of your dependencies started using new features from 3.x it would break everyone stuck on 2.7, so you can't even use the new features in your library. So why would you bother migrating? So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment.
  - ric2b 5y ago
    > So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment. Clearly not, as most libraries are now Python 3 only, so the switch did happen. I do see a lot of people complaining but I see no practical solutions being suggested. "Just don't do a breaking change" isn't a practical solution when the problem being fixed was such a core feature of every language, strings.
    - fnord123 5y ago

jonnytran 5y ago

This tells me that you've never used a well-managed language or framework. Those aren't the only two options. Ruby 1.9 was released around the same time as Python 3, with a similar amount of large breaking changes, and no one was holding on to Ruby 1.8 the way the Python community held on to Python 2.7. You could keep using it if you wanted to, but no one did. Ember.js is another example that I've used that was refreshingly well-managed, with a clear (oftentimes automated) upgrade path between minor releases. Using semver and LTS versions, it didn't just break backward compatibility without a significant deprecation period. Those are just a few examples off the top of my head, but I'm sure other good examples exist. When things are well-managed, you as a developer have the freedom to upgrade when it's a good time for you. When you have production software with real users or a business that depends on it, you can't always just drop whatever you're doing to upgrade, which is why backward compatibility is needed. If it's done right, there's a self-imposed drive to want to move to the latest with all its improvements. On the other hand, with Python 3, they took away things that people cared about, leaving developers not only with no drive to upgrade, but an irrational impetus to hold on to what they had, even when the situation was fixed at a technical level.

dwheeler 5y ago

> But, Python 3 took longer than a decade to kill Python 2 as they were trying to give people “plenty of time”. I disagree, I think you're learning exactly the wrong lesson from the Python3 debacle. It took a long time for Python 2->3 because the Python3 developers ignored the need for easy backwards compatibility, just like the Go developers are doing. Python3 required all software, including all your transitive dependencies, to be simultaneously updated. Python3 was dead-on-arrival for many years until there were finally concessions made in Python3 to make backwards compatibility less painful (in this case, so that code could more easily be written to work in both Python2 and Python3). If the go developers want people to use "install" instead of "get", sure! But give time so that the change can be distributed across the ecosystem before removing the functionality. There's no hurry.

barsonme 5y ago
I mean, the Python2 vs Python3 split was primarily caused by language changes, not tooling. And Go’s 1.x comparability promise is rock solid. It seems difficult to compare the two.
kortex 5y ago
Except py3 needed to be a breaking change, because unicode handling. It doesn't matter if the API rearranging was delayed and the only change 2->3 was string/bytes handling, it still would have taken a decade. What's the alternative? Deprecate warning old-style string handling and slowly nudge it out? Great, that's not actually decideable, since you need to know how a str is being used. str are at the very heart of python. This would be a gargantuan task just to write the linter.
- rst 5y ago
  Ruby made a similar change in character encoding starting at roughly the same time; it's (barely) remembered now as a non-event because they didn't take the "opportunity" to bundle in a bunch of other breaking changes which collectively required much more pervasive dinks to pre-existing code than the encoding issues.

bjt 5y ago

In the language proper, the Go authors have made very clear commitments about backward compatibility. (See https://golang.org/doc/go1compat https://golang.org/doc/go1compat.) What's notable about this situation is seeing that their compatibility commitment extends only to the stuff inside the language, and not to the tooling provided to work with the language.

samuell 5y ago

I tend to agree. I'm one of those developers maintaining a few open source projects on the side and sometimes struggle to keep up with updates to the tooling and best practices. For me, it has caused more confusion than help that the old way of using go get still works, even without any warnings to tell me I should start using the new way. I wanted to upgrade myself to using the latest best practices ASAP, but struggled to learn the proper new way, because all the old ways I do almost automatically still work. As long as the messages about how to do instead are really clear and helpful, I find it should be better to help people move in the right direction as soon as possible.

Egoist 5y ago

To be fair, python way of handling versions is the worst and that even goes to the package maintainers. Especially what happened to python 2 -> python3. I don’t like the logic of no version specified = python 2. I have made the mistake of thinking i have the right python binary only to realize it gives syntax error for being python 2

jacquesm 5y ago

This is an interesting side effect of open source. Companies can not afford to break their customers deployments and so tend to bend over backwards to guarantee backwards compatibility. But in open source that link is much more tenuous and project reputation does not directly translate into monetary value in most cases, especially if there is no commercial model attached to a particular solution. This is made worse by the fact that open source is typically developed with a very early public release to drive adoption, rather than that the first decade or so the solution is battle tested in-house and only released when most of the kinks have been worked out.

ferdowsi 5y ago
Any type of backwards compatibility breakage provides a decision point to either decide: * do I put in the work to upgrade all my code so that it works with this new version? * do I jump ship to some other library/language that I've been interested in? In the Python 3 breaking case, it provided good reason for engineers at major enterprises to start building in Go instead of investing in the Python 3 upgrade. Another debacle was Angular being completely backwards incompatible, giving an opportunity for React to gain mindshare.

paulddraper 5y ago

> Python 3 took longer than a decade to kill That was an inevitable conclusion from two facts: 1. Python 2 was EXTREMELY well adopted. Like, Java-level, but even deeper in the stack. 2. Python 3 had fundamental changes. (namely byte/string) The only way for a shorter migration is a change to one of those two facts.

mohaba 5y ago

Go has repeatedly chosen "(1) break lots of people". Not for the language itself, but the tooling around it.