21 ms·

Backward Compatibility, Go 1.21, and Go 2

nadermx 3y ago
Moving some code from python to Golang was instrumental in helping me scale. I am so glad to read they are going to stick to their core statement of backwards compatability
pjmlp 3y ago
Looking forward to Go 1.99999999999999....
deleted 3y ago
[deleted]
dcow 3y ago
> That raises an obvious question: when should we expect the Go 2 specification that breaks old Go 1 programs? > The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened. Why is backwards compatibility such a religious sin for Go? Python made it through a backwards-incompatible source change. I understand breaking backwards compatibility would be difficult on a short timescale, but on a long-term time scale people would migrate. Source rewriters would handle most of the transition. Over 3-5 years I could see a source-breaking change play out positively for some of these newer languages like Go and Rust. And arguably, they sorely need it.
- jimmaswell 3y ago
  Python was a disaster. I still miss print statements and encoding-agnostic strings. Good on Go for doing the right thing.
  - hk__2 3y ago
    Print statements were a mistake. If you forbid breaking changes, you have no way to fix past mistakes in the language design. There’s noting inherently "right" in refusing to do breaking changes.
    - jimmaswell 3y ago
      Removing the print statement was the mistake to me. It violated Python's own stated principle of practicality over purity.
      - rowanseymour 3y ago
        Having two ways to do the same thing is the mistake, and print() was always more consistent with other built in functions are invoked.
      - masklinn 3y ago
        There was nothing practical about the print statement. The print function is easier to use, meshes a lot better with the langage, and can actually be extended without C++ style syntactic nonsense. The print function is one of the best things to come out of p3.
  - dcow 3y ago
    I think if you'd ask any Python programmer today, they'd say Python is very much healthy and the community has successfully transitioned.
    - jimmaswell 3y ago
      Python was my first language and I still use it sometimes. Still run into 2 vs 3 issues often.
  - mrweasel 3y ago
    > encoding-agnostic strings Do you mean byte strings vs. strings in Python 3 or did you actually like string handling in Python 2, because that basically "Tell me that you only allow ASCII without telling me that you only all ASCII". I can see the issue with byte strings in Python3, it's annoying that you have to think about both strings and byte strings, but for dealing with actual text having everything just be unicode was reason enough to upgrade from 2 to 3. We deleted so much code dedicated to dealing with encoding during our switch to Python 3, everything just became better.
    - jimmaswell 3y ago
      I had an IRC markov-like bot in Python. It used to be so simple in Python 2: - the bytes come in from the IRC server - they go in a string in the log, I can print this log to the console even if it has some IRC control codes (there will be a garbage character here or there but that's OK) - if I want to make a bold/color/etc I can just throw \xwhatever in the string. if a word from the log had bold in it and it's repeated back it will also have the bold in it. Then I reluctantly ported it to Python 3 and it was awful. Python now had to micromanage every single string to ensure I don't have any "naughty" bytes in it. Conversions to/from byte/string everywhere. Massive headache every time I wanted to read or write IRC encoded strings to a txt file or print them to the console or anything. In Python 2 the encoding only lived outside the program, in my terminal, text editor, and IRC clients. Bytes went in, bytes went out, and everyone was happy. Python 3 decided it needed to know exactly what was going on every step of the way and didn't trust me anymore, forcing me to do an elaborate song and dance to get anything done. I prefer my tools to have as little an opinion as possible. Let me open the door while I'm driving, let me run my web browser as root, and let me print \xDE\xAD\xBE\xEF to the console.
      - mrweasel 3y ago
        > Python now had to micromanage every single string to ensure I don't have any "naughty" bytes in it. Oh that is annoying, our use case just fitted better into how Python 3 works. We went the opposite way. We micromanaged strings all over the place to ensure that encodings would always be correct. We needed unicode but also connected to Windows systems, which uses their own weird codepage system. Encoding and decoding was everywhere along with encoding detection. Python 3 made all that go away.
- packetlost 3y ago
  It's probably because Google has no interest in rewriting the hundreds of thousands of lines of Go code they have internally and don't want to expend the resources to maintain a v1 and a v2.
- 0cf8612b2e1e 3y ago
  Especially for a compiled language, I would think it is significantly easier to make automated code porting which is guaranteed to be correct. Or at least enough to handle the 99% of a code base which is likely not impacted.
  - dcow 3y ago
    Which is exactly what Swift did when it shipped early source-incompatible revisions.
- zer0tonin 3y ago
  > Python made it through a backwards-incompatible source change The transition took more than a decade and was kind of a mess for a long while. For other languages, like Perl, it really didn't work out.
- mr_00ff00 3y ago
  Python is definitely the exception, not the rule.
  - dcow 3y ago
    Swift shipped source-breaking updates earlier in its lifetime. I honestly don't really know of a story where a source-incompatible update killed a language. People grumble, then they move on.
    - addaon 3y ago
      > I honestly don't really know of a story where a source-incompatible update killed a language. Perl, with the Perl 5 -> Perl 6 (later Raku) transition? Fortran, with the F77 -> F95 transition?
    - ainar-g 3y ago
      > I honestly don't really know of a story where a source-incompatible update killed a language. Death may not come as swiftly (heh) as you think. I know a few people (including myself) who, when deciding which language to add to their toolbox, had decided against Swift because of its reputation as “that language that always breaks code”, among other reasons. There are just a few anecdotal data points, of course, but I don't think it's controversial to say that a history of messy updates definitely makes new people less likely to learn a language without an absolute necessity.
    - throwaway894345 3y ago
      The pain of breaking changes is proportional to the volume of code affected by the breakage. This usually means breakages early in the lifetime are easy because there's relatively little code. For mainstream languages that have a decade or more of widespread usage, a breakage is a big deal. > I honestly don't really know of a story where a source-incompatible update killed a language. Perl. I mean, Perl isn't strictly dead, but its share of the market plummeted. Python almost certainly would have suffered a similar fate if it weren't for the explosion of interest in scientific/numeric computing (which more than made up for massive attrition to other languages, including Go).
- aeturnum 3y ago
  > I understand breaking backwards compatibility would be difficult on a short timescale, but on a long-term time scale people would migrate. It's funny to see people expressing this view because the "2 to 3 migration problems" is still a lively conversation in the Python world. I happen to agree with you and view it as a price of success - but at the same time I think it's obvious that you will pay an outsized price in community sentiment for even reasonable timescales for EOL'ing old versions.
- deleted 3y ago
  [deleted]
- distrill 3y ago
  this always seemed like a nightmare to me. even so today years after python2 was officially sunset, documentation is still all over the web that may never catch up. yes technically the language got over it but i would hold this up as an example of a reason not to break backwards compatibility. having to manage multiple interpreter versions when i'm just trying to run software on my computer, what a pain in the neck.
- crickey 3y ago
  Has python really though? still my company has a bunch of 2.7 lying around that not one is touching. I would like to flip your question on its head and ask why does any language need a breaking change ever? Might as well create a new language in that case
  - mrweasel 3y ago
    While I can't say for sure, one or the reasons I seem to recall from the Python 3 transition was that the Python 2 design was pretty much a dead end. There where so many limitation and wrong design choices that it would keep the language from moving forward. That does seem a little aggressive, but it does feel like Python picked up a lot of steam once Python 3 was viable (something that happened way earlier than many care to admit). Our code base wasn't huge at the time, a few 100.000 lines of code. Getting everything running was a week of work for three people. Sure many had way more complicated code, and some depended on some idiosyncrasies of Python 2 making thing more complex, but a lot of people acted like the Python developers shoot their dog. Mostly these people either simply didn't want to do the work or their particular niche was made ever so slightly more complex... or they depended on unmaintained libraries which is bad in it's own way. Python 3 was always going to be able to do everything Python 2 could, yet a large groups of people acted as if that wasn't the case. Still not the best transition ever devised, we had to wait until 3.2 to get the speed to a point where it's wasn't an issue for all but the largest users.
    - LexiMax 3y ago
      The Python 3 upgrade process for many projects was incredibly painful. "Mercurial’s journey to and reflections on Python 3" should be required reading for anybody with rose-tinted glasses of the migration. https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/ https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journ... There was, of course, a Hacker News thread discussing the article, and a fair few people decided to blame the Mercurial developers for handling the migration inelegantly. Because that's how you win over an audience of developers - reassuring them that if Python has a backwards-compatibility break, Python fans will go out of your way to try and blame you for writing bad code. And not, perhaps, the fact that Python was missing things like a u string prefix and % bytestring formatting until 3.3 (2012) and 3.5 (2015!!!) respectively. If I sound peeved, I really loved Python in the 2.x days, and the way the 3.x transition was handled broke my heart and prevented me from using the language for pretty much an entire decade. There are lessons to be learned from the transition, but not if we ignore the real problems that the transition caused. More importantly, we need to recognize that Python is not the Python we know today because of how "well" the transition was handled, but because Numpy and Matplotlib swooped in and gave Python new niches to excel in at just the right time.
- yakubin 3y ago
  Python programmers just self-selected themselves into a set of programmers who care about backwards-compatibility less than other programmers. You can see this attitude all over the Python ecosystem. And even in standard Python it’s not just one backwards-incompatible change, but a series still made from time to time. Programmers from C++, Java and Go worlds wouldn’t accept it as easily.
- TeddyDD 3y ago
  Go developer experience: * install the newest compiler * clone the code * go build Python developer experience: - clone the code - setup virtual env (otherwise you will break your system) - install very specific version of interpreter because lib x supports only Python from 2020, because Python breaks compatibility in minor versions - no, you can't just update lib x withut updating python and other deps - install deps (hopefully author of the code pinned everyting, otherwise you're fucked) - never update any deps or you will suffer
  - throwaway894345 3y ago
    > Go developer experience: * install the newest compiler * clone the code * go build HN screwed up your formatting, FYI.
    - TeddyDD 3y ago
      I'm clueless when it comes to HN formatting ¯\_(ツ)_/¯
      - dcow 3y ago
        use extra new lines liberally (when in doubt, add a newline) is good working advice
  - gen220 3y ago
    As somebody who writes a lot of python, I'm going to quibble, but your statement isn't unfair. :) My quibble would be "don't use lib x". 99% of the time, you don't need an unsupported 3rd party library from 2020. In the worst case, you can copy the subset of lib x that you actually need, the copied code will typically just work, verbatim, in a later python version. In summary, the "common" path travelled by footgun-aware python programmers is not this bad. But yeah, it'd be nice if the language constraints meant you couldn't end up in a situation like this, and it'd be nice if we didn't have to learn-by-footgun as much in the python community. TBF, Python is just an old language that comes with early-mover advantages and disadvantages. Like an old house, we have just learned to live with (i.e. avoid) certain floorboards.
- badrequest 3y ago
  > Python made it through a backwards-incompatible source change. It took them a decade and permanently tarnished their perception with many programmers. They "made it through" in a similar way to how cancer survivors enter remission.
- dgb23 3y ago
  Incompatibility, lack of stability and other churn inducing changes are the nemesis of software maintenance. The implied cost is immense and soul sucking. In many cases it’s pure vanity as well. It’s fine for early languages, research languages and toy languages. But outside of these categories it’s not worth the cost.
- morelisp 3y ago
  > Python made it through a backwards-incompatible source change.... Source rewriters would handle most of the transition. It seems we have collectively learned literally nothing from the failed plans to change Python incompatibly.
- masklinn 3y ago
  > Python made it through a backwards-incompatible source change. It made it, but it was a rough few years, and the string model changes while mostly welcome (though not perfect) were a pain, we still find bugs from time to time. Things also got a lot better once the community figured how to do proper multiversion sources even though it was more limiting. A statically typed langage would have it a lot easier, by virtue of both the API and the semantics changes being much more flagrant, as well as the compiler making it easier to actually mix different versions of the langage across different packages (or even source files).
- jerf 3y ago
  "Why is backwards compatibility such a religious sin for Go?" I think the best way to understand it is that it is a first-class feature of the language. Thus, for Go specifically, it is like asking "Why is it a statically-typed language?" or "Why is the language compiled rather than interpreted?"; these are not bad questions but to a large degree the answer is that was a major choice made at the start of the language. And "why won't they get rid of it?" is in the same class of questions as "Why won't Python just become a statically-typed language?", which, is, again not intrinsically a bad question, but one that is certainly in a different category from "why won't Python adopt this particular bit of syntax sugar in their next version?" That the designers of Go would consider that a "feature" and so many programmers probably find classifying "backwards compatibility" as a feature a completely befuddling concept ("that's not what a feature is!") is probably a pretty good microcosm of the difference between the gestalt of programmers as a whole and the Go designers.
- ranting-moth 3y ago
  > Python made it through a backwards-incompatible source change. That's skipping a few fact, isn't it? Let's call it what it was. Python was a victim in a cataclysmic software disaster of biblical proportions. It spend 10 years in rehab afterwards but miraculously made it through yes.
- dekhn 3y ago
  Backwards compatibility matters to the Go developers because all of them worked with the same codebases for 20+ years. I remember rob pike showed me a source file that had been written before I was born (1973) but is still part of (I think) Plan9.
Waterluvian 3y ago
I'm a big fan of the assertion that a future Go 2 will never break Go 1 compatibility. I think if you need to make changes so significant to a language, you may as well just fork and rename the language (an opinion I can see many holes in). I wonder: why not go further and say "there will never be a Go 2" in order to eliminate ambiguity about this? If a theoretical Go 2 will run all Go 1 programs, what would make it different from some Go 1.xx release? Some might interpret this post as saying that, but I don't think it quite does. It says "There will not be a Go 2 that breaks Go 1 programs."
- sudhirj 3y ago
  It becomes a semantic difference at that point. If Go is doing semver, and there are going to be no backward-incompatible changes, there's no reason to ever increment the major version. Everything is a minor version (compatible additions) and patch version (bug fixes).
- jdc0589 3y ago
  > I wonder: why not go further and say "there will never be a Go 2" Pretty sure they've said this in the past.
- flakes 3y ago
  The article does state that at the end: > The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened.
- cogman10 3y ago
  Java went through this. There was a Java 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, and 1.7. Then, Java decided "You know what, we aren't breaking backwards compatibility so instead of naming things 1.x, let's just say Java 8, 9, 10...21" I think that ultimately makes sense.
  - mrweasel 3y ago
    I did not know that was the reasoning or logic behind the Java 8, 9, 10 ... numbering, that clears up so many thing.
sudhirj 3y ago
Amen to that. I get super excited about Go releases because they often add useful stuff with zero breakage of anything (just free wins all around). It's not clear that any part of the language is so broken that backward compatible changes can't fix it. Even the few foot guns like loop variable assignment have proposals that mostly preserve compatibility.
- sedatk 3y ago
  Interesting because I observe the opposite sentiment among .NET developers for features added in C# despite that its backwards compatibility is also fully preserved. They say “the language is getting bloated”, “it becomes harder to learn”. I totally have your perspective on this, but the difference in attitudes is noteworthy.
  - sudhirj 3y ago
    I haven't used C# in over a decade, but I was already feeling that way - there's just a lot in there. Go seems to start with a default no to things, so that might be why it has a relatively small surface area.
  - jerf 3y ago
    In the past ten years, here's a list of significant feature additions to the Go language itself: * Generics And even that has not been the shocking revolution some people expected; it turns out to overall be a nice little addition rather than something that rewrote what good Go was. Nothing like the Python transition to "new style" classes, or the Python 2 -> 3 transition, or the Python async ecosystem transition, and that's just one language. For the most part a Go 1.4 programmer suddenly transported to today would not find it a terribly difficult task to read code using the generics. And broadly speaking, the language didn't start with a lot of features either. Go has had a lot of library improvements, it's had a lot of tooling improvements, but the language itself is extremely stable. I've seen a few people actually complain about Go moving too fast, to which I wonder what exactly would make them happy if even Go is zooming along too quickly for them, because I honestly don't know a language moving more slowly than Go, for all the advantages and all the disadvantages that incurs. I've honestly sort of wished I could sit down with them for 15 minutes and see if I could figure out what their real problem is, or if they really are upset that there was ever a major change.
chrisdinn 3y ago
I write a lot of Go and I can’t tell you how much this warms my heart. Compatibility probably isn’t much fun for the language team, always having to keep one foot firmly in the “distant” past. But for those of us that have to maintain large Go systems it’s such a gift.
- nappy-doo 3y ago
  I worked on the Go compiler for a couple of years, and it wasn't a big deal. We just thought carefully about things, and dealt with a lot of rejection of ideas. If we couldn't make it fit, it wasn't right, and we'd try again. If we still couldn't make it fit, we probably didn't have a good handle on the problem, and it was right to stew on it longer. Frankly, I truly appreciated working with people who thought carefully and tried to make sure the right ideas were in. I appreciated Russ being a BDFL, Ian, Rob, and Rob. I'm glad I did it, and it made me a much better engineer.
kodra 3y ago
Interesting to see the first two comments in this thread have the opposing opinions on backward compatibility. I guess it depends on how deeply Python cut you.
- deleted 3y ago
  [deleted]
fullstackchris 3y ago
darn i was hoping for at least a hint or mention when Go 2 might be released... no dice
- sudhirj 3y ago
  Go 2 is coming out every six months as continuous Go 1.x releases.
- tptacek 3y ago
  The article ends with a definitive answer to that question.
- euroderf 3y ago
  I would expect a Go 2 to dispense with accumulated API cruft and to overhaul syntax with something radically different. But to otherwise maintain compatibility.
Joker_vD 3y ago
Ah, parsing IPs. Just how exactly was the BSD's original inet_ntoa written, I wonder? The atoi/atol and sscanf with %d/%u always parse exactly decimal integers; it would had to use either %i or strtou with 0 base to have this silly effect.
- wahern 3y ago
  No need to guess. My man page for inet_aton says it comes from 4.3BSD: https://github.com/dank101/4.3BSD-Reno/blob/master/lib/libc/net/inet_addr.c https://github.com/dank101/4.3BSD-Reno/blob/master/lib/libc/... The earlier inet_addr from 4.2BSD has the same logic: https://github.com/dank101/4.2BSD/blob/master/lib/libc/inet/inet_addr.c https://github.com/dank101/4.2BSD/blob/master/lib/libc/inet/... inet_aton and inet_addr parse addresses the obvious way. Using something like strtoul or especially sscanf would be stilted. The beauty of C pointers is that it makes simple parsing tasks very easy--perhaps too easy.
  - Joker_vD 3y ago
    O_O They've intentionally coded it that way? This is atrocious. And this hand-rolled mess that doesn't even parse numbers correctly! It would parse "099" as 81 and "99999999999999999" as whatever it is modulo (MAX_ULONG+1), without any overflow detection. Well, at least they don't accept negative numbers, that's something. Anf mind you, beauty of C pointers has nothing to do with neither of these two bugs not the original decision to support octals and hexadecimals.
- doctor_eval 3y ago
  I laughed when I read that. “Back in the day” I decided to “clean up” my /etc/hosts by zero padding the quads. Anyway, the outcome was that I had to go back and remove the zeroes.
the_duke 3y ago
Never breaking compatibility is hardly a new idea. Java and C++ have invested tremendous amounts of effort into preserving backwards compatibility for decades, often requiring bending over backwards and very suboptimal designs for new features, especially in C++. But it keeps users happy. At least the ones with large old code bases. I think Rust has one of the cleanest models for this, which keeps complexity low: editions. The compiler will always support old code written against older editions, but the language can still introduce breaking changes in newer editions. Developers can either opt in to new editions and migrate their code, or do nothing, and things continue to work fine. There is seamless/transparent interoperability. Of course Rust is still pretty young, and if this model will work long term remains to be seen. For example, I imagine this causes a lot of implementation complexity in the compiler, the standard library is much more restricted and must remain stable across editions, and major overhauls probably won't be possible. But so far it has worked out really well, allowing the team to fix warts and mistakes in the language.
- deleted 3y ago
  [deleted]
- zigzag312 3y ago
  I would upvote this twice if I could. We will never break compatibility is code for "we will never fix warts and mistakes in the language".
  - tptacek 3y ago
    It obviously isn't, as the text of the article repeatedly observes.
    - zigzag312 3y ago
      You are right. I haven't read the article and just assumed. It's actually about how they enabled introducing "breaking" changes without actually breaking backwards compatibility with existing code. Which is best possible outcome.
- 3y ago
dang 3y ago
Related: Forward Compatibility and Toolchain Management in Go 1.21 - https://news.ycombinator.com/item?id=37122932 https://news.ycombinator.com/item?id=37122932 (no comments yet, but some will probably show up)
JoshGlazebrook 3y ago
I started using Go at work ~2 years ago and I love it, especially for the backwards compatibility. But my personal projects up until then were node.js backends written with Typescript. Those personal projects are essentially stuck in time because of the whole ESM/commonjs mess that is modern javascript. Some of the npm package I use have been updated to only support ESM modules, while others will never be updated, some are half and half. It's in such a bad state that I've decided if it does ever fully break I'm just going to re-write the backend in Go, and I know I'm not the only one just frustrated with the modern javascript ecosystem and have projects stuck on old node.js and npm package versions because of it.
- cookiengineer 3y ago
  Babel was the most enterprise thing that could happen to the JS ecosystem. Gone are the simple distribution channels, and all build pipelines have 100s of megabytes of legacy crap that nobody actually ever executes. If you want to tell me your page is working in IE6, you're lying. It will break apart in all places. Anybody remember bower and pikapkg? That was the peak in my opinion.
  - nobleach 3y ago
    Oh my.... yes. For me, that would have been Angular 1.x days. And while it was neat having a tool that could pull a deterministic flat list of dependencies, I wouldn't go back to those days. I do wholeheartedly agree that injecting core-js into every single build, in the rarest of cases that you'd need to support a browser that doesn't support generators, or some other featured added around 2015, is just plain silly. I cringe when I look at a dependency graph and see all those polyfills in my builds!!
- joshstrange 3y ago
  In your position I'd probably do the same thing and no doubt the ESM/commonJS mess is a mess and huge PITA. All that said I'll probably continue with my TypeScript/NodeJS backends since I just absolutely love writing TypeScript and I love sharing code between the front and backend. I use JS/TS in my day job (frontend only) as well so it's super nice to be able to benefit from that knowledge/practice. I also use TypeScript to write a few apps (some for work, some for my side project, some for personal use) so staying in the TypeScript ecosystem for almost everything I do is really nice. Again, I'm not defending that annoying/bad parts of TS and certainly not saying I've escaped the ESM/commonJS hell unscathed, just that I use TS everywhere and I generally have a lot of fun writing/running it.
jokoon 3y ago
BTW, I've read the Go GC can be disabled, but what happens if you do? Wouldn't you have to avoid memory leaks?
- jeeyoungk 3y ago
  If your program is short running, then it may be more efficient to disable GC and let the dying process to take care of it all.
  - 0cf8612b2e1e 3y ago
    There many tales about programs foregoing any kind of memory collection and relying upon the business process itself to resolve the issue. My favorite is a missile. Evidently the program leaks memory like crazy. Solution was to determine how much memory would be required for the platform to fly to its farthest possible target + some margin. Alternatively are stock trading platforms written in Java. Disable the GC entirely because trading hours are only a a limited portion of the day. Restart the program daily.
    - hbn 3y ago
      I like to think the stock market thing is actually the reverse, and they shut it down every night because all the programs that keep it running were written in a memory-leaking tech stack that needs restarting
    - titzer 3y ago
      > My favorite is a missile. This might be apocryphal, as software for this class of embedded system almost certainly doesn't dynamically allocate anything; probably doesn't even use pools. I have a friend who works on missile software at a big defense contractor, and they do actually clean up their memory.
      - 0cf8612b2e1e 3y ago
        I found a source, quoting the quote, so provenance is what it is > This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention. [0] https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98125 https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
gavinhoward 3y ago
As a language designer, I respect the decisions they made here, including you never have a real Go 2. I'm also going to pilfer their techniques for ensuring compatibility.
mseepgood 3y ago
Since Go 2 is never going to happen, maybe it's time to rename the "Go2" label on GitHub and remove the "Go 2:" prefix in the template for language change proposals. I think this confuses people into believing that Go 2 is a thing.
- ainar-g 3y ago
  Based on the discussions I've seen, Go2 is considered to be the name for the process of extending the language, not an exact release version. With that said, the label seems to “work” by allowing people to first think of a backwards-incompatible way to solve a problem and then, possibly, arrive at a much more compatible solution in the process of discussion.
  - mseepgood 3y ago
    > Based on the discussions I've seen, Go2 is considered to be the name for the process of extending the language, not an exact release version. I know, but many people obviously don't know that, so it might be a bad name. Just label it LanguageChange or Incompatible.
- yencabulator 3y ago
  Go 2 is the Zeno paradox goalpost that will never be achieved, while making continual progress toward it.
unethical_ban 3y ago
If Go 2 won't break Go 1 programs, shouldn't it be Go 1? I get not using semantic versioning for end user packages like a web browser, but for backend systems and APIs, it still makes sense. I don't see why go didn't use full semantic versioning (x.y.z) where any update that didn't break anything moved Z, new APIs or minor changes to behavior/compile such as in the article move Y, and large changes to the core language or core libraries moves X. By semantic versioning, they aren't moving off "Go 1" any time soon, no matter what it's called.
- mseepgood 3y ago
  > If Go 2 won't break Go 1 programs, shouldn't it be Go 1? Yes, that's what the article is saying.
  - unethical_ban 3y ago
    Ah. So to phrase it differently, "There will never be a Go 2 unless marketing says we should renumber." Just stop referencing "Go 2" as if they ever think it will exist, then!
    - metaltyphoon 3y ago
      Agreed. It’s confusing as hell
w10-1 3y ago
The question for compatibility is not whether but how. And it's not really backwards: you want your code to just work, from now on. Go 1.21 offers two essential features not matched by any other language ecosystem: 1. A GODEBUG setting for each change, together with per-change opt-out and per-change metric for detecting use of the prior implementation. 2. A per-module toolchain version, together with automatic fetching of both older and newer go toolchains (deployed safely as modules) As an amazing bonus, if you specify a given version of go (e.g., 1.21.2), then when running under a newer version of go, go will automatically apply the relevant opt-out configuration so you won't get the new behavior until you ask for it. Finally, as ever you can declare things in code, in go.mod, and in environment. That basically covers all the use-cases for compatibility, from developers through deployers. Simple, and beautiful.
- shakow 3y ago
  > essential features not matched by any other language ecosystem > proceeds to list features abundantly common in other languages Least enthusiastic Go user.
- deleted 3y ago
  [deleted]
- mcbrit 3y ago
  Apologies, but this actually sounds like a nightmare to me, if you have at least 1-10m+ loc over enough teams, enough teams being probably 5+ depending on org boundaries. Either you support the new version or you don't is more than enough complexity to cause arbitrarily ridiculous problems, because there is a deep valley of you /think/ you support the new version and the new version thinks that it supports you but you both miss. (who wants the t-shirt saying that they have been responsible for a 1m+ code base on top of 10m+ for at least 20 years?)
  - jrockway 3y ago
    If Team A requires compatibility with go 1.21, their go.mod will start with "go 1.21". Even if the code is compiled with go 1.22, their code will run unchanged, as the toolchain now treats the go version line as the toolchain to be compatible with. Similarly, if Team B requires compatibility with go 1.22 but their code is being compiled with go 1.21, go will download the 1.22 toolchain and run with that instead. It's sneaky and crazy, but so crazy it just might work. (As a user of CircleCI convenience images for a few tests suites, I appreciate this feature. When there is some security vulnerability that requires updating to go 1.21.1, I don't have to wait for Circle to build a new convenience image. I can just change go.mod and start using 1.21.1 immediately. This saves a day of telling people to ignore govulncheck.) The TL;DR is that the compiler version is now something you can declare in your go.mod file like any other dependency. If you share one go.mod file across all teams or have a One Version Policy, then there will always be work to do. No doubt there are several dedicated (in practice) employees to manage "there is a critical security release for github.com/whatever/frob@1.2.3 but the Team A's tests fail when updating to github.com/whatever/frob@1.2.4", which is inevitable at this scale.
brunojppb 3y ago
> Boring is good. Boring is stable. Boring means being able to focus on your work, not on what’s different about Go. This really resonates with me. I work with NodeJS and the JS ecosystem in general on my day job and I have to tell you, the struggle is real. The ecosystem is fragmented, everyone is doing their own thing, which is hard to make things stable. Don’t get me wrong, I still enjoy this work, but I really wish the JS ecosystem could have a stable modern foundation we could rely on.
- hermanradtke 3y ago
  The JS eco-system (npm, React, etc)? Sure. Let us also acknowledge that JavaScript, the language, has been prioritizing backwards compatibility before golang even existed.
  - ilyt 3y ago
    Well, it is a bit easier if you have no stdlib to speak of
    - trhhowaway232 3y ago
      JS has a stdlib, there's just nothing in it.
- devjab 3y ago
  JavaScript is famously backwards compatible. That’s exactly why it’s the mess you describe.
- afavour 3y ago
  > I really wish the JS ecosystem could have a stable modern foundation we could rely on. I actually think we do now. ES modules, ES2020 code. Both supported by Node and major browsers. Node even has a built in test runner now! The problem is getting everyone up to this bar. Once we’re there I think things are going to feel a lot better. I think part of the problem is that the JS ecosystem also encompasses frontend UI work and there are so many different applications for it that multiple implementations is inevitable. Desirable, even.
mdwhatcott 3y ago
To coin a phrase, "Go 2 considered harmful" :)
- deleted 3y ago
  [deleted]
- ainar-g 3y ago
  https://github.com/golang/proposal/blob/d661ed19a203000b7c5441d2cd63a6e4b98ff2ba/design/28221-go2-transitions.md#go-2 https://github.com/golang/proposal/blob/d661ed19a203000b7c54... About five years too late, heh.
  - mdwhatcott 3y ago
    I knew it was too good to have been original.
AtNightWeCode 3y ago
I suggest Go and Dart morph into one lang. Then you could use the power of Go with the more logical syntax of Dart.
- rstat1 3y ago
  So you want them to completely break every pre-existing Go program, for no practical benefit? That seems dumb.
  - AtNightWeCode 3y ago
    No. It would only be a flag to allow obsolete Go code in practice I guess. EDIT: C++ did not break C. The people managing Go have full understanding of dependencies even though they made breaking changes.
- AtNightWeCode 3y ago
  Could some of the genius down-voting argue for the reason why Google needs both of these more or less dying langs?
  - physicles 3y ago
    Go is dying?
parhamn 3y ago
Love this. Nothing better than coming to a go codebase and bumping the go version knowing everything will work fine. One thing I worry about is that the type system can’t get improved significantly without breaking changes in the “this was wrong and wont compile now" sense. Although I'm not sure theres interest for this stuff in the golang team at all. But there are many low hanging type system improvements in go that are major compile time robustness wins for folks, with no language additions. 1) reporting unchecked nils, might require formalizing [T, nil] | [nil, err] so err != nil guarantees T (obviously concurrent pointer access makes it tricky but thats special code with special considerations, not the 99% case) 2) unchecked array access 3) inferring types of nested struct literals. Writing nested GRPC calls is such a damn pain go, this is literally only one layer of type inference... its in the damn function signature I'm calling! 4) Exhaustive enum matches But now I'm curious, is there any interest for these changes in the golang community? None are adding "features" (like say generics) but would be huge robustness wins and seem pretty easy.
- josephg 3y ago
  Just to beat this drum from outside the go community, rust / swift style enums with parameters are mana from heaven. So many programs get easier to write using them. If there’s one way I’d love the go type system to be improved, it would be by adding these simple, lovely algebraic data types. Trust me, they would look great in Go. Treat yourself.
  - sharno 3y ago
    It's ridiculous to me that the most popular languages from the last 20 years or more are the ones that handicapped. They have `and` types but not `or`. It sounds like a very basic logic tool that's needed for types.
  - andyferris 3y ago
    I agree. If go had sum types I’d use it in a heartbeat!
  - valzam 3y ago
    The irony is that Go actually does have sum types, but only for generics! type A interface { Foo | Bar | Baz } Can't use this anywhere but in generic type signatures though :(
gigatexal 3y ago
Here’s hoping they do all the wild changes they want in go 2 and keep go 1.x versions compatible with each other. That gets you the best of both worlds: legacy code can run the legacy version of go and the newer iteration of the language will break compatibility and thereby shed any tech debt and cruft as it learns from any previous mistakes or compromises.
- stanleydrew 3y ago
  Seems you didn't get to the end: https://go.dev/blog/compat#go2 https://go.dev/blog/compat#go2
  - gigatexal 3y ago
    Oh my bad. Hmm. Well not what I wanted but probably the best choice I guess.
deagle50 3y ago
Call me when we get some sugar for `if err != nil`. The signal to noise ratio when reading Go code is not great.
- assbuttbuttass 3y ago
  I did some regex analysis on my codebase of over 37000 lines. In exactly 566 occurrences of "if err != nil", there were only 154 that just returned the error directly. The other instances are doing some form of wrapping to add more context to the error, or collecting errors from multiple operations, or wrapping the error with a status code, or a bunch of other things. The problem with every error handling suggestion I've seen is that it only handles the one case if err != nil { return nil, err } But that's only the case 27% of the time! The other cases are harder, and require more thought anyway. Why optimize for a rare case that's already easy?
  - deagle50 3y ago
    Thanks for looking this up. I'm not just referring to blocs that just return the error, though even then your 154 occurrences lead to 462 lines of noise. Noise that could could be avoided with sugar like `?`. I'm referring to all the code blocks that start with `if err != nil {`. Wrapping and adding context could be done at the end of the previous function call and we wouldn't have to read boilerplate over and over.
iraqmtpizza 3y ago
[flagged]
vl 3y ago
Compatibility or not, but if object field of interface is set to nil, then myVar == nil should return true, unlike bizzare behavior now! Right now it's possible to get nil interface from one func, return it from another resulting in hidden cast, and this returned value fails nil check. This leads to hidden bugs, and code like this: p = makeP() if p == nil { return nil } return p and all this can be avoided by not requiring both fields of interface to be nil for successful nil check. I sure hope this will be fixed at least in 2. Also finally we got max/min. Maybe it's time for, you know, sets? Ordered_maps? Hashable slices? Ground breaking, I know.
Zamicol 3y ago
Nice article Russ.
varispeed 3y ago
Since they announced adding malware in the toolchain (sorry, khem, telemetry) I somewhat lost interest in Go. How do I know which version has spying turned on or whether this was abandoned? edit: I wonder if this was mandated by Chinese government, as certain Go tools that help circumvent censorship are written in Go and maybe government wants to know who compiles them.
ilyt 3y ago
I do hope they will eventually introduce sum types and better way of handling errors, but keeping the old code just work is frankly more important on the grander scale.
fjfuvucucuc 3y ago
[dead]
atleastoptimal 3y ago
Pokemon Go 2 the polls
davewritescode 3y ago
This is something I’ve complained about before on HN but this rings really hollow when Go 1.17 arbitrarily updated the x.509 package to suddenly stop supporting TLS hostname validation based on the CN field because it was deprecated in the X509 specification. My browser doesn’t care, why should Go?
- icholy 3y ago
  Found the guy who only read the title.
auxten 3y ago
Golang's forward compatibility and static compilation allow developers to quickly download and use the latest Golang release without the pain of upgrading like interpreted languages or VM-dependent languages.
sleepytimetea 3y ago
The leading zeroes in net.ParseIP change broke some of our unit tests too.

Moving some code from python to Golang was instrumental in helping me scale. I am so glad to read they are going to stick to their core statement of backwards compatability

pjmlp 3y ago

Looking forward to Go 1.99999999999999....

deleted 3y ago

[deleted]

dcow 3y ago

> That raises an obvious question: when should we expect the Go 2 specification that breaks old Go 1 programs? > The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened. Why is backwards compatibility such a religious sin for Go? Python made it through a backwards-incompatible source change. I understand breaking backwards compatibility would be difficult on a short timescale, but on a long-term time scale people would migrate. Source rewriters would handle most of the transition. Over 3-5 years I could see a source-breaking change play out positively for some of these newer languages like Go and Rust. And arguably, they sorely need it.

jimmaswell 3y ago
Python was a disaster. I still miss print statements and encoding-agnostic strings. Good on Go for doing the right thing.
- hk__2 3y ago
  Print statements were a mistake. If you forbid breaking changes, you have no way to fix past mistakes in the language design. There’s noting inherently "right" in refusing to do breaking changes.
  - jimmaswell 3y ago
    Removing the print statement was the mistake to me. It violated Python's own stated principle of practicality over purity.
    - rowanseymour 3y ago
      Having two ways to do the same thing is the mistake, and print() was always more consistent with other built in functions are invoked.
    - masklinn 3y ago
      There was nothing practical about the print statement. The print function is easier to use, meshes a lot better with the langage, and can actually be extended without C++ style syntactic nonsense. The print function is one of the best things to come out of p3.
- dcow 3y ago
  I think if you'd ask any Python programmer today, they'd say Python is very much healthy and the community has successfully transitioned.
  - jimmaswell 3y ago
    Python was my first language and I still use it sometimes. Still run into 2 vs 3 issues often.
- mrweasel 3y ago
  > encoding-agnostic strings Do you mean byte strings vs. strings in Python 3 or did you actually like string handling in Python 2, because that basically "Tell me that you only allow ASCII without telling me that you only all ASCII". I can see the issue with byte strings in Python3, it's annoying that you have to think about both strings and byte strings, but for dealing with actual text having everything just be unicode was reason enough to upgrade from 2 to 3. We deleted so much code dedicated to dealing with encoding during our switch to Python 3, everything just became better.
  - jimmaswell 3y ago
    I had an IRC markov-like bot in Python. It used to be so simple in Python 2: - the bytes come in from the IRC server - they go in a string in the log, I can print this log to the console even if it has some IRC control codes (there will be a garbage character here or there but that's OK) - if I want to make a bold/color/etc I can just throw \xwhatever in the string. if a word from the log had bold in it and it's repeated back it will also have the bold in it. Then I reluctantly ported it to Python 3 and it was awful. Python now had to micromanage every single string to ensure I don't have any "naughty" bytes in it. Conversions to/from byte/string everywhere. Massive headache every time I wanted to read or write IRC encoded strings to a txt file or print them to the console or anything. In Python 2 the encoding only lived outside the program, in my terminal, text editor, and IRC clients. Bytes went in, bytes went out, and everyone was happy. Python 3 decided it needed to know exactly what was going on every step of the way and didn't trust me anymore, forcing me to do an elaborate song and dance to get anything done. I prefer my tools to have as little an opinion as possible. Let me open the door while I'm driving, let me run my web browser as root, and let me print \xDE\xAD\xBE\xEF to the console.
    - mrweasel 3y ago
      > Python now had to micromanage every single string to ensure I don't have any "naughty" bytes in it. Oh that is annoying, our use case just fitted better into how Python 3 works. We went the opposite way. We micromanaged strings all over the place to ensure that encodings would always be correct. We needed unicode but also connected to Windows systems, which uses their own weird codepage system. Encoding and decoding was everywhere along with encoding detection. Python 3 made all that go away.
packetlost 3y ago
It's probably because Google has no interest in rewriting the hundreds of thousands of lines of Go code they have internally and don't want to expend the resources to maintain a v1 and a v2.
0cf8612b2e1e 3y ago
Especially for a compiled language, I would think it is significantly easier to make automated code porting which is guaranteed to be correct. Or at least enough to handle the 99% of a code base which is likely not impacted.
- dcow 3y ago
  Which is exactly what Swift did when it shipped early source-incompatible revisions.
zer0tonin 3y ago
> Python made it through a backwards-incompatible source change The transition took more than a decade and was kind of a mess for a long while. For other languages, like Perl, it really didn't work out.
mr_00ff00 3y ago
Python is definitely the exception, not the rule.
- dcow 3y ago
  Swift shipped source-breaking updates earlier in its lifetime. I honestly don't really know of a story where a source-incompatible update killed a language. People grumble, then they move on.
  - addaon 3y ago
    > I honestly don't really know of a story where a source-incompatible update killed a language. Perl, with the Perl 5 -> Perl 6 (later Raku) transition? Fortran, with the F77 -> F95 transition?
  - ainar-g 3y ago
    > I honestly don't really know of a story where a source-incompatible update killed a language. Death may not come as swiftly (heh) as you think. I know a few people (including myself) who, when deciding which language to add to their toolbox, had decided against Swift because of its reputation as “that language that always breaks code”, among other reasons. There are just a few anecdotal data points, of course, but I don't think it's controversial to say that a history of messy updates definitely makes new people less likely to learn a language without an absolute necessity.
  - throwaway894345 3y ago
    The pain of breaking changes is proportional to the volume of code affected by the breakage. This usually means breakages early in the lifetime are easy because there's relatively little code. For mainstream languages that have a decade or more of widespread usage, a breakage is a big deal. > I honestly don't really know of a story where a source-incompatible update killed a language. Perl. I mean, Perl isn't strictly dead, but its share of the market plummeted. Python almost certainly would have suffered a similar fate if it weren't for the explosion of interest in scientific/numeric computing (which more than made up for massive attrition to other languages, including Go).
aeturnum 3y ago
> I understand breaking backwards compatibility would be difficult on a short timescale, but on a long-term time scale people would migrate. It's funny to see people expressing this view because the "2 to 3 migration problems" is still a lively conversation in the Python world. I happen to agree with you and view it as a price of success - but at the same time I think it's obvious that you will pay an outsized price in community sentiment for even reasonable timescales for EOL'ing old versions.
deleted 3y ago
[deleted]
distrill 3y ago
this always seemed like a nightmare to me. even so today years after python2 was officially sunset, documentation is still all over the web that may never catch up. yes technically the language got over it but i would hold this up as an example of a reason not to break backwards compatibility. having to manage multiple interpreter versions when i'm just trying to run software on my computer, what a pain in the neck.
crickey 3y ago
Has python really though? still my company has a bunch of 2.7 lying around that not one is touching. I would like to flip your question on its head and ask why does any language need a breaking change ever? Might as well create a new language in that case
- mrweasel 3y ago
  While I can't say for sure, one or the reasons I seem to recall from the Python 3 transition was that the Python 2 design was pretty much a dead end. There where so many limitation and wrong design choices that it would keep the language from moving forward. That does seem a little aggressive, but it does feel like Python picked up a lot of steam once Python 3 was viable (something that happened way earlier than many care to admit). Our code base wasn't huge at the time, a few 100.000 lines of code. Getting everything running was a week of work for three people. Sure many had way more complicated code, and some depended on some idiosyncrasies of Python 2 making thing more complex, but a lot of people acted like the Python developers shoot their dog. Mostly these people either simply didn't want to do the work or their particular niche was made ever so slightly more complex... or they depended on unmaintained libraries which is bad in it's own way. Python 3 was always going to be able to do everything Python 2 could, yet a large groups of people acted as if that wasn't the case. Still not the best transition ever devised, we had to wait until 3.2 to get the speed to a point where it's wasn't an issue for all but the largest users.
  - LexiMax 3y ago
    The Python 3 upgrade process for many projects was incredibly painful. "Mercurial’s journey to and reflections on Python 3" should be required reading for anybody with rose-tinted glasses of the migration. https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/ https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journ... There was, of course, a Hacker News thread discussing the article, and a fair few people decided to blame the Mercurial developers for handling the migration inelegantly. Because that's how you win over an audience of developers - reassuring them that if Python has a backwards-compatibility break, Python fans will go out of your way to try and blame you for writing bad code. And not, perhaps, the fact that Python was missing things like a u string prefix and % bytestring formatting until 3.3 (2012) and 3.5 (2015!!!) respectively. If I sound peeved, I really loved Python in the 2.x days, and the way the 3.x transition was handled broke my heart and prevented me from using the language for pretty much an entire decade. There are lessons to be learned from the transition, but not if we ignore the real problems that the transition caused. More importantly, we need to recognize that Python is not the Python we know today because of how "well" the transition was handled, but because Numpy and Matplotlib swooped in and gave Python new niches to excel in at just the right time.
yakubin 3y ago
Python programmers just self-selected themselves into a set of programmers who care about backwards-compatibility less than other programmers. You can see this attitude all over the Python ecosystem. And even in standard Python it’s not just one backwards-incompatible change, but a series still made from time to time. Programmers from C++, Java and Go worlds wouldn’t accept it as easily.
TeddyDD 3y ago
Go developer experience: * install the newest compiler * clone the code * go build Python developer experience: - clone the code - setup virtual env (otherwise you will break your system) - install very specific version of interpreter because lib x supports only Python from 2020, because Python breaks compatibility in minor versions - no, you can't just update lib x withut updating python and other deps - install deps (hopefully author of the code pinned everyting, otherwise you're fucked) - never update any deps or you will suffer
- throwaway894345 3y ago
  > Go developer experience: * install the newest compiler * clone the code * go build HN screwed up your formatting, FYI.
  - TeddyDD 3y ago
    I'm clueless when it comes to HN formatting ¯\_(ツ)_/¯
    - dcow 3y ago
      use extra new lines liberally (when in doubt, add a newline) is good working advice
- gen220 3y ago
  As somebody who writes a lot of python, I'm going to quibble, but your statement isn't unfair. :) My quibble would be "don't use lib x". 99% of the time, you don't need an unsupported 3rd party library from 2020. In the worst case, you can copy the subset of lib x that you actually need, the copied code will typically just work, verbatim, in a later python version. In summary, the "common" path travelled by footgun-aware python programmers is not this bad. But yeah, it'd be nice if the language constraints meant you couldn't end up in a situation like this, and it'd be nice if we didn't have to learn-by-footgun as much in the python community. TBF, Python is just an old language that comes with early-mover advantages and disadvantages. Like an old house, we have just learned to live with (i.e. avoid) certain floorboards.
badrequest 3y ago
> Python made it through a backwards-incompatible source change. It took them a decade and permanently tarnished their perception with many programmers. They "made it through" in a similar way to how cancer survivors enter remission.
dgb23 3y ago
Incompatibility, lack of stability and other churn inducing changes are the nemesis of software maintenance. The implied cost is immense and soul sucking. In many cases it’s pure vanity as well. It’s fine for early languages, research languages and toy languages. But outside of these categories it’s not worth the cost.
morelisp 3y ago
> Python made it through a backwards-incompatible source change.... Source rewriters would handle most of the transition. It seems we have collectively learned literally nothing from the failed plans to change Python incompatibly.
masklinn 3y ago
> Python made it through a backwards-incompatible source change. It made it, but it was a rough few years, and the string model changes while mostly welcome (though not perfect) were a pain, we still find bugs from time to time. Things also got a lot better once the community figured how to do proper multiversion sources even though it was more limiting. A statically typed langage would have it a lot easier, by virtue of both the API and the semantics changes being much more flagrant, as well as the compiler making it easier to actually mix different versions of the langage across different packages (or even source files).
jerf 3y ago
"Why is backwards compatibility such a religious sin for Go?" I think the best way to understand it is that it is a first-class feature of the language. Thus, for Go specifically, it is like asking "Why is it a statically-typed language?" or "Why is the language compiled rather than interpreted?"; these are not bad questions but to a large degree the answer is that was a major choice made at the start of the language. And "why won't they get rid of it?" is in the same class of questions as "Why won't Python just become a statically-typed language?", which, is, again not intrinsically a bad question, but one that is certainly in a different category from "why won't Python adopt this particular bit of syntax sugar in their next version?" That the designers of Go would consider that a "feature" and so many programmers probably find classifying "backwards compatibility" as a feature a completely befuddling concept ("that's not what a feature is!") is probably a pretty good microcosm of the difference between the gestalt of programmers as a whole and the Go designers.
ranting-moth 3y ago
> Python made it through a backwards-incompatible source change. That's skipping a few fact, isn't it? Let's call it what it was. Python was a victim in a cataclysmic software disaster of biblical proportions. It spend 10 years in rehab afterwards but miraculously made it through yes.
dekhn 3y ago
Backwards compatibility matters to the Go developers because all of them worked with the same codebases for 20+ years. I remember rob pike showed me a source file that had been written before I was born (1973) but is still part of (I think) Plan9.

Waterluvian 3y ago

I'm a big fan of the assertion that a future Go 2 will never break Go 1 compatibility. I think if you need to make changes so significant to a language, you may as well just fork and rename the language (an opinion I can see many holes in). I wonder: why not go further and say "there will never be a Go 2" in order to eliminate ambiguity about this? If a theoretical Go 2 will run all Go 1 programs, what would make it different from some Go 1.xx release? Some might interpret this post as saying that, but I don't think it quite does. It says "There will not be a Go 2 that breaks Go 1 programs."

sudhirj 3y ago
It becomes a semantic difference at that point. If Go is doing semver, and there are going to be no backward-incompatible changes, there's no reason to ever increment the major version. Everything is a minor version (compatible additions) and patch version (bug fixes).
jdc0589 3y ago
> I wonder: why not go further and say "there will never be a Go 2" Pretty sure they've said this in the past.
flakes 3y ago
The article does state that at the end: > The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened.
cogman10 3y ago
Java went through this. There was a Java 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, and 1.7. Then, Java decided "You know what, we aren't breaking backwards compatibility so instead of naming things 1.x, let's just say Java 8, 9, 10...21" I think that ultimately makes sense.
- mrweasel 3y ago
  I did not know that was the reasoning or logic behind the Java 8, 9, 10 ... numbering, that clears up so many thing.

sudhirj 3y ago

Amen to that. I get super excited about Go releases because they often add useful stuff with zero breakage of anything (just free wins all around). It's not clear that any part of the language is so broken that backward compatible changes can't fix it. Even the few foot guns like loop variable assignment have proposals that mostly preserve compatibility.

sedatk 3y ago
Interesting because I observe the opposite sentiment among .NET developers for features added in C# despite that its backwards compatibility is also fully preserved. They say “the language is getting bloated”, “it becomes harder to learn”. I totally have your perspective on this, but the difference in attitudes is noteworthy.
- sudhirj 3y ago
  I haven't used C# in over a decade, but I was already feeling that way - there's just a lot in there. Go seems to start with a default no to things, so that might be why it has a relatively small surface area.
- jerf 3y ago
  In the past ten years, here's a list of significant feature additions to the Go language itself: * Generics And even that has not been the shocking revolution some people expected; it turns out to overall be a nice little addition rather than something that rewrote what good Go was. Nothing like the Python transition to "new style" classes, or the Python 2 -> 3 transition, or the Python async ecosystem transition, and that's just one language. For the most part a Go 1.4 programmer suddenly transported to today would not find it a terribly difficult task to read code using the generics. And broadly speaking, the language didn't start with a lot of features either. Go has had a lot of library improvements, it's had a lot of tooling improvements, but the language itself is extremely stable. I've seen a few people actually complain about Go moving too fast, to which I wonder what exactly would make them happy if even Go is zooming along too quickly for them, because I honestly don't know a language moving more slowly than Go, for all the advantages and all the disadvantages that incurs. I've honestly sort of wished I could sit down with them for 15 minutes and see if I could figure out what their real problem is, or if they really are upset that there was ever a major change.

chrisdinn 3y ago

I write a lot of Go and I can’t tell you how much this warms my heart. Compatibility probably isn’t much fun for the language team, always having to keep one foot firmly in the “distant” past. But for those of us that have to maintain large Go systems it’s such a gift.

nappy-doo 3y ago
I worked on the Go compiler for a couple of years, and it wasn't a big deal. We just thought carefully about things, and dealt with a lot of rejection of ideas. If we couldn't make it fit, it wasn't right, and we'd try again. If we still couldn't make it fit, we probably didn't have a good handle on the problem, and it was right to stew on it longer. Frankly, I truly appreciated working with people who thought carefully and tried to make sure the right ideas were in. I appreciated Russ being a BDFL, Ian, Rob, and Rob. I'm glad I did it, and it made me a much better engineer.

kodra 3y ago

Interesting to see the first two comments in this thread have the opposing opinions on backward compatibility. I guess it depends on how deeply Python cut you.

deleted 3y ago
[deleted]

fullstackchris 3y ago

darn i was hoping for at least a hint or mention when Go 2 might be released... no dice

sudhirj 3y ago
Go 2 is coming out every six months as continuous Go 1.x releases.
tptacek 3y ago
The article ends with a definitive answer to that question.
euroderf 3y ago
I would expect a Go 2 to dispense with accumulated API cruft and to overhaul syntax with something radically different. But to otherwise maintain compatibility.

Joker_vD 3y ago

Ah, parsing IPs. Just how exactly was the BSD's original inet_ntoa written, I wonder? The atoi/atol and sscanf with %d/%u always parse exactly decimal integers; it would had to use either %i or strtou with 0 base to have this silly effect.

wahern 3y ago
No need to guess. My man page for inet_aton says it comes from 4.3BSD: https://github.com/dank101/4.3BSD-Reno/blob/master/lib/libc/net/inet_addr.c https://github.com/dank101/4.3BSD-Reno/blob/master/lib/libc/... The earlier inet_addr from 4.2BSD has the same logic: https://github.com/dank101/4.2BSD/blob/master/lib/libc/inet/inet_addr.c https://github.com/dank101/4.2BSD/blob/master/lib/libc/inet/... inet_aton and inet_addr parse addresses the obvious way. Using something like strtoul or especially sscanf would be stilted. The beauty of C pointers is that it makes simple parsing tasks very easy--perhaps too easy.
- Joker_vD 3y ago
  O_O They've intentionally coded it that way? This is atrocious. And this hand-rolled mess that doesn't even parse numbers correctly! It would parse "099" as 81 and "99999999999999999" as whatever it is modulo (MAX_ULONG+1), without any overflow detection. Well, at least they don't accept negative numbers, that's something. Anf mind you, beauty of C pointers has nothing to do with neither of these two bugs not the original decision to support octals and hexadecimals.
doctor_eval 3y ago
I laughed when I read that. “Back in the day” I decided to “clean up” my /etc/hosts by zero padding the quads. Anyway, the outcome was that I had to go back and remove the zeroes.

the_duke 3y ago

Never breaking compatibility is hardly a new idea. Java and C++ have invested tremendous amounts of effort into preserving backwards compatibility for decades, often requiring bending over backwards and very suboptimal designs for new features, especially in C++. But it keeps users happy. At least the ones with large old code bases. I think Rust has one of the cleanest models for this, which keeps complexity low: editions. The compiler will always support old code written against older editions, but the language can still introduce breaking changes in newer editions. Developers can either opt in to new editions and migrate their code, or do nothing, and things continue to work fine. There is seamless/transparent interoperability. Of course Rust is still pretty young, and if this model will work long term remains to be seen. For example, I imagine this causes a lot of implementation complexity in the compiler, the standard library is much more restricted and must remain stable across editions, and major overhauls probably won't be possible. But so far it has worked out really well, allowing the team to fix warts and mistakes in the language.

deleted 3y ago
[deleted]
zigzag312 3y ago
I would upvote this twice if I could. We will never break compatibility is code for "we will never fix warts and mistakes in the language".
- tptacek 3y ago
  It obviously isn't, as the text of the article repeatedly observes.
  - zigzag312 3y ago
    You are right. I haven't read the article and just assumed. It's actually about how they enabled introducing "breaking" changes without actually breaking backwards compatibility with existing code. Which is best possible outcome.
3y ago

dang 3y ago

Related: Forward Compatibility and Toolchain Management in Go 1.21 - https://news.ycombinator.com/item?id=37122932 https://news.ycombinator.com/item?id=37122932 (no comments yet, but some will probably show up)

JoshGlazebrook 3y ago

I started using Go at work ~2 years ago and I love it, especially for the backwards compatibility. But my personal projects up until then were node.js backends written with Typescript. Those personal projects are essentially stuck in time because of the whole ESM/commonjs mess that is modern javascript. Some of the npm package I use have been updated to only support ESM modules, while others will never be updated, some are half and half. It's in such a bad state that I've decided if it does ever fully break I'm just going to re-write the backend in Go, and I know I'm not the only one just frustrated with the modern javascript ecosystem and have projects stuck on old node.js and npm package versions because of it.

cookiengineer 3y ago
Babel was the most enterprise thing that could happen to the JS ecosystem. Gone are the simple distribution channels, and all build pipelines have 100s of megabytes of legacy crap that nobody actually ever executes. If you want to tell me your page is working in IE6, you're lying. It will break apart in all places. Anybody remember bower and pikapkg? That was the peak in my opinion.
- nobleach 3y ago
  Oh my.... yes. For me, that would have been Angular 1.x days. And while it was neat having a tool that could pull a deterministic flat list of dependencies, I wouldn't go back to those days. I do wholeheartedly agree that injecting core-js into every single build, in the rarest of cases that you'd need to support a browser that doesn't support generators, or some other featured added around 2015, is just plain silly. I cringe when I look at a dependency graph and see all those polyfills in my builds!!
joshstrange 3y ago
In your position I'd probably do the same thing and no doubt the ESM/commonJS mess is a mess and huge PITA. All that said I'll probably continue with my TypeScript/NodeJS backends since I just absolutely love writing TypeScript and I love sharing code between the front and backend. I use JS/TS in my day job (frontend only) as well so it's super nice to be able to benefit from that knowledge/practice. I also use TypeScript to write a few apps (some for work, some for my side project, some for personal use) so staying in the TypeScript ecosystem for almost everything I do is really nice. Again, I'm not defending that annoying/bad parts of TS and certainly not saying I've escaped the ESM/commonJS hell unscathed, just that I use TS everywhere and I generally have a lot of fun writing/running it.

jokoon 3y ago

BTW, I've read the Go GC can be disabled, but what happens if you do? Wouldn't you have to avoid memory leaks?

jeeyoungk 3y ago
If your program is short running, then it may be more efficient to disable GC and let the dying process to take care of it all.
- 0cf8612b2e1e 3y ago
  There many tales about programs foregoing any kind of memory collection and relying upon the business process itself to resolve the issue. My favorite is a missile. Evidently the program leaks memory like crazy. Solution was to determine how much memory would be required for the platform to fly to its farthest possible target + some margin. Alternatively are stock trading platforms written in Java. Disable the GC entirely because trading hours are only a a limited portion of the day. Restart the program daily.
  - hbn 3y ago
    I like to think the stock market thing is actually the reverse, and they shut it down every night because all the programs that keep it running were written in a memory-leaking tech stack that needs restarting
  - titzer 3y ago
    > My favorite is a missile. This might be apocryphal, as software for this class of embedded system almost certainly doesn't dynamically allocate anything; probably doesn't even use pools. I have a friend who works on missile software at a big defense contractor, and they do actually clean up their memory.
    - 0cf8612b2e1e 3y ago
      I found a source, quoting the quote, so provenance is what it is > This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention. [0] https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98125 https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

gavinhoward 3y ago

As a language designer, I respect the decisions they made here, including you never have a real Go 2. I'm also going to pilfer their techniques for ensuring compatibility.

mseepgood 3y ago

Since Go 2 is never going to happen, maybe it's time to rename the "Go2" label on GitHub and remove the "Go 2:" prefix in the template for language change proposals. I think this confuses people into believing that Go 2 is a thing.

ainar-g 3y ago
Based on the discussions I've seen, Go2 is considered to be the name for the process of extending the language, not an exact release version. With that said, the label seems to “work” by allowing people to first think of a backwards-incompatible way to solve a problem and then, possibly, arrive at a much more compatible solution in the process of discussion.
- mseepgood 3y ago
  > Based on the discussions I've seen, Go2 is considered to be the name for the process of extending the language, not an exact release version. I know, but many people obviously don't know that, so it might be a bad name. Just label it LanguageChange or Incompatible.
yencabulator 3y ago
Go 2 is the Zeno paradox goalpost that will never be achieved, while making continual progress toward it.

unethical_ban 3y ago

If Go 2 won't break Go 1 programs, shouldn't it be Go 1? I get not using semantic versioning for end user packages like a web browser, but for backend systems and APIs, it still makes sense. I don't see why go didn't use full semantic versioning (x.y.z) where any update that didn't break anything moved Z, new APIs or minor changes to behavior/compile such as in the article move Y, and large changes to the core language or core libraries moves X. By semantic versioning, they aren't moving off "Go 1" any time soon, no matter what it's called.

mseepgood 3y ago
> If Go 2 won't break Go 1 programs, shouldn't it be Go 1? Yes, that's what the article is saying.
- unethical_ban 3y ago
  Ah. So to phrase it differently, "There will never be a Go 2 unless marketing says we should renumber." Just stop referencing "Go 2" as if they ever think it will exist, then!
  - metaltyphoon 3y ago
    Agreed. It’s confusing as hell

w10-1 3y ago

The question for compatibility is not whether but how. And it's not really backwards: you want your code to just work, from now on. Go 1.21 offers two essential features not matched by any other language ecosystem: 1. A GODEBUG setting for each change, together with per-change opt-out and per-change metric for detecting use of the prior implementation. 2. A per-module toolchain version, together with automatic fetching of both older and newer go toolchains (deployed safely as modules) As an amazing bonus, if you specify a given version of go (e.g., 1.21.2), then when running under a newer version of go, go will automatically apply the relevant opt-out configuration so you won't get the new behavior until you ask for it. Finally, as ever you can declare things in code, in go.mod, and in environment. That basically covers all the use-cases for compatibility, from developers through deployers. Simple, and beautiful.

shakow 3y ago
> essential features not matched by any other language ecosystem > proceeds to list features abundantly common in other languages Least enthusiastic Go user.
deleted 3y ago
[deleted]
mcbrit 3y ago
Apologies, but this actually sounds like a nightmare to me, if you have at least 1-10m+ loc over enough teams, enough teams being probably 5+ depending on org boundaries. Either you support the new version or you don't is more than enough complexity to cause arbitrarily ridiculous problems, because there is a deep valley of you /think/ you support the new version and the new version thinks that it supports you but you both miss. (who wants the t-shirt saying that they have been responsible for a 1m+ code base on top of 10m+ for at least 20 years?)
- jrockway 3y ago
  If Team A requires compatibility with go 1.21, their go.mod will start with "go 1.21". Even if the code is compiled with go 1.22, their code will run unchanged, as the toolchain now treats the go version line as the toolchain to be compatible with. Similarly, if Team B requires compatibility with go 1.22 but their code is being compiled with go 1.21, go will download the 1.22 toolchain and run with that instead. It's sneaky and crazy, but so crazy it just might work. (As a user of CircleCI convenience images for a few tests suites, I appreciate this feature. When there is some security vulnerability that requires updating to go 1.21.1, I don't have to wait for Circle to build a new convenience image. I can just change go.mod and start using 1.21.1 immediately. This saves a day of telling people to ignore govulncheck.) The TL;DR is that the compiler version is now something you can declare in your go.mod file like any other dependency. If you share one go.mod file across all teams or have a One Version Policy, then there will always be work to do. No doubt there are several dedicated (in practice) employees to manage "there is a critical security release for github.com/whatever/frob@1.2.3 but the Team A's tests fail when updating to github.com/whatever/frob@1.2.4", which is inevitable at this scale.

brunojppb 3y ago

> Boring is good. Boring is stable. Boring means being able to focus on your work, not on what’s different about Go. This really resonates with me. I work with NodeJS and the JS ecosystem in general on my day job and I have to tell you, the struggle is real. The ecosystem is fragmented, everyone is doing their own thing, which is hard to make things stable. Don’t get me wrong, I still enjoy this work, but I really wish the JS ecosystem could have a stable modern foundation we could rely on.

hermanradtke 3y ago
The JS eco-system (npm, React, etc)? Sure. Let us also acknowledge that JavaScript, the language, has been prioritizing backwards compatibility before golang even existed.
- ilyt 3y ago
  Well, it is a bit easier if you have no stdlib to speak of
  - trhhowaway232 3y ago
    JS has a stdlib, there's just nothing in it.
devjab 3y ago
JavaScript is famously backwards compatible. That’s exactly why it’s the mess you describe.
afavour 3y ago
> I really wish the JS ecosystem could have a stable modern foundation we could rely on. I actually think we do now. ES modules, ES2020 code. Both supported by Node and major browsers. Node even has a built in test runner now! The problem is getting everyone up to this bar. Once we’re there I think things are going to feel a lot better. I think part of the problem is that the JS ecosystem also encompasses frontend UI work and there are so many different applications for it that multiple implementations is inevitable. Desirable, even.

mdwhatcott 3y ago

To coin a phrase, "Go 2 considered harmful" :)

deleted 3y ago
[deleted]
ainar-g 3y ago
https://github.com/golang/proposal/blob/d661ed19a203000b7c5441d2cd63a6e4b98ff2ba/design/28221-go2-transitions.md#go-2 https://github.com/golang/proposal/blob/d661ed19a203000b7c54... About five years too late, heh.
- mdwhatcott 3y ago
  I knew it was too good to have been original.

AtNightWeCode 3y ago

I suggest Go and Dart morph into one lang. Then you could use the power of Go with the more logical syntax of Dart.

rstat1 3y ago
So you want them to completely break every pre-existing Go program, for no practical benefit? That seems dumb.
- AtNightWeCode 3y ago
  No. It would only be a flag to allow obsolete Go code in practice I guess. EDIT: C++ did not break C. The people managing Go have full understanding of dependencies even though they made breaking changes.
AtNightWeCode 3y ago
Could some of the genius down-voting argue for the reason why Google needs both of these more or less dying langs?
- physicles 3y ago
  Go is dying?

parhamn 3y ago

Love this. Nothing better than coming to a go codebase and bumping the go version knowing everything will work fine. One thing I worry about is that the type system can’t get improved significantly without breaking changes in the “this was wrong and wont compile now" sense. Although I'm not sure theres interest for this stuff in the golang team at all. But there are many low hanging type system improvements in go that are major compile time robustness wins for folks, with no language additions. 1) reporting unchecked nils, might require formalizing [T, nil] | [nil, err] so err != nil guarantees T (obviously concurrent pointer access makes it tricky but thats special code with special considerations, not the 99% case) 2) unchecked array access 3) inferring types of nested struct literals. Writing nested GRPC calls is such a damn pain go, this is literally only one layer of type inference... its in the damn function signature I'm calling! 4) Exhaustive enum matches But now I'm curious, is there any interest for these changes in the golang community? None are adding "features" (like say generics) but would be huge robustness wins and seem pretty easy.

josephg 3y ago
Just to beat this drum from outside the go community, rust / swift style enums with parameters are mana from heaven. So many programs get easier to write using them. If there’s one way I’d love the go type system to be improved, it would be by adding these simple, lovely algebraic data types. Trust me, they would look great in Go. Treat yourself.
- sharno 3y ago
  It's ridiculous to me that the most popular languages from the last 20 years or more are the ones that handicapped. They have `and` types but not `or`. It sounds like a very basic logic tool that's needed for types.
- andyferris 3y ago
  I agree. If go had sum types I’d use it in a heartbeat!
- valzam 3y ago
  The irony is that Go actually does have sum types, but only for generics! type A interface { Foo | Bar | Baz } Can't use this anywhere but in generic type signatures though :(

gigatexal 3y ago

Here’s hoping they do all the wild changes they want in go 2 and keep go 1.x versions compatible with each other. That gets you the best of both worlds: legacy code can run the legacy version of go and the newer iteration of the language will break compatibility and thereby shed any tech debt and cruft as it learns from any previous mistakes or compromises.

stanleydrew 3y ago
Seems you didn't get to the end: https://go.dev/blog/compat#go2 https://go.dev/blog/compat#go2
- gigatexal 3y ago
  Oh my bad. Hmm. Well not what I wanted but probably the best choice I guess.

deagle50 3y ago

Call me when we get some sugar for `if err != nil`. The signal to noise ratio when reading Go code is not great.

assbuttbuttass 3y ago
I did some regex analysis on my codebase of over 37000 lines. In exactly 566 occurrences of "if err != nil", there were only 154 that just returned the error directly. The other instances are doing some form of wrapping to add more context to the error, or collecting errors from multiple operations, or wrapping the error with a status code, or a bunch of other things. The problem with every error handling suggestion I've seen is that it only handles the one case if err != nil { return nil, err } But that's only the case 27% of the time! The other cases are harder, and require more thought anyway. Why optimize for a rare case that's already easy?
- deagle50 3y ago
  Thanks for looking this up. I'm not just referring to blocs that just return the error, though even then your 154 occurrences lead to 462 lines of noise. Noise that could could be avoided with sugar like `?`. I'm referring to all the code blocks that start with `if err != nil {`. Wrapping and adding context could be done at the end of the previous function call and we wouldn't have to read boilerplate over and over.

iraqmtpizza 3y ago

[flagged]

vl 3y ago

Compatibility or not, but if object field of interface is set to nil, then myVar == nil should return true, unlike bizzare behavior now! Right now it's possible to get nil interface from one func, return it from another resulting in hidden cast, and this returned value fails nil check. This leads to hidden bugs, and code like this: p = makeP() if p == nil { return nil } return p and all this can be avoided by not requiring both fields of interface to be nil for successful nil check. I sure hope this will be fixed at least in 2. Also finally we got max/min. Maybe it's time for, you know, sets? Ordered_maps? Hashable slices? Ground breaking, I know.

Zamicol 3y ago

Nice article Russ.

varispeed 3y ago

Since they announced adding malware in the toolchain (sorry, khem, telemetry) I somewhat lost interest in Go. How do I know which version has spying turned on or whether this was abandoned? edit: I wonder if this was mandated by Chinese government, as certain Go tools that help circumvent censorship are written in Go and maybe government wants to know who compiles them.

ilyt 3y ago

I do hope they will eventually introduce sum types and better way of handling errors, but keeping the old code just work is frankly more important on the grander scale.

fjfuvucucuc 3y ago

[dead]

atleastoptimal 3y ago

Pokemon Go 2 the polls

davewritescode 3y ago

This is something I’ve complained about before on HN but this rings really hollow when Go 1.17 arbitrarily updated the x.509 package to suddenly stop supporting TLS hostname validation based on the CN field because it was deprecated in the X509 specification. My browser doesn’t care, why should Go?

icholy 3y ago
Found the guy who only read the title.

auxten 3y ago

Golang's forward compatibility and static compilation allow developers to quickly download and use the latest Golang release without the pain of upgrading like interpreted languages or VM-dependent languages.

sleepytimetea 3y ago

The leading zeroes in net.ParseIP change broke some of our unit tests too.