FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid Atom 1.0 feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 1, column 507: name should not be blank (10 occurrences) [help]

... 2T00:00:00+00:00</updated><author><name></name></author><summary type="h ...
                                             ^

line 1, column 39881: content should not contain data-slug attribute (10 occurrences) [help]

... ocs.js&#34;&gt;&lt;/script&gt;&#xA;&#xA;</content></entry><entry><title> ...
                                             ^

line 1, column 39881: content should not contain script tag (40 occurrences) [help]

... ocs.js&#34;&gt;&lt;/script&gt;&#xA;&#xA;</content></entry><entry><title> ...
                                             ^

line 1, column 151362: content should not contain style tag (2 occurrences) [help]

... ocs.js&#34;&gt;&lt;/script&gt;&#xA;&#xA;</content></entry><entry><title> ...
                                             ^

Source: http://blog.golang.org/feed.atom

<feed xmlns="http://www.w3.org/2005/Atom"><title>The Go Blog</title><id>tag:blog.golang.org,2013:blog.golang.org</id><link rel="self" href="https://go.dev/blog/feed.atom"></link><updated>2024-05-02T00:00:00+00:00</updated><entry><title>Secure Randomness in Go 1.22</title><id>tag:blog.golang.org,2013:blog.golang.org/chacha8rand</id><link rel="alternate" href="https://go.dev/blog/chacha8rand"></link><published>2024-05-02T00:00:00+00:00</published><updated>2024-05-02T00:00:00+00:00</updated><author><name></name></author><summary type="html">ChaCha8Rand is a new cryptographically secure pseudorandom number generator used in Go 1.22.</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/chacha8rand">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>Secure Randomness in Go 1.22</h1>
 
 <p class="author">
 Russ Cox and Filippo Valsorda<br>
 2 May 2024
 </p>
 
 <p>Computers aren&rsquo;t random.
On the contrary, hardware designers work very hard to make sure computers run every program the same way every time.
So when a program does need random numbers, that requires extra effort.
Traditionally, computer scientists and programming languages
have distinguished between two different kinds of random numbers:
statistical and cryptographic randomness.
In Go, those are provided by <a href="/pkg/math/rand/"><code>math/rand</code></a>
and <a href="/pkg/crypto/rand"><code>crypto/rand</code></a>, respectively.
This post is about how Go 1.22 brings the two closer together,
by using a cryptographic random number source in <code>math/rand</code>
(as well as <code>math/rand/v2</code>, as mentioned in our <a href="/blog/randv2">previous post</a>).
The result is better randomness and far less damage when
developers accidentally use <code>math/rand</code> instead of <code>crypto/rand</code>.</p>
<p>Before we can explain what Go 1.22 did, let&rsquo;s take a closer look
at statistical randomness compared to cryptographic randomness.</p>
<h2 id="statistical-randomness">Statistical Randomness</h2>
<p>Random numbers that pass basic statistical tests
are usually appropriate for use cases like simulations, sampling,
numerical analysis, non-cryptographic randomized algorithms,
<a href="/doc/security/fuzz/">random testing</a>,
<a href="https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle" rel="noreferrer" target="_blank">shuffling inputs</a>,
and
<a href="https://en.wikipedia.org/wiki/Exponential_backoff#Collision_avoidance" rel="noreferrer" target="_blank">random exponential backoff</a>.
Very basic, easy to compute mathematical formulas turn out to work
well enough for these use cases.
Because the methods are so simple, however, an observer who
knows what algorithm is being used can typically predict the rest
of the sequence after seeing enough values.</p>
<p>Essentially all programming environments provide a mechanism for generating
statistical random numbers
that traces back through C to
Research Unix Third Edition (V3), which added a pair of functions: <code>srand</code> and <code>rand</code>.
The manual page included
a note that read:</p>
<blockquote>
<p><em>WARNING The author of this routine has been writing
random-number generators for many years and has never been
known to write one that worked.</em></p>
</blockquote>
<p>This note was partly a joke but also an acknowledgement that such
generators are <a href="https://www.tuhs.org/pipermail/tuhs/2024-March/029587.html" rel="noreferrer" target="_blank">inherently not random</a>.</p>
<p>The source code of the generator makes clear how trivial it is.
Translated from PDP-11 assembly to modern C, it was:</p>
<pre><code>uint16 ranx;

void
srand(uint16 seed)
{
 ranx = seed;
}

int16
rand(void)
{
 ranx = 13077*ranx + 6925;
 return ranx &amp; ~0x8000;
}
</code></pre>
<p>Calling <code>srand</code> seeds the generator with a single integer seed,
and <code>rand</code> returns the next number from the generator.
The AND in the return statement clears the sign bit to make sure the result is positive.</p>
<p>This function is an instance of the general class of
<a href="https://en.wikipedia.org/wiki/Linear_congruential_generator" rel="noreferrer" target="_blank">linear congruential generators (LCGs)</a>,
which Knuth analyzes in <em>The Art of Computer Programming</em>, Volume 2, section 3.2.1.
The main benefit of LCGs is that constants can be chosen such that they
emit every possible output value once before repeating,
as the Unix implementation did for 15-bit outputs.
A serious problem with LCGs, however, is that the high bits of the state do not affect the low bits at all,
so every truncation of the sequence to <em>k</em> bits necessarily repeats with a smaller period.
The low bit must toggle: 0, 1, 0, 1, 0, 1.
The low two bits must count up or down: 0, 1, 2, 3, 0, 1, 2, 3, or else 0, 3, 2, 1, 0, 3, 2, 1.
There are four possible three-bit sequences; the original Unix implementation repeats 0, 5, 6, 3, 4, 1, 2, 7.
(These problems can be avoided by reducing the value modulo a prime,
but that would have been quite expensive at the time.
See S. K. Park and K. W. Miller&rsquo;s 1988 CACM paper
“<a href="https://dl.acm.org/doi/10.1145/63039.63042" rel="noreferrer" target="_blank">Random number generators: good ones are hard to find</a>”
for a short analysis
and the first chapter of Knuth Volume 2 for a longer one.)</p>
<p>Even with these known problems,
the <code>srand</code> and <code>rand</code> functions were included in the first C standard,
and equivalent functionality was included in essentially every language since then.
LCGs were once the dominant implementation strategy,
although they&rsquo;ve fallen off in popularity due to some important drawbacks.
One significant remaining use is <a href="https://github.com/openjdk/jdk8u-dev/blob/master/jdk/src/share/classes/java/util/Random.java" rel="noreferrer" target="_blank"><code>java.util.Random</code></a>,
which powers <a href="https://github.com/openjdk/jdk8u-dev/blob/master/jdk/src/share/classes/java/util/Random.java" rel="noreferrer" target="_blank"><code>java.lang.Math.random</code></a>.</p>
<p>Another thing you can see from the implementation above
is that the internal state is completely exposed by the result of <code>rand</code>.
An observer who knows the algorithm and sees a single result
can easily compute all future results.
If you are running a server that calculates some random values
that become public and some random values that must stay secret,
using this kind of generator would be disastrous:
the secrets wouldn&rsquo;t be secret.</p>
<p>More modern random generators aren&rsquo;t as terrible as the original Unix one,
but they&rsquo;re still not completely unpredictable.
To make that point, next we will look at the original <code>math/rand</code> generator from Go 1
and the PCG generator we added in <code>math/rand/v2</code>.</p>
<h2 id="the-go-1-generator">The Go 1 Generator</h2>
<p>The generator used in Go 1&rsquo;s <code>math/rand</code> is an instance of what is called a
<a href="https://en.wikipedia.org/wiki/Linear-feedback_shift_register" rel="noreferrer" target="_blank">linear-feedback shift register</a>.
The algorithm is based on an idea by George Marsaglia,
tweaked by Don Mitchell and Jim Reeds,
and further customized by Ken Thompson for Plan 9 and then Go.
It has no official name, so this post calls it the Go 1 generator.</p>
<p>The Go 1 generator&rsquo;s internal state is a slice <code>vec</code> of 607 uint64s.
In that slice, there are two distinguished elements: <code>vec[606]</code>, the last element, is called the “tap”,
and <code>vec[334]</code> is called the “feed”.
To generate the next random number,
the generator adds the tap and the feed
to produce a value <code>x</code>,
stores <code>x</code> back into the feed,
shifts the entire slice one position to the right
(the tap moves to <code>vec[0]</code> and <code>vec[i]</code> moves to <code>vec[i+1]</code>),
and returns <code>x</code>.
The generator is called “linear feedback” because the tap is <em>added</em> to the feed;
the entire state is a “shift register” because each step shifts the slice entries.</p>
<p>Of course, actually moving every slice entry forward would be prohibitively expensive,
so instead the implementation leaves the slice data in place
and moves the tap and feed positions backward
on each step. The code looks like:</p>
<pre><code>func (r *rngSource) Uint64() uint64 {
 r.tap--
 if r.tap &lt; 0 {
 r.tap += len(r.vec)
 }

 r.feed--
 if r.feed &lt; 0 {
 r.feed += len(r.vec)
 }

 x := r.vec[r.feed] + r.vec[r.tap]
 r.vec[r.feed] = x
 return uint64(x)
}
</code></pre>
<p>Generating the next number is quite cheap: two subtractions, two conditional adds, two loads, one add, one store.</p>
<p>Unfortunately, because the generator directly returns one slice element from its internal state vector,
reading 607 values from the generator completely exposes all its state.
With those values, you can predict all the future values, by filling in your own <code>vec</code>
and then running the algorithm.
You can also recover all the previous values, by running the algorithm backward
(subtracting the tap from the feed and shifting the slice to the left).</p>
<p>As a complete demonstration, here is an <a href="/play/p/v0QdGjUAtzC">insecure program</a>
generating pseudorandom authentication
tokens along with code that predicts the next token given a sequence of earlier tokens.
As you can see, the Go 1 generator provides no security at all (nor was it meant to).
The quality of the generated numbers also depends on the initial setting of <code>vec</code>.</p>
<h2 id="the-pcg-generator">The PCG Generator</h2>
<p>For <code>math/rand/v2</code>, we wanted to provide a more modern statistical random generator
and settled on Melissa O&rsquo;Neill&rsquo;s PCG algorithm, published in 2014 in her paper
“<a href="https://www.pcg-random.org/pdf/hmc-cs-2014-0905.pdf" rel="noreferrer" target="_blank">PCG: A Family of Simple Fast Space-Efficient Statistically Good Algorithms for Random Number Generation</a>”.
The exhaustive analysis in the paper can make it hard to notice at first glance how utterly trivial the generators are:
PCG is a post-processed 128-bit LCG.</p>
<p>If the state <code>p.x</code> were a <code>uint128</code> (hypothetically), the code to compute the next value would be:</p>
<pre><code>const (
 pcgM = 0x2360ed051fc65da44385df649fccf645
 pcgA = 0x5851f42d4c957f2d14057b7ef767814f
)

type PCG struct {
 x uint128
}

func (p *PCG) Uint64() uint64 {
 p.x = p.x * pcgM + pcgA
 return scramble(p.x)
}
</code></pre>
<p>The entire state is a single 128-bit number,
and the update is a 128-bit multiply and add.
In the return statement, the <code>scramble</code> function reduces the 128-bit state
down to a 64-bit state.
The original PCG used (again using a hypothetical <code>uint128</code> type):</p>
<pre><code>func scramble(x uint128) uint64 {
 return bits.RotateLeft(uint64(x&gt;&gt;64) ^ uint64(x), -int(x&gt;&gt;122))
}
</code></pre>
<p>This code XORs the two halves of the 128-bit state together
and then rotates the result according to the top six bits of the state.
This version is called PCG-XSL-RR, for “xor shift low, right rotate”.</p>
<p>Based on a <a href="/issue/21835#issuecomment-739065688">suggestion from O&rsquo;Neill during proposal discussion</a>,
Go&rsquo;s PCG uses a new scramble function based on multiplication,
which mixes the bits more aggressively:</p>
<pre><code>func scramble(x uint128) uint64 {
 hi, lo := uint64(x&gt;&gt;64), uint64(x)
 hi ^= hi &gt;&gt; 32
 hi *= 0xda942042e4dd58b5
 hi ^= hi &gt;&gt; 48
 hi *= lo | 1
}
</code></pre>
<p>O&rsquo;Neill calls PCG with this scrambler PCG-DXSM, for “double xorshift multiply.”
Numpy uses this form of PCG as well.</p>
<p>Although PCG uses more computation to generate each value,
it uses significantly less state: two uint64s instead of 607.
It is also much less sensitive to the initial values of that state,
and <a href="https://www.pcg-random.org/statistical-tests.html" rel="noreferrer" target="_blank">it passes many statistical tests that other generators do not</a>.
In many ways it is an ideal statistical generator.</p>
<p>Even so, PCG is not unpredictable.
While the scrambling of bits to prepare the result does not
expose the state directly like in the LCG and Go 1 generators,
<a href="https://pdfs.semanticscholar.org/4c5e/4a263d92787850edd011d38521966751a179.pdf" rel="noreferrer" target="_blank">PCG-XSL-RR can still be be reversed</a>,
and it would not be surprising if PCG-DXSM could too.
For secrets, we need something different.</p>
<h2 id="cryptographic-randomness">Cryptographic Randomness</h2>
<p><em>Cryptographic random numbers</em> need to be utterly unpredictable
in practice, even to an observer who knows how they are generated
and has observed any number of previously generated values.
The safety of cryptographic protocols, secret keys, modern commerce,
online privacy, and more all critically depend on access to cryptographic
randomness.</p>
<p>Providing cryptographic randomness is ultimately the job of the
operating system, which can gather true randomness from physical devices—timings
of the mouse, keyboard, disks, and network, and more recently
<a href="https://web.archive.org/web/20141230024150/http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf" rel="noreferrer" target="_blank">electrical noise measured directly by the CPU itself</a>.
Once the operating system has gathered a meaningful
amount of randomness—say, at least 256 bits—it can use cryptographic
hashing or encryption algorithms to stretch that seed into
an arbitrarily long sequence of random numbers.
(In practice the operating system is also constantly gathering and
adding new randomness to the sequence too.)</p>
<p>The exact operating system interfaces have evolved over time.
A decade ago, most systems provided a device file named
<code>/dev/random</code> or something similar.
Today, in recognition of how fundamental randomness has become,
operating systems provide a direct system call instead.
(This also allows programs to read randomness even
when cut off from the file system.)
In Go, the <a href="/pkg/crypto/rand/"><code>crypto/rand</code></a> package abstracts away those details,
providing the same interface on every operating system: <a href="/pkg/crypto/rand/#Read"><code>rand.Read</code></a>.</p>
<p>It would not be practical for <code>math/rand</code> to ask the operating system for
randomness each time it needs a <code>uint64</code>.
But we can use cryptographic techniques to define an in-process
random generator that improves on LCGs, the Go 1 generator, and even PCG.</p>
<h2 id="the-chacha8rand-generator">The ChaCha8Rand Generator</h2>
<p>Our new generator, which we unimaginatively named ChaCha8Rand for specification purposes
and implemented as <code>math/rand/v2</code>&rsquo;s <a href="/pkg/math/rand/v2/#ChaCha8"><code>rand.ChaCha8</code></a>,
is a lightly modified version of Daniel J. Bernstein&rsquo;s <a href="https://cr.yp.to/chacha.html" rel="noreferrer" target="_blank">ChaCha stream cipher</a>.
ChaCha is widely used in a 20-round form called ChaCha20, including in TLS and SSH.
Jean-Philippe Aumasson&rsquo;s paper “<a href="https://eprint.iacr.org/2019/1492.pdf" rel="noreferrer" target="_blank">Too Much Crypto</a>”
argues persuasively that the 8-round form ChaCha8 is secure too (and it&rsquo;s roughly 2.5X faster).
We used ChaCha8 as the core of ChaCha8Rand.</p>
<p>Most stream ciphers, including ChaCha8, work by defining a function that is given
a key and a block number and produces a fixed-size block of apparently random data.
The cryptographic standard these aim for (and usually meet) is for this output to be indistinguishable
from actual random data in the absence of some kind of exponentially costly brute force search.
A message is encrypted or decrypted by XOR&rsquo;ing successive blocks of input data
with successive randomly generated blocks.
To use ChaCha8 as a <code>rand.Source</code>,
we use the generated blocks directly instead of XOR&rsquo;ing them with input data
(this is equivalent to encrypting or decrypting all zeros).</p>
<p>We changed a few details to make ChaCha8Rand more suitable for generating random numbers. Briefly:</p>
<ul>
<li>ChaCha8Rand takes a 32-byte seed, used as the ChaCha8 key.</li>
<li>ChaCha8 generates 64-byte blocks, with calculations treating a block as 16 <code>uint32</code>s.
A common implementation is to compute four blocks at a time using <a href="https://en.wikipedia.org/wiki/Single_instruction,_multiple_data" rel="noreferrer" target="_blank">SIMD instructions</a>
on 16 vector registers of four <code>uint32</code>s each.
This produces four interleaved blocks that must be unshuffled for XOR&rsquo;ing with the input data.
ChaCha8Rand defines that the interleaved blocks are the random data stream,
removing the cost of the unshuffle.
(For security purposes, this can be viewed as standard ChaCha8 followed by a reshuffle.)</li>
<li>ChaCha8 finishes a block by adding certain values to each <code>uint32</code> in the block.
Half the values are key material and the other half are known constants.
ChaCha8Rand defines that the known constants are not re-added,
removing half of the final adds.
(For security purposes, this can be viewed as standard ChaCha8 followed by subtracting the known constants.)</li>
<li>Every 16th generated block, ChaCha8Rand takes the final 32 bytes of the block for itself,
making them the key for the next 16 blocks.
This provides a kind of <a href="https://en.wikipedia.org/wiki/Forward_secrecy" rel="noreferrer" target="_blank">forward secrecy</a>:
if a system is compromised by an attack that
recovers the entire memory state of the generator, only values generated
since the last rekeying can be recovered. The past is inaccessible.
ChaCha8Rand as defined so far must generate 4 blocks at a time,
but we chose to do this key rotation every 16 blocks to leave open the
possibility of faster implementations using 256-bit or 512-bit vectors,
which could generate 8 or 16 blocks at a time.</li>
</ul>
<p>We wrote and published a <a href="https://c2sp.org/chacha8rand" rel="noreferrer" target="_blank">C2SP specification for ChaCha8Rand</a>,
along with test cases.
This will enable other implementations to share repeatability with the Go implementation
for a given seed.</p>
<p>The Go runtime now maintains a per-core ChaCha8Rand state (300 bytes),
seeded with operating system-supplied cryptographic randomness,
so that random numbers can be generated quickly without any lock contention.
Dedicating 300 bytes per core may sound expensive,
but on a 16-core system, it is about the same as storing a single shared Go 1 generator state (4,872 bytes).
The speed is worth the memory.
This per-core ChaCha8Rand generator is now used in three different places in the Go standard library:</p>
<ol>
<li>
<p>The <code>math/rand/v2</code> package functions, such as
<a href="/pkg/math/rand/v2/#Float64"><code>rand.Float64</code></a> and
<a href="/pkg/math/rand/v2/#N"><code>rand.N</code></a>, always use ChaCha8Rand.</p>
</li>
<li>
<p>The <code>math/rand</code> package functions, such as
<a href="/pkg/math/rand/#Float64"><code>rand.Float64</code></a> and
<a href="/pkg/math/rand/#Intn"><code>rand.Intn</code></a>,
use ChaCha8Rand when
<a href="/pkg/math/rand/#Seed"><code>rand.Seed</code></a> has not been called.
Applying ChaCha8Rand in <code>math/rand</code> improves the security of programs
even before they update to <code>math/rand/v2</code>,
provided they are not calling <code>rand.Seed</code>.
(If <code>rand.Seed</code> is called, the implementation is required to fall back to the Go 1 generator for compatibility.)</p>
</li>
<li>
<p>The runtime chooses the hash seed for each new map
using ChaCha8Rand instead of a less secure <a href="https://github.com/wangyi-fudan/wyhash" rel="noreferrer" target="_blank">wyrand-based generator</a>
it previously used.
Random seeds are needed because if
an attacker knows the specific hash function used by a map implementation,
they can prepare input that drives the map into quadratic behavior
(see Crosby and Wallach&rsquo;s “<a href="https://www.usenix.org/conference/12th-usenix-security-symposium/denial-service-algorithmic-complexity-attacks" rel="noreferrer" target="_blank">Denial of Service via Algorithmic Complexity Attacks</a>”).
Using a per-map seed, instead of one global seed for all maps,
also avoids <a href="https://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion" rel="noreferrer" target="_blank">other degenerate behaviors</a>.
It is not strictly clear that maps need a cryptographically random seed,
but it&rsquo;s also not clear that they don&rsquo;t. It seemed prudent and was trivial to switch.</p>
</li>
</ol>
<p>Code that needs its own ChaCha8Rand instances can create its own <a href="/pkg/math/rand/v2/#ChaCha8"><code>rand.ChaCha8</code></a> directly.</p>
<h2 id="fixing-security-mistakes">Fixing Security Mistakes</h2>
<p>Go aims to help developers write code that is secure by default.
When we observe a common mistake with security consequences,
we look for ways to reduce the risk of that mistake
or eliminate it entirely.
In this case, <code>math/rand</code>&rsquo;s global generator was far too predictable,
leading to serious problems in a variety of contexts.</p>
<p>For example, when Go 1.20 deprecated <a href="/pkg/math/rand/#Read"><code>math/rand</code>’s <code>Read</code></a>,
we heard from developers who discovered (thanks to tooling pointing out
use of deprecated functionality) they had been
using it in places where <a href="/pkg/crypto/rand/#Read"><code>crypto/rand</code>’s <code>Read</code></a>
was definitely needed, like generating key material.
Using Go 1.20, that mistake
is a serious security problem that merits a detailed investigation
to understand the damage.
Where were the keys used?
How were the keys exposed?
Were other random outputs exposed that might allow an attacker to derive the keys?
And so on.
Using Go 1.22, that mistake is just a mistake.
It&rsquo;s still better to use <code>crypto/rand</code>,
because the operating system kernel can do a better job keeping the random values
secret from various kinds of prying eyes,
the kernel is continually adding new entropy to its generator,
and the kernel has had more scrutiny.
But accidentally using <code>math/rand</code> is no longer a security catastrophe.</p>
<p>There are also a variety of use cases that don&rsquo;t seem like “crypto”
but nonetheless need unpredictable randomness.
These cases are made more robust by using ChaCha8Rand instead of the Go 1 generator.</p>
<p>For example, consider generating a
<a href="https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)" rel="noreferrer" target="_blank">random UUID</a>.
Since UUIDs are not secret, using <code>math/rand</code> might seem fine.
But if <code>math/rand</code> has been seeded with the current time,
then running it at the same instant on different computers
will produce the same value, making them not “universally unique”.
This is especially likely on systems where the current time
is only available with millisecond precision.
Even with auto-seeding using OS-provided entropy,
as introduced in Go 1.20,
the Go 1 generator&rsquo;s seed is only a 63-bit integer,
so a program that generates a UUID at startup
can only generate 2⁶³ possible UUIDs and is
likely to see collisions after 2³¹ or so UUIDs.
Using Go 1.22, the new ChaCha8Rand generator
is seeded from 256 bits of entropy and can generate
2²⁵⁶ possible first UUIDs.
It does not need to worry about collisions.</p>
<p>As another example, consider load balancing in a front-end server
that randomly assigns incoming requests to back-end servers.
If an attacker can observe the assignments and knows the
predictable algorithm generating them,
then the attacker could send a stream
of mostly cheap requests but arrange for all the expensive requests
to land on a single back-end server.
This is an unlikely but plausible problem using the Go 1 generator.
Using Go 1.22, it&rsquo;s not a problem at all.</p>
<p>In all these examples, Go 1.22 has eliminated or greatly reduced
security problems.</p>
<h2 id="performance">Performance</h2>
<p>The security benefits of ChaCha8Rand do have a small cost,
but ChaCha8Rand is still in the same ballpark as both the Go 1 generator and PCG.
The following graphs compare the performance of the three generators,
across a variety of hardware, running two operations:
the primitive operation “Uint64,” which returns the next <code>uint64</code> in the random stream,
and the higher-level operation “N(1000),” which returns a random value in the range [0, 1000).</p>
<div style="background-color: white;">
<img src="chacha8rand/amd.svg">
<img src="chacha8rand/intel.svg">
<img src="chacha8rand/amd32.svg">
<img src="chacha8rand/intel32.svg">
<img src="chacha8rand/m1.svg">
<img src="chacha8rand/m3.svg">
<img src="chacha8rand/taut2a.svg">
</div>
<p>The “running 32-bit code” graphs show modern 64-bit x86 chips
executing code built with <code>GOARCH=386</code>, meaning they are
running in 32-bit mode.
In that case, the fact that PCG requires 128-bit multiplications
makes it slower than ChaCha8Rand, which only uses 32-bit SIMD arithmetic.
Actual 32-bit systems matter less every year,
but it is still interesting that ChaCha8Rand is faster than PCG
on those systems.</p>
<p>On some systems, “Go 1: Uint64” is faster than “PCG: Uint64”,
but “Go 1: N(1000)” is slower than “PCG: N(1000)”.
This happens because “Go 1: N(1000)” is using <code>math/rand</code>&rsquo;s algorithm for
reducing a random <code>int64</code> down to a value in the range [0, 1000),
and that algorithm does two 64-bit integer divide operations.
In contrast, “PCG: N(1000)” and “ChaCha8: N(1000)” use the <a href="/blog/randv2#problem.rand">faster <code>math/rand/v2</code> algorithm</a>,
which almost always avoids the divisions.
Removing the 64-bit divisions dominates the algorithm change
for 32-bit execution and on the Ampere.</p>
<p>Overall, ChaCha8Rand is slower than the Go 1 generator,
but it is never more than twice as slow, and on typical servers the
difference is never more than 3ns.
Very few programs will be bottlenecked by this difference,
and many programs will enjoy the improved security.</p>
<h2 id="conclusion">Conclusion</h2>
<p>Go 1.22 makes your programs more secure without any code changes.
We did this by identifying the common mistake of accidentally using <code>math/rand</code>
instead of <code>crypto/rand</code> and then strengthening <code>math/rand</code>.
This is one small step in Go&rsquo;s ongoing journey to keep programs
safe by default.</p>
<p>These kinds of mistakes are not unique to Go.
For example, the npm <code>keypair</code> package tries to generate an RSA key pair
using Web Crypto APIs, but if they&rsquo;re not available, it falls back to JavaScript&rsquo;s <code>Math.random</code>.
This is hardly an isolated case,
and the security of our systems cannot depend on developers not making mistakes.
Instead, we hope that eventually all programming languages
will move to cryptographically strong pseudorandom generators
even for “mathematical” randomness,
eliminating this kind of mistake, or at least greatly reducing its blast radius.
Go 1.22&rsquo;s <a href="https://c2sp.org/chacha8rand" rel="noreferrer" target="_blank">ChaCha8Rand</a> implementation
proves that this approach is competitive with other generators.</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 <p>
 
 
 
 <b>Previous article: </b><a href="/blog/randv2">Evolving the Go Standard Library with math/rand/v2</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry><entry><title>Evolving the Go Standard Library with math/rand/v2</title><id>tag:blog.golang.org,2013:blog.golang.org/randv2</id><link rel="alternate" href="https://go.dev/blog/randv2"></link><published>2024-05-01T00:00:00+00:00</published><updated>2024-05-01T00:00:00+00:00</updated><author><name></name></author><summary type="html">Go 1.22 adds math/rand/v2 and charts a course for the evolution of the Go standard library.</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/randv2">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>Evolving the Go Standard Library with math/rand/v2</h1>
 
 <p class="author">
 Russ Cox<br>
 1 May 2024
 </p>
 
 <p>Since Go 1 was <a href="/blog/go1">released in March 2012</a>,
changes to the standard library have been
constrained by Go&rsquo;s <a href="/doc/go1compat">compatibility promise</a>.
Overall, compatibility has been a boon for Go users,
providing a stable base for production systems,
documentation, tutorials, books, and more.
Over time, however, we&rsquo;ve realized mistakes in the original APIs
that cannot be fixed compatibly; in other cases,
best practices and convention have changed.
We need a plan for making important, breaking changes too.</p>
<p>This blog post is about Go 1.22&rsquo;s new <a href="/pkg/math/rand/v2/"><code>math/rand/v2</code></a> package,
the first “v2” in the standard library.
It brings needed improvements to the <a href="/pkg/math/rand/"><code>math/rand</code></a> API,
but more importantly it sets an example for how we can
revise other standard library packages as the need arises.</p>
<p>(In Go, <code>math/rand</code> and <code>math/rand/v2</code> are two different packages
with different import paths.
Go 1 and every release after it have included <code>math/rand</code>; Go 1.22 added <code>math/rand/v2</code>.
A Go program can import either package, or both.)</p>
<p>This post discusses the specific rationale for the changes in <code>math/rand/v2</code>
and then <a href="#principles">reflects on the general principles</a> that will guide
new versions of other packages.</p>
<h2 id="pseudo">Pseudorandom Number Generators</h2>
<p>Before we look at <code>math/rand</code>, which is an API for a pseudorandom number generator,
let&rsquo;s take a moment to understand what that means.</p>
<p>A pseudorandom number generator is a deterministic program
that generates a long sequence of
seemingly random numbers from a small seed input,
although the numbers are not in fact random at all.
In the case of <code>math/rand</code>, the seed is a single int64,
and the algorithm produces a sequence of int64s
using a variant of a
<a href="https://en.wikipedia.org/wiki/Linear-feedback_shift_register" rel="noreferrer" target="_blank">linear-feedback shift register (LFSR)</a>.
The algorithm is based on an idea by George Marsaglia,
tweaked by Don Mitchell and Jim Reeds,
and further customized by Ken Thompson for Plan 9 and then Go.
It has no official name, so this post calls it the Go 1 generator.</p>
<p>The goal is for these generators to be fast,
repeatable, and random enough to support simulations,
shuffling, and other non-cryptographic use cases.
Repeatability is particularly important for uses like
numerical simulations or randomized testing.
For example, a randomized tester might pick a seed
(perhaps based on the current time), generate
a large random test input, and repeat.
When the tester finds a failure, it only needs to print the seed
to allow repeating the test with that specific large input.</p>
<p>Repeatability also matters over time: given a particular
seed, a new version of Go needs to generate the same
sequence of values that an older version did.
We didn&rsquo;t realize this when we released Go 1;
instead, we discovered it the hard way,
when we tried to make a change in Go 1.2
and got reports that we had broken certain tests
and other use cases.
At that point, we decided Go 1 compatibility included
the specific random outputs for a given seed
and <a href="/change/5aca0514941ce7dd0f3cea8d8ffe627dbcd542ca">added a test</a>.</p>
<p>It is not a goal for these kinds of generators to produce
random numbers suitable for deriving cryptographic keys
or other important secrets.
Because the seed is only 63 bits,
any output drawn from the generator, no matter how long,
will also only contain 63 bits of entropy.
For example, using <code>math/rand</code> to generate a 128-bit or 256-bit AES key
would be a serious mistake,
since the key would be easier to brute force.
For that kind of use, you need a cryptographically strong
random number generator, as provided by <a href="/pkg/crypto/rand/"><code>crypto/rand</code></a>.</p>
<p>That&rsquo;s enough background that we can move on to what needed
fixing in the <code>math/rand</code> package.</p>
<h2 id="problems">Problems with <code>math/rand</code></h2>
<p>Over time, we noticed more and more problems with <code>math/rand</code>.
The most serious were the following.</p>
<h3 id="problem.generator">Generator Algorithm</h3>
<p>The generator itself needed replacement.</p>
<p>The initial implementation of Go, while production ready, was in many ways a “pencil sketch”
of the entire system, working well enough to serve as a base for future development:
the compiler and runtime were written in C; the garbage collector was a conservative, single-threaded,
stop-the-world collector; and the libraries used basic implementations throughout.
From Go 1 through around Go 1.5, we went back and drew the “fully inked”
version of each of these: we converted the compiler and runtime to Go; we wrote a new, precise, parallel,
concurrent garbage collection with microsecond pause times; and we replaced
standard library implementations with more sophisticated, optimized algorithms
as needed.</p>
<p>Unfortunately, the repeatability requirement in <code>math/rand</code>
meant that we couldn&rsquo;t replace the generator there without
breaking compatibility.
We were stuck with the Go 1 generator,
which is reasonably fast (about 1.8ns per number on my M3 Mac)
but maintains an internal state of almost 5 kilobytes.
In contrast, Melissa O&rsquo;Neill&rsquo;s <a href="https://www.pcg-random.org/" rel="noreferrer" target="_blank">PCG family of generators</a>
generates better random numbers in about 2.1ns per number
with only 16 bytes of internal state.
We also wanted to explore using
Daniel J. Bernstein&rsquo;s <a href="https://cr.yp.to/chacha.html" rel="noreferrer" target="_blank">ChaCha stream cipher</a>
as a generator.
A <a href="/blog/chacha8rand">follow-up post</a> discusses that generator specifically.</p>
<h3 id="problem.source">Source Interface</h3>
<p>The <a href="/pkg/math/rand/#Source"><code>rand.Source</code> interface</a> was wrong.
That interface defines the
concept of a low-level random number generator that generates
non-negative <code>int64</code> values:</p>
<pre><code>% go doc -src math/rand.Source
package rand // import &quot;math/rand&quot;

// A Source represents a source of uniformly-distributed
// pseudo-random int64 values in the range [0, 1&lt;&lt;63).
//
// A Source is not safe for concurrent use by multiple goroutines.
type Source interface {
 Int63() int64
 Seed(seed int64)
}

func NewSource(seed int64) Source
%
</code></pre>
<p>(In the doc comment, “[0, N)” denotes a
<a href="https://en.wikipedia.org/wiki/Interval_(mathematics)#Definitions_and_terminology" rel="noreferrer" target="_blank">half-open interval</a>,
meaning the range includes 0 but ends just before 2⁶³.)</p>
<p>The <a href="/pkg/math/rand/#Rand"><code>rand.Rand</code> type</a> wraps a <code>Source</code>
to implement a richer set of operations, such as
generating <a href="/pkg/math/rand/#Rand.Intn">an integer between 0 and N</a>,
generating <a href="/pkg/math/rand/#Rand.Float64">floating-point numbers</a>, and so on.</p>
<p>We defined the <code>Source</code> interface to return a shortened 63-bit value
instead of a uint64 because that&rsquo;s what the Go 1 generator and
other widely-used generators produce,
and it matches the convention set by the C standard library.
But this was a mistake: more modern generators produce full-width uint64s,
which is a more convenient interface.</p>
<p>Another problem is the <code>Seed</code> method hard-coding an <code>int64</code> seed:
some generators are seeded by larger values,
and the interface provides no way to handle that.</p>
<h3 id="problem.seed">Seeding Responsibility</h3>
<p>A bigger problem with <code>Seed</code> is that responsibility for seeding the global generator was unclear.
Most users don&rsquo;t use <code>Source</code> and <code>Rand</code> directly.
Instead, the <code>math/rand</code> package provides a global generator
accessed by top-level functions like <a href="/pkg/math/rand/#Intn"><code>Intn</code></a>.
Following the C standard library, the global generator defaults to
behaving as if <code>Seed(1)</code> is called at startup.
This is good for repeatability but bad for programs that want
their random outputs to be different from one run to the next.
The package documentation suggests using <code>rand.Seed(time.Now().UnixNano())</code> in that case,
to make the generator&rsquo;s output time-dependent,
but what code should do this?</p>
<p>Probably the main package should be in charge of how <code>math/rand</code> is seeded:
it would be unfortunate for imported libraries to configure global state themselves,
since their choices might conflict with other libraries or the main package.
But what happens if a library needs some random data and wants to use <code>math/rand</code>?
What if the main package doesn&rsquo;t even know <code>math/rand</code> is being used?
We found that in practice many libraries add init functions
that seed the global generator with the current time, “just to be sure”.</p>
<p>Library packages seeding the global generator themselves causes a new problem.
Suppose package main imports two packages that both use <code>math/rand</code>:
package A assumes the global generator will be seeded by package main,
but package B seeds it in an <code>init</code> func.
And suppose that package main doesn&rsquo;t seed the generator itself.
Now package A&rsquo;s correct operation depends on the coincidence that package B is also
imported in the program.
If package main stops importing package B, package A will stop getting random values.
We observed this happening in practice in large codebases.</p>
<p>In retrospect, it was clearly a mistake to follow the C standard library here:
seeding the global generator automatically would remove the confusion
about who seeds it, and users would stop being surprised by repeatable
output when they didn&rsquo;t want that.</p>
<h3 id="problem.scale">Scalability</h3>
<p>The global generator also did not scale well.
Because top-level functions like <a href="/pkg/math/rand/#Intn"><code>rand.Intn</code></a>
can be called simultaneously from multiple goroutines,
the implementation needed a lock protecting the shared generator state.
In parallel usage, acquiring and releasing this lock was more expensive
than the actual generation.
It would make sense instead to have a per-thread generator state,
but doing so would break repeatability
in programs without concurrent use of <code>math/rand</code>.</p>
<h3 id="problem.rand">The <code>Rand</code> implementation was missing important optimizations</h3>
<p>The <a href="/pkg/math/rand/#Rand"><code>rand.Rand</code> type</a> wraps a <code>Source</code>
to implement a richer set of operations
For example, here is the Go 1 implementation of <code>Int63n</code>, which returns
a random integer in the range [0, <code>n</code>).</p>
<pre><code>func (r *Rand) Int63n(n int64) int64 {
 if n &lt;= 0 {
 panic(&quot;invalid argument to Int63n&quot;)
 }
 max := int64((1&lt;&lt;63 - 1) - (1&lt;&lt;63)%uint64(n))
 v := r.src.Int63()
 for v &gt; max {
 v = r.Int63()
 }
 return v % n
}
</code></pre>
<p>The actual conversion is easy: <code>v % n</code>.
However, no algorithm can convert 2⁶³ equally likely values
into <code>n</code> equally likely values unless 2⁶³ is a multiple of <code>n</code>:
otherwise some outputs will necessarily happen more often
than others. (As a simpler example, try converting 4 equally likely values into 3.)
The code computes <code>max</code> such that
<code>max+1</code> is the largest multiple of <code>n</code> less than or equal to 2⁶³,
and then the loop rejects random values greater than or equal to <code>max+1</code>.
Rejecting this too-large values ensures that all <code>n</code> outputs are equally likely.
For small <code>n</code>, needing to reject any value at all is rare;
rejection becomes more common and more important for larger values.
Even without the rejection loop, the two (slow) modulus operations
can make the conversion more expensive than generating the random value <code>v</code>
in the first place.</p>
<p>In 2018, <a href="https://arxiv.org/abs/1805.10941" rel="noreferrer" target="_blank">Daniel Lemire found an algorithm</a>
that avoids the divisions nearly all the time
(see also his <a href="https://lemire.me/blog/2019/06/06/nearly-divisionless-random-integer-generation-on-various-systems/" rel="noreferrer" target="_blank">2019 blog post</a>).
In <code>math/rand</code>, adopting Lemire&rsquo;s algorithm would make <code>Intn(1000)</code> 20-30% faster,
but we can&rsquo;t: the faster algorithm generates different values than the standard conversion,
breaking repeatability.</p>
<p>Other methods are also slower than they could be, constrained by repeatability.
For example, the <code>Float64</code> method could easily be sped up by about 10%
if we could change the generated value stream.
(This was the change we tried to make in Go 1.2 and rolled back, mentioned earlier.)</p>
<h3 id="problem.read">The <code>Read</code> Mistake</h3>
<p>As mentioned earlier, <code>math/rand</code> is not intended for
and not suitable for generating cryptographic secrets.
The <code>crypto/rand</code> package does that, and its fundamental
primitive is its <a href="/pkg/crypto/rand/#Read"><code>Read</code> function</a>
and <a href="/pkg/crypto/rand/#Reader"><code>Reader</code></a> variable.</p>
<p>In 2015, we accepted a proposal to make
<code>rand.Rand</code> implement <code>io.Reader</code> as well,
along with <a href="/pkg/math/rand/#Read">adding a top-level <code>Read</code> function</a>.
This seemed reasonable at the time,
but in retrospect we did not pay enough attention to the
software engineering aspects of this change.
Now if you want to read random data, now you have
two choices: <code>math/rand.Read</code> and <code>crypto/rand.Read</code>.
If the data is going to be used for key material,
it is very important to use <code>crypto/rand</code>,
but now it is possible to use <code>math/rand</code> instead,
potentially with disastrous consequences.</p>
<p>Tools like <code>goimports</code> and <code>gopls</code> have a special case
to make sure they prefer to use <code>rand.Read</code> from
<code>crypto/rand</code> instead of <code>math/rand</code>, but that&rsquo;s not a complete fix.
It would be better to remove <code>Read</code> entirely.</p>
<h2 id="fix.v1">Fixing <code>math/rand</code> directly</h2>
<p>Making a new, incompatible major version of a package is never our first choice:
that new version only benefits programs that switch to it,
leaving all existing usage of the old major version behind.
In contrast, fixing a problem in the existing package has much more impact,
since it fixes all the existing usage.
We should never create a <code>v2</code> without doing as much as possible to fix <code>v1</code>.
In the case of <code>math/rand</code>, we were able to partly address
a few of the problems described above:</p>
<ul>
<li>
<p>Go 1.8 introduced an optional <a href="/pkg/math/rand/#Uint64"><code>Source64</code> interface</a> with a <code>Uint64</code> method.
If a <code>Source</code> also implements <code>Source64</code>, then <code>Rand</code> uses that method
when appropriate.
This “extension interface” pattern provides a compatible (if slightly awkward)
way to revise an interface after the fact.</p>
</li>
<li>
<p>Go 1.20 automatically seeded the top-level generator and
deprecated <a href="/pkg/math/rand/#Seed"><code>rand.Seed</code></a>.
Although this may seem like an incompatible change
given our focus on repeatability of the output stream,
<a href="/issue/56319">we reasoned</a> that any imported package that called <a href="/pkg/math/rand/#Int"><code>rand.Int</code></a>
at init time or inside any computation would also
visibly change the output stream, and surely adding or removing
such a call cannot be considered a breaking change.
And if that&rsquo;s true, then auto-seeding is no worse,
and it would eliminate this source of fragility for future programs.
We also added a <a href="/doc/godebug">GODEBUG setting</a> to opt
back into the old behavior.
Then we marked the top-level <code>rand.Seed</code> as <a href="/wiki/Deprecated">deprecated</a>.
(Programs that need seeded repeatability can still use
<code>rand.New(rand.NewSource(seed))</code> to obtain a local generator
instead of using the global one.)</p>
</li>
<li>
<p>Having eliminated repeatability of the global output stream,
Go 1.20 was also able to make the global generator scale better
in programs that don&rsquo;t call <code>rand.Seed</code>,
replacing the Go 1 generator with a very cheap per-thread
<a href="https://github.com/wangyi-fudan/wyhash" rel="noreferrer" target="_blank">wyrand generator</a>
already used inside the Go runtime. This removed the global mutex
and made the top-level functions scale much better.
Programs that do call <code>rand.Seed</code> fall back to the
mutex-protected Go 1 generator.</p>
</li>
<li>
<p>We were able to adopt Lemire&rsquo;s optimization in the Go runtime,
and we also used it inside <a href="/pkg/math/rand/#Shuffle"><code>rand.Shuffle</code></a>,
which was implemented after Lemire&rsquo;s paper was published.</p>
</li>
<li>
<p>Although we couldn&rsquo;t remove <a href="/pkg/math/rand/#Read"><code>rand.Read</code></a> entirely,
Go 1.20 marked it <a href="/wiki/Deprecated">deprecated</a> in favor of
<code>crypto/rand</code>.
We have since heard from people who discovered that they were accidentally
using <code>math/rand.Read</code> in cryptographic contexts when their editors
flagged the use of the deprecated function.</p>
</li>
</ul>
<p>These fixes are imperfect and incomplete but also real improvements
that helped all users of the existing <code>math/rand</code> package.
For more complete fixes, we needed to turn our attention to <code>math/rand/v2</code>.</p>
<h2 id="fix.v2">Fixing the rest in <code>math/rand/v2</code></h2>
<p>Defining <code>math/rand/v2</code> took
significant planning,
then a <a href="/issue/60751">GitHub Discussion</a>
and then a <a href="/issue/61716">proposal discussion</a>.
It is the same
as <code>math/rand</code> with the following breaking changes
addressing the problems outlined above:</p>
<ul>
<li>
<p>We removed the Go 1 generator entirely, replacing it with two new generators,
<a href="/pkg/math/rand/v2/#PCG">PCG</a> and <a href="/pkg/math/rand/v2/#ChaCha8">ChaCha8</a>.
The new types are named for their algorithms (avoiding the generic name <code>NewSource</code>)
so that if another important algorithm needs to be added, it will fit well into the
naming scheme.</p>
<p>Adopting a suggestion from the proposal discussion, the new types implement the
<a href="/pkg/encoding/#BinaryMarshaler"><code>encoding.BinaryMarshaler</code></a>
and
<a href="/pkg/encoding/#BinaryUnmarshaler"><code>encoding.BinaryUnmarshaler</code></a>
interfaces.</p>
</li>
<li>
<p>We changed the <code>Source</code> interface, replacing the <code>Int63</code> method with a <code>Uint64</code> method
and deleting the <code>Seed</code> method. Implementations that support seeding can provide
their own concrete methods, like <a href="/pkg/math/rand/v2/#PCG.Seed"><code>PCG.Seed</code></a> and
<a href="/pkg/math/rand/v2/#ChaCha8.Seed"><code>ChaCha8.Seed</code></a>.
Note that the two take different seed types, and neither is a single <code>int64</code>.</p>
</li>
<li>
<p>We removed the top-level <code>Seed</code> function: the global functions like <code>Int</code> can only be used
in auto-seeded form now.</p>
</li>
<li>
<p>Removing the top-level <code>Seed</code> also let us hard-code the use of scalable,
per-thread generators by the top-level methods,
avoiding a GODEBUG check at each use.</p>
</li>
<li>
<p>We implemented Lemire&rsquo;s optimization for <code>Intn</code> and related functions.
The concrete <code>rand.Rand</code> API is now locked in to that value stream,
so we will not be able to take advantage of any optimizations yet to be discovered,
but at least we are up to date once again.
We also implemented the <code>Float32</code> and <code>Float64</code> optimizations we wanted to use back in Go 1.2.</p>
</li>
<li>
<p>During the proposal discussion, a contributor pointed out detectable bias in the
implementations of <code>ExpFloat64</code> and <code>NormFloat64</code>.
We fixed that bias and locked in the new value streams.</p>
</li>
<li>
<p><code>Perm</code> and <code>Shuffle</code> used different shuffling algorithms and produced different value streams,
because <code>Shuffle</code> happened second and used a faster algorithm.
Deleting <code>Perm</code> entirely would have made migration harder for users.
Instead we implemented <code>Perm</code> in terms of <code>Shuffle</code>, which still lets us
delete an implementation.</p>
</li>
<li>
<p>We renamed <code>Int31</code>, <code>Int63</code>, <code>Intn</code>, <code>Int31n</code>, and <code>Int63n</code> to
<code>Int32</code>, <code>Int64</code>, <code>IntN</code>, <code>Int32N</code>, and <code>Int64N</code>.
The 31 and 63 in the names were unnecessarily pedantic
and confusing, and the capitalized N is more idiomatic for a second
“word” in the name in Go.</p>
</li>
<li>
<p>We added <code>Uint</code>, <code>Uint32</code>, <code>Uint64</code>, <code>UintN</code>, <code>Uint32N</code>, and <code>Uint64N</code>
top-level functions and methods.
We needed to add <code>Uint64</code> to provide direct access to the core <code>Source</code>
functionality, and it seemed inconsistent not to add the others.</p>
</li>
<li>
<p>Adopting another suggestion from the proposal discussion,
we added a new top-level, generic function <code>N</code> that is like
<code>Int64N</code> or <code>Uint64N</code> but works for any integer type.
In the old API, to create a random duration of up to 5 seconds,
it was necessary to write:</p>
<pre><code>d := time.Duration(rand.Int63n(int64(5*time.Second)))
</code></pre>
<p>Using <code>N</code>, the equivalent code is:</p>
<pre><code>d := rand.N(5 * time.Second)
</code></pre>
<p><code>N</code> is only a top-level function; there is no <code>N</code> method on <code>rand.Rand</code>
because there are no generic methods in Go.
(Generic methods are not likely in the future, either;
they conflict badly with interfaces, and a complete implementation
would require either run-time code generation or slow execution.)</p>
</li>
<li>
<p>To ameliorate misuse of <code>math/rand</code> in cryptographic contexts,
we made <code>ChaCha8</code> the default generator used in global functions,
and we also changed the Go runtime to use it (replacing wyrand).
Programs are still strongly encouraged to use <code>crypto/rand</code>
to generate cryptographic secrets,
but accidentally using <code>math/rand/v2</code> is not as catastrophic
as using <code>math/rand</code> would be.
Even in <code>math/rand</code>, the global functions now use the <code>ChaCha8</code> generator when not explicitly seeded.</p>
</li>
</ul>
<h2 id="principles">Principles for evolving the Go standard library</h2>
<p>As mentioned at the start this post, one of the goals for this work
was to establish principles and a pattern for how we approach all
v2 packages in the standard library.
There will not be a glut of v2 packages
in the next few Go releases.
Instead, we will handle one package
at a time, making sure we set a quality bar that will last for another decade.
Many packages will not need a v2 at all.
But for those that do, our approach boils down to three principles.</p>
<p>First, a new, incompatible version of a package will use
<code>that/package/v2</code> as its import path,
following
<a href="https://research.swtch.com/vgo-import" rel="noreferrer" target="_blank">semantic import versioning</a>
just like a v2 module outside the standard library would.
This allows uses of the original package and the v2 package
to coexist in a single program,
which is critical for a
<a href="/talks/2016/refactor.article">gradual conversion</a> to the new API.</p>
<p>Second, all changes must be rooted in
respect for existing usage and users:
we must not introduce needless churn,
whether in the form of unnecessary changes to an existing package or
an entirely new package that must be learned instead.
In practice, that means we take the existing package
as the starting point
and only make changes that are well motivated
and provide a value that justifies the cost to users of updating.</p>
<p>Third, the v2 package must not leave v1 users behind.
Ideally, the v2 package should be able to do everything the v1 package
could do,
and when v2 is released, the v1 package should be rewritten
to be a thin wrapper around v2.
This would ensure that existing uses of v1 continue to benefit
from bug fixes and performance optimizations in v2.
Of course, given that v2 is introducing breaking changes,
this is not always possible, but it is always something to consider carefully.
For <code>math/rand/v2</code>, we arranged for the auto-seeded v1 functions to
call the v2 generator, but we were unable to share other code
due to the repeatability violations.
Ultimately <code>math/rand</code> is not a lot of code and does not require
regular maintenance, so the duplication is manageable.
In other contexts, more work to avoid duplication could be worthwhile.
For example, in the
<a href="/issue/63397">encoding/json/v2 design (still in progress)</a>,
although the default semantics and the API are changed,
the package provides configuration knobs that
make it possible to implement the v1 API.
When we eventually ship <code>encoding/json/v2</code>,
<code>encoding/json</code> (v1) will become a thin wrapper around it,
ensuring that users who don&rsquo;t migrate from v1 still
benefit from optimizations and security fixes in v2.</p>
<p>A <a href="/blog/chacha8rand">follow-up blog post</a> presents the <code>ChaCha8</code> generator in more detail.</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 
 
 <p>
 
 
 <b>Next article: </b><a href="/blog/chacha8rand">Secure Randomness in Go 1.22</a><br>
 
 
 
 
 <b>Previous article: </b><a href="/blog/survey2024-h1-results">Go Developer Survey 2024 H1 Results</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry><entry><title>Go Developer Survey 2024 H1 Results</title><id>tag:blog.golang.org,2013:blog.golang.org/survey2024-h1-results</id><link rel="alternate" href="https://go.dev/blog/survey2024-h1-results"></link><published>2024-04-09T00:00:00+00:00</published><updated>2024-04-09T00:00:00+00:00</updated><author><name></name></author><summary type="html">What we learned from our 2024 H1 developer survey</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/survey2024-h1-results">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>Go Developer Survey 2024 H1 Results</h1>
 
 <p class="author">
 Alice Merrick and Todd Kulesza<br>
 9 April 2024
 </p>
 
 <style type="text/css" scoped>
 .chart {
 margin-left: 1.5rem;
 margin-right: 1.5rem;
 width: 800px;
 }
 blockquote p {
 color: var(--color-text-subtle) !important;
 }

 .quote_source {
 font-style: italic;
 }

 @media (prefers-color-scheme: dark) {
 .chart {
 border-radius: 8px;
 }
 }
</style>
<h2 id="background">Background</h2>
<p>This post shares the results of our most recent Go Developer Survey, conducted
in January and February 2024. Along with capturing sentiments and challenges
around using Go and Go tooling, our primary focus areas for this survey were
about how developers are starting to use Go (or other languages) for
AI-related use cases, and particular challenges for those who are learning Go
or looking to expand their Go skill set.</p>
<p>We recruited participants from the Go blog and through randomized prompts in
the VS Code Go plug-in. This year, with the help of
<a href="https://jetbrains.com" rel="noreferrer" target="_blank">JetBrains</a>, we also included a randomized survey prompt in the
<a href="https://jetbrains.com/go/" rel="noreferrer" target="_blank">GoLand IDE</a>, allowing us to recruit a more
representative sample of Go developers. We received a total of 6,224
responses! A huge thank you to all those who contributed to making this
possible.</p>
<h2 id="tldr">Highlights</h2>
<ul>
<li>Developer sentiment remains high, with 93% of respondents expressing
satisfaction with Go over the past year.</li>
<li>A majority of respondents (80%) said they trust the Go team to &ldquo;do what&rsquo;s
best&rdquo; for developers like themselves when maintaining and evolving the
language.</li>
<li>Among survey respondents who build AI-powered applications and services,
there is a shared sense that Go is a strong platform for running these types
of applications in production. For example, a majority of respondents
working with AI-powered applications already use Go or would like to migrate
to Go for their AI-powered workloads, and the most serious challenges
developers encounter are related to the library and documentation ecosystems
rather than the core language and runtime. That said, the most commonly
documented paths for getting started are currently Python-centric, resulting
in many organizations starting AI-powered work in Python before moving to a
more production-ready language.</li>
<li>The most common kinds of AI-powered services respondents are building
include summarization tools, text generation tools, and chatbots. Responses
suggest that many of these use cases are internal-facing, such as chatbots
trained upon an organization&rsquo;s internal documentation and intended to answer
employee questions. We hypothesize that organizations are intentionally
starting with internal use cases to develop in-house expertise with LLMs
while avoiding potential public embarrassment when AI-powered agents behave
unexpectedly.</li>
<li>Lack of time or opportunities was the most commonly cited challenge for
respondents to reaching their Go-related learning goals, suggesting that
language learning is difficult to prioritize without a specific goal or
business case in mind. The next most common challenge was in learning new
best practices, concepts, and idioms that are particular to Go when coming
from other language ecosystems.</li>
</ul>
<h2 id="contents">Contents</h2>
<ul>
<li><a href="#sentiment">Developer sentiment</a></li>
<li><a href="#devenv">Developer environments</a></li>
<li><a href="#priorities">Resource and performance priorities</a></li>
<li><a href="#mlai">Understanding AI use cases for Go</a></li>
<li><a href="#learn">Learning challenges</a></li>
<li><a href="#demographics">Demographics</a></li>
<li><a href="#firmographics">Firmographics</a></li>
<li><a href="#methodology">Methodology</a></li>
<li><a href="#closing">Closing</a></li>
</ul>
<h2 id="sentiment">Developer sentiment</h2>
<p>Overall satisfaction remains high in the survey with 93% of respondents saying
they were somewhat or very satisfied with Go during the last year. This isn&rsquo;t
surprising, considering our audience is those who have voluntarily taken our
survey. But even among those who were randomly sampled from both VS Code and
GoLand, we still see comparable rates of satisfaction (92%). Although the
exact percentages fluctuate slightly from survey to survey, we do not see any
statistically significant differences from <a href="/blog/survey2023-h2-results">2023
H2</a>, when the satisfaction rate was
90%.</p>
<p><img src="survey2024h1/csat.svg" alt="Chart of developer satisfaction with Go"
class="chart" /></p>
<h3 id="trust">Trust</h3>
<p>This year we introduced a new metric for measuring developer trust. This was
an experimental question and its wording may change over time as we learn more
about how respondents interpreted it. Because this is the first time we asked
this question, we don&rsquo;t have previous years to give us context for our
results. We found that 80% of respondents somewhat or strongly agree that they
trust the Go team to do what&rsquo;s best for users like them. Respondents with 5 or
more years of experience with Go tended to agree more (83%) than those with
less than 2 years of experience (77%). This could reflect <a href="https://en.wikipedia.org/wiki/Survivorship_bias" rel="noreferrer" target="_blank">survivorship
bias</a> in that those who trust
the Go team more are more likely to continue using Go, or may reflect how
trust is calibrated over time.</p>
<p><img src="survey2024h1/trust_go.svg" alt="Chart of developer trust with the Go
team" class="chart" /></p>
<h3 id="community">Community satisfaction</h3>
<p>In the last year, almost a third of respondents (32%) said they participated
in the Go developer community either online or at in-person events. More
experienced Go developers were more likely to have participated in a community
event and were more satisfied with community events overall. Although we can&rsquo;t
draw causal conclusions from this data, we did see a positive correlation
between community satisfaction and overall satisfaction with Go. It could be
that participating in the Go community increases satisfaction through
increased social interaction or technical support. In general, we also found
that respondents with less experience were less likely to have participated in
events in the last year. This may mean they haven&rsquo;t discovered events or found
opportunities yet to be involved.</p>
<p><img src="survey2024h1/community_events.svg" alt="Chart of participation in
community events" class="chart" /> <img src="survey2024h1/community_sat.svg"
alt="Chart of community satisfaction" class="chart" /></p>
<h3 id="biggestchallenge">Biggest challenges</h3>
<p>For several years, this survey has asked participants about their biggest
challenge when using Go. This has always been in the form of an open text box
and has elicited a wide variety of responses. In this cycle we introduced a
closed form of the question, where we provided the most common write-in
responses from prior years. Respondents were randomly shown either the open or
closed forms of the question. The closed form helps us validate how we&rsquo;ve
historically interpreted these responses, while also increasing the number of
Go developers we hear from: this year participants who saw the closed form
were 2.5x more likely to answer than those who saw the open form. This higher
number of responses narrows our margin of error and increases our confidence
when interpreting survey results.</p>
<p>In the closed-form, only 8% of respondents selected &ldquo;Other&rdquo;, which suggests we
captured the majority of common challenges with our response choices.
Interestingly, 13% of respondents said they don&rsquo;t face any challenges using
Go. In the open text version of this question, only 2% of respondents gave
this response. The top responses in the closed-form were learning how to write
Go effectively (15%) and the verbosity of error handling (13%). This matches
what we saw in the open-text form, where 11% of responses mentioned learning
Go, learning best practices, or issues with documentation as their biggest
challenge, and another 11% mentioned error handling.</p>
<p><img src="survey2024h1/biggest_challenge_closed.svg" alt="Chart of closed form
biggest challenges using Go" class="chart" /> <img
src="survey2024h1/text_biggest_challenge.svg" alt="Chart of open text biggest
challenges using Go" class="chart" /></p>
<p>Respondents who saw the closed form of the question also received a follow-up
open-text question to give them an opportunity to tell us more about their
biggest challenge in case they had wanted to provide more nuanced answers,
additional challenges, or anything else they felt was important.The most
common response mentioned Go&rsquo;s type system, and often asked specifically for
enums, option types, or sum types in Go. Often we did not get much context for
these requests, but we suspect this is due to some recent proposals and
community discussions related to enums, an increase in folks coming from other
language ecosystems where these features are common, or the expectation that
these features will reduce writing boilerplate code. One of the more
comprehensive comments related to the type system explained as follows:</p>
<blockquote>
<p>&ldquo;These aren&rsquo;t big challenges, but more conveniences I miss in the language.
There&rsquo;s ways around all of them, but it would be nice not to have to think
about it.</p>
</blockquote>
<blockquote>
<p>Sum types/closed enums can be emulated but its a lot of faff. It&rsquo;s a very
handy feature to have when interacting with APIs that only have a limited
set of values for a particular element/field in a response and a value
outside of it is an error. It helps with validation and catching issues at
the point of entry and can often directly be generated from API
specifications like JSON Schema, OpenAPI or heaven forbid XML Schema
Definitions.</p>
</blockquote>
<blockquote>
<p>I don&rsquo;t mind the error checking verbosity at all, but the nil-checking with
pointers gets tedious especially when [I] need to drill into a deeply nested
struct of pointer fields. Some form of Optional/Result type or an ability to
chase through a chain of pointers and simply get a nil back instead of
triggering a runtime panic would be appreciated.&rdquo;</p>
</blockquote>
<p><img src="survey2024h1/text_biggest_challenge_anything.svg" alt="Chart of
anything else related to biggest challenges using Go" class="chart" /></p>
<h2 id="devenv">Developer environments</h2>
<p>As in previous years, most survey respondents develop with Go on Linux (61%)
and macOS (58%) systems. Although the numbers haven&rsquo;t changed much from year
to year, we did see some interesting differences in our self-selected sample.
The randomly sampled groups from JetBrains and VS Code were more likely (31%
and 33%, respectively) to develop on Windows than the self-selected group
(19%). We don&rsquo;t know exactly why the self-selected group is so different, but
we hypothesize that, because they likely encountered the survey from reading
the Go Blog, these respondents are some of the most engaged and experienced
developers in the community. Their operating system preferences might be
reflective of historical priorities of the core development team who typically
developed on Linux and macOS. Thankfully we have the random samples from
JetBrains and VS Code to provide a more representative view of developer
preferences.</p>
<p><img src="survey2024h1/os_dev.svg" alt="Chart of operating systems respondents
use when developing Go software" class="chart" /> <img
src="survey2024h1/os_dev_src.svg" alt="Chart of operating systems respondents
use when developing Go software, split by difference sample sources"
class="chart" /> <img src="survey2024h1/os_dev_exp.svg" alt="Chart of
operating systems respondents use when developing Go software, split by
duration of experience" class="chart" /></p>
<p>As a followup for the 17% of respondents who develop on WSL, we asked which
version they&rsquo;re using. 93% of respondents who develop on WSL are using version
2, so going forward, <a href="/issue/63503">the Go team at Microsoft has decided to focus their
efforts on WSL2.</a></p>
<p><img src="survey2024h1/wsl_version.svg" alt="Chart of WSL versions usage"
class="chart" /></p>
<p>Given that two of our sample populations were recruited from within VS Code or
GoLand, they are strongly biased towards preferring those editors. To avoid
skewing the results, we show the data here from the self-selected group only.
Similar to previous years, the most common code editors among Go Developer
Survey respondents continue to be <a href="https://code.visualstudio.com/" rel="noreferrer" target="_blank">VS Code</a>
(43%) and <a href="https://www.jetbrains.com/go/" rel="noreferrer" target="_blank">GoLand</a> (33%). We don&rsquo;t see any
statistically significant differences from mid-2023, (44% and 31%,
respectively).</p>
<p><img src="survey2024h1/editor.svg" alt="Chart of code editors respondents
prefer to use with Go" class="chart" /></p>
<p>With the prevalence of Go for cloud development and containerized workloads,
it&rsquo;s no surprise that Go developers primarily deploy to Linux environments
(93%). We didn&rsquo;t see any significant changes from last year.</p>
<p><img src="survey2024h1/os_deploy.svg" alt="Chart of platforms respondents
deploy Go software to" class="chart" /></p>
<p>Go is a popular language for modern cloud-based development, so we typically
include survey questions to help us understand which cloud platforms Go
developers are using and how satisfied they are with the three most popular
platforms: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud. This
section was only shown to respondents who said they use Go for their primary
job, about 76% of total respondents. 98% of those who saw this question work
on Go software that integrates with cloud services. Over half of respondents
used AWS (52%), while 27% used GCP for their Go development and deployments.
For both AWS and Google Cloud, we don&rsquo;t see any differences between small or
large companies in their likelihood to use either provider. Microsoft Azure is
the only cloud provider that is significantly more likely to be used in large
organizations (companies with &gt; 1,000 employees) than smaller shops. We didn&rsquo;t
see any significant differences in usage based on the size of the organization
for any other cloud providers.</p>
<p>The rates of satisfaction for using Go with AWS and Google Cloud were both
77%. Historically these rates have been about the same. As in previous years,
the satisfaction rate for Microsoft Azure was lower (57%).</p>
<p><img src="survey2024h1/cloud_platform.svg" alt="Chart of cloud platforms
respondents" class="chart" /> <img src="survey2024h1/cloud_sat_aws.svg"
alt="Chart of satisfaction with Go on AWS in the last year" class="chart" />
<img src="survey2024h1/cloud_sat_gcp.svg" alt="Chart of satisfaction with
using Go on Google Cloud in the last year" class="chart" /> <img
src="survey2024h1/cloud_sat_azure.svg" alt="Chart of satisfaction with using
Go on Microsoft Azure in the last year" class="chart" /></p>
<h2 id="priorities">Resource and Security Priorities</h2>
<p>To help prioritize the Go team&rsquo;s work, we wanted to understand the top
resource cost and security concerns for teams using Go. About half of
respondents using Go at work reported having at least one resource cost
concern in the last year (52%). The engineering costs of writing and maintaining Go
services was more common (28%) than concern for the costs of running Go
services (10%) or both about equally (12%). We didn&rsquo;t see any significant
differences in resource concerns between small and large organizations. To
address concerns about resource costs, the Go team is continuing to optimize
Go and enhance profile-guided optimization (PGO).</p>
<img src="survey2024h1/cost_concern.svg" alt="Chart of cost concerns respondents have had related to their Go usage in the last year" class="chart" />
<p>As for security priorities, we asked respondents to tell us up to three of
their top concerns. Of those who did have security concerns, overall, the top
concern was insecure coding practices (42%), followed by system
misconfiguration (29%). Our main takeaway is that respondents are especially
interested in tooling to help find and fix potential security issues while
they&rsquo;re writing code. This aligns with what we&rsquo;ve learned from prior research
into how developers find and address security vulnerabilities.</p>
<p><img src="survey2024h1/security_concern.svg" alt="Chart of cost concerns
respondents have had related Go usage in the last year" class="chart" /></p>
<h3 id="perf">Performance Tooling</h3>
<p>Our goals for this section were to measure how respondents perceive the ease
or difficulty of diagnosing performance issues and determine whether this task
is more or less difficult depending on their editor or IDE usage.
Specifically, we wanted to know if it&rsquo;s more difficult to diagnose performance
issues from the command line, and if we should invest in improving the
integration of performance diagnostic tooling within VS Code to make this task
easier. In our analyses, we show comparisons between respondents who prefer VS
Code or GoLand to highlight what we learned about the experience of using VS
Code compared to another common editor.</p>
<p>We first asked a general question about different kinds of tools and
techniques respondents use with Go to have some points of comparison. We found
that only 40% of respondents use tools to improve code performance or
efficiency. We didn&rsquo;t see any significant differences based on editor or IDE
preference, that is, VS Code users and GoLand users were about equally likely
to use tools to improve code performance or efficiency.</p>
<p><img src="survey2024h1/dev_techniques.svg" alt="Chart of different techniques
used for security, quality and performance" class="chart" /></p>
<p>Most respondents (73%) told us that identifying and addressing performance
issues is at least moderately important. Again, we didn&rsquo;t see any significant
differences here between GoLand and VS Code users in how important they found
diagnosing performance issues.</p>
<p><img src="survey2024h1/perf_importance.svg" alt="Chart of the importance of
identifying and addressing performance issues " class="chart" /></p>
<p>Overall, respondents did not find diagnosing performance issues easy, with 30%
reporting it was somewhat or very difficult and 46% saying it was neither easy
nor difficult. Contrary to our hypothesis, VS Code users were not more likely
to report challenges when diagnosing performance issues vs. other respondents.
Those using their command line for diagnosing performance issues, regardless
of their preferred editor, also did not report this task as more challenging
than those using their IDE. Years of experience was the only significant
factor we observed, where less experienced Go developers found it overall more
difficult to diagnose performance issues than more experienced Go developers.</p>
<p><img src="survey2024h1/perf_easiness.svg" alt="Chart of how easy or difficult
respondents found diagnosing performance issues " class="chart" /> <img
src="survey2024h1/perf_easiness_exp.svg" alt="Chart of how easy or difficult
respondents found diagnosing performance issues split by duration of
experience" class="chart" /> <img src="survey2024h1/perf_easiness_where.svg"
alt="Chart of how easy or difficult respondents found diagnosing performance
issues split by where they use performance diagnostic tools " class="chart" /></p>
<p>To answer our original question, most developers found it difficult to
diagnose performance issues in Go, regardless of their preferred editor or
tooling. This was especially true for developers with less than two years of
experience in Go.</p>
<p>We also included a follow-up for respondents who rated diagnosing performance
issues as at least slightly important to understand which issues were most
important to them. Latency, total memory, and total CPU were the top concerns.
There could be several explanations to the significance of these areas. First,
they are measurable and easily convertible into business costs. Secondly,
total memory and CPU usage represent physical constraints that necessitate
hardware upgrades or software optimizations for improvement. Moreover,
latency, total memory, and total CPU are more manageable by developers and can
impact even straightforward services. In contrast, GC performance and memory
allocation may only be relevant in rare cases or for exceptionally heavy
workloads. Additionally, latency stands out as the most user-visible metric,
as high latency results in slow services and dissatisfied users.</p>
<p><img src="survey2024h1/perf_concerns.svg" alt="Chart of which performance
issues are the highest concern to respondents" class="chart" /></p>
<h2 id="mlai">Understanding AI use cases for Go</h2>
<p>Our <a href="/blog/survey2023-h2-results#mlai">previous survey</a> asked Go
developers about their early experiences with generative AI systems. To go a
bit deeper this cycle, we asked several AI-related questions to understand how
respondents are building AI-powered (more specifically, LLM-powered) services.
We found that half of survey respondents (50%) work at organizations that are
building or exploring AI-powered services. Of these, just over half (56%) said
they were involved with adding AI capabilities to their organization&rsquo;s
services. Our remaining AI-related questions were only shown to this slice of
respondents.</p>
<p>Please be cautious about generalizing these participant responses to the
overall population of Go developers. Because only about ¼ of survey
respondents are working with AI-powered services, we suggest using this data
to understand the early adopters in this space, with the caveat that early
adopters tend to be a bit different than the majority of people who will
eventually adopt a technology. As an example, we expect that this audience is
experimenting with more models and SDKs than may be the case a year or two
from now, and encountering more challenges related to integrating those
services into their existing code base.</p>
<p><img src="survey2024h1/ai_org.svg" alt="Chart of respondents whose org is
currently building or exploring ML/AI based services" class="chart" /> <img
src="survey2024h1/ai_involved.svg" alt="Chart of respondents who are currently
involved in their orgs AI based development" class="chart" /></p>
<p>Among the audience of Go developers working professionally with generative AI
(GenAI) systems, a solid majority (81%) reported using OpenAI&rsquo;s ChatGPT or
DALL-E models. A collection of open-source models also saw high adoption, with
a majority of respondents (53%) using at least one of Llama, Mistral, or
another OSS model. We see some early evidence that larger organizations
(1,000+ employees) are a bit less likely to be using OpenAI models (74% vs.
83%) and a bit more likely to be using other proprietary models (22% vs. 11%).
We do not, however, see any evidence of differences in adoption of OSS models
based on organization size–both smaller companies and larger enterprises show
small majorities adopting OSS models (51% and 53%, respectively). Overall we
found that a plurality of respondents prefer to use open-source models (47%)
with only 19% preferring proprietary models; 37% said they had no preference.</p>
<p><img src="survey2024h1/generative_models.svg" alt="Chart of which generative
AI models respondents' orgs are using" class="chart" /> <img
src="survey2024h1/ai_libs.svg" alt="Chart of which AI related services and
libraries respondents' orgs are using" class="chart" /></p>
<p>The most common kinds of services respondents are building include
summarization tools (56%), text generation tools (55%), and chatbots (46%).
Open-text responses suggested that many of these use cases are
internal-facing, such as chat bots trained upon an organization&rsquo;s internal
documentation and intended to answer employee questions. Respondents raised
several concerns about external-facing AI features, most notably due to
reliability (e.g., do slight changes in my question lead to very different
results?) and accuracy (e.g., are the results trustworthy?) issues. An
interesting theme running through these responses was a sense of tension
between the risk of not adopting AI tooling at all (and thereby losing a
potential competitive advantage should generative AI become necessary in the
future), balanced against the risk of negative publicity or violating
regulations/laws by using untested AI in high-criticality customer-facing
domains.</p>
<p>We found evidence that Go is already being used in the GenAI space, and there
appears to be an appetite for more. Roughly ⅓ of respondents who were building
AI-powered features told us they were already using Go for a variety of GenAI
tasks, including prototyping new features and integrating services with LLMs.
These proportions tick up slightly for two areas where we believe Go is a
particularly well-suited tool: data pipelines for ML/AI systems (37%) and
hosting API endpoints for ML/AI models (41%). In addition to these (likely
early) adopters, we found that about ¼ of respondents <em>want</em> to use Go for
these types of uses, but are currently blocked by something. We&rsquo;ll return to
these blockers shortly, after exploring why respondents wanted to use Go for
these tasks in the first place.</p>
<p><img src="survey2024h1/ai_apps.svg" alt="Chart of the kinds of Generative AI
apps respondents work on" class="chart" /> <img
src="survey2024h1/ai_uses_interest.svg" alt="Chart of the kinds of AI apps
respondents' orgs are currently working on or considering" class="chart" /></p>
<h3 id="reasons-for-using-go-with-generative-ai-systems">Reasons for using Go with generative AI systems</h3>
<p>To help us understand what benefits developers hope to derive from using Go in
their AI/ML services, we asked developers why they feel Go is a good choice
for this domain. A clear majority (61%) of respondents mentioned one or more
of Go&rsquo;s core principles or features, such as simplicity, runtime safety,
concurrency, or single-binary deployments. One third of respondents cited
existing familiarity with Go, including a desire to avoid introducing new
languages if they can avoid it. Rounding out the most common responses were
various challenges with Python (particularly for running production services)
at 14%.</p>
<blockquote>
<p>&ldquo;I think that the robustness, simplicity, performance and native binaries
that the language offers make it a far stronger choice for AI workloads.&rdquo;
<span class="quote_source">&mdash; Open-source Go developer at a large
organization with up to 1 year of experience</span></p>
</blockquote>
<blockquote>
<p>&ldquo;We want to keep our tech stack as homogenous as possible across the
organization to make it easier for everybody to develop on all areas. Since
we are already writing all our backends in Go, it is of interest to us to be
able to write ML model deployments in Go and avoid having to rewrite parts
of the stack for logging, monitoring, etc&hellip; in a separate language [like]
Python.&rdquo; <span class="quote_source">&mdash; Professional Go developer at a
mid-sized organization with 5 – 7 years of experience</span></p>
</blockquote>
<blockquote>
<p>&ldquo;Go is better for us at running API servers and background tasks on worker
pools. Go&rsquo;s lower resource usage has allowed us to grow without using more
resources. And we have found that Go projects are easier to maintain over
time both in code changes and when updating dependencies. We run the models
as a separate service written in Python and interact with them in Go.&rdquo;
<span class="quote_source">&mdash; Professional Go developer at a large
organization with 5 – 7 years of experience</span></p>
</blockquote>
<p>It appears that among Go developers who are interested in ML/AI, there is a
shared sense that 1) Go is inherently a good language for this domain (for the
reasons articulated above), and 2) there is reluctance to introduce a new
language once organizations have already invested in Go (this point reasonably
generalizes to any language). Some respondents also expressed frustration with
Python for reasons such as type safety, code quality, and challenging
deployments.</p>
<p><img src="survey2024h1/text_ml_interest.svg" alt="Chart of respondents'
reasons for why Go is a good choice for their AI related use case"
class="chart" /></p>
<h3 id="challenges-when-using-go-with-genai-systems">Challenges when using Go with GenAI systems</h3>
<p>Respondents were largely unified on what currently prevents them from using Go
with AI-powered services: the ecosystem is centered around Python, their
favorite libraries/frameworks are all in Python, getting started documentation
assumes Python familiarity, and the data scientists or researchers exploring
these models are already familiar with Python.</p>
<blockquote>
<p>&ldquo;Python just seems to have all the libraries. PyTorch for example is widely
used to run models. If there were frameworks in Go to run these models, we&rsquo;d
much rather be doing that.&rdquo; <span class="quote_source">&mdash; Professional Go
developer at a large organization with 2 – 4 years of experience</space></p>
</blockquote>
<blockquote>
<p>&ldquo;Python tools are substantially more mature and usable out of the box,
making them a significantly lower cost to implement.&rdquo;
<span class="quote_source">&mdash; Professional Go developer at a small
organization with 2 – 4 years of experience</span></p>
</blockquote>
<blockquote>
<p>&ldquo;[The] Go world is missing many AI libraries. If I have a LLM PyTorch model,
I can&rsquo;t even serve it (or I&rsquo;m unaware how to do it). With Python it&rsquo;s
basically a few lines of code.&rdquo; <span class="quote_source">&mdash; Professional
Go developer at a small organization with up to 1 year of experience</span></p>
</blockquote>
<p>These findings triangulate well with our observation above that Go developers
believe Go <em>should</em> be a great language for building production-ready AI
services: only 3% of respondents said that something specific to Go was
blocking their path forward, and only 2% cited specific interoperability
challenges with Python. In other words, most blockers developers face could be
resolved in the module and documentation ecosystem, rather than necessitating
core language or runtime changes.</p>
<p><img src="survey2024h1/text_ml_blockers.svg" alt="Chart of what is blocking
respondents from using Go with their AI powered apps" class="chart" /></p>
<p>We also asked survey participants whether they were already working with
Python for GenAI, and if so, whether they&rsquo;d prefer to use Go. Respondents who
said they&rsquo;d prefer to use Go rather than Python also received a follow-up
about what would enable them to use Go with GenAI systems.</p>
<p>A solid majority (62%) of respondents reported already using Python to
integrate with generative AI models; of this group, 57% would rather use Go
instead. Given that our survey audience are all Go developers, we should
expect this to be an approximate upper bound on the proportion of overall
developers who are interested in moving from Python to Go for GenAI tasks,
given the state of each ecosystem today.</p>
<p>Of the respondents who are already using Python but would prefer to use Go,
the vast majority (92%) said that the availability of Go equivalents for
Python libraries would enable them to integrate Go with GenAI systems.
However, we should be cautious when interpreting this result; the open-text
responses and a separate set of contextual interviews with developers working
on GenAI services describe a Python-centric ecosystem around GenAI; it&rsquo;s not
only that Go lacks many libraries when compared with the Python ecosystem, but
also that the perceived level of investment into Go libraries is lower,
documentation and examples are predominantly in Python, and the network of
experts working in this area are already comfortable with Python.
Experimenting and building proofs-of-concept in Python is almost certain to
continue, and the lack of Go variants of Python libraries (for example,
<a href="https://pandas.pydata.org/" rel="noreferrer" target="_blank">pandas</a>) is only the first barrier developers
would encounter when trying to port from Python to Go. Libraries and SDKs are
necessary, but unlikely by themselves to be sufficient, to build a robust Go
ecosystem for production ML/AI applications.</p>
<p>Further, contextual interviews with Go developers building AI-powered services
suggest that <em>calling</em> APIs from Go is not a major issue, particularly with
hosted models such as <a href="https://openai.com/gpt-4" rel="noreferrer" target="_blank">GPT-4</a> or
<a href="https://gemini.google.com/" rel="noreferrer" target="_blank">Gemini</a>. Building, evaluating, and hosting custom
models is seen as challenging in Go (primarily due to the lack of frameworks
and libraries that support this in Python), but interview participants
distinguished between hobbyist use cases (e.g., playing around with custom
models at home) and business use cases. The hobbyist cases are dominated by
Python for all of the reasons enumerated above, but the business use cases are
more focused around reliability, accuracy, and performance while calling
hosted models. This is an area where Go can shine <em>without</em> building a large
ecosystem of ML/AI/data science libraries, though we expect developers will
still benefit from documentation, best practice guidance, and examples.</p>
<p>Because the field of GenAI is so novel, best practices are still being
identified and tested. Initial contextual interviews with developers have
suggested that one of their goals is to be prepared for a future in which
GenAI becomes a competitive advantage; by making some investment in this area
now, they hope to moderate future risk. They&rsquo;re also still trying to
understand what GenAI systems might be helpful for and what the return on
investment (if any) may look like. Due to these unknowns, our early data
suggests that organizations (especially outside the tech industry) may be
hesitant to make long-term commitments here, and will instead pursue a lean or
scrappy approach until either a reliable use case with clear benefits emerges,
or their industry peers begin to make large, public investments in this space.</p>
<p><img src="survey2024h1/python_usage.svg" alt="Chart showing high usage of
Python to integrate with gen AI models" class="chart" /> <img
src="survey2024h1/go_python_pref.svg" alt="Chart showing preference to use Go
rather than Python to integrate with gen AI models" class="chart" /> <img
src="survey2024h1/enable_go.svg" alt="Chart of what would enable respondents
to use Go where they are currently using Python" class="chart" /> <img
src="survey2024h1/text_ml_challenge.svg" alt="Chart of biggest challenges for
respondents integrating backend services with gen AI models" class="chart" /></p>
<h2 id="learn">Learning challenges</h2>
<p>In order to improve the experience of learning Go, we wanted to hear from
inexperienced Go developers, as well as those who might have already mastered
the basics on what they see as their biggest challenge to meeting their
learning goals. We also wanted to hear from developers who might primarily be
focused on helping others get started with Go rather than their own learning
goals, since they might have some insights on common challenges they see when
onboarding developers.</p>
<p>Only 3% of respondents said that they were currently learning the basics of
Go. This isn&rsquo;t too surprising, considering most of our survey respondents
have at least a year of experience with Go. Meanwhile, 40% of respondents said
that they have already learned the basics but want to learn more advanced
topics and another 40% said that they help other developers learn Go. Only 15%
said they didn&rsquo;t have any learning goals related to Go.</p>
<p><img src="survey2024h1/learning_goal.svg" alt="Chart of respondents' learning
goals for Go" class="chart" /></p>
<p>When we looked at more finely grained time segments of Go experience, we found
that 30% of those who&rsquo;ve been using Go for less than three months say they&rsquo;re
learning the basics of Go, while about two-thirds of them say that they&rsquo;ve
already learned the basics. That&rsquo;s good evidence that someone can at least
feel like they&rsquo;ve learned the basics of Go in a short amount of time, but it
also means we don&rsquo;t have as much feedback from this group who are at the
beginning of their learning journey.</p>
<p><img src="survey2024h1/learning_goal_go_exp.svg" alt="Chart of respondents'
learning goals for Go split by finer units of time" class="chart" /></p>
<p>To determine what kinds of learning materials might be most needed in the
community, we asked what kind of learning content respondents preferred for
topics related to software development. They were able to select multiple
options so the numbers here exceed 100%. 87% of respondents said they
preferred written content, which was by far the most preferred format. 52%
said they preferred video content, and in particular this format was more
often preferred by developers with less experience. This could indicate a
growing desire for learning content in video format. The less experienced
demographic did not prefer written content any less than other groups,
however. <a href="https://www.sciencedirect.com/science/article/abs/pii/S0360131514001353" rel="noreferrer" target="_blank">Providing both written and video formats together has been shown to
improve learning
outcomes</a>
and <a href="https://udlguidelines.cast.org/representation/perception" rel="noreferrer" target="_blank">helps developers with different learning preferences and
abilities</a>, which
could increase the accessibility of learning content in the Go community.</p>
<p><img src="survey2024h1/learning_content_exp.svg" alt="Chart of respondents'
preferred formats for learning content, split by years of Go experience"
class="chart" /></p>
<p>We asked respondents who said they had a learning goal related to Go what
their biggest challenge was to reaching their goal. This was intentionally
left broad enough that someone who was just getting started or who had already
mastered the basics could respond to this question. We also wanted to give
respondents the opportunity to tell us about a wide range of challenges, not
just topics they find difficult.</p>
<p>Overwhelmingly, the most common challenge mentioned was a lack of time or
other personal limitations such as focus or motivation to learn or (44%).
Although we can&rsquo;t give respondents more time, we should be mindful when we&rsquo;re
producing learning materials or introducing changes in the ecosystem that
users may be operating under significant time constraints. There may also be
opportunities for educators to produce resources that are <a href="https://web.cortland.edu/frieda/id/IDtheories/26.html" rel="noreferrer" target="_blank">digestible in
smaller portions</a> or
<a href="https://psychology.ucsd.edu/undergraduate-program/undergraduate-resources/academic-writing-resources/effective-studying/spaced-practice.html#:~:text=This%20is%20known%20as%20spaced,information%20and%20retain%20it%20longer." rel="noreferrer" target="_blank">at a regular
cadence</a>
to keep learners motivated.</p>
<p>Other than time, the top challenge was learning new concepts, idioms or best
practices that are unique to Go (11%). In particular, adapting to a statically
typed compiled language from Python or JavaScript and learning how to organize
Go code can be particularly challenging. Respondents also asked for more
examples (6%), both in documentation and real world applications to learn
from. Developers coming from a larger developer community expected to be able
to find more existing solutions and examples.</p>
<blockquote>
<p>&ldquo;Moving from a language like Python to a statically typed, compiled language
has been challenging, but Go itself hasn&rsquo;t been. I like to learn through
quick feedback, so Python&rsquo;s REPL was great for that. So now I need to focus
on really reading documentation and examples to be able to learn. Some of
the documentation for Go is quite sparse and could do with more examples.&rdquo;
<span class="quote_source">&mdash; Respondent with less than 3 years of
experience with Go.</span></p>
</blockquote>
<blockquote>
<p>&ldquo;My main challenge is the lack of example projects for enterprise-level
applications. How to organize a big Go project is something I would like to
have more examples as reference. I would like to refactor the current
project I am working [on] to a more modular/clean architecture style, and I
find it difficult in Go due to lack of examples / a more opinionated
‘folder/package&rsquo; reference.&rdquo; <span class="quote_source">&mdash; Respondent with
1–2 years of experience with Go.</span></p>
</blockquote>
<blockquote>
<p>&ldquo;It&rsquo;s a smaller ecosystem than I am used to so online searches don&rsquo;t yield
as many results to specific issues. The resources that are out there are
incredibly helpful and I usually am able to solve issues eventually, it just
takes a little longer.&quot;<span class="quote_source">&mdash; Respondent with less
than 3 months of experience with Go.</span></p>
</blockquote>
<p><img src="survey2024h1/text_learning_challenge.svg" alt="Chart of biggest
challenges to reaching respondents' learning goals" class="chart" /></p>
<p>For respondents whose primary learning goal was to help others get started
with Go, we asked what might make it easier for developers to get started with
Go. We got a wide range of responses including documentation suggestions,
comments on difficult topics (e.g., using pointers or concurrency), as well as
requests for adding more familiar features from other languages. For
categories that made up less than 2% of responses, we lumped them into &ldquo;Other&rdquo;
responses. Interestingly, nobody mentioned &ldquo;more time.&rdquo; We think this is
because lack of time or motivation is most often a challenge when there isn&rsquo;t
an immediate necessity to learn something new related to Go. For those helping
others get started with Go, there may be a business reason for doing so,
making it easier to prioritize, and hence &ldquo;lack of time&rdquo; is not as much of a
challenge.</p>
<p>Consistent with the previous results, 16% of those who help others get started
with Go told us that new Go developers would benefit from having more
realistic examples or project-based exercises to learn from. They also saw the
need to help developers coming from other language ecosystems through
comparisons between them. <a href="https://dl.acm.org/doi/abs/10.1145/3377811.3380352" rel="noreferrer" target="_blank">Previous research tells us that experience with one
programming language can interfere with learning a new
one</a>, especially when new
concepts and tooling are different from what developers are used to. There are
existing resources that aim to address this issue (just try searching for
&ldquo;Golang for [language] developers&rdquo; for examples), but it could be difficult
for new Go developers to search for concepts they don&rsquo;t have the vocabulary
for yet or these kinds of resources might not adequately address specific
tasks. In the future we would like to learn more about how and when to present
language comparisons to facilitate learning new concepts.</p>
<p>A related need that this group reported was more explanations behind Go&rsquo;s
philosophy and best practices. It could be the case that learning not only
<em>what</em> makes Go different but also <em>why</em> would help new Go developers
understand new concepts or ways of doing tasks that might be different from
their previous experience.</p>
<p><img src="survey2024h1/text_onboard_others.svg" alt="Chart of ideas from
respondents who help others get started with Go" class="chart" /></p>
<h2 id="demographics">Demographics</h2>
<p>We ask similar demographic questions during each cycle of this survey so we
can understand how comparable the year-over-year results may be. For example,
if a majority of respondents reported having less than one year of experience
with Go in one survey cycle, it&rsquo;d be very likely that any other differences in
results from prior cycles stem from this major demographic shift. We also use
these questions to provide comparisons between groups, such as satisfaction
according to how long respondents have been using Go.</p>
<p>This year we introduced some minor changes to how we ask about experience with
Go to match the JetBrains developer survey. This allowed us to make
comparisons between our survey populations and facilitated data analysis.</p>
<p><img src="survey2024h1/go_exp.svg" alt="Chart of how long respondents have
been working with Go" class="chart" /></p>
<p>We saw some differences in experience level depending on how developers
discovered our survey. The population who responded to survey notifications in
VS Code skewed toward less experience with Go; we suspect this a reflection of
VS Code&rsquo;s popularity with new Go developers, who may not be ready to invest in
an IDE license while they&rsquo;re still learning. With respect to years of Go
experience, the respondents randomly selected from GoLand are more similar to
our self-selected population who found the survey through the Go Blog. Seeing
consistencies between samples such as these allows us to more confidently
generalize findings to the rest of the community.</p>
<p><img src="survey2024h1/go_exp_src.svg" alt="Chart of how long respondents have
been working with Go, split by different sample sources" class="chart" /></p>
<p>In addition to years of experience with Go, this year we also measured years
of professional coding experience. We were surprised to find that 26% of
respondents have 16 or more years of professional coding experience. For
comparison, the <a href="https://www.jetbrains.com/lp/devecosystem-2023/demographics/#code_yrs" rel="noreferrer" target="_blank">JetBrains Developer Survey
audience</a>
from 2023 had a majority of respondents with 3–5 years of professional
experience. Having a more experienced demographic could affect differences in
responses. For example, we saw significant differences in what kinds of
learning content respondents with different levels of experience preferred.</p>
<p><img src="survey2024h1/dev_exp.svg" alt="Chart of respondents' years of
professional developer experience" class="chart" /></p>
<p>When we looked at our different samples, the self-selected group was even more
experienced than the randomly selected groups, with 29% having 16 or more
years of professional experience. This suggests that our self-selected group
is generally more experienced than our randomly selected groups and can help
explain some of the differences we see in this group.</p>
<p><img src="survey2024h1/dev_exp_src.svg" alt="Chart of respondents' years of
professional developer experience" class="chart" /></p>
<p>We introduced another demographic question during this cycle on employment
status to help us make comparisons with <a href="https://www.jetbrains.com/lp/devecosystem-2023/demographics/#employment_status" rel="noreferrer" target="_blank">JetBrains&rsquo; Developer
Survey</a>.
We found that 81% of respondents were fully employed, significantly more than
63% on the JetBrains survey. We also found significantly fewer students in our
population (4%) compared to 15% on the JetBrains survey. When we look at our
individual samples, we see a small but significant difference within our
respondents from VS Code, who are slightly less likely to be fully employed
and slightly more likely to be students. This makes sense given that VS Code
is free.</p>
<p><img src="survey2024h1/employment.svg" alt="Chart of respondents' employment
status" class="chart" /></p>
<p>Similar to previous years, the most common use cases for Go were API/RPC
services (74%) and command line tools (63%). We&rsquo;ve heard that Go&rsquo;s built-in
HTTP server and concurrency primitives, ease of cross-compilation, and
single-binary deployments make Go a good choice for these kinds of
applications.</p>
<p>We also looked for differences based on respondents&rsquo; level of experience with
Go and organization size. More experienced Go developers reported building a
wider variety of applications in Go. This trend was consistent across every
category of app or service. We did not find any notable differences in what
respondents are building based on their organization size.</p>
<p><img src="survey2024h1/what.svg" alt="Chart of the types of things respondents
are building with Go" class="chart" /></p>
<h2 id="firmographics">Firmographics</h2>
<p>We heard from respondents at a variety of different organizations. About 27%
worked at large organizations with 1,000 or more employees, 25% were from
midsize organizations of 100–1,000 employees, and 43% worked at smaller
organizations with less than 100 employees. As in previous years, the most
common industry people work in was technology (48%) while the second most
common was financial services (13%) .</p>
<p>This is statistically unchanged from the past few Go Developer Surveys—we
continue to hear from people in different countries and in organizations of
different sizes and industries at consistent rates year after year.</p>
<p><img src="survey2024h1/org_size.svg" alt="Chart of the different organization
sizes where respondents use Go" class="chart" /></p>
<p><img src="survey2024h1/industry.svg" alt="Chart of the different industries
where respondents use Go" class="chart" /></p>
<p><img src="survey2024h1/location.svg" alt="Chart of countries or regions where
respondents are located" class="chart" /></p>
<h2 id="methodology">Methodology</h2>
<p>Prior to 2021, we announced the survey primarily through the Go Blog, where it
was picked up on various social channels like Twitter, Reddit, or Hacker News.
In 2021 we introduced a new way to recruit respondents by using the VS Code Go
plugin to randomly select users to be shown a prompt asking if they&rsquo;d like to
participate in the survey. This created a random sample that we used to
compare the self-selected respondents from our traditional channels and helped
identify potential effects of <a href="https://en.wikipedia.org/wiki/Self-selection_bias" rel="noreferrer" target="_blank">self-selection
bias</a>. For this cycle, our
friends at JetBrains generously provided us with an additional random sample
by prompting a random subset of GoLand users to take the survey!</p>
<p>64% of survey respondents &ldquo;self-selected&rdquo; to take the survey, meaning they
found it on the Go blog or other social Go channels. People who don&rsquo;t follow
these channels are less likely to learn about the survey from them, and in
some cases, they respond differently than people who do closely follow them.
For example, they might be new to the Go community and not yet aware of the Go
blog. About 36% of respondents were randomly sampled, meaning they responded
to the survey after seeing a prompt in VS Code (25%) or GoLand (11%). Over the
period of January 23 &ndash; February 13, there was roughly a 10% chance that users
would have seen this prompt. By examining how the randomly sampled groups
differ from the self-selected responses, as well as from each other, we&rsquo;re
able to more confidently generalize findings to the larger community of Go
developers.</p>
<p><img src="survey2024h1/source.svg" alt="Chart of different sources of survey
respondents" class="chart" /></p>
<h3 id="how-to-read-these-results">How to read these results</h3>
<p>Throughout this report we use charts of survey responses to provide supporting
evidence for our findings. All of these charts use a similar format. The title
is the exact question that survey respondents saw. Unless otherwise noted,
questions were multiple choice and participants could only select a single
response choice; each chart&rsquo;s subtitle will tell the reader if the question
allowed multiple response choices or was an open-ended text box instead of a
multiple choice question. For charts of open-ended text responses, a Go team
member read and manually categorized all of the responses. Many open-ended
questions elicited a wide variety of responses; to keep the chart sizes
reasonable, we condensed them to a maximum of the top 10-12 themes, with
additional themes all grouped under &ldquo;Other&rdquo;. The percentage labels shown in
charts are rounded to the nearest integer (e.g., 1.4% and 0.8% will both be
displayed as 1%), but the length of each bar and row ordering are based on the
unrounded values.</p>
<p>To help readers understand the weight of evidence underlying each finding, we
included error bars showing the 95% <a href="https://en.wikipedia.org/wiki/Confidence_interval" rel="noreferrer" target="_blank">confidence
interval</a> for responses;
narrower bars indicate increased confidence. Sometimes two or more responses
have overlapping error bars, which means the relative order of those responses
is not statistically meaningful (i.e., the responses are effectively tied).
The lower right of each chart shows the number of people whose responses are
included in the chart, in the form &ldquo;n = [number of respondents]&rdquo;. In cases
where we found interesting differences in responses between groups, (e.g.,
years of experience, organization size, or sample source) we showed a
color-coded breakdown of the differences.</p>
<h2 id="closing">Closing</h2>
<p>And that&rsquo;s it for our semi-annual Go Developer Survey. Many thanks to everyone
who shared their thoughts on Go and everyone who contributed to making this
survey happen! It means the world to us and truly helps us improve Go.</p>
<p>This year we&rsquo;re also excited to announce the forthcoming release of this survey&rsquo;s
dataset. We expect to share this anonymized data by the end of April, allowing
anyone to slice and dice survey responses as needed to answer their own
questions about the Go ecosystem.</p>
<p>Updated 2024-05-03: We unfortunately need to delay the release of this
dataset. We&rsquo;re still working to make this happen, but we don&rsquo;t expect to be
able to share it until the second half of 2024.</p>
<p>&mdash; Alice and Todd (on behalf of the Go team at Google)</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 
 
 
 
 <p>
 
 
 <b>Next article: </b><a href="/blog/randv2">Evolving the Go Standard Library with math/rand/v2</a><br>
 
 
 
 
 <b>Previous article: </b><a href="/blog/execution-traces-2024">More powerful Go execution traces</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry><entry><title>More powerful Go execution traces</title><id>tag:blog.golang.org,2013:blog.golang.org/execution-traces-2024</id><link rel="alternate" href="https://go.dev/blog/execution-traces-2024"></link><published>2024-03-14T00:00:00+00:00</published><updated>2024-03-14T00:00:00+00:00</updated><author><name></name></author><summary type="html">New features and improvements to execution traces from the last year.</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/execution-traces-2024">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>More powerful Go execution traces</h1>
 
 <p class="author">
 Michael Knyszek<br>
 14 March 2024
 </p>
 
 <p>The <a href="/pkg/runtime/trace">runtime/trace</a> package contains a powerful tool for understanding and
troubleshooting Go programs.
The functionality within allows one to produce a trace of each goroutine&rsquo;s execution over some
time period.
With the <a href="/pkg/cmd/trace"><code>go tool trace</code> command</a> (or the excellent open source
<a href="https://gotraceui.dev/" rel="noreferrer" target="_blank">gotraceui tool</a>), one may then visualize and explore the data within these
traces.</p>
<p>The magic of a trace is that it can easily reveal things about a program that are hard to see in
other ways.
For example, a concurrency bottleneck where lots of goroutines block on the same channel might be
quite difficult to see in a CPU profile, because there&rsquo;s no execution to sample.
But in an execution trace, the <em>lack</em> of execution will show up with amazing clarity, and the stack
traces of blocked goroutines will quickly point at the culprit.</p>
<div class="image">
 <img src="execution-traces-2024/gotooltrace.png" alt="">
</div>
<p>Go developers are even able to instrument their own programs with <a href="/pkg/runtime/trace#Task">tasks</a>,
<a href="/pkg/runtime/trace#WithRegion">regions</a>, and <a href="/pkg/runtime/trace#Log">logs</a> that
they can use to correlate their higher-level concerns with lower-level execution details.</p>
<h2 id="issues">Issues</h2>
<p>Unfortunately, the wealth of information in execution traces can often be out of reach.
Four big issues with traces have historically gotten in the way.</p>
<ul>
<li>Traces had high overheads.</li>
<li>Traces didn&rsquo;t scale well, and could become too big to analyze.</li>
<li>It was often unclear when to start tracing to capture a specific bad behavior.</li>
<li>Only the most adventurous gophers could programmatically analyze traces, given the lack of a
public package for parsing and interpreting execution traces.</li>
</ul>
<p>If you&rsquo;ve used traces in the last few years, you&rsquo;ve likely been frustrated by one or more of these
problems.
But we&rsquo;re excited to share that over the last two Go releases we&rsquo;ve made big progress in all four
of these areas.</p>
<h2 id="low-overhead-tracing">Low-overhead tracing</h2>
<p>Prior to Go 1.21, the run-time overhead of tracing was somewhere between 10–20% CPU for many
applications, which limits tracing to situational usage, rather than continuous usage like CPU
profiling.
It turned out that much of the cost of tracing came down to tracebacks.
Many events produced by the runtime have stack traces attached, which are invaluable to actually
identifying what goroutines were doing at key moments in their execution.</p>
<p>Thanks to work by Felix Geisendörfer and Nick Ripley on optimizing the efficiency of tracebacks,
the run-time CPU overhead of execution traces has been cut dramatically, down to 1–2% for many
applications.
You can read more about the work done here in <a href="https://blog.felixge.de/reducing-gos-execution-tracer-overhead-with-frame-pointer-unwinding/" rel="noreferrer" target="_blank">Felix&rsquo;s great blog
post</a>
on the topic.</p>
<h2 id="scalable-traces">Scalable traces</h2>
<p>The trace format and its events were designed around relatively efficient emission, but required
tooling to parse and keep around the state of the entirety of a trace.
A few hundred MiB trace could require several GiB of RAM to analyze!</p>
<p>This issue is unfortunately fundamental to how traces are generated.
To keep run-time overheads low, all events are written to the equivalent of thread-local buffers.
But this means events appear out of their true order, and the burden is placed on the trace
tooling to figure out what really happened.</p>
<p>The key insight to making traces scale while keeping overheads low was to occasionally split the
trace being generated.
Each split point would behave a bit like simultaneously disabling and reenabling tracing in one
go.
All the trace data so far would represent a complete and self-contained trace, while the new trace
data would seamlessly pick up from where it left off.</p>
<p>As you might imagine, fixing this required <a href="/issue/60773">rethinking and rewriting a lot of the foundation of
the trace implementation</a> in the runtime.
We&rsquo;re happy to say that the work landed in Go 1.22 and is now generally available.
<a href="/doc/go1.22#runtime/trace">A lot of nice improvements</a> came with the rewrite, including some
improvements to the <a href="/doc/go1.22#trace"><code>go tool trace</code> command</a> as well.
The gritty details are all in the <a href="https://github.com/golang/proposal/blob/master/design/60773-execution-tracer-overhaul.md" rel="noreferrer" target="_blank">design
document</a>,
if you&rsquo;re curious.</p>
<p>(Note: <code>go tool trace</code> still loads the full trace into memory, but <a href="/issue/65315">removing this
limitation</a> for traces produced by Go 1.22+ programs is now feasible.)</p>
<h2 id="flight-recording">Flight recording</h2>
<p>Suppose you work on a web service and an RPC took a very long time.
You couldn&rsquo;t start tracing at the point you knew the RPC was already taking a while, because the
root cause of the slow request already happened and wasn&rsquo;t recorded.</p>
<p>There&rsquo;s a technique that can help with this called flight recording, which you may already be
familiar with from other programming environments.
The insight with flight recording is to have tracing on continuously and always keep the most
recent trace data around, just in case.
Then, once something interesting happens, the program can just write out whatever it has!</p>
<p>Before traces could be split, this was pretty much a non-starter.
But because continuous tracing is now viable thanks to low overheads, and the fact that the runtime
can now split traces any time it needs, it turns out it was straightforward to implement flight
recording.</p>
<p>As a result, we&rsquo;re happy to announce a flight recorder experiment, available in the
<a href="/pkg/golang.org/x/exp/trace#FlightRecorder">golang.org/x/exp/trace package</a>.</p>
<p>Please try it out!
Below is an example that sets up flight recording to capture a long HTTP request to get you started.</p>
<div class="code">
<pre> <span class="comment">// Set up the flight recorder.</span>
 fr := trace.NewFlightRecorder()
 fr.Start()

 <span class="comment">// Set up and run an HTTP server.</span>
 var once sync.Once
 http.HandleFunc(&#34;/my-endpoint&#34;, func(w http.ResponseWriter, r *http.Request) {
 start := time.Now()

 <span class="comment">// Do the work...</span>
 doWork(w, r)

 <span class="comment">// We saw a long request. Take a snapshot!</span>
 if time.Since(start) &gt; 300*time.Millisecond {
 <span class="comment">// Do it only once for simplicity, but you can take more than one.</span>
 once.Do(func() {
 <span class="comment">// Grab the snapshot.</span>
 var b bytes.Buffer
 _, err = fr.WriteTo(&amp;b)
 if err != nil {
 log.Print(err)
 return
 }
 <span class="comment">// Write it to a file.</span>
 if err := os.WriteFile(&#34;trace.out&#34;, b.Bytes(), 0o755); err != nil {
 log.Print(err)
 return
 }
 })
 }
 })
 log.Fatal(http.ListenAndServe(&#34;:8080&#34;, nil))
</pre>
</div>
<p>If you have any feedback, positive or negative, please share it to the <a href="/issue/63185">proposal
issue</a>!</p>
<h2 id="trace-reader-api">Trace reader API</h2>
<p>Along with the trace implementation rewrite came an effort to clean up the other trace internals,
like <code>go tool trace</code>.
This spawned an attempt to create a trace reader API that was good enough to share and that could
make traces more accessible.</p>
<p>Just like the flight recorder, we&rsquo;re happy to announce that we also have an experimental trace reader
API that we&rsquo;d like to share.
It&rsquo;s available in the <a href="/pkg/golang.org/x/exp/trace#Reader">same package as the flight recorder,
golang.org/x/exp/trace</a>.</p>
<p>We think it&rsquo;s good enough to start building things on top of, so please try it out!
Below is an example that measures the proportion of goroutine block events that blocked to wait on
the network.</p>
<div class="code">
<pre> <span class="comment">// Start reading from STDIN.</span>
 r, err := trace.NewReader(os.Stdin)
 if err != nil {
 log.Fatal(err)
 }

 var blocked int
 var blockedOnNetwork int
 for {
 <span class="comment">// Read the event.</span>
 ev, err := r.ReadEvent()
 if err == io.EOF {
 break
 } else if err != nil {
 log.Fatal(err)
 }

 <span class="comment">// Process it.</span>
 if ev.Kind() == trace.EventStateTransition {
 st := ev.StateTransition()
 if st.Resource.Kind == trace.ResourceGoroutine {
 from, to := st.Goroutine()

 <span class="comment">// Look for goroutines blocking, and count them.</span>
 if from.Executing() &amp;&amp; to == trace.GoWaiting {
 blocked++
 if strings.Contains(st.Reason, &#34;network&#34;) {
 blockedOnNetwork++
 }
 }
 }
 }
 }
 <span class="comment">// Print what we found.</span>
 p := 100 * float64(blockedOnNetwork) / float64(blocked)
 fmt.Printf(&#34;%2.3f%% instances of goroutines blocking were to block on the network\n&#34;, p)
</pre>
</div>
<p>And just like the flight recorder, there&rsquo;s a <a href="/issue/62627">proposal issue</a> that would
be a great place to leave feedback!</p>
<p>We&rsquo;d like to quickly call out Dominik Honnef as someone who tried it out early, provided great
feedback, and has contributed support for older trace versions to the API.</p>
<h2 id="thank-you">Thank you!</h2>
<p>This work was completed, in no small part, thanks to the help of the those in the <a href="/issue/57175">diagnostics
working group</a>, started over a year ago as a collaboration between stakeholders from
across the Go community, and open to the public.</p>
<p>We&rsquo;d like to take a moment to thank those community members who have attended the diagnostic
meetings regularly over the last year: Felix Geisendörfer, Nick Ripley, Rhys Hiltner, Dominik
Honnef, Bryan Boreham, thepudds.</p>
<p>The discussions, feedback, and work you all put in have been instrumental to getting us to where we
are today.
Thank you!</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 
 
 
 
 
 
 <p>
 
 
 <b>Next article: </b><a href="/blog/survey2024-h1-results">Go Developer Survey 2024 H1 Results</a><br>
 
 
 
 
 <b>Previous article: </b><a href="/blog/generic-slice-functions">Robust generic functions on slices</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry><entry><title>Robust generic functions on slices</title><id>tag:blog.golang.org,2013:blog.golang.org/generic-slice-functions</id><link rel="alternate" href="https://go.dev/blog/generic-slice-functions"></link><published>2024-02-22T00:00:00+00:00</published><updated>2024-02-22T00:00:00+00:00</updated><author><name></name></author><summary type="html">Avoiding memory leaks in the slices package.</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/generic-slice-functions">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>Robust generic functions on slices</h1>
 
 <p class="author">
 Valentin Deleplace<br>
 22 February 2024
 </p>
 
 <p>The <a href="/pkg/slices">slices</a> package provides functions that work for slices of any type.
In this blog post we&rsquo;ll discuss how you can use these functions more effectively by understanding how slices are represented in memory and how that affects the garbage collector, and we&rsquo;ll cover how we recently adjusted these functions to make them less surprising.</p>
<p>With <a href="/blog/deconstructing-type-parameters">Type parameters</a> we can write functions like <a href="/pkg/slices#Index">slices.Index</a> once for all types of slices of comparable elements:</p>
<pre><code>// Index returns the index of the first occurrence of v in s,
// or -1 if not present.
func Index[S ~[]E, E comparable](s S, v E) int {
 for i := range s {
 if v == s[i] {
 return i
 }
 }
 return -1
}
</code></pre>
<p>It is no longer necessary to implement <code>Index</code> again for each different type of element.</p>
<p>The <a href="/pkg/slices">slices</a> package contains many such helpers to perform common operations on slices:</p>
<pre><code> s := []string{&quot;Bat&quot;, &quot;Fox&quot;, &quot;Owl&quot;, &quot;Fox&quot;}
 s2 := slices.Clone(s)
 slices.Sort(s2)
 fmt.Println(s2) // [Bat Fox Fox Owl]
 s2 = slices.Compact(s2)
 fmt.Println(s2) // [Bat Fox Owl]
 fmt.Println(slices.Equal(s, s2)) // false
</code></pre>
<p>Several new functions (<code>Insert</code>, <code>Replace</code>, <code>Delete</code>, etc.) modify the slice. To understand how they work, and how to properly use them, we need to examine the underlying structure of slices.</p>
<p>A slice is a view of a portion of an array. <a href="/blog/slices-intro">Internally</a>, a slice contains a pointer, a length, and a capacity. Two slices can have the same underlying array, and can view overlapping portions.</p>
<p>For example, this slice <code>s</code> is a view on 4 elements of an array of size 6:</p>
<div class="image">
 <img src="generic-slice-functions/1_sample_slice_4_6.svg" width="450" alt="">
</div>
<p>If a function changes the length of a slice passed as a parameter, then it needs to return a new slice to the caller. The underlying array may remain the same if it doesn&rsquo;t have to grow. This explains why <a href="/blog/slices">append</a> and <code>slices.Compact</code> return a value, but <code>slices.Sort</code>, which merely reorders the elements, does not.</p>
<p>Consider the task of deleting a portion of a slice. Prior to generics, the standard way to delete the portion <code>s[2:5]</code> from the slice <code>s</code> was to call the <a href="/ref/spec#Appending_and_copying_slices">append</a> function to copy the end portion over the middle portion:</p>
<pre><code>s = append(s[:2], s[5:]...)
</code></pre>
<p>The syntax was complex and error-prone, involving subslices and a variadic parameter. We added <a href="/pkg/slices#Delete">slice.Delete</a> to make it easier to delete elements:</p>
<pre><code>func Delete[S ~[]E, E any](s S, i, j int) S {
 return append(s[:i], s[j:]...)
}
</code></pre>
<p>The one-line function <code>Delete</code> more clearly expresses the programmer&rsquo;s intent. Let’s consider a slice <code>s</code> of length 6 and capacity 8, containing pointers:</p>
<div class="image">
 <img src="generic-slice-functions/2_sample_slice_6_8.svg" width="600" alt="">
</div>
<p>This call deletes the elements at <code>s[2]</code>, <code>s[3]</code>, <code>s[4]</code> from the slice <code>s</code>:</p>
<pre><code>s = slices.Delete(s, 2, 5)
</code></pre>
<div class="image">
 <img src="generic-slice-functions/3_delete_s_2_5.svg" width="600" alt="">
</div>
<p>The gap at the indices 2, 3, 4 is filled by shifting the element <code>s[5]</code> to the left, and setting the new length to <code>3</code>.</p>
<p><code>Delete</code> need not allocate a new array, as it shifts the elements in place. Like <code>append</code>, it returns a new slice. Many other functions in the <code>slices</code> package follow this pattern, including <code>Compact</code>, <code>CompactFunc</code>, <code>DeleteFunc</code>, <code>Grow</code>, <code>Insert</code>, and <code>Replace</code>.</p>
<p>When calling these functions we must consider the original slice invalid, because the underlying array has been modified. It would be a mistake to call the function but ignore the return value:</p>
<pre><code> slices.Delete(s, 2, 5) // incorrect!
 // s still has the same length, but modified contents
</code></pre>
<h2 id="a-problem-of-unwanted-liveness">A problem of unwanted liveness</h2>
<p>Before Go 1.22, <code>slices.Delete</code> didn&rsquo;t modify the elements between the new and original lengths of the slice. While the returned slice wouldn&rsquo;t include these elements, the &ldquo;gap&rdquo; created at the end of the original, now-invalidated slice continued to hold onto them. These elements could contain pointers to large objects (a 20MB image), and the garbage collector would not release the memory associated with these objects. This resulted in a memory leak that could lead to significant performance issues.</p>
<p>In this above example, we’re successfully deleting the pointers <code>p2</code>, <code>p3</code>, <code>p4</code> from <code>s[2:5]</code>, by shifting one element to the left. But <code>p3</code> and <code>p4</code> are still present in the underlying array, beyond the new length of <code>s</code>. The garbage collector won’t reclaim them. Less obviously, <code>p5</code> is not one of the deleted elements, but its memory may still leak because of the <code>p5</code> pointer kept in the gray part of the array.</p>
<p>This could be confusing for developers, if they were not aware that &ldquo;invisible&rdquo; elements were still using memory.</p>
<p>So we had two options:</p>
<ul>
<li>Either keep the efficient implementation of <code>Delete</code>. Let users set obsolete pointers to <code>nil</code> themselves, if they want to make sure the values pointed to can be freed.</li>
<li>Or change <code>Delete</code> to always set the obsolete elements to zero. This is extra work, making <code>Delete</code> slightly less efficient. Zeroing pointers (setting them to <code>nil</code>) enables the garbage collection of the objects, when they become otherwise unreachable.</li>
</ul>
<p>It was not obvious which option was best. The first one provided performance by default, and the second one provided memory frugality by default.</p>
<h2 id="the-fix">The fix</h2>
<p>A key observation is that &ldquo;setting the obsolete pointers to <code>nil</code>&rdquo; is not as easy as it seems. In fact, this task is so error-prone that we should not put the burden on the user to write it. Out of pragmatism, we chose to modify the implementation of the five functions <code>Compact</code>, <code>CompactFunc</code>, <code>Delete</code>, <code>DeleteFunc</code>, <code>Replace</code> to &ldquo;clear the tail&rdquo;. As a nice side effect, the cognitive load is reduced and users now don’t need to worry about these memory leaks.</p>
<p>In Go 1.22, this is what the memory looks like after calling Delete:</p>
<div class="image">
 <img src="generic-slice-functions/4_delete_s_2_5_nil.svg" width="600" alt="">
</div>
<p>The code changed in the five functions uses the new built-in function <a href="/pkg/builtin#clear">clear</a> (Go 1.21) to set the obsolete elements to the zero value of the element type of <code>s</code>:</p>
<div class="image">
 <img src="generic-slice-functions/5_Delete_diff.png" width="800" alt="">
</div>
<p>The zero value of <code>E</code> is <code>nil</code> when <code>E</code> is a type of pointer, slice, map, chan, or interface.</p>
<h2 id="tests-failing">Tests failing</h2>
<p>This change has led to some tests that passed in Go 1.21 now failing in Go 1.22, when the slices functions are used incorrectly. This is good news. When you have a bug, tests should let you know.</p>
<p>If you ignore the return value of <code>Delete</code>:</p>
<pre><code>slices.Delete(s, 2, 3) // !! INCORRECT !!
</code></pre>
<p>then you may incorrectly assume that <code>s</code> does not contain any nil pointer. <a href="/play/p/NDHuO8vINHv">Example in the Go Playground</a>.</p>
<p>If you ignore the return value of <code>Compact</code>:</p>
<pre><code>slices.Sort(s) // correct
slices.Compact(s) // !! INCORRECT !!
</code></pre>
<p>then you may incorrectly assume that <code>s</code> is properly sorted and compacted. <a href="/play/p/eFQIekiwlnu">Example</a>.</p>
<p>If you assign the return value of <code>Delete</code> to another variable, and keep using the original slice:</p>
<pre><code>u := slices.Delete(s, 2, 3) // !! INCORRECT, if you keep using s !!
</code></pre>
<p>then you may incorrectly assume that <code>s</code> does not contain any nil pointer. <a href="/play/p/rDxWmJpLOVO">Example</a>.</p>
<p>If you accidentally shadow the slice variable, and keep using the original slice:</p>
<pre><code>s := slices.Delete(s, 2, 3) // !! INCORRECT, using := instead of = !!
</code></pre>
<p>then you may incorrectly assume that <code>s</code> does not contain any nil pointer. <a href="/play/p/KSpVpkX8sOi">Example</a>.</p>
<h2 id="conclusion">Conclusion</h2>
<p>The API of the <code>slices</code> package is a net improvement over the traditional pre-generics syntax to delete or insert elements.</p>
<p>We encourage developers to use the new functions, while avoiding the &ldquo;gotchas&rdquo; listed above.</p>
<p>Thanks to the recent changes in the implementation, a class of memory leaks is automatically avoided, without any change to the API, and with no extra work for the developers.</p>
<h2 id="further-reading">Further reading</h2>
<p>The signature of the functions in the <code>slices</code> package is heavily influenced by the specifics of the representation of slices in memory. We recommend reading</p>
<ul>
<li><a href="/blog/slices-intro">Go Slices: usage and internals</a></li>
<li><a href="/blog/slices">Arrays, slices: The mechanics of &lsquo;append&rsquo;</a></li>
<li>The <a href="https://en.wikipedia.org/wiki/Dynamic_array" rel="noreferrer" target="_blank">dynamic array</a> data structure</li>
<li>The <a href="/pkg/slices">documentation</a> of the package slices</li>
</ul>
<p>The <a href="/issue/63393">original proposal</a> about zeroing obsolete elements contains many details and comments.</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 
 
 
 
 
 
 
 
 <p>
 
 
 <b>Next article: </b><a href="/blog/execution-traces-2024">More powerful Go execution traces</a><br>
 
 
 
 
 <b>Previous article: </b><a href="/blog/routing-enhancements">Routing Enhancements for Go 1.22</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry><entry><title>Routing Enhancements for Go 1.22</title><id>tag:blog.golang.org,2013:blog.golang.org/routing-enhancements</id><link rel="alternate" href="https://go.dev/blog/routing-enhancements"></link><published>2024-02-13T00:00:00+00:00</published><updated>2024-02-13T00:00:00+00:00</updated><author><name></name></author><summary type="html">Go 1.22&#39;s additions to patterns for HTTP routes.</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/routing-enhancements">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>Routing Enhancements for Go 1.22</h1>
 
 <p class="author">
 Jonathan Amsterdam, on behalf of the Go team<br>
 13 February 2024
 </p>
 
 <p>Go 1.22 brings two enhancements to the <code>net/http</code> package&rsquo;s router: method
matching and wildcards. These features let you express common routes as
patterns instead of Go code. Although they are simple to explain and use,
it was a challenge to come up with the right rules for selecting the winning
pattern when several match a request.</p>
<p>We made these changes as part of our continuing effort to make Go a great
language for building production systems. We studied many third-party web
frameworks, extracted what we felt were the most used features, and integrated
them into <code>net/http</code>. Then we validated our choices and improved our design by
collaborating with the community in a <a href="https://github.com/golang/go/discussions/60227" rel="noreferrer" target="_blank">GitHub discussion</a> and a <a href="/issue/61410">proposal issue</a>.
Adding these features to the standard library means one fewer dependency for
many projects. But third-party web frameworks remain a fine choice for current
users or programs with advanced routing needs.</p>
<h2 id="enhancements">Enhancements</h2>
<p>The new routing features almost exclusively affect the pattern string passed
to the two <code>net/http.ServeMux</code> methods <code>Handle</code> and <code>HandleFunc</code>, and the
corresponding top-level functions <code>http.Handle</code> and <code>http.HandleFunc</code>. The only
API changes are two new methods on <code>net/http.Request</code> for working with wildcard
matches.</p>
<p>We&rsquo;ll illustrate the changes with a hypothetical blog server in which every post
has an integer identifier. A request like <code>GET /posts/234</code> retrieves the post with
ID 234. Before Go 1.22, the code for handling those requests would start with a
line like this:</p>
<pre><code>http.HandleFunc(&quot;/posts/&quot;, handlePost)
</code></pre>
<p>The trailing slash routes all requests beginning <code>/posts/</code> to the <code>handlePost</code>
function, which would have to check that the HTTP method was GET, extract
the identifier, and retrieve the post. Since the method check isn&rsquo;t strictly
necessary to satisfy the request, it would be a natural mistake to omit it. That
would mean that a request like <code>DELETE /posts/234</code> would fetch the post, which
is surprising at the least.</p>
<p>In Go 1.22, the existing code will continue to work, or you could instead write this:</p>
<pre><code>http.HandleFunc(&quot;GET /posts/{id}&quot;, handlePost2)
</code></pre>
<p>This pattern matches a GET request whose path begins &ldquo;/posts/&rdquo; and has two
segments. (As a special case, GET also matches HEAD; all the other methods match
exactly.) The <code>handlePost2</code> function no longer needs to check the method, and
extracting the identifier string can be written using the new <code>PathValue</code> method
on <code>Request</code>:</p>
<pre><code>idString := req.PathValue(&quot;id&quot;)
</code></pre>
<p>The rest of <code>handlePost2</code> would behave like <code>handlePost</code>, converting the string
identifier to an integer and fetching the post.</p>
<p>Requests like <code>DELETE /posts/234</code> will fail if no other matching pattern is
registered. In accordance with <a href="https://httpwg.org/specs/rfc9110.html#status.405" rel="noreferrer" target="_blank">HTTP semantics</a>, a <code>net/http</code> server will reply
to such a request with a <code>405 Method Not Allowed</code> error that lists the available methods
in an <code>Allow</code> header.</p>
<p>A wildcard can match an entire segment, like <code>{id}</code> in the example above, or if
it ends in <code>...</code> it can match all the remaining segments of the path, as in the
pattern <code>/files/{pathname...}</code>.</p>
<p>There is one last bit of syntax. As we showed above, patterns ending in a slash,
like <code>/posts/</code>, match all paths beginning with that string. To match only the
path with the trailing slash, you can write <code>/posts/{$}</code>. That will match
<code>/posts/</code> but not <code>/posts</code> or <code>/posts/234</code>.</p>
<p>And there is one last bit of API: <code>net/http.Request</code> has a <code>SetPathValue</code> method
so that routers outside the standard library can make the results of their own
path parsing available via <code>Request.PathValue</code>.</p>
<h2 id="precedence">Precedence</h2>
<p>Every HTTP router must deal with overlapping patterns, like <code>/posts/{id}</code> and
<code>/posts/latest</code>. Both of these patterns match the path &ldquo;posts/latest&rdquo;, but at most
one can serve the request. Which pattern takes precedence?</p>
<p>Some routers disallow overlaps; others use the pattern that was registered last.
Go has always allowed overlaps, and has chosen the longer pattern regardless
of registration order. Preserving order-independence was important to us (and
necessary for backwards compatibility), but we needed a better rule than
&ldquo;longest wins.&rdquo; That rule would select <code>/posts/latest</code> over <code>/posts/{id}</code>, but
would choose <code>/posts/{identifier}</code> over both. That seems wrong: the wildcard
name shouldn&rsquo;t matter. It feels like <code>/posts/latest</code> should always win this
competition, because it matches a single path instead of many.</p>
<p>Our quest for a good precedence rule led us to consider many properties of
patterns. For example, we considered preferring the pattern with the longest
literal (non-wildcard) prefix. That would choose <code>/posts/latest</code> over <code>/posts/ {id}</code>. But it wouldn&rsquo;t distinguish between <code>/users/{u}/posts/latest</code> and
<code>/users/{u}/posts/{id}</code>, and it seems like the former should take precedence.</p>
<p>We eventually chose a rule based on what the patterns mean instead of how they
look. Every valid pattern matches a set of requests. For example,
<code>/posts/latest</code> matches requests with the path <code>/posts/latest</code>, while <code>/posts/{id}</code>
matches requests with any two-segment path whose first segment is &ldquo;posts&rdquo;. We
say that one pattern is <em>more specific</em> than another if it matches a strict subset
of requests. The pattern <code>/posts/latest</code> is more specific than <code>/posts/{id}</code>
because the latter matches every request that the former does, and more.</p>
<p>The precedence rule is simple: the most specific pattern wins. This rule
matches our intuition that <code>posts/latests</code> should be preferred to <code>posts/{id}</code>,
and <code>/users/{u}/posts/latest</code> should be preferred to <code>/users/{u}/posts/{id}</code>.
It also makes sense for methods. For example, <code>GET /posts/{id}</code> takes
precedence over <code>/posts/{id}</code> because the first only matches GET and HEAD
requests, while the second matches requests with any method.</p>
<p>The &ldquo;most specific wins&rdquo; rule generalizes the original &ldquo;longest wins&rdquo; rule for
the path parts of original patterns, those without wildcards or <code>{$}</code>. Such
patterns only overlap when one is a prefix of the other, and the longer is the
more specific.</p>
<p>What if two patterns overlap but neither is more specific? For example, <code>/posts/{id}</code>
and <code>/{resource}/latest</code> both match <code>/posts/latest</code>. There is no obvious answer to
which takes precedence, so we consider these patterns to conflict with each other.
Registering both of them (in either order!) will panic.</p>
<p>The precedence rule works exactly as above for methods and paths, but we had to
make one exception for hosts to preserve compatibility: if two patterns would
otherwise conflict and one has a host while the other does not, then the pattern
with the host takes precedence.</p>
<p>Students of computer science may recall the beautiful theory of regular
expressions and regular languages. Each regular expression picks out a regular
language, the set of strings matched by the expression. Some questions are
easier to pose and answer by talking about languages rather than expressions.
Our precedence rule was inspired by this theory. Indeed, each routing pattern
corresponds to a regular expression, and sets of matching requests play the role of
regular languages.</p>
<p>Defining precedence by languages instead of expressions makes it easy to state
and understand. But there is a downside to having a rule based on potentially
infinite sets: it isn&rsquo;t clear how to implement it efficiently. It turns out we
can determine whether two patterns conflict by walking them segment by segment.
Roughly speaking, if one pattern has a literal segment wherever the other has a
wildcard, it is more specific; but if literals align with wildcards in both
directions, the patterns conflict.</p>
<p>As new patterns are registered on a <code>ServeMux</code>, it checks for conflicts with previously
registered patterns. But checking every pair of patterns would take quadratic
time. We use an index to skip patterns that cannot conflict with a new pattern;
in practice, it works quite well. In any case, this check happens when
patterns are registered, usually at server startup. The time to match incoming
requests in Go 1.22 hasn&rsquo;t changed much from previous versions.</p>
<h2 id="compatibility">Compatibility</h2>
<p>We made every effort to keep the new functionality compatible with older
versions of Go. The new pattern syntax is a superset of the old, and the new
precedence rule generalizes the old one. But there are a few edge cases. For
example, previous versions of Go accepted patterns with braces and treated
them literally, but Go 1.22 uses braces for wildcards. The GODEBUG setting
<code>httpmuxgo121</code> restores the old behavior.</p>
<p>For more details about these routing enhancements, see the <a href="/pkg/net/http#ServeMux"><code>net/http.ServeMux</code>
documentation</a>.</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 
 
 
 
 
 
 
 
 
 
 <p>
 
 
 <b>Next article: </b><a href="/blog/generic-slice-functions">Robust generic functions on slices</a><br>
 
 
 
 
 <b>Previous article: </b><a href="/blog/go1.22">Go 1.22 is released!</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry><entry><title>Go 1.22 is released!</title><id>tag:blog.golang.org,2013:blog.golang.org/go1.22</id><link rel="alternate" href="https://go.dev/blog/go1.22"></link><published>2024-02-06T00:00:00+00:00</published><updated>2024-02-06T00:00:00+00:00</updated><author><name></name></author><summary type="html">Go 1.22 enhances for loops, brings new standard library functionality and improves performance.</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/go1.22">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>Go 1.22 is released!</h1>
 
 <p class="author">
 Eli Bendersky, on behalf of the Go team<br>
 6 February 2024
 </p>
 
 <p>Today the Go team is thrilled to release Go 1.22,
which you can get by visiting the <a href="/dl/">download page</a>.</p>
<p>Go 1.22 comes with several important new features and improvements. Here are
some of the notable changes; for the full list, refer to the <a href="/doc/go1.22">release
notes</a>.</p>
<h2 id="language-changes">Language changes</h2>
<p>The long-standing &ldquo;for&rdquo; loop gotcha with accidental sharing of loop variables
between iterations is now resolved. Starting with Go 1.22, the following code
will print &ldquo;a&rdquo;, &ldquo;b&rdquo;, and &ldquo;c&rdquo; in some order:</p>
<pre><code>func main() {
 done := make(chan bool)

 values := []string{&quot;a&quot;, &quot;b&quot;, &quot;c&quot;}
 for _, v := range values {
 go func() {
 fmt.Println(v)
 done &lt;- true
 }()
 }

 // wait for all goroutines to complete before exiting
 for _ = range values {
 &lt;-done
 }
}
</code></pre>
<p>For more information about this change and the tooling that helps keep code from
breaking accidentally, see the earlier <a href="/blog/loopvar-preview">loop variable blog
post</a>.</p>
<p>The second language change is support for ranging over integers:</p>
<pre><code>package main

import &quot;fmt&quot;

func main() {
 for i := range 10 {
 fmt.Println(10 - i)
 }
 fmt.Println(&quot;go1.22 has lift-off!&quot;)
}
</code></pre>
<p>The values of <code>i</code> in this countdown program go from 0 to 9, inclusive. For more
details, please refer to <a href="/ref/spec#For_range">the spec</a>.</p>
<h2 id="improved-performance">Improved performance</h2>
<p>Memory optimization in the Go runtime improves CPU performance by 1-3%, while
also reducing the memory overhead of most Go programs by around 1%.</p>
<p>In Go 1.21, <a href="/blog/pgo">we shipped</a> profile-guided optimization (PGO) for the Go
compiler and this functionality continues to improve. One of the optimizations
added in 1.22 is improved devirtualization, allowing static dispatch of more
interface method calls. Most programs will see improvements between 2-14% with
PGO enabled.</p>
<h2 id="standard-library-additions">Standard library additions</h2>
<ul>
<li>
<p>A new <a href="/pkg/math/rand/v2">math/rand/v2</a> package
provides a cleaner, more consistent API and uses higher-quality,
faster pseudo-random generation algorithms. See
<a href="/issue/61716">the proposal</a> for additional details.</p>
</li>
<li>
<p>The patterns used by <a href="/pkg/net/http#ServeMux">net/http.ServeMux</a>
now accept methods and wildcards.</p>
<p>For example, the router accepts a pattern like <code>GET /task/{id}/</code>, which
matches only <code>GET</code> requests and captures the value of the <code>{id}</code> segment
in a map that can be accessed through <a href="/pkg/net/http#Request">Request</a> values.</p>
</li>
<li>
<p>A new <code>Null[T]</code> type in <a href="/pkg/database/sql">database/sql</a> provides
a way to scan nullable columns.</p>
</li>
<li>
<p>A <code>Concat</code> function was added in package <a href="/pkg/slices">slices</a>, to
concatenate multiple slices of any type.</p>
</li>
</ul>
<hr>
<p>Thanks to everyone who contributed to this release by writing code and
documentation, filing bugs, sharing feedback, and testing the release
candidates. Your efforts helped to ensure that Go 1.22 is as stable as possible.
As always, if you notice any problems, please <a href="/issue/new">file an issue</a>.</p>
<p>Enjoy Go 1.22!</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 <p>
 
 
 <b>Next article: </b><a href="/blog/routing-enhancements">Routing Enhancements for Go 1.22</a><br>
 
 
 
 
 <b>Previous article: </b><a href="/blog/survey2024-h1">Share your feedback about developing with Go</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry><entry><title>Share your feedback about developing with Go</title><id>tag:blog.golang.org,2013:blog.golang.org/survey2024-h1</id><link rel="alternate" href="https://go.dev/blog/survey2024-h1"></link><published>2024-01-23T00:00:00+00:00</published><updated>2024-01-23T00:00:00+00:00</updated><author><name></name></author><summary type="html">Help shape the future of Go by sharing your thoughts via the Go Developer Survey</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/survey2024-h1">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>Share your feedback about developing with Go</h1>
 
 <p class="author">
 Alice Merrick, for the Go team<br>
 23 January 2024
 </p>
 
 <p>Happy New Year! <a href="https://google.qualtrics.com/jfe/form/SV_083SVAUCji98YeO?s=b" rel="noreferrer" target="_blank">The Go Developer Survey is now
open</a>, and we want
to hear from you!</p>
<p>Since 2016, the insights from our Go Developer Surveys have helped us identify
key usage patterns, understand developer challenges, discover tooling
preferences, and track emerging trends within the community. Your feedback is
essential in shaping the future of Go, so please take 10–15 minutes to complete
the survey by February 11, 2024. <a href="https://google.qualtrics.com/jfe/form/SV_083SVAUCji98YeO?s=b" rel="noreferrer" target="_blank">Take the survey
now!</a></p>
<p>The more developers who participate, the better we&rsquo;ll be able to understand the
needs of the Go community. You can help spread the word by sharing this survey
on your social media channels, with your co-workers, and in any other relevant
communities.</p>
<p>Thank you for your time and feedback!</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 <p>
 
 
 <b>Next article: </b><a href="/blog/go1.22">Go 1.22 is released!</a><br>
 
 
 
 
 <b>Previous article: </b><a href="/blog/deadcode">Finding unreachable functions with deadcode</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry><entry><title>Finding unreachable functions with deadcode</title><id>tag:blog.golang.org,2013:blog.golang.org/deadcode</id><link rel="alternate" href="https://go.dev/blog/deadcode"></link><published>2023-12-12T00:00:00+00:00</published><updated>2023-12-12T00:00:00+00:00</updated><author><name></name></author><summary type="html">deadcode is a new command to help identify functions that cannot be called.</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/deadcode">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>Finding unreachable functions with deadcode</h1>
 
 <p class="author">
 Alan Donovan<br>
 12 December 2023
 </p>
 
 <p>Functions that are part of your project&rsquo;s source code but can never be
reached in any execution are called &ldquo;dead code&rdquo;, and they exert a drag
on codebase maintenance efforts.
Today we&rsquo;re pleased to share a tool named <code>deadcode</code> to help you identify them.</p>
<pre><code>$ go install golang.org/x/tools/cmd/deadcode@latest
$ deadcode -help
The deadcode command reports unreachable functions in Go programs.

Usage: deadcode [flags] package...
</code></pre>
<h2 id="example">Example</h2>
<p>Over the last year or so, we&rsquo;ve been making a lot of changes to the
structure of <a href="/blog/gopls-scalability">gopls</a>, the
language server for Go that powers VS Code and other editors.
A typical change might rewrite some existing function, taking care to
ensure that its new behavior satisfies the needs of all existing callers.
Sometimes, after putting in all that effort, we would discover to our
frustration that one of the callers was never actually reached in any
execution, so it could safely have been been deleted.
If we had known this beforehand our refactoring task would have been
easier.</p>
<p>The simple Go program below illustrates the problem:</p>
<pre><code>module example.com/greet
go 1.21
</code></pre>
<pre><code>package main

import &quot;fmt&quot;

func main() {
 var g Greeter
 g = Helloer{}
 g.Greet()
}

type Greeter interface{ Greet() }

type Helloer struct{}
type Goodbyer struct{}

var _ Greeter = Helloer{} // Helloer implements Greeter
var _ Greeter = Goodbyer{} // Goodbyer implements Greeter

func (Helloer) Greet() { hello() }
func (Goodbyer) Greet() { goodbye() }

func hello() { fmt.Println(&quot;hello&quot;) }
func goodbye() { fmt.Println(&quot;goodbye&quot;) }
</code></pre>
<p>When we execute it, it says hello:</p>
<pre><code>$ go run .
hello
</code></pre>
<p>It&rsquo;s clear from its output that this program executes the <code>hello</code>
function but not the <code>goodbye</code> function.
What&rsquo;s less clear at a glance is that the <code>goodbye</code> function can
never be called.
However, we can&rsquo;t simply delete <code>goodbye</code>, because it&rsquo;s required by the
<code>Goodbyer.Greet</code> method, which in turn is required to implement the
<code>Greeter</code> interface whose <code>Greet</code> method we can see is called from <code>main</code>.
But if we work forwards from main, we can see that no <code>Goodbyer</code> values
are ever created, so the <code>Greet</code> call in <code>main</code> can only reach <code>Helloer.Greet</code>.
That&rsquo;s the idea behind the algorithm used by the <code>deadcode</code> tool.</p>
<p>When we run deadcode on this program, the tool tells us that the
<code>goodbye</code> function and the <code>Goodbyer.Greet</code> method are both unreachable:</p>
<pre><code>$ deadcode .
greet.go:23: unreachable func: goodbye
greet.go:20: unreachable func: Goodbyer.Greet
</code></pre>
<p>With this knowledge, we can safely remove both functions,
along with the <code>Goodbyer</code> type itself.</p>
<p>The tool can also explain why the <code>hello</code> function is live. It responds
with a chain of function calls that reaches <code>hello</code>, starting from main:</p>
<pre><code>$ deadcode -whylive=example.com/greet.hello .
 example.com/greet.main
dynamic@L0008 --&gt; example.com/greet.Helloer.Greet
 static@L0019 --&gt; example.com/greet.hello
</code></pre>
<p>The output is designed to be easy to read on a terminal, but you can
use the <code>-json</code> or <code>-f=template</code> flags to specify richer output formats for
consumption by other tools.</p>
<h2 id="how-it-works">How it works</h2>
<p>The <code>deadcode</code> command
<a href="https://pkg.go.dev/golang.org/x/tools/go/packages" rel="noreferrer" target="_blank">loads</a>,
<a href="https://pkg.go.dev/go/parser" rel="noreferrer" target="_blank">parses</a>,
and <a href="https://pkg.go.dev/go/types" rel="noreferrer" target="_blank">type-checks</a> the specified packages,
then converts them into an
<a href="https://pkg.go.dev/golang.org/x/tools/go/ssa" rel="noreferrer" target="_blank">intermediate representation</a>
similar to a typical compiler.</p>
<p>It then uses an algorithm called
<a href="https://pkg.go.dev/golang.org/x/tools/go/callgraph/rta" rel="noreferrer" target="_blank">Rapid Type Analysis</a> (RTA)
to build up the set of functions that are reachable,
which is initially just the entry points of each <code>main</code> package:
the <code>main</code> function,
and the package initializer function,
which assigns global variables and calls functions named <code>init</code>.</p>
<p>RTA looks at the statements in the body of each reachable function to
gather three kinds of information: the set of functions it calls directly;
the set of dynamic calls it makes through interface methods;
and the set of types it converts to an interface.</p>
<p>Direct function calls are easy: we just add the callee to the set of
reachable functions, and if it&rsquo;s the first time we&rsquo;ve encountered the
callee, we inspect its function body the same way we did for main.</p>
<p>Dynamic calls through interface methods are trickier, because we don&rsquo;t
know the set of types that implement the interface. We don&rsquo;t want
to assume that every possible method in the program whose type matches
is a possible target for the call, because some of those types may
be instantiated only from dead code! That&rsquo;s why we gather the set of
types converted to interfaces: the conversion makes each of these
types reachable from <code>main</code>, so that its methods are now possible
targets of dynamic calls.</p>
<p>This leads to a chicken-and-egg situation. As we encounter each new
reachable function, we discover more interface method calls and more
conversions of concrete types to interface types.
But as the cross product of these two sets (interface method calls ×
concrete types) grows ever larger, we discover new reachable
functions.
This class of problems, called &ldquo;dynamic programming&rdquo;, can be solved by
(conceptually) making checkmarks in a large two-dimensional table,
adding rows and columns as we go, until there are no more checks to
add. The checkmarks in the final table tells us what is reachable;
the blank cells are the dead code.</p>
<div class="image">
<center>
 <img src="deadcode-rta.svg" alt="illustration of Rapid Type Analysis"/><br/> <i>
 The <code>main</code> function causes <code>Helloer</code> to be
 instantiated, and the <code>g.Greet</code> call<br/>
 dispatches to the <code>Greet</code> method of each type instantiated so far.
 </i>
</center>
</div>
<p>Dynamic calls to (non-method) functions are treated similar to
interfaces of a single method.
And calls made <a href="https://pkg.go.dev/reflect#Value.Call" rel="noreferrer" target="_blank">using reflection</a>
are considered to reach any method of any type used in an interface
conversion, or any type derivable from one using the <code>reflect</code> package.
But the principle is the same in all cases.</p>
<h2 id="tests">Tests</h2>
<p>RTA is a whole-program analysis. That means it always starts from a
main function and works forward: you can&rsquo;t start from a library
package such as <code>encoding/json</code>.</p>
<p>However, most library packages have tests, and tests have main
functions. We don&rsquo;t see them because they are generated behind the
scenes of <code>go test</code>, but we can include them in the analysis using the
<code>-test</code> flag.</p>
<p>If this reports that a function in a library package is dead, that&rsquo;s
a sign that your test coverage could be improved.
For example, this command lists all the functions in <code>encoding/json</code>
that are not reached by any of its tests:</p>
<pre><code>$ deadcode -test -filter=encoding/json encoding/json
encoding/json/decode.go:150:31: unreachable func: UnmarshalFieldError.Error
encoding/json/encode.go:225:28: unreachable func: InvalidUTF8Error.Error
</code></pre>
<p>(The <code>-filter</code> flag restricts the output to packages matching the
regular expression. By default, the tool reports all packages in the
initial module.)</p>
<h2 id="soundness">Soundness</h2>
<p>All static analysis tools
<a href="https://en.wikipedia.org/wiki/Rice%27s_theorem" rel="noreferrer" target="_blank">necessarily</a>
produce imperfect approximations of the possible dynamic
behaviors of the target program.
A tool&rsquo;s assumptions and inferences may be &ldquo;sound&rdquo;, meaning
conservative but perhaps overly cautious, or &ldquo;unsound&rdquo;, meaning
optimistic but not always correct.</p>
<p>The deadcode tool is no exception: it must approximate the set of
targets of dynamic calls through function and interface values or
using reflection.
In this respect, the tool is sound. In other words, if it reports a
function as dead code, it means the function cannot be called even
through these dynamic mechanisms. However the tool may fail to report
some functions that in fact can never be executed.</p>
<p>The deadcode tool must also approximate the set of calls made from
functions not written in Go, which it cannot see.
In this respect, the tool is not sound.
Its analysis is not aware of functions called exclusively from
assembly code, or of the aliasing of functions that arises from
the <a href="https://pkg.go.dev/cmd/compile#hdr-Compiler_Directives" rel="noreferrer" target="_blank"><code>go:linkname</code> directive</a>.
Fortunately both of these features are rarely used outside the Go runtime.</p>
<h2 id="try-it-out">Try it out</h2>
<p>We run <code>deadcode</code> periodically on our projects, especially after
refactoring work, to help identify parts of the program that are no
longer needed.</p>
<p>With the dead code laid to rest, you can focus on eliminating code
whose time has come to an end but that stubbornly remains alive,
continuing to drain your life force. We call such undead functions
&ldquo;vampire code&rdquo;!</p>
<p>Please try it out:</p>
<pre><code>$ go install golang.org/x/tools/cmd/deadcode@latest
</code></pre>
<p>We&rsquo;ve found it useful, and we hope you do too.</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 <p>
 
 
 <b>Next article: </b><a href="/blog/survey2024-h1">Share your feedback about developing with Go</a><br>
 
 
 
 
 <b>Previous article: </b><a href="/blog/survey2023-h2-results">Go Developer Survey 2023 H2 Results</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry><entry><title>Go Developer Survey 2023 H2 Results</title><id>tag:blog.golang.org,2013:blog.golang.org/survey2023-h2-results</id><link rel="alternate" href="https://go.dev/blog/survey2023-h2-results"></link><published>2023-12-05T00:00:00+00:00</published><updated>2023-12-05T00:00:00+00:00</updated><author><name></name></author><summary type="html">What we learned from our 2023 H2 developer survey</summary><content type="html">
<div id="blog"><div id="content">
 <div id="content">

 <div class="Article" data-slug="/blog/survey2023-h2-results">
 
 <h1 class="small"><a href="/blog/">The Go Blog</a></h1>
 

 <h1>Go Developer Survey 2023 H2 Results</h1>
 
 <p class="author">
 Todd Kulesza<br>
 5 December 2023
 </p>
 
 <style type="text/css" scoped>
 .chart {
 margin-left: 1.5rem;
 margin-right: 1.5rem;
 width: 800px;
 }
 blockquote p {
 color: var(--color-text-subtle) !important;
 }

 .quote_source {
 font-style: italic;
 }

 @media (prefers-color-scheme: dark) {
 .chart {
 border-radius: 8px;
 }
 }
</style>
<h2 id="background">Background</h2>
<p>In August 2023, the Go team at Google conducted our bi-annual survey of Go
developers. We recruited participants via a public post on the Go blog and a
randomized prompt in VS Code, resulting in 4,005 responses. We primarily
focused survey questions around a few topics: general sentiment and feedback
about developing with Go, technology stacks used alongside Go, how developers
start new Go projects, recent experiences with toolchain error messages, and
understanding developer interest around ML/AI.</p>
<p>Thank you to everyone who participated in this survey! This report shares what
we learned from your feedback.</p>
<h2 id="tldr">tl;dr</h2>
<ol>
<li>Go developers said they are <strong>more interested in AI/ML tooling that
improves the quality, reliability, and performance of code they write</strong>,
rather than writing code for them. An always-awake, never-busy expert
&ldquo;reviewer&rdquo; might be one of the more helpful forms of AI developer
assistance.</li>
<li>The top requests for improving toolchain warnings and errors were to <strong>make
the messages more comprehensible and actionable</strong>; this sentiment was
shared by developers of all experience levels, but was particularly strong
among newer Go developers.</li>
<li>Our experiment with project templates (<code>gonew</code>) appears to solve critical
problems for Go developers (especially developers new to Go) and does so in
a way that matches their existing workflows for starting a new project.
Based on these findings, we believe <strong><code>gonew</code> can substantially reduce
onboarding barriers for new Go developers and ease adoption of Go in
organizations</strong>.</li>
<li>Three out of every four respondents work on Go software that also uses
cloud services; this is evidence that <strong>developers see Go as a language for
modern, cloud-based development</strong>.</li>
<li><strong>Developer sentiment towards Go remains extremely positive</strong>, with 90% of
survey respondents saying they felt satisfied while working with Go during
the prior year.</li>
</ol>
<h2 id="contents">Contents</h2>
<ul>
<li><a href="#sentiment">Developer sentiment</a></li>
<li><a href="#devenv">Developer environments</a></li>
<li><a href="#stacks">Tech stacks</a></li>
<li><a href="#gonew">How developers start new Go projects</a></li>
<li><a href="#err_handling">Developer goals for error handling</a></li>
<li><a href="#mlai">Understanding ML/AI use cases</a></li>
<li><a href="#err_msgs">Toolchain error messages</a></li>
<li><a href="#microservices">Microservices</a></li>
<li><a href="#modules">Module authorship and maintenance</a></li>
<li><a href="#demographics">Demographics</a></li>
<li><a href="#firmographics">Firmographics</a></li>
<li><a href="#methodology">Methodology</a></li>
<li><a href="#closing">Closing</a></li>
</ul>
<h2 id="sentiment">Developer sentiment</h2>
<p>Go developers continue to report high levels of satisfaction with the Go
ecosystem. A large majority of respondents said they felt satisfied while
working with Go over the past year (90% satisfied, 6% dissatisfied), and a
majority (52%) went further and said they were &ldquo;very satisfied&rdquo;, the highest
rating. Longtime readers have likely noticed that this number doesn&rsquo;t change
much from year to year. This is expected for a large, stable project like Go;
we view this metric as a <a href="https://en.wikipedia.org/wiki/Economic_indicator#Lagging_indicators" rel="noreferrer" target="_blank">lagging
indicator</a>
that can help confirm widespread issues in the Go ecosystem, but isn&rsquo;t where
we expect to first learn about potential problems.</p>
<p>We typically find that the longer someone has worked with Go, the more likely
they are to report being satisfied with it. This trend continued in 2023;
among respondents with less than one year of Go experience, 82% reported
satisfaction with the Go development experience, compared to the 94% of Go
developers with five or more years of experience. There are likely a mix of
factors contributing to this, such as some respondents developing an
appreciation for Go&rsquo;s design choices over time, or deciding Go isn&rsquo;t a good
fit for their work and so not returning to this survey in following years
(i.e., <a href="https://en.wikipedia.org/wiki/Survivorship_bias" rel="noreferrer" target="_blank">survivorship bias</a>).
Still, this data helps us quantify the current getting started experience for
Go developers, and it seems clear we could do more to help emerging Gophers
find their footing and enjoy early successes developing with Go.</p>
<p>The key takeaway is that a large majority of people who chose to work with Go
during the past year were happy with their experience. Further, the number of
people working with Go continues to increase; we see evidence of this from
external research like <a href="https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof" rel="noreferrer" target="_blank">Stack Overflow&rsquo;s Developer
Survey</a>
(which found 14% of professional developers worked with Go during the past
year, a roughly 15% year-over-year increase), as well as analytics for
<a href="/">go.dev</a> (which show an 8% rise in visitors year-over-year).
Combining this growth with a high satisfaction score is evidence that Go
continues to appeal to developers, and suggests that many developers who
choose to learn the language feel good about their decision long afterwards.
In their own words:</p>
<blockquote>
<p>&ldquo;After 30+ years of development in C, C++, Java, and now seven years of
programming in Go, it is still the most productive language by far. It&rsquo;s not
perfect (no language is), but it has the best balance of productivity,
complexity, and performance.&rdquo; <span class="quote_source">&mdash; Professional Go
developer w/ 5 &ndash; 9 years of experience</span></p>
</blockquote>
<blockquote>
<p>&ldquo;This is currently the best language I know, and I&rsquo;ve tried many. The
tooling is awesome, compile times are great, and I can be really productive.
I&rsquo;m glad I have Go as a tool, and I don&rsquo;t need to use TypeScript
server-side. Thanks.&rdquo; <span class="quote_source">&mdash; Open source Go
developer w/ 3 &ndash; 4 years of experience</span></p>
</blockquote>
<p><img src="survey2023h2/csat.svg" alt="Chart of developer satisfaction with Go"
class="chart" /></p>
<h2 id="devenv">Developer environments</h2>
<p>As in prior years, the majority of survey respondents told us they work with
Go on Linux (63%) and macOS (58%) systems. Small variations in these numbers
from year to year are most likely dependent upon who finds and responds to
this survey (particularly on the Go blog), as we don&rsquo;t see consistent
year-over-year trends in the random sample coming from VS Code.</p>
<p>We do continue to see that newer members of the Go community are more likely
to be working with Windows than more experienced Go developers. We interpret
this as a signal that Windows-based development is important for onboarding
new developers to the Go ecosystem, and is a topic our team hopes to focus on
more in 2024.</p>
<p><img src="survey2023h2/os_dev.svg" alt="Chart of operating systems respondents
use when developing Go software" class="chart" /> <img
src="survey2023h2/os_dev_exp.svg" alt="Chart of operating systems respondents
use when developing Go software, split by duration of experience"
class="chart" /></p>
<p>Respondents continue to be heavily focused on Linux deployments. Given the
prevalence of Go for cloud development and containerized workloads, this is
not surprising but is still an important confirmation. We found few meaningful
differences based on factors such as organization size or experience level;
indeed, while novice Go developers appear more likely to <em>develop</em> on Windows,
92% still <em>deploy</em> to Linux systems. Perhaps the most interesting finding from
this breakdown is that more experienced Go developers said they deploy to a
wider variety of systems (most notably WebAssembly and IoT), though it&rsquo;s
unclear if this is because such deployments are challenging for newer Go
developers or the result of experienced Go developers using Go in a broader
range of contexts. We also observed that both IoT and WebAssembly have
steadily increased in recent years, with each rising from 3% in 2021 to 6% and
5% in 2023, respectively.</p>
<p><img src="survey2023h2/os_deploy.svg" alt="Chart of platforms respondents
deploy Go software to" class="chart" /></p>
<p>The computing architecture landscape has changed over the past few years, and
we see that reflected in the current architectures Go developers say they work
with. While x86-compatible systems still account for the majority of
development (89%), ARM64 is also now used by a majority of respondents (56%).
This adoption appears to be partly driven by Apple Silicon; macOS developers
are now more likely to say they develop for ARM64 than for x86-based
architectures (76% vs. 71%). However, Apple hardware isn&rsquo;t the only factor
driving ARM64 adoption: among respondents who don&rsquo;t develop on macOS at all,
29% still say they develop for ARM64.</p>
<p><img src="survey2023h2/arch.svg" alt="Chart of architectures respondents use
with Go" class="chart" /></p>
<p>The most common code editors among Go Developer Survey respondents continue to
be <a href="https://code.visualstudio.com/" rel="noreferrer" target="_blank">VS Code</a> (44%) and
<a href="https://www.jetbrains.com/go/" rel="noreferrer" target="_blank">GoLand</a> (31%). Both of these proportions
ticked down slightly from 2023 H1 (46% and 33%, respectively), but remain
within this survey&rsquo;s margin of error. Among the &ldquo;Other&rdquo; category,
<a href="https://helix-editor.com/" rel="noreferrer" target="_blank">Helix</a> accounted for the majority of responses.
Similar to the results for operating systems above, we don&rsquo;t believe this
represents a meaningful shift in code editor usage, but rather shows some of
the variability we expect to see in a community survey such as this. In
particular, we exclude the randomly sampled respondents from VS Code for this
question, as we know that group is heavily biased towards VS Code. However,
that has the side effect of making these results more susceptible to variation
each year.</p>
<p>We also looked at respondents&rsquo; level of satisfaction with Go based on the
editor they prefer using. After controlling for length of experience, we found
no differences: we don&rsquo;t believe people enjoy working with Go more or less
based on which code editor they use. That doesn&rsquo;t necessarily mean all Go
editors are equal, but may reflect that people find the editor that is best
for their own needs. This would suggest the Go ecosystem has a healthy
diversity of different editors geared towards different use cases and
developer preferences.</p>
<p><img src="survey2023h2/editor_self_select.svg" alt="Chart of code editors
respondents prefer to use with Go" class="chart" /></p>
<h2 id="stacks">Tech stacks</h2>
<p>To better understand the web of software and services that Go developers
interact with, we asked several questions about tech stacks. We&rsquo;re sharing
these results with the community to show which tools and platforms are in
common use today, but we believe everyone should consider their own needs and
use cases when selecting a tech stack. More plainly: we neither intend for
readers to use this data to select components of their tech stack because they
are popular, nor to avoid components because they are not commonly used.</p>
<p>First, we can say with confidence that Go is a language for modern cloud-based
development. Indeed, 75% of respondents work on Go software that integrates
with cloud services. For nearly half of respondents, this involved AWS (48%),
and almost one-third used GCP (29%) for their Go development and deployments.
For both AWS and GCP, usage is equally balanced among large enterprises and
smaller organizations. Microsoft Azure is the only cloud provider that is
significantly more likely to be used in large organizations (companies with &gt;
1,000 employees) than smaller shops; other providers show no meaningful
differences in usage based on the size of the organization.</p>
<p><img src="survey2023h2/cloud.svg" alt="Chart of cloud platforms respondents
use with Go" class="chart" /></p>
<p>Databases are extremely common components of software systems, and we found
that 91% of respondents said the Go services they work on use at least one.
Most frequently this was PostgreSQL (59%), but with double digits of
respondents reporting use of six additional databases, it&rsquo;s safe to say there
are not just a couple of standard DBs for Go developers to consider. We again
see differences based on organization size, with respondents from smaller
organizations more likely to report using PostgreSQL and Redis, while
developers from large organizations are somewhat more likely to use a database
specific to their cloud provider.</p>
<p><img src="survey2023h2/db.svg" alt="Chart of databases respondents use with
Go" class="chart" /></p>
<p>Another common component respondents reported using were caches or key-value
stores; 68% of respondents said they work on Go software incorporating at
least one of these. Redis was clearly the most common (57%), followed at a
distance by etcd (10%) and memcached (7%).</p>
<p><img src="survey2023h2/cache.svg" alt="Chart of caches respondents use with
Go" class="chart" /></p>
<p>Similar to databases, survey respondents told us they use a range of different
observability systems. Prometheus and Grafana were the most commonly cited
(both at 43%), but Open Telemetry, Datadog, and Sentry were all in double
digits.</p>
<p><img src="survey2023h2/metrics.svg" alt="Chart of metric systems respondents
use with Go" class="chart" /></p>
<p>Lest anyone wonder &ldquo;Have we JSON&rsquo;d all the things?&rdquo;&hellip; yes, yes we have.
Nearly every respondent (96%!) said their Go software uses the JSON data
format; that&rsquo;s about as close to universal as you&rsquo;ll see with self-reported
data. YAML, CSV, and protocol buffers are also all used by roughly half of
respondents, and double-digit proportions work with TOML and XML as well.</p>
<p><img src="survey2023h2/data.svg" alt="Chart of data formats respondents use
with Go" class="chart" /></p>
<p>For authentication and authorization services, we found most respondents are
building upon the foundations provided by standards such as
<a href="https://jwt.io/introduction" rel="noreferrer" target="_blank">JWT</a> and <a href="https://oauth.net/2/" rel="noreferrer" target="_blank">OAuth2</a>. This
also appears to be an area where an organization&rsquo;s cloud provider&rsquo;s solution
is about as likely to be used as most turn-key alternatives.</p>
<p><img src="survey2023h2/auth.svg" alt="Chart of authentication systems
respondents use with Go" class="chart" /></p>
<p>Finally, we have a bit of a grab bag of other services that don&rsquo;t neatly fit
into the above categories. We found that nearly half of respondents work with
gRPC in their Go software (47%). For infrastructure-as-code needs, Terraform
was the tool of choice for about ¼ of respondents. Other fairly common
technologies used alongside Go included Apache Kafka, ElasticSearch, GraphQL,
and RabbitMQ.</p>
<p><img src="survey2023h2/other_tech.svg" alt="Chart of authentication systems
respondents use with Go" class="chart" /></p>
<p>We also looked at which technologies tended to be used together. While nothing
clearly analogous to the classic <a href="https://en.wikipedia.org/wiki/LAMP_(software_bundle)" rel="noreferrer" target="_blank">LAMP
stack</a> emerged from this
analysis, we did identify some interesting patterns:</p>
<ul>
<li>All or nothing: Every category (except data formats) showed a strong
correlation where if a respondent answered “None” to one category, they
likely answered “None” for all of the others. We interpret this as evidence
that a minority of use cases require none of these tech stack components,
but once the use case requires any one of them, it likely requires (or is at
least simplified by) more than just one.</li>
<li>A bias towards cross-platform technologies: Provider-specific solutions
(i.e., services that are unique to a single cloud platform) were not
commonly adopted. However, if respondents used one provider-specific
solution (e.g., for metrics), they were substantially more likely to also
say they used cloud-specific solutions in order areas (e.g., databases,
authentication, caching, etc.).</li>
<li>Multicloud: The three biggest cloud platforms were most likely to be
involved in multicloud setups. For example, if an organization is using any
non-AWS cloud provider, they’re probably also using AWS. This pattern was
clearest for Amazon Web Services, but was also apparent (to a lesser extent)
for Google Cloud Platform and Microsoft Azure.</li>
</ul>
<h2 id="gonew">How developers start new Go projects</h2>
<p>As part of our <a href="/blog/gonew">experimentation with project
templates</a>, we wanted to understand how Go
developers get started with new projects today. Respondents told us their
biggest challenges were choosing an appropriate way to structure their project
(54%) and learning how to write idiomatic Go (47%). As two respondents phrased
it:</p>
<blockquote>
<p>&ldquo;Finding an appropriate structure and the right abstraction levels for a new
project can be quite tedious; looking at high-profile community and
enterprise projects for inspiration can be quite confusing as everyone
structures their project differently&rdquo; <span class="quote_source">&mdash;
Professional Go developer w/ 5 &ndash; 9 years of Go experience</span></p>
</blockquote>
<blockquote>
<p>&ldquo;It would be great if [Go had a] toolchain to create [a project&rsquo;s] basic
structure for web or CLI like `go init &lt;project name&gt;`&rdquo; <span
class="quote_source">&mdash; Professional Go developer w/ 3 &ndash; 4 years of
experience</span></p>
</blockquote>
<p>Newer Go developers were even more likely to encounter these challenges: the
proportions increased to 59% and 53% for respondents with less than two years
of experience with Go, respectively. These are both areas we hope to improve
via our <code>gonew</code> prototype: templates can provide new Go developers with
well-tested project structures and design patterns, with initial
implementations written in idiomatic Go. These survey results have helped our
team to keep the purpose of <code>gonew</code> focused on tasks the Go community most
struggle with.</p>
<p><img src="survey2023h2/new_challenge.svg" alt="Chart of challenges respondents
faced when starting new Go projects" class="chart" /></p>
<p>A majority of respondents told us they either use templates or copy+paste code
from existing projects when starting a new Go project (58%). Among respondents
with less than five years of Go experience, this proportion increased to
nearly ⅔ (63%). This was an important confirmation that the template-based
approach in <code>gonew</code> seems to meet developers where they already are, aligning
a common, informal approach with <code>go</code> command-style tooling. This is further
supported by the common feature requests for project templates: a majority of
respondents requested 1) a pre-configured directory structure to organize
their project and 2) sample code for common tasks in the project domain. These
results are well-aligned with the challenges developers said they faced in the
previous section. The responses to this question also help tease apart the
difference between project structure and design patterns, with nearly twice as
many respondents saying they want Go project templates to provide the former
than the latter.</p>
<p><img src="survey2023h2/new_approach.svg" alt="Chart of approaches respondents
used when starting new Go projects" class="chart" /></p>
<p><img src="survey2023h2/templates.svg" alt="Chart of functionality respondents
requested when starting new Go projects" class="chart" /></p>
<p>A majority of respondents told us the ability to make changes to a template
<em>and</em> have those changes propagate to projects based on that template was of
at least moderate importance. Anecdotally, we haven&rsquo;t spoken with any
developers who <em>currently</em> have this functionality with home-grown template
approaches, but it suggests this is an interesting avenue for future
development.</p>
<p><img src="survey2023h2/template_updates.svg" alt="Chart of respondent interest
in updatable templates" class="chart" /></p>
<h2 id="err_handling">Developer goals for error handling</h2>
<p>A perennial topic of discussion among Go developers is potential improvements
to error handling. As one respondent summarized:</p>
<blockquote>
<p>&ldquo;Error handling adds too much boilerplate (I know, you probably heard this
before)&rdquo; <span class="quote_source">&mdash; Open source Go developer w/ 1 &ndash; 2
years of experience</span></p>
</blockquote>
<p>But, we also hear from numerous developers that they appreciate Go&rsquo;s approach
to error handling:</p>
<blockquote>
<p>&ldquo;Go error handling is simple and effective. As I have backends in Java and
C# and exploring Rust and Zig now, I am always pleased to go back to write
Go code. And one of the reasons is, believe it or not, error handling. It is
really simple, plain and effective. Please leave it that way.&rdquo; <span
class="quote_source">&mdash; Open source Go developer w/ 5 &ndash; 9 years of
experience</span></p>
</blockquote>
<p>Rather than ask about specific modifications to error handling in Go, we
wanted to better understand developers&rsquo; higher-level goals and whether Go&rsquo;s
current approach has proven useful and usable. We found that a majority of
respondents appreciate Go&rsquo;s approach to error handling (55%) and say it helps
them know when to check for errors (50%). Both of these outcomes were stronger
for respondents with more Go experience, suggesting that either developers
grow to appreciate Go&rsquo;s approach to error handling over time, or that this is
one factor leading developers to eventually leave the Go ecosystem (or at
least stop responding to Go-related surveys). Many survey respondents also
felt that Go requires a lot of tedious, boilerplate code to check for errors
(43%); this remained true regardless of how much prior Go experience
respondents had. Interestingly, when respondents said they appreciate Go&rsquo;s
error handling, they were unlikely to say it also results in lots of
boilerplate code&mdash;our team had a hypothesis that Go developers can both
appreciate the language&rsquo;s approach to error handling and feel it&rsquo;s too
verbose, but only 14% of respondents agreed with both statements.</p>
<p>Specific issues that respondents cited include challenges knowing which error
types to check for (28%), wanting to easily show a stack trace along with the
error message (28%), and the ease with which errors can be entirely ignored
(19%). About ⅓ of respondents were also interested in adopting concepts from
other languages, such as Rust&rsquo;s <code>?</code> operator (31%).</p>
<p>The Go team has no plans to add exceptions to the language, but since this is
anecdotally a common request, we included it as a response choice. Only 1 in
10 respondents said they wished they could use exceptions in Go, and this was
inversely related to experience&mdash;more veteran Go developers were less likely
to be interested in exceptions than respondents newer to the Go community.</p>
<p><img src="survey2023h2/error_handling.svg" alt="Chart of respondents' thoughts
about Go's error handling approach" class="chart" /></p>
<h2 id="mlai">Understanding ML/AI use cases</h2>
<p>The Go team is considering how the unfolding landscape of new ML/AI
technologies may impact software development in two distinct veins: 1) how
might ML/AI tooling help engineers write better software, and 2) how might Go
help engineers bring ML/AI support to their applications and services? Below,
we delve into each of these areas.</p>
<h3 id="helping-engineers-write-better-software">Helping engineers write better software</h3>
<p>There&rsquo;s little denying we&rsquo;re in <a href="https://www.gartner.com/en/articles/what-s-new-in-artificial-intelligence-from-the-2023-gartner-hype-cycle" rel="noreferrer" target="_blank">a hype cycle around the possibilities for
AI/ML</a>.
We wanted to take a step back to focus on the broader challenges developers
face and where they think AI might prove useful in their regular work. The
answers were a bit surprising, especially given the industry&rsquo;s current focus
on coding assistants.</p>
<p>First, we see a few AI use cases that about half of respondents thought could
be helpful: generating tests (49%), suggesting best practices in-situ (47%),
and catching likely mistakes early in the development process (46%). A
unifying theme of these top use cases is that each could help improve the
quality and reliability of code an engineer is writing. A fourth use case
(help writing documentation) garnered interest from about ⅓ of respondents.
The remaining cases comprise a long tail of potentially fruitful ideas, but
these are of significantly less general interest than the top four.</p>
<p>When we look at developers&rsquo; duration of experience with Go, we find that
novice respondents are interested in help resolving compiler errors and
explaining what a piece of Go code does more than veteran Go developers. These
might be areas where AI could help improve the getting started experience for
new Gophers; for example, an AI assistant could help explain in natural
language what an undocumented block of code does, or suggest common solutions
to specific error messages. Conversely, we see no differences between
experience levels for topics like &ldquo;catch common mistakes&rdquo;&mdash;both novice and
veteran Go developers say they would appreciate tooling to help with this.</p>
<p>One can squint at this data and see three broad trends:</p>
<ol>
<li>Respondents voiced interest in getting feedback from &ldquo;expert reviewers&rdquo; in
real-time, not just during review time.</li>
<li>Generally, respondents appeared most interested in tooling that saves them
from potentially less-enjoyable tasks (e.g., writing tests or documenting
code).</li>
<li>Wholesale writing or translating of code was of fairly low interest,
especially to developers with more than a year or two of experience.</li>
</ol>
<p>Taken together, it appears that today, developers are less excited by the
prospect of machines doing the fun (e.g., creative, enjoyable, appropriately
challenging) parts of software development, but do see value in another set of
&ldquo;eyes&rdquo; reviewing their code and potentially handling dull or repetitive tasks
for them. As one respondent phrased it:</p>
<blockquote>
<p>&ldquo;I&rsquo;m specifically interested in using AI/ML to improve my productivity with
Go. Having a system that is trained in Go best practices, can catch
anti-patterns, bugs, generate tests, with a low rate of hallucination, would
be killer.&rdquo; <span class="quote_source">&mdash; Professional Go developer w/ 5 &ndash;
9 years of experience</span></p>
</blockquote>
<p>This survey, however, is just one data point in a quickly-evolving research
field, so it&rsquo;s best to keep these results in context.</p>
<p><img src="survey2023h2/ml_use_cases.svg" alt="Chart of respondents' interest
in AI/ML support for development tasks" class="chart" /></p>
<h3 id="bringing-ai-features-to-applications-and-services">Bringing AI features to applications and services</h3>
<p>In addition to looking at how Go developers might benefit from AI/ML-powered
tooling, we explored their plans for building AI-powered applications and
services (or supporting infrastructure) with Go. We found that we&rsquo;re still
early in <a href="https://en.wikipedia.org/wiki/Technology_adoption_life_cycle" rel="noreferrer" target="_blank">the adoption
curve</a>: most
respondents have not yet tried to use Go in these areas, though every topic
saw some level of interest from roughly half of respondents. For example, a
majority of respondents reported interest in integrating the Go services they
work on with LLMs (49%), but only 13% have already done so or are currently
evaluating this use case. At the time of this survey, responses gently suggest
that developers may be most interested in using Go to call LLMs directly,
build the data pipelines needed to power ML/AI systems, and for creating API
endpoints other services can call to interact with ML/AI models. As one
example, this respondent described the benefits they hoped to gain by using Go
in their data pipelines:</p>
<blockquote>
<p>&ldquo;I want to integrate the ETL [extract, transform, and load] part using Go,
to keep a consistent, robust, reliable codebase.&rdquo; <span
class="quote_source">&mdash; Professional Go developer w/ 3 &ndash; 4 years of
experience</span></p>
</blockquote>
<p><img src="survey2023h2/ml_adoption.svg" alt="Chart of respondents' current use
of (and interest in) Go for AI/ML systems" class="chart" /></p>
<h2 id="err_msgs">Toolchain error messages</h2>
<p>Many developers can relate to the frustrating experience of seeing an error
message, thinking they know what it means and how to resolve it, but after
hours of fruitless debugging realize it meant something else entirely. One
respondent explained their frustration as follows:</p>
<blockquote>
<p>&ldquo;So often the printed complaints wind up having nothing to do with the
problem, but it can take an hour before I discover that that&rsquo;s the case. The
error messages are unnervingly terse, and don&rsquo;t seem to go out of their way
to guess as to what the user might be trying to do or [explain what they&rsquo;re]
doing wrong.&rdquo; <span class="quote_source">&mdash; Professional Go developer w/ 10+
years of experience</span></p>
</blockquote>
<p>We believe the warnings and errors emitted by developer tooling should be
brief, understandable, and actionable: the human reading them should be able
to accurately understand what went wrong and what they can do to resolve the
issue. This is an admittedly high bar to strive for, and with this survey we
took some measurements to understand how developers perceive Go&rsquo;s current
warning and error messages.</p>
<p>When thinking about the most recent Go error message they worked through,
respondents told us there was much room for improvement. Only a small majority
understood what the problem was from the error message alone (54%), and even
fewer knew what to do next to resolve the issue (41%). It appears a relatively
small amount of additional information could meaningfully increase these
proportions, as ¼ of respondents said they mostly knew how to fix the problem,
but needed to see an example first. Further, with 11% of respondents saying
they couldn&rsquo;t make sense of the error message, we now have a baseline for
current understandability of the Go toolchain&rsquo;s error messages.</p>
<p>Improvements to Go&rsquo;s toolchain error messages would especially benefit
less-experienced Gophers. Respondents with up to two years of experience were
less likely than veteran Gophers to say they understood the problem (47% vs.
61%) or knew how to fix it (29% vs. 52%), and were twice as likely to need to
search online to fix the issue (21% vs. 9%) or even make sense of what the
error meant (15% vs. 7%).</p>
<p>We hope to focus on improving toolchain error messages during 2024. These
survey results suggest this is an area of frustration for developers of all
experience levels, and will particularly help newer developers get started
with Go.</p>
<p><img src="survey2023h2/err_exp.svg" alt="Chart of error handling experiences"
class="chart" /></p>
<p><img src="survey2023h2/err_exp_exp.svg" alt="Chart of error handling
experiences, split by duration of Go experience" class="chart" /></p>
<p>To understand <em>how</em> these messages might be improved, we asked survey
respondents an open-ended question: &ldquo;If you could make a wish and improve one
thing about error messages in the Go toolchain, what would you change?&rdquo;. The
responses largely align with our hypothesis that good error messages are both
understandable and actionable. The most common response was some form of &ldquo;Help
me understand what led to this error&rdquo; (36%), 21% of respondents explicitly
asked for guidance to fix the problem, and 14% of respondents called out
languages such as Rust or Elm as exemplars which strive to do both of these
things. In the words of one respondent:</p>
<blockquote>
<p>&ldquo;For compilation errors, Elm or Rust-style output pinpointing exact issue in
the source code. Errors should include suggestions to fix them where
possible&hellip; I think a general policy of &lsquo;optimize error output to be read by
humans&rsquo; with &lsquo;provide suggestions where possible&rsquo; would be very welcome
here.&rdquo; <span class="quote_source">&mdash; Professional Go developer w/ 5 &ndash; 9
years of experience</span></p>
</blockquote>
<p>Understandably, there is a fuzzy conceptual boundary between toolchain error
messages and runtime error messages. For example, one of the top requests
involved improved stack traces or other approaches to assist debugging runtime
crashes (22%). Similarly, a surprising theme in 4% of the feedback was about
challenges with getting help from the <code>go</code> command itself. These are great
examples of the Go community helping us identify related pain points that
weren&rsquo;t otherwise on our radar. We started this investigation focused on
improving compile-time errors, but one of the core areas Go developers would
like to see improved actually relates to run-time errors, while another was
about the <code>go</code> command&rsquo;s help system.</p>
<blockquote>
<p>&ldquo;When an error is thrown, the call stack can be huge and includes a bunch of
files I don&rsquo;t care about. I just want to know where the problem is in MY
code, not the library I&rsquo;m using, or how the panic was handled.&rdquo; <span
class="quote_source">&mdash; Professional Go developer w/ 1 &ndash; 2 years of
experience</span></p>
</blockquote>
<blockquote>
<p>&ldquo;Getting help via `go help run` dumps a wall of text, with links to
further readings to find the available command-line flags. Or the fact that
it understands `go run &ndash;help` but instead of showing the help, it says
&lsquo;please run go help run instead&rsquo;. Just show me list of flags in `go run
&ndash;help`.&rdquo; <span class="quote_source">&mdash; Professional Go developer w/ 3 &ndash;
4 years of experience</span></p>
</blockquote>
<p><img src="survey2023h2/text_err_wish.svg" alt="Chart of potential improvements
for Go's error messages" class="chart" /></p>
<h2 id="microservices">Microservices</h2>
<p>We commonly hear that developers find Go to be a great fit for microservices,
but we have never tried to quantify how many Go developers have adopted this
type of service architecture, understand how those services communicate with
one another, or the challenges developers encounter when working on them. This
year we added a few questions to better understand this space.</p>
<p>A plurality of respondents said they work mostly on microservices (43%), with
another ¼ saying they work on a mix of both microservices and monoliths. Only
about ⅕ of respondents work mostly on monolithic Go applications. This is one
of the few areas where we see differences based on the size of organization
respondents work at&mdash;large organizations seem more likely to have adopted a
microservice architecture than smaller companies. Respondents from large
organizations (&gt;1,000 employees) were most likely to say they work on
microservices (55%), with only 11% of these respondents working primarily on
monoliths.</p>
<p><img src="survey2023h2/service_arch.svg" alt="Chart of respondents' primary
service architecture" class="chart" /></p>
<p>We see some bifurcation in the number of microservices comprising Go
platforms. One group is composed of a handful (2 to 5) of services (40%),
while the other consists of larger collections, with a minimum of 10 component
services (37%). The number of microservices involved does not appear to be
correlated with organization size.</p>
<p><img src="survey2023h2/service_num.svg" alt="Chart of the number of
microservices respondents' systems involve" class="chart" /></p>
<p>A large majority of respondents use some form of direct response request
(e.g., RPC, HTTP, etc.) for microservice communication (72%). A smaller
proportion use message queues (14%) or a pub/sub approach (9%); again, we see
no differences here based on organization size.</p>
<p><img src="survey2023h2/service_comm.svg" alt="Chart of how microservices
communicate with one another" class="chart" /></p>
<p>A majority of respondents build microservices in a polyglot of languages, with
only about ¼ exclusively using Go. Python is the most common companion
language (33%), alongside Node.js (28%) and Java (26%). We again see
differences based on organization size, with larger organizations more likely
to be integrating Python (43%) and Java (36%) microservices, while smaller
organizations are a bit more likely to only use Go (30%). Other languages
appeared to be used equally based on organization size.</p>
<p><img src="survey2023h2/service_lang.svg" alt="Chart of other languages that Go
microservices interact with" class="chart" /></p>
<p>Overall, respondents told us testing and debugging were their biggest
challenge when writing microservice-based applications, followed by
operational complexity. Many other challenges occupy the long tail on this
graph, though &ldquo;portability&rdquo; stands out as a non-issue for most respondents. We
interpret this to mean that such services aren&rsquo;t intended to be portable
(beyond basic containerization); for example, if an organization&rsquo;s
microservices are initially powered by PostgreSQL databases, developers aren&rsquo;t
concerned with potentially porting this to an Oracle database in the near
future.</p>
<p><img src="survey2023h2/service_challenge.svg" alt="Chart of challenges
respondents face when writing microservice-based applications" class="chart" /></p>
<h2 id="modules">Module authorship and maintenance</h2>
<p>Go has a vibrant ecosystem of community-driven modules, and we want to
understand the motivations and challenges faced by developers who maintain
these modules. We found that about ⅕ of respondents maintain (or used to
maintain) an open-source Go module. This was a surprisingly high proportion,
and may be biased due to how we share this survey: module maintainers may be
more likely to closely follow the Go blog (where this survey is announced)
than other Go developers.</p>
<p><img src="survey2023h2/mod_maintainer.svg" alt="Chart of how many respondents
have served as a maintainer for a public Go module" class="chart" /></p>
<p>Module maintainers appear to be largely self-motivated&mdash;they report working
on modules that they need for personal (58%) or work (56%) projects, that they
do so because they enjoy working on these modules (63%) and being part of the
public Go community (44%), and that they learn useful skills from their module
maintainership (44%). More external motivations, such as receiving recognition
(15%), career advancement (36%), or cash money (20%) are towards the bottom of
the list.</p>
<p><img src="survey2023h2/mod_motivation.svg" alt="Chart of the motivations of
public module maintainers" class="chart" /></p>
<p>Given the forms of <a href="https://en.wikipedia.org/wiki/Motivation#Intrinsic_and_extrinsic" rel="noreferrer" target="_blank">intrinsic
motivation</a> identified above, it
follows that a key challenge for module maintainers is finding time to devote
to their module (41%). While this might not seem like an actionable finding in
itself (we can&rsquo;t give Go developers an extra hour or two each day, right?),
it&rsquo;s a helpful lens through which to view module tooling and
development&mdash;these tasks are most likely occurring while the developer is
already pressed for time, and perhaps it&rsquo;s been weeks or months since they
last had an opportunity to work on it, so things aren&rsquo;t fresh in their memory.
Thus, aspects like understandable and actionable error messages can be
particularly helpful: rather than require someone to once again search for
specific <code>go</code> command syntax, perhaps the error output could provide the
solution they need right in their terminal.</p>
<p><img src="survey2023h2/mod_challenge.svg" alt="Chart of challenges respondents
face when maintaining public Go modules" class="chart" /></p>
<h2 id="demographics">Demographics</h2>
<p>Most survey respondents reported using Go for their primary job (78%), and a
majority (59%) said they use it for personal or open-source projects. In fact,
it&rsquo;s common for respondents to use Go for <em>both</em> work and personal/OSS
projects, with 43% of respondents saying they use Go in each of these
situations.</p>
<p><img src="survey2023h2/where.svg" alt="Chart of situations in which
respondents recently used Go" class="chart" /></p>
<p>The majority of respondents have been working with Go for under five years
(68%). As we&rsquo;ve seen in <a href="/blog/survey2023-q1-results#novice-respondents-are-more-likely-to-prefer-windows-than-more-experienced-respondents">prior
years</a>,
people who found this survey via VS Code tended to be less experienced than
people who found the survey via other channels.</p>
<p>When we break down where people use Go by their experience level, two findings
stand out. First, a majority of respondents from all experience levels said
they&rsquo;re using Go professionally; indeed, for people with over two years of
experience, the vast majority use Go at work (85% &ndash; 91%). A similar trend
exists for open-source development. The second finding is that developers with
less Go experience are more likely to be using Go to expand their skill set
(38%) or to evaluate it for use at work (13%) than more experienced Go
developers. We interpret this to mean that many Gophers initially view Go as
part of &ldquo;upskilling&rdquo; or expanding their understanding of software development,
but that within a year or two, they look to Go as more of a tool for doing
than learning.</p>
<p><img src="survey2023h2/go_exp.svg" alt="Chart of how long respondents have
been working with Go" class="chart" /></p>
<p><img src="survey2023h2/where_exp.svg" alt="Chart of situations in which
respondents recently used Go, split by their level of Go experience"
class="chart" /></p>
<p>The most common use cases for Go continue to be API/RPC services (74%) and
command line tools (62%). People tell us Go is a great choice for these types
of software for several reasons, including its built-in HTTP server and
concurrency primitives, ease of cross-compilation, and single-binary
deployments.</p>
<p>The intended audience for much of this tooling is in business settings (62%),
with 17% of respondents reporting that they develop primarily for more
consumer-oriented applications. This isn&rsquo;t surprising given the low use of Go
for consumer-focused applications such as desktop, mobile, or gaming, vs. its
very high use for backend services, CLI tooling, and cloud development, but it
is a useful confirmation of how heavily Go is used in B2B settings.</p>
<p>We also looked for differences based on respondents&rsquo; level of experience with
Go and organization size. More experienced Go developers reported building a
wider variety of different things in Go; this trend was consistent across
every category of app or service. We did not find any notable differences in
what respondents are building based on their organization size.</p>
<p><img src="survey2023h2/what.svg" alt="Chart of the types of things respondents
are building with Go" class="chart" /></p>
<p><img src="survey2023h2/enduser.svg" alt="Chart of the audience using the
software respondents build" class="chart" /></p>
<p>Respondents were about equally likely to say this was the first time they&rsquo;ve
responded to the Go Developer Survey vs. saying they had taken this survey
before. There is a meaningful difference between people who learned about this
survey via the Go blog, where 61% reported taking this survey previously, vs.
people who learned about this survey via a notification in VS Code, where only
31% said they&rsquo;ve previously taken this survey. We don&rsquo;t expect people to
perfectly recall every survey they&rsquo;ve responded to on the internet, but this
gives us some confidence that we&rsquo;re hearing from a balanced mix of new and
repeat respondents with each survey. Further, this tells us our combination of
social media posts and random in-editor sampling are both necessary for
hearing from a diverse set of Go developers.</p>
<p><img src="survey2023h2/return_respondent.svg" alt="Chart of how many
respondents said they have taken this survey before" class="chart" /></p>
<h2 id="firmographics">Firmographics</h2>
<p>Respondents to this survey reported working at a mix of different
organizations, from thousand-person-plus enterprises (27%), to midsize
businesses (25%) and smaller organizations with &lt; 100 employees (44%). About
half of respondents work in the technology industry (50%), a large increase
over the next most-common industry&mdash;financial services&mdash;at 13%.</p>
<p>This is statistically unchanged from the past few Go Developer Surveys&mdash;we
continue to hear from people in different countries and in organizations of
different sizes and industries at consistent rates year after year.</p>
<p><img src="survey2023h2/org_size.svg" alt="Chart of the different organization
sizes where respondents use Go" class="chart" /></p>
<p><img src="survey2023h2/industry.svg" alt="Chart of the different industries
where respondents use Go" class="chart" /></p>
<p><img src="survey2023h2/location.svg" alt="Chart of countries or regions where
respondents are located" class="chart" /></p>
<h2 id="methodology">Methodology</h2>
<p>Most survey respondents &ldquo;self-selected&rdquo; to take this survey, meaning they
found it on the Go blog or other social Go channels. A potential problem with
this approach is that people who don&rsquo;t follow these channels are less likely
to learn about the survey, and might respond differently than people who do
closely follow them. About 40% of respondents were randomly sampled, meaning
they responded to the survey after seeing a prompt for it in VS Code (everyone
using the VS Code Go plugin between mid-July &ndash; mid-August 2023 had a 10% of
receiving this random prompt). This randomly sampled group helps us generalize
these findings to the larger community of Go developers.</p>
<h3 id="how-to-read-these-results">How to read these results</h3>
<p>Throughout this report we use charts of survey responses to provide supporting
evidence for our findings. All of these charts use a similar format. The title
is the exact question that survey respondents saw. Unless otherwise noted,
questions were multiple choice and participants could only select a single
response choice; each chart&rsquo;s subtitle will tell the reader if the question
allowed multiple response choices or was an open-ended text box instead of a
multiple choice question. For charts of open-ended text responses, a Go team
member read and manually categorized the responses. Many open-ended questions
elicited a wide variety of responses; to keep the chart sizes reasonable, we
condensed them to a maximum of the top 10 themes, with additional themes all
grouped under &ldquo;Other&rdquo;. The percentage labels shown in charts are rounded to
the nearest integer (e.g., 1.4% and 0.8% will both be displayed as 1%), but
the length of each bar and row ordering are based on the unrounded values.</p>
<p>To help readers understand the weight of evidence underlying each finding, we
included error bars showing the 95% <a href="https://en.wikipedia.org/wiki/Confidence_interval" rel="noreferrer" target="_blank">confidence
interval</a> for responses;
narrower bars indicate increased confidence. Sometimes two or more responses
have overlapping error bars, which means the relative order of those responses
is not statistically meaningful (i.e., the responses are effectively tied).
The lower right of each chart shows the number of people whose responses are
included in the chart, in the form &ldquo;n = [number of respondents]&rdquo;.</p>
<p>We include select quotes from respondents to help clarify many of our
findings. These quotes include the length of times the respondent has used Go.
If the respondent said they use Go at work, we refer to them as a
&ldquo;professional Go developer&rdquo;; if they don&rsquo;t use Go at work but do use Go for
open-source development, we refer to them as an &ldquo;open-source Go developer&rdquo;.</p>
<h2 id="closing">Closing</h2>
<p>The final question on our survey always asks respondents whether there&rsquo;s
anything else they&rsquo;d like to share with us about Go. The most common piece of
feedback people provide is &ldquo;thanks!&rdquo;, and this year was no different (33%). In
terms of requested language improvements, we see a three-way statistical tie
between improved expressivity (12%), improved error handling (12%), and
improved type safety or reliability (9%). Respondents had a variety of ideas
for improving expressivity, with the general trend of this feedback being
&ldquo;Here&rsquo;s a specific thing I write frequently, and I wish it were easier to
express this in Go&rdquo;. The issues with error handling continue to be complaints
about the verbosity of this code today, while feedback about type safety most
commonly touched on <a href="https://en.wikipedia.org/wiki/Tagged_union" rel="noreferrer" target="_blank">sum types</a>.
This type of high-level feedback is extremely useful when the Go team tries to
plan focus areas for the coming year, as it tells us general directions in
which the community is hoping to steer the ecosystem.</p>
<blockquote>
<p>&ldquo;I know about Go&rsquo;s attitude towards simplicity and I appreciate it. I just
wish there [were] slightly more features. For me it would be better error
handling (not exceptions though), and maybe some common creature comforts
like map/reduce/filter and ternary operators. Anything not too obscure
that&rsquo;ll save me some &lsquo;if&rsquo; statements.&rdquo; <span class="quote_source">&mdash;
Professional Go developer w/ 1 &ndash; 2 years of experience</span></p>
</blockquote>
<blockquote>
<p>&ldquo;Please keep Go in line with the long term values Go established so long ago
— language and library stability. [&hellip;] It is an environment I can
rely on to not break my code after 2 or 3 years. For that, thank you very
much.&rdquo; <span class="quote_source">&mdash; Professional Go developer w/ 10+ years
of experience</span></p>
</blockquote>
<p><img src="survey2023h2/text_anything_else.svg" alt="Chart of other topics
respondents shared with us" class="chart" /></p>
<p>That&rsquo;s all for this bi-annual iteration of the Go Developer Survey. Thanks to
everyone who shared their feedback about Go&mdash;we have immense gratitude for
taking your time to help shape Go&rsquo;s future, and we hope you see some of your
own feedback reflected in this report. 🩵</p>
<p>&mdash; Todd (on behalf of the Go team at Google)</p>

 </div>

 
 <div class="Article prevnext">
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 <p>
 
 
 <b>Next article: </b><a href="/blog/deadcode">Finding unreachable functions with deadcode</a><br>
 
 
 
 
 <b>Previous article: </b><a href="/blog/14years">Fourteen Years of Go</a><br>
 
 
 <b><a href="/blog/all">Blog Index</a></b>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 </div>
 

 </div>
</div>

<script src="/js/jquery.js"></script>
<script src="/js/playground.js"></script>
<script src="/js/play.js"></script>
<script src="/js/godocs.js"></script>

</content></entry></feed>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid Atom 1.0" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=http%3A//blog.golang.org/feed.atom"><img src="valid-atom.png" alt="[Valid Atom 1.0]" title="Validate my Atom 1.0 feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//blog.golang.org/feed.atom

Home · About · News · Docs · Terms