15 ms·

Proposal: Go 2 transition

206 points by piinbinary 8y ago

hiccuphippo 8y ago
Don't be Perl 6.
- bigdubs 8y ago
  https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md#perl https://github.com/golang/proposal/blob/master/design/28221-...
  - pjc50 8y ago
    Uhoh, they're still proposing to remove features. This is a terrible idea and crippled both the Perl and Python transitions. If you remove a feature and it doesn't compile existing programs, it's a new language. The automated backwards compatibility proposed might help, although it's not clear if you can mix files and libraries from different versions of the language?
    - kstrauser 8y ago
      What did Python remove?
      - jrockway 8y ago
        Many things. The linked document notes that the print statement of Python 2 was removed from Python 3, harming migration.
        ianamartin 8y ago
        The print statement to function didn't hurt migration. Nor did any of the other actual changes. What hurt the migration is a small but loud group of Python developers who think everything in the language was just fine, that not only was Python 3 unnecessary, it was actively bad and signaled a bunch of know-it-all theoretical type people from other languages coming in and taking over their own little corner of the wild west and imposing law and order where it wasn't asked for. Actually, even those people aren't what hobbled the Python migration. What made it such a mess was that the core team didn't tell that crowd to fuck right off and get with the program or get left behind. And even now with 2.7 nearing end of life, those same grumpy curmudgeons hang around web forums and reddit and blogs here and there, giving new people bad advice, complaining about how much better the old days were before unicode and async and types. I even saw someone griping about those new-fangled decorators and how monkeypatching was better. The thing that made a mess out of the transition was the core team trying too hard to coax people who didn't want to move into coming along with them with a small bucket of carrots and no sticks. They tried to pull the bandaid off slowly and it took too long and still hurt like hell.
        kstrauser 8y ago
        I couldn't agree more. There was a huge amount of wailing that, for instance, Python 3 suddenly made devs care about the difference between text and bytes, when Python 2 had let them happily write broken code without complaining. Yes, you have to write correct code now. Yes, this requires changing some stuff. But yes, this is better for everyone in the (not so) long run.
        orangecat 8y ago
        The Python 3 transition has taken 10+ years and millions of developer-hours. It is perfectly reasonable to question whether the benefits have been worth the costs, especially when compared to other platforms like JavaScript that have made much greater advancements during that time.
      - hathawsh 8y ago
        See the release notes of Python 3.0: https://docs.python.org/3.0/whatsnew/3.0.html#removed-syntax https://docs.python.org/3.0/whatsnew/3.0.html#removed-syntax The removals were actually an easier pill to swallow than the numerous subtle changes in behavior introduced by the big, deep switch to Unicode. I'm over it now, but that was painful!
      - rraval 8y ago
        This is my attempt to be sympathetic to the GP's point of view, perhaps they have a different example in mind. One example comes from the new-style / old-style classes distinction and the method resolution order when considering multiple inheritance. Python 2.3 introduced "new-style" classes which inherit from `object` and use the C3 resolution algorithm [1]. For backwards compatibility reasons, "old-style" classes without an explicit `object` base class still used the old method resolution semantics. Python 3 does away with "old-style" classes entirely and all classes must use the "new-style" semantics. There's presumably a ton of code that doesn't specify `object` as an explicit base class, and thus may have subtle broken behaviour under "new-style". Given Python 3's inability / unwillingness to simulate the old behaviour, I'm unaware of any tool that's able to rewrite Python 2 to 3 in a bullet proof fashion [2]. This is not the same kind of breakage that other people mention, like `print` being a function or `reduce` being moved to `functools`. Those are simply backwards incompatible "movements", not outright removals, and thus can be rewritten by automated tools. [1] https://www.python.org/download/releases/2.3/mro/ https://www.python.org/download/releases/2.3/mro/ [2] https://portingguide.readthedocs.io/en/latest/classes.html#new-style-classes https://portingguide.readthedocs.io/en/latest/classes.html#n...
      - yammajr 8y ago
        maybe not removed, but they certainly did make breaking changes to the language. here are some of the most obvious python 2: print "foo" # foo 3 / 5 # 0 apply # <built-in function apply> python 3: print "foo" # SyntaxError: Missing parentheses in call to 'print' 3 / 5 # 0.6 apply # NameError: name 'apply' is not defined
        stcredzero 8y ago
        These are precisely the kind of changes one would make to a language if you wanted to cause as much pain as possible. (I say this as someone who has been paid to write a syntax-driven code rewriting tool to go from one language version to another.)
        shaklee3 8y ago
        But at the same time, f-strings are soooo much better than the old way, or even .format().
      - bobbyi_settv 8y ago
        For one, it removed the ability to do % formatting with bytes objects. When working with a wire protocol like ssh, you need to work with sequences of bytes, not Unicode strings, and porting code that assembled them using % formatting was a huge pain; I tried and failed to port paramiko to python 3.
        minitech 8y ago
        You might already be aware, but %-formatting with bytes is back as of 3.5.
    - TheDong 8y ago
      There's a distinct difference. python3 code cannot import python2 libraries. That split the ecosystem. Go intends for a go2 library to be able to import and use a go1 library. This means there isn't a split in the ecosystem at any point in time. It's fine to remove a feature as long as old programs still build because you must opt in to the removal via setting "version=go2" or whatever in go.mod. This is distinctly different from being the perl and python transitions because the new compiler can still build old code, including with removed features, until you opt into the new language version.. and even once you do opt in, all your dependencies are fine whether they have opted in or not.
      - muraiki 8y ago
        You can actually use Perl 5 and even Python code in Perl 6.
    - jrockway 8y ago
      They do propose that, but with caveats. They mention removing string(i) in, say go 1.20. If a module notes that the maximum version of go that the module works with is 1.19 (because it uses that feature), then the 1.20 compiler can compile that module in go language 1.19 mode. Thus you can use 1.20 features in your module and still depend on the module that uses the deprecated syntax, because the go compiler can still operate on that old code. This is different from python 3 because python 3 cannot run python 2 code, even if told that some library is python 2. That is where the migration pain came from.
      - mdpye 8y ago
        I'm unconvinced by the max-version part, I can't see how it doesn't require either A) being overly restrictive, and declaring the current released version as your max, breaking for a short time on each new lang version B) being psychic, and knowing when (without the aid of semver) your package might break An unmaintained package will not be updated with the max flag when the breakage occurs. Any package always declaring the current version will have to be updated for every new release. Both seem like a lot of admin. I know using unmaintained packages isn't ideal in the first place, but it happens, and packages exist that are pretty much "finished" and very light on bugs, if they were stable and heavily exercised for some time before losing their maintainers.
        bdhess 8y ago
        The breakage you describe in A) shouldn't happen according to the proposal. The compiler for toolchain version X+1 should still be able to compile code that is language version X.
        chc 8y ago
        An unmaintained package doesn't need new features from then-future versions of Go, so it's fine if you declare the current version as your max. It doesn't break in the new version, it just doesn't have access to features introduced after the max version.
        8y ago
- lizmat 8y ago
  Always make new mistakes :-)
deleted 8y ago
[deleted]
ilovecaching 8y ago
If you're frustrated by the lack of a strong type system in Go then check out Rust. Rust has type parameters and type constraints that let you write generic code. The authors have also been super attentive to the good parts of Go. Rust has great tooling through Cargo, it has rustfmt for formatting, rls for language server support. Rust also adds real sum types and a tuple type. Multi-value returns are just tuples, they aren't a special case of the semantics. Result types let you avoid writing if err != nil everywhere, but we still believe in the mantra of not panicking for things that are not truly exceptional. Rust is also closer to C++s performance, and it's a strongly community driven project. We also have great concurrency primitives. We have channels, but we also have futures, which can be scheduled on green threads in a CSP style just like Go, or can be run behind the Actor model, using async/await syntax with polling... there's a lot more flexibility there to align the language to your business needs.
- rhodysurf 8y ago
  So I am a C++ dev by day and I write some go and rust for side projects or smaller projects at work. Go is SOOOOOO much simpler to write (unless you get into crazy threading data race stuff) than rust. I like rust (a lot), but the mental load is a lot more to take on than go.
  - steveklabnik 8y ago
    An interesting comparison between experiences is that people describe Rust as having a lot of mental load at first, but eventually as having way less, since the compiler does so much for you. On the topic of the original thread, I wonder why Rust wasn’t included; maybe it’s because our first release that’s achieving similar goals is happening six weeks from now, and they wanted to see how things played out in practice, not in theory.
    - rhodysurf 8y ago
      Yeah I agree that as I learned rust I got used to it and became slowly more productive. But I am still nowhere near as fast to accomplish things with it as I am with modern C++ or go or swift.
pjmlp 8y ago
The proposal document seems to be quite good.
deleted 8y ago
[deleted]
wildchild 8y ago
They are too toxic to bother.
deleted 8y ago
[deleted]
TheDong 8y ago
I'm surprised there's no reference to rust epochs [0]. Sure, they haven't seen use in the wild to learn lessons from in that regard, but they're a very well thought out solution to an effectively identical problem. They both ended up with very similar results (define a version in cargo.toml/go.mod, use that version of the language to build), but there's also more to it than that, and the rust proposal could help guide discussion of other possible issues too. [0]: https://github.com/rust-lang/rfcs/pull/2052 https://github.com/rust-lang/rfcs/pull/2052
- steveklabnik 8y ago
  (They’re called “editions” now, by the way https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html )
- Thaxll 8y ago
  I'm not sure it's wise to talk about Rust in those discussions, Rust is the language that needs nightly for a lot of recent libraries to work... talking about stability / backward compatibility.
  - steveklabnik 8y ago
    Which libraries are you talking about? Empirically, the majority of Rust users use stable. Additionally, the nightly/stable split exists to serve exactly this problem; if you need stability, you use stable, and the need for nightly drops each and every release.
    - Thaxll 8y ago
      I think the most popular web framework is rocket.rs, it needs nightly. That's latest example I have, honestly when I looked a year ago others libraries were using nightly.
      - dx87 8y ago
        Why would you tell people that the recent libraries require nightly, when you admit that you haven't even looked at the library ecosystem in the past year? I honestly don't get the motivation that would make you want to come here just to post lies about a programming language.
AnimalMuppet 8y ago
The conclusion? > A real Go 2 would, perhaps unsurprisingly, be harmful. Nicely done!
wwarner 8y ago
Imma say here that while perl5->perl6 transition didn't work out very well, the perl4->perl5 transition was hugely successful. Back to Go!
- setquk 8y ago
  I think that was mostly because Perl pretty much died about the same time.
  - ryl00 8y ago
    Reports of perl's death are greatly exaggerated.
    - brokencode 8y ago
      It’s fun to use that quote, but is it actually true? At one time, Perl was extremely popular, and was basically the Python of its era. Now, I barely ever hear about it, and it mainly seems to be used as a cautionary example of what can happen to a language when it goes through a major update.
      - labster 8y ago
        Yes, it is actually true. Both Perls have a regular release cycle, and continue to be used in companies around the world. The amount of developers isn't really growing for Perl 5, but it's not really shrinking either. eBay isn't dead just because Amazon and Ali became the dominant players, nor is Perl dead because Python and JS overtook it. The market just got larger. Also, please try Perl 6. The marketing may be a cautionary example, but the language itself reflects 15 years of polish.
        setquk 8y ago
        I’m not sure that is the case. I know a lot of Perl developers who jumped ship. Including me. While I respect that Perl development is still going, I haven’t seen it used by anyone in production for at least 15 years.
the_other_guy 8y ago
I don't understand why it is so hard to add enums for example, Golang authors are fiercely defiant to adding many small essential features. I understand that they worship the statement "simple is beautiful", but they took the statement to a whole another unprecedentedly stupid level. And even after all the resistance towards generics, dependency management and error handling, they are trying to fix them very late and probably not through a good way [Edit] whoa! until 4 minutes ago this comment was +6 and now it's -1, I am sure these are purely uncoordinated downvotes, sums up the hostility in the Golang community towards any kind of improvement or even the slightest shred of criticism, even though I use Golang heavily and I don't actually hate it, I really don't understand this hostility everywhere online (github, HN, reddit, etc...) [Edit2] mass downvotes, still ZERO explanation. Typical golang "fans"
- tptacek 8y ago
  This has in fact nothing to do with the story itself.
- shizcakes 8y ago
  Explanation: your comment was unnecessary hostile itself (“unprecedentedly stupid level”), and folks are following the time honored tradition of downvoting and moving along. It really looks like you’re trying to pick a fight. It’s cool if you want enums. I miss them too. That’s not the problem here.
  - the_other_guy 8y ago
    The enum thing was just an example, that wasn't even the main point of my comment
- atombender 8y ago
  There are proposals to add enums to Go [1]. Enums are specific instance of sum types (aka discriminated unions), and while having simple typed enums would be nice, Go would benefit, in my opinion, from having true sum types, and this has also been proposed [2]. Unfortunately, due to Go's current semantics (e.g. zero values) and memory layout, adding sum types is not as straightforward as one might hope [3]. However, given that Go2 is allowed to break backwards compatibility, something might come out of the discussion. [1] https://github.com/golang/go/issues/19814 https://github.com/golang/go/issues/19814 [2] https://github.com/golang/go/issues/19412 https://github.com/golang/go/issues/19412 [3] https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d03t6ji/?st=ixp2gf04&sh=7d6920db https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...
Jach 8y ago
PHP: Good 4->5 transition, they almost made the Python 3 mistake with PHP 6, but sanely dropped it and the PHP 5 -> 7 seems to be going along nicely... JS is looking a lot like the C++ story. Totally different language.
- shabbyrobe 8y ago
  The 5 -> 7 transition was great from the point of view of someone writing PHP, but it was significantly more painful for extension writers. The only way I could update my stuff was with many hours of careful spelunking through the PHP source looking for examples of the new APIs, then many more hours of fun with valgrind working out all of the ZVAL indirection and zend_parse_parameters changes I'd missed. I'm fine with the burden of the upgrade being transferred to users of the C API - that seemed like a very astute trade to me - but the process could've been made a lot easier with a proper upgrade guide rather than a few hasty, incomplete notes in the wiki.
vorg 8y ago
There seem to be a few standard ways to evolve to the next major version of a programming language: (1) Announce the next major version to be far off into the future, and say it will be as backwards compatible as possible to keep developers supporting the old version, e.g. Go 1->2. (2) Build next version to be a little different to current version, provide no facility for interoperating between versions, then expect developers to switch over because of the branding, e.g. Python 2->3. (3) Announce next version to be far off into the future, and say it will be a totally different language and expect developers to switch because of the branding, e.g. Perl 5->6. (4) Don't announce or build a new major version, and keep profiting from developers using the current version for as long as possible, e.g. Java 1.x. (5) Announce next version to be very soon, but delay it for as long as possible with unofficial roadblocks and keep profiting from developers using the old version for as long as possible, e.g. Apache Groovy 2->3.
- justinator 8y ago
  Oh Perl 5-6 interopability was actualy promised at the very beginning - it was framed as "automatic translation" I think the problem that can't be dolved is only perl 5 can parse perl 5! There's other projects to make this happen (like: use v5;) Calling a Perl 5 module from Perl 6 can work I believe ( as well as other languages!), which is somewhat of a miracle. But it's interfaced using Perl 6.
  - lizmat 8y ago
    To elaborate a bit on this: the 'use v5' project is pretty much dead at this point in time. (see also my open letter to the Perl community: https://www.perl.com/article/an-open-letter-to-the-perl-community/ https://www.perl.com/article/an-open-letter-to-the-perl-comm... ) To call Perl 5 code from Perl 6, we currently have Inline::Perl5 (https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE): > Supports Perl 5 modules including XS modules. Allows passing integers, strings, arrays, hashes, code references, file handles and objects between Perl 5 and Perl 6. Also supports calling methods on Perl 5 objects from Perl 6 and calling methods on Perl 6 objects from Perl 5 and subclass Perl 5 classes in Perl 6. In a similar vein, there are Inline::Python (https://github.com/niner/Inline-Python/blob/master/README.md https://github.com/niner/Inline-Python/blob/master/README.md) and other Inline modules (https://modules.perl6.org/search/?q=Inline https://modules.perl6.org/search/?q=Inline ) that can be called from Perl 6.
throwaway487548 8y ago
Yes, --lang= or --std= would do the job. Even crosslinking should be easy since object code is the same.
- bmn__ 8y ago
  This is how e.g. C/C++ does it, this design is a mistake. The version information should be attached to the source code, not the compiler invocation. It is pointless to compile source code of a certain version (e.g. C++17) with the wrong options switch.
xte 8y ago
IMVHO things changes, hopefully for good, so give time and advise far before etc is a needed and good practice but evolution must happen so if someone have problem keeping up with reasonable time it means someone do have a problem, not a thing Go developer can fix or slow evolution because of that. We all know how bad evolution is in commercial world, force evolution is a need. Software is not a product, can't last forever untouched.
iofiiiiiiiii 8y ago
Wow, that is a long piece of text. Can someone TLDR the actual conclusion from out of that verbosity?
lazyjones 8y ago
I like this proposal. For unmaintained code that needs fixing when incompatible changes are introduced, I wouldn’t make the toolchain increasingly complex though. It‘d be better to just fork it and have it fixed by volunteers (or bots!), then put in some canonical location (e.g. github.com/go2compat/oldhost.org/olddir/...) so developers can just try to change the include path as a standard solution on such compile errors. This is more feasible now than 15 years ago since even unmaintained code is usually public on github or similar. It would help to break as few things as possible in this case, but that seems to be the intention anyway.
Jabbles 8y ago
I'm not sure how this would work for changes that would affect a whole program. For instance, say Go wanted to introduce a moving GC, and say that required removing interfaces as map keys. How could a function that returned a map[interface{}]int in one module be called from another that was compiled with a later version of Go? Would the whole program would have to be compiled with the non-moving GC? Perhaps the answer is that Go would never introduce such a change.
- ainar-g 8y ago
  Go doesn't have a stable ABI, AFAIK, so what (probably) actually going to happen is that the same Go 2 compiler will compile both Go 1 and Go 2 packages using the same runtime.
  - Jabbles 8y ago
    But that would prevent the Go 2 compiler from using the given improvement to the runtime (i.e. moving GC).
- cdoxsey 8y ago
  For this particular case they thought ahead and require implementations to work with a GC that might move pointers. You run into it with cgo, which, as a result, has quite arcane rules for passing data between the two: https://golang.org/cmd/cgo/#hdr-Passing_pointers https://golang.org/cmd/cgo/#hdr-Passing_pointers Like with randomizing hashmap keys, they randomly enforce the rule to make sure that no one relies on it just happening to work since Go's GC doesn't currently move pointers.
  - Jabbles 8y ago
    I don't understand - as you say, cgo requires extra rules. Are you suggesting that extra rules will apply every time you cross a particular Go version boundary? This proposal doesn't seem to suggest that.
    - cdoxsey 8y ago
kiallmacinnes 8y ago
150 comments, and nobody is mentioning the maximum version thing? Am I alone in thinking that's a terrible idea, that having module authors around the globe define a maximum version is going to result in masses of libraries pinned needlessly to old versions, and masses of unmaintained but otherwise solid and complete libs unpinned, despite them now needing a maximum version pin?
- ianlancetaylor 8y ago
  Remember that they are only pinned to an old language version. They will still work fine with new release of Go, they will just be built with the old language semantics. So what's the harm? I agree that unmaintained libraries that don't adapt to modules could be a problem. We'll have to see what happens.

206 points by piinbinary 8y ago

hiccuphippo 8y ago

Don't be Perl 6.

bigdubs 8y ago
https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md#perl https://github.com/golang/proposal/blob/master/design/28221-...
- pjc50 8y ago
  Uhoh, they're still proposing to remove features. This is a terrible idea and crippled both the Perl and Python transitions. If you remove a feature and it doesn't compile existing programs, it's a new language. The automated backwards compatibility proposed might help, although it's not clear if you can mix files and libraries from different versions of the language?
  - kstrauser 8y ago
    What did Python remove?
    - jrockway 8y ago
      Many things. The linked document notes that the print statement of Python 2 was removed from Python 3, harming migration.
      - ianamartin 8y ago
        The print statement to function didn't hurt migration. Nor did any of the other actual changes. What hurt the migration is a small but loud group of Python developers who think everything in the language was just fine, that not only was Python 3 unnecessary, it was actively bad and signaled a bunch of know-it-all theoretical type people from other languages coming in and taking over their own little corner of the wild west and imposing law and order where it wasn't asked for. Actually, even those people aren't what hobbled the Python migration. What made it such a mess was that the core team didn't tell that crowd to fuck right off and get with the program or get left behind. And even now with 2.7 nearing end of life, those same grumpy curmudgeons hang around web forums and reddit and blogs here and there, giving new people bad advice, complaining about how much better the old days were before unicode and async and types. I even saw someone griping about those new-fangled decorators and how monkeypatching was better. The thing that made a mess out of the transition was the core team trying too hard to coax people who didn't want to move into coming along with them with a small bucket of carrots and no sticks. They tried to pull the bandaid off slowly and it took too long and still hurt like hell.
        kstrauser 8y ago
        I couldn't agree more. There was a huge amount of wailing that, for instance, Python 3 suddenly made devs care about the difference between text and bytes, when Python 2 had let them happily write broken code without complaining. Yes, you have to write correct code now. Yes, this requires changing some stuff. But yes, this is better for everyone in the (not so) long run.
        orangecat 8y ago
        The Python 3 transition has taken 10+ years and millions of developer-hours. It is perfectly reasonable to question whether the benefits have been worth the costs, especially when compared to other platforms like JavaScript that have made much greater advancements during that time.
    - hathawsh 8y ago
      See the release notes of Python 3.0: https://docs.python.org/3.0/whatsnew/3.0.html#removed-syntax https://docs.python.org/3.0/whatsnew/3.0.html#removed-syntax The removals were actually an easier pill to swallow than the numerous subtle changes in behavior introduced by the big, deep switch to Unicode. I'm over it now, but that was painful!
    - rraval 8y ago
      This is my attempt to be sympathetic to the GP's point of view, perhaps they have a different example in mind. One example comes from the new-style / old-style classes distinction and the method resolution order when considering multiple inheritance. Python 2.3 introduced "new-style" classes which inherit from `object` and use the C3 resolution algorithm [1]. For backwards compatibility reasons, "old-style" classes without an explicit `object` base class still used the old method resolution semantics. Python 3 does away with "old-style" classes entirely and all classes must use the "new-style" semantics. There's presumably a ton of code that doesn't specify `object` as an explicit base class, and thus may have subtle broken behaviour under "new-style". Given Python 3's inability / unwillingness to simulate the old behaviour, I'm unaware of any tool that's able to rewrite Python 2 to 3 in a bullet proof fashion [2]. This is not the same kind of breakage that other people mention, like `print` being a function or `reduce` being moved to `functools`. Those are simply backwards incompatible "movements", not outright removals, and thus can be rewritten by automated tools. [1] https://www.python.org/download/releases/2.3/mro/ https://www.python.org/download/releases/2.3/mro/ [2] https://portingguide.readthedocs.io/en/latest/classes.html#new-style-classes https://portingguide.readthedocs.io/en/latest/classes.html#n...
    - yammajr 8y ago
      maybe not removed, but they certainly did make breaking changes to the language. here are some of the most obvious python 2: print "foo" # foo 3 / 5 # 0 apply # <built-in function apply> python 3: print "foo" # SyntaxError: Missing parentheses in call to 'print' 3 / 5 # 0.6 apply # NameError: name 'apply' is not defined
      - stcredzero 8y ago
        These are precisely the kind of changes one would make to a language if you wanted to cause as much pain as possible. (I say this as someone who has been paid to write a syntax-driven code rewriting tool to go from one language version to another.)
      - shaklee3 8y ago
        But at the same time, f-strings are soooo much better than the old way, or even .format().
    - bobbyi_settv 8y ago
      For one, it removed the ability to do % formatting with bytes objects. When working with a wire protocol like ssh, you need to work with sequences of bytes, not Unicode strings, and porting code that assembled them using % formatting was a huge pain; I tried and failed to port paramiko to python 3.
      - minitech 8y ago
        You might already be aware, but %-formatting with bytes is back as of 3.5.
  - TheDong 8y ago
    There's a distinct difference. python3 code cannot import python2 libraries. That split the ecosystem. Go intends for a go2 library to be able to import and use a go1 library. This means there isn't a split in the ecosystem at any point in time. It's fine to remove a feature as long as old programs still build because you must opt in to the removal via setting "version=go2" or whatever in go.mod. This is distinctly different from being the perl and python transitions because the new compiler can still build old code, including with removed features, until you opt into the new language version.. and even once you do opt in, all your dependencies are fine whether they have opted in or not.
    - muraiki 8y ago
      You can actually use Perl 5 and even Python code in Perl 6.
  - jrockway 8y ago
    They do propose that, but with caveats. They mention removing string(i) in, say go 1.20. If a module notes that the maximum version of go that the module works with is 1.19 (because it uses that feature), then the 1.20 compiler can compile that module in go language 1.19 mode. Thus you can use 1.20 features in your module and still depend on the module that uses the deprecated syntax, because the go compiler can still operate on that old code. This is different from python 3 because python 3 cannot run python 2 code, even if told that some library is python 2. That is where the migration pain came from.
    - mdpye 8y ago
      I'm unconvinced by the max-version part, I can't see how it doesn't require either A) being overly restrictive, and declaring the current released version as your max, breaking for a short time on each new lang version B) being psychic, and knowing when (without the aid of semver) your package might break An unmaintained package will not be updated with the max flag when the breakage occurs. Any package always declaring the current version will have to be updated for every new release. Both seem like a lot of admin. I know using unmaintained packages isn't ideal in the first place, but it happens, and packages exist that are pretty much "finished" and very light on bugs, if they were stable and heavily exercised for some time before losing their maintainers.
      - bdhess 8y ago
        The breakage you describe in A) shouldn't happen according to the proposal. The compiler for toolchain version X+1 should still be able to compile code that is language version X.
      - chc 8y ago
        An unmaintained package doesn't need new features from then-future versions of Go, so it's fine if you declare the current version as your max. It doesn't break in the new version, it just doesn't have access to features introduced after the max version.
        8y ago
lizmat 8y ago
Always make new mistakes :-)

deleted 8y ago

[deleted]

ilovecaching 8y ago

If you're frustrated by the lack of a strong type system in Go then check out Rust. Rust has type parameters and type constraints that let you write generic code. The authors have also been super attentive to the good parts of Go. Rust has great tooling through Cargo, it has rustfmt for formatting, rls for language server support. Rust also adds real sum types and a tuple type. Multi-value returns are just tuples, they aren't a special case of the semantics. Result types let you avoid writing if err != nil everywhere, but we still believe in the mantra of not panicking for things that are not truly exceptional. Rust is also closer to C++s performance, and it's a strongly community driven project. We also have great concurrency primitives. We have channels, but we also have futures, which can be scheduled on green threads in a CSP style just like Go, or can be run behind the Actor model, using async/await syntax with polling... there's a lot more flexibility there to align the language to your business needs.

rhodysurf 8y ago
So I am a C++ dev by day and I write some go and rust for side projects or smaller projects at work. Go is SOOOOOO much simpler to write (unless you get into crazy threading data race stuff) than rust. I like rust (a lot), but the mental load is a lot more to take on than go.
- steveklabnik 8y ago
  An interesting comparison between experiences is that people describe Rust as having a lot of mental load at first, but eventually as having way less, since the compiler does so much for you. On the topic of the original thread, I wonder why Rust wasn’t included; maybe it’s because our first release that’s achieving similar goals is happening six weeks from now, and they wanted to see how things played out in practice, not in theory.
  - rhodysurf 8y ago
    Yeah I agree that as I learned rust I got used to it and became slowly more productive. But I am still nowhere near as fast to accomplish things with it as I am with modern C++ or go or swift.

pjmlp 8y ago

The proposal document seems to be quite good.

deleted 8y ago

[deleted]

wildchild 8y ago

They are too toxic to bother.

deleted 8y ago

[deleted]

TheDong 8y ago

I'm surprised there's no reference to rust epochs [0]. Sure, they haven't seen use in the wild to learn lessons from in that regard, but they're a very well thought out solution to an effectively identical problem. They both ended up with very similar results (define a version in cargo.toml/go.mod, use that version of the language to build), but there's also more to it than that, and the rust proposal could help guide discussion of other possible issues too. [0]: https://github.com/rust-lang/rfcs/pull/2052 https://github.com/rust-lang/rfcs/pull/2052

steveklabnik 8y ago
(They’re called “editions” now, by the way https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html )
Thaxll 8y ago
I'm not sure it's wise to talk about Rust in those discussions, Rust is the language that needs nightly for a lot of recent libraries to work... talking about stability / backward compatibility.
- steveklabnik 8y ago
  Which libraries are you talking about? Empirically, the majority of Rust users use stable. Additionally, the nightly/stable split exists to serve exactly this problem; if you need stability, you use stable, and the need for nightly drops each and every release.
  - Thaxll 8y ago
    I think the most popular web framework is rocket.rs, it needs nightly. That's latest example I have, honestly when I looked a year ago others libraries were using nightly.
    - dx87 8y ago
      Why would you tell people that the recent libraries require nightly, when you admit that you haven't even looked at the library ecosystem in the past year? I honestly don't get the motivation that would make you want to come here just to post lies about a programming language.

AnimalMuppet 8y ago

The conclusion? > A real Go 2 would, perhaps unsurprisingly, be harmful. Nicely done!

wwarner 8y ago

Imma say here that while perl5->perl6 transition didn't work out very well, the perl4->perl5 transition was hugely successful. Back to Go!

setquk 8y ago
I think that was mostly because Perl pretty much died about the same time.
- ryl00 8y ago
  Reports of perl's death are greatly exaggerated.
  - brokencode 8y ago
    It’s fun to use that quote, but is it actually true? At one time, Perl was extremely popular, and was basically the Python of its era. Now, I barely ever hear about it, and it mainly seems to be used as a cautionary example of what can happen to a language when it goes through a major update.
    - labster 8y ago
      Yes, it is actually true. Both Perls have a regular release cycle, and continue to be used in companies around the world. The amount of developers isn't really growing for Perl 5, but it's not really shrinking either. eBay isn't dead just because Amazon and Ali became the dominant players, nor is Perl dead because Python and JS overtook it. The market just got larger. Also, please try Perl 6. The marketing may be a cautionary example, but the language itself reflects 15 years of polish.
      - setquk 8y ago
        I’m not sure that is the case. I know a lot of Perl developers who jumped ship. Including me. While I respect that Perl development is still going, I haven’t seen it used by anyone in production for at least 15 years.

the_other_guy 8y ago

I don't understand why it is so hard to add enums for example, Golang authors are fiercely defiant to adding many small essential features. I understand that they worship the statement "simple is beautiful", but they took the statement to a whole another unprecedentedly stupid level. And even after all the resistance towards generics, dependency management and error handling, they are trying to fix them very late and probably not through a good way [Edit] whoa! until 4 minutes ago this comment was +6 and now it's -1, I am sure these are purely uncoordinated downvotes, sums up the hostility in the Golang community towards any kind of improvement or even the slightest shred of criticism, even though I use Golang heavily and I don't actually hate it, I really don't understand this hostility everywhere online (github, HN, reddit, etc...) [Edit2] mass downvotes, still ZERO explanation. Typical golang "fans"

tptacek 8y ago
This has in fact nothing to do with the story itself.
shizcakes 8y ago
Explanation: your comment was unnecessary hostile itself (“unprecedentedly stupid level”), and folks are following the time honored tradition of downvoting and moving along. It really looks like you’re trying to pick a fight. It’s cool if you want enums. I miss them too. That’s not the problem here.
- the_other_guy 8y ago
  The enum thing was just an example, that wasn't even the main point of my comment
atombender 8y ago
There are proposals to add enums to Go [1]. Enums are specific instance of sum types (aka discriminated unions), and while having simple typed enums would be nice, Go would benefit, in my opinion, from having true sum types, and this has also been proposed [2]. Unfortunately, due to Go's current semantics (e.g. zero values) and memory layout, adding sum types is not as straightforward as one might hope [3]. However, given that Go2 is allowed to break backwards compatibility, something might come out of the discussion. [1] https://github.com/golang/go/issues/19814 https://github.com/golang/go/issues/19814 [2] https://github.com/golang/go/issues/19412 https://github.com/golang/go/issues/19412 [3] https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d03t6ji/?st=ixp2gf04&sh=7d6920db https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...

Jach 8y ago

PHP: Good 4->5 transition, they almost made the Python 3 mistake with PHP 6, but sanely dropped it and the PHP 5 -> 7 seems to be going along nicely... JS is looking a lot like the C++ story. Totally different language.

shabbyrobe 8y ago
The 5 -> 7 transition was great from the point of view of someone writing PHP, but it was significantly more painful for extension writers. The only way I could update my stuff was with many hours of careful spelunking through the PHP source looking for examples of the new APIs, then many more hours of fun with valgrind working out all of the ZVAL indirection and zend_parse_parameters changes I'd missed. I'm fine with the burden of the upgrade being transferred to users of the C API - that seemed like a very astute trade to me - but the process could've been made a lot easier with a proper upgrade guide rather than a few hasty, incomplete notes in the wiki.

vorg 8y ago

There seem to be a few standard ways to evolve to the next major version of a programming language: (1) Announce the next major version to be far off into the future, and say it will be as backwards compatible as possible to keep developers supporting the old version, e.g. Go 1->2. (2) Build next version to be a little different to current version, provide no facility for interoperating between versions, then expect developers to switch over because of the branding, e.g. Python 2->3. (3) Announce next version to be far off into the future, and say it will be a totally different language and expect developers to switch because of the branding, e.g. Perl 5->6. (4) Don't announce or build a new major version, and keep profiting from developers using the current version for as long as possible, e.g. Java 1.x. (5) Announce next version to be very soon, but delay it for as long as possible with unofficial roadblocks and keep profiting from developers using the old version for as long as possible, e.g. Apache Groovy 2->3.

justinator 8y ago
Oh Perl 5-6 interopability was actualy promised at the very beginning - it was framed as "automatic translation" I think the problem that can't be dolved is only perl 5 can parse perl 5! There's other projects to make this happen (like: use v5;) Calling a Perl 5 module from Perl 6 can work I believe ( as well as other languages!), which is somewhat of a miracle. But it's interfaced using Perl 6.
- lizmat 8y ago
  To elaborate a bit on this: the 'use v5' project is pretty much dead at this point in time. (see also my open letter to the Perl community: https://www.perl.com/article/an-open-letter-to-the-perl-community/ https://www.perl.com/article/an-open-letter-to-the-perl-comm... ) To call Perl 5 code from Perl 6, we currently have Inline::Perl5 (https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE): > Supports Perl 5 modules including XS modules. Allows passing integers, strings, arrays, hashes, code references, file handles and objects between Perl 5 and Perl 6. Also supports calling methods on Perl 5 objects from Perl 6 and calling methods on Perl 6 objects from Perl 5 and subclass Perl 5 classes in Perl 6. In a similar vein, there are Inline::Python (https://github.com/niner/Inline-Python/blob/master/README.md https://github.com/niner/Inline-Python/blob/master/README.md) and other Inline modules (https://modules.perl6.org/search/?q=Inline https://modules.perl6.org/search/?q=Inline ) that can be called from Perl 6.

throwaway487548 8y ago

Yes, --lang= or --std= would do the job. Even crosslinking should be easy since object code is the same.

bmn__ 8y ago
This is how e.g. C/C++ does it, this design is a mistake. The version information should be attached to the source code, not the compiler invocation. It is pointless to compile source code of a certain version (e.g. C++17) with the wrong options switch.

xte 8y ago

IMVHO things changes, hopefully for good, so give time and advise far before etc is a needed and good practice but evolution must happen so if someone have problem keeping up with reasonable time it means someone do have a problem, not a thing Go developer can fix or slow evolution because of that. We all know how bad evolution is in commercial world, force evolution is a need. Software is not a product, can't last forever untouched.

iofiiiiiiiii 8y ago

Wow, that is a long piece of text. Can someone TLDR the actual conclusion from out of that verbosity?

lazyjones 8y ago

I like this proposal. For unmaintained code that needs fixing when incompatible changes are introduced, I wouldn’t make the toolchain increasingly complex though. It‘d be better to just fork it and have it fixed by volunteers (or bots!), then put in some canonical location (e.g. github.com/go2compat/oldhost.org/olddir/...) so developers can just try to change the include path as a standard solution on such compile errors. This is more feasible now than 15 years ago since even unmaintained code is usually public on github or similar. It would help to break as few things as possible in this case, but that seems to be the intention anyway.

Jabbles 8y ago

I'm not sure how this would work for changes that would affect a whole program. For instance, say Go wanted to introduce a moving GC, and say that required removing interfaces as map keys. How could a function that returned a map[interface{}]int in one module be called from another that was compiled with a later version of Go? Would the whole program would have to be compiled with the non-moving GC? Perhaps the answer is that Go would never introduce such a change.

ainar-g 8y ago
Go doesn't have a stable ABI, AFAIK, so what (probably) actually going to happen is that the same Go 2 compiler will compile both Go 1 and Go 2 packages using the same runtime.
- Jabbles 8y ago
  But that would prevent the Go 2 compiler from using the given improvement to the runtime (i.e. moving GC).
cdoxsey 8y ago
For this particular case they thought ahead and require implementations to work with a GC that might move pointers. You run into it with cgo, which, as a result, has quite arcane rules for passing data between the two: https://golang.org/cmd/cgo/#hdr-Passing_pointers https://golang.org/cmd/cgo/#hdr-Passing_pointers Like with randomizing hashmap keys, they randomly enforce the rule to make sure that no one relies on it just happening to work since Go's GC doesn't currently move pointers.
- Jabbles 8y ago
  I don't understand - as you say, cgo requires extra rules. Are you suggesting that extra rules will apply every time you cross a particular Go version boundary? This proposal doesn't seem to suggest that.
  - cdoxsey 8y ago

kiallmacinnes 8y ago

150 comments, and nobody is mentioning the maximum version thing? Am I alone in thinking that's a terrible idea, that having module authors around the globe define a maximum version is going to result in masses of libraries pinned needlessly to old versions, and masses of unmaintained but otherwise solid and complete libs unpinned, despite them now needing a maximum version pin?

ianlancetaylor 8y ago
Remember that they are only pinned to an old language version. They will still work fine with new release of Go, they will just be built with the old language semantics. So what's the harm? I agree that unmaintained libraries that don't adapt to modules could be a problem. We'll have to see what happens.