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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Go: Don't Change the Libraries in 1.18

183 点作者 dbattaglia超过 3 年前

8 条评论

nine_k超过 3 年前
A good call, and probably the most reasonable decision in their situation.<p>OTOH this removes much of the point to use generics, and makes working with stdlib from type-parametric code more painful.<p>Still great to see things improving. It took mere 11 years.
评论 #28897822 未加载
评论 #28895950 未加载
评论 #28895734 未加载
kubb超过 3 年前
What will likely happen is that the users will design generic libraries themselves. There will likely be a couple, and eventually they will converge on the most useful features. Then the Go team can just get inspiration from that I guess.<p>I&#x27;m excited about the prospect of having iterators. It will enable a different, more consistent programming style.<p>I&#x27;m also hoping for immutable collections, even though the lack of specialization will make it more difficult to implement them efficiently. They would enable a more robust way to build concurrent systems.
评论 #28896566 未加载
评论 #28896538 未加载
评论 #28897536 未加载
dathinab超过 3 年前
Hm, shouldn&#x27;t they first update the (most important&#x2F;interesting) libraries in a fork before stabilizing generics?<p>I mean designing a feature in a clean room is one think, but using it a the standard library would be a good way to know if they messed up the design in some way.
评论 #28896621 未加载
cube2222超过 3 年前
Also think this is a good call.<p>Though the second comment has merit too, I think it would be good to have some common abstraction right away, like we had io.Writer, io.Reader, etc. so everybody doesn&#x27;t define their own, as it&#x27;ll take time to crawl out of that.<p>Although in practice it did work out well with error wrapping which was first in libraries and then the stdlib defined an interface for them, which resulted in all libraries adopting that.<p>&gt; Similarly, if constraints isn’t part of 1.18, there will be a lot of independent redefinitions of orderable types. I don’t think we’re going to learn from experience much that could change that package now.
1_player超过 3 年前
tl;dr: We&#x27;re shipping generics in 1.18, it&#x27;s a huge release so let&#x27;s wait a little bit until they stabilise and they&#x27;re used in production before changing our stdlib.<p>Good call in my book, and I&#x27;m extremely excited to have generics finally. I thought they were going to ship with 2.0, but the sooner the better!<p>It&#x27;s cool to hate on Go, it&#x27;s taken over the system programming space for a reason, like it or not, and after working full time on Elixir it&#x27;s hard not to think in map&#x2F;reduce and other generic constructs, which were unreasonably verbose before in Go. Now the haters will have to focus on the &quot;if err != nil&quot; statement to pile on the language — though to be fair I&#x27;ll expect some ergonomic improvement on that aspect as well, eventually.<p>With generics, Go will be my new Python, but with a decent dependency and deployment story, and I&#x27;ll just need Zig for my low-level manual memory management needs. What&#x27;s Rust?<p>EDIT: indeed being a bit cheeky with HN&#x27;s favourite language isn&#x27;t well received in this place.
评论 #28895703 未加载
评论 #28897745 未加载
评论 #28895668 未加载
评论 #28895687 未加载
评论 #28896037 未加载
评论 #28901040 未加载
评论 #28895659 未加载
评论 #28902085 未加载
olingern超过 3 年前
JavaScript&#x2F;TypeScript changes so much that a codebase will look very different from one year to the next. JS&#x2F;TS has come a long way and needed to make substantial change, but I appreciate the slow moving, methodical nature in which the Go team moves the language and environment forward.
评论 #28896761 未加载
评论 #28896822 未加载
评论 #28897119 未加载
crnkofe超过 3 年前
I was really looking forward to getting some basic generic standard library funcs. Guess what I&#x27;m getting now is a a ton of std libraries each with a slightly different approach, slightly different bugs and update cycles which will nicely inflate the amount of tech debt in existing codebases.<p>I guess from the standpoint of a language designer it makes life a bit easier not to do anything and just cherry pick the winners of the various generic attempts that the community will create but as an app. developer I find this disturbing. Also I question the rush to a release all of a sudden. Generics took years to come to fruition. Another year for a decent stdlib won&#x27;t really hurt anyone and for those that really really want it they can enable it through build constraints.
nyanpasu64超过 3 年前
C++17 introduced std::optional and std::variant, but they&#x27;re not used by the standard library in 2021, as far as I&#x27;ve seen (unlike Rust which is better off for using them). It feels quite like a missed opportunity to produce more ergonomic APIs (though the inability to produce an optional&lt;T&amp;&gt; is limiting, and std::variant is inefficient at compile and possibly runtime and apparently can&#x27;t be fixed because ABI). I&#x27;m not a Go user, but I dislike multiple competing approaches to problems without clear guidance or fully embracing newer approaches.