Coming from fp background, I find Nix language very sensible. Especially for something like hermetic packaging.
The primitives for packaging in nix feel exactly like what they should be. When you look at a definition, the things that piece of code could do in principle (and things you could do with it as a consumer) tend to cleanly match it's semantic purpose and its responsibilities. So a lot of things are self-documenting.
Was there a reason these features were not accepted to upstream Immich and needed to be in a fork?
Looking at the latest commits, Noodle Galery has many signed with Claude, but Immich doesn't. Is LLM policy a reason for fork? (Just speculating, I don't know.)
UPD: Immich has this in CONTRIBUTING.md, seems like its LLM policy is more strict:
> We ask you not to open PRs generated with an LLM.
vs. Noodle Galery:
> We actively encourage the use of LLMs and AI coding tools.
It also even easier to get working and integrate into your system in a sustainable manner with NixOS. Do it by hand or throw an LLM at it, it will get you a declarative patch for your NixOS config that brings llama-cpp into your config that you can review and add under version control (no random `make install` build artifacts contaminating your system, no wondering "what was it that I ran? what are all these files? how do I do the same with a newer version?" a couple months later). There's also likely some build cache where Nixoids have already build what you want.
I had a great experience with llama-cpp with Nvidia backend on NixOS.
What concrete arguments are there to believe in your talent hypothesis instead of their tool hypothesis?
A couple more comments like this from you, and I'll be able to say, "cyanmoonx has a history of blaming the talent rather than bad tools". There being a history like that is neither an argument for nor against tools being bad. And also, don't forget that bad tools and bad talent don't rule each other out.
Claude code is just pool quality. They don't make how this thing will behave clear to the user, or give control. They fail at anything that needs an abstraction or model, not just APIs and shell scripts glued together. And "just ask AI" seems to be the default fix.
That vibe coding they brag about as if it was a good thing, it shows.
Take their notation for describing permissions. The docs are not comprehensive, and in practice it doesn't quite work how they describe it.
Or their management of sub-agents. I once lost a sub-agent, it finished and disappeared from UI. Apparently, you can't bring it back yourself: you have to ask the parent agent to do it for you. But the parent was Fable, and I ran out of credits, so I was locked out of using my opus sub-agent because of it.
Or an even more grotesque example: when you paste your claude API token to authorize, it covers characters with *. But it seems like an LLM has hallucinated a limit of API key length and the tail of your key stays visible.
What amazes me is how, for a vibe coded product where all they have to do is use their AI to fix things ... NOTHING EVER GETS FIXED!
I've probably gone to file 20 bugs. In all 20 cases there wasn't just one issue already filed for it: there were several, each which had a bunch of upvotes. And in all 20 cases ... every. last. one. ... Anthropic closed the ticket with no comment.
IF YOU ARE GOING TO HAVE A SHITTY VIBE CODED PRODUCT, AT LEAST USE YOUR SHITTY AI TO FIX THE SHITTY PROBLEMS!
I mean. This is what happens with vibe-coded projects. When there's no actual software engineering going on, I wouldn't expect anything better than this.
What is a "document editor"? I edit my documents in Kakoune, and send a PDF. Where is that history supposed to be?
About your actual point: can you also make AI actually say things and have something to say, and not just try to imitate someone who is trying to get a point across?
I'm not catching students, I'm reviewing comments in code and documentation written with AI. I even wish it would convince me and try not to notice it, but I can't. I'm pretty sure I'd fail AI generated slop, not for cheating, but for nonsense.
Ps. You didn't write that comment with AI, did you?
> So is for Go developers who want systems-level control without learning a new language. And for C programmers who like Go's safety, structure, and tooling.
Wut?
Also, how do you preserve garbage collector semantics without garbage collector?
- Everything in the language is statically allocated or stack-allocated. You have to call a malloc / free function to get heap allocated things
- The language is not memory safe (you can't return slices, pointers, or interface types from a function if the thing was created inside the function, unless you used heap allocation)
- Interfaces (the only variable size struct Go has) are implemented by creating a struct of function pointers. Arrays and maps (the non-struct variable size types) are implemented as stack-only and maps are limited to 1024 keys. You can opt into heap-based arrays / maps in the standard library to bypass this.
Been a while since I used go but I remember it being kind of uniquely hard to tell? Like a struct is on the stack, but a *struct is maybe on the heap, depending on escape analysis?
In go you don’t need to care, the GC will take care of allocations on the heap and the runtime will choose when something should go on the stack. That’s the problem: in this other language it’s suicidal to program as if it was the same as Go as you will just make huge mistakes like returning a pointer to a local variable.
In C you explicitly malloc things onto the heap. In go, taking the address of something maybe allocates on the heap, or maybe not if escape analysis can keep it on the stack.
As far as I understand co-routines help don't really help with memory shared across go-routines. They only help in the fact you need to manage spawning and joining threads, making it easier to do stuff in parallel. But they don't provide thread-safety.
edit: I suppose you don't get segfaults or buffer overflows and the sort in go for accessing memory in a parallel context, you get recoverable panics. But that is still not really thread safety in my opinion, it is memory safety.
What was your methodology and structure in making the prompts for the rewrite? Did you let the LLM roam in all of the codebase and tests from the beginning, or revealed things to it gradually in some way?
Regression tests start to play a different role with LLMs.
On one hand, they give an LLM a short feedback loop to correct itself, and iterate fast when writing code. A human also uses it as a feedback loop, but we don't iterate as fast and don't handle big walls of conditions, so its effect is not as big.
On the other hand, LLM's ability to handle a big wall of if-conditions can backfire if it starts taking shortcuts and taking the tests-as-a-spec too literally, overfitting the solution, overly focusing on the given datapoints (conditions checked by tests) and missing the overall behavior shape that the tests intend to pin down. For humans, this is less of a concern because we are bad at big walls of if-conditions, and we'd rather try to see the original shape that the tests are pinning down than monkey-patch the solution to fit the individual points.
It's interesting to see how one balanced these two. In this case particularly. Maybe you could play around with separating the data you give an LLM into "training set" and "validation set", training set can be seen fully, but validation set is hidden and is only queried when the solution is deemed ready. Say, training set = original source code + half of the tests; LLM uses that for quick feedback loop. And validation set = the remaining half of the tests; test code is not shown to the LLM and run only when the LLM says it's done to catch potential overfitting of the resulting solution over training set.
To me, the credibility of a solution like that would depend on what methodology the authors used. If they just let the LLM see all tests, I'd be skeptical (albeit unable to point out specific bugs due to the volume of work and LLM's ability to make bad things look trustworthy). The good thing is, real-life use will add new, unseen before datapoints for testing — so validation set will build up with time. Really curious to see how it will work.
I don't in ow if I'd say it's "easy". The Python ecosystem in particular is quite hard to get working in a hermetic way (Nix or otherwise). Multiple attempts at getting Python easy to package with Nix have come and gone over the years.
The primitives for packaging in nix feel exactly like what they should be. When you look at a definition, the things that piece of code could do in principle (and things you could do with it as a consumer) tend to cleanly match it's semantic purpose and its responsibilities. So a lot of things are self-documenting.
reply