anttiharju

Zsa voyager is low profile, you aware of that?

Happy user for 1+ year here

Responding to an anecdote with another is fair I suppose

> This already the case today, you can't run your bank's app or government eID apps on anything but Google or Apple devices.

Fairphone 6 with e/OS begs to differ. Dutch phone with a French OS. No issues.

Love the writing style

I think most of the pain with GitHub Actions goes away if you use actionlint, action-validator, prettier/yamlfmt in a single ci job to validate your setup. Can even add them as git hooks that automatically stage changes and give quick feedback when iterating.

Or just use composite actions, it's not 2020 anymore.

Templating GitHub Actions is very powerful (I've worked with such a setup) but it has its own headaches and if you don't _need_ custom tooling better to not have it.

I can wish for improvements on the native setup without reaching out for the sledgehammer.

I think YAML anchors in GitHub Actions are very welcome, for example for DRYing the push/pull_request 'paths:' filters [1].

Now only if they supported paths filter for `workflow_call` [2] event in addition to push/pull_request and my life would be a lot easier. Nontrivial repos have an unfortunate habit of building some sort of broken version of change detection themselves.

The limit of 20 unique workflow calls is quite low too but searching the docs for a source maybe they have removed it? It used to say

> You can call a maximum of 20 unique reusable workflows from a single workflow file.

but now it's max of 4 nested workflows without loops, which gives a lot of power for the more complex repos [3]. Ooh. Need to go test this.

[1] https://docs.github.com/en/actions/reference/workflows-and-a...

[2] https://docs.github.com/en/actions/reference/workflows-and-a...

[3] https://docs.github.com/en/actions/how-tos/reuse-automations...

I wish it'd be easy to plug it to a s3 backend and thumbnails etc. ephemeral things could just be on disk.

I think people should do/go where they have a peace of mind, whatever that place may be.

Nokia (mostly networking-related things nowadays) touts - or at least used to, haven't kept up to date - itself as one of the most ethical companies around.

> But isn't that true for every big corp, or even every public company?

So I suppose not really, no.

Additionally companies working on carbon-free energy might also serve as evidence. There are some big ones around.

Unity Ads have been a thing long before (2014) ironSource merger (2022)

https://unity.com/news/unity-technologies-acquire-applifier-...

https://unity.com/blog/news/welcome-ironsource

I've also been eyeing Rust, but coming from Go where you can build more or less complete cli tools with just the standard library I'm not overtly exited by occurrences like this.

From what I've seen Rust projects seem more or less node-esque in the sense that people just keep pulling all kinds of dependencies, not necessarily even understanding them that much. Like apparently serde the library is responsible for most of the slow compile times people associate with Rust, because deserialization/serialization is kind of a common thing to do in an app.

Happy to be corrected on my statements, not 100% on anything.

edit: apparently the behaviour in Go std library is the same, heh https://news.ycombinator.com/item?id=45022680

Linters that catch any silly mistakes. Shellcheck, actionlint, action-validator, prettier, ... coupled with automated release process. I find that when merges break due to trivial issues I lose motivation. Also Lefthook with stage fixed is a lifesaver.

I don't doubt any of that but why stick to such old conventions when there are explicit and immediately clear options?

I don't think me writing an if condition

if boolean != true

instead of

if boolean == false

should pass code review. I don't think my pet peeve is necessarily different from that. I understand there's a historical convention but I don't think there's any real reason for having to stick to it.

Hell, some of the other compiler options are flags with no 0 or 1, why could this not have been --static or any flag? I'm genuinely curious.

Moreover, 0 here maps to false but in program exit codes it maps to success which in my mind maps to true but then we have this discrepancy so it does not appear to be the right mental model.

I've no issues with boolean logic (&&, ||) but unfortunately all my schooling has done those with the notion of true/false instead of bits iirc.

At least in the case of cgo_enabled it does define the default behaviour

pydantic?

My pet peeve is CGO_ENABLED compiler option in Go. It's set to 0 or 1 to enable/disable (can never remember which mapa to which)

If it was just CGO=true or CGO=false I think so much confusion could have been avoided.

I think similar thinking applies here. It's convoluted to disable something by setting ai_disable=true because I read it like: setting false true instead of just setting boolean.

https://flox.dev is pretty great

Curious about whether you're aware of https://www.aitofit.io/en and how your app compares to it

I suppose I phrased this poorly. Stack traces are useful indeed. I guess what I like that usually wrapped errors are bit more thoughtful, stack traces can look a bit like "vomit".

Posted this because of the other Go error handling post today https://news.ycombinator.com/item?id=44171677

I like error wrapping. I've worked in codebases where systems had to be debugged by piecing together individual log lines. With error wrapping I can usually see the exact path that lead to the error in one line.

I was actually bit scared, so read through the whole post and am happy with the conclusion.

Go is very readable in my experience. I'd like to keep it that way.

With `brew install go`

and

module github.com/anttiharju/vmatch

go 1.21.0

toolchain go1.21.1

I still get a binary that claims to be built with the latest version of Go instead of 1.21.1 or .0

vmatch has version 0.1.6+dirty built with go1.24.3 from 83c9aa83 on 2025-05-25T18:43:30Z

I think this is a problem for me. Go 1.22 did a breaking change with the for loops for example https://go.dev/blog/loopvar-preview.

I see that I can change it with a command like `go env -w GOTOOLCHAIN=go1.21.1+auto` but then again I'm doing something I don't want, managing the version.

Perhaps I'm missing some config.

It's a helpful link, thank you. I think I need to play with toolchain more. Last time I checked I think there was some corner case that was not covered but I could be wrong.

On https://github.com/anttiharju/vmatch as a hobby. It's starting to get to a workable state, I'm using it to manage Go and golangci-lint for the project itself. It even works with the Go vs code plugin.

I think many version managers make things unnecessarily difficult, especially if one hops from one repo to another. vmatch automatically uses and installs the right versions.

Everyone needs hobbies

Do you think https://github.com/openai/CLIP can be ran on it? LLM makes me think of chatbots but I suppose because it's inference-based it would work. Somewhat unclear on what's the difference between LLMs and inference, I think inference is the type of compute LLMs use.

I wonder if inference-d would be a fitting name.

I wonder if this is preferable to kServe

Enforce on CI. Autofix in pre-commit hooks. Lefthook is fantastic for this.

Example config: https://github.com/anttiharju/vmatch/blob/9e64b0636601c236a5...