6 ms·
I know the basics of C, but stopped short of getting deep into threading and concurrency since it seems like Go and Rust handle that in a more efficient way (al
by magicmu 11y ago
I know the basics of C, but stopped short of getting deep into threading and concurrency since it seems like Go and Rust handle that in a more efficient way (although there's no way I would use Rust in production yet). Are there any advantages to using C/C++ for a new large-scale project?
- Aeolos 11y agoThe main advantage is a huge body of mostly functional code that you can attempt to integrate into your build system. The main disadvantage is that good C++ programmers are very hard to come by.
- hyc_symas 11y agoGood programmers are hard to come by, and that will always be true, regardless of what language you choose.
- Aeolos 11y agoVery true, and that's why newer languages are designed to limit the amount of damage average programmers can cause, while maintaining the same level of performance. See Rust for example. Sorry, small rant incoming. Ignore at will! I would still argue that good C++ programmers are exceptionally rare. I've worked with C++ professionally for roughly a decade (and as a hobby for many years before that), and despite using it and reading about it and fighting it and reasoning with it, I still don't consider myself a good C++ programmer. I've met several self-proclaimed good C++ programmers, but I've only ever met one I'd genuinely call good. He had experience in a dozen languages, half of them functional, and he produced code that was concise, maintainable, fast, documented, with correct pre- and post-conditions. Perhaps the best part was that he created interfaces that were a joy to use and very hard to misuse. He didn't like C++, but he knew how to make it work anyway. It was a joy to work with him. Contrast with your average C++ programmer who will overuse templates (hey, it's generic), generate a deep class hierarchy (hey, it's object oriented), of course with tons of setters and mutable state (parallelism? isn't that like std::thread and stuff?) and then waste time micro-optimizing anyway (hey, C++ is fast). Bonus points for avoiding the STL because "the STL is slow" (== game programmer, although this is becoming less common nowadays). Extra bonus points for arguing that GCs are slow, and then littering the code std::shared_pointer everywhere. These days, I go as far as to say that anyone who only has C++ in his toolbelt is not a particularly good C++ programmer, simply because of the lack of perspective.
- steveklabnik 11y agoJust for curiosity's sake, what specifically would make you not use Rust in production yet?
- OopsCriticality 11y agoNot OP but from the perspective of the industrial side: no track record, no formal standard, changes too fast, incomplete documentation, doesn't have an extensive commercial and supporting ecosystem (e.g. Parasoft, Java Path Finder), limited pool of experienced programmers with embedded and regulated environment experience. Arguably, it falls under the heading of "too new". I'd prefer to deal with known knowns rather than the known unknowns or gasp unknown unknowns of something new. It's a very conservative position, but it's borne out of the expense associated with mistakes and corrections of.
- steveklabnik 11y agoCool thanks! I'm trying to figure out what blockers are so we can prioritize things; a lot of these are very reasonable, but not immediately actionable things for me. Sounds good. :)
- OopsCriticality 11y agoSorry I can't offer anything more specific and actionable; I guess comparing Rust to a fine wine, something that must be aged to reach full potential, will have to do :)
- steveklabnik 11y agoHehe, no need to be sorry. It's one of the best answers, actually: it means that there aren't any fires, it's just about playing the long game and letting time pass. I prefer that. :)
- magicmu 11y agoI don't care quite as much about the lack of a proven track-record -- I understand the value there, but I love tinkering and trust Rust enough to not have any concerns about core stability (maybe a mistake, but there it is). It's mostly the lack of a stable HTTP library / ecosystem that throws me off; it seems like everything there is changing pretty frequently. That's just my impression though, and I'd love to be wrong :) I mentioned in another thread as well that the last time I played around with Rust, it seemed like most of the useful Cargo packages were dependent on the nightly version, which definitely gave me pause. I can't seem to find any of these packages now, though, so that's either changed or was an incorrect impression.