TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

How generics are implemented in Go 1.18

288 点作者 komuW大约 3 年前

12 条评论

kerkeslager大约 3 年前
So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go&#x27;s type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it&#x27;s better because it&#x27;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&#x27;s).<p>A few years later we had go generate. Which I argued was a glorified C macro system to get around the lack of generics. Oh and everybody forgot about the single-pass thing, I guess.<p>Now in this thread there are a bunch of people commenting that they can&#x27;t wait to combine all their <i>copy pasted code</i> using a generics which are implemented via a tree traversal that actually kind of complicated the idea of what a pass even is (I think memoization could make this linear, but at the cost of memory?).<p>This is a language that seemingly insists on breaking the wheel. Notice I didn&#x27;t say <i>reinventing</i>, because in over a decade they haven&#x27;t actually gotten a working version of the wheel out yet. I mean seriously, Go was released in 2009: if I&#x27;m not mistaken, C# had a pretty good generic system already, and there were a bunch of other workable options to copy from less-mainstream languages. Not that copying has helped: they copied coroutines from other languages, but failed to present a coherent memory sharing model (just copy Erlang FFS), which severely limits the usefulness of coroutines.<p>Every few years someone gets me to try Go out again and I discover, yet again, that it&#x27;s still struggling with problems that were solved before it existed. It&#x27;s a shame that this language has stolen so much mind share from more deserving languages.
评论 #30524131 未加载
评论 #30523720 未加载
评论 #30523503 未加载
评论 #30532249 未加载
评论 #30524270 未加载
评论 #30524320 未加载
评论 #30525744 未加载
评论 #30526979 未加载
评论 #30523917 未加载
评论 #30525188 未加载
评论 #30554927 未加载
评论 #30525483 未加载
评论 #30523771 未加载
评论 #30525683 未加载
kevingadd大约 3 年前
This approach (sharing code for various generic instances and passing in a blob of type information) is used for generics in some other languages&#x2F;runtime environments - for example .NET will in many cases do code sharing like this where it will generate a reusable generic function that operates over many types and then pass it type information so it can operate properly instead of having to generate 50 different versions of a function like a C++ compiler does. This obviously can have some performance implications, but it makes sense to do it (especially in Go&#x27;s case where what came before it was tons of virtual calls anyway).<p>In .NET on Windows you can sometimes observe this because generic types in your stack traces (in the debugger) will be replaced with &#x27;System.__Canon&#x27; [<a href="https:&#x2F;&#x2F;twitter.com&#x2F;matthewwarren&#x2F;status&#x2F;1161249300401311745" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;matthewwarren&#x2F;status&#x2F;1161249300401311745</a>] instead of the actual type - this indicates that the type was completely erased, so the current function could be running for any number of types and the type can&#x27;t be identified based on the current instruction pointer.<p>The shared code + blob approach becomes more necessary in an AOT compiled environment like Go (and you&#x27;ll see it used more in AOT compiled modes for .NET) since you can no longer rely on being able to on-demand JIT some optimized code when a new type shows up.
c-linkage大约 3 年前
I thought this was something like traits, but it goes way beyond that.<p>Sub-dictionaries are described here: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;proposal&#x2F;blob&#x2F;master&#x2F;design&#x2F;generics-implementation-gcshape.md#subdictionaries" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;proposal&#x2F;blob&#x2F;master&#x2F;design&#x2F;generi...</a><p>It looks like the compiler needs to walk down the entire call tree from the top-level generic and then compute new dictionaries for each called function. Since the compiler may not know the entire call tree, it may have to build nested dictionaries.<p>Wacky stuff!
评论 #30520319 未加载
layer8大约 3 年前
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?
评论 #30524540 未加载
评论 #30521048 未加载
评论 #30520933 未加载
评论 #30520176 未加载
评论 #30520215 未加载
majewsky大约 3 年前
By the way, are there any projects underway to produce a library of the most common basic template functions? I&#x27;m very much looking forward to unifying some of my most copy-pasted functions when 1.18 is out, but I would like to unify on a central library right away.
评论 #30520753 未加载
sigmaml大约 3 年前
I made a crude proposal for generics in 2011[1], in which I proposed a pair of concepts (&quot;storage class&quot; and &quot;type class&quot;) that are somewhat similar to the concept of this &quot;gcshape&quot;.<p>I proposed it as a compromise between full monomorphisation and runtime code generation.<p>[1] <a href="http:&#x2F;&#x2F;oneofmanyworlds.blogspot.com&#x2F;2011&#x2F;11&#x2F;draft-2-of-proposal-for-generics-in-go.html" rel="nofollow">http:&#x2F;&#x2F;oneofmanyworlds.blogspot.com&#x2F;2011&#x2F;11&#x2F;draft-2-of-propo...</a>
shadowgovt大约 3 年前
Something I haven&#x27;t been able to pull up yet: what does the addition of generics do the `reflect` package? I assume it needs to be extended to deal with reflection through generics?
评论 #30519871 未加载
cryptos大约 3 年前
Do Go generics support covariance and contravariance?
评论 #30519990 未加载
mbrodersen大约 3 年前
I think the Haskell compiler GHC is using a similar approach (directories) to implement type classes.
colesantiago大约 3 年前
When is generics officially coming into Go? I thought it would be in February as promised?
评论 #30520040 未加载
评论 #30520041 未加载
评论 #30520068 未加载
评论 #30520243 未加载
elromulous大约 3 年前
Disclaimer: I only very occasionally touch Go code.<p>Hasn&#x27;t this been a very long time coming? Iirc there has been much dispute over this in the community. Can anyone weigh in on what the other options were?
评论 #30519416 未加载
评论 #30519740 未加载
评论 #30519593 未加载
评论 #30519750 未加载
slx26大约 3 年前
Programming languages are lacking because they are too stuck in the &quot;implementation plane&quot; while trying to deal with lots of &quot;system design&quot; problems. Generics, traits, interfaces, union types and others are fundamentally targeted at giving developers more expressive power to describe the <i>systems</i> we are designing. We know there are many parts we could swap around, using different implementations, connecting some pieces here and there... and the system should make sense and work. We can see that it must work! But these features are trying to resolve problems from a very closely-connected but still different domain, and that&#x27;s why we see so much friction when trying to use them. We try to encode system-level patterns in the implementation, and there&#x27;s gonna be friction. We can see that these features give us power, and that&#x27;s why we like them, but we also see the problems they cause, and that&#x27;s when we get cold feet and say &quot;yeah... maybe it&#x27;s not such a great idea&quot;.<p>I&#x27;m actually really happy to get generics in golang, and I&#x27;m happy with the team giving it as much thought as they need, but we are only gonna get so far within the current paradigm of trying to model the universe from a few text files. Generics are nice, but we shall do better in the future!
评论 #30520442 未加载
评论 #30520952 未加载
评论 #30520854 未加载