Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go generics are not bad

lemire.me

Post reply on HN
Print view View original

281–290 of 305 posts

Re: Go generics are not bad

#281

Post by anonymoushn »

throwaway894345 wrote: post #263
anonymoushn wrote: post #246

Earlier quoted context omitted.

Sure, if any method anywhere takes a pointer receiver, then anyone can declare an interface that matches that method, and that interface is (among other things) like an Option > in Rust or a ??T in Zig. It's weird to post "There is no inner/outer nil" since the most straightforward interpretation of that claim is that there is no None/Some(None) distinction, and this is straightforwardly not true. For some reason, mo…

> the most straightforward interpretation of that claim is that there is no None/Some(None) distinction, and this is straightforwardly not true. That’s not the most straightforward interpretation, since it would invalidate the original criticism that I responded to (that Go more-or-less uniquely requires you to check inner/outer nil). > For some reason, most languages do not encourage the users to create types that a…

A difference between Go and Java is that a null Regex in Java will not be implicitly converted to a non-null Stringable containing a null Regex.

If you'd like, I can post about "implicit conversion from nil pointers to non-nil interfaces containing nil pointers that can only be checked for nil using reflection, combined with interfaces that work by duck typing and an existing body of code that pervasively uses struct pointer receivers in methods that panic when passed a nil pointer, even if it was a nil pointer contained in a non-nil interface" but that's a bit of a mouthful.

Re: Go generics are not bad

#282

Post by grumpyprole »

germandiago wrote: post #278
grumpyprole wrote: post #256

Earlier quoted context omitted.

Such a function can still be pure on the outside. This is real (state) encapsulation, not the encapsulation sold to you by OOP vendors.

Ok but there was discussion about Haskell so I was sticking to that... of course if you can have functional as an extra without preventing imperative in the low level then you can apply the best of both worlds.

Haskell let's one write fast imperative code when needed or call C functions.

Re: Go generics are not bad

#283

Post by erik_seaberg »

kgeist wrote: post #172
cookiengineer wrote: post #171

Earlier quoted context omitted.

The point of described scenario was to have a _different_ if/elseif branch, and not the identical behaviour for one struct type. If item instanceof HouseStruct {} Elseif item instanceof ContainerStruct {} With your suggested solution you end up with OOP fatigue and GenericBuildingImplementationStruct which is probably not what golang wanted to embrace with their type system.

I'm not sure I follow what you mean. In Go the equivalent to your example is: switch val := item.(type) { case HouseStruct: case ContainerStruct: }

Doesn’t type switch require an interface value? Go tries not to add boxing-like overhead to generics.

Re: Go generics are not bad

#284

Post by Matl »

ratww wrote: post #275
Matl wrote: post #252

Earlier quoted context omitted.

> Who cares if it’s cheap and tiring, it’s the truth. You do realize that is a matter of personal opinion, right? There's plenty of developers who like the language, (doesn't mean they're not seeking to always improve it), then there's those who hate it. But a comment from someone who loves Go but says nothing more as to why would be equally as useless as a generic comment from someone less found of it. They're free…

No. It's not a matter of personal opinion. Go indeed lacks "several features, including safety features, that help people perform their job better". Whether you're one of those people and whether the language really needs those features is a different issue. But when it comes to modern languages Go stands out for lacking several important features. And of course no language "needs" most features: as long as it's Turi…

> No. It's not a matter of personal opinion. Go indeed lacks "several features, including safety features, that help people perform their job better".

That is a subjective statement. There's no objective list of language features that make a programmer's job better. I'd like to see optional types in Go, but I can't say that it would objectively make the vast majority of programs I've written better, not to say about the wider community.

I liked the error handling proposal from the Go team, but the wider community rejected it. Was it 'objectively bad'?

I could go on and on.

> What people are trying to have here is starting discussion of possible paths for the language to grow, no matter how crude that "start" is. It is "cheap" criticism? Sure,

My problem is exactly that this is not the case. You don't start a discussion on 'possible paths' towards improvement without actually discussing any concrete path.

Take a look at Swift for example, which even its original author stepped away from due to in part constant onslaught of features at the expense of wider design considerations, (as he perceived it).

Go could certainly go faster, but I do think the 'how fast' is a delicate balance that doesn't have a simple answer.

It merely looks like the typical HN mantra on programming languages. It's like posting about Rust in every thread on C++. I am someone who happens to like Rust but I don't think doing that would win us many fans.

In many ways OP's criticism is even less concrete.

Re: Go generics are not bad

#285

Post by tapirl »

silisili wrote: post #265
tapirl wrote: post #204

Earlier quoted context omitted.

You don't need to buy it. It is free for reading online, and most contents in my website are free. "insulting"? That is a too heavy word.

I rather agree, and must apologize as English seems to be slipping from me lately. I spent some time trying to think of the right word, but ended on insult, debating whether that was too negative of a word to use. Perhaps dismissive would have been better?

It is just too simple to draw a conclusion. And IMHO, it is not very generics related.

Re: Go generics are not bad

#286

Post by [deleted] »

erik_seaberg wrote: post #283
kgeist wrote: post #172

Earlier quoted context omitted.

I'm not sure I follow what you mean. In Go the equivalent to your example is: switch val := item.(type) { case HouseStruct: case ContainerStruct: }

Doesn’t type switch require an interface value? Go tries not to add boxing-like overhead to generics.

[deleted]

Re: Go generics are not bad

#287

Post by tored »

kgeist wrote: post #261
iasay wrote: post #162

Earlier quoted context omitted.

That’s actually a brilliant assertion (sorry for the crap pun). The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job. Go makes them deal with it.

When we were rewriting a module in our backend from PHP to Go, explicit error handling helped us find and fix bugs due to edge cases we weren't even aware of. The usual idiom in PHP was to just catch exceptions at the top level and show an error (I think that's what exception handling usually devolves to). Since in Go we were explicitly handling errors at every level in the chain, it forced us to reason about error c…

Now I don't know how your PHP code was structured, but in my experience there usually three types of mistakes done with error handling in PHP code

1) not properly checking return values from standard library functions

2) not checking correct last error level function after use of standard library function, e.g. json_last_error(), curl_errno() etc

3) different handling of old style errors vs exceptions

This is an unfortunate legacy of PHP, it is messy and error prone.

I'm not a golang programmer but to my understanding is that the golang compiler does not enforce strict error handling, if a function changes its signature to start returning an error when it previously didn't is not something the compiler will warn about. This is unfortunate too.

I never really been a huge fan of exceptions either, but the good thing about exceptions is that they are not silent by default whereas return values can be ignored and therefore errors can missed.

What I'm trying to say is that we need stricter compilers.

My personal style of coding in PHP to avoid hidden bugs is to code in defensive style, where the unhappy path is as important as the happy path, combined with strict type handling where I try to use the type system to detect bugs.

Re: Go generics are not bad

#288

Post by ratww »

Matl wrote: post #284
ratww wrote: post #275

Earlier quoted context omitted.

No. It's not a matter of personal opinion. Go indeed lacks "several features, including safety features, that help people perform their job better". Whether you're one of those people and whether the language really needs those features is a different issue. But when it comes to modern languages Go stands out for lacking several important features. And of course no language "needs" most features: as long as it's Turi…

> No. It's not a matter of personal opinion. Go indeed lacks "several features, including safety features, that help people perform their job better". That is a subjective statement. There's no objective list of language features that make a programmer's job better. I'd like to see optional types in Go, but I can't say that it would objectively make the vast majority of programs I've written better, not to say about…

> There's no objective list of language features that make a programmer's job better.

Quite the contrary, the list is often very objective. People know what makes them more productive. It’s just not a single list for everyone. This is why people engage in language criticism: to push for features THEY want.

You say “don’t use the language”, we say “we use what we want, maybe you don’t use the features”.

> You don't start a discussion on 'possible paths' towards improvement without actually discussing any concrete path.

Read the whole thread. It started with concrete paths: functional operators like map/reduce/etc.

The suggestion was promptly dismissed by the people against changes in Golang by calling it “type system fidget spinners”. That’s a lowbrow dismissal and an attempt to nuke civility.

The poster you attacked was replying to that. So they must “propose changes” on every single post, even on meta posts replying to your crowd?

The only people behaving badly here so far are the anti-change people.

This is what I’m addressing. I’m not asking for features. I’m asking for your crowd to stop behaving like children.

Re: Go generics are not bad

#289

Post by kgeist »

tored wrote: post #287
kgeist wrote: post #261

Earlier quoted context omitted.

When we were rewriting a module in our backend from PHP to Go, explicit error handling helped us find and fix bugs due to edge cases we weren't even aware of. The usual idiom in PHP was to just catch exceptions at the top level and show an error (I think that's what exception handling usually devolves to). Since in Go we were explicitly handling errors at every level in the chain, it forced us to reason about error c…

Now I don't know how your PHP code was structured, but in my experience there usually three types of mistakes done with error handling in PHP code 1) not properly checking return values from standard library functions 2) not checking correct last error level function after use of standard library function, e.g. json_last_error(), curl_errno() etc 3) different handling of old style errors vs exceptions This is an unfo…

>if a function changes its signature to start returning an error when it previously didn't is not something the compiler will warn about.

This is why we use linters, they can catch this kind of problem.

Re: Go generics are not bad

#290

Post by [deleted] »

anonymoushn wrote: post #281
throwaway894345 wrote: post #263

Earlier quoted context omitted.

> the most straightforward interpretation of that claim is that there is no None/Some(None) distinction, and this is straightforwardly not true. That’s not the most straightforward interpretation, since it would invalidate the original criticism that I responded to (that Go more-or-less uniquely requires you to check inner/outer nil). > For some reason, most languages do not encourage the users to create types that a…

A difference between Go and Java is that a null Regex in Java will not be implicitly converted to a non-null Stringable containing a null Regex. If you'd like, I can post about "implicit conversion from nil pointers to non-nil interfaces containing nil pointers that can only be checked for nil using reflection, combined with interfaces that work by duck typing and an existing body of code that pervasively uses struct…

[deleted]
Post reply on HN