-
Request for a go linter: something that would warn when an variable with the name
erris not of typeerror:func Bla() { err := 123 // 'err' not of type 'error' }Would’ve saved me a few hours today trying to test if a Future was not-nil, without actually waiting for the result.
golang -
Moan-routine: LO's Predicate Signatures
A critique of function signatures the ’lo’ package offers for functions like Map and Filter. Continue reading →
-
There’s no reason to use Testify’s Suite package for Go unit tests anymore. It’s possible to do whatever you need to do with Go’s builtin test runner. Furthermore, most IDEs are smart enough to detect and run sub-tests that use
t.Run(). So save yourself some trouble and just use the defaults.I guess my point is that it’s nice to be able to run specific unit tests directly from the IDE, and that’s difficult to do using the Suite package.
golang -
Does Google ever regret naming Go “Go”? Such a common word to use as a proper noun. I know the language devs prefer not to use Golang, but there’s no denying that it’s easier to search for.
golang -
Lot of interesting thing scheduled for Go 1.24, but this one looks particularly exciting:
The new Text function can be used to generate cryptographically secure random text strings.
You’d be surprised how often I need to generate random strings. Doing so, without installing a third-party package, is always a bit involved; either generating a UUID and stripping the dashes, or doing a Base64 on a random byte slice. To be given a function to do this from the standard library will be most welcome.
And yes, I know generating a UUID usually involves installing a package (it’s high time Go’s standard library included a UUID implementation IMHO), but it’s usually a package I import anyway. Either that, or go-nanoid.
golang -
Goland’s LLM-powered auto-complete is really good. It’s got to the point where it feels like Goland is broken when I’m using a version that doesn’t have it. I’m sure they hope to expand of this, and if I can make a request on what they could do next, it would be to add “auto-complete” suggestions in other areas of the code.
For example, I’m working on a function which uses AWS’s Golang SDK to send an SQS message. I started writing out the call to send a message, when I found out that I forgot to define both the context and queue name in the function I’m working in. Nothing too hard to fix, of course, but it would mean moving away from where I’m am now, and conducting a mini context-switch away from calling the SDK to fixing my function definition.
It would be nice for the LLM-based auto-completer to suggest adding the context as the first parameter of the function, as per the convention. The queue name is a little more ambiguous: it could either be suggested as another function parameter or as a field on the provider type. I suppose both are just as likely, but assuming that Goland is refining it’s model based on my trends, it could suggest adding the topic name as a field, along with adding it in as a parameter to the constructor function.
Anyway, something for them to look at when they run out of work.
I mean, to be fair, they do offer “quick fixes” like creating a field when I reference one that doesn’t exist. They just need to take the next step and outright suggest it as a change, rather than have me write out the missing field, click the type error, and select the fix from the menu.
golang -
Please, Go developers, do not use Testify’s suite package. There’s not much support for the de-facto tabular test pattern, where you have tests nested within tests. Plus, it lacks any IDE integration niceties, such as running specific scenarios. Just use the built-in test package.
Nothing wrong with the Testify project itself, mind you. I use the assert package all the time. But the suite package just doesn’t gel with how unit testing is traditionally done in Go.
golang -
Buffalo, the Go framework that’s a bit like Rails, has been archived on GitHub. I’m wondering if it’s been retired. I’ve seen no announcement but I’m starting to suspect that it has.
A real shame. It was pretty good and the dev was so passionate behind it. Maybe running it was just too much.
I may need to rebuild Alto because of this. I was considering doing so anyway, just to make it simpler to maintain (I’m kinda afraid to touch it at the moment).
golang -
Dealing with money is annoying. Dealing with money using Go’s
big.Rattype? Really annoying.😮💨I complain, but dealing with Go’s weird API for big.Rat still beats flaffing about with formulas in Numbers.
golang -
Broadtail
Date: 2021 – 2022
Status: Paused
First project I’ll talk about is Broadtail. I think I talked about this one before, or at least I posted screenshot of it. I started work on this in 2021. The pandemic was still raging, and much of my downtime was watching YouTube videos. We were coming up to a federal election, and I was getting frustrated with seeing YouTube ads from political parties that offend me. This was before YouTube Premium so there was no real way to avoid these ads. Or was there?
Continue reading → -
Why I like developing in Go vs. something like NodeJS: my development setup doesn’t randomly break for some weird reason. When it does break, it’s because of something I did explicitly.
golang -
Why I'm Considering Building A Blogging CMS
I’m planning to start a new blog about Go development and one of the things that I’m currently torn on is how to host it. The choice look to be either using a service like blot.im or micro.blog or some other hosting service, using a static site generation tool like Hugo, or building my own CMS for it. I know that one of the things people tell you about blogging is that building your CMS is not worth your time: I myself even described it as “second cardinal sin of programming” on my first post to micro.blog.
Continue reading → -
Offical support for file embedding coming to Go
I’m excited to see, via Golang Weekly, that the official support for embedding static files in Go is being realised, with the final commit merged to the core a couple of days ago. This, along with the new file-system abstraction, will mean that it will be much easier to embed files in Go applications, and make use of them within the application itself.
One of the features I like about coding is Go is that the build artefacts are statically linked executables that can be distributed without any additional dependencies. This means that if I wanted to share something, all I need to do is to give them a single file that they can just run, without needing to worry about whether particular dependencies or runtimes are installed prior to doing so.
Continue reading → -
Remarks on Go's Error Handling using Facebook's SDK Crashes As a Framing Device
There are new reports of Facebook’s SDK crashing apps again due to server changes. The post above links to Bugsnag article which explores the underlying cause: that’s worth a read.
I’m going to throw a shout-out to Go’s approach to error handling here. I’m not saying that this shows the superiority of Go over Objective C: these sorts of things can happen in any language. The difference I want to highlight is that Go treats error handling as part of the standard flow of the language, rather than the exceptional flow. This forces you to think about error conditions when you’re making calls to code that can fail.
Continue reading → -
On Go’s Type Parameters Proposal
The developers of Go have release a new draft proposal for type parameters. The biggest change is the replacing the concept of constraints, which complicated the proposal somewhat, and replaced it with interfaces to express the same thing. You can read the proposal here latest proposal here.
I think they’re starting to reach a great balance between what currently exists in the language, and the features required to make a useful type parameter system. The use of interfaces to constrain the type, that is declare the operators that a type must implement in order to be used as a type parameter for a function or struct, makes total sense. It also makes moving to type parameters in some areas of the standard library trivial. For example, the sort.Sort function prototype:
Continue reading →
