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

271–280 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#271

Post by lolive »

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.

Newer is not always better. So I prefer to stay behind a little, if I can. [I stayed away from JavaScript until ES6 and Typescript. And I think I avoided myself a lot of headaches being that cautious]

Re: Go Replaces Interface{} with 'Any'

#272

Post by lolive »

lolive wrote: post #271
bearcherian wrote: post #236

Earlier quoted context omitted.

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.

Newer is not always better. So I prefer to stay behind a little, if I can. [I stayed away from JavaScript until ES6 and Typescript. And I think I avoided myself a lot of headaches being that cautious]

Oh. And and at one moment in my career, I had to jump into serious web dev ;(

But it was just after the death of IE ;) [Call me lucky]

My 2 cents: widespread adoption is not synonym with long term perenity.

Re: Go Replaces Interface{} with 'Any'

#273

Post by lanstin »

politician wrote: post #232
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.

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

There is a reason very robust software is written in C: no exceptions means you think about normal errors all the time and reason about what the difference bwtween an error openjng the file and an wrror writing the file. Sqlite, linux, cpython, all bullet proof and all C. The lack of exceptions more than makes up for memory unsafety issues.

Re: Go Replaces Interface{} with 'Any'

#274

Post by stormbrew »

latortuga wrote: post #208
stormbrew wrote: post #205

Earlier quoted context omitted.

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…

This seems like it would apply to literally any new feature - new code won't compile on an old compiler. It isn't the purpose of semver though, semver is trying to help you upgrade old code safely.

I think the thing, to me, is that semver is very useful where these things are purely mechanical. This (at least usually) applies to libraries. Semver enables things like lockfiles as used by ruby bundler and later cargo and various other things. But not all systems are upgraded in mechanical ways, and not all 'breaks' are purely mechanical.

This is why you can't really use semver (usefully) for everything. What's a "breaking change" in a word processor?

Languages aren't used like word processors, but they also aren't exactly used like libraries either. People get stuck on language versions for different reasons than why they get stuck on library versions.

At any rate I think in practice I think languages that are trying to hew to semver concepts like this just wind up with a 'fake major version'. Since Rust, for eg., might never go to 2.x the 1. in front of 54 is really just academic. That's the "real" major version as far as anyone needs to know.

A lot of the arguments in this thread seem to be kinda tautological. There's no law that says they have to use semver, nor is there a law that says semver can't be imperfect. "Semver is semver because semver says so" is not a compelling argument.

Re: Go Replaces Interface{} with 'Any'

#275

Post by randomdata »

linkdd wrote: post #169
randomdata wrote: post #161

Earlier quoted context omitted.

> It implies that the expected behavior is the "happy path" (everything went well) and any deviations (errors) is unexpected. Errors are the "happy path", though. Your network connection was lost for the data you were trying to transmit so you saved it to your hard drive instead means that everything went well! Throwing your hands up in the air and crashing your program because you had to make a decision is not somet…

> Throwing your hands up in the air and crashing your program because you had to make a decision is not something you would normally want to do And that's not something you do thanks to try/catch. You just handle the error where it's meaningful to handle it. The happy path of "make a request" is that there is no network error. The happy path of "make sure this request is sent" is that you handle the unexpected networ…

> And that's not something you do thanks to try/catch. You just handle the error where it's meaningful to handle it.

And it is always most meaningful to handle it immediately, so what's the point of introducing a application-wide goto jump, amid Dijkstra's warnings that doing so is harmful when you're just going to catch right away anyway?

> The happy path of "make a request" is that there is no network error.

If there is a network error, you're still happy. It is not like you screwed up as a programmer. What is there to be unhappy about? The network error input to your function is very much expected and part of the "happy path" as much as any other input to your application.

> if there is an unexpected network failure, let it crash

Network failures are never unexpected. It would be exceptional to never experience a network failure.

> How do you check which errors you want to handle and which one you want to propagate with just a string describing your error?

Why would your errors be strings? When errors are just plain old values like any other it is true that you could resort to using strings to represent errors, but it would be quite unidiomatic to do so. Kind of like how you can overload exceptions to handle errors, but just because you can does not mean you should.

Re: Go Replaces Interface{} with 'Any'

#276

Post by killingtime74 »

jcadam wrote: post #40
vlunkr wrote: post #29

Earlier quoted context omitted.

While it's good to get up-to-date, I don't think anyone should go re-write code or radically change their programming style to use generics. There's no need to over-complicate things. Anywhere that you're either copy-pasting a bunch, or using code generation might be a good fit for generics.

Just you try not being up-to-date in a coding interview.

I’ve only ever been offered to pick my own language in interviews (so I always pick Python). Is this not your experience?

Re: Go Replaces Interface{} with 'Any'

#278

Post by swagonomixxx »

eru wrote: post #254
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…

You could separate the semantic version from the PR version. The PR version doesn't even have to be numeric. You can give them proper names.

Disagree with this. Most middle managers wouldn't understand the difference. One canonical version is enough, any more and there's just confusion, not enlightenment.

Re: Go Replaces Interface{} with 'Any'

#279

Post by valenterry »

jshen wrote: post #233
pawelmurias wrote: post #163

Earlier quoted context omitted.

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.

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.

Post reply on HN