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

Expectations for generics in Go 1.18

groups.google.com

Post reply on HN
Print view View original

201–209 of 209 posts

Re: Expectations for generics in Go 1.18

#201

Post by iamcreasy »

effdee wrote: post #146
iamcreasy wrote: post #106

Earlier quoted context omitted.

I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.

Pressing ga in command mode in Vim displays the ASCII / Unicode value of the character under the cursor.

Yes, but IntelljIDEA's Linter showed me the error. Without linter you'll need compiler/interpreter to tell you something is not right.

And in my case, even if compiler / interpreter reported about an invalid syntax - I would not think of checking the unicode codepoint as it the character appeared to look exactly like semicolon.

Re: Expectations for generics in Go 1.18

#202

Post by javier2 »

benhoyt wrote: post #4
dgunay wrote: post #2

Very reasonable caveats for a feature as big as generics. Personally, I'm super excited for the potential generics has to make error handling in Go less noisy, so I'll be attempting to use it ASAP.

Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics? You want to return early (and potentially add context to the error) if there was an error, otherwise continue on. How are you thinking of solving this with generics? The previous try() proposal added new control flow. That's part of the reason it was criticized so heavily -- it hid a control flow construct in something…

It is both, because multiple return values break function chaining.

Re: Expectations for generics in Go 1.18

#203

Post by arc619 »

Kranar wrote: post #68
rustnote wrote: post #49

Earlier quoted context omitted.

So there's a runtime cost for using generics?

The linked article is a proposal but at least when I tried Go a couple of weeks ago, it did not use that approach and to the best of my knowledge that proposal has not yet been implemented. Instead as of now Go uses the straight forward approach of generating one implementation for every instantiation just like C++ compilers do. The upside is there is no runtime cost to using generics, the downside is there is signif…

> the downside is there is significant compile time and link time cost to generics.

Are we talking statistically significant or productivity significant compile time cost? Go has a fairly fast compiler, it would be a shame if generics made that a less stand-out feature.

Re: Expectations for generics in Go 1.18

#204

Post by dnautics »

topspin wrote: post #200
dnautics wrote: post #194

Earlier quoted context omitted.

Have you seen what a "rich error struct union" looks like in zig? It's very easy and very legible code. I'd further bet that there are no cases when you're doing this that you want an error return trace. And the downstream handling code is very easy. If there is a problem with how it's done in zig, it's a community one: maybe the pattern needs a megaphone beside it, like examples in the main docs or tuts in the vario…

"Have you seen what a "rich error struct union" looks like in zig?" No, and I'm not arguing that zig hasn't done well. I do argue that Go has not; you're only non-weird choice is to fetter code with miles of "if err ==/!=" gymnastics. Traces are frequently very useful; precise traces have saved me a lot of pain in life. Lack of traces precludes nothing for me, but I have enjoyed the benefit of them enough times to ac…

Traces are fantastic for unexpected errors. You don't need them, for example, when validating user input, which is the type of system where you want richer errors.

Re: Expectations for generics in Go 1.18

#205

Post by earleybird »

Cthulhu_ wrote: post #111
LudwigNagasena wrote: post #97

Earlier quoted context omitted.

In 10 years a new word may become fashionable. Better to keep technical terms the same.

It's not about fashion, it's about cultural identity. I take it you don't see a problem with master/slave either? Just do a find and replace, refactoring is easy and trying to argue on the internet about it is tiring.

If identity is about appearance, that would seem to admit fashion for consideration.

Re: Expectations for generics in Go 1.18

#206

Post by masklinn »

Zababa wrote: post #172
masklinn wrote: post #169

Earlier quoted context omitted.

You’re confusing the chicken for the egg. Sum types are a powerful language feature, but they’re also a general language feature, they don’t exist for the sole purpose of creating a Result type (and indeed a number of languages have had the former and lacked the latter).

Do you mean that in contrast to affine types, that are here for borrow checking?

No, I mean that in contrast to the other side of the discussion (zig’s errors).

And affine types are not here for borrow checking, it’s closer to the opposite. Affine types are a formalisation of RAII, borrow checking is a way to make references memory-safe without runtime overhead which mostly avoids unnecessary (and sometimes impossible requiring allocations & refcounting) copies of affine types.

Re: Expectations for generics in Go 1.18

#207

Post by blondin »

arp242 wrote: post #55
blondin wrote: post #40

Earlier quoted context omitted.

is it really the case that parsers can't tell the greater than sign in "a, b = w (z)" without type information? or is it simply difficult to parse for some parsers?

It's a problem all languages with need to solve one way or the other; see e.g. https://blog.dyvil.org/syntax/2016/04/19/angle-bracket-gener... So for C# it's resolved "by examining the token after the closing >: If it is one of (, ), ], :, ;, ,, ., ?, == or !=, the expression is parsed as a generic method call." I assume this works reasonably well; however, it's not hard to see how this might be a problem in some cas…

thanks for explaining :)

Re: Expectations for generics in Go 1.18

#208

Post by ipmonkey »

iamcreasy wrote: post #106
topspin wrote: post #20

Earlier quoted context omitted.

On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?

I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.

vim user here. Most of us are running the same linters and language servers as every other major editor, which does a pretty good job catching stuff like this. Modern vim is really only a C core with a web of JS, Python, Lua, and vimscript using the exact same third party solutions for every other part of an "IDE". emacs is probably similar, but no personal experience with that.

Re: Expectations for generics in Go 1.18

#209

Post by ipmonkey »

topspin wrote: post #25
benhoyt wrote: post #4

Earlier quoted context omitted.

Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics? You want to return early (and potentially add context to the error) if there was an error, otherwise continue on. How are you thinking of solving this with generics? The previous try() proposal added new control flow. That's part of the reason it was criticized so heavily -- it hid a control flow construct in something…

"Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics?" It's both. Adding only concise flow control, such as with the ? operator, works poorly if all you can return is multiple non-generic values; various common permutations get awkward in that case. And as you point out Result doesn't achieve much without the concise operators. Rust has very successfully shown the benefi…

Early return is definitely a part of the problem. One thing you could do with generics is create option/result wrappers that would work with any code and hack together a try/early return solution using panic/recover, but you'd offend the Go community, and at that point you might as well just use Rust.
Post reply on HN