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

131–140 of 228 posts

Re: How generics are implemented in Go 1.18

#131

Post by pjmlp »

Kranar wrote: post #33
kenniskrag wrote: post #9

Earlier quoted context omitted.

Isn't that solved with c++ modules [1]? [1] https://en.cppreference.com/w/cpp/language/modules

Not really, in C++ templates still need to be instantiated in every module but modules don't have to each repeat the parsing of template definitions. The module that declares the template will do the job of parsing the template and producing some intermediate representation of it that other modules can consume. Okay that does save some amount of time but the overwhelming majority of time spent compiling templates is…

They sure do, make the most common expansions avaiable as extern templates.

Re: How generics are implemented in Go 1.18

#132

Post by mahesh-hegde »

pjmlp wrote: post #128
mahesh-hegde wrote: post #122

Earlier quoted context omitted.

AOT compiler; single binary; standard library and package ecosystem well suited for a subset of programming tasks, while being much lightweight and less verbose than Java / C#. Would not pick Go to make a website. But it's probably best tool to make a simple HTTP server or command line tool that deals with files or network.

Java has AOT compilers since 2000, they just weren't free beer. .NET was released with AOT compiler, although it only did dynamic linking (NGEN). Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.

> Java has AOT compilers since 2000, they just weren't free beer.

"just"

Tell me how me, a student in India with a cheap plastic laptop running Linux, could get straightforward access to some AOT compiler produced by some commercial company in north pole or somewhere.

Open source compilers got popular for a reason.

Now we have graalvm, but getting something running with graalvm is not always straightforward. Even with a full framework like quarkus I have had to use escape hatches @RegisterForReflection. Usability matters. And Go was built from day 1 with AOT in mind.

And lastly Go has better built-in / first-party supported APIs for file I/O, networking etc.. Subjective thing, I guess. When I want to make a database backed website, I reach for spring boot or vert.x; But Go wins for CLI stuff.

I don't know much about C# because I primarily work on Linux.

Re: How generics are implemented in Go 1.18

#133

Post by pjmlp »

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…

I bet that if the Docker and Kubernetes ecosystem was born today, Rust would be used instead.

We are already seeing the transition happening, e.g. Deis Labs:

https://deislabs.io/posts/still-rusting-one-year-later/

> Given the team’s background in many Go projects, we often hear something like this: “Well, what about Go? Do you regret moving to Rust? What do you miss from Go?” Addressing this in the context of our discussion of Rust felt like a smart decision.

Re: How generics are implemented in Go 1.18

#134

Post by dboreham »

kllrnohj wrote: post #80
shadowgovt wrote: post #20

Earlier quoted context omitted.

C++ still has the dubious honor of being the only language where I encountered code that I could not compile because my machine lacked enough memory. I'm sure that's possible in other languages, but the program I was trying to compile wasn't that complicated... It had just been written by someone who believed every concrete class needed an abstract interface it was implementing.

I see you haven't worked with the joy of gradle & modern Java development. By the time you stack up gradle, javac itself, proguard or for Android R8 which are basically required to fix the terrible bytecode javac produces, some annotation processors because WHY NOT, custom build plugins, etc... it gets big

You really need Scala to run out of memory though.

Re: How generics are implemented in Go 1.18

#135

Post by pjmlp »

mahesh-hegde wrote: post #132
pjmlp wrote: post #128

Earlier quoted context omitted.

Java has AOT compilers since 2000, they just weren't free beer. .NET was released with AOT compiler, although it only did dynamic linking (NGEN). Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.

> Java has AOT compilers since 2000, they just weren't free beer. "just" Tell me how me, a student in India with a cheap plastic laptop running Linux, could get straightforward access to some AOT compiler produced by some commercial company in north pole or somewhere. Open source compilers got popular for a reason. Now we have graalvm, but getting something running with graalvm is not always straightforward. Even wit…

Like always, on a street bazaar, or are you going to tell us they don't exist?

Re: How generics are implemented in Go 1.18

#136

Post by tsss »

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…

No post body was provided.

Re: How generics are implemented in Go 1.18

#137

Post by pkolaczk »

vips7L wrote: post #95
shadowgovt wrote: post #89

Earlier quoted context omitted.

Computers seem to have caught up. The Java stack is the slowest one I regularly use (though it does support a certain amount of hot-recompile that other toolchains I use don't or can't), but it's never just crashed because it can't find room to store all those bytecode files.

I’ve compiled projects with javac, scalac, g++, gcc, and dmd. Javac is faster than all of them.

javac doesn't have to generate optimized machine code, which saves it a lot of time. But you pay the price incrementally in all those slow startups of java apps.

Re: How generics are implemented in Go 1.18

#138

Post by socialdemocrat »

BatteryMountain wrote: post #125
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…

C# generics are delicious. Combined with the strong compiler and super good reflection features, you can do very well indeed with it.

Nah… if so was embracing C# style complexity I would rather do Swift of Rust. At least they have a clean solution for fixing the million-dollar-mistake.

My chief attraction to Go is simplicity. I can be away from Go for years and pick it up again really fast. With simplicity, you naturally need to make some sacrifices, but I think Go team has been diligent about choosing those.

Re: How generics are implemented in Go 1.18

#139

Post by socialdemocrat »

pjmlp wrote: post #129
throwaway34241 wrote: post #105

Earlier quoted context omitted.

I think C# might be the closest mainstream language, but I’d say explicit pointers, interior pointers, and slices as the default list type might be things that make Go programming a little lower level. There are also other differences that would prevent using C#’s system as is - Go doesn’t have the reference/value type dichotomy or inheritance. I think they also wanted to be able to abstract across float/doubles etc…

Never used unsafe and raw pointers in C#? They exist since version 1.0. Never used ArraySegments in C#? They exist since version 2.0 Abtracting over float/doubles is called generics.

It is not the same thing at all if you care to compare the details. C# pointers come with a long list of caveats which does not apply in Go. They feel like a bolted on escape hatch rather than a real part of the language.

Re: How generics are implemented in Go 1.18

#140

Post by socialdemocrat »

jcelerier wrote: post #116
MobiusHorizons wrote: post #112

Earlier quoted context omitted.

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

C# ahead-of-time compilation has for many years come with all sorts of caveats. Early versions requires runtime system because not everything got compiled on parts. Later versions have all sorts restrictions which do no apply for Go.

I think when C# and Java people compare with other languages they treat it as a checkbox exercise without caring about how good that feature actually is.

Post reply on HN