Hacker News Reader

Comment by mr_mitm | Hacker News Reader

My impression is that it's the NodeJS, Go and Rust communities that don't care about XDG.

This 11 year old, open issue is very symptomatic of this IMHO: https://github.com/rust-lang/cargo/issues/1734

In my experience, the Rust community very much cares - it is a struggle to find a modern Rust application of any popularity that does not abide by XDG.

.cargo's placement is a historical mistake that can't be undone now, but ecosystem participants are generally good participants.

why can’t it be undone?

for new installations going forward, why not put the folder in XDG_CONFIG_DIR and an optional symlink from ~/.cargo that can be opted in

Not sure about use in the Go community at large but Go introduced os.UserConfigDir[1] which is portable across Windows, macOS, Plan 9 and Linux/BSD as per XDG back in 2019. Also CacheDir.

[1]: https://pkg.go.dev/os#UserConfigDir

> On Darwin, it returns $HOME/Library/Application Support

Which is not the behaviour most people would think is sensible, especially for CLI programs.

Ghostty has chosen to use that as the default and I feel like it's going to be the tipping point where people will assume $HOME/Library/Application Support is normal for CLI programs.

Mac users are used to checking ~/Library/Application Support/App, ~/.app, and ~/.local/config/app

fwiw, it absolutely drives me nuts that cli programs are putting configs in that hard to reach folder (long path name and _spaces_ in the folder name ugh)

Go isn't perfect, but $GOPATH isn't really used that much anymore. There's a bunch of stuff in ~/.config/ and ~/.cache/

Go creates `~/go` by default. It's not even hidden. Unfortunately, saying it's not really used that much doesn't help with this.

Reply on news.ycombinator.com