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

331–340 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#331

Post by nine_k »

philwelch wrote: post #7
exdsq wrote: post #3

Earlier quoted context omitted.

How is generics not a big enough change to warrant 2.0? Edit: I’m impressed generics aren’t a breaking change! I thought this changed Interface{} to Any as a breaking change

In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.

Changing the programming approach seriously should be a major version change.

A language is an interface with humans. Switching to generics is a major change in the way to think about the source code. It's not an implementation detail which is not a big deal as long as the compiler can accept earlier source syntax.

Re: Go Replaces Interface{} with 'Any'

#332

Post by esoterae »

dragonwriter wrote: post #316
garmaine wrote: post #314

Earlier quoted context omitted.

Nearly every big fix in an API is technically a breaking change if you want to be pedantic. This kind of collateral damage which requires multiple points of failure doesn’t usually count as a semantic major change.

> Nearly every big fix in an API is technically a breaking change if you want to be pedantic. A fix is not a breaking change in the API, because “breaking” refers to expected behavior (so, yes, code that relies on a bug can be broken by a fix; presumably, if you've coded to an observed behavior differing from the spec you are aware of having done so.)

I stand in awe of your patience in the face of autodefensive incomprehension.

Re: Go Replaces Interface{} with 'Any'

#333

Post by ComputerGuru »

eru wrote: post #304
imron wrote: post #240

Earlier quoted context omitted.

I use rust and my code does not have .unwrap() (and definitely not .unwrap().unwrap()) in it either. That's what the ? operator is for.

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.

Re: Go Replaces Interface{} with 'Any'

#334

Post by klabb3 »

drvd wrote: post #329
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…

> I am [...] quite experienced in Java and Js/Ts. > I never jumped the Go bandwagon because of the lack of generics. > Can I now try Go? Probably no. You still would be very disappointed. Go's take at writing and maintaining software often is pretty repugnant to people with a strong Java or JavaScript mindset. If missing user defined parametric polymorphism ("generics") was a reason to not even _try_ it you will be o…

This feels like an unusual opinion. Lots of people from different backgrounds are happy with Go. And it's praised particularly for its concurrency model.

That said, generics are still new and won't have the strongest library support for a while, and it takes a bit for idioms to settle. It wouldn't be unreasonable to wait for ~a year.

Re: Go Replaces Interface{} with 'Any'

#335

Post by fsdjkflsjfsoij »

valenterry wrote: post #279
jshen wrote: post #233

Earlier quoted context omitted.

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.

Why don't you list the languages that you have used? Otherwise there isn't really any new information. For example for, having done Java, Scala, Python, Groovy, Haskell, Typescript and a couple others, Go reads extremely horrible. It feels as bad as enterprisey Java to me.

I've used all of those and more and spent a decade deep in the purely functional Scala/Haskell camp. Diving into a moderate or large Go code base is always far easier for me even though I've used Go much less than the others. Before I even knew Go I would often look at various algorithms in Go just because it was so easy to understand exactly what was happening.

Re: Go Replaces Interface{} with 'Any'

#336

Post by halfdan »

garmaine wrote: post #308
notfed wrote: post #295

Earlier quoted context omitted.

Java 10 introduced "var", which broke code with variables named "var". I'm glad they did not introduce a new language JavaWithVar.

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".

Re: Go Replaces Interface{} with 'Any'

#337

Post by KronisLV »

nine_k wrote: post #331
philwelch wrote: post #7

Earlier quoted context omitted.

In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.

Changing the programming approach seriously should be a major version change. A language is an interface with humans . Switching to generics is a major change in the way to think about the source code. It's not an implementation detail which is not a big deal as long as the compiler can accept earlier source syntax.

Heh, i think that there are plenty of opinions about how software versioning should work.

Yours is a pretty good one, i think that software versions should be indicative of what it contains to the people using them, whereas some others primarily care about the compatibility with the other versions. Semantic versioning is better suited to the latter group, because it doesn't really care about what's in the software, beyond what the changes are when compared to the other versions - breaking functionality, non-breaking functionality or just fixes of some sort.

My own alternative would take a slightly different approach yet - a system that would indicate when something was released, as well as whether the release is supposed to be stable (think MySQL 5.7, but in a format like 2021-stable-1234), or something more like a rolling release/nightly build with the latest changes (in format like 2021-latest-2345), an idea that in part i shamelessly stole from the Unity game engine, Ubuntu and JetBrains IDEs, since having a glance at their versions makes it apparent what you're looking at.

I actually wrote about that idea on my blog: https://blog.kronis.dev/articles/stable-software-release-sys...

Since then, i've started using that scheme for a few internal libraries in my dayjob to see whether it will work out (where switching to something else would be a matter of updating the CI, so less than an hour), as well as some personal projects.

Of course, each versioning scheme has advantages and disadvantages.

Re: Go Replaces Interface{} with 'Any'

#338

Post by pjmlp »

robto wrote: post #57
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…

In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.11, respectively[0]. In Clojure land they just say 1.x, even when large new features are added. I like this because it emphasizes the community's commitment backwards compatibility, which I greatly value. I've spent a good deal of time writing Javascript, where library developers…

Java does break compatibility, although they strive to avoid it as much as possible.

https://docs.oracle.com/en/java/javase/17/language/java-lang...

https://docs.oracle.com/en/java/javase/17/migrate/getting-st...

The x.y versioning with y being a synonym for major version was abandonend in Java 9.

Re: Go Replaces Interface{} with 'Any'

#339

Post by mseepgood »

planb wrote: post #318
exdsq wrote: post #3

Earlier quoted context omitted.

How is generics not a big enough change to warrant 2.0? Edit: I’m impressed generics aren’t a breaking change! I thought this changed Interface{} to Any as a breaking change

Was "any" a reserved word in Go before? Because if not, this would be a breaking chnage for all code that uses a var named "any".

"any" is a new identifier, not a keyword. The usual shadowing rules apply.

Re: Go Replaces Interface{} with 'Any'

#340

Post by zxcq544 »

lolive wrote: post #227
mseepgood wrote: post #2

It's a type alias, introduced for generics. By the way, Go 1.18 Beta 1 is released (with generics): https://groups.google.com/g/golang-announce/c/eAjK4Oezs_A

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…

For IDE you can try goland(which is Intellij Idea for go). For replacing shell scripts go should be fine. It's closer to C than Java, so you will often write "if err!=nil" which is not a problem actually. Go feels like C with Hashmaps and simplified threading.
Post reply on HN