This Week in Programming: Has the Time Finally Come for Generics in Golang?

The debate around adding generics to the Go programming language has been going on for years now, often with much resistance, but it’s starting to look like one proposal finally has some backing and general acceptance from the greater Go community — much to the surprise of some involved.

Introduced this week in a blog post looking at the next step for generics, penned by Golang team members Ian Lance Taylor and Robert Griesemer, the first update in nearly a year on the topic explains that the generics design draft previously submitted for feedback has been refined, resulting in an updated design draft. The authors summarize the primary difference between the two proposals:

The biggest change is that we are dropping the idea of contracts. The difference between contracts and interface types was confusing, so we’re eliminating that difference. Type parameters are now constrained by interface types. Interface types are now permitted to include type lists, though only when used as constraints; in the previous design draft type lists were a feature of contracts. More complex cases will use a parameterized interface type.

For the time being, the team has introduced an experimentation tool that “permits people to type check and run code written using the version of generics described in the design draft” by translating generic code into ordinary Go code. It is meant to give users a feel of how the proposed design would, if accepted work, and they note that it will be implemented differently if so.

I’ve done over 1000 (mostly API design) reviews when I was working on Go. You might be wondering who needs generics, here are my three categories:
– Data layers, database APIs
– Collections
– Container types

Lack of generics is not just copy/paste but causing error-prone APIs.

— Jaana Dogan (@rakyll) June 17, 2020

As for the proposal itself, it offers several levels of detail, from an abstract, to a high-level overview, to the full level of detail you might expect from such a document. As with everything Go, the design is intended to be fully backward compatible with Go 1, and the authors note that “as the term generic is widely used in the Go community, we will use it below as a shorthand to mean a function or type that takes type parameters. Don’t confuse the term generic as used in this design with the same term in other languages like C++, C#, Java, or Rust; they have similarities but are not the same.”

The team says that they are, as usual, looking for feedback from the Go community at large, with the best way being to use the golang-nuts@googlegroups.com mailing list. In this effort, they are looking to learn two primary things:

“First, does generic code make sense? Does it feel like Go? What surprises do people encounter? Are the error messages useful?

Second, we know that many people have said that Go needs generics, but we don’t necessarily know exactly what that means. Does this draft design address the problem in a useful way? If there is a problem that makes you think ‘I could solve this if Go had generics,’ can you solve the problem when using this tool?”

“Go is a toy language because there are no generics”
*Adds generics*
“Real languages use <T>”

— Miek Gieben (@miekg) June 17, 2020

This Week in Programming

• Go Package Repository Goes Open Source: One more bit of Go news before we move on, the team also announced this week that pkg.go.dev is now open source, and accepting contributions. For those interested in getting involved, the repository lives at go.googlesource.com/pkgsite, mirrored to github.com/golang/pkgsite, and you are encouraged to read the contribution guidelines. Currently, design issues are on the top of the list for what to tackle next, including a more cohesive search and navigation experience.
• GitHub Gets “Super Linter”: GitHub has introduced its “one linter to rule them all”, the GitHub Super Linter, which it was originally built internally to maintain consistency in its own documentation and code. The team has open sourced the tool, which helps prevent broken code from being uploaded to master branches, establish coding best practices across multiple languages, build guidelines for code layout and format, and automates the process to help streamline code reviews. The Super Linter itself is packaged into a Docker container and called by GitHub Actions, allowing for any repository on GitHub.com to call it. For full details, check out the README.md.

C programmers are like pic.twitter.com/8sREwhgVVh

— Graham Christensen (@grhmc) June 17, 2020

• Azure Offers Free Course, Scholarship in Machine Learning: Microsoft Azure has come out with Udacity to announce the Azure Machine Learning scholarships and courses, which it says will help address the rising demand for artificial intelligence (AI) and data science roles. The free, introductory course is based on Azure Machine Learning and offers a low-code experience using Azure Machine Learning’s automated ML and drag-and-drop capabilities. The companies will also offer a new machine learning Nanodegree Program, in which students will build and deploy ML solutions using tools and frameworks such as PyTorch, TensorFlow, scikit-learn, and ONNX. The top 300 performers in the free introductory course will be offered scholarships to the Nanodegree Program, and more details are available on the course page.
• AWS Adds EFS For Lambda Functions: AWS has introduced a shared file system for Lambda functions with the ability to “mount an Amazon Elastic File System (EFS), a scalable and elastic NFS file system storing data within and across multiple availability zones (AZ) for high availability and durability.” The feature will let you store and share data across all concurrent execution environments of Lambda functions and access the same EFS file system from multiple functions. Users will also be able to share the same EFS file system with Amazon Elastic Compute Cloud (EC2) instances, containerized applications using Amazon ECS and AWS Fargate, and on-premises servers.

git push origin andtonic

— Leah Culver (@leahculver) June 17, 2020

• Flash EOL On The Way: SDTimes writes that Adobe is reminding its users that the Flash end of life is coming up at the end of 2020, with the company ceasing distribution and updates. I don’t know about you, but I’m glad my pursuit of Flash ended about fifteen (or so) years ago — as did Flash’s real popularity, as SDTimes notes began with the release of the iPhone, which didn’t support Flash. Adobe announced the end of Flash back in 2017, citing open standards such as HTML5, WebGL, and WebAssembly. On its Flash Player End of Life page, Adobe says that it will not only remove downloads for all versions, but also that “Flash-based content will be blocked from running in Adobe Flash Player after the EOL Date.”

remember logging off?

— Owen Williams ⚡ (@ow) June 16, 2020