Hacker News Reader

Comment by jonathanstrange | Hacker News Reader

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.

View on HN

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.

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.

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?

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

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.

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.

C++11 introduced breaking changes (https://stackoverflow.com/questions/6399615/what-breaking-ch...) but is widely regarded as a boon to the language.

Yes, but in large part, those changes were quite obscure, in comparison to things like how to define classes.

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

Rust 2018 has breaking changes, and their mechanism for dealing with it is incredible.

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.

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

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

Yeah, wikipedia cites some unspecified maritime usage of _ but it's definitely not common. It seems like most of the standards outside of programming languages have been moving towards spaces. Unfortunately there doesn't seem to be an easy way to search e.g. https://lh.2xlibre.net/values/thousands_sep/ but some lazy JavaScript shows no underscores and several flavors of whitespace:

    new Set($(".value").map((idx, elem) => elem.textContent))
    Set(8) [ "", ",", ".", "         ", " ", "'", " ", "٬" ]

It's interesting though, Racket certainly doesn't shy away from it. It allows you to use the lambda symbol as a replacement for the `lambda` keyword. (The keyword still works however)

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

Go is a decade old with many large production-grade code bases. The language is pretty stable, and worth learning!

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.

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.

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.

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.

There’s a tool called fix, it’s already part of the standard Go distribution. In the past (mostly pre 1.0, IIRC?), it’s used to apply changes to one’s codebase when migrating between Go releases that introduce incompatible changes.

https://golang.org/cmd/fix/

Can it be used in editors, say VS Code, to provide fix-its or suggestions for improving code on a line-by-line basis? If so, that sounds great. A lot of languages are missing this in their standard distributions and devs must rely on third-party offerings.

Reply on news.ycombinator.com