Live data from Hacker News

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

github.com

51–60 of 87 posts

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

#51
I've used a similar tool, called dotter, by SuperCuber on GitHub. It's actually very similar--uses a handlebars template language and built in Rust. Definitely a must have if you're on multiple *nix systems and you've invested time into developing your configs!

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

#53
post #21
post #11

Earlier quoted context omitted.

I find Rust super ergonomic for any kind of app. The memory management aspect is trivial and second nature to anyone used to unmanaged languages, and the type system equally is not difficult to understand. It's a general purpose language, but it does give you full control. Plus, of course, you can encode a large amount of program states in the type system and borrowing checks enforce rules that programmers usually ha…

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.

As a counterpoint to the parent commenter, I like using Rust for personal stuff (like the project being linked to) for almost everything besides the memory model; I prefer Cargo to any other build tool I've used, and I like how I can eliminate boilerplate with stuff like Serde (for serialization), clap (for argument parsing), and even for how I'm able to write one-off macros to generate code for myself. The documentation for the language and tooling is great, and most packages have fairly good documentatio as well because any package published on crates.io will have it generated from the doc comments into a static site and hosted on docs.rs. The compiler error messages are better than any other language I've used, and at least for my personal use on Linux, I can easily compile with musl and get a fully static binary when libc is my only native dependency; I'm sure that Linux desktops are part of the "not many of those around" you refer to, but the same trick would work just as easily for any Linux server, and I do feel like there are plenty of those around!

If I could get all of those quality of life things in a language with a garbage collector, I'd probably use that for most things instead. Right now though, the closest options would be maybe OCaml or Swift, one of which doesn't really give me nearly as much in terms of quality of life stuff around documentation and tooling, and the other isn't nearly as streamlined to use on my platform of choice as I'd like, so I'm using Rust unless (or until!) something better for my personal projects comes along.

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

#54
post #53
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.

As a counterpoint to the parent commenter, I like using Rust for personal stuff (like the project being linked to) for almost everything besides the memory model; I prefer Cargo to any other build tool I've used, and I like how I can eliminate boilerplate with stuff like Serde (for serialization), clap (for argument parsing), and even for how I'm able to write one-off macros to generate code for myself. The documenta…

What issues do you run into with Rusts memory management?

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

#55
post #21
post #11

Earlier quoted context omitted.

I find Rust super ergonomic for any kind of app. The memory management aspect is trivial and second nature to anyone used to unmanaged languages, and the type system equally is not difficult to understand. It's a general purpose language, but it does give you full control. Plus, of course, you can encode a large amount of program states in the type system and borrowing checks enforce rules that programmers usually ha…

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.

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

#56

Earlier quoted context omitted.

Serious question: why not, if the author just knows Rust? Are you so allergic to anything written in Rust? Then get some new pills and ointments because there's going to be more and more of it.

The antibodies are probably to the "written in rust" addendum, which seems unnecessary unless rust adds something to the product. Much of the answer above to "why Rust" concerns the developer, and we are potential customers, so who cares? Just drop the "in Rust" and don't worry going forward. Honestly though I thought we were past the "written in Rust" phase.

It works. Including on me. I'm much more likely to pay attention to a tool that I know is written in Rust. This is both because I love the language and really enjoy using it, and because I've gotten conditioned to believing that tools written in it will be extremely robust, fast, useful, and stable. I can easily rattle off a dozen tools I use on a regular basis written in Rust that are significantly better than their non-Rust counterparts (starting with ripgrep, which is extremely fast). It's effective marketing still.

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

#58

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?

It's BEEN built so the price has been paid. I'm not going to complain that someone over-engineered a useful tool and got away with it.

I will say that rust is pretty damn productive once you organize your brain around ownership. I haven't had to mark a lifetime in over a month.

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

#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 back to .git.

It’s really just two “mv” commands, I can’t believe you need a tool for just that.

What am I missing out on?

Post reply on HN