4 ms·
I haven't tried writing C(++) in ages, but what recall being a giant irritant was the tooling. Writing simple programs was fine enough, but the whole matter of
by jszymborski 3y ago
I haven't tried writing C(++) in ages, but what recall being a giant irritant was the tooling.
Writing simple programs was fine enough, but the whole matter of linking libraries and writing Make files was a headache.
- alexhutcheson 3y agoThis is a huge pain point. If you're writing small programs that fit in a couple files in a single directory, then you can get by with manual invocations of clang or gcc at the command line. If you want to build anything of moderate complexity, then you need to get familiar with all the complexity of a separate build system like Make/CMake/Bazel/etc. Java has a similar problem - once your program grows beyond ~1 directory, you end up needing to learn Maven/Gradle/etc. Build and testing tooling is one thing that younger languages have generally done much better. Rust, Go, Dart and others all have standard build tools integrated with the language that scale to large projects, with standard testing frameworks integrated with those tools. Scripting languages like Python have import features within the language itself. Much lower cognitive overhead.
- shrimp_emoji 3y agoAre you suggesting `cargo test` is somehow any simpler and nicer to use than `cd build/ ; cmake ../src/ && make -j100 && ctest`?
- theamk 3y agoThis is a huge pain if you want to support multiple systems, which most of the biggest products do. But if you (1) choose a single OS, (2) have "few" (say under 20) files and (3) rely only on OS-provided libraries, then things are actually pretty simple. For example, you only support Ubuntu 20.04 or Fedora 39. Then your makefiles are nice and easy to read, and you just rely on pkg-config for the libraries.
- whateveracct 3y agoI Nixify all the C I work with. It has good, automatic support for all the common tooling setups.