News for hackers. Stuff that matters.
Re:Go 2, here we come by jsmith45 on Thursday November 29, 2018 @12:22PM (#18561853)
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.

Re:Go 2, here we come by bryanlarsen on Thursday November 29, 2018 @12:32PM (#18561940)
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.
Re:Go 2, here we come by stcredzero on Thursday November 29, 2018 @12:48PM (#18562084)
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?

Re:Go 2, here we come by fgonzag on Thursday November 29, 2018 @05:16PM (#18564648)
.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)
Re:Go 2, here we come by copperx on Thursday November 29, 2018 @01:37PM (#18562565)
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).
Re:Go 2, here we come by littlestymaar on Thursday November 29, 2018 @04:19PM (#18564112)
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.
Re:Go 2, here we come by hhmc on Thursday November 29, 2018 @07:27PM (#18565539)
C++11 introduced breaking changes (https://stackoverflow.com/questions/6399615/what-breaking-ch...) but is widely regarded as a boon to the language.
Re:Go 2, here we come by stcredzero on Friday December 07, 2018 @06:29PM (#18632636)
Yes, but in large part, those changes were quite obscure, in comparison to things like how to define classes.
Re:Go 2, here we come by stcredzero on Thursday November 29, 2018 @01:49PM (#18562693)
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.
Re:Go 2, here we come by bryanlarsen on Friday November 30, 2018 @07:06AM (#18568483)
Rust 2018 has breaking changes, and their mechanism for dealing with it is incredible.
Re:Go 2, here we come by rootbear on Thursday November 29, 2018 @12:40PM (#18561995)
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.

Re:Go 2, here we come by acdha on Thursday November 29, 2018 @01:11PM (#18562316)
> 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.

Re:Go 2, here we come by rootbear on Thursday November 29, 2018 @01:32PM (#18562519)
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...

Re:Go 2, here we come by acdha on Thursday November 29, 2018 @04:24PM (#18564154)
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) [ "", ",", ".", "         ", " ", "'", " ", "٬" ]
Re:Go 2, here we come by opnitro on Friday November 30, 2018 @12:07AM (#18566861)
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)