Go is the most hated programming language. Compared to other languages, it provides 80% of utility with 20% of complexity. The hate comes from people who want 81% of utility, or 85% or 97%. As Rob Pike said, no one denies that 87% of utility provides more utility than 80%. The problem is that additional 7% of utility requires 36% more work. Here are some example. Someone complained on HN that struct tags are a not as powerful as annotations or macros. I explained that this is 80⁄20 design. Go testing standard library is a couple hundred lines of code, didn’t change much over the years and yet it provides all the basic testing features you might need. It doesn’t provide all the convenience features you might think of. That’s what Java’s jUnit library does, at a cost of tens of thousands lines of code and years of never-ending development. Go is 80⁄20 design. Goroutines are 80⁄20 design for concurrency compared to async in C# or Rust. Not as many features and knobs but only a fraction of complexity (for users and implementors). When Go launched it didn’t have user defined generics but the built-in types that needed it were generic: arrays/slices, maps, channels. That 8⁄20 design served Go well for over a decade. Most languages can’t resist driving towards 100% design at 400% the cost. C#, Swift, Rust - they all seem on a never-ending treadmill of adding features. Even JavaScript, which started as a 70⁄30 language has been captured by people whose job became adding more features to JavaScript. If 80⁄20 is good, wouldn’t 70⁄30 be even better? No, it wouldn’t. Go has shown that you can have a popular language without enums. I don’t think you could have a popular language without structs. There’s a line below which the language is just not useful enough. Finally, what does “work” mean? There’s work done by the users of the language. Every additional feature of the language requires the programmer to learn about it. It’s more work than it seems. If you make functions as first class concepts, the work is not just learning the syntax and functionality. You need to learn new patterns coding, like functions that return functions. You need to learn about currying, passing functions as arguments. You need to learn not only how but when: when you should use that powerful functionality and when you shouldn’t. You can’t skip that complexity. Even if you decide to not learn how to use functions as first class concepts, your co-worker might and you have to be able to understand his code. Or the library you uses it or a tutorial talks about it. That’s why 80+% languages need coding guidelines. Google has one for C++ because hundreds of programmers couldn’t effectively work on shared C++ codebase if there was no restriction on what features any individual programmer could use. Google’s C++ style guide exists to lower C++ from 95% language to 90% language. The other work is by implementors of the language. Swift is a cautionary tale here. Despite over 10 years of development by very smart people with practically unlimited budget, on a project that is a priority for Apple, Swift compiler is still slow, crashy and is not meaningfully cross platform. They designed a language that they cannot implement properly. In contrast Go, a much simpler but still very capable, was fast, cross platform and robust from version 1.0.

In Chrome Dev Tools you can setup a mapping between the files web server sends to the browser and files on disk. This allows editing files in dev tools and having those changes saved to a file, which is handy. Early in 2025 they’ve added a way to automatically configure this mapping. It’s quite simple. Your server needs to serve /.well-known/appspecific/com.chrome.devtools.json file with content that looks like: { "workspace": { "root": "C:/Users/kjk/src/edna/src", "uuid": "8f6e3d9a-4b7c-4c1e-a2d5-7f9b1e3c1384" } } The uuid should be unique for each project. I got mine by asking Grok to generate random version 4 uuid. On Windows the path has to use Unix slash. It didn’t work when I sent Windows path. Shocking incompetence of the devs. This only works from localhost. Security. This file is read when you open dev tools in chrome. If you already have it open, you have to close and re-open. You still need to connect (annoying security theater). So the first thing you need to do: switch to sources tab in dev tools reveal left side panel (if hidden) switch to workspace tab there you should see the mapping is already configured but you need to click connect button Apparently bun sends this automatically. Here’s how I send it in my Go server: func serveChromeDevToolsJSON(w http.ResponseWriter, r *http.Request) { // your directory might be different than "src" srcDir, err := filepath.Abs("src") must(err) // stupid Chrome doesn't accept windows-style paths srcDir = filepath.ToSlash(srcDir) // uuid should be unique for each workspace uuid := "8f6e3d9a-4b7c-4c1e-a2d5-7f9b0e3c1284" s := `{ "workspace": { "root": "{{root}}", "uuid": "{{uuid}}" } }` s = strings.ReplaceAll(s, "{{root}}", srcDir) s = strings.ReplaceAll(s, "{{uuid}}", uuid) logf("serveChromeDevToolsJSON:\n\n%s\n\n", s) w.Header().Set("Content-Type", "application/json") w.Write(data) }

In Chrome Dev Tools you can setup a mapping between the files web server sends to the browser and files on disk. This allows editing files in dev tools and having those changes saved to a file, which is handy. Early in 2025 they’ve added a way to automatically configure this mapping. It’s quite simple. Your server needs to serve /.well-known/appspecific/com.chrome.devtools.json file with content that looks like: { "workspace": { "root": "C:/Users/kjk/src/edna/src", "uuid": "8f6e3d9a-4b7c-4c1e-a2d5-7f9b1e3c1384" } } The uuid should be unique for each project. I got mine by asking Grok to generate random version 4 uuid. On Windows the path has to use Unix slash. It didn’t work when I sent Windows path. Shocking incompetence of the devs. This only works from localhost. Security. This file is read when you open dev tools in chrome. If you already have it open, you have to close and re-open. First time you’ll have to give Chrome permissions to access that source director on disk. You need to: switch to sources tab in dev tools reveal left side panel (if hidden) switch to workspace tab there you should see the mapping is already configured but you need to click connect button Apparently bun sends this automatically. Here’s how I send it in my Go server: func serveChromeDevToolsJSON(w http.ResponseWriter, r *http.Request) { // your directory might be different than "src" srcDir, err := filepath.Abs("src")   must(err) // stupid Chrome doesn't accept windows-style paths   srcDir = filepath.ToSlash(srcDir) // uuid should be unique for each workspace   uuid := "8f6e3d9a-4b7c-4c1e-a2d5-7f9b0e3c1284" s := `{   "workspace": {     "root": "{{root}}",     "uuid": "{{uuid}}"   } }` s = strings.ReplaceAll(s, "{{root}}", srcDir)   s = strings.ReplaceAll(s, "{{uuid}}", uuid)   logf("serveChromeDevToolsJSON:\n\n%s\n\n", s)   w.Header().Set("Content-Type", "application/json")   w.Write(data) }

You don’t want your software to crash, do you? This post describes my experiences in making SumatraPDF crash less. SumatraPDF is a Windows desktop app. It’s a fast viewer for PDF, ePub, comic books etc.. It’s small and yet full of features. Know thy crashes The most important step in fixing crashes is knowing about them. There are variations between different Windows versions and variations of how people customize Windows and how they use your software. Sometimes in ways you would never think of. Those variations can lead to bugs or crashes. I have no hope of testing my software in all possible configurations. If you’re Microsoft or Adobe you can reinvest some of the revenue to hire an army or testers, setup compatibility labs etc. but for a single developer this is not realistic. Bugs most often lurk in untested code and even a very good testing effort won’t encounter all things that can go wrong in real life. Get the crash reports automatically Very few people bother to submit bug reports and crashes. When a program crashes, they just shrug and restart. The only realistic way to be informed about crashes is to automatically gather crash reports without user involvement. This is a proven idea. Microsoft did it for Windows. Mozilla and Google did it for their browsers. How to get crashes Regardless of the platform, the solution involves two parts: code in the software itself. When a crash happens it runs crash handler which creates crash report and sends it to the server a server, which accepts crash reports from the software The server The server part is simple: it’s a Go server running on Hetzner that accepts crash reports in text form via HTTP POST requests, saves them to disk and provides simple UI for browsing them. Crash reports are deleted after a week because there’s no point keeping them. If a crash stops happening, it was fixed. If it keeps happening, I’ll get new crash report. Intercepting crashes in C++ on Windows SumatraPDF is written in C++. We want our code to be executed when a crash or other fatal thing happen. To be notified about fatal things in C runtime: usesignal(SIGABRT, onSignalAbort);. This register onSignalAbort to be called on SIGABRT: void __cdecl onSignalAbort(int) { // put the signal back because can be called many times // (from multiple threads) and raise() resets the handler signal(SIGABRT, onSignalAbort); CrashMe(); } I just induce a hardware crash (referencing invalid memory location 0) so that it’s handled by crash handler: inline void CrashMe() { char* p = nullptr; // cppcheck-suppress nullPointer *p = 0; // NOLINT } To register with C++ runtime: ::set_terminate(onTerminate);. Similarly: void onTerminate() { CrashMe(); } To register for exceptions generated by CPU: gDumpEvent = CreateEvent(nullptr, FALSE, FALSE, nullptr); if (!gDumpEvent) { log("InstallCrashHandler: skipping because !gDumpEvent\n"); return; } gDumpThread = CreateThread(nullptr, 0, CrashDumpThread, nullptr, 0, nullptr); if (!gDumpThread) { log("InstallCrashHandler: skipping because !gDumpThread\n"); return; } gPrevExceptionFilter = SetUnhandledExceptionFilter(CrashDumpExceptionHandler); // 1 means that our handler will be called first, 0 would be: last AddVectoredExceptionHandler(1, CrashDumpVectoredExceptionHandler); Generating a crash report The most important part of a crash report is a readable call stack of a thread that crashed which looks like: sumatrapdf.exe!RectF::IsEmpty+0x0 \src\utils\GeomUtil.cpp+314 sumatrapdf.exe!DisplayModel::GetContentStart+0x3f \src\DisplayModel.cpp+1196 sumatrapdf.exe!DisplayModel::GoToPrevPage+0x7e \src\DisplayModel.cpp+1386 sumatrapdf.exe!CanvasOnMouseWheel+0x191 \src\Canvas.cpp+1318 sumatrapdf.exe!WndProcCanvasFixedPageUI+0x300 \src\Canvas.cpp+1672 sumatrapdf.exe!WndProcCanvas+0xa7 \src\Canvas.cpp+1993 user32.dll!CallWindowProcW+0x589 user32.dll!TranslateMessage+0x292 sumatrapdf.exe!RunMessageLoop+0x15c \src\SumatraStartup.cpp+531 sumatrapdf.exe!WinMain+0x11fd \src\SumatraStartup.cpp+1407 sumatrapdf.exe!__scrt_common_main_seh+0x106 To get a call stack you can use StackWalk64() from dbghelp.dll. But those are just addresses in memory. You then have to map each address into a loaded dll and offset in that dll. Then you have to match offset in the dll to a function and offset in that functions. And then match that offset in the function to a source code file and line that generated that code. To do all of that you need symbols in .pdb format. Because SumatraPDF is open source I decided for an unorthodox approach: For each version of SumatraPDF executable, I store .pdb symbols in online storage (currently it happens to be Cloudflare’s S3-copmatible R2). When crash happens I download those symbols locally, unpack them, and initialize dbghelp.dll with their locations. I then resolve addresses in memory to dll name, function name, offset in function and source code file name and line number. Other stuff in crash report: info about OS version, processor etc. in case those correlate to the crash list of loaded dlls. It’s quite common that other software injects their dlls into all executables running and those dlls might have bugs that cause the crash SumatraPDF configuration. To my detriment I’ve made SumatraPDF quite customizable and sometimes bugs only happen when certain options are used and if I’m not using the same settings, I can’t reproduce the bug even if I execute the same steps logs. When I can’t figure out a certain crash, I can add additional logging to help me understand what leads to the crash I include Git has revision in the executable, which is included in crash report. That way I can post-process the crash report on the server and for each stack frame I can generate a link to source code on GitHub. When crash happens the program is compromised so I take care to pre-compute as much info before crash handler executes. If crash handler crashes, I won’t get the crash report. SumatraPDF experience How does it work in practice? I’ve implemented the system described here in Sumatra 1.5. Sumatra is a rather complicated piece of C++ code and quite popular (several thousand of downloads per day). Before 1.5 we had a system where we would save the minidump to a disk and after a crash we would ask the user to report it in our bug tracker and attach minidump to the bug report. Almost no one did that. I only got few crash reports from users in few months. The automated system was sending tens of crash reports per day. Once I knew about the problems, I would try to fix them. Some problems I could fix just by looking at crash report. Some required writing stress tests to make them easier to reproduce locally. Some of them I can’t fix (e.g. because they are caused by buggy printer drivers or other software that injects buggy dlls into SumatraPDF process). I do know that I fixed some of the bugs. I can see that a new release generates less crashes and by looking at crash reports I can tell that some crashes that happened frequently in previous releases do not happen anymore. Building automated crash reporting system was the best investment I could have made for improving reliability of SumatraPDF. The alternatives While the general idea is always the same, there are different ways of implementing it. On Windows a simpler solution is to capture so-called minidumps (using MiniDumpWriteDumpProc() Windows API) instead of going to the trouble of generating human-readable crash reports client side. I did that too. The problem with that approach is that you have to inspect each crash dump manually in the debugger (e.g. WinDBG). I wrote a python script that automated the process (you can script it by launching cdb debugger with the right parameters and making it run !analyze -v)). Unfortunately, cdb is buggy and was hanging on some dump files. It’s probably possible to work around with a timeout in the python script, but at that point I stopped caring. Windows provides native support for minidumps. Google took minidump design and provided cross-platform implementation for Windows, Mac and Linux, as part of breakpad project which was then replaced by Crashpad. They are both Breakpad is the crash reporting system used by Google for Chrome and Mozilla for Firefox. It contains both client and server parts for native (C/C++ or Objective C) code. I used it once for a Mac app. For Objective C I prefer the approach described above as it’s simpler to implement, but I’m sure that’s a solid and well tested approach. On Windows, crash reports from your app are already sent to Microsoft as part of Windows Error Reporting. Apparently, it’s possible to for third party developers to get access to those reports but I never did that so I don’t know how. References CrashHandler.cpp is crash handling code in SumatraPDF Chrome’s crash reporting Mozilla crash reporting