<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Go on JVQ.net</title>
    <link>https://jvq.net/tags/go/</link>
    <description>Recent content in Go on JVQ.net</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 19 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://jvq.net/tags/go/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>jvq Blocks a Go Logging Change That Added Two Allocations to Every Request</title>
      <link>https://jvq.net/jvq-blocks-a-go-logging-change-that-added-two-allocations-to-every-request/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://jvq.net/jvq-blocks-a-go-logging-change-that-added-two-allocations-to-every-request/</guid>
      <description>&lt;p&gt;An access logger writes one JSON line per request. In Go, the usual way to make that cheap is to append into a buffer the caller owns: no &lt;code&gt;fmt&lt;/code&gt;, no &lt;code&gt;encoding/json&lt;/code&gt;, no strings built along the way. Done right, the benchmark says 0 allocs/op, and the garbage collector never hears about the logger at all.&lt;/p&gt;&#xA;&lt;p&gt;That property is easy to lose and hard to notice. Time per call wanders by several percent from run to run on a CI machine. An allocation count doesn&amp;rsquo;t wander. That&amp;rsquo;s why jvq compares allocations exactly, and why their budget can be an amount, here 0, instead of a percentage. This worked example is a small Go package set up to show it, with two real commits run through jvq 0.5.0 on a two-core cloud VM.&lt;/p&gt;</description>
    </item>
    <item>
      <title>jvq Flags an Update Check That Made a Go Command-Line Tool Nearly Four Times Bigger</title>
      <link>https://jvq.net/jvq-flags-an-update-check-that-made-a-go-command-line-tool-nearly-four-times-bigger/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://jvq.net/jvq-flags-an-update-check-that-made-a-go-command-line-tool-nearly-four-times-bigger/</guid>
      <description>&lt;p&gt;Some tools are judged by their size. A small binary that gets copied onto every build agent, baked into container images, or downloaded at the start of each CI job pays for every megabyte many times a day. Nobody looks at the size in review, because the diff doesn&amp;rsquo;t show it.&lt;/p&gt;&#xA;&lt;p&gt;jvq can gate the size of files your build makes, next to the timings. This worked example is a small Go command-line tool, &lt;code&gt;lvl&lt;/code&gt;, that counts log levels in JSON Lines files. Two real commits were run through jvq 0.5.0 on a two-core cloud VM.&lt;/p&gt;</description>
    </item>
    <item>
      <title>First jvq Release Fails Pull Requests That Make Go Benchmarks Slower Than Their Budget</title>
      <link>https://jvq.net/first-jvq-release-fails-pull-requests-that-make-go-benchmarks-slower-than-their-budget/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://jvq.net/first-jvq-release-fails-pull-requests-that-make-go-benchmarks-slower-than-their-budget/</guid>
      <description>&lt;p&gt;Most slowdowns get in one pull request at a time. An extra allocation in a loop, a string copied where a slice would do, a log call on the hot path. Each costs a few percent, each passes review, and a month later the service is 30% slower and nobody can say which change did it.&lt;/p&gt;&#xA;&lt;p&gt;jvq 0.1 is a check you put in CI to stop that. You give it a benchmark command and a budget, such as 5% slower at most. On every pull request it runs your benchmarks on the base branch and on the change, on the same runner, taking turns, and fails the build when the change is clearly over budget.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
