As we’ve discussed many times over the years, developers have been anticipating the addition of generics to Go for a long time. celebrations with the release of Go 1.18.

Since the release of the long-awaited feature, there have been numerous tutorials, demos, and discussions, but this week the discussion took a bit of a turn, wondering if the feature is really ready for prime time.

In a blog post on his company blog, Vicent Martiwhich works on the performance of the MySQL-compatible serverless database platform PlanetScalewrites that generics can slow down your Go code.

I don’t think generics in Go 1.18 are ready for mainstream adoption. Their performance is worrying. My opinion on the @planetscaledata Blog: https://t.co/mJVIj9MQ5u

— Vicent Marti (@vmg) March 30, 2022

In his blog post, Martí says that while there has been some opposition to generics lest the language become “a verbose, Enterprisey Java-lite with generic factories or, more terrifyingly, a degenerate HaskellScript that replaces ifs with monads”, others simply hope that generics will provide “essential functionality for implementing clean, reusable code at scale”. Apart from this dynamic, however, there is a third party, to which he belongs: “systems engineers who are not enthusiastic about generics per se, but about monomorphization and its implications for performance.

There are generally two ways to implement generics, writes Martí. First, you can use “boxing”, in which pointers help abstract and do all the “things” (his preferred non-technical term for this discussion) that a function will operate on “look and act alike manner”. This is the approach used for Go interfaces, dyn Traits in Rust, and virtual classes in C++, but he says they “are limited by their expressiveness and runtime overhead”. Second, you can use monomorphism, which essentially creates “a different copy of the function for each unique thing it needs to operate on” and has always been the go-to for implementing generics in different languages, because it “just boils down to swapping longer compile times for important performance gains in the resulting code.

We didn’t talk about it at Gophercon?
Some discussion on this topic: https://t.co/sNftruzAV9

— Bryan Boreham 💉💉💉 (@bboreham) March 30, 2022

The downside of monomorphization, however, is that it creates a lot more code, and so Go has taken a bit of a middle path, with an approach it calls “GCShape stencil with dictionaries.” Rick BransonDirector of Software Engineering at PlanetScale, offered a quick summary of this point in an email.

“There are very real cases where generating specific code for each kind of generic code swapping will dramatically increase compile times and the size of the resulting compiled executable to the point where it becomes problematic. code execution in some cases! So the Go compiler doesn’t actually generate new code for each type permutation. It uses a number of heuristics, including “GC Shape Stenciling” which makes compromises to maintain a reasonable number of permutations.In some cases, these trade-offs reduce performance adversely, because the generated machine code cannot be as simple, nasty, and special, and must support a wider range of types when executing. That’s a lot of what the blog is about,” Branson wrote.

Martí spends much of the blog post delving into the very technical and beautifully formatted details of what makes this so, which we’ll let this summary replace, but if you’re dying for more detail, they’re there in spades. Beyond that, however, we come to a more concise list of do’s and don’ts for getting the best out of generic performance as it is currently designed, and Martí’s suggestions for how Go might modify its design to further increase runtime performance.

Martí summed up his opinion on the matter in an email, writing that he thinks “the right trade-off for a system language (and any compiled language, for that matter) is to pay the upfront cost at compile time to generate a generic zero-cost abstraction at Duration This is the baseline, and the only sensible approach in my opinion: first, you make the compiler generate the best possible code under all circumstances, then you compare the compiler, and if it’s too slow, you’re working on optimizing the compiler Incidentally, if the compiler for your language is written in your language (like Go is), having it generate better code _also_ speeds up the compiler itself!

This week in programming

• Visual Studio 2022 gets the GitHub co-driver: Wherever you land on the ethical considerations around GitHub Copilot, the company’s so-called “AI pair programmer,” you might have to admit that it’s a fun tool to play with, and maybe even- be useful. Until now it was only available online in GitHub Codespaces and in Visual Studio Code, but now the company said that GitHub Copilot is now available for Visual Studio 2022. GitHub launched Copilot in a technical overview last year, and since then, Visual Studio 2022, which launched late last year, has been the most requested IDE. While you still need to join the waitlist, GitHub is adding more capacity as we speak, so be sure to register as soon as possible. Once you receive an email that you’re signed in, just follow the instructions and you’ll be up and running.

The next major release of React, React 18, has just been released. There’s some *really* cool stuff in this one, and it sets the stage for even more in the future! 😮

I’m going to share some of the things I’m most excited about in the thread. 🧵

— Josh W. Comeau (@JoshWComeau) March 30, 2022

• What’s so bad about Goto? Surely you have already heard of various things that are considered harmful, as initially triggered by by Edsger Dijkstra 1968 article”GOTO considered dangerous.” Well, a little blog post came through our feed this week that offered a little explanation of the harmfulness of goto, an instruction later popularized in the BASIC programming language that could be used to jump to different lines of code, and we thought it was worth sharing. If you have have you ever wondered why goto is considered harmfulor perhaps claiming that “goto being harmful is considered an overreaction”, as the author puts it, he argues that it is “because as the complexity of a program increases, unstructured jumps can lead to an inability to understand what is happening in a program, even in small programs. The argument is presented by showing two nearly identical flowcharts, the one on the right differing only in that it has a single goto argument.” “left flowchart has 72 unique paths. The right flowchart with the dotted line signifying an unstructured jump has 93,748,416,840 unique paths,” the author explains, then adding, “Now imagine a program where there are 10 or 100 jumps of this type? Sounds harmful, indeed.
• RedMonk’s language ranking finds stability: It may already be April on the calendar you’re reading, but The RedMonk Programming Language Rankings for January 2022 have just arrived and the analyst firm writes that “this quarter’s race story – as it is with a few races now – is stability”, a trend they have seen in recent years. In fact, 17 of the 20 languages ​​have remained stable over the past three quarters, and Redmonk wonders if this is “representative of industry usage, or is it more of a process artifact? ” Perhaps, they think, we are entering an era “where languages ​​have found their respective niches and a level with their particular competition”. For all the details on what changed (or mostly didn’t), go on and read RedMonk’s analysis of the ever-unchanging rankings, along with the many caveats they offer. Biggest move this quarter? C++ fell two places, and your guess is as good as theirs, at this point. (Maybe it’s the switch to Rust, for memory safety?)

I just learned that python is pronounced like “pee-thon” in French and like “poo-thon” in Finnish and I’m not sure I’ll ever get over it because I’m a kid

— social media is still a bad idea 🇺🇦 (@techpractical) March 29, 2022

The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: PlanetScale.