6 ms·
rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better. It
by beeflet 11mo ago
rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better.
It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write.
I would like to use rust to write android apps. I don't really like the whole android studio java thing.
- gpm 11mo ago> I think cargo is better than cmake I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages). I absolutely agree if you aren't Google though.
- petcat 11mo agoYeah my understanding is that google has some sort of God program they use that can compile anything and has 10,000 command line options.
- kridsdale1 11mo agoIt’s https://en.wikipedia.org/wiki/Bazel_(software) https://en.wikipedia.org/wiki/Bazel_(software)
- kridsdale1 11mo agoGoogle3 uses Blaze which is an internal Bazel. And it’s fantastic. I like Facebook’s BUCK too but it’s basically the same thing. If I were to go to another company I’d promote using either of the above.
- vlovich123 11mo agoWhat does Android do for Rust?
- surajrmal 11mo agoIt uses Soong which internally calls rustc: https://source.android.com/docs/setup/build/rust/building-rust-modules/android-rust-modules https://source.android.com/docs/setup/build/rust/building-ru...
- ncruces 11mo agoAndroid uses Soong: https://source.android.com/docs/setup/build https://source.android.com/docs/setup/build Proprietary code uses the internal version of Bazel: https://bazel.build/ https://bazel.build/
- johnisgood 11mo agoI dislike Rust, but I would definitely prefer it over the "Android Studio Java / Kotlin thing", for sure.
- mk89 11mo agoI cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like. But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...
- dontlaugh 11mo agoAll three have very similar syntax when compared even to something like Python or Ruby, let alone ML or Haskell. Seems like a spurious complaint.
- gf000 11mo agoI mean, Rust is quite a different category than C or Go, if this is the 3 languages you reference. Rust has plenty of syntax coming straight from ML (okay, not straight, probably through OCaML) Pattern matching, destructuring, expressions everywhere, etc are stuff that C/Go never even heard about.
- baq 11mo agoNo need to like it. It isn’t brainfck and does the job.
- MBCook 11mo agoI don’t disagree, that’s part of why I like Swift so much. Rust looks very C++ to me. But if I was working in C++ and had a choice of C++ or Rust, I’d go Rust based on this.
- mk89 11mo agoAgree! Swift I forgot to mention. What a nice and elegant language.
- claudiug 11mo agoin the beginning I also hate it, but now is fine.
- 11mo ago
- tux3 11mo ago>I think cargo is better than cmake That is an understatement. I can't think of a build system that has spawned more attempts to find something better than CMake has. There have been so many people trying to make their own C/C++ build system and/or package manager out of sheer spite for CMake that it's frankly hard to keep track. In fairness to them and to CMake, it's not a simple problem to solve. To truly know CMake is to wish you didn't, that way someone else would have to maintain it.
- bluGill 11mo agoYou seem to forget about autotools. Cmake is ugly but I'll take it over autotools.
- danudey 11mo agoAs an end user: at least with autotools it's easy for me to see the available configuration options with ./configure --help in a nicely readable way. cmake has -LAH but it's still... kind of awful. At least it knows how to use ninja though.
- bluGill 11mo agoProblem is autotools doesn't work when cross compiling - the options are there but there is always something wrong, and it isn't easy to fix. cmake can at least get that right. Note that I cross compile a lot of code so this matters to me, if you just do the common thing autolools might work - but make would as well then.
- josephg 11mo agoYeah; generally I find CMake rules are much easier to read and modify than autotools and makefiles. With Makefiles there’s about 18 different ways to write a rule to compile something, and I find I need to go hunting through a bunch of files to figure out how this makefile in particular defined a rule for compiling this C file in particular. CMake is much higher level. I can just see all the higher level targets, and how they’re built. Then - orthogonally - I can modify the build system that CMake uses to compile C code. It makes a lot more sense. But I’d take cargo over any of this stuff. Cargo means I don’t have to think about compiler flags at all.
- WhyNotHugo 11mo agoCargo is absolutely awful. It might be better than cmake, but it still the worst part about Rust. It’s completely opaque, and intermixes a huge pile of different functionality. Distributing Rust software is the pain that it is mostly because of how Cargo works. It’s pretty much impossible to sanely distribute something that isn’t a headache for downstream to consume.
- ModernMech 11mo agoCan you expand on your reasoning? Because the opposite seems to be true when it comes to projects like uv. People love the single-file executable -- easy to just compile that for a platform and have your users download it. It seems like the uv project is having a good time with that model, so I think they show it's not "impossible". Maybe they're doing something different I'm not aware of? Or maybe your use case is different, so what's impossible about your situation?
- quantummagic 11mo agoIsn't it also the npm model?
- josephg 11mo agoCan you say more? I’ve found it a joy to use compared to CMake and friends. How does it make it harder to consume something downstream? Seems easy enough to me - just share the source crate. Are you trying to distribute pre compiled code or something like that? I can see how that would be harder - cargo doesn’t really support that use case. How would you improve cargo?
- WhyNotHugo 11mo ago> just share the source crate That’s a nice concrete example of something that sounds simple but is a nightmare. Let’s be clear: the goal is to distribute a tarball which the receiver can build. Crates won’t be packaged in the target host (that’s part of Rust’s design), so we don’t have any choice but to include them too. But there’s no simple way of gathering all of these. “cargo vendor” fetches all transitive dependencies for all platforms. So if any dependency supports windows, you end up with 400MB(!) of windows-only dependencies, even if your project doesn’t target windows. This makes “cargo target” useless. There’s “cargo-vendor-filtered”, a huge hack around this bug, but it’s also broke in subtle ways. In the end, if you want to distribute a tarball which a downstream can build, you can’t. Cargo works online only. Like I said: cargo is too opaque. There’s no command to generate a list of files that it would download for a build. There’s no command to fetch all “real” dependencies. It too opaque an monolithic, doing everything in one indivisible way. This is a great experience for the developer, but awful for anyone else.