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

231–240 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#231

Post by chrsig »

mseepgood wrote: post #49
hamburglar wrote: post #42

Earlier quoted context omitted.

That’s “a particular directory structure” that conflicts with many already-existing projects. What if I have a mostly-java project that has a couple bits of go code buried in it that I want to use as modules? Break it up into multiple repos for no good reason? No single tool should be acting like it owns the root directory of my repo.

The root of the Go project with the go.mod file doesn't have to be the root of the repository.

For that matter, you can have multiple modules in a repository.

Re: Go Replaces Interface{} with 'Any'

#232

Post by politician »

nvarsj wrote: post #109
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!

Yes, please, the iferr pattern drives me nuts. While I built a few years of my career on golang, I'm absolutely sick of the language at this point. At least we finally get generics.

Writing code for the happy path is 1/100th of programming. Maybe less.

Re: Go Replaces Interface{} with 'Any'

#233

Post by jshen »

pawelmurias wrote: post #163
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…

A language shouldnt be optimized towards doc avoiding newbies at the cost of making things verbose and ugly.

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.

Re: Go Replaces Interface{} with 'Any'

#234

Post by noisy_boy »

halfmatthalfcat wrote: post #197
jchw wrote: post #84

Earlier quoted context omitted.

I’d kill for union types as well. … and pattern matching. Maybe just some extensions for `switch`. … and one of the `try` proposals. That having been said… I do appreciate that Go has gotten where it is today by being radically simple, and that a lot of extreme care needs to be done to add new features to the language. It’s hard to draw a firm line in the sand. I feel like all of these features would work great toget…

At that point, let's just write Scala.

I think a language that doesn't focus much on backwards compatibility isn't a great comparison to Go :) Having written some Scala, I really like the language. I also like Go's excellent performance, easy concurrency, ability to produce a single binary without having to rely on JVM etc. I think it would be a bad idea to get overly complicated constructs into Go but union types/pattern matching are relatively accessible, not uncommon now and provide a lot of expressiveness without the risk of code becoming unreadable. Those combined with maybe some alternative approaches for error handling will make me want to write Go again (I've written one component in Go that is working perfectly but it was just too much code with bulk of it being err != nil).

Re: Go Replaces Interface{} with 'Any'

#235

Post by selljamhere »

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…

> Also I wonder whether the language has a IDE support as good as IntelliJ with Java (safe function extraction, type-safe autocomplete)

Jet Brains makes GoLand, which is about as good as they come. It should feel familiar if you're used to IntelliJ. https://www.jetbrains.com/go/

Re: Go Replaces Interface{} with 'Any'

#236

Post by bearcherian »

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…

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.

Re: Go Replaces Interface{} with 'Any'

#237

Post by jchw »

halfmatthalfcat wrote: post #197
jchw wrote: post #84

Earlier quoted context omitted.

I’d kill for union types as well. … and pattern matching. Maybe just some extensions for `switch`. … and one of the `try` proposals. That having been said… I do appreciate that Go has gotten where it is today by being radically simple, and that a lot of extreme care needs to be done to add new features to the language. It’s hard to draw a firm line in the sand. I feel like all of these features would work great toget…

At that point, let's just write Scala.

I don’t enjoy writing Scala even if the pattern matching syntax is basically the same as Rust. Some of it is the build tool, some of it is the JVM, and some of it is simply distaste for the language.

I don’t hate Scala and I’ve even written a few PRs in Scala, but I have had trouble picking it up for actual projects.

Go is extremely pragmatic and often favors clarity in how code will execute and simplicity in syntax and grammar. It’s basically a GC’d successor to C in many regards. It eschews classes for interface-based polymorphism, it compiles and runs code very fast, and above all, I’ve found it easy and rewarding to pick up.

I don’t want all of the expressiveness of Scala. Just a bit more than Go has today. Not much more.

Re: Go Replaces Interface{} with 'Any'

#238

Post by Lhiw »

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 lambdas and the lack of the functional handling of collections seems problematic to me

Why? 95% of lambdas I see should have been written without them. It's very rare I run into situations where it is more elegant or not really possible to write it another way.

Devs just love doing tricky shit for no reason it seems.

Re: Go Replaces Interface{} with 'Any'

#239

Post by msbarnett »

stormbrew wrote: post #205
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.

I feel like this is perhaps a bit of a gap in semver tbh. Sometimes a purely additive change can be quite major, in the sense that it shifts the thing in such a fundamental way that you are unlikely to try to interoperate between before and after, and are likely to run into trouble if you do. Basically, if 1.18 code is extremely unlikely to work against a 1.17 compiler, because a new (technically additive) feature is…

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.

Re: Go Replaces Interface{} with 'Any'

#240

Post by imron »

johnisgood wrote: post #215
linkdd wrote: post #86

Earlier quoted context omitted.

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

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

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.
Post reply on HN