Live data from Hacker News

A cross-platform multi-target dotfiles manager written in Rust

github.com

61–70 of 87 posts

Re: A cross-platform multi-target dotfiles manager written in Rust

#61

Serious question: why Rust? Sounds like this is not exactly systems level programming or any user would suffer from or even notice garbage collection latency. Is Rust building up a decent ecosystem now for application programming? When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?

The primary purpose of Rust is to write Rust. It is only the secondary purpose to actually write useful things.

One thing your comment has in common with it then ;-)

Re: A cross-platform multi-target dotfiles manager written in Rust

#62
post #60

Dumb yet serious question : what problem is a dotfile manager even trying to solve? Personally I have a git repo in my home directory and just commit dotfiles to it. The only drawback is that git always think there’s a git repo no matter where I am in my home, so I usually rename the .git folder to .git_hidden. And on the (rare) occasion that I want to update one of my dotfiles I just rename the .git_hidden directory…

I recently learned it. I have personal and work laptops (two work laptops as of now for different companies). 90% of dotfiles should be the same. But rest is pain to sync. I’m using chezmoi that has templating mechanism that helps me.

Re: A cross-platform multi-target dotfiles manager written in Rust

#63

Serious question: why Rust? Sounds like this is not exactly systems level programming or any user would suffer from or even notice garbage collection latency. Is Rust building up a decent ecosystem now for application programming? When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?

Rust is a popular choice for CLI tools as well as Go and I do think the ecosystem is picking up. In fact there are a bunch of them for the terminal. https://terminaltrove.com/language/rust/ https://terminaltrove.com/language/go/

I've used both, and they are comparable in library support. I happen to write _much_ faster in Go, so it's usually my default choice for CLIs, unless I specifically need to bridge with another Rust program.

Re: A cross-platform multi-target dotfiles manager written in Rust

#67

Why no MacOS support if you claim cross-platform? That's not honest.

It's still cross platform, just across Linux and Windows, doesn't look dishonest. It's similar to other "linux/macos"-only tools that also call themselves cross platform. The baffling part though is recommending using homebrew to install it on linux.

> The baffling part though is recommending using homebrew to install it on linux.

Do they really? Probably AI-generated.

Re: A cross-platform multi-target dotfiles manager written in Rust

#68
post #21

Earlier quoted context omitted.

As someone used to unamaged languages since 1986, and with a major focused on systems programing, it isn't that clear cut. Rust executables are only 100% static on OSes that expose system libraries as static libraries, and there are not many of those around, outside embedded systems.

> Rust executables are only 100% static on OSes that expose system libraries as static libraries This seems to be a weird hair to split. GP clearly means “a single executable you can run on any install of the target OS without dependencies.” Whether it’s a truly honest-to-goodness static binary that don’t link to libc or libSystem or whatever is important to approximately zero people, outside of internet pedants.

It is, because so many folks make such a big deal of how using computers as they used to be until early 1980's, with single static linking model.

Ironically the same folks don't see to appreciate how object files and binary libraries work in static linking, lets make it even better compiling always from source.

Re: A cross-platform multi-target dotfiles manager written in Rust

#69
post #60

Dumb yet serious question : what problem is a dotfile manager even trying to solve? Personally I have a git repo in my home directory and just commit dotfiles to it. The only drawback is that git always think there’s a git repo no matter where I am in my home, so I usually rename the .git folder to .git_hidden. And on the (rare) occasion that I want to update one of my dotfiles I just rename the .git_hidden directory…

FWIW, you don't have to do that rename dance; git allows specifying the name of the .git metadata directory via `git --git-dir=$HOME/.git_hidden ...` or `GIT_DIR=$HOME/.git_hidden git ...`

I don't know how big your .gitignore must be when trying to use a tool that wants to own every file and directory to manage your /home but if that works for you, more power to ya

Re: A cross-platform multi-target dotfiles manager written in Rust

#70

Serious question: why Rust? Sounds like this is not exactly systems level programming or any user would suffer from or even notice garbage collection latency. Is Rust building up a decent ecosystem now for application programming? When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?

As a user, if I have the choice between 2 apps, I’ll strongly favor a Go, Rust or ANSI C app over a Python, Ruby, Shell or C++ app.

This is because empirically, they usually work better, feel more polished, faster and I can easily contribute patches if I need. If a tool is written in Python, I’ll go out of my way to find a rewrite in another language.

Post reply on HN