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

321–330 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#321

Post by masklinn »

zemo wrote: post #183
masklinn wrote: post #102

Earlier quoted context omitted.

> I’d kill for union types as well. > … and pattern matching. Maybe just some extensions for `switch`. Go has type switches which are… ok. If it were possible to “close up” interfaces and type switches took that in account (match completeness) you’d be done about done, you would not have the structural / patterned unpacking but that’s probably less of a concern.

the fact that the set of types that can satisfy an interface is open is the source of their power. "closed interfaces" are broadly an antipattern in Go.

> "closed interfaces" are broadly an antipattern in Go.

That is complete nonsense.

The ability to create an open set of types is powerful, so is the ability to create a closed set of types, and they are not exclusive.

But go currently has only one of the two, which significantly limits its expressivity and type safety.

Re: Go Replaces Interface{} with 'Any'

#322

Post by dharmab »

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

I just tested on the dev branch and you can still use variables named `any`. The compiler is smart enough to tell variable names and types apart. You can even create a variable named any with type any with `var any any`

Re: Go Replaces Interface{} with 'Any'

#323

Post by saghm »

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.

> The majority of developers are extremely cautious of generics and found the status quo to be the best balance between readability and conciseness.

Most people who use Go have specifically chosen to use it though (or at least sought out opportunities, given that it's not something entrenched like Java being used due to inertia), so yes, most of them are fine with how Go is or they wouldn't be using it in the first place. If Go had generics from the start, I'd imagine most users would be fine with that too due to self-selection.

Re: Go Replaces Interface{} with 'Any'

#325

Post by jshen »

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 those languages. It’s far easier to make sense of a non trivial go code base I’ve never seen before than any of those.

Re: Go Replaces Interface{} with 'Any'

#326

Post by DarylZero »

eru wrote: post #301
DarylZero wrote: post #204

Earlier quoted context omitted.

In general, you can replace pattern matching with a function that takes one function for each constructor of the sum type. However, doing this kind of ... sucks.

It sucks when you have to use it for everything, but it's a useful enough technique that most Haskell datatypes come with functions that provide exactly this conversion to church encoding. See eg 'maybe' ( https://www.stackage.org/haddock/lts-18.18/base-4.14.3.0/Pre... on stackage) or foldr for lists. 'foldr' is interesting, because it encapsulates a recursive pattern matching on lists. For the non-recursive version,…

It's probably actually better than pattern matching when there are only two, as in those cases. But even at three, it becomes a mess. And more than three? Yuck.

Re: Go Replaces Interface{} with 'Any'

#327

Post by tgv »

skybrian wrote: post #298
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…

Go has function literals, which are basically lambdas but a bit more verbose. Typical Go style doesn’t use them as often as other languages. You might assign one to a variable, giving you an inner function. But loops are usually written as for loops, not map calls. One API call that comes to mind where you might use one is ast.Inspect. [1] Go often works well for replacing shell scripts, even without generics. [1] ht…

> Go often works well for replacing shell scripts, even without generics.

That’s selling the language short. Way too short.

Re: Go Replaces Interface{} with 'Any'

#328

Post by saghm »

kaba0 wrote: post #192
peoplefromibiza wrote: post #106

Earlier quoted context omitted.

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…

Nitpick, but I like to point out that Java’s exceptions are themselves a Result type/analog with them. You can unwrap it by a try catch, and can choose to rethrow it with minimal syntax. It even has a plus, it will auto-attach a stacktrace to the error case.

This is only the case for "checked" exceptions though; the important part about the Result type in Rust is that it won't implicitly propagate errors if you try to just use the success value but instead will give a compiler error. I don't code much Java, but my impression is that standard library methods throwing unchecked exceptions is far more common than panicking, the closest equivalent is in Rust.

Re: Go Replaces Interface{} with 'Any'

#329

Post by drvd »

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…

> 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 offended by by other things Go does in its particular way. Be it error handling, pattern matching, concurrency, mutability, etc. Basically if you try to write Java (or JavaScript) programs in Go you will suffer and hate Go. Same for C++/Rust aficionados. Go's newly added "generics" still come without "library support".

Re: Go Replaces Interface{} with 'Any'

#330

Post by klabb3 »

MereInterest wrote: post #296
kelnos wrote: post #189

Earlier quoted context omitted.

> Sure, but semantic versioning really is the wrong kind of versioning to use for a language. I don't agree. I usually don't care so much when a particular feature was introduced into a language (and if I do, it's usually a Wikipedia search away). I mostly care whether or not code written assuming version X can be compiled with version Y of the compiler. Semantic versioning can tell me the latter. Making versioning a…

> 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 cases, at the expense of maintaining a recent toolchain.

Not saying this tradeoff is for everyone, and I've never used C++ professionally so I'm probably ignorant. But are you saying it's common with production projects that use a compiler from 2003 or earlier? What's the use case?

Post reply on HN