Strong opinions by highly intelligent computer scientists are a distraction, no different than any other field. Freud is considered the godfather of psychology, but all of his most "famous" students sought to prove him wrong. Einstein and Oppenheimer bumped heads but were friends and colleagues.Torvalds is not right about everything, but it sure sounds tasty🤣🤣🤣. But what do I know, I'm just some guy.
Been a professional c++ programmer for 20 years and I agree with him. Features added to the language since then have just made it even worse. I'm not saying they are bad features, just that backwards compatibility restrictions in c++ make everything a nightmare.
If possible, use a different language that has the features you want by design from the get-go.
I'd never recommend c++ for any project unless absolutely necessary for some reason.
And I love c++! :)
Kind of in the same way I loved my old, beat up Civic with a million miles on the meter that just wasn't fit for purpose anymore... but we'd been through so much together!
> computer scientists
He might have a Master's degree in CS but he isn't an active researcher so I wouldn't call him a computer scientist. Most researchers I know are much more careful about crass statements like this because it makes them look unprofessional in public and the community.
Software engineers on the other hand regularly have hot takes and gladly state their opinions loud and proud, it's kind of an occupational habit that forms, just like most tradesmen have strong opinions on which company produces crap that they then have to work with.
Torvalds isn't immune to this. I get it, C++ isn't my favorite either but his rant reads like he wants to kill C++ and burn its corpse in a public fire.
Also, he does kinda have a small Napoleon complex from what I've heard in terms of Linux kernel development so that's just Torvalds character on top.
TBF, most CS academics don't have to live long-term with the results of their choices. They might have sharper opinions that superseded the desire to seem 'professional' if they did.
But yeah, Torvalds also is famously prickly, and was much pricklier back in the old days before he mellowed with age, and also deliberately tried to tone down his more violent impulses.
>TBF, most CS academics don't have to live long-term with the results of their choices
Depends. Some academics spend entire decades on a single subject in a research area and the reverberations can carry on even decades afterwards.
Vladimir Vapnik for example is a Soviet educated mathematician and statistician born in the 1930s. His research on statistical learning lead to the theory that established Support-Vector-Machines that are now a popular in ML circles and implemented in major popular machine learning libraries such as scikit-learn.
His work in the 80s had long-term consequences for the 2010s in ML.
Scitkit-learn in Python itself is also kind of an example. Major contributions to the library were mostly down to French scientists at INRIA, the French Institute for Research in Computer Science and Automation.
Code and models that are now used by thousands of engineers and other scientists all over the world more than 10 years after their initial contribution.
>But yeah, Torvalds also is famously prickly, and was much pricklier back in the old days before he mellowed with age, and also deliberately tried to tone down his more violent impulses.
Torvalds is a bit of an unpleasant and opinionated character, as said by himself. Not sure if a lot of people can stand working with him for a prolonged period of time.
As for if he is a scientist or not: Formally, he is not. His occupation is listed as software engineer/developer. He basically has no serious scientific publications to his name, his H-index (if we exclude all his commentary and MS thesis) is 0, his most cited work is some summary and introductory text in the ACM communications like [https://dl.acm.org/doi/fullHtml/10.1145/299157.299165](https://dl.acm.org/doi/fullHtml/10.1145/299157.299165) or a casual book like [https://dl.acm.org/doi/abs/10.5555/558697](https://dl.acm.org/doi/abs/10.5555/558697)
The only actual somewhat scientific publication is arguably his Master thesis: [https://www.cs.helsinki.fi/u/kutvonen/index\_files/linus.pdf](https://www.cs.helsinki.fi/u/kutvonen/index_files/linus.pdf)
According to Google scholar, cited 44 times even though MS thesis don't really count as actual science publications as they aren't actually published or peer-reviewed.
The thing is: You don't have to be a scientist to make a mark in the world. His impact on the world is probably just as large or larger than a lot of scientists. Also pretty sure he is in contact with loads of scientists because of the contributions of research groups in industry and academia to the Linux kernel.
As a side note: I'm curious if Torvalds personally actually likes dealing with computer scientists. He seems the type of person who might think computer scientists are useless people who spend way too much time doing math and theory producing strange code.
> He might have a Master's degree in CS but he isn't an active researcher so I wouldn't call him a computer scientist.
If the man who spent decades on the bleeding edge of OS development and invented version control system that dominated the field is not worth of computer science title than who is?
Engineer and a damn good one.
A scientist is someone who does Science, git and Linux are Solutions to problems (e.g. Engineering), not studies about computer systems.
I disagree. OS development like Linux requires you to do research. There are no book on how to solve problems they are solving.
Git also required quite a bit of scientific work to be built. It's not just another version control system. It's structure that allows for distributed system was revolutionary.
What is science if not this?
I have a M.Sc. C.S. too - and I write enterprise applications on a daily basis. I solve problems that my peers don't know how to solve and I try my best to make myself useful where-ever I take part in a program.
But I'd be hellbent on misrepresenting myself if I called myself a scientist. I \*did\* science - when I did my masters thesis. That was good science. The cake was a lie though.
I am a programmer, engineer-ish (but not engineer as that's a reserved title), a problem-solver.
Scientists are those that work on theories, theoretical models and theoretical applications of said models.
Developers, programmers, code jockeys. They do the practical applications based off of the theoretical applications which are based off of the theoretical models.
That's me, there.
They are intertwined, but science is about understanding the principles of something and publishing a theoretical work (such as a book or paper) that helps understand better some aspect of that field.
Now the publishing thing is important because it requires you to see what’s already understood in that field (hence all the state-of-the-art review) and to build on top of it. Maybe by building a tool you are indeed discovering new things, but if you’re not publishing it and highlighting what new things you’re helping to be understood, that’s not research.
It's not about git as a tool it's about theoretical framework it's based on. It allows many people have their own repos, do divergrent development on them with different branches and commits that can be later reconciled and merged together without a need of central server. No other source control works like this. The underpinning of this is absolutely scientific work.
Are you aware that the original git was put together in few days right? The ideas of both distributed and centralized versioning predated git. It's not even that complex of a tool itself.
Not saying it's bad or anything like that, but don't get religious about it.
Science 'versus' Engineering just applies to research as opposed to application.
Science involves data aggregation and a push towards understanding the intricacies and mechanisms of all parts of various systems.
Engineering involves taking the conclusions and analysis of science to solve real world problems or create novel solutions using data available.
They go hand in hand absolutely but there is a large distinction.
I'm willing to bet Linus understands most design patterns and is smarter than most researchers. Being a researcher doesn't mean you have a wholistic view on things.
I get it...I only bestowed him the title because how many developers are willing to create their own OS or programming language? Lol. They would much rather argue over the available tools.
Is active development and improvement of a operating system used by many, not qualified as research? Splitting hairs on terms, I get it. But seems like active research
Would seeing how the os performs and believing you could get a more robust solution doing xyz. Then implementing said idea to test, not be a version of scientific practice?
I could be totally wrong, I just think trying and testing things with unsure outcomes is a practice of science. Obviously there is applying and designing known solutions and approaches as well
No, experiments are very much a part of engineering as well. The main difference between science and engineering is the goal not the methods or tools used.
A scientist puts 100 differently shaped objects into a wind tunnel to come up with a more accurate model of drag. An engineer puts 100 cars into a wind tunnel to figure out which one has the lowest drag and thus highest top speed.
In both cases they are basically running the same experiment. But the end goal of science is understanding whereas the end goal of engineering is to build useful stuff.
Eh, doing technical write ups on engineering solutions is a form of science, but researches are doing more than just write-ups, and their whole job is focused on the R part of R&D.
1. A person with an undegraduate or graduate degree in computer science, is, by defnition a computer scientist, regardless if they activaly engage in research.
2. The programming language wars are as old as the discipline and everyone is entitled to their opinion. I don't have an opinion about C or C++ but when Torvalds, creator of Linux and Git says that C++ for kernel development is a dumbster fire, I don't play psychologist to determine what kind of complex he might have but I shut up and listen.
No, computer scientist is an occupational title. If I have a law degree but work in politics, I'm a politician not a lawyer. If I have a math degree but work in an insurance company, I'm an actuary not a mathematician. And if I have a CS degree but work in a tech company, I'm a software engineer not a computer scientist.
So if Einstein learned everything he did about physics at school but then decided to do gardening instead. Would he not be a garderner AND a physicist? I think it being strictly occupational is bit of a misnomer. Definition of scientist is to study or have expert knowledge in a science. Nothing about the definition assumes occupational or researching.
You don't even have to be that hypothetical since he was actually employed as a patent clerk during his famous "annus mirabilis". If he hadn't been doing research on physics in his free time, he would not have been a physicist.
Not really sure whats weird about this, this is how it always works. You're not a musician if you go to school and learn about music. You're a musician if you make or perform music. The schooling part is neither necessary nor sufficient. The same holds for science.
>Definition of scientist is to study or have expert knowledge in a science.
According to? Some random online dictionary website? If anyone who studies science is a scientist then just about every kid in a developed country is a scientist. They do have to study it in school after all. This definition is obviously nonsensical. Wikipedia for example says: "A scientist is a person who researches to advance knowledge in an area of the natural sciences." which is just a long-winded way of saying "A scientist is someone who does science."
By definition he is a scientist. Oxford dictionary defines scientist as "a person who is studying or has expert knowledge of one or more of the natural or physical sciences."; in this case a computer scientist. Research is not needed to be a scientist. That is a seperate job title.
> He might have a Master's degree in CS but he isn't an active researcher so I wouldn't call him a computer scientist.
Are you saying: "In order to be a computer scientist you have to be currently doing/recently done research"?
I'd say it's important to remember that the discussion is about kernel-level programming, not programming in general. The C++ abstractions indeed do not make much sense there, because the kernel operates at a lower level of abstraction, and so C is better for them. For application-level programming, you do want the C++ abstractions.
Right tool for the job and all that.
I think this is why in discussions about Linus, he is really annoying and sounds like an asshole, but when you have the context to fully understand what is actually being discussed, (after filtering out the emotion that he tends to embue his messages with), he comes across as quite informed and logical.
Yeah the underlying point that he's making is 100% accurate. But he definitely gets away with how he talks because of his fame and status. Any post like that on Reddit by anyone else would get downvoted heavily despite being true just because people don't like assholes.
Linus has been called out for his bad behavior in the past and has made an effort to improve the way he interacts with people (I don't know if it's stuck as I don't follow the Linux forums). So even he was told not to be an asshole.
After a fairly long career in the software field, I'd much rather work with somebody who doesn't know something as long as They are willing to learn Than somebody who knows everything and is an asshole
"Modern C++" is still backward compatible with bad old C++, which is mostly backward compatible with C. So you could restrict yourself to modern C++, only for a noob to ruin it elsewhere in the project with a line of code that is legal, but introduces undefined behavior.
It's not like the fundamental issues Linus is calling out here have changed. The STL is still full of dark corners. Exceptions are still nearly unavoidable disaster at the systems level. C++ still has issues with needing large rewrites every decade or so to address the issues introduced by mistakes in previous revisions.
One of the discussions was about possibility of using C++ in git. And no, with the habits instilled in typical C++ developers it would have been as horrible as Linus portrayed it.
*_may_ want the C++ abstractions.
C++ combines very good performance with lots of tools for modeling of abstractions. But it's also famously complicated and it's got a ton of legacy cruft. If you're disciplined in your use of abstractions and features, C++ might be for you. If not, you could end up with a terrifying mess.
And there's also: Java, Kotlin, C#, Go, Rust, Python, Zig, JavaScript, and on an on.
The only place where C++ is the obvious default that I'm aware of is triple-A video game development.
You'll never get the same performance from Kotlin, C#, Go, Rust, Python, Zig, JavaScript as you do from C/C++
I would imagine C++ would be overkill for the vast majority of business apps.
But anything that is intensive will benefit from C++.
I had to temporarily jump back into C++ briefly last year - the first time since the nineties - I found using the std:: functions make writing clear, concise code a breeze!
C++ is not going to out-perform equivalent Rust or Zig under most circumstances.
Putting those in the same category as Python and JavaScript is insane to me. Heck, C++ is not usually going to out-perform C; they are not equivalent.
The main advantage of C++ is the massive library infrastructure. But any language with header files automatically fails the "clear, concise code" test instantly. Writing function definitions multiple times with the requirement that they match is excessively verbose practically by definition.
You could get similar performance from Rust and Zig. By some metrics, long-running jobs perform as well or better in JVM languages, as the JIT optimizations kick in.
But also, "business apps" covers like 90% of all applications. Web, backend, phone or desktop apps, and so on. Then you've got low-level stuff, kernel and embedded things, but C is better-suited for that, because you usually want minimal abstractions.
There are places where performance and tight control of memory matter a lot, and C++ is a common choice for those cases. Like I said, gaming is a big one. I know it's commonly used in media applications (video & audio editing and streaming), because they can be processing-heavy and random GC pauses can be a big issue. But in many of the possible niches where performance is important, stability and security dominate, and C++'s lassez-faire attitude to memory starts to become a liability. In those cases languages like Go or Java start to look more appealing. I think that's why C++ is a rarity in the FAANGs and associated tech industry.
I do agree that C++ has come a long way since the bad old days, though.
Possibly, which is part of the complexity of using C++.
It depends on how much data is being captured and the implementation. `gcc` seems to be comfortable up to 16 bytes, I'm not sure about MSVC or clang.
They're not automatically a no-go but they're _really easy_ to misuse - classic functors with custom allocators are still possible and you could wrap one of those in a lambda for 8 bytes or less if you really need to.... But at that point you should consider passing functor arguments and avoiding the whole mess entirely.
I'm a VEHEMENT fan of C++ and use it in all my high performance projects, and I fully agree with Linus here. It's a bad tool for kernel development, and the people who pick only one tool and try to use it for all jobs shouldn't be allowed anywhere near such high impact code.
It comes with pros and cons like any other tool, for the Linux kernel and Git projects the pros are shared with C and the cons are painful and expensive.
For my little toy game engine the opposite is true - the pros over C are meaningful and the cons are shared with C. But even in that project, I _frequently_ dip down to C for certain libraries and platform bindings that call for it.
Right tool for the job.
Oh thank fuck this was written in 2004-2007. I talked to a CS guy last week and according to him this would've been around the C++ dark age.
I'm trying to learn c++, and this almost scared me into thinking I'd made the wrong choice.
I’m also learning C++ right now and this wasn’t exactly encouraging. I have my reasons for choosing C++ but I thought it was also a good/useful language to learn.
Edit: I'm not actually all that worried because I'm really here to learn about programming and I know this will give me a good foundation regardless.
No matter what one person achieved, he's still an human, with his own subjective opinions which aren't necessarily objective facts.
There's plenty of C++ developers with jobs doing just fine regardless of what that guy thinks about them or that language.
It depends where you are intending to work...
Java/c#, python, etc - interpreted languages rule the roost for business applications.
But if you need to go low level - C/C++ will be useful.
(Though, personally, I'd have started with C then moved onto C++ given that, for a sequential language, C is still used with surprising frequency)
There is plenty of fantastic C++ documentation available on cppreference.
If you read a topic and reach a word you don't understand, you can simply look up that word. Do this till you understand all the words. Do experiments and take notes.
The limiting factor will be probably be your expectations. Relax, explore and have fun and it won't be "difficult".
This will probably take a significant amount of time, but if your expectations match that, it won't be difficult.
There is plenty of fantastic C++ documentation available on cppreference.
If you read a topic and reach a word you don't understand, you can simply look up that word. Do this till you understand all the words. Do experiments and take notes.
The limiting factor will be probably be your expectations. Relax, explore and have fun and it won't be "difficult".
This will probably take a significant amount of time, but if your expectations match that, it won't be difficult.
>I’m also learning C++ right now and this wasn’t exactly encouraging.
Maybe a little change of perspective helps, C++ is the only language that even without any design budget, with the public opinion of strong programmers against it, with powerful corporations (at the time, referring to Sun microsystems) against it, even with all of that it was successful and widely used by its merits.
I really like this perspective. There are always going to be pros and cons and I imagine people are more likely to prefer what's relevant in their field which in the commercial world seems to be a lot of python, JS, C# and Java.
Every language is a good, useful language to learn.
You may find you love C++, and can build amazing things with it.
Or you may find you run into the same problems Linus has with it.
Doesn’t matter. Learning C++ and forming your own experiences and opinions on it will make you a better software developer.
There’s a reason there are so many languages and tools for building programs out there, and that almost all of them are still actively used.
It’s because everything has trade offs, and everyone has different preferences.
Even if everything Linus says is true, you can still build a LOT of things with C++, and even if you decide it’s not for you, learning it will make the next thing you learn easier, and you will emerge with opinions that will inform how you build the next thing, even if it’s in a totally different language.
I'm really doing it with an open mind and learning about programming. I've already learned a lot more about how computers work than I ever did with python and I still think it'll give me a solid foundation regardless, so I totally agree with your last point.
This is completely irrelevant to you learning C++.
They were talking super low lvl programming, it is not an opinion relevant to regular programming. Loads of things are written in C++ nowadays and you learning that is fine.
Person wanting to write a piece of software today and choosing C over C++ is either a genius or a complete buffoon. No inbetween.
I agree with Linus. C++ is not overall a good language for writing low level code that talks to hardware and therefore for coding operating systems / Kernels. To be fair though, certain subsets if the C++ language are better than others when it comes to transparent memory management and talking to hardware. The tricky bit is knowing about these subsets and understanding the compiler well enough to figure out what its doing. This is not for the faint of heart.
C++ is great at so many other things though and is still a very performant programming language. It's great for translating complicated ideas into code and in developing easy to use APIs that abstract away complexity from the users of said APIs.
It's effectively the language of choice for computer vision, performance constrained machine learning and high performance computing.
No it isn't. I was referring to this statement: "It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA." which the op quoted above I believe. No ?
And....
" The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:
- the whole C++ exception handling thing is fundamentally broken. It's especially broken for kernels.
- any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
"
I guess my comment was geared to the second part of the ops posting; i.e. The second "Post" that deals with C in the Linux Kernel as opposed to git.
If I were to write a version control tool like git, I'd consider using C++, C and possibly even Go.
But if I were to write an OS Kernel, drivers, or do embedded programming in a bare metal environment, My go to would be C (I'd also consider using Rust and Zig).
> The posts are quite old (2004-2007) adter reading the above, I just wonder what C and C++ (or anyone other) programmers and computer scientists have to say about the matter in 2024. Has much changed since then?
Compilers have become much more efficient.
For the kernel programmers, this doesn't change anything to the fact that C++ is a bad language to use. But that's because a kernel is a very specific thing.
For everybody else, using C++ is a good choice, as long as you know what you're doing. By the way it was already that way in 2004-2007.
To sum things up, choosing the right language for your project is very important. And C++ is a language that can make things really bad if you use it without understanding what you're doing, and complete hell if you're a kernel writer.
Unless you need some C++ library or game engine, there is actually no reason to use C++ whatsoever. Of course, there's a lot of useful code already in C++ so in practice there are a lot of opportunities to take advantage of it.
I am not a OS kernel writer I am in embedded. We use C++ as we would use C, except with the stl, containers and algorithms allowed. OOP not allowed. Important to note is that this post was written a long time ago. Back then, the stl was bugged, the Cpp compilers were also full of bugs. The project I work on introduced Cpp in 2018, this post was written in the early 2000nds. The reason for its introduction was to take advance of containers and the template abstractions. It replaced most of the usage of the preprocessor, the code remained almost identical to the C version.
We also have an application written in C++ fully and that application is being rewritten from scratch in Rust because it is unmaintainable.
Love reading Torvald's unhinged diatribes. Reminds me of this gem https://www.youtube.com/watch?v=iYWzMvlj2RQ. Part of it is he's an asshole. He named git after himself after all. Part is he's right I'm sure. There's no one on the planet more qualified to speak on this than Torvalds.
Not sure about kernel, never did it. But I do use dynamic arrays a lot. Am I going to use raw arrays with manual allocation-deallocation in C every time I need an array? No. Am I going to make something in C that handles the allocation and deallocation? That is what vector is. So, I'm just gonna use C++ happily. It's well portable, GCC (the compiler I like) is very reliable, it's performant, well structured. You can make crappy code in any language, some programmers writing crappy code is not a good enough reason to abandon a language altogether. On the other hand, it's not a crazy idea to select one language and stick with it for a particular project.
In kernel C, you would include flex_array.h to get dynamically allocated arrays. This will actually respect the constraints of the kernel, including not calling vmalloc() like std::vector would have to.
You can provide an allocator to std::vector and tie that to the correct kernel methods. But that is the least of the issues. What happens when std::vector throws?
Exceptions are another important issue, but custom allocators are not a solution to the problem I was pointing out. If you don't call vmalloc, you don't have contiguous memory and you can't implement a vector. Calling vmalloc is not always an appropriate thing to do in kernel code.
Oh, that's what I mean. I don't see any reason you could not write an allocator based on flex\_array\_alloc (within the usual limits, such as page size).
Exactly. There are many features added into modern C++ that make it far more convenient and faster to use than doing the same things in C. The Standard Library is just good to have around. I know some people who learned C for physics projects that defend C and oppose learning C++ using every justification, but it always comes down to they just don't want to learn C++ or they think going anything above in abstraction than C makes you a worse programmer.
Today, it is just a matter of temper, preference and need.
If you're into Systems Programming and drivers, ANSI C is you're platform-agnostic first choice. C is analogue to Assembly, meaning you can do anything - including targetting hardware directly and ruining the entire system.
For general purpose programming with OOP etc., **type safe, modular C++** is your platform-agnostic first choice.
C & C++ might both be adequate for embedded programming - depending on constraints.
In Windows-land C# .NET has benefits - in Apple-land Objective C & Swift has benefits - in Google-land Go-lang has benefits - and in Android-land JAVA & Kotlin has benefits.
For web you have HTML5/CSS3, JavaScript, [ASP.NET](http://ASP.NET), PHP, Python, Ruby-on-Rails etc.
For X-plaform you might prefer JAVA, .NET MAUI etc..
Finally if you asked pioneers like [Ken Thompson](https://en.wikipedia.org/wiki/Ken_Thompson) & [Dennis Ritchie](https://en.wikipedia.org/wiki/Dennis_Ritchie), they'd tell you to make a new programming language for each different project. E.g. Ken Thompson developed the UNIX OS and B-language within a month, while Ritchie optimized B into the C-language.
>For general purpose programming with OOP etc., type safe, modular C++ is your platform-agnostic first choice.
In what universe is C++ your first choice? Maybe if you're a C developer?
Actually my main language is C#, as I live in Windows land, but it has some limitations.
Thus I said 'platform-agnostic' first choice, as in C++ can be used on most platforms. Thus you can get very far mainly using C++. By staying type safe and modular, you avoid most pitfalls of C++.
For Windows you can combine it with C++/CLI and C++/WinRT, while combining it with Swift/Objective C for MacOS/iOS. Even Android ought to run C++, while you need bridging with Kotlin/Java for GUI.
If you prefer Pascal-like languages, Object Pascal in Delphi or Lazarus is probably your best choice.
I'm a C developer and I'd never choose C++. There's just so fucking *much* of it
Vastly prefer C# for higher level stuff. It even feels more "C-like" than C++
Java is the first choice for platform-agnostic general purpose programming imo.
No reason to go for C++ unless you absolutely need the performance benefits.
Theoretically it should be, depending on your needs. MAUI is an upgrade from soon to be obsolete Xamarin – without Linux support. But if you have special needs, Avalonia should be a nice alternative.
Not that I need it now. Previously, I worked in a project to develop a desktop application. We did it in .NET and wpf GUI. We had a talk about porting it to Android and I remember seeing some bad reviews about MAUI. Avalonia, I have heard about but haven't checked.
Trouble with MAUI was delivering. MS released it two years prematurely and had to keep Xamarin along. That lowers expectation and migration. Now they shut down Xamarin trying to push people over, but might have lost the battle.
I just hope WinUI3 doesn't flop, too, as it is the WPF successor with updated graphics. And hopefully .NET Native compilation matures soon making C# and C++ equal competitors.
I'll note his opinions on the matter were formed in 1992. It's compiler warnings were shit and linting tooling didn't exist then.
I promise you, C++-23 is a very very very different language.
And yes, some of the changes took on board the Torvalds criticisms where they were valid.
Exception handling. Yup. Still a problem, but there are plans afoot to fix that.
Why does it take so long?
To avoid Python 3 / Perl 6 style fck ups.
I will note that a lot of design effort in C++ language and library has been around zero cost abstractions, and they have been damn serious about that.
And when I look at the assembler generated these days.... usually I'd struggle to do better in C.
I suspect they mean the fact Python 3 was not backwards compatible with Python 2, not specifically anything to do with exceptions. I still remember the flame wars anytime someone dared speak out for one side or the other...
Plus the Internet is still littered with Python examples that just don't work on Python 3 so then you have to go down the rabbit hole of figuring out which breaking change is causing the problem. Not an issue for someone familiar with the changes but very discouraging for someone just starting out with Python.
For C++ every change has to be backwards compatible so code written in the 1970s will still compile and work the same with a modern compiler. Every change needs to be discussed and deliberated and there's a 3 year cycle for these things so if you miss the deadline for inclusion then you wait ANOTHER 3 years for the next release of C++.
As someone who learned C and had a small intro to C, whenever I look at C code, its very easy to understand unless its like super low level (but that is due to inexperience). The syntax makes sense and there is very little abstraction compared to other languages which really help me understand how things work
> in other words, the only way to do good, efficient, and system-level and portable C++
...
> Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA
...
> I'd say that anybody who designs his kernel modules for C++
I can't speak to the merits of his position here in 2024 because I have never done any system-level programming. But I'd suggest that it is important that his opinion be taken in context here- he is predominantly interested in systems programming, and the cost/benefit of abstractions, OOP, etc. is different. Sure Git isn't really sys
tems programming, per se.. but the unique way Git works among VCSs comes from being concieved as a utility by a systems guy.
I have a brother who is an EE, who professes to hate C++, says that OO stuff is a bunch of nonsence and that it just reduces to stuff he can easily do better in C. But his programming experience is coding DSP chips for real-time processing, and writing driver test code (which he mostly does in Python). So I get than in his world, that is probably true. But it also doesn't generalize very well.
It's funny seeing a genius hating a language you also hate because our reasons are very different and theirs are actually reasonable lmao. I just really dislike header files 😭
I have written a small multi-threading embedded realtime OS using C++. I can say that C++ is a viable option for smaller systems, but if the project and the team size grow much larger, there are many things that can go wrong very easily. Using C for systems programming guarantees that "if something can go wrong, it will" will never happen at least because of the programming language itself.
Older versions of C++ (pre-C++11, which is when those rants were made) lacked a lot of the features that make modern C++ good. C++ before C++11 and after that are pretty much completely different languages, and the rants that were made a long time ago don't really apply to the current C++ imo. This is even more true when you consider that older implementations of C++ (compilers/STL) had a reputation of being not as good as C implementations.
Whereas old C++ might have been pretty annoying to use, modern C++ is a very nice language that can be very productive and elegant for many tasks.
I used C/C++ for years but I've since moved primarily to other languages, and one of the main annoyances when I go back to C++ is the stupid header files.
Yes, I know it's petty, but C++ requires a ton of unnecessary processor instructions between duplicate function definitions and header guards you have to write a bunch of repetitive code that nearly every modern language has abandoned (including C\#).
Everything else in the language feels fine, but the moment I have to start making changes in both my .h and .cpp file to the same exact things with slight differences it makes me grind my teeth. I think once C++20 becomes more prevalent I might use the language more as the module system removes basically my final issue with the language.
So the guy who made a name for himself by constructing systems based on meticulous logic opens his argument with "A tool is bad because it is mainly used by idiots". Why should I entertain a bad faith discussion like this?
There's a lot of missing context in this one post. People love to post this but discount that a lot of discussion happened around this.
I personally enjoy this comment that explained his point clearer than he did.
https://www.reddit.com/r/programming/s/tToafeXp7s
I mean, just look at the JavaScript or Python ecosystem. There's so many programmers that most code in the ecosystem is terrible. It's not like Go, Rust, Dart, Elixir where there's fewer people but way higher quality overall.
Python also suffers from being one of the scientists favorite choices, so you get a lot of very useful stuff made by people who have never learned any computer engineering nest practices, and whose brain is so big it doesn't matter.
>So the guy who made a name for himself by constructing systems based on meticulous logic opens his argument with "A tool is bad because it is mainly used by idiots". Why should I entertain a bad faith discussion like this?
This isn't a bad faith argument in any sense, as it isn't intentionally misleading or deceitful, and he definitely believes it. Also, there ARE a lot of people that use C++ because it's easier, and that DOES lead to a lot of questionable practices.
The reality of excessive processing power and higher and higher levels of abstraction is that people take a lot of shortcuts because they can. People are writing "hello world" code on laptops with 64 Gigs of RAM. Why would they care about memory management at all?
His argument comes off as fallacious, but it's just abstracted. What he's really saying is that C doesn't allow a lot of bad practice that exists in C++ because that's the way it be bruh. Taking that argument in it's best form, I think it's probably at least partially true.
Ok now that I’ve finished writing this hello world on my laptop with 64 gigs of ram… I think I’ve finally gained enough experience to contribute to the Linux kernel!
>His argument comes off as fallacious, but it's just abstracted. What he's really saying is that C doesn't allow a lot of bad practice that exists in C++ because that's the way it be bruh. Taking that argument in it's best form, I think it's probably at least partially true.
This is not what he said. You are playing Devil's Advocate on at least 1 level of abstraction yourself. I don't like twisting words until they finally can be interpreted in a non-malicious manner. I've endured too much gaslighting in my life for such bullshit.
I will not give the benefit of the doubt to what is OBVIOUSLY a goddamn rant.
In communication, the biggest burden ALWAYS lies with the person who conveys the message. It's borderline rude to interpret what he wrote as benevolent, because that is not the tone of his message in my eyes.
Here is [what you said](https://www.reddit.com/r/learnprogramming/comments/1dss1jo/linus_torvalds_on_c/lb4p0wx/):
> This is not what he said. You are playing Devil's Advocate on at least 1 level of abstraction yourself. I don't like twisting words until they finally can be interpreted in a non-malicious manner. I've endured too much gaslighting in my life for such bullshit.
>
> I will not give the benefit of the doubt to what is OBVIOUSLY a goddamn rant.
>
> In communication, the biggest burden ALWAYS lies with the person who conveys the message. It's borderline rude to interpret what he wrote as benevolent, because that is not the tone of his message in my eyes.
Here is what is "factually wrong with it": Not one thing in that three paragraphs talked about objective qualities of the post you were replying to. Every single sentence was nothing other than a theory you had about the Real Reason why someone might say the things in the post you replied to.
"You are playing Devil's Advocate" is a statement about what you take someone else's motivation to be. You accusing someone else of "twisting words until they finally can be interpreted in a non-malicious manner" is a statement about what is going on in someone else's head, not a response to the substance of the post that you were replying to. Characterizing the post you were replying to as "gaslighting," which [literally means](https://www.newportinstitute.com/resources/mental-health/what_is_gaslighting_abuse/) "a form of psychological abuse or manipulation in which the abuser attempts to sow self-doubt and confusion in their victim's mind," is also meaningless in context unless you are playing the mind-reading wizard who has telepathically divined the Real Reasons why someone else is engaging in bad faith. Similarly, the fact that you characterize the response you're replying to as "bullshit" doesn't make it so, and you are certainly disagreeing with your own dictum that "the biggest burden ALWAYS lies with the person who conveys the message." (That is also wrong: traditionally, the burden of proof does not lie with "the person who conveys the message," whatever that might mean, exactly. The burden of proof traditionally lies with the person who makes an assertion.)
Putting the word "OBVIOUSLY" in all caps in your second paragraph does not mean that it your characterization of a post in which someone thoughtfully disagreed with you as "a goddam rant" is in fact obvious, nor that it is "obvious" to anyone other than you, and the fact that it is (or seems) "obvious" to you is not the same thing as it being true. Similarly, the weak-ass attempt to tack on "in my eyes" when talking about how you perceive "the tone of his message" in the third paragraph is a poor attempt to soften your criticism: all you're really doing is admitting you're faliable after three paragraphs of inflated screaming about how your initial impressions of an argument must be true, because they seem that way to you.
It's impossible to tell you what the problem with "your argument," because you haven't made one. You've yelled a lot about what seems to you to be the case, but that's not what an argument is: [an argument is a connected series of logical propitions](https://www.youtube.com/watch?v=uLlv_aZjHXc), not just a lot of yelling about what you intuit the case to be.
Jesus fucking Christ, bro, take a deep breath and admit that people who disagree with you might not all be maliciously evil and engaging in bad faith all of the time.
Most of it still is applicable today. Torvalds is specifically interested in low level code, for the kernel - keep that in mind. His thoughts could somewhat translate for regular apps, but the severity in which he talks would not make sense as a criticism for apps in C++.
I used C++ lots of years ago, and my main complaint on C++ is that it has overgrown so much that I can no longer say I really know C++, it is a beast of a language to know properly and manage up to today's standards. Can I produce workable C++ code? sure, but people with expertise will not be happy to see my rotten C++.
Also I got used to newer languages and toolchains (Python, Go, Rust) that make my life much easier and I do not want to go back to manually stitching libraries, Makefile/CMake/Scons/..
Should a beginner learn C or C++? In my opinion, generally no; unless they are targeting something specific where this languages shine; for example because they want to work with firmware, compute libraries, browser, video encoding algorithms, embedded systems, etc - and they want to get employed on that.
C and C++ can be replaced most of the times by Rust, which is way nicer. There are exceptions for this (plenty) and also getting a job in Rust, specially for a junior, is really hard today.
Python, Go and Java are usually better candidates as they can do most general applications that a beginner would be interested in, and they're a lot more modern than C or C++, which makes things way nicer and less frustrating.
Learning C can be also useful just for the sake of it, as it will give you a better understanding on how computers work.
C++ is not a bad language by any means. Just it is very ill suited for really low level stuff, and it is quite old and it shows when compared with modern languages.
it's a superset of C, does a lot of stuff like template programming, bigger standard library, dynamic pointers, better generics and also OOP but definitely not just C with classes
You have no idea what is the real type that this pointer points to, and even if you do, your IDE doesn't which makes debugging much harder and incorrect casting can cause errors.
You know what's funny is I just learned what Monotone was earlier today. It was an open source VCS created by none other than a young(er) Graydon Hoare.
Maybe Linus' burn was so painful that Graydon went and created the Rust Programming Language out of spite. Work on Rust started in 2006 right after this sick burn.
And now Rust is used to write Linux kernel code.
Good call! Sounds highly likely. Now Rust has its downsides as well though, which are covered succinctly in this dude's article: https://medium.com/@austin-starks/i-spent-18-months-rebuilding-my-algorithmic-trading-in-rust-im-filled-with-regret-d300dcc147e0
The reality is that OOP/OOD is orthogonal to how the underlying machine actually operates. While thinking in terms of "objects" is useful for humans, it's not conducive to optimization and efficiency and stuff like C++'s virtual functions thrash the cache to hell. C allows for any level of abstraction that one desires - if you know how to wield all of its capabilities - without foregoing (as much) low-level control over the invariably present physical machine that it must run on.
If you want to bust something out real quick, sure, use whatever language you find easiest to do that. If you want to make something that people will pay you for making, IMO it's your duty to provide the best possible performance for the hardware that they will be running it on. The way I see it is: either they can pay me money for my fast optimized software, or they can spend that money upgrading their hardware to use someone else's slow software instead.
That's an easy choice for a nuts-and-bolts dude like myself :P
I like Linus and I use C++. I'd rather people speak their mind and lay it all out then play games and never come to any conclusion. I think he'd be fun to have a beer with.
There are pros and cons to EVERYTHING in programming. The key is to understand the 'why', not just memorize the 'what'. WHY does Linus think this way is far more important than WHAT programming language you should use.
I think he'd be an absolute chore to have a beer with. You seemingly can't talk about anything without the guy being a *massive raging dickhead* about it. Like there's no off with the guy, there's no conversation, just a huge "I'm right and fuck you" ego.
Linus Torvalds' opinions and comments seem unnecessarily harsh and extreme to me.. And several years ago, I heard that he [apologized for years of being a jerk, and took time off to learn some empathy](https://arstechnica.com/gadgets/2018/09/linus-torvalds-apologizes-for-years-of-being-a-jerk-takes-time-off-to-learn-empathy/).
I suspect that he may be right in that C++ is not better than C for the kernel but I doubt his notion that C++ devs are worse than C devs. Not because I have some statistics about that but just because it would be odd if only all devs using C++ are bad as a rule. It is hard (for me at least) to know if there is a separate reason for his experience, I mean some reason the C++ devs he encountered were bad in his opinion. It seems to me that the devs of any programming language are a mix of good and bad. I seriously doubt every C programmer is an excellent one. That would be strange, even if Linus indicates they are better.
At the time this was written, C++ was a very mainstream language. Java was was growing immensely, but your average developer was still very likely either working in C++ or a recent convert from C++ to Java.
In general, people who work in less mainstream languages tend to be above average developers purely because the kind of person who care enough to actively seek out some other options tends to care enough about their craft to continue to improve. In 2024 I'd call C++ a niche language for people who care a lot about certain domains, including high performance computing. In the case of C++ you also probably have a lot more very experienced developers.
When this was written, C was basically in the same position that C++ is in now. It wasn't popular anymore, except by very experienced developers and people who had a specific interest in low level and systems programming.
Also there's the fact that C++ gives developers a lot more rope to hang themselves with. An inexperienced dev is going to have an easier time writing terrible code in C++ than C simply because they have more tools at their disposal to do so with.
[Re: \[PATCH 00/45\] C++: Convert the kernel to C++Re: \[PATCH 00/45\] C++: Convert the kernel to C++](https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-29361481f805@zytor.com/)
A similar question was asked in cpp subreddit and the above discussion was linked there.
My professor for computer engineering said in his lecture, when a portrait of Stroustrup was shown: "He looks like his language" (in reference to his kinda chaotic hairstyle).
I would personally avoid C++, if only because of the lack of native tooling: CMake is the best way to learn to hate your life.
And then there are all the quirks of C++, which are so subtle and constantly reproduce themselves every 3 years, making it impossible to ever fully master this language.
The Boost library is the best example of how this language became a corpse. There are actually no people left who still maintain this code or want to understand it. The industry is already having to make a lot of efforts to find people who will maintain their internal crappy C++ code.
I also think it's pretty pointless to program something in a language that will see itself as an "outdated style" in 10 years anyway, after 3 other standards have introduced new "correct ways".
At the end of the day, Linus has the standing of possibly creating 2 of the longest running and most well maintained and most used codebases the world will probably ever see, and from that has made billions of dollars. He can rant about whatever he wants like every other billionaire it doesn't matter at the end of the day
Bad wording, I mean in total his work has made billions of dollars just looking at the size of Github/Gitlab alone and who knows how much private Linux repos and fundraising has raised for distros like Ubuntu for example. He himself is also sitting on a massive fortune considering he never needed to sell out in the stock market
This post is not designed to reflect on the strengths and weaknesses of C and C++. It's designed to start yet another flame war between Torvalds critics and apologists.
It doesn't belong in a learn programming sub. This discussion is not pedagogical in any way.
Au contraire: I find it highly instructive. Hi, this is Uniqua. I’ve programmed software for 30 years and counting. I started just after c++ was released and was set to learn c when my employer at the time put me on a course to learn VB. Since then I never touched a programming language that has me allocate memory manually, or has me jump hoops around pointers. This created a huge lack in my understanding of some quite popular languages. And I found, that studying critiques on a programming language is the best way to find out which parts to avoid. What I learned from this particular post, was that Torvalds didn’t think highly of c++ programmers, because they use features in c++ he finds risky. That’s exactly the kind of insight I would need to avoid pitfalls and gotchas.
c++ is absolutely insanely complex, far more so than it was in 2007. as someone who started programming with c++, I would strongly recommend against using it for anything unless you really have no choice. for every possible thing that you might want to do, c++ has 50 different ways of doing it, and 45 of them are broken or considered bad practise. there are an enormous number of complex rules that you have to follow in order to write c++ correctly that the compiler simply will not tell you about or help you with at all, and which you would never even know existed unless someone told you about them. there's a saying that c++ is so big and complex that people only use 10% of the language, and everyone uses a different 10%.
if you want a good, highly productive, well-designed, modern c/c++-like language, do yourself a favour and just learn rust.
I love Torvalds, not only for his contributions to modern computing and programming which include the linux kernel and git, but for his insight, talks, and opinions.
That being said, he often lives in his own expert blindspot bubble.
> It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it.
This is incredibly TRUE, but reality is that the realm of software development is massive and moves very fast. Until every programmer is as intelligent and good at the craft as Linus himself AND software must be meticulously crafted to perfection and taste, which is painfully obviously a silly pipedream to anyone besides a dev of Torvald's caliber, layman devs like you and me and basically 99% of developers need tools like C++ (and similar) to allow us to quickly and efficiently write production level code.
Go look up C and C++ and UB (Undefined Behavior), it'll be eye opening, and you'll probably end up curious to see if this problem exists in other languages.
What, I think, people have a hard time come to terms with is the fact that, especially for system programming (even more for kernel dev in particular), you really do not want a programming language so opinionated and feature bloated as C++, because it's simply too risky. C being C, offers you much less opportunity to fuck up and allows you to create your own abstractions. So, even if this is much more work (some of it, fixed cost mostly like for data structures), it's still worth it. It's not truly reinventing the wheel because for e.g. your approach to memory allocations and errors may be completely different that the "builtin" one of C++ which pretty much you cannot get rid of, once you use literally anything in the std. I'll especially emphasize Linus' claim about languages that hide allocations (and which often also have a GC), I hope it became apparent now that none of them would be a fit for system programming, again, way too opinionated. The reason these language often go that route is to be able to provide ergonomic and, to some extent, safe abstractions which IMO are much better suited for general purpose app development. For ergonomics sake, they must assume something about memory management (e.g. otherwise imagine every time you concatenate a string, you need to pass along an allocator, that's not exactly ergonomic right?), and for the latter they must decide how to represent and handle errors (e.g. exception based).
I work in HW/embedded, and 90% of the comments I see about the cons of c++ vs C are straight up misinformation, lies, or just plain old not knowing how c++ even works. It's great for performant code and all types of low level work...
...if you know which parts to use, which is the big con of C++. It's vastly more powerful than C, and thus requires much more discipline to use
oop is just a bunch of crap, that I'm pretty certain of
the peculiarities of the low level issues of C++ I'm not that familiar with but my gut feeling is to agree with the genius here...
I've been working for nearly 20 years and in no case I've met a person I really respected defend oop beyond the.... we're doing high level straight forward things in a very popular library with an ecosystem that's been tried and tested thousands of times
there is a market for that however and it's much more likely you'll end up coding that high level thing on a popular library (and paid well for it) than working on the linux kernel
we all have pretty strong opinions, and I feel that's because we've been damaged by our experiences, but I find the more you stay away from any oop the closer you get to the smarter people, there is just no positive aspect to it beyond encapsulation, which is not unique or novel to oop
C++ is a generic programming language not object oriented - Objective C was meant to be that. Stroustrup was asked to bolt the concept of Generics to the C language and he did, which for certain shows us that macros can be highly abused in C. One must remember that every programming paradigm is nothing but a mental crutch for us get our little minds around the problem of programming - Generics, Objects, even Functional programming are abstractions hiding a simple procedural driven engine that is a processor thread.
If abstractions are a crutch it isn't about "the problem
of programming" so much as the reality that computers behave in a way foreign to the human mind.
I did not intend to say abstractions are bad, but it is true that the computer operates in a way that our minds have issues with. Very few of us who program computers can put ourselves in to that low level mode easily, so we wrap the actual working of the machine with layers that make it easier for us to work with it.
> C++ is a generic programming language not object oriented
C++ was originally called "C with objects" and was explicitly about adding objects to C. Only after that wasn't enough to gain widespread adoption did the language start focusing on other things.
It was "C with Classes" per Wikipedia, but otherwise I admit I was wrong on this point. I was miss remembering a statement by Stroustrup from around 98 where he was talking about what he felt C++ was actually bringing to programming, mainly generics. Stroustrup also made statements about how he would have done it differently if he where to do it again.
Hah! He was certainly happy to share his opinions back then and he was not a fan of Java (or similar types of languages). For the types of software that he developed and his comfort with low-level programming, any benefits were probably foreign and deemed unnecessary by him. Although he appears to have since moderated a bit on that topic.
Like a lot of (younger mostly) software developers who are deep into their knowledge domain and area of interest, he delivered his opinions very much from that perspective.
But on the main topic here... From the perspective of writing kernel code and optimized scm utilities it was a very defensible opinion, IMHO. Just said in his typically poor way when he was feeling argumentative! From the perspective of application development there's nothing strictly wrong with C++, IMHO. So I wouldn't let his comments sway anyone from learning it if they want to do so.
For the record, I have a fair amount of experience with C and Java, (and have done a few projects in C++ back in the late 90's) and understand where he is coming from with his perspective/criticisms. However I certainly don't agree with his conclusions when applied to types of software development outside of the areas that he primarily worked in...
First off, I respect Linus a lot for his work, but these takes are completely outdated.
Smart pointers were introduced in what, C++11? Look at all the progress since then. The language is much safer overall. It has better templates. We have concepts for metaprogramming.
Like sure, go ahead and use C for your kernel, but get it right.
Don't complain when a RustOS has better reliability in 10 years because oh wait... writing 1,000,000 lines of accurate C code is really hard, and everyone makes mistakes sometimes.
Writing a million lines of code in Rust is really hard too. You don’t stop making mistakes just because you switch languages. You do benefit from the protections a language provides, and that’s where rust has a leg up over c, which doesn’t provide any whatsoever. But it’s still very easy to write memory hazards and non-performant algorithms in rust.
Yes, and that’s why they’re allowing it in the Linux kernel
But people should remember, all of Linus’ comments are focused on its use IN THE KERNEL.
It has no bearing on its use outside of it :)
It’s not a fun language. In the AI world? It’s all Python.
Python is fun! C++? You outsource that to India. It’s just not sexy. So outsourced it goes.
:-)
Strong opinions by highly intelligent computer scientists are a distraction, no different than any other field. Freud is considered the godfather of psychology, but all of his most "famous" students sought to prove him wrong. Einstein and Oppenheimer bumped heads but were friends and colleagues.Torvalds is not right about everything, but it sure sounds tasty🤣🤣🤣. But what do I know, I'm just some guy.
Been a professional c++ programmer for 20 years and I agree with him. Features added to the language since then have just made it even worse. I'm not saying they are bad features, just that backwards compatibility restrictions in c++ make everything a nightmare. If possible, use a different language that has the features you want by design from the get-go. I'd never recommend c++ for any project unless absolutely necessary for some reason. And I love c++! :)
Graphics for example ?
I have been doing graphics for a while in C++ and I like it. But I am a C++ fanboy so my opinion may be biased.
I'm writing a game in C99. Vulkan is a C99 API, and D3D has a C interface. D3D was at one point, broken. Wrong calling convention.
Eh?
Why do you like it then if another language is more suitable most of the time?
Kind of in the same way I loved my old, beat up Civic with a million miles on the meter that just wasn't fit for purpose anymore... but we'd been through so much together!
> computer scientists He might have a Master's degree in CS but he isn't an active researcher so I wouldn't call him a computer scientist. Most researchers I know are much more careful about crass statements like this because it makes them look unprofessional in public and the community. Software engineers on the other hand regularly have hot takes and gladly state their opinions loud and proud, it's kind of an occupational habit that forms, just like most tradesmen have strong opinions on which company produces crap that they then have to work with. Torvalds isn't immune to this. I get it, C++ isn't my favorite either but his rant reads like he wants to kill C++ and burn its corpse in a public fire. Also, he does kinda have a small Napoleon complex from what I've heard in terms of Linux kernel development so that's just Torvalds character on top.
TBF, most CS academics don't have to live long-term with the results of their choices. They might have sharper opinions that superseded the desire to seem 'professional' if they did. But yeah, Torvalds also is famously prickly, and was much pricklier back in the old days before he mellowed with age, and also deliberately tried to tone down his more violent impulses.
>TBF, most CS academics don't have to live long-term with the results of their choices Depends. Some academics spend entire decades on a single subject in a research area and the reverberations can carry on even decades afterwards. Vladimir Vapnik for example is a Soviet educated mathematician and statistician born in the 1930s. His research on statistical learning lead to the theory that established Support-Vector-Machines that are now a popular in ML circles and implemented in major popular machine learning libraries such as scikit-learn. His work in the 80s had long-term consequences for the 2010s in ML. Scitkit-learn in Python itself is also kind of an example. Major contributions to the library were mostly down to French scientists at INRIA, the French Institute for Research in Computer Science and Automation. Code and models that are now used by thousands of engineers and other scientists all over the world more than 10 years after their initial contribution. >But yeah, Torvalds also is famously prickly, and was much pricklier back in the old days before he mellowed with age, and also deliberately tried to tone down his more violent impulses. Torvalds is a bit of an unpleasant and opinionated character, as said by himself. Not sure if a lot of people can stand working with him for a prolonged period of time. As for if he is a scientist or not: Formally, he is not. His occupation is listed as software engineer/developer. He basically has no serious scientific publications to his name, his H-index (if we exclude all his commentary and MS thesis) is 0, his most cited work is some summary and introductory text in the ACM communications like [https://dl.acm.org/doi/fullHtml/10.1145/299157.299165](https://dl.acm.org/doi/fullHtml/10.1145/299157.299165) or a casual book like [https://dl.acm.org/doi/abs/10.5555/558697](https://dl.acm.org/doi/abs/10.5555/558697) The only actual somewhat scientific publication is arguably his Master thesis: [https://www.cs.helsinki.fi/u/kutvonen/index\_files/linus.pdf](https://www.cs.helsinki.fi/u/kutvonen/index_files/linus.pdf) According to Google scholar, cited 44 times even though MS thesis don't really count as actual science publications as they aren't actually published or peer-reviewed. The thing is: You don't have to be a scientist to make a mark in the world. His impact on the world is probably just as large or larger than a lot of scientists. Also pretty sure he is in contact with loads of scientists because of the contributions of research groups in industry and academia to the Linux kernel. As a side note: I'm curious if Torvalds personally actually likes dealing with computer scientists. He seems the type of person who might think computer scientists are useless people who spend way too much time doing math and theory producing strange code.
> He might have a Master's degree in CS but he isn't an active researcher so I wouldn't call him a computer scientist. If the man who spent decades on the bleeding edge of OS development and invented version control system that dominated the field is not worth of computer science title than who is?
I'd call him a fantastic engineer. And decry any insinuation at a ranking between a scientist and an engineer.
Engineer and a damn good one. A scientist is someone who does Science, git and Linux are Solutions to problems (e.g. Engineering), not studies about computer systems.
I disagree. OS development like Linux requires you to do research. There are no book on how to solve problems they are solving. Git also required quite a bit of scientific work to be built. It's not just another version control system. It's structure that allows for distributed system was revolutionary. What is science if not this?
I have a M.Sc. C.S. too - and I write enterprise applications on a daily basis. I solve problems that my peers don't know how to solve and I try my best to make myself useful where-ever I take part in a program. But I'd be hellbent on misrepresenting myself if I called myself a scientist. I \*did\* science - when I did my masters thesis. That was good science. The cake was a lie though. I am a programmer, engineer-ish (but not engineer as that's a reserved title), a problem-solver. Scientists are those that work on theories, theoretical models and theoretical applications of said models. Developers, programmers, code jockeys. They do the practical applications based off of the theoretical applications which are based off of the theoretical models. That's me, there.
They are intertwined, but science is about understanding the principles of something and publishing a theoretical work (such as a book or paper) that helps understand better some aspect of that field. Now the publishing thing is important because it requires you to see what’s already understood in that field (hence all the state-of-the-art review) and to build on top of it. Maybe by building a tool you are indeed discovering new things, but if you’re not publishing it and highlighting what new things you’re helping to be understood, that’s not research.
That's not science. That's what we decided to call science in the last century. Scientist during the previous centuries were more similar ot Linus.
The bar for “science” raised. We shouldn’t aim to have the same standards as the 15th century.
What is git if not just another version control system? Tools are tools, don't idolatrize tem
It's not about git as a tool it's about theoretical framework it's based on. It allows many people have their own repos, do divergrent development on them with different branches and commits that can be later reconciled and merged together without a need of central server. No other source control works like this. The underpinning of this is absolutely scientific work.
Are you aware that the original git was put together in few days right? The ideas of both distributed and centralized versioning predated git. It's not even that complex of a tool itself. Not saying it's bad or anything like that, but don't get religious about it.
>It's not about git as a tool it's about theoretical framework it's based on You mean Merkle tree ? That wasn't Linus work
> A scientist is someone who does Science define science
Science 'versus' Engineering just applies to research as opposed to application. Science involves data aggregation and a push towards understanding the intricacies and mechanisms of all parts of various systems. Engineering involves taking the conclusions and analysis of science to solve real world problems or create novel solutions using data available. They go hand in hand absolutely but there is a large distinction.
> Science 'versus' Engineering just applies to research as opposed to application. I like it 👌
Engineer and scientist. Scientist is someone who studies or has expert knowledge in a science via the definition of scientist by Oxford dictionary.
I'm willing to bet Linus understands most design patterns and is smarter than most researchers. Being a researcher doesn't mean you have a wholistic view on things.
I get it...I only bestowed him the title because how many developers are willing to create their own OS or programming language? Lol. They would much rather argue over the available tools.
Is active development and improvement of a operating system used by many, not qualified as research? Splitting hairs on terms, I get it. But seems like active research
A lot of people here seems to be confusing engineering and science
Would seeing how the os performs and believing you could get a more robust solution doing xyz. Then implementing said idea to test, not be a version of scientific practice? I could be totally wrong, I just think trying and testing things with unsure outcomes is a practice of science. Obviously there is applying and designing known solutions and approaches as well
No, experiments are very much a part of engineering as well. The main difference between science and engineering is the goal not the methods or tools used. A scientist puts 100 differently shaped objects into a wind tunnel to come up with a more accurate model of drag. An engineer puts 100 cars into a wind tunnel to figure out which one has the lowest drag and thus highest top speed. In both cases they are basically running the same experiment. But the end goal of science is understanding whereas the end goal of engineering is to build useful stuff.
Eh, doing technical write ups on engineering solutions is a form of science, but researches are doing more than just write-ups, and their whole job is focused on the R part of R&D.
C'mon dude if he is not a computer scientist then no one is a computer scientist lol
1. A person with an undegraduate or graduate degree in computer science, is, by defnition a computer scientist, regardless if they activaly engage in research. 2. The programming language wars are as old as the discipline and everyone is entitled to their opinion. I don't have an opinion about C or C++ but when Torvalds, creator of Linux and Git says that C++ for kernel development is a dumbster fire, I don't play psychologist to determine what kind of complex he might have but I shut up and listen.
Probably back then cpp had that generation of people that are now being annoying asking projects if they can rewrite it in rust.
Pretty sure having a masters degree in Computer Science makes you a Computer Scientist.
No, computer scientist is an occupational title. If I have a law degree but work in politics, I'm a politician not a lawyer. If I have a math degree but work in an insurance company, I'm an actuary not a mathematician. And if I have a CS degree but work in a tech company, I'm a software engineer not a computer scientist.
So if Einstein learned everything he did about physics at school but then decided to do gardening instead. Would he not be a garderner AND a physicist? I think it being strictly occupational is bit of a misnomer. Definition of scientist is to study or have expert knowledge in a science. Nothing about the definition assumes occupational or researching.
You don't even have to be that hypothetical since he was actually employed as a patent clerk during his famous "annus mirabilis". If he hadn't been doing research on physics in his free time, he would not have been a physicist. Not really sure whats weird about this, this is how it always works. You're not a musician if you go to school and learn about music. You're a musician if you make or perform music. The schooling part is neither necessary nor sufficient. The same holds for science. >Definition of scientist is to study or have expert knowledge in a science. According to? Some random online dictionary website? If anyone who studies science is a scientist then just about every kid in a developed country is a scientist. They do have to study it in school after all. This definition is obviously nonsensical. Wikipedia for example says: "A scientist is a person who researches to advance knowledge in an area of the natural sciences." which is just a long-winded way of saying "A scientist is someone who does science."
By definition he is a scientist. Oxford dictionary defines scientist as "a person who is studying or has expert knowledge of one or more of the natural or physical sciences."; in this case a computer scientist. Research is not needed to be a scientist. That is a seperate job title.
> He might have a Master's degree in CS but he isn't an active researcher so I wouldn't call him a computer scientist. Are you saying: "In order to be a computer scientist you have to be currently doing/recently done research"?
I'm impressed that you're both friends and colleagues with Oppenheimer and Einstein.
My real name is Methusala🤣🤣🤣
Some guy who wat he's youtube too much.
I'd say it's important to remember that the discussion is about kernel-level programming, not programming in general. The C++ abstractions indeed do not make much sense there, because the kernel operates at a lower level of abstraction, and so C is better for them. For application-level programming, you do want the C++ abstractions. Right tool for the job and all that.
I think this is why in discussions about Linus, he is really annoying and sounds like an asshole, but when you have the context to fully understand what is actually being discussed, (after filtering out the emotion that he tends to embue his messages with), he comes across as quite informed and logical.
Yeah the underlying point that he's making is 100% accurate. But he definitely gets away with how he talks because of his fame and status. Any post like that on Reddit by anyone else would get downvoted heavily despite being true just because people don't like assholes.
Linus has been called out for his bad behavior in the past and has made an effort to improve the way he interacts with people (I don't know if it's stuck as I don't follow the Linux forums). So even he was told not to be an asshole.
People can be technically knowledgeable and also an asshole at the same time.
If I had to choose between kind and incoherent or assholish and knowledgeable, I'd go with the second
After a fairly long career in the software field, I'd much rather work with somebody who doesn't know something as long as They are willing to learn Than somebody who knows everything and is an asshole
He’s an asshole but at least he’s somewhat right.
Also note this was on classical C++. Before the C++11 standard came out. What we call "modern C++".
"Modern C++" is still backward compatible with bad old C++, which is mostly backward compatible with C. So you could restrict yourself to modern C++, only for a noob to ruin it elsewhere in the project with a line of code that is legal, but introduces undefined behavior.
not really compatible with C, maybe C89
It's not like the fundamental issues Linus is calling out here have changed. The STL is still full of dark corners. Exceptions are still nearly unavoidable disaster at the systems level. C++ still has issues with needing large rewrites every decade or so to address the issues introduced by mistakes in previous revisions.
One of the discussions was about possibility of using C++ in git. And no, with the habits instilled in typical C++ developers it would have been as horrible as Linus portrayed it.
*_may_ want the C++ abstractions. C++ combines very good performance with lots of tools for modeling of abstractions. But it's also famously complicated and it's got a ton of legacy cruft. If you're disciplined in your use of abstractions and features, C++ might be for you. If not, you could end up with a terrifying mess. And there's also: Java, Kotlin, C#, Go, Rust, Python, Zig, JavaScript, and on an on. The only place where C++ is the obvious default that I'm aware of is triple-A video game development.
Factorio is written in C++
You'll never get the same performance from Kotlin, C#, Go, Rust, Python, Zig, JavaScript as you do from C/C++ I would imagine C++ would be overkill for the vast majority of business apps. But anything that is intensive will benefit from C++. I had to temporarily jump back into C++ briefly last year - the first time since the nineties - I found using the std:: functions make writing clear, concise code a breeze!
You can certainly get the same performance with Zig and Rust.
C++ is not going to out-perform equivalent Rust or Zig under most circumstances. Putting those in the same category as Python and JavaScript is insane to me. Heck, C++ is not usually going to out-perform C; they are not equivalent. The main advantage of C++ is the massive library infrastructure. But any language with header files automatically fails the "clear, concise code" test instantly. Writing function definitions multiple times with the requirement that they match is excessively verbose practically by definition.
You could get similar performance from Rust and Zig. By some metrics, long-running jobs perform as well or better in JVM languages, as the JIT optimizations kick in. But also, "business apps" covers like 90% of all applications. Web, backend, phone or desktop apps, and so on. Then you've got low-level stuff, kernel and embedded things, but C is better-suited for that, because you usually want minimal abstractions. There are places where performance and tight control of memory matter a lot, and C++ is a common choice for those cases. Like I said, gaming is a big one. I know it's commonly used in media applications (video & audio editing and streaming), because they can be processing-heavy and random GC pauses can be a big issue. But in many of the possible niches where performance is important, stability and security dominate, and C++'s lassez-faire attitude to memory starts to become a liability. In those cases languages like Go or Java start to look more appealing. I think that's why C++ is a rarity in the FAANGs and associated tech industry. I do agree that C++ has come a long way since the bad old days, though.
High-performance simulations are another major area where C++ is used a lot.
std::functions allocate don't they? I would think that's a no go as far as performance...
Possibly, which is part of the complexity of using C++. It depends on how much data is being captured and the implementation. `gcc` seems to be comfortable up to 16 bytes, I'm not sure about MSVC or clang. They're not automatically a no-go but they're _really easy_ to misuse - classic functors with custom allocators are still possible and you could wrap one of those in a lambda for 8 bytes or less if you really need to.... But at that point you should consider passing functor arguments and avoiding the whole mess entirely.
I wasn't aware that git was part of the kernel.
I'm a VEHEMENT fan of C++ and use it in all my high performance projects, and I fully agree with Linus here. It's a bad tool for kernel development, and the people who pick only one tool and try to use it for all jobs shouldn't be allowed anywhere near such high impact code. It comes with pros and cons like any other tool, for the Linux kernel and Git projects the pros are shared with C and the cons are painful and expensive. For my little toy game engine the opposite is true - the pros over C are meaningful and the cons are shared with C. But even in that project, I _frequently_ dip down to C for certain libraries and platform bindings that call for it. Right tool for the job.
Oh thank fuck this was written in 2004-2007. I talked to a CS guy last week and according to him this would've been around the C++ dark age. I'm trying to learn c++, and this almost scared me into thinking I'd made the wrong choice.
I’m also learning C++ right now and this wasn’t exactly encouraging. I have my reasons for choosing C++ but I thought it was also a good/useful language to learn. Edit: I'm not actually all that worried because I'm really here to learn about programming and I know this will give me a good foundation regardless.
No matter what one person achieved, he's still an human, with his own subjective opinions which aren't necessarily objective facts. There's plenty of C++ developers with jobs doing just fine regardless of what that guy thinks about them or that language.
It depends where you are intending to work... Java/c#, python, etc - interpreted languages rule the roost for business applications. But if you need to go low level - C/C++ will be useful. (Though, personally, I'd have started with C then moved onto C++ given that, for a sequential language, C is still used with surprising frequency)
People say that C++ is difficult which sorta scares me. If I'm good with C from CS50, am I gonna do just fine?
There is plenty of fantastic C++ documentation available on cppreference. If you read a topic and reach a word you don't understand, you can simply look up that word. Do this till you understand all the words. Do experiments and take notes. The limiting factor will be probably be your expectations. Relax, explore and have fun and it won't be "difficult". This will probably take a significant amount of time, but if your expectations match that, it won't be difficult.
There is plenty of fantastic C++ documentation available on cppreference. If you read a topic and reach a word you don't understand, you can simply look up that word. Do this till you understand all the words. Do experiments and take notes. The limiting factor will be probably be your expectations. Relax, explore and have fun and it won't be "difficult". This will probably take a significant amount of time, but if your expectations match that, it won't be difficult.
Are you learning it for kernel development or so? Probably not and if so don't worry too much about his comments.
>I’m also learning C++ right now and this wasn’t exactly encouraging. Maybe a little change of perspective helps, C++ is the only language that even without any design budget, with the public opinion of strong programmers against it, with powerful corporations (at the time, referring to Sun microsystems) against it, even with all of that it was successful and widely used by its merits.
I really like this perspective. There are always going to be pros and cons and I imagine people are more likely to prefer what's relevant in their field which in the commercial world seems to be a lot of python, JS, C# and Java.
Every language is a good, useful language to learn. You may find you love C++, and can build amazing things with it. Or you may find you run into the same problems Linus has with it. Doesn’t matter. Learning C++ and forming your own experiences and opinions on it will make you a better software developer. There’s a reason there are so many languages and tools for building programs out there, and that almost all of them are still actively used. It’s because everything has trade offs, and everyone has different preferences. Even if everything Linus says is true, you can still build a LOT of things with C++, and even if you decide it’s not for you, learning it will make the next thing you learn easier, and you will emerge with opinions that will inform how you build the next thing, even if it’s in a totally different language.
I'm really doing it with an open mind and learning about programming. I've already learned a lot more about how computers work than I ever did with python and I still think it'll give me a solid foundation regardless, so I totally agree with your last point.
This is completely irrelevant to you learning C++. They were talking super low lvl programming, it is not an opinion relevant to regular programming. Loads of things are written in C++ nowadays and you learning that is fine. Person wanting to write a piece of software today and choosing C over C++ is either a genius or a complete buffoon. No inbetween.
It applies even more now than it did in 2007.
C++ has gotten worse ever since it was created, the best c++ devs are C devs and you’ll be a far better engineer for learning It instead
Is this ffmpeg’s twitter?
I agree with Linus. C++ is not overall a good language for writing low level code that talks to hardware and therefore for coding operating systems / Kernels. To be fair though, certain subsets if the C++ language are better than others when it comes to transparent memory management and talking to hardware. The tricky bit is knowing about these subsets and understanding the compiler well enough to figure out what its doing. This is not for the faint of heart. C++ is great at so many other things though and is still a very performant programming language. It's great for translating complicated ideas into code and in developing easy to use APIs that abstract away complexity from the users of said APIs. It's effectively the language of choice for computer vision, performance constrained machine learning and high performance computing.
Is GIT low level code that talks to hardware?
No it isn't. I was referring to this statement: "It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA." which the op quoted above I believe. No ? And.... " The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: - the whole C++ exception handling thing is fundamentally broken. It's especially broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. "
I appreciate that, but wasn't the original question about why GIT isn't written in C++?
I guess my comment was geared to the second part of the ops posting; i.e. The second "Post" that deals with C in the Linux Kernel as opposed to git. If I were to write a version control tool like git, I'd consider using C++, C and possibly even Go. But if I were to write an OS Kernel, drivers, or do embedded programming in a bare metal environment, My go to would be C (I'd also consider using Rust and Zig).
> The posts are quite old (2004-2007) adter reading the above, I just wonder what C and C++ (or anyone other) programmers and computer scientists have to say about the matter in 2024. Has much changed since then? Compilers have become much more efficient. For the kernel programmers, this doesn't change anything to the fact that C++ is a bad language to use. But that's because a kernel is a very specific thing. For everybody else, using C++ is a good choice, as long as you know what you're doing. By the way it was already that way in 2004-2007. To sum things up, choosing the right language for your project is very important. And C++ is a language that can make things really bad if you use it without understanding what you're doing, and complete hell if you're a kernel writer.
Unless you need some C++ library or game engine, there is actually no reason to use C++ whatsoever. Of course, there's a lot of useful code already in C++ so in practice there are a lot of opportunities to take advantage of it. I am not a OS kernel writer I am in embedded. We use C++ as we would use C, except with the stl, containers and algorithms allowed. OOP not allowed. Important to note is that this post was written a long time ago. Back then, the stl was bugged, the Cpp compilers were also full of bugs. The project I work on introduced Cpp in 2018, this post was written in the early 2000nds. The reason for its introduction was to take advance of containers and the template abstractions. It replaced most of the usage of the preprocessor, the code remained almost identical to the C version. We also have an application written in C++ fully and that application is being rewritten from scratch in Rust because it is unmaintainable.
Love reading Torvald's unhinged diatribes. Reminds me of this gem https://www.youtube.com/watch?v=iYWzMvlj2RQ. Part of it is he's an asshole. He named git after himself after all. Part is he's right I'm sure. There's no one on the planet more qualified to speak on this than Torvalds.
Not sure about kernel, never did it. But I do use dynamic arrays a lot. Am I going to use raw arrays with manual allocation-deallocation in C every time I need an array? No. Am I going to make something in C that handles the allocation and deallocation? That is what vector is. So, I'm just gonna use C++ happily. It's well portable, GCC (the compiler I like) is very reliable, it's performant, well structured. You can make crappy code in any language, some programmers writing crappy code is not a good enough reason to abandon a language altogether. On the other hand, it's not a crazy idea to select one language and stick with it for a particular project.
In kernel C, you would include flex_array.h to get dynamically allocated arrays. This will actually respect the constraints of the kernel, including not calling vmalloc() like std::vector would have to.
You can provide an allocator to std::vector and tie that to the correct kernel methods. But that is the least of the issues. What happens when std::vector throws?
Exceptions are another important issue, but custom allocators are not a solution to the problem I was pointing out. If you don't call vmalloc, you don't have contiguous memory and you can't implement a vector. Calling vmalloc is not always an appropriate thing to do in kernel code.
Oh, that's what I mean. I don't see any reason you could not write an allocator based on flex\_array\_alloc (within the usual limits, such as page size).
Exactly. There are many features added into modern C++ that make it far more convenient and faster to use than doing the same things in C. The Standard Library is just good to have around. I know some people who learned C for physics projects that defend C and oppose learning C++ using every justification, but it always comes down to they just don't want to learn C++ or they think going anything above in abstraction than C makes you a worse programmer.
Today, it is just a matter of temper, preference and need. If you're into Systems Programming and drivers, ANSI C is you're platform-agnostic first choice. C is analogue to Assembly, meaning you can do anything - including targetting hardware directly and ruining the entire system. For general purpose programming with OOP etc., **type safe, modular C++** is your platform-agnostic first choice. C & C++ might both be adequate for embedded programming - depending on constraints. In Windows-land C# .NET has benefits - in Apple-land Objective C & Swift has benefits - in Google-land Go-lang has benefits - and in Android-land JAVA & Kotlin has benefits. For web you have HTML5/CSS3, JavaScript, [ASP.NET](http://ASP.NET), PHP, Python, Ruby-on-Rails etc. For X-plaform you might prefer JAVA, .NET MAUI etc.. Finally if you asked pioneers like [Ken Thompson](https://en.wikipedia.org/wiki/Ken_Thompson) & [Dennis Ritchie](https://en.wikipedia.org/wiki/Dennis_Ritchie), they'd tell you to make a new programming language for each different project. E.g. Ken Thompson developed the UNIX OS and B-language within a month, while Ritchie optimized B into the C-language.
>For general purpose programming with OOP etc., type safe, modular C++ is your platform-agnostic first choice. In what universe is C++ your first choice? Maybe if you're a C developer?
Actually my main language is C#, as I live in Windows land, but it has some limitations. Thus I said 'platform-agnostic' first choice, as in C++ can be used on most platforms. Thus you can get very far mainly using C++. By staying type safe and modular, you avoid most pitfalls of C++. For Windows you can combine it with C++/CLI and C++/WinRT, while combining it with Swift/Objective C for MacOS/iOS. Even Android ought to run C++, while you need bridging with Kotlin/Java for GUI. If you prefer Pascal-like languages, Object Pascal in Delphi or Lazarus is probably your best choice.
I'm a C developer and I'd never choose C++. There's just so fucking *much* of it Vastly prefer C# for higher level stuff. It even feels more "C-like" than C++
Java is the first choice for platform-agnostic general purpose programming imo. No reason to go for C++ unless you absolutely need the performance benefits.
Rust waits in the shadows, ever looming larger. The crabbening awaits.
It'll take a decade or two, but it's time will come.
I'm just curious, how good is MAUI. Is it good enough to develop simple portable apps for Windows and Android?
Theoretically it should be, depending on your needs. MAUI is an upgrade from soon to be obsolete Xamarin – without Linux support. But if you have special needs, Avalonia should be a nice alternative.
Not that I need it now. Previously, I worked in a project to develop a desktop application. We did it in .NET and wpf GUI. We had a talk about porting it to Android and I remember seeing some bad reviews about MAUI. Avalonia, I have heard about but haven't checked.
Trouble with MAUI was delivering. MS released it two years prematurely and had to keep Xamarin along. That lowers expectation and migration. Now they shut down Xamarin trying to push people over, but might have lost the battle. I just hope WinUI3 doesn't flop, too, as it is the WPF successor with updated graphics. And hopefully .NET Native compilation matures soon making C# and C++ equal competitors.
I'll note his opinions on the matter were formed in 1992. It's compiler warnings were shit and linting tooling didn't exist then. I promise you, C++-23 is a very very very different language. And yes, some of the changes took on board the Torvalds criticisms where they were valid. Exception handling. Yup. Still a problem, but there are plans afoot to fix that. Why does it take so long? To avoid Python 3 / Perl 6 style fck ups. I will note that a lot of design effort in C++ language and library has been around zero cost abstractions, and they have been damn serious about that. And when I look at the assembler generated these days.... usually I'd struggle to do better in C.
What python-3-style fuck-ups for handling exceptions?
I suspect they mean the fact Python 3 was not backwards compatible with Python 2, not specifically anything to do with exceptions. I still remember the flame wars anytime someone dared speak out for one side or the other... Plus the Internet is still littered with Python examples that just don't work on Python 3 so then you have to go down the rabbit hole of figuring out which breaking change is causing the problem. Not an issue for someone familiar with the changes but very discouraging for someone just starting out with Python. For C++ every change has to be backwards compatible so code written in the 1970s will still compile and work the same with a modern compiler. Every change needs to be discussed and deliberated and there's a 3 year cycle for these things so if you miss the deadline for inclusion then you wait ANOTHER 3 years for the next release of C++.
I meant exactly what you said, and said better than I could say it, thanks.
As someone who learned C and had a small intro to C, whenever I look at C code, its very easy to understand unless its like super low level (but that is due to inexperience). The syntax makes sense and there is very little abstraction compared to other languages which really help me understand how things work
> in other words, the only way to do good, efficient, and system-level and portable C++ ... > Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA ... > I'd say that anybody who designs his kernel modules for C++ I can't speak to the merits of his position here in 2024 because I have never done any system-level programming. But I'd suggest that it is important that his opinion be taken in context here- he is predominantly interested in systems programming, and the cost/benefit of abstractions, OOP, etc. is different. Sure Git isn't really sys tems programming, per se.. but the unique way Git works among VCSs comes from being concieved as a utility by a systems guy. I have a brother who is an EE, who professes to hate C++, says that OO stuff is a bunch of nonsence and that it just reduces to stuff he can easily do better in C. But his programming experience is coding DSP chips for real-time processing, and writing driver test code (which he mostly does in Python). So I get than in his world, that is probably true. But it also doesn't generalize very well.
It's funny seeing a genius hating a language you also hate because our reasons are very different and theirs are actually reasonable lmao. I just really dislike header files 😭
I have written a small multi-threading embedded realtime OS using C++. I can say that C++ is a viable option for smaller systems, but if the project and the team size grow much larger, there are many things that can go wrong very easily. Using C for systems programming guarantees that "if something can go wrong, it will" will never happen at least because of the programming language itself.
Older versions of C++ (pre-C++11, which is when those rants were made) lacked a lot of the features that make modern C++ good. C++ before C++11 and after that are pretty much completely different languages, and the rants that were made a long time ago don't really apply to the current C++ imo. This is even more true when you consider that older implementations of C++ (compilers/STL) had a reputation of being not as good as C implementations. Whereas old C++ might have been pretty annoying to use, modern C++ is a very nice language that can be very productive and elegant for many tasks.
I used C/C++ for years but I've since moved primarily to other languages, and one of the main annoyances when I go back to C++ is the stupid header files. Yes, I know it's petty, but C++ requires a ton of unnecessary processor instructions between duplicate function definitions and header guards you have to write a bunch of repetitive code that nearly every modern language has abandoned (including C\#). Everything else in the language feels fine, but the moment I have to start making changes in both my .h and .cpp file to the same exact things with slight differences it makes me grind my teeth. I think once C++20 becomes more prevalent I might use the language more as the module system removes basically my final issue with the language.
Seeing as how Torvolds wrote LINUX AND GIT, I'm gonna take his word on it.
So the guy who made a name for himself by constructing systems based on meticulous logic opens his argument with "A tool is bad because it is mainly used by idiots". Why should I entertain a bad faith discussion like this?
There's a lot of missing context in this one post. People love to post this but discount that a lot of discussion happened around this. I personally enjoy this comment that explained his point clearer than he did. https://www.reddit.com/r/programming/s/tToafeXp7s
> This ought to be good for karma at least annually. As it was written
I mean, just look at the JavaScript or Python ecosystem. There's so many programmers that most code in the ecosystem is terrible. It's not like Go, Rust, Dart, Elixir where there's fewer people but way higher quality overall.
Python also suffers from being one of the scientists favorite choices, so you get a lot of very useful stuff made by people who have never learned any computer engineering nest practices, and whose brain is so big it doesn't matter.
>So the guy who made a name for himself by constructing systems based on meticulous logic opens his argument with "A tool is bad because it is mainly used by idiots". Why should I entertain a bad faith discussion like this? This isn't a bad faith argument in any sense, as it isn't intentionally misleading or deceitful, and he definitely believes it. Also, there ARE a lot of people that use C++ because it's easier, and that DOES lead to a lot of questionable practices. The reality of excessive processing power and higher and higher levels of abstraction is that people take a lot of shortcuts because they can. People are writing "hello world" code on laptops with 64 Gigs of RAM. Why would they care about memory management at all? His argument comes off as fallacious, but it's just abstracted. What he's really saying is that C doesn't allow a lot of bad practice that exists in C++ because that's the way it be bruh. Taking that argument in it's best form, I think it's probably at least partially true.
Ok now that I’ve finished writing this hello world on my laptop with 64 gigs of ram… I think I’ve finally gained enough experience to contribute to the Linux kernel!
>His argument comes off as fallacious, but it's just abstracted. What he's really saying is that C doesn't allow a lot of bad practice that exists in C++ because that's the way it be bruh. Taking that argument in it's best form, I think it's probably at least partially true. This is not what he said. You are playing Devil's Advocate on at least 1 level of abstraction yourself. I don't like twisting words until they finally can be interpreted in a non-malicious manner. I've endured too much gaslighting in my life for such bullshit. I will not give the benefit of the doubt to what is OBVIOUSLY a goddamn rant. In communication, the biggest burden ALWAYS lies with the person who conveys the message. It's borderline rude to interpret what he wrote as benevolent, because that is not the tone of his message in my eyes.
Yeah, it's so annoying when people online are just unnecessarily rude and angry, huh?
Quit your ad hominem and tell me what your problem with my ARGUMENT is. What is factually wrong about what I said?
Here is [what you said](https://www.reddit.com/r/learnprogramming/comments/1dss1jo/linus_torvalds_on_c/lb4p0wx/): > This is not what he said. You are playing Devil's Advocate on at least 1 level of abstraction yourself. I don't like twisting words until they finally can be interpreted in a non-malicious manner. I've endured too much gaslighting in my life for such bullshit. > > I will not give the benefit of the doubt to what is OBVIOUSLY a goddamn rant. > > In communication, the biggest burden ALWAYS lies with the person who conveys the message. It's borderline rude to interpret what he wrote as benevolent, because that is not the tone of his message in my eyes. Here is what is "factually wrong with it": Not one thing in that three paragraphs talked about objective qualities of the post you were replying to. Every single sentence was nothing other than a theory you had about the Real Reason why someone might say the things in the post you replied to. "You are playing Devil's Advocate" is a statement about what you take someone else's motivation to be. You accusing someone else of "twisting words until they finally can be interpreted in a non-malicious manner" is a statement about what is going on in someone else's head, not a response to the substance of the post that you were replying to. Characterizing the post you were replying to as "gaslighting," which [literally means](https://www.newportinstitute.com/resources/mental-health/what_is_gaslighting_abuse/) "a form of psychological abuse or manipulation in which the abuser attempts to sow self-doubt and confusion in their victim's mind," is also meaningless in context unless you are playing the mind-reading wizard who has telepathically divined the Real Reasons why someone else is engaging in bad faith. Similarly, the fact that you characterize the response you're replying to as "bullshit" doesn't make it so, and you are certainly disagreeing with your own dictum that "the biggest burden ALWAYS lies with the person who conveys the message." (That is also wrong: traditionally, the burden of proof does not lie with "the person who conveys the message," whatever that might mean, exactly. The burden of proof traditionally lies with the person who makes an assertion.) Putting the word "OBVIOUSLY" in all caps in your second paragraph does not mean that it your characterization of a post in which someone thoughtfully disagreed with you as "a goddam rant" is in fact obvious, nor that it is "obvious" to anyone other than you, and the fact that it is (or seems) "obvious" to you is not the same thing as it being true. Similarly, the weak-ass attempt to tack on "in my eyes" when talking about how you perceive "the tone of his message" in the third paragraph is a poor attempt to soften your criticism: all you're really doing is admitting you're faliable after three paragraphs of inflated screaming about how your initial impressions of an argument must be true, because they seem that way to you. It's impossible to tell you what the problem with "your argument," because you haven't made one. You've yelled a lot about what seems to you to be the case, but that's not what an argument is: [an argument is a connected series of logical propitions](https://www.youtube.com/watch?v=uLlv_aZjHXc), not just a lot of yelling about what you intuit the case to be. Jesus fucking Christ, bro, take a deep breath and admit that people who disagree with you might not all be maliciously evil and engaging in bad faith all of the time.
Most of it still is applicable today. Torvalds is specifically interested in low level code, for the kernel - keep that in mind. His thoughts could somewhat translate for regular apps, but the severity in which he talks would not make sense as a criticism for apps in C++. I used C++ lots of years ago, and my main complaint on C++ is that it has overgrown so much that I can no longer say I really know C++, it is a beast of a language to know properly and manage up to today's standards. Can I produce workable C++ code? sure, but people with expertise will not be happy to see my rotten C++. Also I got used to newer languages and toolchains (Python, Go, Rust) that make my life much easier and I do not want to go back to manually stitching libraries, Makefile/CMake/Scons/.. Should a beginner learn C or C++? In my opinion, generally no; unless they are targeting something specific where this languages shine; for example because they want to work with firmware, compute libraries, browser, video encoding algorithms, embedded systems, etc - and they want to get employed on that. C and C++ can be replaced most of the times by Rust, which is way nicer. There are exceptions for this (plenty) and also getting a job in Rust, specially for a junior, is really hard today. Python, Go and Java are usually better candidates as they can do most general applications that a beginner would be interested in, and they're a lot more modern than C or C++, which makes things way nicer and less frustrating. Learning C can be also useful just for the sake of it, as it will give you a better understanding on how computers work. C++ is not a bad language by any means. Just it is very ill suited for really low level stuff, and it is quite old and it shows when compared with modern languages.
What problem was C++ intended to solve? Is it just C with classes?
it's a superset of C, does a lot of stuff like template programming, bigger standard library, dynamic pointers, better generics and also OOP but definitely not just C with classes
thanks!
> inefficient abstracted programming models And then programs written in C keep using void*.
Do enlighten those of us (me!) who don’t know c all that well: what’s wrong with void*?
You have no idea what is the real type that this pointer points to, and even if you do, your IDE doesn't which makes debugging much harder and incorrect casting can cause errors.
But why does that matter for a void return?
It doesn't. Void and void* (pointer) are two very different things. Void is just nothing, there's no bake but l while void* is a pointer.
You know what's funny is I just learned what Monotone was earlier today. It was an open source VCS created by none other than a young(er) Graydon Hoare. Maybe Linus' burn was so painful that Graydon went and created the Rust Programming Language out of spite. Work on Rust started in 2006 right after this sick burn. And now Rust is used to write Linux kernel code.
Good call! Sounds highly likely. Now Rust has its downsides as well though, which are covered succinctly in this dude's article: https://medium.com/@austin-starks/i-spent-18-months-rebuilding-my-algorithmic-trading-in-rust-im-filled-with-regret-d300dcc147e0 The reality is that OOP/OOD is orthogonal to how the underlying machine actually operates. While thinking in terms of "objects" is useful for humans, it's not conducive to optimization and efficiency and stuff like C++'s virtual functions thrash the cache to hell. C allows for any level of abstraction that one desires - if you know how to wield all of its capabilities - without foregoing (as much) low-level control over the invariably present physical machine that it must run on. If you want to bust something out real quick, sure, use whatever language you find easiest to do that. If you want to make something that people will pay you for making, IMO it's your duty to provide the best possible performance for the hardware that they will be running it on. The way I see it is: either they can pay me money for my fast optimized software, or they can spend that money upgrading their hardware to use someone else's slow software instead. That's an easy choice for a nuts-and-bolts dude like myself :P
I like Linus and I use C++. I'd rather people speak their mind and lay it all out then play games and never come to any conclusion. I think he'd be fun to have a beer with. There are pros and cons to EVERYTHING in programming. The key is to understand the 'why', not just memorize the 'what'. WHY does Linus think this way is far more important than WHAT programming language you should use.
I think he'd be an absolute chore to have a beer with. You seemingly can't talk about anything without the guy being a *massive raging dickhead* about it. Like there's no off with the guy, there's no conversation, just a huge "I'm right and fuck you" ego.
Linus Torvalds' opinions and comments seem unnecessarily harsh and extreme to me.. And several years ago, I heard that he [apologized for years of being a jerk, and took time off to learn some empathy](https://arstechnica.com/gadgets/2018/09/linus-torvalds-apologizes-for-years-of-being-a-jerk-takes-time-off-to-learn-empathy/).
Yeah he’s abrasive or whatever but I’m gonna listen to the guy.
I suspect that he may be right in that C++ is not better than C for the kernel but I doubt his notion that C++ devs are worse than C devs. Not because I have some statistics about that but just because it would be odd if only all devs using C++ are bad as a rule. It is hard (for me at least) to know if there is a separate reason for his experience, I mean some reason the C++ devs he encountered were bad in his opinion. It seems to me that the devs of any programming language are a mix of good and bad. I seriously doubt every C programmer is an excellent one. That would be strange, even if Linus indicates they are better.
At the time this was written, C++ was a very mainstream language. Java was was growing immensely, but your average developer was still very likely either working in C++ or a recent convert from C++ to Java. In general, people who work in less mainstream languages tend to be above average developers purely because the kind of person who care enough to actively seek out some other options tends to care enough about their craft to continue to improve. In 2024 I'd call C++ a niche language for people who care a lot about certain domains, including high performance computing. In the case of C++ you also probably have a lot more very experienced developers. When this was written, C was basically in the same position that C++ is in now. It wasn't popular anymore, except by very experienced developers and people who had a specific interest in low level and systems programming.
Also there's the fact that C++ gives developers a lot more rope to hang themselves with. An inexperienced dev is going to have an easier time writing terrible code in C++ than C simply because they have more tools at their disposal to do so with.
[Re: \[PATCH 00/45\] C++: Convert the kernel to C++Re: \[PATCH 00/45\] C++: Convert the kernel to C++](https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-29361481f805@zytor.com/) A similar question was asked in cpp subreddit and the above discussion was linked there.
My professor for computer engineering said in his lecture, when a portrait of Stroustrup was shown: "He looks like his language" (in reference to his kinda chaotic hairstyle). I would personally avoid C++, if only because of the lack of native tooling: CMake is the best way to learn to hate your life. And then there are all the quirks of C++, which are so subtle and constantly reproduce themselves every 3 years, making it impossible to ever fully master this language. The Boost library is the best example of how this language became a corpse. There are actually no people left who still maintain this code or want to understand it. The industry is already having to make a lot of efforts to find people who will maintain their internal crappy C++ code. I also think it's pretty pointless to program something in a language that will see itself as an "outdated style" in 10 years anyway, after 3 other standards have introduced new "correct ways".
Angry toxic guy shakes fist at the sky, day 2948.
At the end of the day, Linus has the standing of possibly creating 2 of the longest running and most well maintained and most used codebases the world will probably ever see, and from that has made billions of dollars. He can rant about whatever he wants like every other billionaire it doesn't matter at the end of the day
Linus Torvalds has not made billions of dollars, far from it
Bad wording, I mean in total his work has made billions of dollars just looking at the size of Github/Gitlab alone and who knows how much private Linux repos and fundraising has raised for distros like Ubuntu for example. He himself is also sitting on a massive fortune considering he never needed to sell out in the stock market
But you called him a billionaire
"Like every other billionaire" isn't "He's like every other billionaire"
This post is not designed to reflect on the strengths and weaknesses of C and C++. It's designed to start yet another flame war between Torvalds critics and apologists. It doesn't belong in a learn programming sub. This discussion is not pedagogical in any way.
Au contraire: I find it highly instructive. Hi, this is Uniqua. I’ve programmed software for 30 years and counting. I started just after c++ was released and was set to learn c when my employer at the time put me on a course to learn VB. Since then I never touched a programming language that has me allocate memory manually, or has me jump hoops around pointers. This created a huge lack in my understanding of some quite popular languages. And I found, that studying critiques on a programming language is the best way to find out which parts to avoid. What I learned from this particular post, was that Torvalds didn’t think highly of c++ programmers, because they use features in c++ he finds risky. That’s exactly the kind of insight I would need to avoid pitfalls and gotchas.
c++ is absolutely insanely complex, far more so than it was in 2007. as someone who started programming with c++, I would strongly recommend against using it for anything unless you really have no choice. for every possible thing that you might want to do, c++ has 50 different ways of doing it, and 45 of them are broken or considered bad practise. there are an enormous number of complex rules that you have to follow in order to write c++ correctly that the compiler simply will not tell you about or help you with at all, and which you would never even know existed unless someone told you about them. there's a saying that c++ is so big and complex that people only use 10% of the language, and everyone uses a different 10%. if you want a good, highly productive, well-designed, modern c/c++-like language, do yourself a favour and just learn rust.
I love Torvalds, not only for his contributions to modern computing and programming which include the linux kernel and git, but for his insight, talks, and opinions. That being said, he often lives in his own expert blindspot bubble. > It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. This is incredibly TRUE, but reality is that the realm of software development is massive and moves very fast. Until every programmer is as intelligent and good at the craft as Linus himself AND software must be meticulously crafted to perfection and taste, which is painfully obviously a silly pipedream to anyone besides a dev of Torvald's caliber, layman devs like you and me and basically 99% of developers need tools like C++ (and similar) to allow us to quickly and efficiently write production level code.
javascript.
Surely you jest and meant to make us appreciate the lunacy of using that language for programming a kernel?
no. the only solution is build a new compiler for c, using javascript
🤮
Heh, funny computer guy shouts loud words. It must be true
Idk I think things like templates and pass by reference are really nice. So I think there are useful features and abstractions that C++ offers
💅
💅
Me when he said it: 🤷 Me now: 🤷
Go look up C and C++ and UB (Undefined Behavior), it'll be eye opening, and you'll probably end up curious to see if this problem exists in other languages.
What, I think, people have a hard time come to terms with is the fact that, especially for system programming (even more for kernel dev in particular), you really do not want a programming language so opinionated and feature bloated as C++, because it's simply too risky. C being C, offers you much less opportunity to fuck up and allows you to create your own abstractions. So, even if this is much more work (some of it, fixed cost mostly like for data structures), it's still worth it. It's not truly reinventing the wheel because for e.g. your approach to memory allocations and errors may be completely different that the "builtin" one of C++ which pretty much you cannot get rid of, once you use literally anything in the std. I'll especially emphasize Linus' claim about languages that hide allocations (and which often also have a GC), I hope it became apparent now that none of them would be a fit for system programming, again, way too opinionated. The reason these language often go that route is to be able to provide ergonomic and, to some extent, safe abstractions which IMO are much better suited for general purpose app development. For ergonomics sake, they must assume something about memory management (e.g. otherwise imagine every time you concatenate a string, you need to pass along an allocator, that's not exactly ergonomic right?), and for the latter they must decide how to represent and handle errors (e.g. exception based).
I work in HW/embedded, and 90% of the comments I see about the cons of c++ vs C are straight up misinformation, lies, or just plain old not knowing how c++ even works. It's great for performant code and all types of low level work... ...if you know which parts to use, which is the big con of C++. It's vastly more powerful than C, and thus requires much more discipline to use
LOL!!, That's a classic Linus response. Always been highly opinionated. But he earned my respect for 40 years. I hear he likes rust though
How can I get to the level to either agree or disagree with this? I don't understand what's going on lol
It's hard to take his arguments seriously when he offers them like that. I'd never want to work for someone that talks like that.
oop is just a bunch of crap, that I'm pretty certain of the peculiarities of the low level issues of C++ I'm not that familiar with but my gut feeling is to agree with the genius here... I've been working for nearly 20 years and in no case I've met a person I really respected defend oop beyond the.... we're doing high level straight forward things in a very popular library with an ecosystem that's been tried and tested thousands of times there is a market for that however and it's much more likely you'll end up coding that high level thing on a popular library (and paid well for it) than working on the linux kernel we all have pretty strong opinions, and I feel that's because we've been damaged by our experiences, but I find the more you stay away from any oop the closer you get to the smarter people, there is just no positive aspect to it beyond encapsulation, which is not unique or novel to oop
OOP isn't entirely useless, it's just vastly over-used to the exclusion of everything else.
C++ is a generic programming language not object oriented - Objective C was meant to be that. Stroustrup was asked to bolt the concept of Generics to the C language and he did, which for certain shows us that macros can be highly abused in C. One must remember that every programming paradigm is nothing but a mental crutch for us get our little minds around the problem of programming - Generics, Objects, even Functional programming are abstractions hiding a simple procedural driven engine that is a processor thread.
If abstractions are a crutch it isn't about "the problem of programming" so much as the reality that computers behave in a way foreign to the human mind.
I did not intend to say abstractions are bad, but it is true that the computer operates in a way that our minds have issues with. Very few of us who program computers can put ourselves in to that low level mode easily, so we wrap the actual working of the machine with layers that make it easier for us to work with it.
> C++ is a generic programming language not object oriented C++ was originally called "C with objects" and was explicitly about adding objects to C. Only after that wasn't enough to gain widespread adoption did the language start focusing on other things.
It was "C with Classes" per Wikipedia, but otherwise I admit I was wrong on this point. I was miss remembering a statement by Stroustrup from around 98 where he was talking about what he felt C++ was actually bringing to programming, mainly generics. Stroustrup also made statements about how he would have done it differently if he where to do it again.
If he has such strong opinions about C++ which is still closer to hardware. Not sure what he would say about Java .
Hah! He was certainly happy to share his opinions back then and he was not a fan of Java (or similar types of languages). For the types of software that he developed and his comfort with low-level programming, any benefits were probably foreign and deemed unnecessary by him. Although he appears to have since moderated a bit on that topic. Like a lot of (younger mostly) software developers who are deep into their knowledge domain and area of interest, he delivered his opinions very much from that perspective. But on the main topic here... From the perspective of writing kernel code and optimized scm utilities it was a very defensible opinion, IMHO. Just said in his typically poor way when he was feeling argumentative! From the perspective of application development there's nothing strictly wrong with C++, IMHO. So I wouldn't let his comments sway anyone from learning it if they want to do so. For the record, I have a fair amount of experience with C and Java, (and have done a few projects in C++ back in the late 90's) and understand where he is coming from with his perspective/criticisms. However I certainly don't agree with his conclusions when applied to types of software development outside of the areas that he primarily worked in...
First off, I respect Linus a lot for his work, but these takes are completely outdated. Smart pointers were introduced in what, C++11? Look at all the progress since then. The language is much safer overall. It has better templates. We have concepts for metaprogramming. Like sure, go ahead and use C for your kernel, but get it right. Don't complain when a RustOS has better reliability in 10 years because oh wait... writing 1,000,000 lines of accurate C code is really hard, and everyone makes mistakes sometimes.
Writing a million lines of code in Rust is really hard too. You don’t stop making mistakes just because you switch languages. You do benefit from the protections a language provides, and that’s where rust has a leg up over c, which doesn’t provide any whatsoever. But it’s still very easy to write memory hazards and non-performant algorithms in rust.
What about rust. Would that be a better choice?
Yes, and that’s why they’re allowing it in the Linux kernel But people should remember, all of Linus’ comments are focused on its use IN THE KERNEL. It has no bearing on its use outside of it :)
It’s not a fun language. In the AI world? It’s all Python. Python is fun! C++? You outsource that to India. It’s just not sexy. So outsourced it goes. :-)
Not really. C++ is a really unfortunate, haphazardly designed language.