Hacker News new | past | comments | ask | show | jobs | submit
amusingimpala75 | on: Migrating from Go to Rust
This is probably going to sound generic / repetitive, but my biggest complaint about Rust is the package management situation, which is entirely the result of the developer mindset. I love the ergonomics on the rust side (the functional approach to data types is beautiful), but I’m working on two projects side by side, one in rust and one in go at the moment. The dependency trees are entirely different beasts, with most of the stuff on the go project covered by the stdlib whereas I think the rust project is over 400 despite asking for just rusqlite (sqlite), clap (cli), ratatui (tui), and tauri (gui), the last of which is by far the worst offender but even without it, it’s still close on 100 which is crazy. If there were (and maybe there are, I just haven’t found them) decently maintained alternatives to the rust crates that actually have a sane dependency approach, I’d feel much better. I’m just trying to not shai hulud my system, and the rust-web people seem to want to turn cargo into npm in that regard.
praseodym | parent | next
Note that many Rust libraries consist of multiple crates, which all end up in the dependency graph. This makes the number of dependencies seem higher than it actually is: the separate crates have the same maintainers and are often part of the same upstream git repo.

I agree with the general sentiment though. Rust also has a lot of crates that are stuck semi-unmaintained at some 0.x version, often with no better alternative.

loading story #48261260
loading story #48261281
OtomotO | parent | next
The stdlib is the place where good ideas go to die.

And then you have httplib3 followed by httplib4.

In other words: I highly prefer the Rust approach.

It doesn't matter a lot whether I rely on the stdlib or another dependency to me.

It's a dependency after all.

People think just because it's the stdlib it's somehow better quality or better maintained, but these are orthogonal concepts.

In the end it depends solely on resources.

Sure, the stdlib may get more of these, but it may also grow fat and unmaintainable...

loading story #48261339
ViewTrick1002 | parent | next
> rusqlite (sqlite), clap (cli), ratatui (tui), and tauri (gui)

Does any language, except like Java, exist with a standard library comprising matching that?

Also, keep in mind that Tauri itself is 14 crates, where each one shows up in your build tree.

https://github.com/tauri-apps/tauri/blob/dev/Cargo.toml

And Ratatui is 6:

https://github.com/ratatui/ratatui/blob/main/Cargo.toml

loading story #48261636
awesome_dude | parent | next
Package management is the bane of nearly every language/technology

Nobody has "solved" it, and I don't think that there will ever be one (never say never, though, right?)

For Go we rely on developers of libraries to adhere to the semver versioning scheme accurately, and we cannot "pin" versions (a personal bugbear of mine)

There is a couple of workarounds - using SHAs not unlike the git commit hash to provide a pseudo version, and, vendoring (which is a cache of known dependencies - which brings with it cache management problems)

I had the misfortune of having to use Python with a virtual env on the weekend - it did not end well, and reminded me why I migrated away from Python.

Look at Perl (cpan) Java (maven, gradle) Ruby (gems) Go (dep, glide, vgo, modules) Rust (cargo) Node (npm, yarn, etc)

OSes too Redhat (yum, rpm, etc) Debian (apt) Ubuntu (snap - god why????)

And so on

loading story #48261305
repelsteeltje | parent | next
Interesting. I'm not very familiar with Go. What is the equivalent for Tauri in Go's stdlib?

Would it make sense to continue using Go for the frontend and doing only the backend in Rust for your user case?

loading story #48261083
JuniperMesos | parent
Why is it worse to import a number of other packages that provide exactly the functionality you need, than to have a large standard library that provides some but not all of the functionality you need, requiring you to still use some large dependencies?
loading story #48261509