5 ms·
Based on another thread - I think the following topic should be an interesting one for HN to chew on: If someone wanted to write systems type of programming (wh
by sgt 5y ago
Based on another thread - I think the following topic should be an interesting one for HN to chew on: If someone wanted to write systems type of programming (whether it be embedded or Unix tools or even writing a library), should they go for C (C23) or Rust today?
- bruce343434 5y agoI'm going for C, because I am experienced with C and despite it being more tedious, with having to do everything yourself, I stick with it because the compile times, and in fact the compile process, are so much faster and simpler. I really enjoy the direct feedback I can get. I considered C++ but that too had terrible compile times. Ideally a debug build should simply not take longer than 100ms for a codebase that isn't even 5KLoc, and only C seems to be able to offer that experience.
- gefhfffh 5y agoI get that the compile process is faster, but simpler? In my experience, the compile process usually consists of "cargo build" A advantage of Rust is that usually you spend way less time debugging, because the compiler prevents many mistakes from compiling in the first place.
- bruce343434 5y agoI have an IDE with clang-lint and I find that it can spot pretty much every mistake. It can even detect some lifetime issues. Other than that my programming style is very much pass-by-value, trust the compiler to inline it, so the typical memory safety issues are simply not relevant to me.
- pornel 5y agoPass-by-value and let LLVM clean it up is also the idiomatic Rust way. rust-analyzer is pretty good for IDE integration, and it will catch way more than clang-lint (global lifetime analysis with guaranteed correctness, not just best-affort local, and thread safety/data races). Regarding compile times, Rust has a different approach. Instead of a fast cycle of run and see if it broke, it's more of following compiler nags until the program is correct and runs on the first try. Incremental (cached) compile times aren't too bad these days.
- gefhfffh 5y agoBefore I tried Rust (I got sick of it and the slow progress of Herb Sutter's research), I have used CLion with clang-tidy and had plenty of memory issues going undetected. Needless to say I didn't restrict myself to pass-by-value (compatible -> structs with ptrs are problematic as well) style, which seems quite restrictive
- pjmlp 5y agoWith current ISO C++ velocity and the stance to keep doing language evolution in person meetings, I don't think Herb's proposals will ever come to be, and even if they do, it won't matter when they most likely can only make it post-ISO C++26 with best efforts.
- flyinglizard 5y agoWhy does it matter if compile time is 100ms or 300ms? At even a second, that’s going to be so negligible in the context of code-compile-debug work. Especially if something like a flash download is involved.
- bruce343434 5y ago0. it is a noticeable delay and impinges my momentum 1. A flash download is not involved 2. I hardly debug. I seem to be in a minority here, but my linter really does catch pretty much everything. I don't blindly write code, I always ponder my approach first. So basically, the compile times pull me out of the flow.
- zh3 5y agoVery much with you on this one. Even with 50k+ LoC a 'make clean;make' takes less than a second (with help from ccache and a RAM disk). It effectively gets the compiler out of the way and keeps the thought processes continuous. One trick I like is to have a 2nd terminal watching the file(s) I'm editing, triggering a make/run on each save; building and running is then a single keypress away:- while [ 1 ]; do inotifywait -e move_self foo.c cc foo.c -o foo && ./foo # or 'make && ./foo' done
- OJFord 5y agoAre your rust builds really that fast? Wth am I doing wrong! I'd love to measure it in seconds.
- jamincan 5y agoIt's slow for me, but I'm not working on a very powerful machine. That said, cargo check is fast, and my general experience with Rust is that it generally works once it compiles. People getting into more advanced features might have different experiences.
- flohofwoe 5y agoThe compilation time difference between C and Rust for nontrivial projects is much bigger than 3x.
- dureuill 5y agoYou could get productive in Rust in 3 months max, and then the productivity gains would quickly outweigh the initial investment
- donkarma 5y agoRust code takes longer to write than C code
- dureuill 5y agoMy experience is mainly with C++, but from my own evaluation I'm x2 to x3 more productive overall in Rust than in C++. The reasons are a simpler build system that makes using the ecosystem faster, more expressive type system (iterators with combinators, sum types), the safety part that allows to not accidentally introduce UB and to not waste time with static and runtime analysis, shortening debug and review time. This compounds over time to give a better maintenance time. I don't have a similar evaluation for C <-> Rust, but I suspect the result would be even more skewed in Rust's favor: sure, you might be writing individual lines faster in C, but the lack of iterators, generics, traits and RAII, and the relative difficulty to use dependencies means that you will waste a lot of time reinventing the wheel, often suboptimally.
- drran 5y agoTotal time of «coding + debugging» (development time) is shorter for safe Rust, because Rust eliminates few classes of errors. Unsafe Rust and C are same, but Rust have better abstractions (match operator, Rust enum's, typed macros, etc.)
- pornel 5y agoIt does for a novice. But once you learn Rust, it's actually quite productive. Rust has proper collections, strings, iterators, automatic (but not GC) memory management, error propagation, etc. This eliminates a lot of busywork, and makes Rust "denser", so you write less code, but get more done.
- hyperman1 5y ago
- CyberRabbi 5y agoI’m going for C because programming language choice is a matter of personal preference in essence and Rust annoys me.
- sgt 5y agoHow does it annoy you? Development velocity, creativity hinderance?
- CyberRabbi 5y agoVisually it’s annoying. It’s like the comic sans of programming languages.
- sgt 5y agoI used to code Perl in the late 90s. To me it doesn't look /that/ bad.
- CyberRabbi 5y agoIf rust is comic sans then Perl is wingdings, so yes, it could be worse.
- sgt 5y agoHilarious
- adrianN 5y agoI don't think that can be answered in general. It depends on what exactly you want to do and the maturity of the libraries in that area, and how security critical your application is.
- dureuill 5y ago> the maturity of the libraries in that area, While true for C++ which is not very interoperable, C being very interoperable means that there is no advantage into using a C API from C rather than from Rust. > how security critical your application is. Rust also has productivity and general "correctness" advantages that go beyond security (although yes that alone is a factor)
- pkrumins 5y agoDefinitely C!
- dureuill 5y agoIn general, I think they should go for Rust. See [1]. Now, embedded is a special case. You need platform support, and possibly certification, none of which are a given in Rust today. Arguably, not in C23 either at the moment, though. [1]: http://cliffle.com/blog/prefer-rust/ http://cliffle.com/blog/prefer-rust/
- pjmlp 5y agoNeither, unless we are speaking of kernel and drivers kind of systems programming, in which case I would pick Rust. For anything else, a language with automatic memory management.
- mhh__ 5y agoD is a better modern C than Rust. Rust is very nice, but if you just want a safer C that will actually make you more productive versus less productive until you understand how rust wants you to program then D is a better fit.
- Koshkin 5y agoAgree. "A better C" than C++ claims to be.
- rixed 5y agoC, because I don't know how to do intrusive data structures in Rust.
- int_19h 5y agoThere's also Zig to consider here, and it arguably competes more directly and explicitly with C than Rust does.
- elcritch 5y agoNim with ARC works really well for embedded or writing system tools. Compiling to C or C++ is still handy sometimes.