12 ms·

Nice to see some level-headed anecdotes on the experiences of actually _using_ each language, as opposed to the usual "z0mg rustc fixez all yur mem0ry bUgz!!111

Nice to see some level-headed anecdotes on the experiences of actually _using_ each language, as opposed to the usual "z0mg rustc fixez all yur mem0ry bUgz!!111one" And, as someone who's spelunking in the depths of a large CMake project right now, cargo sounds pretty nice.

sophiabits 4y ago
Cargo is really nice! First party integration of developer tools is a big step forward and it’s nice to see it become more widespread (other examples include golang and Terraform) Bryan Cantrill has a number of talks about Rust which are similarly pragmatic
paulddraper 4y ago
Rust advantages are one third memory safety, one third types, and one third package management.
girvo 4y ago
Gosh I despise CMake. I despise it so much, I'm halfway through the process of extricating ESP-IDF from it.
- bluGill 4y ago
  I hate it too, but every alternative can't handle some dark corner of my build that just works in cmake.
  - jesse__ 4y ago
    Have you tried just using bash? (not a joke) I do this for personal projects and honestly, considering the alternatives, I think it rules.
    - bluGill 4y ago
      Bash cannot handle figuring out all my dependencies and how to run them in across howeverany CPUs I have. Nor can it handle all the different cross compile, static analysis, address sanitizer, and so on.builds I run.
    - dagmx 4y ago
      Bash doesn’t scale unless you build out an entire system to make up for all the things cmake does for you, and keep it up to date. Need to handle creating projects for multiple ides? That’s a pain with bash unless you make an entire library of tools. Need to handle finding libraries with all their transitive dependencies? Another set of tools. At that point you’d just have reinvented cmake in a different language. Out of curiosity, are you using bash for projects that are limited to just yourself?
    - delta_p_delta_x 4y ago
      I think the issue with CMake is exactly the issue with C++. There's a 'modern' way to do things, and a 'legacy' way to do things, and the respective designers of CMake and C++ have decided that it was—for several reasons—better to leave the 'legacy' stuff in the languages, rather than pull a Python and make a clean split. In 'modern' CMake, there are targets, and properties on said targets, i.e. compile and link options, C/C++ versions, libraries, headers, other custom dependencies, etc. There are also functions and generator expressions[1] to make control flow a little easier. On top of these, CMake's built-in `find-package` and `FetchContent` make package management a lot easier than it used to be. Want Boost? Just do `find_package(Boost)`, and then `target_link_libraries(<my_target> Boost::boost)`. It gets easier still with a proper C++ dependency manager like vcpkg or Conan. In legacy CMake, all these were set with global variables and there was no unified way to handle packages. I fully foresee going forward that at least a plurality of C++ developers will coalesce on a CMake + vcpkg (which has more packages than Conan) workflow. [1]: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html https://cmake.org/cmake/help/latest/manual/cmake-generator-e...
jcranmer 4y ago
Cargo is definitely a more pleasant build system than anything the C/C++ world has, until you fall off the happy path. One of the pain points of trying to design a build system for C/C++ is that a lot of projects do weird stuff that needs to be supported in build systems, which means you end up needing escape hatches to do that weird stuff all over the place. Cargo takes a narrower view, which means it doesn't attempt to do things like package things for install or handle multi-stage builds. It also has the advantage that things like running tests or package dependencies were built in from the start, so it doesn't have to try to support a million different tools that provide that functionality.
- pornel 4y ago
  I think Cargo is more of a social success than a technical one. People just agreed to use one standard tool, and that does wonders. Technically nothing stops C++ from having the same, except getting everyone to agree on one tool.

sophiabits 4y ago

Cargo is really nice! First party integration of developer tools is a big step forward and it’s nice to see it become more widespread (other examples include golang and Terraform) Bryan Cantrill has a number of talks about Rust which are similarly pragmatic

paulddraper 4y ago

Rust advantages are one third memory safety, one third types, and one third package management.

girvo 4y ago

Gosh I despise CMake. I despise it so much, I'm halfway through the process of extricating ESP-IDF from it.

bluGill 4y ago
I hate it too, but every alternative can't handle some dark corner of my build that just works in cmake.
- jesse__ 4y ago
  Have you tried just using bash? (not a joke) I do this for personal projects and honestly, considering the alternatives, I think it rules.
  - bluGill 4y ago
    Bash cannot handle figuring out all my dependencies and how to run them in across howeverany CPUs I have. Nor can it handle all the different cross compile, static analysis, address sanitizer, and so on.builds I run.
  - dagmx 4y ago
    Bash doesn’t scale unless you build out an entire system to make up for all the things cmake does for you, and keep it up to date. Need to handle creating projects for multiple ides? That’s a pain with bash unless you make an entire library of tools. Need to handle finding libraries with all their transitive dependencies? Another set of tools. At that point you’d just have reinvented cmake in a different language. Out of curiosity, are you using bash for projects that are limited to just yourself?
  - delta_p_delta_x 4y ago
    I think the issue with CMake is exactly the issue with C++. There's a 'modern' way to do things, and a 'legacy' way to do things, and the respective designers of CMake and C++ have decided that it was—for several reasons—better to leave the 'legacy' stuff in the languages, rather than pull a Python and make a clean split. In 'modern' CMake, there are targets, and properties on said targets, i.e. compile and link options, C/C++ versions, libraries, headers, other custom dependencies, etc. There are also functions and generator expressions[1] to make control flow a little easier. On top of these, CMake's built-in `find-package` and `FetchContent` make package management a lot easier than it used to be. Want Boost? Just do `find_package(Boost)`, and then `target_link_libraries(<my_target> Boost::boost)`. It gets easier still with a proper C++ dependency manager like vcpkg or Conan. In legacy CMake, all these were set with global variables and there was no unified way to handle packages. I fully foresee going forward that at least a plurality of C++ developers will coalesce on a CMake + vcpkg (which has more packages than Conan) workflow. [1]: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html https://cmake.org/cmake/help/latest/manual/cmake-generator-e...

jcranmer 4y ago

Cargo is definitely a more pleasant build system than anything the C/C++ world has, until you fall off the happy path. One of the pain points of trying to design a build system for C/C++ is that a lot of projects do weird stuff that needs to be supported in build systems, which means you end up needing escape hatches to do that weird stuff all over the place. Cargo takes a narrower view, which means it doesn't attempt to do things like package things for install or handle multi-stage builds. It also has the advantage that things like running tests or package dependencies were built in from the start, so it doesn't have to try to support a million different tools that provide that functionality.

pornel 4y ago
I think Cargo is more of a social success than a technical one. People just agreed to use one standard tool, and that does wonders. Technically nothing stops C++ from having the same, except getting everyone to agree on one tool.