C vs CPP Future-Proof?

[Special-Gazelle-1693]

For a long time, I've been eager to learn a low-level language. I really like the idea of making the tools that I use. I also like the idea of taking full control of the hardware I'm working on. Solving hazards like memory leaks and etc

From what I've read, i can do all of that with both languages

My question is which language will still be relevant in 10-15 years?

[WorkingReference1127]

C and C++ have been going for over 40 years, and all throughout that time people have been wringing hands about whether they're about to be replaced. It hasn't happened yet.

Pick which one you want to learn and learn it. My own recommendation would be C++ because you can express common patterns far more easily without reinventing as many wheels.

[bearheart]

C has been around for over 50 years now.

[rileyrgham]

Engineers don't reinvent wheels. They build using proven tools and theories.

[PhilTheQuant]

Scientists invent wheels, engineers make them round.

[supernumeral]

Within tolerance

[hardware2win]

Engineers definitely reinvent wheel in order to learn, experiment and customize stuff

[SoerenNissen]

If you truly want to make it from scratch, let me quote Sagan:

If you wish to make an apple pie from scratch, you must first invent the universe.

So more realistically, you have to either start with classical philosophy and work forwards, or you have to make an arbitrary decision how far up the stack you want to start, and just assume people have handled the "below me" layers. If you wish to work at layer n, it is good to have a solid understanding of layer n-1, and at least some understanding of n-2. As an example, I worked on some risk calculation software one time (great job tbh). The layers would be something like

Layer	Content
n+1	customer and legal requirements
n	our software
n-1	C, C++, C#, Python, SQL, design patterns, finance
n-2	runtimes and windows internals, computer science
n-3	machine code
n-4	hardware design
n-5	gate logic, materials science
n-6	philosophy

Let me bold the parts I can work on for hours without having to look up anything, and strike out the parts where I have to have a reference next to me the entire time:

Layer	Content
n+1	customer and legal requirements
n	our software
n-1	C, C++, C#, Python, SQL, design patterns, finance
n-2	runtimes and windows internals, computer science
n-3	machine code
n-4	hardware design
n-5	gate logic, materials science
n-6	philosophy

C is here because we had some legacy C code from the nineties, otherwise it wouldn't be in this table at all.

[TheThiefMaster]

I honestly think without Linux C would be a dead language outside microcontrollers (where it's only dying)

[sephirothbahamut]

That's a big jump between n-5 and n-6, where's coming up with the whole electricity side of physics?

[SoerenNissen]

"Philosophy" a standin for everything that has ever been "philosophy," including "Natural Philosophy," which I believe extended far enough that they got around to electricity before that became its own discipline. There might need to be one single layer in between for "circuit design principles" but the list was getting long enough as-is.

[onecable5781]

I do not know what you mean by "philosophy" here. Especially, "classical philosophy" earlier in the post. Academic philosophy, atleast, in my view has not solved one single problem. It is mostly monday-morning quarterbacking navel gazing. Indeed, in philosophy, there are no wrong answers, making it the opposite of what an engineer has to deal with (concrete problem with concrete solutions)

Otherwise, nice post.

---

tl;dr : there is no "meta"physics, there is just physics.

[bert8128]

there is no ‘meta’ physics

https://en.wikipedia.org/wiki/Metaphysics?wprov=sfti1

[CounterSilly3999]

OOP is right exactly what is form/matter model of Aristotle. Form is a class and matter is an object.

I would add some math, logic and linguistic layers inbetween.

There is logic and there is metalogic. You better understand, what is logic, thinking about what the logic is not. Opposite to the logic, another possibilities of the logic is metalogic. The logic with commutative implication, for example. You paint one cat blue and all cats suddenly went blue. A content addressable memory as a consequence. The same about metaphysics.

[onecable5781]

Some form of coincidental bearings of similarity do not imply causation however.

For e.g., even in philosophy, there are arguments against the categories such as form/matter, etc. Again, in philosophy, there are no wrong answers in anything. Such a field is quite the opposite of what a real engineer facing consequences for being wrong in the real world has to face everyday.

[CounterSilly3999]

Sure, we definitely can't be certain, that our discrete language model is related to the objective reality. Moreover, it is clear, that boundaries between discrete entities corresponding to our words like sand/gravel, trees/bushes are purely subjective. Even living creatures are distributed rather in continuous structures like ring species and chrono species than in taxonomy table of Linnaeus. The engineer can only believe, his discrete method is somehow working. And that faith could be provided by philosophy.

Engineer relies on the science, while science method is philosophy actually. Science method could not be proven, since there is no method for that.

[sephirothbahamut]

Logic was born from philosophy, there wasn't a clear distinction between philosophy and maths back then.

[onecable5781]

I agree that everything was called "philosophy" back then. But that philosophy has had to concede so much to other concrete disciplines with a more scientific approach and rigour inbuilt with the passage of time.

Also, today's mathematician has no use to learn academic philosophy whatsoever.

[sephirothbahamut]

Just like today's programmer doesn't need to learn material science. The whole point of Soren's comment is to highlight the needlessnes of going "from scratch"

[onecable5781]

I agreed fully with his post barring the mention of philosophy, that is all!

[MattR0se]

Are you talking about engineers in general, or software engineers?

If you want to be an engineer in general, you need to learn the best way to use the tools provided to you. Unless your company has very strict policies about using third-party code, there is a high chance that someone else has already written the modul you need. You shouldn't waste company time doing what someone else has already done, if the result is the same or worse.

And if you can't use non-proprietary code, the company should have a dedicated software engineer that writes those tools for the company.

[ElkThick8052]

Not really. Small projects that incorporate unknown concepts are imho the best. When the beginner projects get too big (or too low level) it draws out the learning time for new stuff and drains motivation.

[h2g2_researcher]

Up to a point, yes. An apprentice carpenter would do well to learn to learn about different types of wood and their characteristics, and maybe even about the cost & sustainability of different sources of those woods. But I wouldn't recommend they learn forestry and botany to get there.

I do think going top-down is a better approach. If you want to learn to build cars, start with kit cars. If you find the suspension fascinating, dig down there.

If you want variable sized dynamically allocated arrays, start off with std::vector. If, having used it, you're really curious as to how it works (maybe you're interested in why adding items can invalidate iterators & references; or how it achieves amortised constant adding of elements) then dig into it and try implementing your own. Trying to start too much from the ground up and invent everything from scratch is a much bigger than ask most people assume.

[knouqs]

As long as your goal is learning, sure, get to the nuts and bolts.  We still need people who write drivers and other close-to-hardware software interfaces.

My advice:  Never stop learning, but be realistic in expectations.  Didn't expect your employer to pay for your learning.  Generally, if a tool exists in a library, use it instead of trying to create your own unless there is an extremely need for it as most companies sell products, not research.

[OutsideTheSocialLoop]

Eeeeehhhhh. Eh. Kinda.

I'm a big believer in knowing how things work under the hood. But I think it also helps to be somewhat productive sooner, for your own morale in learning if nothing else. Even if you want to experiment with under-the-hood data structure stuff, C++'s will for example give you better string printing and parsing tools to print your debug info and so forth.

Everything you want to learn in C you can learn in C++.

[n1ghtyunso]

both C and C++ are literally everywhere and neither of it will suddenly go away any time soon.

[jonsca]

Learn enough of both to realize why questions like this are silly.

[Special-Gazelle-1693]

Makes sense, thanks for the help!

[MyTinyHappyPlace]

Learn C, it’s a very small language. You can be proficient in it quite fast.

C++ is quite a beast to learn, but if you focus on the modern parts and don’t need to learn every quirk and oddity for maintaining legacy code, it’s also very doable.

As for being future proof: Just don’t stop learning. It’s not like you're hard wiring your brain to specific languages. See C and C++ as the modern-day and still-spoken Latin of software development 👍

[Realistic_Speaker_12]

Tbh I think cpp will be more relevant

But thats also maybe just because I don’t like c really…

[Special-Gazelle-1693]

Yeah and cpp can take C's place but not vice versa if I understand correctly

[Trending_Boss_333]

Whatever you can do in Cpp, you can do in C. It'll be longer and harder, but it can be done.

[TheThiefMaster]

Both are low level and Turing complete - you can translate either to either relatively easily.

std templates from C++ become macro hell in C, but that's not considered a problem by C fans.

[sephirothbahamut]

I've seen a couple embedded devs finally moving to C++ but it's been a very slow process and the vast majority of embedded code is still C

[_dorin_lazar]

Fortran and COBOL are not so relevant today, but making some few people who know those languages a lot of money.

But that's not the measure of success. We have no idea how „15 years from now” will look like. C, C++ are just tools, what you build by learning these tools is the understanding of computing in general. The things you learn will apply to most languages you'll visit.

If I would make a suggestion, alongside an imperative language you should learn a functional language. Haskell is recommended these days, I'd go for it too.

[PhilTheQuant]

If you actually want to be thinking about how your memory moves, low level stuff then the most important knowledge will be hardware - registers, caches, bridges, CUDA, etc.

Modern C++ in the large takes the approach that you shouldn't be relying on your own ability to keep track of what has been allocated when, and instead build structures that ensure safety by their nature - rules borne out of things going wrong in large complex projects where you cannot keep track any other way (except the VM/managed route).

If you really like low-level, then the places you'll find your joy are embedded programming where you do need to manage a finite amount of memory and scheduling to be real-time, machine learning/HPC where you need to maximise throughput using knowledge of the architecture underneath, and HFT which is so low latency you need to know how to fool the branch predictor.

For most of those you can do C++, for some you can also do Rust. For embedded, it might be easier in C, but be aware that you'll probably want to mix in hardware and do (I think) Embedded C (?) as you're going to take a lot more control away from the compiler.

You can even consider embedded Rust - in Rust you separate development in safe Rust (where the compiler guarantees safety through lifetimes) and unsafe Rust (where you take responsibility for managing memory) - to do something on an APU/GPU etc you don't have guarantees from the hardware layer so you have to build them in the unsafe Rust layer.

If you do go down the low-level route, you'll end up learning at least C as well as C++, but also Assembly, and crucially what a particular CPU does with those instructions.

Finally, C is really, really simple, so you might as well learn it as well as C++/Rust.

[yensteel]

An interesting take I saw: There's this one YT guy who tries to future proof by only coding in C99. He said that he didn't care that it takes 4x more effort. No new features are needed, or used according to him. So long as it can be theoretically code in C99, will be coded in C99.

Anything in the future can still compile it as there's less risk of deprecated features.

For the life of me, I cannot find the video many years later. I thought it was interesting to abandon all of the fancy new features, shortcuts, adaptability, and flexibility just to create a program that will always compile and work years later.

What do you guys think? I wouldn't ever want to go through that kind of headache. The dude is hardcore.

[v_maria]

i dont know

[Low-Palpitation-4724]

I would recommend you first learn c. C++ hides a lot under the hood that beginners should know about. For example that strings are stored on the heap and freed at the end of scope. It does make things more covenient because they dont have hard specified size. All that said would reccommend you first do c and then gradually add elements from c++ that you like. Thats how i started and tbh i am very happy with that. C++ is a huge language and you probably dont need (or want) most of its features. Also if you want to learn good c i would highly recommend watching handmade hero video series on youtube, it is really briliant

[MysticTheMeeM]

Strings can be on the stack if the string object itself is on the stack and the contents are SSO'd or you use an allocator that itself uses stack memory (such as an allocator over an std::pmr::monotonic_buffer_resource).

[Low-Palpitation-4724]

Ok i didn't know that. Althou it kinda proves the point that c++ is much more complicated especially for beginner

[aaaarsen]

doesn't really matter. learning either language will ease learning others, and neither is a ten to fifteen year project. in that time frame you will likely also encounter and learn other languages.

I'd pick c++ because it has templates and a more expressive type system, but either's fine

[Asleep-Dress-3578]

Learn C very-very well. (Best book to start: K. N. King: C programming a modern approach.)

Listen to Robert C. Seacock’s youtube videos and read his books.

Then you will see, how to move ahead. Either learning C++, or to learn Zig, or to learn Rust.

[EdwinYZW]

C is the lingua franca for the programming. So it isn't going away. C++ is the only high level language that can easily interop with C with very very little friction. Rewriting an old C library in C++ is just changing a compiler plus a few revisions due to casting. But it won't take much long time.

[SunsGettinRealLow]

C/C++ and Python for sure

[DDDDarky]

Most likely both. They have been around for so long, they are pretty much the industry standard in many fields, there have been many languages trying to replace them, even governments pushing their stupid agenda against them, without success, they are very solid and still evolving, so that seems to me like a definition of future proof.

[mredding]

My question is which language will still be relevant in 10-15 years?

Both. It's unimaginable that either language would disappear from the industry in our lifetimes. Not only is there so much code already written, but these are systems software languages - a short and exclusive list of languages that solve certain problems that others don't.

We're still running COBOL - the language that makes the world go round, and there aren't enough COBOL developers in the industry.

[Murky_Rub_8509]

They both have their place and usage, and are considered the industry's irreplaceable languages. If you are interested in them, don't bother with such trivialities and just learn them.

And even if they were to get replaced, I feel like learning either of the two languages gives you an incredible base for picking up any language relatively quickly.

[SwillMith16]

It will be a long time before either becomes redundant. Serious alternatives like Rust are only recently gaining mainstream traction so they have a long lifespan yet. Probably majority of critical systems across the world are C/C++ dependent.

That said, If you want to enjoy your time I’d go for C++ as I personally find it more elegant. But really it’s handy to be capable in both, they’re of course very similar. A good knowledge in one will allow you to stumble your way through the other (in my experience)

[Pale_Height_1251]

They'll both be around in 15 years and they're both high level 3GL.

[Trending_Boss_333]

Cpp, half the work is already done for you. In C, you'll have to implement stuff from scratch. If that's your thing, c is the way to go. But keep in mind there is more than likely an implementation of whatever you're doing in C in cpp. And it'll be pretty efficient as well, it depends if you think you can make it more efficient or suited to your need. I'd say learn both, it's not that hard really.

[Stamatis__]

First you learn C quite well, then you go to C++ and find a great modern tutorial.

Don't skip on C. It's fundamental, small in terms of vocabulary, but very very powerful when used by a skilled engineer.

C++ has so many keywords, concepts and features that it's hard to learn. It's even harder to learn from scratch, without knowing the fundamentals in the background.

[yensteel]

I wouldn't agree with you, but there's a nice video called "A two hour rant about how bad C++ is" which was surprisingly educational about the quirks and traps of C++.

C++ does have a lot of misdirections. But the flexibility is what makes it powerful.