HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
benhoyt
goawk
Go2018–2026
benhoyt / goawk

goawk

A POSIX-compliant AWK interpreter written in Go, with CSV support

13Distinct people
22Mentions
0Explicit recommenders
2.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A POSIX-compliant AWK interpreter written in Go, with CSV support

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year22 dated mentions

Observed mentions: 2018-08-18 02:30:16 UTC to 2026-01-16 21:35:44 UTC.

02462018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC707
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC707
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

22 sources
Not me personally, but a GitHub user wrote a replacement for Go's regexp library that was "up to 3-3000x+ faster than stdlib": https://github.com/coregx/coregex ... at first I was impressed, so started testing it and reporting bugs, but as soon as I ran my own benchmarks, it all fell apart (https://github.com/coregx/coregex/issues/29). After some mostly-bot updates, that issue was closed. But someone else opened a very similar one recently (https://github.com/coregx/coregex/issues/79) -- same deal, "actually, it's slower than the stdlib in my tests". Basically AI slop with poor tests, poor benchmarks, and way oversold. How he's positioning these projects is the problematic bit, I reckon, not the use of AI. Same user did a similar thing by creating an AWK interpreter written in Go using LLMs: https://github.com/kolkov/uawk -- as the creato
Read the rest
r of (I think?) the only AWK interpreter written in Go (https://github.com/benhoyt/goawk), I was curious. It turns out that if there's only one item in the training data (GoAWK), AI likes to copy and paste freely from the original. But again, it's poorly tested and poorly benchmarked. I just don't see how one can get quality like this, without being realistic about code review, testing, and benchmarking.
In Cursor's latest “browser experiment” implied success without evidence
Surprised recent versions 1.18+ didn't see a jump in improvement, but might explain sumloop improvement for 1.19 I checked, they use switch on opcodes in vm.go. So would expect a recent improvement, but probably only <5%, & I didn't look close enough to see if awk is one of those languages where instruction dispatch matters less (like how APL tends to avoid issues since array ops avoid having dispatch in tight loops, or how Python avoids instruction dispatch overhead when using numpy) Indeed, they have a comment saying array of functions is faster for older versions of go: https://github.com/benhoyt/goawk/blob/158232a76856e12d680a53... For VMs Go had a problem for large switch statements: it would always use binary search instead of a jump table. This caused gopher-lua & go-lua to both take the route of having an array of functions which
Read the rest
they call on to dispatch instead A couple years ago this was fixed: https://go-review.googlesource.com/c/go/+/357330 I measured a small perf improvement switching gopher-lua to switch: https://github.com/yuin/gopher-lua/pull/479 edit: looking closer, not sure `compiler.CallBuiltin` is doing them a favor anymore. They seem to have a lot of double dispatch operations (like `compiler.AugAssignField`) which would be less impactful with binary search switch
In Go performance from version 1.0 to 1.22
I recently wrote a program of slightly over 200 lines in portable AWK: https://gitlab.com/dbohdan/humsize. I wrote it for a specific operating system (NetBSD), but I have ended up using it everywhere; the portability helped with it. I can recommend AWK for small utilities that transform text in a line- and column-oriented manner and don't need libraries. The main difficulties were making the command-line interface and testing. You can't have flags that begin with a dash in portable AWK without a shell wrapper, and I didn't want one. I settled on manually parsing key=value options, which I don't think are bad, just nonstandard. They look like this: humsize format=%6.1f%1s 'zero= empty' There is no standard way to test AWK code. For testing I wrote a shell script that checks the program's outputs with grep: https://gitlab.com/dbohdan/hu
Read the rest
msize/-/blob/122aaed8d65dc8c285.... Don't do this; your tests should give the user (you) better feedback. You may think your program doesn't need anything but a couple of trivial tests that won't ever change; it is a pain when you inevitably are proven wrong. I should have instead had a directory with reference outputs and diffed against them to see what went wrong (my own example: https://github.com/dbohdan/initool/blob/72f65d3fde245ff8660c...). To ensure I didn't introduce portability issues, I set up testing against different awks in GitLab CI. image: debian:bullseye-slim before_script: - apt update - apt install -y busybox gawk mawk original-awk - ln -s "$(which busybox)" awk - busybox wget -O goawk.tar.gz https://github.com/benhoyt/goawk/releases/download/v1.21.0/goawk_v1.21.0_linux_amd… - tar xzvf goawk.tar.gz test: script: - AWK=false ./test || true - AWK=./awk ./test - AWK=gawk ./test - AWK=./goawk ./test - AWK=mawk ./test - AWK=original-awk ./test Edit: Rephrased and added a nicer shell test example.
In Awk Technical Notes
Yes, that's right. With my simplistic UTF-8-based implementation it turned length() -- for example -- from O(1) to O(N), turning O(N) algorithms which use length() into O(N^2). See this issue: https://github.com/benhoyt/goawk/issues/93 Similar with substr() and other string functions, which when operating as bytes are O(1), but become O(N) when trying to count the number of codepoints as UTF-8. GNU Gawk has a fancier approach, which stores strings as UTF-8 as long as it can, but converts to UTF-32 if it needs to (eg: the string is non-ASCII and you call substr). It looks like Brian Kernighan's code has the same issue with length() and substr(). I'm going to try to email him about this, as I think it's kind of a performance blocker.
In Brian Kernighan adds Unicode support to Awk
I'm not sure if it was via my personal website or just my GitHub profile, but I got my current job at Canonical due to the CTO there reaching out about my GoAWK project (https://github.com/benhoyt/goawk). I get regular recruitment emails because I have my CV/resume online: most of them are very low-effort, but 1 in 20 or something are interesting emails where the recruiter has actually looked at my website and will tailor it personally. I also just enjoy technical writing, and get joy out of sharing it on HN. So it's "worth it" for me.
In Ask HN: Is having a personal blog/brand worth it for you?

Showing the 15 most recent of 22 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.