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

How generics are implemented in Go 1.18

github.com

Post reply on HN
Print view View original

111–120 of 228 posts

Re: How generics are implemented in Go 1.18

#111

Post by mikojan »

kerkeslager wrote: post #91

So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go's type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple. Oh and it was really important to Gophers that Go compiles in a single pass (which I argued is only relevant for truly enormous codebases like Google's). A few ye…

> Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed.

It is not Go that is struggling. It is you. Does literally every language have to turn into Java?

Re: How generics are implemented in Go 1.18

#112

Post by MobiusHorizons »

staticassertion wrote: post #102
throwaway34241 wrote: post #100

Earlier quoted context omitted.

I’m not going to defend what random internet commenters may have said, but in my view the core team has been fairly consistent and their design decisions (to me) make sense. The first thing to understand is that Go occupies a space lower level than Java but higher level than C. It includes things like explicit pointers and more control of memory layout. Many of the design decisions make no sense without that context.…

How is Go lower level than C#?

One major difference that makes Golang lower level is that it compiles to machine code for the target CPU arch/OS instead of bytecode.

Re: How generics are implemented in Go 1.18

#113

Post by 4ad »

layer8 wrote: post #28

Does Go support separate compilation? The approach sounds like a change in the implementation of a generic function (changing the gcshapes) could cause client code to break unless it is recompiled as well. What am I missing?

You say "separate compilation", but what you are really asking is whether Go supports forward-compatible shared libraries.

Go does separate compilation, it's an extremely important property for Go.

Go code can be built as a shared library, loadable by both C or Go code, albeit this is an unusual use case for Go.

However, when multiple Go shared objects are to be linked together, they must share the same Go version, including the toolchain version, so there is no forward compatibility.

Re: How generics are implemented in Go 1.18

#114

Post by valenterry »

omginternets wrote: post #109
kerkeslager wrote: post #91

So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go's type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple. Oh and it was really important to Gophers that Go compiles in a single pass (which I argued is only relevant for truly enormous codebases like Google's). A few ye…

Where does this cause problems for you in practice? Where is the usefulness of goroutines limited practically ? Where is the complex notion of a compiler pass causing problems? I’m very open to the idea that I’m suffering from a problem I don’t know I have, but right now you’re just asserting that problems exist without actually telling us how to recognize them.

I think OP didn't even start using go in practice, so the question doesn't help.

But I can say that it's the same ad with natural languages. No one ever feels that their mother tongue is limiting, until they learn a new and very different language and learn a pattern/style that they cannot apply in the mother tongue.

Re: How generics are implemented in Go 1.18

#115

Post by vyskocilm »

FooBarWidget wrote: post #7
kevin_thibedeau wrote: post #5

Earlier quoted context omitted.

The compile time issues for C++ are entirely because of the creaky header mechanism that doesn't permit efficient parsing. Generics have worked fine in Ada since its inception. Any modern language can adopt the same process of tracking a formal abstract interface that is parsed once and expanded into concrete code as necessary.

Rust also has (relatively) bad compile times due to generics. Not as bad as C++, but you can notice it's significantly worse than Go.

There is tinygo with llvm backend and the build times are abysmal.

Re: How generics are implemented in Go 1.18

#116

Post by jcelerier »

MobiusHorizons wrote: post #112
staticassertion wrote: post #102

Earlier quoted context omitted.

How is Go lower level than C#?

One major difference that makes Golang lower level is that it compiles to machine code for the target CPU arch/OS instead of bytecode.

C# also supports AOT compilation. It's definitely not a low-level / high-level language differentiator. The term generally means the abstraction level you can reach.. I'd be tempted to define it as the distance to simple lambda-calculus in the lambda-cube

Re: How generics are implemented in Go 1.18

#117

Post by ctopher7 »

throwaway894345 wrote: post #104
kerkeslager wrote: post #91

So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go's type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple. Oh and it was really important to Gophers that Go compiles in a single pass (which I argued is only relevant for truly enormous codebases like Google's). A few ye…

> Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It's a shame that this language has stolen so much mind share from more deserving languages. Go steals the mindshare because it focuses on the important problems that other languages neglect in part or in full: performance, tooling, ecosystem, simplicity, readab…

No post body was provided.

Re: How generics are implemented in Go 1.18

#118

Post by kaba0 »

throwaway894345 wrote: post #104
kerkeslager wrote: post #91

So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go's type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple. Oh and it was really important to Gophers that Go compiles in a single pass (which I argued is only relevant for truly enormous codebases like Google's). A few ye…

> Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It's a shame that this language has stolen so much mind share from more deserving languages. Go steals the mindshare because it focuses on the important problems that other languages neglect in part or in full: performance, tooling, ecosystem, simplicity, readab…

There is absolutely nothing mentioned in your comment that Java or C# didn’t already do better 10 years ago, let alone now. The only somewhat redeeming quality of go is virtual threads, but that is not even the reason like 90% of its user base uses it for.

Re: How generics are implemented in Go 1.18

#119

Post by ptsneves »

staticassertion wrote: post #102
throwaway34241 wrote: post #100

Earlier quoted context omitted.

I’m not going to defend what random internet commenters may have said, but in my view the core team has been fairly consistent and their design decisions (to me) make sense. The first thing to understand is that Go occupies a space lower level than Java but higher level than C. It includes things like explicit pointers and more control of memory layout. Many of the design decisions make no sense without that context.…

How is Go lower level than C#?

We use go in an embedded Linux environment. I do C#for web stuff and it would never cross my mind to do c# in an armv7 Raspberry. Also what about cross compilation? The c# runtime is not easily available to use in embedded devices at least that i know of. With go you just set it to compile statically and set the arch target. I can deploy it as a single binary. Love it after years of maintaining cross tool chains.

Re: How generics are implemented in Go 1.18

#120

Post by masklinn »

valenterry wrote: post #114
omginternets wrote: post #109

Earlier quoted context omitted.

Where does this cause problems for you in practice? Where is the usefulness of goroutines limited practically ? Where is the complex notion of a compiler pass causing problems? I’m very open to the idea that I’m suffering from a problem I don’t know I have, but right now you’re just asserting that problems exist without actually telling us how to recognize them.

I think OP didn't even start using go in practice, so the question doesn't help. But I can say that it's the same ad with natural languages. No one ever feels that their mother tongue is limiting, until they learn a new and very different language and learn a pattern/style that they cannot apply in the mother tongue.

This actually has a name in programming circles: the blub paradox.

I guess in natural langages this would be the sapir-whorf hypothesis.

Blub seems like a much stronger effect though, at least anecdotally. But that might be because natural languages are rarely compared in terms of features / capabilities, and even more rarely “ranked” along various such axis.

Post reply on HN