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

341–350 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#341

Post by grumpyprole »

klabb3 wrote: post #330
MereInterest wrote: post #296

Earlier quoted context omitted.

> I don't agree. I usually don't care so much when a particular feature was introduced into a language I care very much when a feature was introduced into a language, because maintaining compatibility with earlier versions of the language determines what features may be used. If I'm working on a library that needs to be compatible with C++03, then that means avoiding smart pointers and rvalues. If I'm working on a li…

> In order to determine it for X > Y (new code on old compiler), you need to know when features were introduced. I think this is a deliberate reduction of dimensionality. Go says that you don't need to worry (for long) about this case, because the toolchain must be updated regularly - and promises that it will be as pain free as possible. This simplifies for the Go team, for library authors, and library users in most…

> But are you saying it's common with production projects that use a compiler from 2003 or earlier? What's the use case?

Modern C++ compilers are not necessarily available on all platforms. For example, Solaris, AIX or old RedHat versions. Go doesn't have this problem yet, but it will.

Re: Go Replaces Interface{} with 'Any'

#342

Post by laumars »

valenterry wrote: post #212
hbn wrote: post #62

Earlier quoted context omitted.

It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Learning Go really reframed my concept of what an interface is, and I thought that using an empty interface to represent "any type" was kind of ingenious, and helps reinforce its ethos. An empty interface can represent any type because every type inherently implements an interface with no methods. An…

> I thought that using an empty interface to represent "any type" was kind of ingenious It makes me a bit sad to read that. We all are on a journey to be become better developers every day. But things like that are like a distraction. They make you think you found a really cool and smart concept, but you actually didn't and it's essentially just a hack. Not sure what the solution can be. But PL designers should be mo…

That’s a very condescending way of say “I don’t personally like this feature”.

Re: Go Replaces Interface{} with 'Any'

#343

Post by preseinger »

linkdd wrote: post #86
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…

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

Chaining computations hides the error control flow path, which negatively impacts readability.

Re: Go Replaces Interface{} with 'Any'

#344

Post by preseinger »

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…

That Go would never pass code review unless it is part of a tiny CLI tool or script.

Re: Go Replaces Interface{} with 'Any'

#345

Post by preseinger »

linkdd wrote: post #138
tptacek wrote: post #135

Earlier quoted context omitted.

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.

Example?

The majority of Go I've been hired to improve has suffered immensely from not using accepted idioms. Most of my work has been focused on introducing those idioms systemically.

Re: Go Replaces Interface{} with 'Any'

#347

Post by benhoyt »

RunOutOfMemory wrote: post #280
ibraheemdev wrote: post #277

Earlier quoted context omitted.

What about it?

interface{} -> any struct{} -> ?

You can define that yourself as "type token = struct{}" or similar. In my experience struct{} occurs even less than interface{}, and it's also 3 characters shorter already, so it's not worth a builtin. I use "chan struct{}" for synchronizing and sometimes use "map[string]struct{}" for sets.

Re: Go Replaces Interface{} with 'Any'

#348

Post by the-alt-one »

valenterry wrote: post #212
hbn wrote: post #62

Earlier quoted context omitted.

It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Learning Go really reframed my concept of what an interface is, and I thought that using an empty interface to represent "any type" was kind of ingenious, and helps reinforce its ethos. An empty interface can represent any type because every type inherently implements an interface with no methods. An…

> I thought that using an empty interface to represent "any type" was kind of ingenious It makes me a bit sad to read that. We all are on a journey to be become better developers every day. But things like that are like a distraction. They make you think you found a really cool and smart concept, but you actually didn't and it's essentially just a hack. Not sure what the solution can be. But PL designers should be mo…

It's not a hack, it's the natural way of expressing it in the chosen type system. The use cases for interface{} are often hacks, because of a lack of parametric polymorphism, but that's different.

Re: Go Replaces Interface{} with 'Any'

#349

Post by flippinburgers »

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…

The lack of generics was never really a problem to begin with.

Re: Go Replaces Interface{} with 'Any'

#350

Post by ithkuil »

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

There is even a name for that https://www.hyrumslaw.com/

The solution clearly can't be to never ever fix bugs though.

But depending on the kind of bugs (especially when they are of the "gotcha"/"UX" kind) often it's better to just create a new API version with the corrected behaviour and keep existing software apply handle the old behaviour the best they could.

But clearly for many many other kinds of bugs (security etc) we are better served with a bug fix in the old API even if that implies a possibility for breaking somebody.

Post reply on HN