anttiharju

paint.net is amazing for basic png editing, I've dreamed of this day. It'a the only thing I miss from Windows. I don't understand the slashback at all.

defer isn't bullet proof either. I think there's a linter about it and os.Exit.

One can just wrap os.Exit in a helper to get the expected behaviour.

Context about tony the pony

https://stackoverflow.com/questions/1732348/regex-match-open...

oh, good catch! Point stands

I remember looking into the nodejs alternatives some years ago, one way to compare them is to look at the open issues. bun had so many hits for 'segfault' and deno has basically none.

Even now:

bun (zig) [1] 119 open / 885 closed

deno (rust) [2] 0 open / 1 closed

I don't think this has that much to do with Zig's anti-AI stance. More about using the right tool for the job.

[1] https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

[2] https://github.com/denoland/deno/issues?q=is%3Aissue%20state...

clap's derive is so nice

Really happy to see 0.16 come out.

I did a really tiny contribution about zig cc supporting -exported_symbols_list, which together with the hack of filtering out -liconv makes for a very viable linux -> macOS Rust cross-compiler. There's a few caveats but those have been manageable so far.

Absolutely in awe of Zig as a project.

I would second their experience, works well for me

What pains are you experiencing? Cdk has far exceeded Ansible and Terraform in my experience.

Github being less and less reliable nowadays just makes this more true.

In the past week I have seen:

- actions/checkout inexplicably failing, sometimes succeeding on 3rd retry (of the built-in retry logic)

- release ci jobs scheduling _twice_, causing failures, because ofc the release already exists

- jobs just not scheduling. Sometimes for 40m.

I have been using it actively for a few years and putting aside everything the author is saying, just the base reliability is going downhill.

I guess zig was right. Too bad they missed builtkite, Codeberg hasn't been that reliable or fast in my experience.

I think cdk is the one to use nowadays. Infrastructure as real code.

I've Fairphone 6 with e/OS. Works well. Ok, some caveats:

- mobilepay does not work (I think Danes have an issue with non-mainstream platforms for whatever reason)

- the default browser does not work for some of the authentication flows when it integrates as the in-app browser. But it does give one dark theme on hn so I can just keep it on my homescreen while fireflx is the default for compat reasons.

for office files one can also unzip and zip to store them in git as plaintext

I would like to live in less historical times.

I'm a Finn.

Tangentially; I keep finding I flag things accidentally due to mainly browsing on mobile.

Secrets that you store in github actions secrets?

What do you mean? Simple env prints get masked as *** in logs

I guess one can always just echo the secret to a file and upload-artifact it

Could be, not familiar with Bazel. Thanks for mentioning it now can check it out.

Second the Nix approach. One can even build a github actions-compatible container out of a flake and have actions run in it. I have done so for my personal projects https://github.com/anttiharju/compare-changes

One can get the ssh access with self-hosted runners but it is problematic because uncovering secrets becomes trivial.

> What is the advantage that github actions provide that people put up with it?

It's the default CI system on github and you get relatively free compute.

GitHub could invest a lot more in actions for sure. Even just in basic stuff like actions/checkout@v6 being broken for self-hosted runners.

Does this discredit the answer?

This also helps one to avoid the expensive macos runners

Issue is, op is trying to use matrix strategy when with cross-compiling they could avoid it. I have done it for https://github.com/anttiharju/compare-changes (which has nontrivial CI pipelines but they could be a lot simpler for op's needs)

Main issue is Rust. Writing catchy headlines about hating something may feel good, but a lot of people could avoid these pains if

- zig cc gets support for new linker flag that Rust requires https://codeberg.org/ziglang/zig/pulls/30628 - rust-lang/libc gets to 1.0 which removes iconv issues for macos https://github.com/rust-lang/libc/issues/3248

> i.e. the lack of a tight feedback loop.

Lefthook helps a lot https://anttiharju.dev/a/1#pre-commit-hooks-are-useful

Thing is that people are not willing to invest in it due to bad experiences with various git hooks, but there are ways to have it be excellent

> I can't imagine what type of upbringing I would have to have, to start thinking that "eating food" is an engineering problem to be solved.

I was really busy with my master's degree, ok? :D

> It's like a genie, take care with what you wish for.

I used to be stuck with this thought. But I came across this delightful documentation RAG project and got to chat with the devs. Idea was that people can ask natural language questions and they get shown the relevant chunk of docs for that query. They were effectively pleading to a genie if I understood it right. Worse yet, the genie/LLM model kept updating weekly from the cloud platform they were using.

But the devs were engineers. They had a sample set of docs and sample set of questions that they knew the intended chunk for. So after model updates they ran the system through this test matrix and used it as feedback for tuning the system prompt. They said they had been doing it for a few months with good results, search remaining capable over time despite model changes.

While these agents.md etc. appear to be useful, I'm not sure they're going to be the key for long-term success. Maybe with a model change it becomes much less effective and the previous hours spent on it become wasteful.

I think something more verifiable/strict is going to be the secret sauce for llm agents. Engineering. I have heard claude code has decent scaffolding. Haven't gotten the chance to play with it myself though.

I liked the headline from some time ago that 'what if LLMs are just another piece of technology'?

> Do you tho?

Recent success I've been happy with has been moving my laptop config to Nix package manager.

Common complaint people have is Nix the language. It's a bit awkward, "JSON-like". I probably would not have had the patience to engage with it with the little time I have available. But AI mostly gets the syntax right, allowing me to engage with it, and I think I've a decent grasp by this point of the ecosystem and even syntax. It's been roughly a year I think.

Like, I don't know all the constructs available in the language, but I can still reason about things as a commoner that I probably don't want to define my username multiple times in my config, esp. when trying to have the setup be reproducible on an arbitary set of personal laptops. So that for a new laptop I just define one new array item as a source of truth and everything downstream just works.

I feel like with AI the architetural properties are more important than the low-level details. Nix has the nice property of reproducibility/declarativeness. You could for sure put even more effort into alternative solutions, but if they lack reproducibility I think you're going to keep suffering, no matter how much AI you have available.

I am certain my config has some silliness in it that someone more experienced would pick out, but ultimately I'm not sure how much that matters. My config is still reproducible enough that I have my very custom env up and running after a few commands on an arbitary macbook.

> Does "picking up" a skill mean the same thing it used to?

I personally feel confident in helping people move their config to Nix, so I would say yes. But it's a big question.

> Do you fact check all the stuff AI tells you? How certain are you, you are learning correct information?

Well, usually I have a more or less testable setup so I can verify whether the desired effect was achieved. Sometimes things don't work, which is when I start reaching for the docs or source code of for example the library I'm trying to use.

> Struggling through unfamiliar topics, making mistakes and figuring out solutions by testing internal hypotheses is a big part of how deep, explanatory knowledge is acquired for human brains.

I don't think this is lost. I iterate a lot. I think the claude code author does too, did they have something like +40k-38k lines of changes over the past year or so. I still use github issues to track what I want to get done when a solution is difficult to reach, and comment progress on them. Recently I did that with my struggles in cross-compiling Rust from Linux to macOS. It's just easier to iterate and I don't need to sleep overnight to get unstuck.

> since these systems are fundamentally poisoned by their own talk,

_I_ feel like this goes into the overthinking territory. I think software and systems will still die by their merits. Same applies to training data. If bugs regularly make it to end users and a competing solution has less defects, I don't think the buggy solution will stay any more afloat thanks to AI. So, I'd argue, the training data will be ok. Paradigms can still exist. Like Theory of Modern Go discouraging globals and init functions. And I think this was something that Tesla also had to deal with pre modern LLMs? As in not all drivers drove well enough that they wanted to use their data for trsining the autopilot.

I really enjoyed your reply, thank you.