For example from this article:

> Karpathy: Classical software engineering would have you believe that dependencies are good (we’re building pyramids from bricks), but imo this has to be re-evaluated, and it’s why I’ve been so growingly averse to them, preferring to use LLMs to “yoink” functionality when it’s simple enough and possible.

Anyone who's heard of "leftpad" or is a Go programmer ("A little copying is better than a little dependency" is literally a "Go Proverb") knows this.

Another recent set of posts to HN had a company close-sourcing their code for security, but "security through obscurity" has been a well understand fallacy in open source circles for decades.

1. be table-stakes for a SDK from the cloud providers themselves

2. have the obvious home in a foundation like the CNCF; how else could you be "cloud native" afterall?

I checked my DNS logs and saw zero attempts to resolve `log.tailscale.com` having ran tailscale for many years (I added it to a blocklist anyway). From their admin panel, it appears "networking logging" requires paying for Premium[0], so it's not being used for free users (or Personal Pro).

Also, from looking at some source code (because the docs don't include this), I discovered you can disable logging for the macOS App Store client by doing:

     echo "TS_NO_LOGS_NO_SUPPORT=true" > ~/Library/Containers/io.tailscale.ipn.macos.network-extension/Data/tailscaled-env.txt

[0]: https://github.com/google/go-containerregistry/blob/v0.20.7/...

[1]: https://github.com/containers/skopeo

My poor memory seems to recall them gaining traction ~10 years ago, but they've fallen hard off my radar.

My fear with adopting a library like this for Go is actually that it might end up being very unfriendly to the profiler once bottlenecks start occurring.

Comments URL: https://news.ycombinator.com/item?id=45686010

Points: 7

# Comments: 1

> Code actions on save

There are command on save hooks which solve the problem for Go, but I could see this being not as applicable for other languages.

> Fuzzy search

Man, I'm pretty sure this shipped before telescope was particular stable or popular. Although, I don't recall if Helix originally used the ripgrep backend at first. They reworked it earlier this year and it was a massive improvement.

> Automatically updating buffers

+1 to this. I constantly suspend (ctrl+z) my editor and sometimes forget about it and could really use this prompt.

> File tree in browser

Space+e or Space+E opens a hierarchical file explorer on HEAD, but this is definitely relatively new

The video does also show off a cool "mineral oil test" to tell the difference, but probably is only effective if you had something to compare it against.

My takeaway though was that I need to thrift some Corningware, though!

1: https://youtube.com/watch?v=2DKasz4xFC0

I'd explicitly configure which servers were triggered which filetypes (aka autocmd and when I first started doing this, the binding for autocmd didn't even exist in lua yet) and have to bind lsp functions to keybindings across languages. FWIW, I have no idea what I would've done in vimscript, lua is a godsend with tables, loops, and lambdas. At this point in time, I was an early adopter neovim's built-in LSP and everyone else was recommending coc.nvim.

But the juxtaposition at the time was that Helix ships `languages.toml` that includes all of this already out of the box. You can override it, if you want, but actually all I wanted was cohesive keybindings for basic LSP functions.

What's the state of the world for neovim today?

I don't chase shiny new tools nor do I aspire to replace my toolchain with things just because they're built in Rust. I've used vim/neovim ~15 years. I don't use many TUIs (I actually can't think of any others besides my editor), but my development workflow is entirely terminal-based. I use native splits/tabs in my terminal emulator instead of screen/tmux/zellij. I spent years balancing having a minimal vim configuration that included plugins (but not compiled ones so that it was portable) but didn't include hundreds or thousands of lines in my vimrc. I'm excited to see how neovim is making progress with native LSP, but for years getting it working meant continuously tweaking vimscript/lua code or adopting a massive plugin written in TypeScript.

When I first tried Helix, LSP just worked; it read what was on the $PATH and used it. That's perfect because it solves for another source of annoyance: having different versions of tools for different projects. As the author notes, there are some LSP features that don't work with Helix, but whenever I dig into the issues, I almost always come to the conclusion that the issue lies in LSP being a VSCode monoculture rather than a deficiency in Helix itself. However, using the right version of a tool for a specific project and not spending any time configuring LSP servers were the top problems plaguing my usage of neovim.

If you're a vim user and you're concerned about muscle memory, by the first week I was proficient and by two weeks, Helix was the default in my brain.

I was a huge supporter of neovim -- I actually was submitting patches to the vim mailing list to fix vim on a beta version of macOS at the time taruda posted his original async patches that kicked everything off. If you had asked me the day before I tried Helix that you could reimplement a vim-like codebase from scratch well enough to abandon the original vim code, I would've agreed with you.

I've managed my dotfiles (12 different configuration files all compatible with cygwin, wsl, linux, macOS) for the past decade in a git repo with a 50 LOC shell script that creates symlinks for me in an intelligent way. What am I missing?

https://jzelinskie.com/posts/p-what/

[1]: https://www.quantamagazine.org/teenager-finds-classical-alte...

Comments URL: https://news.ycombinator.com/item?id=44957934

Points: 11

# Comments: 0

I'm a big fan of jq, having written my own jq wrapper that supports multiple formats (github.com/jzelinskie/faq), but these days I find myself more quickly reaching for Python when I get any amount of complexity. Being able to use uv scripts in Python has considerably lowered the bar for me to use it for scripting.

Where are you drawing the line?