Go 1.18 Released

• go

  2,068 119,564 10.0 Go

  The Go programming language

  

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: https://github.com/golang/go/issues/51127

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't work with the error "cannot unmarshal DNS..."

This error seems to be caused by two things:

1. DNS proxies not adhering to the DNS spec such as VPNs with integrated DNS proxies such as Cisco AnyConnect, internet connection sharing on Windows (which affects DNS resolution in the Windows Subsystem for Linux), and more. Specifically, if these proxies receive a DNS message that utilizes RFC 1035, section 4.1.4 "message compression", which is an extremely simple compression scheme, then they may transmit a DNS message that doesn't utilize message compression, which means the proxy isn't 1:1 but almost always increases the size of DNS responses.

2. Go's net/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' default DNS behavior.

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't work, maintainers couldn't reproduce the issue.

This bug affected major 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.

And these are just the tools that are typically used by skilled technical practitioners. It'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.

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's what makes contributing to OSS awesome.

• lo

  64 15,348 5.8 Go

  💥 A Lodash-style Go library based on Go 1.18+ Generics (map, filter, contains, find...)

WOOO!

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.

This is going to turn Golang from "that one boilerplate-y language without generics" into my favorite language.

I've been using the https://github.com/samber/lo library, and it is very nice to be able to do "map/reduce/etc..." on golang structs.

I would really enjoy a chaining library, and some tooling to make type coersion a bit cleaner.

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• proposal

  46 3,289 4.4 Go

  Go Project Design Documents

  

It’s not a satisfying answer, but the truth is that there just isn’t that much Go code out there suffering from a lack of the kind of basic generics being introduced. It exists, but it’s not the norm.

Instead, what is likely to happen is, a lot of problems that generics can be applied to, they more often will be, simply because the option is on the table, regardless of whether it really improves anything. Go taught me to stop worrying and trust the For loop, and now we’re probably going to have dozens of utility libraries with Map and Reduce routines that people will use for extremely simple loops that don’t need them, probably resulting in slower code that takes longer to compile that needs a slower and more complicated optimizer to make up for it. In my opinion, the antithesis of what makes Go great.

Not saying generics is all bad, or that reduce is bad, or anything like that. But once a programming language has a new way to do something, you can be damn well sure people will use it, often even to their own disadvantage. Go doesn’t have pattern matching control flow, so the best degree of soundness you can pull out of an Optional type is ugly visitor-pattern type interaction. And yet, I’m worried routines will superfluously return Optional types anyways, just because you can, even though it’s not really any better than just returning a type and a boolean.

And yes. Actual code that actually needs generics for real will benefit, undeniably. Data structure and generic algorithm implementations will benefit greatly. The ugly sort package can finally be cleaned up. That’s great. But, most Go programs simply aren’t suffering from a lack of basic generics. Operative words: most, and basic generics. Many programs simply don’t need any data structures other than a basic growable vector type and a basic hashtable, and Go has both and they are built-in and work generically. Yet the more complex problems that C++ templates and Rust generics solve will probably not be aided at all by Go generics, which are simply much more limited in scope.

And despite that, this is quite an increase in compiler complexity. I know many are thinking “how hard could it be? Tons of languages do it today”—but Go isn’t really like all of the other languages. The simpler compiler is a huge benefit to the compiler and the whole ecosystem. Arguably, Go’s simplicity enabled them to experiment with things that wouldn’t be very easy to do in other languages, with regards to its GC and threading model. They’ve got it figured out of course, but it really isn’t a simple walk in the park. Any single aspect has a lot going on:

https://github.com/golang/proposal/blob/master/design/generi...

My hope is that the relatively mature ecosystem of Go will somewhat encourage people to keep their code simple and use generics sparingly, but with such a major shift in the language it’s hard to imagine what is “idiomatic” won’t change over time. I feel Go’s brutalist simplicity is its strong point and that it will just be an inferior option if you try to write code in it like C++ or Rust.

Of course… we’ll see.

• functional-go

  4 179 5.9 Go

  This library is inspired by functional programming - Clojure

earlv 17th century

>> instead of actually giving a shit about the perspectives of those who disagree with you

Now i resent that because i took the time to try and steelman your bad argument.

>> they couldn't be without copy/pasting their implementation for every single array type you wanted to implement them for

Not true, as i said there’s always been options for this:

>> if we need them to be generic over argument types - in the absolute worst case (so not using go generate to help us here or an interface…

Behind the scenes in the compiler, the syntactic sugar of generics are ultimately performing what you would do with “go generate“.

>> in every project that wants to use them

I don’t follow, why aren’t we allowed to create a library for code reuse like https://github.com/logic-building/functional-go/blob/master/... has done for example?

• go_chainable

  2 124 0.0 Go

  With generics, allowing chainable .Map(func(...)).Reduce(func(...)) syntax in go

• go-generic-optional

  1 27 0.0 Go

  Implementation of Optionals in Go using Generics

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project

https://github.com/frenchie4111/go-generic-optional

• genny

  6 1,690 0.0 Go

  Elegant generics for Go

  

Im not sure about any library in particular.

There were bunch of libraries which helped with code generation to work around generics. I don't think it was specific to Graphql.

https://github.com/cheekybits/genny is one I have seen.

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• gtl

  2 6 0.0 Go

  Golang Template Library (GTL). Common data structures using Golang generics. (by dgrr)

I started a template library some time ago. It needs a bit of a clean up, but for starters it's quite decent.

https://github.com/dgrr/gtl

• golang-set

  6 3,915 5.3 Go

  A simple, battle-tested and generic set type for the Go language. Trusted by Docker, 1Password, Ethereum and Hashicorp.

It depends on the level of abstraction you're addressing. One level may be "i need to store things with a quick search function", another may be "i need a storage of ordered names and expiry date for things", etc until you get to "I need a binary tree which orders by comparable types".

Where you split that process as a separate library you either decide to write or reuse - that becomes the problem to solve. A set implementation may be a problem to solve: https://github.com/deckarep/golang-set A btree may be a problem to solve: https://gitlab.com/cznic/b/-/tree/master/v2

• b

  2 - -

It depends on the level of abstraction you're addressing. One level may be "i need to store things with a quick search function", another may be "i need a storage of ordered names and expiry date for things", etc until you get to "I need a binary tree which orders by comparable types".

Where you split that process as a separate library you either decide to write or reuse - that becomes the problem to solve. A set implementation may be a problem to solve: https://github.com/deckarep/golang-set A btree may be a problem to solve: https://gitlab.com/cznic/b/-/tree/master/v2

• redpanda

  69 8,784 10.0 C++

  Redpanda is a streaming data platform for developers. Kafka API compatible. 10x faster. No ZooKeeper. No JVM!

  

a small note on redpanda. Is not a `rewrite`. It is an entire new storage engine, different consensus protocol, different on-disk format, different internal RPC, no external dependencies, ...., in fact when i started it it was using flatbuffers as the API. What we did later to make money is add a kafka-API translation layer, but in terms of code size, is a very small part. The way i'd recommend thinking about it is a new storage engine that is compatible w/ kafka clients. https://github.com/redpanda-data/redpanda/tree/dev/src/v/kaf... - this is basically all the kafka-related code, the rest is net-new design.

Suggest a related project