-
Musings Of Faking a REST-API Client in Server-Side Rendered Templates
Proponents of server-side rendering question whether a well-defined API can also work effectively with server-side templates, suggesting an approach where Go handlers serve both needs without requiring actual server round-trips. Continue reading →
-
TIL that Go’s formatter will be fine formatting a file with a composite literal for a slice, yet the Golang CI linter will complain about it and simply say the file is not fomatted:
// gofmt will be fine with this, but not golangci-lint myValues := []myType{ myType{ Foo: 1, Bar: 2 }, myType{ Foo: 3, Bar: 5 }, }So when you find you find yourself seeing a linter complain that a file that’s not formatted when it seems to be (maybe via an auto-format on save feature), try removing the redundant type name:
myValues := []myType{ { Foo: 1, Bar: 2 }, { Foo: 3, Bar: 5 }, }Maybe this is what the
-sswitch ofgofmtdoes (I haven’t checked). If so, I’m not sure why this switch is not set/available ingo fmt. -
Turns out I’m in the weights. They know I’m a software engineer, but not much more than that. Hilariously, Claude and Gemini think I’m a Swift developer and contributor. I guess the models have a problem recognising Go as a proper noun (or there’s a Leon Mika out there that’s a legendary Swift dev).
-
I’ve found myself using PTAL at work, as a shorthand for “please take another look.” And it doesn’t seem to be a very common shorthand in the circles I work in: I’m usually asked what I mean. Is it a well-known shorthand in other circles? The US, maybe? I picked it up from the Go project.
I’ve never so badly wanted to add a poll to this site until today.
-
I do wonder if the broader Go community would adopt the new UUID package. It’s purely additive so it’s not like they need to, but the strength of any one library package depends on how many people use it. There’s a lot of network effects involved. I definitely will make use of it, but if database client don’t, it will be quite disappointing.
I feel like they would though. There is some precedent of Go developers adopting new language features, such as threading
context.Contextcalls throughout the call graph. So my hopes are high. -
Found this gem of a remark in the documentation of Go’s time formatting string:
It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day.
Yeah, kind of wish we learnt from history on this one. 😼
-
TTL that h2c, the Go HTTP handler that allows for unencrypted HTTP/2 connections, does not do graceful shutdowns. When you call
http.Shutdown()on a server using this hijacking handler, instead of draining the active request, it just kills the server. The good news is that it’s now deprecated in favour of http.Protocols, which doesn’t have this problem. -
🔗 Blain Smith: Just Fucking Use Go
There are not enough “this"es in the English language I can add in support for this post.
-
Might be time to take another look at Zed. Got Go properly setup in it and used it to fix a small bug. I have to do something about the font, but it feels pretty featureful compared to the last time I looked. Shows some decent promise.
-
A gentle reminder that just because you have a coding agent, doesn’t mean everything needs to go through the coding agent. If something can achieved using a traditional command invocation, just use that. It’ll burn zero tokens and would end up being faster in the long run.
-
Could Swift's Guard Statement Work in Go?
Exploring the idea of a
guardstatement in Go reveals significant challenges and limitations compared to its implementation in Swift. Spoilers: it probably wouldn’t work. Continue reading → -
📘 Devlog
Imagen
A personal playground with image generation models (not related to Google’s Imagen model). Continue reading →
-
🛠️ Sky — an Elm-inspired language that compiles to Go
Kind of striking seeing Go becoming the target of other languages. Here’s another one. Looks a bit like Haskell to my eyes.
Via: Hacker News
-
🛠️ Lisette — Rust syntax, Go runtime
A little language inspired by Rust that compiles to Go
This looks really interesting.
-
It looks like Go’s getting a UUID package added to the standard library. Someone’s been reading my mind, or at the very least reading my blog. 😏
-
My Coolify instance has been running really slowly over the last few days. I may start looking at alternatives, or maybe go back to using Dokku.
-
Go iterators don’t have a built in way to send errors back, so I borrowed something from Haskell and made a “maybe” type:
type Maybe[T any] { Value T Err error } func (m Maybe[T]) Get() (T, error) { return m.Value, m.Err }The iterator pushes values wrapped in this, which would have
Valueset if one is available, orErrset if not. TheGet()method provides a convenient way to get both, allowing for patterns that look much like the following:func consume() error { for m := range myIter() { val, err := m.Get() if err != nil { return err } } doThingWithVal(val) } -
Had a go (heh) at making a Go iterator. It was simpler than I expected, once I got my head around how they work. It’s a push model, the iterator pushes value to a yield function, which sends it to
range, and receives a flag on whether to continue. The package docs do a good job explaining this. -
A bit frustrating that I asked my IDE to rename all instances of a method, and it did around half of them, ignoring the interfaces the type implements. I know Go interfaces are different to Java interfaces, but if the type checker passes already, rename things such that it remains that way.
-
Reason Go should add enums number 5,132: you’re not left up to runtime checks to verify that an enum value is invalid. You can rely on the type system to do that. It’s all well and good to implement marshallers and unmarshallers that verify that the input is a valid enum value, but that doesn’t stop developers from casting any arbitrary string to your enum type. And then what are you expected to do in your String() method (which doesn’t return an error)? Do you panic? Return “invalid?” Return the string enum value as is, even if it is invalid?
Making it impossible to even produce invalid types is the whole reason why we have a type system. It’s why I prefer Go over an untyped language like Python and JavaScript. So it would be nice if Go supported enums in the type system to get this guarantee.
-
Added my 👍 to the other 192 on this Go proposal to add generics to methods. Great idea! I’ve been wishing for this for a while.
-
It’s so satisfying seeing the run of a large Go test suite reveal itself as a tree when executed in an editor. IDEs should lean into this, allowing execution of subtests to any depth (not just the top + 1 level), and offering features like find.
