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

Go Replaces Interface{} with 'Any'

github.com

Post reply on HN
Print view View original

261–270 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#261

Post by eru »

pawelmurias wrote: post #46
keithnz wrote: post #39

Earlier quoted context omitted.

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…

> Can upgrade without having to deal with breaking changes This is actually very important. If something is a major change or not is pretty subjective.

It is pretty subjective, but not entirely so, and I would guess there's a pretty clear consensus around whether this is a big deal or not in the community?

Re: Go Replaces Interface{} with 'Any'

#262

Post by eru »

socialdemocrat wrote: post #152
keithnz wrote: post #39

Earlier quoted context omitted.

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…

Get your point, but I kind of like it. It tells some really important info, and they are hardly alone. Python 3.x was breaking change. Until they they stayed in 2.x versioning a long time. And we will never see a Python 4.x

> And we will never see a Python 4.x

Why?

Re: Go Replaces Interface{} with 'Any'

#263

Post by eru »

nirvdrum wrote: post #187
keithnz wrote: post #39

Earlier quoted context omitted.

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…

I agree. It's a bit odd that I just learned generics were added. I expect minor bumps in language versions to be uneventful. Additionally, I expect a language to essentially never introduce breaking changes, so semantic versioning isn't really telling me anything.

> Additionally, I expect a language to essentially never introduce breaking changes, so semantic versioning isn't really telling me anything.

I'm afraid that expectation isn't entirely warranted. Especially around standard library issues.

Re: Go Replaces Interface{} with 'Any'

#264

Post by eru »

naikrovek wrote: post #221
keithnz wrote: post #39

Earlier quoted context omitted.

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…

define a "major" language change, then. after that, get everyone to agree on that definition. that's why semver works; the definition of major change is defined, and that's when you update the major version number.

I have sympathy for your sentiment, but you don't have to come up with a proper definition nor get everyone to agree on that definition.

The Go people can just make up reasonable version numbers without having an all encompassing theory with definitions, and they only have to convince themselves, not everyone on earth.

Re: Go Replaces Interface{} with 'Any'

#265

Post by eru »

Groxx wrote: post #124
13415 wrote: post #93

Earlier quoted context omitted.

It makes no sense to replace a meaningful and helpful criterion - whether it breaks code or not - by some purely subjective assessment of what's a "major change." That just leads to usual version creep, from "Go 2.2" to "Go 3.0", to "Go 4.0", to (inevitable) "Go 10", "Go 11", "Go 11 Pro", "Go 11 Ultimate Edition",...

It could be worse, they could start naming these "Go WXGA+", "Go i99900kf", and "Go for Women".

You joke, but using marketing version names _in addition_ to semantic versions might actually make sense.

Re: Go Replaces Interface{} with 'Any'

#266

Post by eru »

geofft wrote: post #194
wheybags wrote: post #191

Earlier quoted context omitted.

Windows (and vs) version numbers are a pain in the ass though. Constantly need to check that the version you need to put in some config file actually corresponds to the version you really mean.

I haven't seen anyone do a good job of it, but it seems to me that if you wanted to try, the way to do it would be to make the marketing versions and compatibility versions so different that they can't be confused (like Windows 95 or better yet XP, not Windows 7) - and then make sure that your configuration files can accept marketing versions and silently transform them to compatibility versions.

> [...] and then make sure that your configuration files can accept marketing versions and silently transform them to compatibility versions.

Or alternatively, complain loudly.

Re: Go Replaces Interface{} with 'Any'

#267

Post by eru »

msbarnett wrote: post #239
stormbrew wrote: post #205

Earlier quoted context omitted.

I feel like this is perhaps a bit of a gap in semver tbh. Sometimes a purely additive change can be quite major, in the sense that it shifts the thing in such a fundamental way that you are unlikely to try to interoperate between before and after, and are likely to run into trouble if you do. Basically, if 1.18 code is extremely unlikely to work against a 1.17 compiler, because a new (technically additive) feature is…

SemVer is about breaking changes to existing code when you upgrade compilers, not about making future code backwards compatible to older compilers. Every additive language change would be a breaking change in this ReverseSemVer you’re imagining.

Only subtractive changes and eg performance changes would not break things in the grandfather comment's scheme.

Re: Go Replaces Interface{} with 'Any'

#268

Post by TheDong »

johnisgood wrote: post #215
linkdd wrote: post #86

Earlier quoted context omitted.

The Rust Result type has: - map / map_err - and_then / or_else - unwrap / unwrap_or And countless of other functions making it very practical to chain computations without having to pattern match anything. I do the same in Erlang/Elixir. In Golang, I need to check every function call, and if I want to know where an error come from, I need to wrap it in an errors.New() because no exceptions = no stacktrace

Huge no to anything that will require .unwrap() noise everywhere in the codebase. I use Erlang, my code does not have ".unwrap().unwrap()"[1] anywhere. [1] https://github.com/SeaQL/sea-orm/blob/64c54f8ad603df0c1d9da8...

The comparison here is with go.

Unwrap would look like:

    file := os.Open("foo").Unwrap()
I'll take that over the current go state of the art:

    file, err := os.Open("foo")
    if err != nil {
        panic(err)
    }
Just like "panic(err)" is used infrequently, "unwrap" would be used infrequently. They're comparable, and for the cases where unwrap is okay (test code, once-off scripts, etc), I'd definitely prefer it to the panic boilerplate.

Re: Go Replaces Interface{} with 'Any'

#269

Post by crdrost »

peoplefromibiza wrote: post #153
linkdd wrote: post #136

Earlier quoted context omitted.

I also made a library for working with `{:ok, value}` and `{:error, reason}` in Elixir: https://github.com/linkdd/rustic_result Thanks to the pipeline operator and pattern matching, it makes pretty easy to read pipelines. It does not completely replace the with statement (that was not the point) but it simplified a lot of code.

this is nice, especially for the function clauses Elixir is my daily drive and working in Java made me miserable until I started working around the lack of pattern matching facilities Error handling is the worst part, I think a simple switch (retval) { Ok(val): ... break; Error(err): ... would make Java much more pleasant, even without full pattern matching everywhere.

This sorta exists in Java 17:

    sealed interface Result 
        permits Ok, Error {}
    record Ok(value: T) implements Result {}
    record Error(error: Throwable) implements Result {}
    
    // to consume
    switch (result) {
      case Error e -> e.error().getMessage(),
      case Ok v -> v.value().toString()
    }

Re: Go Replaces Interface{} with 'Any'

#270

Post by chenzhekl »

dragonwriter wrote: post #184
keithnz wrote: post #39

Earlier quoted context omitted.

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…

> Sure, but semantic versioning really is the wrong kind of versioning to use for a language. A language or API (things you program against) are pretty much the things for which SemVer makes sense. > The major version should represent major language changes, not whether its a breaking change or not I don’t care if changes are “major”, I care if the code I wrote for version X is expected to need modification to work c…

Can't agree more. One important information that the version number gives me is that if upgrading to newer versions will break my code. SemVer gives me that.
Post reply on HN