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

281–290 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#281

Post by mpalmer »

wyattpeak wrote: post #158
mpalmer wrote: post #129

Earlier quoted context omitted.

Sounds like you think this is some kind of "Web 2.0" situation, but that was just a marketing term. Languages are software; they are dependencies of other software (the only unavoidable dependency!) and as such should absolutely be versioned. Versioning isn't for marketing or providing easy ways for users to remember when features were released. It's a tool for change management. Exciting features often come with bre…

versioning != semantic versioning Semantic versioning is an approach to versioning. It's an approach which, as GP stated, was designed specifically to help with dependency updating. GP isn't proposing that languages shouldn't be versioned, they're saying that semantic versioning is the wrong approach to versioning for a language.

Well I did inadvertently leave out the word semantic but it's certainly what I was describing.

Re: Go Replaces Interface{} with 'Any'

#282

Post by tptacek »

TheDong wrote: post #268
johnisgood wrote: post #215

Earlier quoted context omitted.

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 boilerp…

I don't understand this example at all. A Rust programmer would essentially never use unwrap on the return from File::open. It would be like checking open(2) with assert() in C.

Re: Go Replaces Interface{} with 'Any'

#283

Post by Aeolun »

bearcherian wrote: post #236
lolive wrote: post #227

Earlier quoted context omitted.

Disclaimer: I am totally newbie in Go. But quite experienced in Java and Js/Ts. I never jumped the Go bandwagon because of the lack of generics. Can I now try Go? The following article seems to say that the lack of other features can be frustrating (the lack of lambdas and the lack of the functional handling of collections seems problematic to me) Also I wonder whether the language has a IDE support as good as Intell…

If you're main problem with a new language is that it's not written like the language you are used to, you're not going to be happy with the new language.

Hence I’m not happy with anything that doesn’t look like Java.

Go seems amazing otherwise, but I cannot get over the fact that it forces me to capitalize or not capitalize my variables, and has types in the wrong order.

Re: Go Replaces Interface{} with 'Any'

#284

Post by Dylan16807 »

jonathankoren wrote: post #245
Dylan16807 wrote: post #222

Earlier quoted context omitted.

> Upgrade Upgrading is the problem in this scenario. Let's say 727 is the modern version. If users upgrade to 728, when 728 is based on 402, we have an issue.

> we have an issue. No, we don’t.

It's hard to say much when your replies are so short, but let me try to elaborate.

If a user that was happily using version 727 is now on a version that's almost identical to 402, they're now missing 300 versions' worth of code changes. You don't see how that's an issue? What if they were using functionality from that? Upgrading to 728 has removed all this code they were depending on!

If everyone follows your advice to upgrade, then everyone has this problem. Including you, unless you ignore your own advice.

Re: Go Replaces Interface{} with 'Any'

#285

Post by garmaine »

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…

Arguably a language should NEVER have breaking changes large enough to warrant a SemVer major version update. Rename or fork the language if you want to do that. Such major language overhauls in the past have been a huge waste of developer time as they go back to rewrite affected code.

Re: Go Replaces Interface{} with 'Any'

#286

Post by collinvandyck76 »

qaq wrote: post #68
alkonaut wrote: post #61

After generics (coming soon), a proper sum type and then I'll shut up.

same :) maybe also relax rules a bit to allow type elision for structs in function calls to get python like keyword args. foo("blah", {option1: true}) would work better than functional options people use now.

This would be lovely

Re: Go Replaces Interface{} with 'Any'

#287

Post by Aeolun »

xyzzy_plugh wrote: post #175
linkdd wrote: post #100

Earlier quoted context omitted.

Which is exactly why I said: > I cannot wait for the Result monad. Generics make this possible, and will be a huge improvement to Go's error handling. I'm not saying it will solve everything, but it's a huge step nonetheless.

I think you will find that Go's error handling will not change as much as you suggest. The majority of developers are extremely cautious of generics and found the status quo to be the best balance between readability and conciseness. Convenience is not a goal of the language, generally.

It doesn’t need to be part of the core language. Everyone can make their own monad, or use the one from a library.

Re: Go Replaces Interface{} with 'Any'

#289

Post by 3a2d29 »

jshen wrote: post #233
pawelmurias wrote: post #163

Earlier quoted context omitted.

A language shouldnt be optimized towards doc avoiding newbies at the cost of making things verbose and ugly.

Go is the most readable language I’ve used in terms of understanding other peoples complex code bases, and I’ve been doing this a long time and have used a lot of languages. Edit: It’s also one of the most approachable languages.

Surely Python gets that honor over Go. As much as I like Go, Rust, C, over Python, I would never say the reason is readability.

Re: Go Replaces Interface{} with 'Any'

#290

Post by eweise »

earthboundkid wrote: post #210
eweise wrote: post #35

Earlier quoted context omitted.

Couldn't unbounded just be [T]? Why the extra typing?

With generics, the metatype of a type variable is an interface type. If you just had T, it’s grammatically incomplete because you don’t specify the metatype. I guess you could just assume the any type if it’s incomplete, but that’s an unnecessary inconsistency in the grammar.

I don't know. Making constraints optional is the way it works in all the other languages I use.
Post reply on HN