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

31–40 of 223 posts

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

#31

Post by kitd »

brnt wrote: post #13
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…

Not so serious question: what is Go2 and Python4 would be the same thing?

ie. they both become Nim ;)

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

#32

Post by chris_overseas »

lolive wrote: post #11
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…

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

While I agree with what you're saying, that's not the GP's point. They're talking about backwards compatibility, i.e. old code running on new versions. Java has been extraordinarilly good at that (maybe too much so), with the possible exception of Java 9. Try running Java 1.0 code on JDK 17 and it'll probably run fine. Try running Python 2 code on Python 3 and you're generally going to be in for a very rocky ride.

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

#33

Post by assbuttbuttass »

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…

The fix is pretty simple, just declare err ahead of time:

    func doThing() string {    
        result := "OK"
        var err error
        if result, err = somethingelse(); err != nil {
            return "ERROR"  
        }

        return result
    }

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

#34

Post by masklinn »

qaq wrote: post #23

I have much smaller ask struct type elision in function calls

I have to say I’ve no idea what you mean. In function definitions I’d interpret it as type inference (and would disagree) but you specifically talk about function calls, and consider it a small change. Can you describe what you’re thinking of?

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

#35

Post by assbuttbuttass »

sethvargo wrote: post #27
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?

I would write the author's example as follows:

    for ctx.Err() == nil {
        select {
        case
The extra check for ctx.Err before the select statement easily resolves the author's issue.

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

#36

Post by lolive »

masklinn wrote: post #24
lolive wrote: post #22

Earlier quoted context omitted.

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.

Ok. My bad.

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

#37

Post by asah »

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…

IMHO the long python3 migration was well executed and we're now comfortably on the back side of it. Reminds me of perl4=>5 and other big lifts.

Yes, commercial codebases understaffed for maintenance are kinda stuck, just like any legacy system. IMHO the solution must come from the business model down. Also, security, compliance & cost can help drive priority.

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

#38

Post by rplnt »

mieubrisse wrote: post #4

I'd add one more to this list: proper enum types. We use enums heavily to force devs who use our code into good choices, but the options are currently: 1) Use int-type enums with iota: no human-readable error values, no compile-time guard against illegal enum values, no exhaustive `switch`, and no autogenerated ValidEnumValues for validation at runtime (we instead need to create ValidEnumValues and remember to update…

> no exhaustive `switch`

This is what linters will do for you by default.

> we instead need to create ValidEnumValues and remember to update it every time a new enum value is added

Code generators are first class citizens in go, and writing an icky but reliable test won't be too hard either.

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

#39

Post by sethvargo »

assbuttbuttass wrote: post #35
sethvargo wrote: post #27

Earlier quoted context omitted.

How would you fix that code?

I would write the author's example as follows: for ctx.Err() == nil { select { case The extra check for ctx.Err before the select statement easily resolves the author's issue.

It really doesn't though. It handles the case where the context might have expired or be cancelled, but there's still a race when entering the select between the ctx.Done() and reading from thingCh. You may end up processing one additional unit of work. In situations where the exit condition is channel-based, this won't work.

Additionally, this would only work if you had one predominant condition and that condition was context-based. If you have multiple ordered conditions upon which you want to exit, I can't think of how you'd express that as a range.

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

#40

Post by Eun »

I would like to add proper JSON5 support.

The template problem is a real problem. I used it once and it was pain and moved away instantly. I would vote for go inside go as a template system. So you can effectively write go code.

With the help of yaegi[1] a go templating engine can be build e.g here[2].

[1]: https://github.com/traefik/yaegi

[2]: https://github.com/Eun/yaegi-template

Post reply on HN