258 karma · joined October 14, 2018
No one claims their showels find gold for you.
With any model I've tried I've found it to be a huge pain to have it fix things where it made a wrong assumption without the code becoming a mess and burning a lot of tokens. I'm aware that not everyone works like this but I'm still very opinionated on what the end result should look like so I can still work on it without an LLM.
My workflow is usually:
- read file. I want to achieve X, how do? Do not implement anything.
- I would do a, b and c
- sketch a brief implementation of your suggestion
- <code> (not writing files yet)
- instead of your approach x, wouldn't it make sense to instead do z? What would that look like?
- <code>
- nice, implement this
- starts writing files, run tests, etc.
A welfare state maybe?
There was a time where I was often stuck for an hour with nothing but my phone and I kept copying file contents into chat for context so I made this and it works surprisingly well.
I made nixtml and I take no offence :)
Edit: although looking at this article it seems to be supported.
I really wanted the templates to just be nix functions. It shouldn't be an issue to pass the context to an external program with `pkgs.runCommand` or something and then read the result (IFD like you mentioned).
Edit: I'm glad to hear you like it :)
I didn't like the use of the word "pro-abortion". I generally address them as pro-life even though I don't like that it indirectly indicates that the other side would be "anti-life" but I agree that it's not productive to get into a flame war on terminology.
IMO using string templating for creating structured data in a white-space sensitive configuration language always ends with pain and cursing beyond the most basic application manifests. I'm not saying Terraform or HCL is necessarily the solution either but it certainly wouldn't be Helm in my book.
It's a shame language like CUE or nickel didn't take off for this.
My point is though that using string templating for YAML creation is IMO always a bad idea and using helm for anything more complicated than the most basic application always makes me sad in the end. helmfile adds another templating layer and my limited exposure to it made me really dislike it.
edit: I remember now that this was for rendering config for vector, which itself has templating support with the famous `{{ .key }}` syntax. So not entirely helmfile's fault, but I still stick to my point as I needed to get through 3 levels of templating.
The second, you can do this by setting certain options in the systemd service for your apps, but this is true for any systemd distro.
I thought I'd miss the infinite extendability of neovim with all my plugins and such but it didn't end up mattering to me and it was quite freeing actually to be just bound to what is supported in the core editor (as long as it's enough for you). I've been waiting for editorconfig support since before switching but it doesn't look like it will be merged into core.
Afaik there's plans to add plugin support using some custom lisp language which I'm excited about (I wrote all my neovim config in fennel).
But overall it's really fast and comes with essentials built-in like LSP and tree sitter support. There's some learning curve coming from vim in terms of key commands and such as helix is inspired by kakoune in that realm.
I don't think I did a really good job at convincing you but that's what came from my head quickly :D