Go 1.18

I wish I understood how people can say &#x27;this will result in so much more weird boilerplate garbage code&#x27; as it solves a problem that has resulted in an absolutely ludicrous amount of weird boilerplate garbage code. You&#x27;re not trading off generic code vs non-generic code. <i>Problems</i> are generic. For solving generic <i>problems</i>, you&#x27;re trading off the generic code that best expresses them, for codegen, dynamic downcasting, or Ctrl-V. The first two are not simpler (in the Go way) than generics, and the third is an antipattern in <i>every</i> programming environment.

Generics is the big news, but the fuzzing support is amazing too. I added a fuzz test to an app I have in about 5 minutes. It was no harder than adding a normal test.<p>I expect to see a huge boon in users of fuzzing techniques which will benefit projects across the board.

Release notes are here: <a href="https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;go1.18" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;go1.18</a>

This will no doubt be overshadowed by Generics, but Workspaces[0] are going to be incredibly useful for companies using a monorepo with shared packages.<p>Once again, great job to the Go team!<p>[0] <a href="https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;tutorial&#x2F;workspaces" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;tutorial&#x2F;workspaces</a>

Now time to update <i>interface{}</i> usage and shift to <i>any</i>.<p><pre><code> $ gofmt -r &#x27;interface{} -&gt; any&#x27; -l **&#x2F;*.go </code></pre> Replace -l with -w to write.

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone&#x27;s interested I am happy to make this a real project<p><a href="https:&#x2F;&#x2F;github.com&#x2F;frenchie4111&#x2F;go-generic-optional" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;frenchie4111&#x2F;go-generic-optional</a>

Great to see this!<p>Generics will drastically improve datastructure libraries.<p>That said, for people worrying about overcomplication, fortunately methods can&#x27;t have type parameters. That means ergonomic monads are not possible to implement, and we&#x27;ll most probably not see the whole functional story play out in Go.

For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals.<p>So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal polymorphic message queue per thread? Moreover, Go crippled CSP even further as one cannot select on channel and file descriptor.<p>Fortunately Go does provide mutexes and signals so one can ignore channels unless required by Go API. Still without proper sum types polymorphic and type-safe message queues are not possible.

WOOO!<p>I have been using the RC at work lately, and I have to say: The generics implementation is quite nice, and RUTHLESSLY slashes boilerplate and copy-pasta.<p>This is going to turn Golang from &quot;that one boilerplate-y language without generics&quot; into my favorite language.<p>I&#x27;ve been using the <a href="https:&#x2F;&#x2F;github.com&#x2F;samber&#x2F;lo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;samber&#x2F;lo</a> library, and it is very nice to be able to do &quot;map&#x2F;reduce&#x2F;etc...&quot; on golang structs.<p>I would really enjoy a chaining library, and some tooling to make type coersion a bit cleaner.

I hope open source Go code in the wild remains easy to read and understand. Generics look cool, despite this possible downside.

Hopefully generics will help make better libraries for Graphql. Existing libraries resorted to code generation a lot.

Personally, I&#x27;m waiting until 1.19 to start seriously exploring generics. By then, the dust will have settled a bit, folks will have some good lessons learned to share, and there may be more packages in the stdlib for generics.

Generics!!!<p>I can&#x27;t wait for all the different data structure libraries to embrace it. It will make Go adoption in Data Science use-case easier.

The general excitement about generics on this thread makes me uneasy.<p>Please keep in mind that generics are a pretty big hammer - they can add a lot of complication if not used with caution. Only use a language feature if you absolutely must.

I highly recommend checking out the Type Parameters Proposal[1]. It&#x27;s surprisingly easy to digest and has more realistic and complex examples than the quickstart guide or any other blog post out there.<p>[1] <a href="https:&#x2F;&#x2F;go.googlesource.com&#x2F;proposal&#x2F;+&#x2F;refs&#x2F;heads&#x2F;master&#x2F;design&#x2F;43651-type-parameters.md" rel="nofollow">https:&#x2F;&#x2F;go.googlesource.com&#x2F;proposal&#x2F;+&#x2F;refs&#x2F;heads&#x2F;master&#x2F;des...</a>

My favorite feature is a tiny, couple line bug fix that I pushed hard to get included during the feature freeze. Full details here, but a summary is below: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;51127" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;51127</a><p>For the past ~8 years, many hundreds of people reported on GitHub - and likely many multiples more have encountered and not reported - a program that didn&#x27;t work with the error &quot;cannot unmarshal DNS...&quot;<p>This error seems to be caused by two things:<p>1. DNS proxies not adhering to the DNS spec. This would be due to VPNs with integrated DNS proxies such as Cisco AnyConnect, internet connection sharing on Windows (which affects DNS resolution in the Windows Subsystem for Linux), or even just incorrectly implemented recursive resolvers. Specifically, if these servers <i>receive</i> a DNS message that utilizes RFC 1035, section 4.1.4 &quot;message compression&quot;, which is an extremely simple compression scheme, then they may <i>transmit</i> a DNS message that doesn&#x27;t utilize message compression, which means the proxy isn&#x27;t in response size 1:1 but almost always increases the size of DNS responses.<p>2. Go&#x27;s net&#x2F;dns resolver enforcing a strict 512 byte limit on responses. This is the same behavior as musl (and I would implore a musl maintainer to increase this limit) but not in glibc or most OS distributions&#x27; default DNS behavior.<p>I read every single GitHub issue related to this and found the frustration of both end-users and OSS software maintainers overwhelming. End users lacked the tools to diagnose why the software didn&#x27;t work, maintainers couldn&#x27;t reproduce the issue.<p>This bug affected <i>major</i> projects: Mesos, Docker, Consul, Terraform, and more. For nearly a decade. Sometimes (as in Mesos) these were projects where they controlled the DNS server and client, so they could implement DNS message compression and solve it. In other cases, such as with Docker or Pulumi, where software runs on end-user machines, maintainers may have had to &quot;close, can&#x27;t repro&quot; issues. The error was inscrutable and otherwise very skilled maintainers wrote this off as a fluke or user error.<p>And these are just the tools that are typically used by skilled technical users - usually engineers. It&#x27;s hard to estimate but not difficult to imagine underestimating how many bug reports and issues end-users encountered where a cryptic error message, if shown, never made its way to GitHub.<p>Software that works is better than software that - sometimes cryptically - does not. And when things just work, well, very few people using Go will realize that this fix prevented them from experiencing an afternoon or a day or more of frustration; but I will :) and I think that&#x27;s what makes contributing to OSS awesome.

Tip: If you&#x27;ve only heard about generics, make sure to check out about fuzzing (*testing.F)!

There is also a new set of FAQs on generics:<p><a href="https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;faq#Type_Parameters" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;faq#Type_Parameters</a>

Finally! This will be the last day I see the words &quot;Go&quot; &quot;lack of&quot;&#x2F;&quot;no&quot; and &quot;generics&quot; in one sentence.

When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they&#x27;re bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only end in frustration and confusion.<p>If you read the history of Go, the whole point behind its creation (as with many others) was to start with a clean slate so new norms and ways of doing things could form, in service of large distributed teams and long term maintainability. Lack of generics, as unrelated as it may seem, is actually the result of the those and other goals. Specifically, Go authors avoided complicating the language, runtime, and compiler early on and thereby avoided negatively affecting long term maintainability of both the language and the code written for it (v1 compatibility promise) before having a good grasp of how generics should be implemented in this new language or if it should be at all. Copying the so called tried and tested implementations from existing languages would make little sense as generics are so intertwined with the rest of a language.<p>TL;DR approach learning programming languages like you would approach learning a new natural language with the purpose of living among its native speakers.

Regarding Windows: while this isn&#x27;t on scoop yet I was able to get it in Github Actions like so:<p><pre><code> curl -L -O &quot;https:&#x2F;&#x2F;go.dev&#x2F;dl&#x2F;go1.18.windows-amd64.zip&quot; unzip go1.18.windows-amd64.zip Join-Path $pwd &quot;go\bin&quot; &gt;&gt; $Env:GITHUB_PATH </code></pre> A request&#x2F;suggestion for the Go team: include instructions for how to use the Windows zip! It&#x27;s not a big deal but I had to figure it out by `ls`-ing around.

Why post this useless Github link instead of the release notes or the blog post?

Finally generics support. Now another 10 years for proper enums.<p>Kidding, I always mentioned that CLU like would be good enough.

Is there a go-to implementation of typed map&#x2F;reduce&#x2F;filter with 1.18?

I hope this gets merged into the upcoming Yocto `kirkstone` LTS release branch, since that branch will use the same pinned version for years to come. The previous `dunfell` LTS release branch provided Go 1.14, which can no longer build the latest versions of many projects.

Now Go has everything I need in a programming language!

Hooray! Couple quality of life improvements to embedded filesystems... you can now use files that start with an underscore :D

strings.Cut &#x2F; bytes.Cut is really nice.

Honestly I think this will make the overall programming experience worse.

I think about Go with pleasure until I remember importing. The miseries I&#x27;ve experienced with modules - the way imports are satisfied......just so hard to understand. Built-in support for SCM sites like github (yuck!). Just struggling to put code in a place where some other bit of my code can use it. The C&#x2F;C++ preprocessor is an abortion and go seems to have made something that solves all the problems I had with that but ends up much worse to use.

LET THE REWRITING BEGIN!…

I really hope people will show restraint.

I will forever miss old Go :-(

This is very exciting! Generics will be helpful for some, I&#x27;m sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types.<p>I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the language design, but I suspect that doesn&#x27;t account for all of it. It seems to me that the intensity with which some people fixated on the absence of generics cannot be explained just by frustration with writing non-generic code, which by all accounts was annoying but not overwhelmingly so.<p>So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you?<p>Sometimes I think the core irritation with Go is its simplicity. The suggestion that easy to learn languages can be effective too is somewhat humiliating, as we get attached to the pride of mastering more complex languages, and the suggestion is that some of the struggling we went through was unnecessary, and that folks who wont struggle as much might be able to be effective too, in fact the suggestion is that maybe our pride was misplaced.<p>Theres also a suggestion, in the fact that Go has opinions, that other opinions might be &quot;wrong&quot;. I think this may bug people, who would take up those other opinions or see merit in them, a lot. There&#x27;s also a bit of an anti-expertise &quot;who are you, Go creators, to say you know better than me how to design this program&#x2F;engage in software development?&quot;<p>In any case, it&#x27;s something I&#x27;ve been trying to figure out for a while and I don&#x27;t think I have a complete explanation still. Curious to see what others think.

Why not link the announcement? <a href="https:&#x2F;&#x2F;tip.golang.org&#x2F;blog&#x2F;go1.18" rel="nofollow">https:&#x2F;&#x2F;tip.golang.org&#x2F;blog&#x2F;go1.18</a><p>Who cares about the tag<p>What&#x27;s up mods? @dang yo

Now Go sucks because there are too many generics.

Aaaand now watch every projects abstraction increase tenfold under the weight of generics