Live data from Hacker News

Go Replaces Interface{} with 'Any'

github.com

361–370 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#361

Earlier quoted context omitted.

That wouldn't be large enough a change to warrant a new major SemVer. I'm talking about things like python2 -> python3.

It's clear the py2 to py3 migration was painful but I'm curious to hear how you would apply "they should fork / rename the language" here. To me it just feels like semantics. They said "here's a new major version of python" when they could also have said "we have forked python 2 and we're calling it python 3. We think it's better and we will probably abandon python 2 at some point".

(FWIW, "semantics" would be "what it means", so I figure that's not what you wanted to say: from your example, I guess you are saying it's more that it's a different wording — syntax? — for the same meaning)

But it's about setting expectations.

The only problem I ever had with py2 to py3 migration was that it was even possible to have the same codebase run against both, when languages are incompatible to such a degree (most notably, basic type has changed). It basically forced people to make the worst use of the Python dynamic nature (as soon as the stdlib started doing that, there was no going back).

Re: Go Replaces Interface{} with 'Any'

#362

Earlier quoted context omitted.

That wouldn't be large enough a change to warrant a new major SemVer. I'm talking about things like python2 -> python3.

It's clear the py2 to py3 migration was painful but I'm curious to hear how you would apply "they should fork / rename the language" here. To me it just feels like semantics. They said "here's a new major version of python" when they could also have said "we have forked python 2 and we're calling it python 3. We think it's better and we will probably abandon python 2 at some point".

Was? It still is painful as some companies have decided to keep and support python2 for another 5+ years. I have programs which require the same dep from different pythons.

To me, Python represents how not to do language versioning.

Re: Go Replaces Interface{} with 'Any'

#363
post #267

Earlier quoted context omitted.

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.

I did not in any way shape or form "propose a scheme." I pointed out what I perceive to be a limitation in semver to describe some kinds of changes in some kinds of things in practical terms.

These replies are incredibly and bizarrely dogmatic. I never knew it'd be so hard to have a discussion about semver without people just going "semver is semver" as if that means something.

Re: Go Replaces Interface{} with 'Any'

#364
Going to be downvoted for this, but it would be cool if Go had operator overloading. That way, you could write matrix code in it. I think if Go did this, the language could end up being used in computer graphics and Deep Learning.

Oh, and maybe this goes against the Go ethos, but Python has a library called Sympy for Computer Algebra, and it's quite nice. It clearly relies on operator overloading.

I'm guessing this won't happen for a long time because operator overloading has a reputation (rightly or wrongly) for being abused. Oh well!

[edit]

More philosophical point: Overloading in programming started with mathematical operators, no? The motivation for having it as a language feature is very clear (if you know enough mathematics). What happened?

Re: Go Replaces Interface{} with 'Any'

#365
post #283

Earlier quoted context omitted.

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.

I can't stand the capitalization thing. I see this in C# methods and boolean values in Python every day and it sucks. I think Java got it right on that one.

Re: Go Replaces Interface{} with 'Any'

#366
post #304

Earlier quoted context omitted.

The '?' is not a conceptual advance over .unwrap(), it's "just" a major syntactic convenience.

Of course it is. Unwrap panics on error, while ? bubbles up the error instead. But ? wasn’t introduced to replace unwrap, unwrap was always frowned upon. It instead replaces match and return.

It was always frowned upon, but still ended up everywhere (including lots of documentation and example code) because it was less verbose than the match handling. The ? helped remove that last obstacle.

Re: Go Replaces Interface{} with 'Any'

#368
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…

That's just like, your opinion, man.

Mark it zero!

Re: Go Replaces Interface{} with 'Any'

#369

Going to be downvoted for this, but it would be cool if Go had operator overloading. That way, you could write matrix code in it. I think if Go did this, the language could end up being used in computer graphics and Deep Learning. Oh, and maybe this goes against the Go ethos, but Python has a library called Sympy for Computer Algebra, and it's quite nice. It clearly relies on operator overloading. I'm guessing this w…

> if Go did this, the language could end up being used in computer graphics and Deep Learning.

People have written programs in both of those areas using Fortran-IV which doesn't have overloading either.

Re: Go Replaces Interface{} with 'Any'

#370

Going to be downvoted for this, but it would be cool if Go had operator overloading. That way, you could write matrix code in it. I think if Go did this, the language could end up being used in computer graphics and Deep Learning. Oh, and maybe this goes against the Go ethos, but Python has a library called Sympy for Computer Algebra, and it's quite nice. It clearly relies on operator overloading. I'm guessing this w…

> if Go did this, the language could end up being used in computer graphics and Deep Learning. People have written programs in both of those areas using Fortran-IV which doesn't have overloading either.

I think your comment is designed to troll me. The fact that it's so short and arrogant makes this more likely to be true. Just to be clear: Deep Learning means ConvNets or something fancier, which only became a hot research topic circa 2010 (though they also existed as a prototype in the late '80s). I doubt anybody has programmed ConvNets in Fortran IV; a language from 1962. And even if they did program a prototypical form of ConvNets (I suppose because they were originally an obscure proposal from the '80s) in Fortran-IV, it wouldn't be able to use such essentials as the GPU, or convenience features like autodiff, so in today's world it would be a toy.

I suppose I've fed the troll.

Post reply on HN