I wonder if some of those things can be solved via a shim DLL that provides the necessary missing WinAPI functions instead of modifying the source code. Although the number of changes required seems vanishingly small anyway, so either approach coukd work just fine.
The additional upside of this approach is that you can also quite easily install fish on any host and it won't need any configuration to match what you're already used to
I dabbled in Kubernetes at work a few years ago. I was shocked at the state of their go.mod files. Especially because I had heard Kubernetes used as an example of great Go software. Right off the bat I needed to copy a dozen or so `replace` statements into my go.mod. I was sure I just didn’t understand something and spent an hour or so looking for the “right way” only to discover other open source controllers that had the same replaces in their go.mods.
Maybe that was a transitory stage and it’s straightened out now. I certainly hope so.
I think a lot of people assume Kubernetes must be a good Go example, because it's so big and successful. But it started life as a Java project and was ported into Go, and that shows in some of the architecture, Also, in general across all languages, picking the absolute largest projects you can is often not a great idea in terms of copying design unless you too are going to be that large, e.g., I wouldn't suggest using Firefox as an example of C++ necessarily. Such projects always end up developing solutions to problems you will never have, and solving problems we don't have is one of the most common mistakes software developers make.
I like your comparison about Firefox not being a great example of "good" C/C++.
I'd personally consider myself comfortable in C/C++. I've built Wayland compositors, H264 backends for live-streaming, and built Chromium occasionally for testing. Despite being a die-hard Firefox (zen) user - I still have not been able to compile Firefox! To be fair, this was pre-Firefox quantum days so I hope their SVM and build tools have improved.
Definitely do not look at Kubernetes as a good example of go code and especially not how it handles deps (btw, it only relatively recently switched to go mods).
They write it in space shuttle mode. Which means that it’s all got too many components from too many makers all kludged together and then one piece falls off and the whole thing blows up in production.
I just write my own, small, focused client for these AWS services since the SDKs are generally just so unergonomic. With vibe coding becoming a thing it's become even easier to do that.
You may already know these things, but for others who may not: the AWS SDK for Go suffers from shockingly bad discoverability.
For example, take the S3 library, github.com/aws/aws-sdk-go-v2/service/s3. If you have an s3.Client and you look at e.g. the ListObjectsV2 method, you might have no idea that there is a ListObjectsV2Paginator which makes it much easier to use, because nowhere in the method docs is it mentioned. Indeed, most operations that paginate have more ergonomic paginators, but none of them tell you this.
But that isn't even the worst of it. Say you want to download or upload a file to S3. If you haven't worked with AWS for other languages, you might think that you just do GetObject and PutObject. And yes, for small files, that's generally fine. But for large files you want to use resumable downloads and multipart uploads. So you look and lo, there is no simple way to do this in the AWS SDK for Go. But actually, there is! It's in a totally unrelated and unlinked package, called github.com/aws/aws-sdk-go-v2/feature/s3/manager.
Now you're getting some religion, so you ask "what are the other so-called 'feature' packages?" and you try to browse pkg.go.dev at the github.com/aws/aws-sdk-go-v2/feature level but nope, that's not a Go module so there's nothing to see there. In fact, you can't even browse the other s3 features, never mind find out what other services have features. Fortunately, you can browse their GitHub repo at least: https://github.com/aws/aws-sdk-go-v2/tree/main/feature
It's quite clear that they use poorly thought-out cross-language codegen for this, which partly explains the lack of ergonomics, but also shows that they don't much care whether you use their stuff properly.
Nice project! Having just 16Mb of RAM does indeed sound like a real challenge for stock Go (not the TinyGo variant)! Even hello world is a couple megs, although I imagine Dreamcast isn't 64-bit, so the instructions are probably much shorter. Interesting to see anything written in it :)
Nice article! One nitpick: Go can build C code via cgo when doing go get, but of course that probably won't generate the object files Ruby modules are expecting.
Probably both. Apple Silicon macbooks seem to never actually sleep, they just switch to the energy efficient cores, similar to how iPhones / iPads never truly sleep either. You can tell by leaving e.g. a while loop in zsh running and printing the date + sleep, and when you reopen the lid you'll see quite a few iterations actually completed.
For many cases you don't even need to make stat() call to determine whether or not the file is a directory (d_type specifically can tell it: https://man7.org/linux/man-pages/man3/readdir.3.html). That's what allows find(1) to be so quick
Well, it definitely does _something_, because on NFS the subsequent stat() calls after reading the directory names do indeed complete instantly :), at least in my testing.
I mean, readdirplus as a local filesystem API. Ultimately unix programs are just invoking getdents() (or equivalent) + stat() (or statx, whatever). Linux nfsclient probably caches the result of readdirplus for subsequent stat.
What I've found over the years is that protobuf is actually not that widespread, and, given that, if you ignore gogoprotobuf package, it would generate terrible (for Go's GC) structs with pointers for every field, it's not been terribly popular in Go community either, despite both originating at Google
Not at all. With human you can have some expectations based on context, expertise. They are also far less likely to make up extremely specific details.
Sure. I was agreeing with the conclusion though, where you should aim to verify what you hear from other humans, no matter how confident they sound. Been burned by that a few times by blindly trusting some statements from some respected people only for it to blow up in production because they were wrong :).
That is, strangely, until those humans turn to a topic I know something about. Then their reliability drops like a hot potato. At least they get everything else right!
reply