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

131–140 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#131

Post by tptacek »

keithnz wrote: post #39
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.

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…

They're not using 2.0 because 2.0 might have breaking changes, and they don't want to burn the version number for something that doesn't break the Go 1.0 compatibility promise. Makes sense.

Re: Go Replaces Interface{} with 'Any'

#132

Post by Someone »

AtNightWeCode wrote: post #82
jjice wrote: post #67

Earlier quoted context omitted.

Doesn't 'for' work as 'while' if you only give it a condition in go? I haven't written much, so correct me if I'm wrong.

Does not Interface{} work as well as Any? I mean, most languages have while-statements cause it is more clear what the intention is.

Some languages even have real for statements because it makes more clear what the intention is.

In Pascal, you can’t break out of a for statement, the limit and step value are evaluated only at start of the loop, and you can’t change the value of the variable being looped over.

Consequently, the number of iterations through the loop taken is known when the loop gets entered.

Re: Go Replaces Interface{} with 'Any'

#133

Post by cpuguy83 »

keithnz wrote: post #39
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.

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…

There are already effectively 2 ways to deal with language changes:

1. Min version in go.mod 2. Add a build tag for what to do for new/old version of go (These tags are automatic, you just need to set them in the files)

Re: Go Replaces Interface{} with 'Any'

#134

Post by abendstolz »

meowface wrote: post #47
jonathankoren wrote: post #26

Earlier quoted context omitted.

Well there’s a joke somewhere. Less has my favorite version numbering system. Sequential. Latest stable release: Version 598 https://www.greenwoodsoftware.com/less/

My favorite has become just making the version number the release date.

For binaries, I agree. For libs, I prefer semver

Re: Go Replaces Interface{} with 'Any'

#135

Post by tptacek »

linkdd wrote: post #50
kbd wrote: post #32

This is fantastic. It'll make Go feel much less weird. eg from the diff: []interface{}{1, 2.0, "hi"} -> []any{1, 2.0, "hi"} Now that Go is going to have generics, all we need is sugar syntax for early return on error -- like more modern languages such as Rust and Zig have -- and Go may finally be pleasant to program in!

I cannot wait for the Result monad. The state of error handling in Go at the moment is embarrassing at best.

A lot of people are going to write very un-idiomatic Go code with "Result" types built on simple generics that, 5 years from now, we'll all be kind of smirking at. Rust's Option and Result make sense because the language supports it (most importantly with match statements). They don't make sense here.

Re: Go Replaces Interface{} with 'Any'

#136

Post by linkdd »

peoplefromibiza wrote: post #106
the_duke wrote: post #58

Earlier quoted context omitted.

Emulating sum types in languages without pattern matching is extremely awkward, to the point of being almost useless. type Result[T] struct { ok: *T err: error } Great, so how do you work with it? * You can have a `ok()` getter that returns `*T`. Now you you need an `if x != nil` * `isOk()` + `isErr()` * `unwrap() T`, which panics on errors * `split() (*T, err)` that splits into separate values, especially awkward si…

you can map on ok which is an alias for map_ok and then map_err for errors and or_else or_throw etc. that's similar to what Java does with the Optional type, not great, but not bad either the alternative is checking for nulls which is worse in any possibile way I usually implement something like Kotlin Result when I have to code in Java with a couple of static helpers to build the result: Result.success(T) Result.fai…

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.

Re: Go Replaces Interface{} with 'Any'

#137

Post by setr »

mseepgood wrote: post #114
taywrobel wrote: post #30

Earlier quoted context omitted.

Yes - https://0ver.org/about.html “ZeroVer is satire, please do not use it”

But why is it satire? It makes a lot of sense for projects that don't want to commit to a stable API.

For projects like React Native, which claim production-ready and are presumably quite stable in practice, you’re back to version numbers being meaningless, except with the added bonus it’s not even useful for marketing..

Re: Go Replaces Interface{} with 'Any'

#138

Post by linkdd »

tptacek wrote: post #135
linkdd wrote: post #50

Earlier quoted context omitted.

I cannot wait for the Result monad. The state of error handling in Go at the moment is embarrassing at best.

A lot of people are going to write very un-idiomatic Go code with "Result" types built on simple generics that, 5 years from now, we'll all be kind of smirking at. Rust's Option and Result make sense because the language supports it (most importantly with match statements). They don't make sense here.

Fun observation of mine: most articles/tutorials I've read about "idiomatic go code" are presenting ideas that you never see in any production code.

Seems to me that the ones who write about "idiomatic go code" aren't the ones who are shipping softwares/libraries.

Re: Go Replaces Interface{} with 'Any'

#139

Post by randomdata »

linkdd wrote: post #88
Thaxll wrote: post #63

Earlier quoted context omitted.

Well it's better than most language with exceptions. People makes it a big deal, in reality it's not.

An exception has a stacktrace. This single piece of information is crucial when you debug and makes handling errors in Golang embarrassing. I rest my case.

Go exceptions do carry stack trace information.

However, the topic is errors, not exceptions. Those are very different concepts. Of what use is stack trace information in debugging values that you have assigned error meaning to when not other types of values?

If you had a function

   func add(a, b int) int { return a * b }
there would be no expectation of carrying a stack trace to debug it. So what's different about

   func add(a, b int) error { return errors.New("cannot add") }
that does require a stack trace?

Re: Go Replaces Interface{} with 'Any'

#140

Post by [deleted] »

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…

[deleted]
Post reply on HN