5 ms·

I hope they keep the changes reasonable and do not introduce any breaking changes. I like the language as it is now and I'm very productive in it.

jsmith45 8y ago
Well for the first round they are looking at: 1. Allowing generalized unicode identifiers. That is hardly likely to break anything except possibly some crazy edge cases that dont happen in real code. 2. Binary integer literals. (unlikely to break things) 3. allowing seperating groups of digits in a number with _ like 1_000_000 (unlikely to break anything) 4. Permit signed integers as shift counts (no need to cast ant int to a uint to use it in a shift expression. This won't break any existing code). So at least this first round is quite unlikely to break anything in real use.
- bryanlarsen 8y ago
  For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.
  - stcredzero 8y ago
    It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?
    - copperx 8y ago
      That's a good question because they ostensibly do it to get more users aboard, but in most cases, the result is the opposite (e.g., the Python 2/3 disaster).
      - stcredzero 8y ago
        I was actually thinking of the POV of people writing in the language, not the maintainers of the project which is the language. I guess my point is that those two groups of people have different incentives.
      - littlestymaar 8y ago
        The Python 2/3 switch was indeed a disaster, but in term of user gained and lost not so much: the number of Python users skyrocketed since 2007 despite the breakage nightmare.
      - hhmc 8y ago
        C++11 introduced breaking changes (https://stackoverflow.com/questions/6399615/what-breaking-changes-are-introduced-in-c11 https://stackoverflow.com/questions/6399615/what-breaking-ch...) but is widely regarded as a boon to the language.
        stcredzero 8y ago
        Yes, but in large part, those changes were quite obscure, in comparison to things like how to define classes.
    - fgonzag 8y ago
      .net 2.0 had breaking changes, and it was absolutely justified. The ecosystem would not be where it is now without it. (.net 2.0 introduced reified generics, and required a major overhaul of the internals, with quite a bit of breaking changes)
    - bryanlarsen 8y ago
      Rust 2018 has breaking changes, and their mechanism for dealing with it is incredible.
- rootbear 8y ago
  I would like to see more Unicode operators, at least as options. It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I use an international layout on my Linux systems and can type it easily. Also, I prefer using ' for the thousands separator and was happy when C++ adopted it. It's less visually intrusive, especially with variable width fonts, and some calculators even use apostrophe. Also, in identifiers, the underscore has semantic meaning: foo_bar is different from foobar. But 1'234'567 is meant to be identical to 1234567, so underscore isn't the best choice.
  - acdha 8y ago
    > It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I see the appeal but there are two problems with this: “solvable” is not the same as “easy”, and that similarly also wants fonts which make × more distinct from x. In both cases that's something which is perhaps approachable for dedicated developers but it seems likely to turn newcomers off of the language far more than deliver any real benefit. > the underscore has semantic meaning: foo_bar is different from foobar. But 1'234'567 is meant to be identical to 1234567, so underscore isn't the best choice. It's kind of odd to argue that inconsistency counts against use of the underscore but then argue for adding another distinct use for the apostrophe. That would require care for every tool which works with the language from compilers to highlighters, which seems unlikely to be worth the hassle since, unlike mathematical symbols, there's not much precedent for that convention.
    - rootbear 8y ago
      Prior to some programming languages adopting it, I don't think there was precedent for using underscore as a thousands separator, so I don't consider it a strong precedent. The first language I recall using it was Ada. But I understand that using apostrophe has problems that would likely make its adoption impossible for an existing language. I was actually surprised when C++ adopted it. Interestingly, there is a locale that uses apostrophe for the thousands separator: de_CH (Swiss German). Try this in bash: $ LC_NUMERIC=de_CH df --block-size=\'1KB I don't know if there is a locale that uses underscore, I didn't find one when I looked a while back. Perhaps there should be...
macjohnmcc 8y ago
Yeah the swiftness of changes in Swift have turned me off to that language until it stabilizes.
- frlnBorg 8y ago
  Go is a decade old with many large production-grade code bases. The language is pretty stable, and worth learning!
  - weberc2 8y ago
    Pretty sure Go hit 1.0 in 2012 and Swift in 2014. In any case, I think the age is not a significant indicator or driver of stability (at least for these young languages), but rather the community's commitment toward stability. The Swift community definitely seems to value stability less than the Go community.
    - zapzupnz 8y ago
      Swift can get away with it because the majority of its users are using Xcode which has excellent tools for migrating between versions of Swift, and also interop with Objective-C code. Plus, the current compiler can target a limited number of older versions’ syntax but allowing use of new APIs for some degree of forwards compatibility in large code bases. Whereas I doubt there’s one canonical Go dev environment common to the majority of its users to make easy migrating large code bases and providing simple syntax adjustments.
      - ghthor 8y ago
        The standard go cli toolchain comes with `go fix which was used to do the update code for breaking changes or styles during the time before 1.0 release. If anything, I suspect the swift team was partially inspired by this pattern.
        zapzupnz 8y ago
        I doubt it. Apple's refactoring tools in Xcode go way back, thanks to the introduction of Carbon; the Intel transition; synthesised properties and automatic reference counting in Objective-C 2; and the extremely regular, breaking changes in UIKit.
deleted 8y ago
[deleted]

jsmith45 8y ago

Well for the first round they are looking at: 1. Allowing generalized unicode identifiers. That is hardly likely to break anything except possibly some crazy edge cases that dont happen in real code. 2. Binary integer literals. (unlikely to break things) 3. allowing seperating groups of digits in a number with _ like 1_000_000 (unlikely to break anything) 4. Permit signed integers as shift counts (no need to cast ant int to a uint to use it in a shift expression. This won't break any existing code). So at least this first round is quite unlikely to break anything in real use.

bryanlarsen 8y ago
For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.
- stcredzero 8y ago
  It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?
  - copperx 8y ago
    That's a good question because they ostensibly do it to get more users aboard, but in most cases, the result is the opposite (e.g., the Python 2/3 disaster).
    - stcredzero 8y ago
      I was actually thinking of the POV of people writing in the language, not the maintainers of the project which is the language. I guess my point is that those two groups of people have different incentives.
    - littlestymaar 8y ago
      The Python 2/3 switch was indeed a disaster, but in term of user gained and lost not so much: the number of Python users skyrocketed since 2007 despite the breakage nightmare.
    - hhmc 8y ago
      C++11 introduced breaking changes (https://stackoverflow.com/questions/6399615/what-breaking-changes-are-introduced-in-c11 https://stackoverflow.com/questions/6399615/what-breaking-ch...) but is widely regarded as a boon to the language.
      - stcredzero 8y ago
        Yes, but in large part, those changes were quite obscure, in comparison to things like how to define classes.
  - fgonzag 8y ago
    .net 2.0 had breaking changes, and it was absolutely justified. The ecosystem would not be where it is now without it. (.net 2.0 introduced reified generics, and required a major overhaul of the internals, with quite a bit of breaking changes)
  - bryanlarsen 8y ago
    Rust 2018 has breaking changes, and their mechanism for dealing with it is incredible.
rootbear 8y ago
I would like to see more Unicode operators, at least as options. It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I use an international layout on my Linux systems and can type it easily. Also, I prefer using ' for the thousands separator and was happy when C++ adopted it. It's less visually intrusive, especially with variable width fonts, and some calculators even use apostrophe. Also, in identifiers, the underscore has semantic meaning: foo_bar is different from foobar. But 1'234'567 is meant to be identical to 1234567, so underscore isn't the best choice.
- acdha 8y ago
  > It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I see the appeal but there are two problems with this: “solvable” is not the same as “easy”, and that similarly also wants fonts which make × more distinct from x. In both cases that's something which is perhaps approachable for dedicated developers but it seems likely to turn newcomers off of the language far more than deliver any real benefit. > the underscore has semantic meaning: foo_bar is different from foobar. But 1'234'567 is meant to be identical to 1234567, so underscore isn't the best choice. It's kind of odd to argue that inconsistency counts against use of the underscore but then argue for adding another distinct use for the apostrophe. That would require care for every tool which works with the language from compilers to highlighters, which seems unlikely to be worth the hassle since, unlike mathematical symbols, there's not much precedent for that convention.
  - rootbear 8y ago
    Prior to some programming languages adopting it, I don't think there was precedent for using underscore as a thousands separator, so I don't consider it a strong precedent. The first language I recall using it was Ada. But I understand that using apostrophe has problems that would likely make its adoption impossible for an existing language. I was actually surprised when C++ adopted it. Interestingly, there is a locale that uses apostrophe for the thousands separator: de_CH (Swiss German). Try this in bash: $ LC_NUMERIC=de_CH df --block-size=\'1KB I don't know if there is a locale that uses underscore, I didn't find one when I looked a while back. Perhaps there should be...

macjohnmcc 8y ago

Yeah the swiftness of changes in Swift have turned me off to that language until it stabilizes.

frlnBorg 8y ago
Go is a decade old with many large production-grade code bases. The language is pretty stable, and worth learning!
- weberc2 8y ago
  Pretty sure Go hit 1.0 in 2012 and Swift in 2014. In any case, I think the age is not a significant indicator or driver of stability (at least for these young languages), but rather the community's commitment toward stability. The Swift community definitely seems to value stability less than the Go community.
  - zapzupnz 8y ago
    Swift can get away with it because the majority of its users are using Xcode which has excellent tools for migrating between versions of Swift, and also interop with Objective-C code. Plus, the current compiler can target a limited number of older versions’ syntax but allowing use of new APIs for some degree of forwards compatibility in large code bases. Whereas I doubt there’s one canonical Go dev environment common to the majority of its users to make easy migrating large code bases and providing simple syntax adjustments.
    - ghthor 8y ago
      The standard go cli toolchain comes with `go fix which was used to do the update code for breaking changes or styles during the time before 1.0 release. If anything, I suspect the swift team was partially inspired by this pattern.
      - zapzupnz 8y ago
        I doubt it. Apple's refactoring tools in Xcode go way back, thanks to the introduction of Carbon; the Intel transition; synthesised properties and automatic reference counting in Objective-C 2; and the extremely regular, breaking changes in UIKit.

deleted 8y ago

[deleted]