Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

81–87 of 87 posts

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

#81

Post by pjmlp »

ninkendo wrote: post #79
pjmlp wrote: post #68

Earlier quoted context omitted.

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.

Nobody’s making a big deal about in it in this thread but you.

I beg to differ,

> Good dependency management, a rich package ecosystem, defaults to static binaries which are easy to distribute and a tendency to be fast (even if it’s just the lack of startup overhead) make it a popular choice.

> .....

> Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime.

Somewhere this thread....

And guess what, you can also ignore my comments.

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

#82

Post by ninkendo »

pjmlp wrote: post #81
ninkendo wrote: post #79

Earlier quoted context omitted.

Nobody’s making a big deal about in it in this thread but you.

I beg to differ, > Good dependency management, a rich package ecosystem, defaults to static binaries which are easy to distribute and a tendency to be fast (even if it’s just the lack of startup overhead) make it a popular choice. > ..... > Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime. Somewhere this thread.... And guess what, you can also ignore my…

People are using a term in a different way than you want them to.

They use static binary to mean “the dependencies I specify in my package manager are all put in the one binary, and it doesn’t require a separately installed runtime to run”, which is totally reasonable, and it is opposed to so many languages that don’t work this way.

You’re using static binary to mean “does not link to anything at all”, which on some systems results in worse portability, since the syscall interface is unstable and linking to libc/libsystem/etc is the only supported way to make syscalls.

You come into the discussion assuming definition B, ignore the fact that they’re using definition A, say that they’re making a big deal about definition B, etc.

There’s no confusion from anyone here but you. We all are using definition A. You’re the only one using definition B. It’s probably better if you just recognize that and move on rather than insisting everyone here is an idiot but you.

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

#83

Post by mubou »

rawkode wrote: post #3
cquintana92 wrote: post #2

Looks like we took similar approaches! https://github.com/cquintana92/dotfilers Congratulations, you too unlocked the "None of the hundreds that are out there work exactly like I want, so I'll write my own" badge.

Same. https://github.com/comtrya/comtrya

Saw the name "comtrya" and was immediately reminded of that episode of Stargate, but figured it had to be a coincidence. Cannot tell you how happy I was to see the gif in the readme :)

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

#84

Post by atoav »

glutamate wrote: post #6

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?

I write a lot in Python, but I love to write small utilities in Rust as well. The tooling around command line stuff is just really good in Rust and the distribution (just a binary) is just simpler. On top of that Rust forces you to handle errors with IO, like paths correctly to a degree that gives you much more confidence in the resulting tool.

Give it a try.

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

#86

Post by disnsn »

ninkendo wrote: post #55
pjmlp wrote: 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.

I agree that this is what many people -- including me -- are caring about.

However, it is not achieved in practice with "static" languages like rust and golang for me

I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries between different OS like Ubuntu and Fedora or even just different versions of the same OS

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

#87

Post by ninkendo »

disnsn wrote: post #86
ninkendo wrote: post #55

Earlier quoted context omitted.

> 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.

I agree that this is what many people -- including me -- are caring about. However, it is not achieved in practice with "static" languages like rust and golang for me I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries between different OS like Ubuntu and Fedora or even just different versions of the same OS

> I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries

Assuming you’re talking about rust binaries, this would only happen if your binary is using glibc symbols that don’t exist on an older version of glibc, and then try to run that binary on a system with the older glibc.

But glibc is a red herring here, because rust is only using libc to call syscalls on the host, because that’s how you’re supposed to do it on every OS, and that’s how you have to do it on every OS but Linux. (Only Go seems to want to implement their own syscalls on Linux.)

It’s a red herring though, because even if rust made their own syscalls and didn’t use glibc on Linux, you’d just fail with ENOSYS when these syscalls are used, instead of failing with undefined symbols at load time. If you try to run stuff that was developed against newer kernel features, on a system without these syscalls, you’re going to run into an equivalent issue. (You might get lucky and not need those syscalls in your app, but that’s not always going to be the case.)

Post reply on HN