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

381–390 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#381

Post by koffiezet »

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 agree with the parent though, Go code is super-readable and accessible. I've coded actual useful stuff in Java, C, C++, Pascal, Python, PHP, Pascal, Basic, (Jenkins) Groovy, Typescript, Javascript - and am probably forgetting some.

I also dabbled around in Rust and a bunch of other languages, but I wouldn't call that experience, although when it comes down to the initial accessibility and impressions, in this context, that is relevant I think. Go was hands down the most readable and accessible of the bunch, which probably has some roots in having a C/C++ background, and it being a pretty simple language.

Dev-env wise, it used to be a mess with the GOPATH etc, but that has mostly been resolved. And once past that, it was easily the language I picked up the quickest. It took me 2 or 3 days to actually write something useful. I've jumped head-first into codebases of large projects without even thinking about it, which I would have been very hesitant about if they had been written in another language. I've had to do that plenty for C++ and Java projects, but that always took some convincing of myself, and was never a pleasant experience.

Re: Go Replaces Interface{} with 'Any'

#382

Post by coopierez »

ogogmad wrote: post #380
Cthulhu_ wrote: post #377

Earlier quoted context omitted.

I hear what you're saying, but why make one language look like another when that other language is more suitable for those purposes (graphics and deep learning)? Isn't Python the go-to language for deep learning? It's probably better to stick to that one, because the field itself is hard enough already - learning another language on top will just put people off.

I appreciate the broad philosophy of Go, which is that it's a simple language. Much simpler than Python which (and this is subjective) has made some questionable design choices. I also like how it's not exotic or surprising; you can just get straight to hacking. I also like that Go is fast. It appears that some Python code is being rewritten in Go to make it go faster. Python's slowness is a problem in both the areas…

> Much simpler than Python which (and this is subjective) has made some questionable design choices.

One of the reasons golang is so simple is that they move very carefully on issues like this. It has its benefits and its drawbacks.

Adding operator overloading kind of opens a can of worms here. If they add that, why not arithmetic types? Why not exceptions? Why not x, y, z... Everyone wants just _one_ extra feature that would improve the language. Trouble is everyone disagrees on what that one feature should be.

Re: Go Replaces Interface{} with 'Any'

#383

Post by nvarsj »

Cthulhu_ wrote: post #375
nvarsj wrote: post #109

Earlier quoted context omitted.

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.

What alternative do you propose?

There's many options, just look at other modern languages. The simplest are exceptions/errors that can be thrown - like you get in Java, python, typescript, etc. For something more like a traditional return value, you have std::result in rust, and error union types in zig, with language support to guarantee you check and handle the result. In C, you have macros and goto that can be used to reduce boilerplate and implement whatever pattern you want.

Re: Go Replaces Interface{} with 'Any'

#384

Post by [deleted] »

Cthulhu_ wrote: post #378
welder wrote: post #70

Good, now we just need the ability to declare function parameters and return values non-nullable (Forbid passing nil into a function, and declare a function will never return nil). That would get rid of the "panic: runtime error: invalid memory address or nil pointer dereference" errors. https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...

> Good, now we just need the ability to declare function parameters and return values non-nullable But that's already possible, just declare arguments and return values as values instead of references. I mean you'll get the zero value if you don't use those functions properly, but those won't cause nil pointer dereference errors. I mean, it's a tradeoff between performance and developer competency. To be harsh, I thi…

[deleted]

Re: Go Replaces Interface{} with 'Any'

#385

Post by ljm »

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.

Also for systems relying on continuous delivery in some form, like websites and web apps and SaaS. Because as a user you don't actually have a choice to use an update or stay on an old one.

Considering most places I've worked at just bump the minor number in perpetuity, a date-based version conveys a bit more info. Also so much easier to know when it's going out if you have a release cycle (e.g. you don't have to guess what date 3.12354.0 is going to prod, you would know it already from a version like 2021.12.25).

Re: Go Replaces Interface{} with 'Any'

#386

Post by kubb »

rp1 wrote: post #213
kubb wrote: post #195

Earlier quoted context omitted.

Basically macros, like in Rust, not like in C. Rust can do stuff like the serde serialization library while Go has to rely on reflection with its obvious performance drawbacks.

Go could do something similar if you're willing to run `go generate` as part of your build process. For most Go applications, the reflection overhead is a fine price to pay for convenience, just like GC is a fine price to pay for not having to deal with the borrow checker. Obviously, these tradeoffs don't hold for all programs, but Go has definitely found a niche.

I'm not sure what you're arguing with. I know these things. I'm still missing the ability to have efficient serialization (as one example) easily. It matters.

Re: Go Replaces Interface{} with 'Any'

#388

Post by ljm »

klyrs wrote: post #249
meowface wrote: post #47

Earlier quoted context omitted.

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

Not the git hashcode?

Semver and calver are sequential, so you can easily sort them and compare versions in terms of age. So you would know that jumping from 1.8 to 3.0 for example could be quite large.

You can't do the same with git commit hashes because you can't sort them based on the hash alone. I have no idea how to compare deadbeef and cafebabe without checking the code itself.

Re: Go Replaces Interface{} with 'Any'

#389

Post by necovek »

quietbritishjim wrote: post #373
necovek wrote: post #361

Earlier quoted context omitted.

(FWIW, "semantics" would be "what it means", so I figure that's not what you wanted to say: from your example, I guess you are saying it's more that it's a different wording — syntax? — for the same meaning) But it's about setting expectations. The only problem I ever had with py2 to py3 migration was that it was even possible to have the same codebase run against both, when languages are incompatible to such a degre…

Semantics refers specifically to meaning of words/language. If you say "it's only semantics" then it probably means you both understand and agree on the concepts but not the meaning of the words surrounding those concepts. That applies in this case, with the concept being breaking changes to a language along the lines of Python 2->3, and the terms being "version change" and "new language".

Makes sense, thanks.

Re: Go Replaces Interface{} with 'Any'

#390

Post by chmod775 »

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…

> 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

There's a few other languages out there that work that way. The split is probably is probably 20/80. Though "popular" languages heavily learn towards Java-esque interfaces - with TypeScript and Go being the odd ones in that bunch.

Post reply on HN