Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Learn C++11 or Rust in 2022?
71 points by sharedptr on May 2, 2022 | hide | past | favorite | 156 comments
Python/Golang/C (ye, C) day-to-day job here.

I am interested in either updating myself on (C++11>) or going the Rust way. I see a lot of criticism/hate of C++ lately (mostly due to the comittee), but the tooling and libraries are there for multiple areas.

Rust is also interesting to me from a security standpoint.

So I don't really have time to invest in both languages; any directions?




The smart thing to do is to bet against the herd on HN. Otherwise, facebook would've ceased to exist, everybody would be using ruby and crypto would be worth $0. Bookies love to bet against the herd for a reason.

> I see a lot of criticism/hate of C++ lately

Should tell you something. It's not like agenda driven PR campaigns are new to social media. Whenever I see a wave of criticism or praise on social media, I think to myself, what would paul graham do?

If your job is Python/Golang/C why do you want to learn C++ or Rust? Learn neither. Why not learn a functional language or SQL instead? Or delve deeper into python or go or c.


I remember when Stroustrup's C++ came out in 1986. I used to be able to cite the Annotated Reference Manual (ARM) by chapter and verse. But if I were a young programmer in 2022 and looking at learning either C++ or Rust I'd choose Rust in a heartbeat.

Why?

Many reasons. For starters, C++ is 40 years old at this point and embodies software engineering practices from the late 70's to early 80's (for you young folks, structured programming was the new hotness in the 70's!) C++ was also designed to take advantage of C's tooling, or lack thereof. C had incredibly simplistic dependency management. It worked well for the time since there were very few external dependencies, almost the entirety of the codebase was hand-built by the entity creating the software. There were very few libraries outside of the standard libraries.

C++ has an object model making it difficult to use and extend objects from different code bases/libraries. Never mind the inheritance patterns leading to lots of confusion. Just remember, Java and later C# were created to address these issues with C++. They were both touted to be better versions of C++ (which was true in the application development space where a GC could be tolerated)

Finally, the C++ type system is barely a type system as we understand them today. That's just history - C++ reflects our best thinking from the 70's and the modern type systems started emerging in the 80's. The simplicity makes some things unduly burdensome to implement.

Don't get me wrong - I've programmed in C++ for decades and I like it, warts and all. But I'm also practical and I recognize its days are numbered. Will C++ be around in 20-30 years? Absolutely! But so is Cobol, and would you start a major project today using Cobol? No. You can see we're shifting from C++ to Rust. C++ is the past and the lion's share of the present but Rust is gaining on the present and is the future. If I did't know either Rust or C++ in 2022 then I would focus my efforts on learning Rust.


> would you start a major project today using Cobol? No.

You might not start a project in it, but goddamn I bet you could make a boatload of cash doing consulting work to keep ancient COBOL systems running. Even today that's pretty lucrative business if you have the skills and connections.


Honestly, I think the shift you are already seeing is from C++ -> a GCed language (python, javascript, java).

While C/C++ are everywhere, they are mostly in very low level places. You don't find a lot of new backend projects that go the C++ route.

Rust will likely eat up a significant chunk of C++'s current market share and SOME of the backend service market share (where CPU and Memory are REALLY important). However, I don't find it terribly likely that it will grow much beyond that.

As for the Cobol analogy, a good one, but you have to also realize there are about 1,000,000x more lines of C++ in the wild than Cobol. For cobol to die takes some institutional investment that most companies are not willing to burn. C++ will have a MUCH harder time being purged.


If I was in a situation where c++ made sense for a greenfield project, rust would almost certainly be a better choice.


Except not having the libraries, IDE tooling and graphical debuggers that make C++ still relevant.


I agree those are downsides. But I think memory safety matters more in the problem space where c++ is relevant. I understand that's debatable, but I think the historical evidence suggests that it is impossible to write memory-safe c++ code beyond a fairly low complexity threshold.


Indeed, however memory-safe c++ isn't on the top list of what makes GPGPU, HPC/HFT, LLVM/GCC relevant in the industry, as such, those ecosystems won't be jumping into Rust anytime soon.

Some recent examples, Apple recently added support for using Metal from C++ instead of Swift secure bindings, Android now supports Rust at the OEM layer, no roadmap for NDK/AGK support for anything beyond C and C++, Azure Sphere is "secure" yet SDK is all about C and C++ (no Rust plans), Khronos API ecosystem is all about C and C++, CUDA,....


Agreed the spaces you’ve enumerated make sense for c/c++ still because trading off memory safety is a sensible engineering decision given the current state of things. Unfortunately security vulns can still sneak in there though :/


> You don't find a lot of new backend projects that go the C++ route.

TBF, C++ was never a great backend language. Rust "the language" isn't either, but "Rust the package ecosystem" might be one day (because unlike C++, Rust is coming out of the "web hemisphere").


Between C++ and Rust, my bet would be that you decide Rust.

But—also learn Zig in addition to Rust.

Having seen first-hand how so many threat vectors these days are now supply chain attacks, having reported CVEs and earned P1 bounties in memory safe languages, and having worked on static analysis systems to detect zero day exploits—I'm also impressed by Zig's overall approach towards safety, as being more than only memory safety.

For example, this comes through in Zig's extreme simplicity and explicitness, and also how Zig enables checked arithmetic by default for safe builds. For people who haven't worked in security, integer overflow and wraparound may seem like small things, but they increase the probability of exploits such as buffer bleeds, i.e. attacks like OpenSSL's Heartbleed, which are often remotely accessible and easier to pull off than a UAF.

In fact, no language is 100% memory safe, i.e. able to prevent a memory buffer bleed, because these are logic errors with respect to the protocol. However, explicit control flow and checked arithmetic do help to close semantic gaps and minimize ambiguity, which is what good security comes down to.

Of course, Zig only offers spatial memory safety, and not temporal memory safety like Rust. So Zig is more memory safe than C, and less memory safe than Rust or JavaScript. Nevertheless, Zig is safer than Rust when it comes to being able to handle memory allocation failure.

Again, Rust's borrow checker is also valuable for concurrency safety, i.e. for multithreaded systems, but if you're using io_uring for fast I/O, then multithreading is less of the necessary evil that it used to be a few years ago.

Zig is something you can pick up in a week, with state of the art tooling, and fantastic C-ABI interop for libraries.

So... learn both!


I'm confused when people preach Zig and then safety in the same sentence. Zig has basically all the same problems that C++ has with a few extra bells and whistles. There are perfectly good reasons to like Zig, but it being "safe" is not one of them.

> For example, this comes through in little things like Zig's extreme simplicity and explicitness

"Simplicity" does not mean safety. In fact simplicity means you can't describe hard problems easily without being overly verbose, which means more code and more attack surfaces. Problems are what can be simple or complex. If your language advertises "simplicity" it just means it can't solve complex problems in straight forward ways. Zig is just repeating the mistakes of C++ as well as all the mistakes of Go.

> or people who haven't worked in security, integer overflow and wraparound may seem like a small thing, but they increase the probability of buffer bleeds, i.e. attacks like OpenSSL's Heartbleed, which are often remotely accessible and easier to pull off than a UAF.

Zig does exactly what Rust does in this case.

> In fact, no language is 100% memory safe, i.e. able to prevent a memory buffer bleed, because these are logic errors with respect to the file or protocol format.

What are you trying to argue here? Buffer bleeds can't happen in safe rust.

> The borrow checker is obviously great for multithreaded systems, but if you're using io_uring for fast I/O, then multithreading is less of the necessary evil that it used to be a few years ago.

Syncronization is a problem in any kind of multitasking. Whether that happens inside or outside the language is the only question. The OS can have all the same problems your code can have. https://mobile.twitter.com/axboe/status/1505335772706091011 Also io_uring assumes you're only ever writing for Linux.

> Nevertheless, Zig is safer than Rust when it comes to checked arithmetic or being able to handle memory allocation failure.

This is simply incorrect. Most of the problem with unchecked overflow is for buffer overflows, which are fully caught. Rust gives options to handle memory allocation failure if you want to handle it. Generally though for most applications simply crashing is completely fine.


> I'm confused

Thanks, I've tried to clarify that Zig provides spatial memory safety but not temporal memory safety, so hopefully it's less confusing.

> "Simplicity" does not mean safety.

Ceteris parabus, complexity breeds bugs and simplicity improves the probability of safety. For example, if I were auditing a piece of code for security, I would prefer the simplest correct program to the most complex correct program. Reduced surface area means reduced area for attack.

When I say that Zig pursues simplicity, I also mean this as high praise, that Zig is highly "orthogonal". In other words, able to solve difficult problems with a minimum of overlapping features. For example, Zig's comptime gives you generics, but also gives you so much more, plus there is also type safety throughout Zig's comptime, yet it eliminates the need for macros, and is more versatile, powerful and flexible at the same time. It's incredibly elegant. Nothing left to add, nothing left to take away.

> Zig does exactly what Rust does in this case.

Things like checked arithmetic matter and should be enabled by default in safe builds, yet Rust does not actually do this in safe release builds. Zig does and I hope that Rust one day will.

> What are you trying to argue here? Buffer bleeds can't happen in safe rust.

By definition, buffer bleeds can in fact happen in safe Rust. The borrow checker can protect against UAF and overflow, but the borrow checker can't protect against all kinds of underflow, which is what a buffer bleed is. You can even pull them off in JavaScript.

No language is actually 100% memory safe, not with respect to buffer bleeds.


> Things like checked arithmetic matter and should be enabled by default in safe builds, yet Rust does not actually do this in safe release builds. Zig does and I hope that Rust one day will.

The entire origin of unchecked arithmetic being a problem originates from their use as indexes to buffers. If you solve the indexing buffer issue you don't need to completely expand every single mathematical operation to a checked one which slows down the code. If people want checked artihmetic for some reason in the rare case that it matters in a non-buffer case, then they can used things like checked_add.


> Reduced surface area means reduced area for attack.

First of all, that's security, not safety. Lots of software exists in an environment where it isn't going to be attacked.

> Things like checked arithmetic matter and should be enabled by default in safe builds.

Rust offers actual checked arithmetic - for example, suppose I have a 32-bit signed integer (i32) and I want to add something to it, in Rust I can choose the most appropriate of:

add - also presented as the + operator, in debug this will panic on overflow, but in production I can choose, either panic or just have it wrap silently

checked_add - at runtime check for overflow and get either None or Some(i32)

overflowing_add - this time instead of Option we get a pair back, with our (wrapped if necessary) numeric answer and a boolean saying if we overflowed

saturating_add - addition saturates at the minimum and maximum thresholds

unchecked_add - even in debug builds this is not checked (yes it's unsafe)

wrapping_add - this performs the most likely native hardware behaviour, wrapping numbers around at the limits

You might also realise your variable should inherently have certain arithmetic, for example a 16-bit PCM sample should always have saturating arithmetic (getting this wrong is one reason badly written older audio software can sound bad) so you can make them Saturating<i16> or maybe you actually want wrapping arithmetic on the simulated 32-bit CPU registers in your Motorola 68000 simulator, so you use Wrapping<u32> for them.

The debug behaviour for the trivial + operator is not intended to be your best defence, if you're sure you want wrapping, write that down, if you're sure you want to check, write the check. But sure, if you somehow want your release code to panic, but don't want to write the panics out by hand, you can tell the compiler you want this in release builds.

> By definition, buffer bleeds can happen in safe Rust.

Nope.

> The borrow checker can protect against UAF and overflow, but it can't protect against all kinds of underflow

And it doesn't, in safe Rust the actual bounds checks are emitted, and they only get elided in most cases because in idiomatic Rust it's clear to the compiler that the checks are unnecessary (e.g. iterating over items in a vector, the compiler knows how long the vector is, and it can see we're starting at the beginning and stopping at the end, so, we don't need the bounds check and it won't actually be emitted in the machine code). thing[index] is bounds checked in safe Rust.

> No language is actually 100% memory safe, not with respect to buffer bleeds.

Many languages are 100% memory safe. Most fascinating here is WUFFS which - in exchange for its restricted purpose - gets to be both entirely safe and faster than the C (or C++, or Rust) you'd actually write.

You literally can't write a "buffer bleed" type goof in WUFFS. I don't mean "You won't because it's so easy to get it right" or even "It will warn you about the problem at runtime so you can fix it". I mean code which can exhibit that bug does not compile.


> First of all, that's security, not safety. Lots of software exists in an environment where it isn't going to be attacked.

I use the terms interchangeably on purpose, because safety and security are really two sides of the same coin. In the past, I've worked in security and I now work in a domain where safety is critical. It's my experience that the two fields have considerable overlap.

We can always get better at interdisciplinary sharing of knowledge.


> I'm confused when people preach Zig and then safety in the same sentence.

Zig enforces correctness much more than C or C++ does (e.g. no implicit 'lossy' conversions, much stricter and enforced error handling, no implicit null, etc.), so it's completely fine to say that Zig is much safer than C or C++.

The main difference between Zig and Rust is the borrow checker, but a lot of memory corruption issues in C and C++ are "second order effects" of sloppy code which would be caught in Zig either at compile or runtime.


Except the little detail about sloppy use after free.


Agreed but doing this at compile time would require some sort of pointer lifetime tracking in the compiler. Don't know how much of this is feasable without going "full borrow checker", but static analyzers for C do a similar thing, by far not as watertight as Rust of course.

The General Purpose Allocator can optionally catch use-after-free by not recycling virtual memory addresses, not very efficient for small high-frequency allocations of course, but then Zig isn't an OOP language either (where it would be common to create and destroy massive amounts of tiny objects).


> ...but static analyzers for C do a similar thing..

Exactly, which begs the question why bother with Zig at all.


Zig is a much more ergonomic language, toolchain and build system. And since Zig is also a C/C++/ObjC toolchain, it's not about "Zig or C/C++", but about "Zig and C/C++" (at least from my PoV).


From my point of view it isn't enough to warrant adoption over existing alternatives.

Maybe someone proves me wrong with some killer application that makes Zig unavoidable for the rest of us.


Zig is a competitor to C, I think that really clarifies its design decisions. Eg., It's use of a interpreter during compilation to process macros, redresses C's purely textual approach.


> In fact simplicity means you can't describe hard problems easily without being overly verbose, which means more code and more attack surfaces.

Hence simplicity is not a desirable goal. We need to create complex languages so that fewer people can understand and use it in a few projects and write very less code. Less code means less bugs. ‘Complex’ is the way to go. /s


Counterpoint: Zig is unstable (as in, <1.0 release) and the docs are still pretty lacking. You’ll find yourself reading source code if you want to do anything nontrivial pretty much.

Stick to C++ or Rust, which I won’t weigh in on here. But both are much more mature.


Also there's no job market for it.


I don't think Zig is recommended for production use. It's not at 1.0.0 yet.

That said, there are at least three stealth-mode SaaS companies I know of betting on Zig for their performance sensitive / low-latency software. Where I work, we're tracking Zig's nightly build and follow/contribute to Zig progress and stability roadmap.

Zig hits a sweet spot between C and C++. It feels really nice to work in -- in a way that many people describe Go. I think Zig is a very attractive option for allocation sensitive programs like games, audio, or purpose-built data stores. Give it a look and decide for yourself.


D had a couple of such SaaS and doesn't seem to have helped much in the end.


see? learn Rust, but yeah, also learn Zig, or whatever new flavor of the day. No thanks. I don't want my tool set to change every year. I got out of web dev exactly for that reason. I'll stick to my C++ or C, thanks.


And your software will continue to have memory safety issues.


memory safety issues are the result of poor software engineering.


History has demonstrated over and over and over again that c/c++ code above a certain complexity threshold (which is fairly low), _will_ have memory safety issues. It doesn't matter how good you are at engineering.


but all the companies are making people do coding inteviews now. didn't that solve the problem????? apparently not.


If the interview question was find the memory vuln in this giant code base, I would probably fail.


FYI, the fact that you can do poor software engineering in safe Rust (or any memory-safe language) and still do not have memory safety issues completely disproves your statement.


Here’s a fun way to decide. Do Raytracing in One Weekend[1] in one of them. Then rewrite it again in the other. That should give you a good sense for which one you want to invest in.

Spoiler: I did this exercise myself. I found Rust to be more convenient in some ways. The Rayon crate made adding parallelism (threads) pretty easy. Some other crates made things pretty terminal output easier.

C++ feels more familiar to me in many ways though - I also write C fairly often. Implementing parallelism was more difficult. (I tried `pragma omp` stuff which should work similarly to Rayon, but couldn’t get it to work.) But just getting something working seems a little more straightforward.

I find myself fighting Rust somewhat often. In C/++, if you know what you’re doing, and you just want something working as a fun side project, it usually takes less dev time in my experience. Maybe that’s because I’m still learning it. Some folks will argue that the Rust compiler forces you to write better code and actually makes dev faster because it catches your mistakes. I haven’t found this to be true.

For example trying to implement simple polymorphism in Rust that was analogous to the implementations in Raytracing Weekend got ugly very fast. I ended in a weird hell of having to add annotations to everything to support generics. Again maybe I don’t understand the language enough, but adding polymorphism was a 5-minute straightforward exercise in C++, even as someone who doesn’t write it often.

I like a lot of stuff about Rust but I’m doing my hobby dev stuff in C instead nowadays, mostly for dev speed like I said, and probably would opt for using a subset of C++ for higher-level projects.

[1] https://raytracing.github.io/books/RayTracingInOneWeekend.ht...


I'm not ready to go back to C++ for this, but I know exactly what you're talking about regarding polymorphism. It's all magic and fairy dust for me, I'm really enjoying Rust. But once you want a dyn trait instead of a simple function, suddenly half of the magic doesn't work any more, and the language explodes into all riddles. (Interesting ones, I admit, and often there is some valuable insight at the end. But still a distraction.)

I guess as C++ veterans, we have to re-learn which approaches will work straight-forward, and which are the ones are asking for trouble. (I eventually found decent solutions for my problems that, while not the ones I had in mind initially, didn't require solving any hard puzzles.)


Well said, sometimes the developer community forgets what they are giving up (vs what they are exchanging for).

Is it a sin to say that, because you know c++ so well you don't need the nanny's and excessive overhead of validation?

That's akin to someone saying they never need to write tests.

Have you ever started a project without tests?


I don’t think raytracing is a good test of a languages merits. It tests a fairly narrow part of the scope of a modern language.


Not for everybody, and I’m sure it’s not the most efficient way to approach it, but I personally felt that learning modern C++ was a good intermediate step before learning Rust.

Going to rust directly has been a very frustrating experience and made me give up.

Instead I spent time learning C++, I found out I could more easily transfer my knowledge/skills there. Once you become more proficient with the basics you learn about move, copy, smart punters, ownership, etc.

After some point you start to notice that you are basically doing in your mind exactly what a borrow checker enforce. So that made me curious and I tried rust again, and this time everything made complete sense and the language has been incredibly refreshing to work with.

This intermediate state was very useful for me to build my mental model and develop a better intuition, C++ made it simpler to do it in a more progressive way. And Rust is a fantastic langage if you can wrap your mind around it’s semantic and learn to work with the borrow checker.


One reason C++ experience is so helpful with Rust is because the language was created by C++ programmers for C++ programmers, so most books and even documentation are written from that perspective.


This is something that's completely obvious to me. What I don't understand is why people online insist that Rust is so different and C++ knowledge is useless - I doubt I'd grok it immediately if I didn't understand C++.


> Going to rust directly has been a very frustrating experience and made me give up.

IMHO, you could learn Rust as a first PL by treating it as a functional programming language with a focus on purity, like a twist on ML or F#. The borrow checker rules and things like the String/&str distinction follow naturally from that POV. Then learn how "interior mutability" is used to enable more C-like procedural programming with shared mutable state.


I feel that by starting with FP, for example by starting with something close to ML in syntax and concepts, you cut yourself from too much of the programming world as everything else feels completely foreign and weird. But I get your point, you can approach it from the other side and also develop your intuition this way.


I had the same experience. Went to rust from a memory managed language, had no idea why people liked it so much. Then, I had to learn some Delphi (and not 10, like 7 compatible), and coming back to Rust was a breath of fresh air, and I understood the value in the ownership system.


I'd say C++ at this point in time. It's getting better by the day, yet it has decades of high quality projects and libs you can rely on. Each new version is better than the last. It may be irritating that few things are ever hard-deprecated, and you have to keep a list of current best practices. On the other hand, concepts, ranges, previously auto and constexpr, are all godsend and make for an expressive language that's still very powerful.

With Rust, depending on what you're working on, you may lose almost no time integrating C and C++ (with an extern C interface) libraries, or you may lose 50% of it. Sure, you don't have to know CMake at least (which is a hard requirement for C++ nowadays), but using any extraordinary library dependency in Rust may prove to be a nightmare. Essentially: if someone else didn't already package it, prepare to lose some serious time. The language is nice, but the ecosystem is immature.

Things are probably going to change, and Rust will become more viable over time, but C++ is also improving at a rapid pace so I guess Rust will never completely outcompete it.


One of the core benefits of C++ is that it is a high level language that's still super close to the hardware. Switching from C++ to other languages, if you have mastered C++, should largely be a question of "what things are automatically done for me" which is very different from "what are these new things I need to do" that you have to deal with when you switch between other languages.


> One of the core benefits of C++ is that it is a high level language that's still super close to the hardware.

This is also the main selling point of Rust, IMO.


Yeah, the unreasonable C++ hate is real. That said, from the modern perspective, the old versions of C++ do suck very much. If you're not even acquainted with C++11 yet, you should definitely check out C++20.

Rust is less expressive than C, but likewise it does give less chances to shoot yourself in the foot.

C++ is often derided for its complexity, arising from its long development. While it's true that C++ allows many wrong ways to do something, I don't think that should really be a problem. The language's main problem is societal: C++ (and C) is often used by people who haven't bothered to learn the language. E.g. one can't rely on random unknown C++ code handling integer overflow and type punning correctly, so in such cases it's wise to compile with

    -fno-strict-aliasing -fno-strict-overflow
A part of the problem is that C/C++ is so traditionally established, it's taught as as an introductory language at universities, for example. But it's usually taught wrong, because there's no incentive to teaching it right, and trying to teach it right could in fact be counterproductive, if the goal is merely to introduce someone to programming. This is why I think it would be best to teach Python or Julia as the introductory programming language, and (modern) C++ only afterwards.

Rust's advantage in this regard is that it's more centralized, it's lead by a foundation instead of being standardized, so everyone who learns Rust, learns the one, correct way to do things.


I learnt it at university back then, but I had already toyed with C++11 so I always made puns and called what they were teaching C--. Essentially they were teaching a very old version and the evaluation machines ignored all the "modern" bits back then.

My idea is to either C++20 (not sure if there is a resource to learn directly from C++20 or if there are compilers supporting it) or Rust, personally I would go for C++ seeing as there's a wider ecosystem and tools out there, lots of libraries (which are a bit of a pain to use sometimes) and it is almost anywhere.

But to be fair, I am out of the loop of C++/Rust and what I see in my internet circles is Rust > C++ mostly because of the memory safety; which makes me wonder if it is worth or not; also lots of C++ hate which reminds me of PHP.

I just have a hard time making decisions.


By the end of the day your employer will decide which language/version is to be used on a project, so you should check with your employer. That said, even C++98/03 is well an alive; as a consultant I still see a lot of industry projects using C++98/03, some with a few elements of C++11; I rarely see C++17 and never see Rust projects.


Erratum: s/less expressive than C/less expressive than C++/


C++ has a myriad of wonderful language features that exist entirely within C++ and cross no language boundaries. I really adore C++ as a language but unfortunately I find little pragmatic use for it unless I'm working 100% inside C++ and using native APIs only. If you're doing that, it's a dream. Rust, on the other hand, speaks the same ABI as C, and with serde, can read and write to most formats and/or APIs with utmost ease.

C++ I find can get a little unwieldy quite fast, but is generally easier to keep simple. It maps to higher-level concepts in easy and intuitive ways. Rust, I hate to say it, but unless you know best practices / idiomatic Rust from the start, you'll have to do a lot of refactoring as you learn the language. Some constructs simply aren't possible using safe Rust. Many embrace the limitations, many else frustrate themselves again and again until 'the Rust way' drills into their heads. But, of course, once you get a feel for it, it's pleasant to write in.

How much difficulty you'll have with Rust or C++ depends on what problems you try to solve, and what your approach to programming is generally. If you're more of a pragmatic "I write simple programs that actually do things" I don't think you'll have any problems with Rust. It's very straightforward. And the tooling is second-to-none. If you like to partake in exploratory programming, trying out different theoretical models and different abstractions, C++ caters to that by allowing you to write more elegant designs than in Rust, with the downside that it also lets you make worse mistakes.

The wider cross-language library ecosystem is mostly C-based I've found, so, in C++ you can just use those libraries directly with no hassle (the only hassle being the build system, or lack thereof). Rust can use those libraries as well (as long as you don't have a gut-reaction "ew" to using `unsafe` everywhere) but unfortunately the safe and idiomatic Rust library ecosystem is kind of on the bleeding edge at the moment. Hopefully things will stable out soon, and all these hip new technologies will come to fruition, but that day is not today.

I know this isn't really nudging in one way or another but really it comes down to what you value in a language and what projects you want to see through using these technologies that will determine which one you like better. Have fun!


> C++ has a myriad of wonderful language features that exist entirely within C++ and cross no language boundaries. I really adore C++ as a language but unfortunately I find little pragmatic use for it unless I'm working 100% inside C++ and using native APIs only. If you're doing that, it's a dream. Rust, on the other hand, speaks the same ABI as C, and with serde, can read and write to most formats and/or APIs with utmost ease.

This seems like a weird statement. Yes, C++ has a load of features you can't express in a C API. But so does Rust! Yes, Rust can produce and consume libraries with a C API. But so can C++! They're in pretty much identical positions here, aren't they?

It's true that serde is great, and C++ doesn't have an equivalent (AFAIK). But C++ does typically have excellent piecemeal support for popular serialisation formats.


I find it difficult to articulate, so forgive me if I'm not getting my point across, but the gist of what I'm trying to say in that section is less about straight binary compatibility and more about API design in general, playing to the respective language's strengths. I feel like Rust encourages more "C-like" APIs, and its added features (such as memory safety) are in effect the whole running time of the program, regardless of where that memory comes from or how it's initialized. On the other hand, C++ has something of a vendor lock-in regarding how it functions - RAII, constructors, exceptions, inheritance, etc. etc. all assume you have objects with a lifecycle that starts and ends in C++, and that those objects see most of their use according to C++'s object model. All of C++'s features come together in a brilliantly harmonized way and build off each other, but, if you forgo even some of those features, you end up missing out on most of them.


It's possible to have some parts of what serde does if you restrict yourself to aggregates (no private members, no explicit constructors), e.g. your types are simple structs such as

     struct foo { int x; std::string label; };
Here it's possible to serialize/deserialize this structure in a generic way without having to annotate it - currently it's a bit complicated to implement so libraries help doing it (e.g.https://github.com/apolukhin/pfr_non_boost) but in 23 the missing language feature that makes the code trivial to write without any library should be there.


For current job availability, C++. For enjoyment (in my case) and potential future jobs (not guaranteed), Rust. C++ is tried and true and it's proven itself for sure. Rust is just more fun to work with for me though. Lots of good tooling and documentation for both as well.


C/C++ have proven themselves impossible to write in a secure manner at any useful scale. The evidence is overwhelming.


C and C++ are the most common languages in avionics and space


I'm not sure the history of software driven avionics and space accidents really support that as an argument for their safety?


written by trusted expert programmers.


It depends on which direction you want to go.

Rust is probably a better bet for web-related things. There is not much C++ there, and Rust seems to get some popularity. After all, Rust was originally made for Firefox.

For more industrial applications, or game dev, C++ is likely the way to go. Where I work, we do a lot of industrial applications and we have a lot of C++ projects, including new ones. Rust is not even on the radar. [Edit: C++ here is mostly C++11 now, with some C++98 and not much C++14 and later, I expect that we will get to C++17 soon enough but C++20 probably has a long way to go]

Forget about the criticism/hate of C++ and hype of Rust, it has little to do with practical applications.


In a word: Yes!

Learn Rust because it has things to teach. Learn C++ for what it has, too, and because it is the language work gets done in.

They are much more similar than different. Rust builds in prescribed solutions for what its designers have deemed the most pressing problems. C++ builds in more power for library designers to address what each considers the most pressing problems.

There is broad agreement on what are problems, but with different solutions. Both languages work. I personally find Rust unable to express what I want to write, but it is evident not everybody wants to write those things.

Knowing both will make you a better programmer in either.

Practically all of the highest-paid coding work is conducted in C++. That will be true for many years to come. More people pick up coding C++ professionally, in any given week, than the total paid to code Rust. That has been going on for years, and is accelerating: attendance at C++ conventions, and the number of them, is exploding.

So, keep up with C++, and keep an eye on Rust.


I assume you know an older form of C++; the language changed a lot over the years, and the more recent features are "better" but they also make C++ (even) more complex. It suffers from ugliness, non-orthogonality, over-complexity, among other diseases, but it is still somewhat practically relevant. Rust is worth learning for its 1. avoidance of null and memory leaks 2. great error handling 3. excellent compiler error messages 4. concise notation (perhaps except macros, Common LISP wins here IMHO).

So first learn Rust, later learn C++11+ (by the time there will be a successor of C++11 that may look even less like the C++ you know).

Learning Rust will develop your thinking and taste, and this will then help you judge the flavour of C++ that you will be learning later (and because you'd update your C++ skills later, you may skip another C++ legacy flavour in the process).


I think you should tinker enough with both languages to learn their main concepts and then let 'outside requirements' guide you from there. E.g. if you're looking for a C++ or Rust job, or want to contribute to a C++ or Rust open source project, or just generally enjoy one language more than the other for weekend projects.

Also, if you're already fluent in another imperative programming language, it shouldn't take more than one or two weeks of a few hours after work to get an initial grip on both languages and decide whether you like them or not.

Personally, I find both languages equally frustrating for 'spare time stuff' (for different reasons though) and prefer simpler languages like C, Zig, Go, Python or Typescript (depending on the problem at hand).


> I see a lot of criticism/hate of C++ lately (mostly due to the comittee), but the tooling and libraries are there for multiple areas.

I like C++ and my main caveat is that you don't just write C++. You also have to get good at tools like Valgrind and develop a deep intuition and understanding of what the language does under the hood. That's going to require a significant time investment and some people just don't have the right energy for it.

Nowadays the only reason I would learn C++ instead of Rust would be if I wanted to benefit from the much bigger C++ ecosystem, for example to build a game engine from scratch.


Surely in any language you would have to learn tooling ? What happens when your user report performance problems on Python, Java or JS programs, you surely use some profiling tool there, no ?


If you use Python and JS chances are you do some form of web development, where most performance issues have to do with I/O, and most of those I/O issues are caused by bad queries. It ultimately comes down to using application performance monitoring software and analyzing query plans. Memory issues are an oddity and are usually caused by users doing stuff like uploading gigantic files.


> using application performance monitoring software and analyzing query plans.

soo... tooling ? how is that different from using valgrind ? it's literally one click in my IDE to use it and it will show e.g. the time spent at each line of code directly in it.

> If you use Python and JS chances are you do some form of web development, where most performance issues have to do with I/O, and most of those I/O issues are caused by bad queries.

I don't know about this, what I know is that multiple times in my career I had people come at me with python software that was slow, and transliterating them almost line by line to C++ made them much, much, much faster.

Also I have all these apps on my system which apparently depend on python, none of them being a web app:

    Name            : 3dsconv
    Name            : anydesk-bin
    Name            : arandr
    Name            : asciidoc
    Name            : bind
    Name            : binwalk
    Name            : bpytop
    Name            : breezy
    Name            : carla
    Name            : ceph-libs
    Name            : cmake-format
    Name            : cppcheck
    Name            : cppman-git
    Name            : cython
    Name            : deluge
    Name            : deluge-gtk
    Name            : diffuse
    Name            : distcc
    Name            : fio
    Name            : fontforge
    Name            : fvwm
    Name            : fwupd
    Name            : gconf
    Name            : gcovr
    Name            : gdb
    Name            : gdb-common
    Name            : gdown
    Name            : glusterfs
    Name            : gnome-tweaks
    Name            : gobject-introspection
    Name            : gtk-doc
    Name            : i3-workspace-groups-git
    Name            : ibus
    Name            : inkscape
    Name            : iotop
    Name            : ipython
    Name            : itstool
    Name            : jack_mixer
    Name            : kajongg
    Name            : kig
    Name            : kitty
    Name            : kitty-shell-integration
    Name            : libffado
    Name            : libixion
    Name            : libopenshot
    Name            : libreoffice-fresh
    Name            : libsearpc
    Name            : libsigrokdecode
    Name            : lldb
    Name            : mallard-ducktype
    Name            : meld
    Name            : mercurial
    Name            : meson
    Name            : mono
    Name            : mypy
    Name            : namcap
    Name            : node-gyp
    Name            : nuitka
    Name            : openshot
    Name            : pahole
    Name            : paperwork
    Name            : pax-utils
    Name            : pcsclite
    Name            : perf
    Name            : ps_mem
    Name            : pyalpm
    Name            : pyside2
    Name            : qemu-tools
    Name            : reflector
    Name            : repo
    Name            : rubber
    Name            : samba
    Name            : scons
    Name            : seafile
    Name            : setconf
    Name            : smbclient
    Name            : smem
    Name            : solaar
    Name            : speech-dispatcher
    Name            : tellico
    Name            : thefuck
    Name            : thonny
    Name            : torbrowser-launcher
    Name            : udiskie
    Name            : virtualbox
    Name            : yelp-tools
    Name            : youtube-dl
    Name            : yt-dlp
    Name            : zim
incidentally, my day to day experience definitely does not classify any of the software I actually use in the "fast and enjoyable" category, except zim and tellico. Like, just launched a couple that I had forgotten about: solaar, a GUI for configuring logitech mice, and thonny, a minimalistic IDE for arduinos, etc. and they take actually observable time to start, on a 1k€ CPU, which I really find to be entirely ridiculous (and made me remember why I don't use them more).


Imo the biggest difference is that in the Python / JS world you can be considered a senior developer at many respectable companies and still be clueless about tooling, optimization etc. Most shops (exceptions being places that do a lot of ETL, data processing...) are OK with clunky Python as long as it is not unusable. On the other hand if you are working with C / C++ a more active approach is needed if you don't want your software to blow up.


It's a bit of a dilemma if we are talking about landing a job here.

With C++ you'll have more offers, but you are more likely to be unsatisfied with your job: in large corps you'll usually have to untangle lots of messy legacy codes; while in start-ups things are more likely to be done quick and dirty and the flexibility C++ provides doesn't make it any better.

With Rust unless you are in the US, it's gonna be extremely difficult for you to find an opportunity; even in the US I gather there are not many chances and I _guess_ recruiters would expect higher proficiency as Rust is known for its steep learning curve.


Learn Rust. When you get to C++ later on, it will make you write much better C++ code. The other way, not so much.


I am personally not a fan of learning a language that does a bunch of "magic" behind the scenes for you, and basically tells you that you don't need to understand what is going on behind the scenes. That is the impression I get from Rust. I also have no interest in investing in a language that might no longer be hot in a few years. At least with C or C++ it will be here, until I'm retiring. The volume of software out there written in those language is massive and most "new" software engineers will not be able to deal with it as they have been brought up on python, javascript, java or whatever the new flavor of the day is.


It’s funny because I get the magic impression from c++ but not from rust. Stuff like copy semantics in C++ is so absurd. Rust is explicit and by design not particularly magical.


I agree, and let's not even start with operator overloading. Rust on the other hand seems to be a safe but also rather explicit language (a good thing not just for system programming).


Yeah the list really does go on… the number of high powered foot guns is truly terrifying


I am talking about Rust, not C++


I was agreeing with the comment I replied to, who assessed that Rust was the less "magic"-y language.


it is not less magicy, rust is more magicy. which is why i don’t want it and why i think we don’t need it. a new language cannot abstract you from the machine or OS you write software for.


at least c++ doesn't force constructs onto you. remember java? that language was a fad too that didnt' go anywhere, because it forced object-oriented programming onto the user.


I agree java forces a set of constructs, but it's a clear win for c++ - it has far too many constructs that interact in incredibly subtle and complex ways. And it will only get worse over time as they accumulate. At least I can obtain a fairly good mental model for what Java does without being a wizard.


I remember, it is running on all the mobile phones around the house, on the TV, on the blueray player, and apparently Amazon needs it to deliver my packages, Netflix to manage the next movie I want to watch,...


ah yes, it runs on a lot of mobile phones, and app developers cannot get consistent performance out of all those different phones, thanks to java and the Shit OS that runs on them, which shall remain unnamed.

i worked for a startup once that put a java based GUI on top of some C code and used the JNI. the endless issues with java bankrupted the company as the clients who were supposed to adopt the solution refused to deal with the sub par performance and reliability.


Not everyone can afford to hire good coders, so they get what they pay for.


java and that OS using java are poor solutions and the idea that you can get consistent performance out of a variety of phones running an OS incorporating java is retarded. at least at Apple they know what they are doing and never made that mistake.


There is just not enough information in your post in what you want to do with your knowledge.

If you have a long time horizon, Rust is the safer bet, if you want a job fast, C++ has probably more job offers.


Honestly my main short-time goal is to write performant applications, I have some processes in mind that would work way better if I could manage memory instead.

At the moment I just write bits in C whenever I need it but when it scales in a decent size I would just write the whole thing in C++/Rust


With C++ realistically memory management is so hard that if you want to go solo, and you don't want to debug segfaults all the time, Rust is definitely the way to go. It teaches you manual memory management like nothing else.


Unless you're manually implementing data structures or something similar you basically never need to manage your memory manually in modern C++. std::vector takes care of most your needs and smart pointers exist for the few cases where it doesn't. There's not really a lot of difference to Rust there except that OOB access is a panic in Rust and (most likely) a segfault in C++ but you can trivially enable that checking by putting the STL in debug mode.

C++'s problem is that most people never learn it properly and think "C/C++" is a thing because most courses/tutorials are stuck in the 90s and effectively teach shitty C with classes and iostream. Rust is great and has really nice features which I'd like to have in C++ too (like pattern matching) but memory safety is really not an issue in proper modern C++. I'm aware that this is a bit of a "you're just holding it wrong" but pretty much all languages have things you shouldn't do anymore once they evolve, it's just more obvious in the one with strong backwards compatibility requirements to the ancient language created before all the modern research into language design.


It's entirely possible to invoke memory unsafety in modern C++.

    std::vector<int> v {1, 2, 3};
    int& x = something(v);
    something_else(std::move(v));
    x = 42;
Is this UB? Impossible to tell without examining the code of the functions involved!


Nobody said it's impossible, it's just generally not an issue if you write normal code (read: stop treating C++ as C, they are completely different languages). There's only very little difference in how much you need to think about lifetimes and stuff between Rust and modern C++, it's far from being "hard". Sure Rust holds your hands a bit more in those regards but you can also just turn on address sanitizer and friends and then you have a very similar experience.


I took an Earley parser library written in Java and ported it to C++ with just using smart pointers everywhere for memory management and it Just Works™. Like magic really as I can’t recall having to hunt down any segfaults and I spent a bunch of time debugging that thing because porting from Java wasn’t really a copy paste operation especially since I never mess with Java so don’t know the standard library stuff.


> With C++ realistically memory management is so hard

Honest question as I'm not a C++ developer: Even with all the new C++17/20 stuff?


Problems with memory management are a fading memory when coding modern C++.

All the things Rust advocates insist cannot be done safely in C++ are now trivial. Use-after-free, leaks, buffer overruns, what-have-you, no longer need any attention to avoid if you stick to modern C++. Some people insist on coding as if it were C, and bring along all of C's failings. Leave them behind.


Unfortunely, only when working solo, or with a team that really embraces security.

Those people that insist on coding as if it were C are still a very big group across the industry.


The problem is that it's too late to add linear typing to C++ at this point and get rid of all other types. So I would say yes.


> If you have a long time horizon, Rust is the safer bet

I mean, maybe. Or maybe it gets replaced by something else.


C++20 is going to be much friendlier. If you're new to C-like languages though, perhaps start with C and work up to C++. The foundations are important to understand, and you'll appreciate why RAII is important.

EDIT: Ah yes, the "crawww C is unsafe, use rust crawww!" downvote crowd is out in full force today.


Starting with C is the worst way to learn C++. You start out with bad habits you then have to unlearn.

Unlearning bad C habits is hard because the language accommodates them for as long as you continue to cling to them. You need to consciously decide you will use the new, better way. Once you have done each once, there will be no temptation to backslide.


Fully disagree. Understanding pointer semantics is a pre-requisite for understanding RAII.


I know C++ since 1993, I am quite curious how pointer semantics have anything to do with RAII.


Because smart pointers are still pointers under the hood. You're forgetting the time before you know what pointers were - people coming from higher level languages don't immediately grok the concept. By teaching them automatic memory management patterns like we use in C++ without teaching them why you need such things, they'll never fully understand the code they're writing.

It's like the "I know React but not JavaScript" crowd all over again.


If you think RAII is about smart pointers, you really don't understand it.

RAII is about resource management, regardless of where those resources live on.

Heap allocated, OS handles, indexes on a fixed sized buffer, network sockets, ...


Yes, I'm aware, thanks. Lifetimes, ownership, etc. are all overlaps of RAII and associated concepts.

Again, what did being pedantic prove here? You clearly understood what I meant.


Yeah, doesn't make sense. Pointers are less useful in C++, because we have better things now.


Of course we do. You still need to know how pointers work to use RAII effectively, though.


Not at all, because RAII is about constructors/destructors, and not at all about pointers.

Heap allocated data is one special case of OS resources that can be managed by constructor/destructor pairs.


What did being pedantic prove here?


The thread started with you insisting a C-level conception of pointers is essential to coding C++, which turns out to be false.

Learning C first is a very bad way to learn C++. One can pick up pointers later, and asm blocks after that.


The downvotes are probably because you said "start with C" while the OP has clearly stated they have experience with C and use it in their day job.

P.S. I haven't downvoted you.


Oh I missed that line, thanks. The advice still stands, however - perhaps not to OP. But I think it's even more reason to learn C++20 in OP's case.


I use C at work and in the past for hobby projects C++ (11) to do some modifications to Quake 3.

Is C++20 support in compilers already? MSVC/GCC/Clang


MSVC has a good amount of C++20 support now https://en.cppreference.com/w/cpp/compiler_support#cpp20.


Not fully, but the important pieces yes. Clang and GCC in particular, not sure about MSVC as I don't use it.


Since it looks like you want to use it for some personal projects and you’re already comfortable with C, I’d suggest C++.

I’ve found that Rust requires more careful design to satisfy the borrow checker, whereas in C++ you’d just copy or use a smart pointer and move on with life. Additionally, when in Rust you have to change that careful design, the changes tend to cascade and spread.

All of the above could be largely avoided by using copying and smart pointers also in Rust, except that goes against the culture and what everyone else is doing. Most of the APIs you’re using will probably want you to use references…

To me Rust is the kind of language you’d use if you have your solution figured out and you want to implement a robust program based on that. Flexibility and development speed are not its strengths.


Rust - assuming something these languages are uniquely-suited to, like embedded, drivers, OS programming, or 3D graphics. It's a smoother experience in most areas. For example, I find it to have cleaner, more explicit syntax, good included tooling, and is easier to compile. Things like blocking implicit number conversions, and specifying array types (or array references) instead of pointers are nice.

A warning: Rust as a language has a large surface area, and there are some features and design paradigms that can make it messy to read and write. I would treat generics as a tool to be used sparingly, vice as a default API, for example. Same with Async and Tokio.


I’ll remark that _both_ of them have a very different aesthetic from Python, Golang & C, all of which aim for a certain simplicity of syntactic structure, whilst Rust and C++ both go for “power through the type system”. If you want a language that shares that aesthetic, you might be better off looking at JavaScript.

As others have remarked, there’s a lot more C++ gigs out there. I don’t think knowing C is actually much of an advantage to learning C++ though, the idioms and libraries are too different. Personally, I like Rust, it’s got a great community and the language feels “next-gen” in a way C++ never will.


Today, I think it comes down to what you want to build and what dependencies or SDKs (if any) that requires. If you want to build something greenfield with simple dependencies, I would go Rust. However, if you want to build something that depends on existing software, there's a good chance that you're going to have an easier time today doing that with C++ due to its dominant ecosystem.

For example, one of my products embeds Chromium (via CEF), which itself is a huge C++ project. I'm interested in working with Rust, but it's simpler for me to just use C++ rather than working against the grain.


Depends on which area you want to work on, anything related with GPGPU, HPC/HFT, GUI tooling, LLVM/GCC infrastructure will be focused on C++ for at least one decade, or more still.

For Cloud Native stuff, Rust might be a better option, specially due to the security focus.


Look at the practical side of things, C++ is going nowhere and its improving. C++ is simple just write and compile. No rustc, cargo and rustup combo. Both languages are good but one is tested and tried.


No contest !

Just go with C++11/14/17/20 and you will be set for life.


What is your objective? If it's to be exposed to new ideas, I suspect that you will find Rust more interesting. In general Rust's notions of ownership/borrowing will be new to anyone, but to a Python/Go/C programmer like yourself I suspect you will also enjoy learning about tagged unions (what Rust calls "enums"), pattern matching, and expression-oriented programming (e.g. how `if` can be used directly as a ternary operator).


Just learn both. Find the time.

From a practical perspective, if you're short on time and want a return on your investment, C++ will open up more opportunities on the job front.


It depends on what your objective is. I assume you want to expand your skillset for the future. C++ is good because there's tons of legacy C++ code out there, and companies will need people to maintain it for decades to come. Rust is good because it's trendy and looks good on a resume. Do note, however, that C++ and Rust skills are unlikely to be valuable at the same kinds of companies.


I would choose Rust. Today it might be that the market has more jobs on C++ and there are more codebases.

In the future, those codebases will only be the legacy ones and you will end up doing more maintenance with C++.

With Rust your investment of today will pay off in a few years.

Deciding what to learn today is an investment decision and you should look into what you think the future will look like. To me it looks Rusty. :-)


I think a valid concern might be - in 5 or 10 years, C++ still remains, just like Java and other "boring" languages. However, Rust might have been replaced by the next "Rust". That environment is still somewhat in flux.


I agree with you, it might turn out that C++ outlives Rust. I am seeing more codebases being created from scratch in Rust nowadays. We are just making bets on the opposite side. I guess we both agree that the deciding factor should be what you think the future will look like in 5+ years. Nobody knows what will happen in 5 years, then it is a bet or an investment decision you make.


I'm sure exactly the same comment can be found on Slashdot in 1997 with "Java" instead of "Rust"


TLDR; Learn both and choose the right tool for the right job.

Now, for C++ I can share some links I personally follow:

    https://github.com/AnthonyCalandra/modern-cpp-features
    https://www.youtube.com/c/lefticus1/videos
    https://www.fluentcpp.com/
    https://www.cppstories.com/
    https://hackingcpp.com/
    https://www.modernescpp.com/
About Rust, this link https://www.rust-lang.org/learn shares far too many goodies that any level of programmer can benefit out of it.

Enjoy!


> So I don't really have time to invest in both languages; any directions?

Why not? It's not like "two languages == double the time".

In this particular case, learning both side by side and comparing design choices may well lead to a better understanding and even be faster than just learning one of them.


Learn Rust, I write both and I find it and the tooling around it to be an absolute delight. It has a decent amount of traction and jobs too. It being relatively young I think this is the language in that space to watch.


my personal opinion is to learn Rust and something like zig or nim


Man I have not heard of those last two wow. Well 2016/2008 not really brand new either.


It depends on the direction/industry you want to move in - depending on that you have to learn. The solution of the task will show you which language is more suitable.


Learn both. You're likely to encounter both of them at some point in your career. I also find it easer to go from modern C++ to Rust than the other way around.


Build something small in each, you’ll know instantly.


Neither. Program in D - https://dlang.org/


C(+) on client and Java on Server, for eternity.


To really appreciate Rust you have to understand the problems with C++ that it solves. I would say learn Rust but you will learn C++ along the way.


While it may be tempting to learn C++11 now, the current industry standard is Rust.

C++11 is a well-known and popular language for software engineering, but was released in 2011. Most programs written in C++11 are being updated or rewritten in Rust because of its simpler syntax, more modern features, and generally easier development process. Additionally, many companies will hire programmers that specialize in Rust over those who specialize in C++11.

Although it is possible to find jobs doing C++11 development, we would recommend learning Rust instead.


I love rust, but you are living in a bubble if you think rust has already managed to become the industry standard.


If you go for C++, don't start lower than C++20. MSVC has a chunk of C++23 done already


I don't understand why someone who has so much open source information, has the intelligence to learn C-level languages, and has a certain experience in the industry, would ask such a question.


Maybe they just want to try to see which way the wind is blowing before making a decision which would require more than a little effort to achieve?

I’m actually surprised that the general consensus isn’t rust as that’s the new shiny plus the people saying C++ are giving very valid reasons beyond the usual language dogma arguments that these discussions usually devolve into.


I mostly use C when I need to speed up some bits in our codebase; and I have no chance to ask people really working in C++/Rust which can give help me decide; the people I know use C++ for games or QT. The ones I know that touched Rust gave up after 1.5 weeks.

As you say I wanted to know how's the scene at the moment; I am very disconnected from how they have both evolved and their future (mostly because what I see is hate to C++)


Unless you're going to be doing something that specifically requires C++ (some game engine related code comes to mind), go with Rust. Most real-world code (by number of codes and lines of code) is something else than C/C++ nowadays, just because of developer velocity and a larger hiring pool.

Yes, you can get that last cycle of power from a piece of hardware by going with C or C++, but on the other hand finding people who can do that is time-consuming and expensive. And in many cases eventually not worth it.

"C++" is such a big concept toi grasp fully, that I don't see the point of studying it unless you're getting paid for it.


> Most real-world code (by number of codes and lines of code) is something else than C/C++ nowadays, just because of developer velocity and a larger hiring pool.

This is simply not true. Examples of major software that is being actively developed:

- Lots of compilers/runtimes (gcc, LLVM (which Rust builds upon), Java/JDK/JVM, Swift, node.js) - All major browsers and browser engines (Chrome/Chromium, Firefox, WebKit) and thus Electorn - Lots of rich client applications using either some Windows API, or something like Qt, or Electron (JS + C++) - Major game engines such as Unreal, Frostbite, CryEngine - Major OS'es graphics API build upon C++: Microsoft's Direct3D, Apple's Metal

And this is completely ignoring the embedded world, where C++ competes at least at some higher level with C.

All of this requires C++ engineers.


Again, this is a tiny portion of actual coders.

The amount of people actually _making_ compilers and runtimes is multiple orders of magnitude smaller than the people using them.

Same with browser engines and game engines. For every coder doing the actual engine, there are a hundred others just using the engine, not touching C++.

You did list a pretty substantial portion of the segments where C++ is a valid choice and in many cases (along with C) the only option.


It's not like they are equivalent. I'd rather stop programming (or any kind of computer science related career) rather than take a job doing business Java or writing game logic in Lua or C#.


When the car's automatic gearbox breaks down, it is nice that there are some mechanics around.


True, but not everyone with a license needs to know how to rebuild a gearbox =)


Depends, on some countries getting a license means acquiring basic repair and first-help skills. :)

In any case, the point was that those that know how to repair the gearbox must come from somewhere.


> "C++" is such a big concept toi grasp fully, that I don't see the point of studying it unless you're getting paid for it.

Not really necessary to grasp the entirety of the language to use it effectively, I dabble in C++ here and there and usually treat it as a fancy C just using stuff like smart pointers, strings and vectors. Even learned some C++17 stuff which made what I was trying to do a lot simpler though I can’t remember what I was up to, think it was some boost lib I was already using that got promoted or std::variant shenanigans with my asdl generator — definitely yaks were being shorn I can say for sure.


How do you begin to get paid for it without studying it first?


Some employers are actually far-sighted enough to spend money training their employees.

So e.g. you hire a bunch of fresh graduates who've learned some programming maybe Java and Python, and maybe have other expertise you value (e.g. maybe they're aerospace engineers and you write control software for jet engines) and you spend money hiring somebody capable to stand at the front and teach them how to write C++. It's their job to learn this, so you can do it pretty intensively, e.g. lecture slot / exercises / break / repeat.

C++ is a big sprawling language, but you can make a good start on them in two weeks.

You've presumably worked somewhere with at least some onboarding or spin-up time. Somewhere you weren't employee #1 and responsible for buying your own stationery and cleaning the toilet ? What did you do on day one? Fire training? How to use the CI system? Anti-bribery? Getting your photo taken for an ID badge? Maybe some "easy" first tasks just to learn your way around the systems?

If you have a job where you turn up on day one and are just as productive as a long haul employee, I have terrible news for you - you are the most replaceable person in your organisation and you are going to get fired.


Get an employer who lets you learn on the job.

Programming languages are like actual languages, after you know the first two or three, the fourth one isn't that much of a hassle (there are exceptions of course).

I didn't know crap about C# when I started my current job, but I did have a decade of Java under my belt. Took me about a day to figure out the basics. Ifs and switches and functions and classes are the same everywhere.

If I would've had to study something like Haskell or Scheme, it would've taken a bit longer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: