Conversation

Notices

1. Embed this notice
   Natty :butterflyN: (natty@astolfo.social)'s status on Friday, 03-Jan-2025 07:27:37 JST Natty :butterflyN:

   @wyatt8740@tech.lgbt Ours is 8 gigs and we've built thousands of crates for like a dozen different projects
   
   I'm sorry but I don't see how cargo is some evil boogeyman while native package managers or CMake are suddenly saints

   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 03-Jan-2025 07:27:31 JST anna

     in reply to
     @natty @wyatt8740 but hating on cargo is not misplaced even if rust is good, cargo is not inseparable from rust, and ignoring it's many flaws because it's the defacto standard build system for rust helps no one
     
     rust would be so much better without cargo, which is why i'm hopeful for meson support, and for gccrs too because the mentality of the community around gccrs is different than the one around rustc
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Natty :butterflyN: (natty@astolfo.social)'s status on Friday, 03-Jan-2025 07:27:33 JST Natty :butterflyN:

     in reply to

     • anna

     @navi@social.vlhl.dev @wyatt8740@tech.lgbt Well we meant that indirectly, as in what language the package manager was for, and what it needed to get its job done

   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 03-Jan-2025 07:27:34 JST anna

     in reply to
     @natty @wyatt8740 cargo is awful at things any package manager should do tho, it's overly rigid and only really works for `cargo install` and *very* simplistic build requirements, but for some reason it's treated as the be all end all for rust building and packaging
     
     like 8 years later and we still can't install auxiliary files (like manpages) with cargo: https://github.com/rust-lang/cargo/issues/2729, packages constantly download c or c++ crates and build them ad-hoc in build.rs, cargo doesn't have the correct abstractions for a package manager, it isn't nearly as portable as meson/muon or even autotools, and cargo itself has nothing to do with memory safety, rust has, rust is quite the good language, cargo is awfully designed
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Natty :butterflyN: (natty@astolfo.social)'s status on Friday, 03-Jan-2025 07:27:36 JST Natty :butterflyN:

     in reply to

     @wyatt8740@tech.lgbt If you're gonna do systems or embedded, of course you'll prefer having more control, but hating on Cargo is misplaced if portable binaries, memory safety, and correct abstraction are not the goal to begin with :floofWoozy:

   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 03-Jan-2025 07:55:20 JST anna

     in reply to
     @natty @wyatt8740 there is no box, building c libraries in build.rs is not a box, not a solution, it's an ugly hack that breaks in the real world a lot
     
     that is the major issue, real systems are not neat boxes, they're messy, they need proper handling, cargo provides nothing for that, and at the same time, it *refuses* to play along with other tools. it wants control of the source tree but it does not want to do all the work necessary to interface with the rest of the world
     
     can't stick to doing simple binaries if your project doesn't ship only binaries, because those files can't be wrapped in a rust binary to begin with
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Natty :butterflyN: (natty@astolfo.social)'s status on Friday, 03-Jan-2025 07:55:21 JST Natty :butterflyN:

     in reply to

     • anna

     @navi@social.vlhl.dev @wyatt8740@tech.lgbt I mean yeah we know about the Fish thing, but I'd say it's valid to use something else for places where it is wrapping around complex native stuff, especially when many such quirky things are often C libraries with a safe Rust wrapper. Fish porting the platform-dependent stuff to Rust was bound to be a bumpy road
     
     But once you wrap the quirky stuff, you can essentially stick to doing these simple binaries just fine, and Cargo gets that done. Which is sort of the main point of Rust, isolating the dirty stuff in a box and using that box without having to know the insides of it

   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 03-Jan-2025 07:55:22 JST anna

     in reply to
     @natty @wyatt8740 cargo is only a good experience if you only write rust, with minimal interaction with other languages, without need of auxiliary files, and only for standard mainstream platforms, as support for conditional features based on platforms is also lacking, see "The Gripes" and "The Sad" on fish's rust port blog[1], which had to keep cmake in tree because of how inadequate cargo is as a build system / package manager
     
     i'm not even talking about dynlink because it's not even necessary, hare for example statically links libraries, but they don't vendor them, instead looks for them in HAREPATH, usually /usr/src/hare
     
     cargo only works well for developers that only need simple rust binaries and not much else, it's a design flaw, and one that after talking with many rust devs and lurking on many issues, the community seems to have very little want to fix
     
     1: https://fishshell.com/blog/rustport/
   • Embed this notice
     Natty :butterflyN: (natty@astolfo.social)'s status on Friday, 03-Jan-2025 07:55:24 JST Natty :butterflyN:

     in reply to

     • anna

     @navi@social.vlhl.dev @wyatt8740@tech.lgbt What Cargo does is pretty good in terms of development experience, but unless we have the tooling and abstractions for high-quality native library interoperability, we're doing this approach

   • Embed this notice
     Natty :butterflyN: (natty@astolfo.social)'s status on Friday, 03-Jan-2025 07:55:25 JST Natty :butterflyN:

     in reply to

     • anna

     @navi@social.vlhl.dev @wyatt8740@tech.lgbt Mmm not saying Cargo can't be blamed for issues, but many things Rust lacks to be used for aforementioned stuff like dynamic linking, Cargo isn't the limiting factor, and hating on it for areas where Rust is simply undercooked doesn't solve the underlying issues of the ecosystem that need work first, and since it has this vendoring paradigm, obviously it's hard to bend it to do stuff where dependency resolution is entirely different

   • Embed this notice
     argv minus one (argv_minus_one@mastodon.sdf.org)'s status on Sunday, 02-Mar-2025 20:00:21 JST argv minus one

     in reply to

     • anna

     @navi

     > it wants control of the source tree

     Um no. I have a Maven project with some Rust code, with pom.xml and Cargo.toml in the same folder. That works fine. Cargo DGAF that it's being invoked from another build system instead of directly, nor that the Rust sources are in a different folder than usual (because, again, there is both Rust and Java code in this project). It Just Works™, as Cargo usually does.

     @natty @wyatt8740

   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Sunday, 02-Mar-2025 20:00:21 JST anna

     in reply to

     • argv minus one
     @argv_minus_one
     
     cargo does want to control the *rust* part of the source tree, cargo does not play nice with other build systems that want to manage the *rust* part of the source tree.
     
     it's the whole reason meson couldn't "just wrap cargo" as rust people complained so much. it lacks basic options and flexibility required to be a proper secondary build system
     Haelwenn /элвэн/ :triskell: likes this.