oleg_log – Telegram
oleg_log
1.78K subscribers
1.85K photos
129 videos
9 files
2.76K links
Shelter for antisocial programmers "Oleg"

halp: @olegkovalov
web: https://olegk.dev
fov: @oleg_fov
chat: @oleg_log_blabla
podcast: @generictalks

about: https://news.1rj.ru/str/oleg_log/3200
Download Telegram
Suddenly I need to generate HTML pages in Go. Any good libs besides html/template ?

html/template works fine but I'm not a fan of writing:

languages: [{{ range .Langs }}'{{.Code}}', {{ end }}],


that in <noscript> isn't well parsed by VSCode (due to extra {{ and }}). Curious is there a better templating engine. Thanks in advance.
Hot take:

What if Claude generates tooooo much unneeded code just to waste your tokens and pay more?

🤔🤔🤔
at least this makes at least 1 PM happy 🫶
Meh, skills issue 🫳🎤

> A million ways to die from a data race in Go

https://gaultier.github.io/blog/a_million_ways_to_data_race_in_go.html
Guess how I found a new Go release? Yep, govulncheck ci job failed :(
Forwarded from 🇺🇦 Go performance channel (Oleg)
🥳 Go 1.25.5 and 1.24.11 are released!

🔐 Security: Includes security fixes for crypto/x509 (CVE-2025-61729, CVE-2025-61727).

🗣 Announcement: groups.google.com/g/golang-ann...

📦 Download: go.dev/dl/#go1.25.5

#golang
oof, 2022-03-03 is calling 😢

I'm always curious why someone is using outdated Go? I mean, I understand it's hard to migrate DB because of data but from my exp Go update is mostly bumping 1 line in CI config.

Yeah, there were rough edges but mostly everything was fine..weird.

AFAIR there was a problem with preemptive scheduler for cpu-intensive tasks (which happened in Go 1.14 not 1.16)
oleg_log
oof, 2022-03-03 is calling 😢 I'm always curious why someone is using outdated Go? I mean, I understand it's hard to migrate DB because of data but from my exp Go update is mostly bumping 1 line in CI config. Yeah, there were rough edges but mostly everything…
also, DRAFT Go 1.26 release notes

> The Green Tea garbage collector, previously available as an experiment in Go 1.25, is now enabled by default after incorporating feedback.
> The baseline runtime overhead of cgo calls has been reduced by ~30%.
> The compiler can now allocate the backing store for slices on the stack in more situations, which improves performance

sexy

https://tip.golang.org/doc/go1.26
oh cmon
Damn, VSCode becomes more and more overwhelmed with features.

Now the new auto-suggestions in the terminal. Afair there is no AI in termainal yet.

Time to move to VSCodium?
Any jj (jujutsu, new git, kinda) fans here? Do you really enjoy switching to the alternative?

Curious to hear any team/company improvements (if any lol)
> Gin is a very bad software library

And you know what? This is true. Like a bunch of other stuff.

https://eblog.fly.dev/ginbad.html
I might be wrong, but doing an incident review a month later feels way too late.

Sure, you note everything during the incident, so it’s all documented (lol) but c’mon.
You lose the context, you miss the ideas. It’s like looking at a picture full of dots with no lines connecting them.

I just don’t get it. It’s like performing an autopsy after the burial way too late, goddammit.
Apple Passwords, just whyyyy???
N900 <3

The most desirable phone of my childhood.

https://yaky.dev/2025-12-11-nokia-n900-necromancy/
I think I can confidently say that the following pattern is wrong in all cases. B ut it works… until it doesn’t.

{
...
for {
go process(...)
}

// some logic around atomicCounter waiting for a zero
}

func process(...) {
atomicCounter.Add(1)
defer atomicCounter.Add(-1)
}


Not convinced? Let's rewrite with sync.WaitGroup:

{
...
for {
go process(...)
}

// some logic around sync.WaitGroup.Wait()
}

func process(...) {
wg.Add(1)
defer wg.Done()
}


Even if this still doesn't convince you, this issue is documented in go vet:

https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/waitgroup

The problem is that atomicCounter is updated inside a goroutine that happens instantly but there is no real guarantee that this will happen instantly.
The runtime may schedule the goroutine later, so the counter might not be incremented yet.

Voila, now you've to debug why you missing data that was consumed but not processed!

And the fix is quite simple: any goroutine management should happen before the goroutine start:

{
...
for {
wg.Add(1)
go process(...)
}

// some logic around sync.WaitGroup.Wait()
}

func process(...) {
defer wg.Done()
}
I made smth (tbh, I just open-sourced 1 internal pkg), 3 funcs but used dozens of times across the codebase.

https://github.com/cristalhq/ordx

cmp := ordx.RankCmp([]string{"low", "medium", "high"})

fmt.Println(cmp("low", "high"))
fmt.Println(cmp("high", "low"))
fmt.Println(cmp("medium", "medium"))

// Output:
// -1
// 1
// 0


Fuzz and race tests are always welcome.
Gods Gophers gave you an arbitrary order of top-level definitions yet you still write code as if it were C :(

Or am I the one who prefers exported definitions first and unexported later?