3 ms·

I wonder, have you considered D? Seems almost ideal to me for this kind of small tooling, and it's unlikely to break because of dependency version changes cause

by jhgb 4y ago

I wonder, have you considered D? Seems almost ideal to me for this kind of small tooling, and it's unlikely to break because of dependency version changes caused by the thirty-seventh party.

mgunyho 4y ago
Not really. The main reason for choosing Rust was to try it out, because it's the new cool thing. And I do find it really enjoyable. Rust is also trying very hard to keep dependency-related breakage to a minimum, and I think the Cargo ecosystem is doing a great job at that.
- jhgb 4y ago
  Fair enough; "I wanted to try out X" is always a valid reason. It's just that compared to C, things like Unicode support, argument parsing and JSON support are already part of D's standard library so no dependencies should be required for those.
nicoburns 4y ago
Rust is also unlikely to break because of dependency version changes caused by the thirty-seventh party. Despite similarly large dependency trees, the Rust ecosystem takes backwards compatibility much more seriously than e.g. the JavaScript ecosystem.
- jhgb 4y ago
  Well, I should hope so. Nevertheless every dependency removed completely removes even the possibility of such breakage.
  - nicoburns 4y ago
    I mean sure, but it means you have to maintain that functionality yourself. Often DIY implementations are not as robust as the versions in battle tested libraries with lots of eyes. So you can easily end up with more problems overall.
cillian64 4y ago
> unlikely to break because of dependency version changes caused by the thirty-seventh party. With rust you just check in your Cargo.lock file to your VCS and then the versions of your dependencies and their dependencies (etc) are pinned, so if it works now then it will always work. For dependencies on crates.io authors don’t even have the option to remove a version once it’s published. Upgrading dependencies is an explicit operation, so you only do it when required and run your tests afterwards. In practice I’ve had far fewer issues with dependency versions using rust than I’ve had using dynamic system libraries in the C/C++ ecosystem

by jhgb 4y ago

I wonder, have you considered D? Seems almost ideal to me for this kind of small tooling, and it's unlikely to break because of dependency version changes caused by the thirty-seventh party.

mgunyho 4y ago

Not really. The main reason for choosing Rust was to try it out, because it's the new cool thing. And I do find it really enjoyable. Rust is also trying very hard to keep dependency-related breakage to a minimum, and I think the Cargo ecosystem is doing a great job at that.

jhgb 4y ago
Fair enough; "I wanted to try out X" is always a valid reason. It's just that compared to C, things like Unicode support, argument parsing and JSON support are already part of D's standard library so no dependencies should be required for those.

nicoburns 4y ago

Rust is also unlikely to break because of dependency version changes caused by the thirty-seventh party. Despite similarly large dependency trees, the Rust ecosystem takes backwards compatibility much more seriously than e.g. the JavaScript ecosystem.

jhgb 4y ago
Well, I should hope so. Nevertheless every dependency removed completely removes even the possibility of such breakage.
- nicoburns 4y ago
  I mean sure, but it means you have to maintain that functionality yourself. Often DIY implementations are not as robust as the versions in battle tested libraries with lots of eyes. So you can easily end up with more problems overall.

cillian64 4y ago

> unlikely to break because of dependency version changes caused by the thirty-seventh party. With rust you just check in your Cargo.lock file to your VCS and then the versions of your dependencies and their dependencies (etc) are pinned, so if it works now then it will always work. For dependencies on crates.io authors don’t even have the option to remove a version once it’s published. Upgrading dependencies is an explicit operation, so you only do it when required and run your tests afterwards. In practice I’ve had far fewer issues with dependency versions using rust than I’ve had using dynamic system libraries in the C/C++ ecosystem