Hacker News Reader

Comment by tialaramex | Hacker News Reader

> we gave the general rule that language redefinitions like what I just described are not permitted

Not just a "general rule" that document also specifically talks about precisely this issue (for loops) and resolves that Go will not fix this.

Change is the only constant, we should design systems with the expectation that they'll need to adapt over time or they will be replaced by something which can. With this mindset, Go should have solved the for loop problem years ago, just as C# did. This could have been a story about how once upon a time Go had these very silly for loop semantics, but that hasn't been true for many years.

This necessity of change is why I think the decision not to take Epochs for C++ 20 was much more consequential than things like rejecting the "Goals and priorities" paper which had immediate effects (in that particular case spurring the Carbon experiment).

View on HN

What’s your point here? They changed their mind, given years of data that showed this specific issue was worthy of an exception.

> Epochs for C++ 20

How did they plan to make Epochs compatible with headers being copy&pasted at the #include site? And what about template instantiation?

Epochs is intended to be used with C++ 20 Modules. An epoch can only apply to a whole module.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18...

Modules I suppose.

Arguably if Go had done this years ago, go.mod would not have existed and this would have an even bigger impact.

Just like we'll rarely pick exactly the right behavior, we'll rarely pick exactly the right time to fix the broken behavior.

I mean, Go had vendoring and vendoring managers not unlike npm and it's node_modules.

But a language more comfortable with change implies that change is more likely - not less likely. Given pretty much every modern language has some kind of dependency management utility - I'd be surprised if Go didn't end up with one

> Arguably if Go had done this years ago, go.mod would not have existed and this would have an even bigger impact.

I'm interested in the logical arguments that would support this. I can't think of any.

Are you of the opinion that the version in go.mod existed many years ago, or that requiring a recent number in it won’t comparatively limit the impact? Both seem obviously false to me.

I read this as:

    IF loop variable syntax had been redefined years ago
    THEN
        go.mod would not exist
        AND
        impact would have been larger

It seems from this thread that what they meant to say was:

    IF loop variables had been redefined BEFORE go.mod existed
    THEN impact would have been larger

I think they misinterpreted the word “existed” in this case. They took it as go mod would have never been made instead of go mod didn’t exist at that time.

But that's exactly what that sentence says, isn't it? Otherwise it'd been "Arguably if Go had done this years ago when go.mod did not exist, this would have had an even bigger impact" or something like this?

> But that's exactly what that sentence says, isn't it?

No?

> Otherwise it'd been "Arguably if Go had done this years ago when go.mod did not exist, this would have had an even bigger impact" or something like this?

That’s a worst take on the same sentiment? I find your version a lot clunkier. The original sets a hypothetical stage and from that its conclusion, I think it flows better.

> The original sets a hypothetical stage and from that its conclusion, I think it flows better.

The stage is "years ago", and conclusion is "go.mod would not have existed and this would have an even bigger impact". My version re-arranges the sentence so that "go.mod not existing" bit is a part of the premise, not of the conclusion.

Tense agreement in English subjunctive is hard. Especially for non-natives such as me: I do parse the original statement like that and just can't bring myself to understand it otherwise.

English native, and I parsed it the same way. The OG comment to me reads as if "go.mod never would have existed", not "go.mod didn't exist at this point in time."

Exactly, the comma is what does it, it separates the sentence into three fragments and then the 'and' joins segments two and three.

If the comma had instead been the word "when", as suggested, this would parse the other way. It still would have been a bit awkward but would make sense.

Ironically I have stopped using the word "when" in constructions like this because it confuses non-native English (esp. German) speakers who read it in the conditional rather than temporal sense.

How one depends on another? To me it sounds these things are orthogonal.

There's an ambiguity in the phrase "then go.mod wouldn't have existed." One way to read it is "then, as a consequence, go.mod wouldn't have existed" and the other is "then go.mod wouldn't have existed at that time." I believe the intention was the latter, whereas you're inferring the former.

go.mod provides a way to introduce the new behaviour incrementally. The key point is the dependencies can (and already do) declare different go versions in their go.mod file. When everything is compiled, each module is compiled with the behaviour that applies to its own declared go version. So even if you update your go.mod go version to take advantage of this (soon to be) new behaviour, you can continue to use existing deps happily without worrying they will break.

Because of time? How would you use go.mod when go mod does not exist?

Reply on news.ycombinator.com