Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I'd like to see in Go 2.0

sethvargo.com

Post reply on HN
Print view View original

21–30 of 223 posts

Re: What I'd like to see in Go 2.0

#21

Post by szastamasta »

avg_dev wrote: post #9
bstpierre wrote: post #7

Serious question: what are the odds that go 2 ends up like python 3 and it takes the world over a decade of pain to migrate? (I like both python and go, and I’m still maintaining a sizable body of py2 code.) “Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migr…

It would be nice if there was a tool that re-wrote your Go-1 code in Go-2.

Nope, this is exactly what has killed Python3. There is only one way forward - old code still has to work or people will simply stay on 1.0 forever.

Re: What I'd like to see in Go 2.0

#22

Post by lolive »

masklinn wrote: post #14
lolive wrote: post #11

Earlier quoted context omitted.

Not a Go développer here, but let’s take the example of Java when it got (for example) generics or functional features. There was NO going back. These were so fundamental improvements that the past was absolutely outdated as soon as those new features were available. May be the same thing will happen for Go

Not sure how relevant that is, the old code worked fine in post-generics Java.

Technically yes. But, to me, the question is how developpers are changed by a given paradigm shift. It happened with generics, it happens with functional programming. So an evolution in the language can just make its past versions instantly outdated. [afaiu, python 3 did not do that. But my point is to say that it can happen.]

Re: What I'd like to see in Go 2.0

#24

Post by masklinn »

lolive wrote: post #22
masklinn wrote: post #14

Earlier quoted context omitted.

Not sure how relevant that is, the old code worked fine in post-generics Java.

Technically yes. But, to me, the question is how developpers are changed by a given paradigm shift. It happened with generics, it happens with functional programming. So an evolution in the language can just make its past versions instantly outdated. [afaiu, python 3 did not do that. But my point is to say that it can happen.]

But that’s a completely different matter.

The issue of Python 2 / Python 3 is that the two were not compatible, which made the transition extremely complicated. That has nothing to do with the new version making the old one essentially outdated because of the usefulness of its contents.

Re: What I'd like to see in Go 2.0

#25

Post by masklinn »

szastamasta wrote: post #21
avg_dev wrote: post #9

Earlier quoted context omitted.

It would be nice if there was a tool that re-wrote your Go-1 code in Go-2.

Nope, this is exactly what has killed Python3. There is only one way forward - old code still has to work or people will simply stay on 1.0 forever.

I mean… yes, but also, not even remotely.

Languages like Rust have solved this through the concept of editions (or whatever you want to call it), essentially package or module-level “compilation mode” which allows evolving the language without breaking the old code.

The issue of the Python transition is that it was way too massive and the repercussion were way too widespread (e.g. they necessarily leaked into the APIs) for this to be possible, despite Python having an entire mechanism to handle this with `from __future__` (though admittedly that being a file-level attribute makes it less than ideal to move the language forwards).

Re: What I'd like to see in Go 2.0

#26

Post by fastest963 »

t43562 wrote: post #20

Everyone has their own gripes. Modules are what cause me the most pain in Go - especially where they're in github and I need to fork them and now change all the code that references them. I don't know if the problems are even tractable because the way it all works is so incredibly complicated and any change would break a lot. I would like to remove all the "magic" that's built-in for specific SCMS/repository hosting…

You should be able to use "replace" to use your forked module instead of the original and you don't have to change anything.

Re: What I'd like to see in Go 2.0

#27

Post by sethvargo »

maccard wrote: post #3

This is a great post, and I agree with much of what he said (range shouldn't copy - I would love a range that iterates by const-reference by default, to lift a phrase from C++). Deterministic select I hard disagree with. The code in the blog post is race-y, and needs to be fixed, not select. If anything, making select deterministic will introduce _more_ subtle bugs when developers rely on that behavior only to find o…

How would you fix that code?

Re: What I'd like to see in Go 2.0

#28

Post by masklinn »

randallsquared wrote: post #18

The issue with the order of range seems like using the same name for satisfying a different requirement: in a template, you're much more likely to want the value than the index, so it makes sense that a looping construct with a single parameter would be putting the value in that parameter. In a loop in normal code, you're more likely to want to do math on the index. So, I'd say the problem is more about punning the n…

> In a loop in normal code, you're more likely to want to do math on the index.

It really is not, no. The number of loops using `enumerate` (or working on range / indices directly) in Python or Rust are a small fraction of those just iterating the sequence itself.

That would be even more so for Go, which has no higher-level data-oriented utilities (e.g. HOFs or comprehensions, which would usually replace a number of non-indexed loops, and would thus increase the ratio of indexed to non-indexed loops).

Re: What I'd like to see in Go 2.0

#29

Post by jatone »

t43562 wrote: post #20

Everyone has their own gripes. Modules are what cause me the most pain in Go - especially where they're in github and I need to fork them and now change all the code that references them. I don't know if the problems are even tractable because the way it all works is so incredibly complicated and any change would break a lot. I would like to remove all the "magic" that's built-in for specific SCMS/repository hosting…

yeah it sucks, I think IDEs should help here. 1 click uplift var error to parent scope.

Re: What I'd like to see in Go 2.0

#30

Post by jatone »

fastest963 wrote: post #26
t43562 wrote: post #20

Everyone has their own gripes. Modules are what cause me the most pain in Go - especially where they're in github and I need to fork them and now change all the code that references them. I don't know if the problems are even tractable because the way it all works is so incredibly complicated and any change would break a lot. I would like to remove all the "magic" that's built-in for specific SCMS/repository hosting…

You should be able to use "replace" to use your forked module instead of the original and you don't have to change anything.

unfortunately replace is not supported well with modules. and they are hell bent on not supporting it well.
Post reply on HN