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

291–300 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#291

Post by eru »

ViViDboarder wrote: post #96
meowface wrote: post #47

Earlier quoted context omitted.

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

See CalVer. The date is definitely helpful for something with fairly stable APIs where breaking changes aren’t really happening. Perfect for things like Ubuntu, pytz, and ca-certificates. Less for something like a library who’s API could change and break your implementation.

CalVer is useful for Ubuntu. But not because it's stable, just the opposite:

It's useful for Ubuntu, because each Ubuntu release is a hodgepodge of lots of unrelated updates. Some will be breaking, some will be fine.

Re: Go Replaces Interface{} with 'Any'

#292

Post by eru »

bearcherian wrote: post #236
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…

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.

You can like generics without requiring everything to look like Java.

(In fact, generics have been a relatively late and reluctant addition to Java. They had been at home in ML-family languages and others for ages before.)

Re: Go Replaces Interface{} with 'Any'

#293

Post by eru »

ImprobableTruth wrote: post #248
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 lambdas https://go.dev/ref/spec#Function_literals

Yes, but without generics it's hard to do much useful with lambdas in your statically typed language. You can't even write a filter or map function.

And eg Go's old workaround for polymorphic sorting functions was just atrocious: it was rather convoluted, and only really worked at all for in-place sorting.

Re: Go Replaces Interface{} with 'Any'

#294

Post by eru »

hbn wrote: post #62
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!

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…

> It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias.

Having lots of syntactic sugar works out OK for Haskell.

For example, in Haskell straight-line imperative looking code is an alias for some underlying callback hell.

Re: Go Replaces Interface{} with 'Any'

#295

Post by notfed »

garmaine wrote: post #285
dragonwriter wrote: post #184

Earlier quoted context omitted.

> Sure, but semantic versioning really is the wrong kind of versioning to use for a language. A language or API (things you program against) are pretty much the things for which SemVer makes sense. > The major version should represent major language changes, not whether its a breaking change or not I don’t care if changes are “major”, I care if the code I wrote for version X is expected to need modification to work c…

Arguably a language should NEVER have breaking changes large enough to warrant a SemVer major version update. Rename or fork the language if you want to do that. Such major language overhauls in the past have been a huge waste of developer time as they go back to rewrite affected code.

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

Re: Go Replaces Interface{} with 'Any'

#296

Post by MereInterest »

kelnos wrote: post #189
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…

> 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 library that needs to be compatible with C++11, then I need to write my own make_unique(). If I'm working on a library that needs to be compatible with C++14, then I need to avoid using structured bindings.

If a project allows breaking backwards compatibility, then SemVer is a great way to put that information front and center. If a project considers backwards compatibility to be a given, then there's no point in having a constant value hanging out in front of the version number.

> I mostly care whether or not code written assuming version X can be compiled with version Y of the compiler.

Semantic versioning can only tell that for the case where X Y (new code on old compiler), you need to know when features were introduced.

Re: Go Replaces Interface{} with 'Any'

#297

Post by eru »

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.

Go is ok-ish, if you use small programs and solve exactly the same problems the language designers had in mind in exactly the same ways the language designers had in mind.

The constant repetition and near-but-not-quite copy-paste boilerplate everywhere makes it hard to spot the crux of what's actually going on.

Re: Go Replaces Interface{} with 'Any'

#298

Post by skybrian »

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…

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] https://pkg.go.dev/go/ast#Inspect

Re: Go Replaces Interface{} with 'Any'

#300

Post by eru »

3a2d29 wrote: post #289
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.

Surely Python gets that honor over Go. As much as I like Go, Rust, C, over Python, I would never say the reason is readability.

Python is quite readable for short snippets.

It can be quite a mess for larger systems.

That combination of trade-offs makes it a great language to solve interview style problems in on a white board.

You can alleviate those larger scale problems in Python a bit with good IDE support, embracing type annotations, and going with a style that prefers immutability over action-at-a-distance.

Post reply on HN