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

Notes on the Go2 Generics Draft

jmoiron.net

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Notes on the Go2 Generics Draft

#81

Post by stochastic_monk »

nicoulaj wrote: post #75
jy3 wrote: post #60

Earlier quoted context omitted.

That means Go is not the right tool for you. Don't use it. It's so sad to see people pushing to radically alter a language that they will probably never use because it will never be suitable for their needs.

So what is the use case for Go exactly ? Programs that don't need to put numbers in containers ?

You didn't ask me, but the people I know using it are primarily writing networking or cryptographic code.

My biggest complaint about Go is the lack of generics; I bet they're just trying to get more adoption. That being said, adding generics won't eliminate all the other things I dislike about the language.

Re: Notes on the Go2 Generics Draft

#82

Post by xfer »

giovannibajo1 wrote: post #77
pjmlp wrote: post #53

Earlier quoted context omitted.

How much would had it achieved if it didn't had the Google logo to go along it? Lets say developed at SV startup XYZ instead.

There’s precedent that Google’s brand doesn’t make people magically swallow programming languages without thinking: Dart. I think it’s disingenuous to reduce Go success to some Google marketing operation. I dislike Google as a brand in the way they design products and their weak privacy stance, but I love Go nonetheless.

Go is also similar to languages like limbo/newsqueak. None of those are popular(many might not have even heard of them). So part of success definitely goes to being successfully marketed as a google product.

Re: Notes on the Go2 Generics Draft

#83

Post by cyphar »

euyyn wrote: post #74
cyphar wrote: post #21

Earlier quoted context omitted.

> hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers I'm a day-to-day Go developer and maintain some of the most widely used Go projects out there. While I understand their wish to do things "slow and steady" there were several other missteps and double-downs by the language designers that left me with a bi…

Why do you think, from your experience, it is not a systems programming language?

You cannot write a single-threaded program in it (GOMAXPROCS doesn't do what you probably think it does), and the green threading until very recently didn't obey runtime.LockOSThread which meant that you couldn't even guarantee that a function would execute on the same logical thread (which is critical for certain syscalls).

cgo (which is unfortunately necessary if you have C library dependencies) has significant issues like not being able to support union conversion to a Go type -- which means that you have to write helper functions in C and call those to access unions. This is part of a more generic problem that the memory safety model doesn't lend well to systems programming (and unsafe.* is just too scary to be usable everywhere).

Oh, and the syscall package is effectively deprecated and you now have to switch everything to golang.org/x/sys/unix in order to use it properly (though one of the maintainers does nicely send PRs to projects often). This indicates to me that not enough people tested that the "syscall" package interface made sense in the 9 years before 1.0 and the stability guarantee set in (which means that the code which is very important for a systems programming language wasn't widely tested).

If you want to (for instance) use AT_FDCMD with openat(2) you won't be able to because all of the syscall bindings require file descriptors to be a uint -- despite the kernel interface using an int (and the fact that AT_FDCMD is -100 or something like that). Yet they use AT_FDCMD internally -- which means they know it is needed but they elected not to expose this to users.

It uses the "int" type for PIDs instead of using pid_t, for crying out loud. No systems programming language should do that.

Re: Notes on the Go2 Generics Draft

#84

Post by pjmlp »

giovannibajo1 wrote: post #77
pjmlp wrote: post #53

Earlier quoted context omitted.

How much would had it achieved if it didn't had the Google logo to go along it? Lets say developed at SV startup XYZ instead.

There’s precedent that Google’s brand doesn’t make people magically swallow programming languages without thinking: Dart. I think it’s disingenuous to reduce Go success to some Google marketing operation. I dislike Google as a brand in the way they design products and their weak privacy stance, but I love Go nonetheless.

Dart suffered from Google politics, trying to take over JavaScript, and then being dropped by Google's own teams (Chrome and Angular).

Being rescued by AdWords team, and now having Flutter team as their last hope.

Go hasn't suffered from such politics.

Let's not forget that Go is a mix of Oberon-2 and Limbo, both a failure regarding market adoption, in spite of their technical qualities.

Re: Notes on the Go2 Generics Draft

#85

Post by baby »

zoul wrote: post #76
baby wrote: post #68

Earlier quoted context omitted.

Same here, as a security consultant reading Golang is always a pleasure. I'm pretty sure that the strongest codebases I've seen were in Golang just because of how easy it is for everyone to read the code and actually spend time looking for logic bugs instead of trying to understand what is happening. Developers love to be able to write their magical code and their clever abstractions and often forget that their code…

Developers love to be able to write their magical code and their clever abstractions and often forget that their code is paying the price by becoming less clear and less readable. Are you saying that it has to be that way with generics? Because I would disagree with that. Cautiously applied, generics can make your code more clear, more readable and, most importantly, more type safe – and not just because of container…

Yes it will be this way for MOST usages with a minor subsets of codebases which will benefit from them.

Re: Notes on the Go2 Generics Draft

#86

Post by zimbatm »

civility wrote: post #57
nemo1618 wrote: post #24

I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…

Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.

Maybe that's the issue. From what I have seen, the lack of generics mainly becomes painful when working in the numerical space. If I work on mapping JSON, doing APIs and CLIs I don't really need generics. If I work on algorithms and data bags then it starts to be annoying re-implementing the same thing over and over again.

So in these discussion you have devops-type people mainly dealing with APIs that are perfectly content. And the ones that work with algorithms are talking past them because they don't experience the same pain.

Instead of changing the language to enable generics everywhere, maybe there is a lighter version that exists that only applies to numerical problems. Is it possible that a boxed "Number" type would solve most of the problems?

Re: Notes on the Go2 Generics Draft

#87

Post by civility »

cdoxsey wrote: post #59
civility wrote: post #57

Earlier quoted context omitted.

Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.

Ironically generics don't necessarily solve this. C# requires multiple implementations of numeric methods because int/float/etc don't sit in a type hierarchy. It also doesn't really work in Java either because you have to use the Object types. Even in rust this looks pretty complicated: https://travisf.net/rust-generic-numbers Maybe it's easy in c++? I've seem a similar comment made on almost every discussion of this…

Yes, it works well enough in C++. It would be nice if another language, without C++'s other pitfalls, got some of this right.

Btw, it's "ironic" that you think pointing at two broken implementations says anything about where it works. "Are folks just not aware" it's ridiculous to be snarky when arguing from a position of ignorance?

Re: Notes on the Go2 Generics Draft

#88

Post by phamilton »

zimbatm wrote: post #86
civility wrote: post #57

Earlier quoted context omitted.

Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.

Maybe that's the issue. From what I have seen, the lack of generics mainly becomes painful when working in the numerical space. If I work on mapping JSON, doing APIs and CLIs I don't really need generics. If I work on algorithms and data bags then it starts to be annoying re-implementing the same thing over and over again. So in these discussion you have devops-type people mainly dealing with APIs that are perfectly…

> mapping JSON

I find that an ideal set of tools allow us to describe our task and write our code using the same idioms.

The fact that "mapping JSON" doesn't actually involve calling "map" on JSON data is a great example of why not having generics in golang is frustrating for me.

Re: Notes on the Go2 Generics Draft

#89

Post by everybodyknows »

mort96 wrote: post #71
nemo1618 wrote: post #24

I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…

I'm curious, what's a better solution for generics if you want some kind of container which doesn't need to care what type it contains? Is the better solution to just use the current C-style void* s everywhere and manually cast your objects to and from void* (or in Go's case, interface{}), leaving type safety to the programmer? Or is the argument that people shouldn't need to write containers, and all necessary conta…

Code generation by means of Go's standard template library has worked nicely for me. Best of all, gdb sees the concrete type, so value inspection stays easy.

Only snag, minor enough, is that emacs auto-indent becomes confused by the double braces, as in "{{.templateVar}}".

Re: Notes on the Go2 Generics Draft

#90

Post by civility »

jy3 wrote: post #60
civility wrote: post #57

Earlier quoted context omitted.

Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.

That means Go is not the right tool for you. Don't use it. It's so sad to see people pushing to radically alter a language that they will probably never use because it will never be suitable for their needs.

No, Go is not currently the right tool for me, but it's close, and it would be much closer with (usable) generics.

What's "so sad" is you think this Reddit style "Don't use it" imperative is an acceptable way to talk to people. You're rightfully afraid of complexity creeping into an otherwise clean language, but it would suck less if you said it better.

Post reply on HN