
Linus Torvalds on C++ - NARKOZ
http://harmful.cat-v.org/software/c++/linus
======
kabdib
I use C and C++ extensively (30+ years writing C, 25 or so writing C++).

I much prefer C when writing systems-level code. It's simpler and a lot more
predictable. You don't get the illusion that things like memory management are
free.

I /have/ written drivers in C++. Here you have to be very careful about memory
allocation (calling 'new' in an interrupt handler is usually death, though
I've also written very specialized allocators that work in IRQ contexts). STL
isn't going to cut it, especially if you're writing something real-time that
needs very predictable performance.

So, my basic prejudice is that while you can use C++ for systems stuff, you
still really need to be close to C semantics, so you're basically buying
namespaces and "C with classes" at the risk that some yahoo later on is going
to #include <map> and utterly hose things . . .

~~~
jgraettinger
My own experience is that RAII has been very useful in low-level work when
used to capture cleanup/finalization. Results in fewer if-statements and SLOC.

Issues of real-time performance and new vs malloc vs in-place/nothrow new also
seem like orthogonal concerns here. The larger problem is that yahoo who's
using the wrong algorithm and/or maintaining driver code w/o benefit of code
review ;)

~~~
beagle3
My (admittedly short) experience writing kernel drivers with C++ was that RAII
could be great help, but there's no way you can rely on any library you did
not write yourself (and one that you wrote with the express intent to use for
low-level work at that).

C++ code just tends to assume it's fine to do whatever crazy stuff it assumes
needs to be done, like allocating 4 bytes at a time using new. C code is
usually more careful about that, and quite a few packages offer control of
their memory allocation in C. (Yes, C++ does allow you to overload new and
delete, and have allocator traits, and more. Come back when you've actually
implemented this for a library you did not write, and we'll discuss war
stories if I can remember them. It was 2001, it was ugly back then, and I'd be
surprised if it is better looking now).

------
stephen_g
Has anyone really not seen this in the last two years?

Anyway, Linus may be a very experienced C programmer, but that doesn't mean
his opinion on C++ carries much weight... I'd be more interested on what
someone who actually has a lot of experience in using C++ says. Especially
with modern C++ and recent tools, libraries etc, which are very different from
what was around five or ten years ago.

I suppose it is nice for a change for someone bagging out C++ (however
inaccurately) to be advocating C instead of a managed or interpreted language
though!

~~~
nxn
Haven't seen it. I've seen many other examples of Torvalds being an ass, but I
don't bother to keep track really.

It does make me wonder though how he's able to get away with responses like
that, when most other "founders" (not sure what the proper term here really
is) would have the majority of their users/supporters just go elsewhere.

EDIT: ... Let alone have supporters who get defensive enough to start
downvoting someone who stated the obvious (he did act like an ass), while
asking a reasonable question too.

~~~
winestock
This man is being downvoted unfairly.

I've read Torvalds' post at the top of the page. I've also read the balance of
opinion on this page. The majority view is that C++ _really is_ a terrible
language for writing a kernel. Fine, I accept that.

Now re-read Torvalds' post. How many people here would want to work with
someone who regularly expresses himself like that? I know, I know; substance
is more important than image and so forth. But that post reminds me of what
people said working with Steve Jobs was like before he died.

Life is too short to work with jerks.

EDIT: Removed excess snark.

~~~
gaius
Except it's not true: The Commodore Amiga delivered multi-tasking, shared
objects and sophisticated IPC in only 256k of main memory. They cite OO
techniques as being key.

<http://en.wikipedia.org/wiki/Exec_(Amiga)>

~~~
telent
What's not true? Exec used some OO techniques in non-OO languages. So does
Linux. I can't see which post this was intended as a response to

------
redthrowaway
I tend to take everything Linus says with a grain of salt. Not because he's
wrong, or because he doesn't know what he's talking about, but there's enough
of the puckish troll in him that I tend to read his posts more with an eye to
their intended effect, than to what he's actually saying.

There are plenty of applications for which c++ is a perfectly sensible
language choice. Git isn't one of them.

~~~
mikeash
If I understand what proponents of C++ say, C++ is supposed to be suited best
for medium-level programming where abstraction is helpful but low-level
constructs and speed are still helpful. It's supposed to give you many of the
benefits of higher level languages while still giving you high performance.
It's intended to be widely portable but still easily hook into special OS-
specific facilities.

This description sounds like an excellent language for git to me. And in fact,
while I don't like C++ much in general, if properly managed, I think a project
like git could do well if written in C++.

~~~
dedward
It's that "if properly managed" bit that would be a nightmare from hell to
manage... easier to just do it in C.

What it's intended to do is rather different than what it's actually used for
in real life..... code talks, anything else is just smoke, right?

IF someone can come alnog and show us a better way in any language, then
tehre's something to argue about, otehrwise, the guy who has working code wins
over the guy without it, always.

~~~
mikeash
I guess what I'm really interested in here is, if git isn't an appropriate
project for C++, just what is?

~~~
redthrowaway
AAA games, browsers... Really, anything where you need to have some
abstraction but performance is still critical.

~~~
groby_b
There's a large faction in AAA games that thinks C++ is a stupid idea. It's
debatable who's right in that debate, but good points are being raised.

The problem is not so much that C++ is a worse language than C - it's that it
makes it insanely easy to shoot yourself in the foot in hideously complex ways
that take forever to unravel. See e.g. two phase name lookup -
[http://blog.llvm.org/2009/12/dreaded-two-phase-name-
lookup.h...](http://blog.llvm.org/2009/12/dreaded-two-phase-name-lookup.html)

There are plenty of other places where the design constraints of C++ have
forced it into a dark corner on the edge of the realm of madness. It _does_
buy you additional abstraction, but there is a price you pay for that.

Personally, I'm not happy with either camp. C shows its age - it's from the
70s - and C++ is just out of control. So I'll continue to use both unless
there's a decent replacement. (I'm squinting at Go, Rust, and BitC - and none
of them are quite what I'd like to see)

~~~
andolanra
I might suggest taking a look at D. It's more or less C++ redesigned from the
ground up by a C++ compiler writer, so it's much more consistent and a lot
more pleasant to program in. I've had bad experiences with the third-party
libraries, which were sometimes inconsistently documented and half-finished on
account of the still unfortunately small community, but the standard libraries
are excellent, especially everything that Andrei Alexandrescu has touched. For
elaboration:
[http://drdobbs.com/article/print?articleId=217801225&sit...](http://drdobbs.com/article/print?articleId=217801225&siteSectionName=)

~~~
groby_b
D _was_ decent until D2.0 started to get a serious case of feature envy. I'm
not too happy with that new direction.

------
srean
Now this has me a bit confused, why no love for STL ?

I wish Linus had added more detail. Is the complaint that the binaries are too
big (not quite, if you strip them of the unnecessary symbols) ? or is it that
it can be a tedium to go over the reams of error messages that compilers spit
out when things go wrong. The second point I am willing to concede, it
requires you to read messages inside out, which lisp does train you into
doing. Or is the complaint about something else entirely ?

Something else that I hear often that bothers me is the claim that STL adds
huge runtime overhead. Maybe it was true with the old compilers, but with the
current ones, GCC4.5, Intel its not true at least not in a noticeable way. The
whole point of STL was the ability to generate optimized code. I have actually
verified that the iterator based access patterns on vectors for instance gets
optimized away into simple pointer based indexing into memory blocks.

I like STL, in fact I will go so far and admit that I will not code in C++
unless I sense that I will benefit from STL and or templates. Though STL gets
used often merely as a container library I think you get more out of it when
you use its algorithms. I really like it that I do not have to write for loops
(and potentially get the indexing wrong).

If one squints the right way, it has map, reduce, filter and map-reduce all
built in (transform, accumulate, innerproduct) though I miss a vararg zip
function. An un-ignorable side benefit to using the STL primitives is that if
a parallelized version comes along the way, you get a fairly painless way to
make your code parallel. You do have force some of your snippets to be
sequential to account for the fact that there is not enough work to
parallelize. This is the direction were GCC's STL library is headed with its
parallel_mode.
[http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode...](http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html)

@cube Appreciate your comment. For writing kernels and VMs I gladly buy your
argument, to add to what you said there is the ABI mess.

~~~
huhtenberg
STL containers are essentially the opposite of what's used in many C programs,
Linux kernel included.

In C, in order to string several data items into a collection one would add a
container-specific _control_ element to the data item, and then feed a pointer
to this element to the container code. Container sees only these elements, and
nothing else. On one hand, accessing actual data item obviously requires
casting and offsetof'ing, but on other hand it allows placing the same data
item into multiple containers, and this is _great_. Think - multiple key-value
stores, each keyed by a different field in data item. Generally speaking, the
paradigm is that there are THE data items, and there are miscellaneous
supporting structures that help organizing tehm.

In C++, container is the ultimate destination for a piece of data. It is the
_owner_ of a data item. If I want a piece of data to be on a list and in a
tree, I must decide which will be the "primary" container. Alternatively, I
can store a _pointer_ to an item, but this effectively negates safety benefits
of STL containers.

[0] <http://kernelnewbies.org/FAQ/LinkedLists>

~~~
helmut_hed
I don't see this. You can have a container of pointers in C++ just as you can
in C. No special ownership semantics is assumed, nor do you have to decide
which is the "owner" any more than you do in C. Or the problem is the same, at
any rate. Plus you're not constantly casting <void*> to things.

You can have a container of smart pointers, too, if you really don't want to
think about ownership.

~~~
acqq
No, that's not the subject. The subject is, as chancho also mentions here
(<http://news.ycombinator.com/item?id=3641718>), something that's explained in

[http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive/intr...](http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive/intrusive_vs_nontrusive.html#intrusive.intrusive_vs_nontrusive.differences_intrusive_vs_nontrusive)

Since you can write C in C++ of course everything can be written in C++ too if
you don't use C++ "common" libraries and roll your own infrastructure. Once
you care about "guts" of your program enough that you have to care about
allocations, you'd see that as soon as you're thinking about "containers"
having "pointers" to "objects" you're probably on the wrong way. Because
"objects" often _contain_ pointers that make part of more data structures but
also can be of _different size_ (you can't even "sizeof" them) and also you
want to be the one who controls when and where each of them is actually stored
(in a sense of the memory block).

I've done these things in C++ without boost, more "in a C way" inside of the
separate modules (those that were critical) and I still wouldn't use boost
monster, the amount of code dependency is much smaller that way.

Also see groby_b's: <http://news.ycombinator.com/item?id=3641890>

------
davvid
Linus' rant is grounded in practicality. Portability concerns are huge for
git. Read the source code.

Git compiles on lots of (arcane and ancient) Unix flavors, and has to deal
with the compilers on those platforms. C is still the right choice for git.

~~~
Valdemar
> Portability concerns are huge for git.

Oh, is that why Git has such great support for Windows?...

...

~~~
slowpoke
"Portability" doesn't necessarily mean "runs on every system ever made". As
pointed out by your parent, it runs on pretty much all _UNIX flavors_ , even
the ancient and obscure ones. If you want to blame anything for the abysmal
git functionality on Windows, it should be Windows, not git.

~~~
jpatte
IMHO, "being portable" is more about "being available to many users" than
"being available to many systems". Focusing on ancient and obscure systems
(used by who, exactly?) while ignoring systems used by a large potential users
population doesn't make a lot of sense to me. And I don't see how you can
blame that on these major systems either.

Willing to specifically support archaic but important systems who desperately
needs git (idk, NASA supercomputers perhaps?) is fine, but that's kind of a
niche strategy; it's not about portability anymore.

~~~
tommorris
Git was built specifically to scratch the itch of Linux kernel developers.

Linux kernel developers tend to like making sure the Linux kernel works on as
many obscure architectures as possible. See
[https://en.wikipedia.org/wiki/List_of_Linux_supported_archit...](https://en.wikipedia.org/wiki/List_of_Linux_supported_architectures)

Making sure Git is portable across system architectures is quite important.

Also, portability in the "being available to many systems" thing is important
for a lot of developers. I build stuff that currently has to deploy on
SPARC/Solaris, but there are plans to make it so that in the not-so-distant
future, all that stuff will be moving to virtualized clusters of x86_64 Linux.
Portability in the narrow UNIX sense is pretty damn important to a lot of
people.

~~~
jpatte
I don't see how your example contradicts my point of view. When you move
things from a fairly popular system to a widely popular system, you expect it
to work as well as before. Now instead if you had chosen an obscure system
nobody cared about, of course you would have loved your tools would be
supported as well - but hey, you knew that choice was risky.

Of course portability is pretty damn important : it gives you the liberty to
choose the system you want (depending on your needs) while keeping the same
user experience everywhere. But x86_64 Linux systems (for instance) should not
be supported because they run Linux : they should be supported because a whole
bunch of people use them and need that support.

------
willvarfar
Symbian _was_ written in C++.

It was basically C with encapsulation. So using C++ as a better C.

It worked well. It didn't use STL nor boost and the exceptions weren't as
you'd know them. Memory management was much more carefully counted than is
normal in C/C++ programs, and reservation meant commit.

It was programmed by a pretty clever disciplined bunch. Well, most of us were
;)

------
balloot
This feels like it was written by a guy who wrote a popular OS and has had
people kissing his ass for 15 years. Basically the coding version of a diva
musician.

~~~
joezydeco
How many distributed version control systems have _you_ worked on and released
to the public? Any worth critiquing?

~~~
nxn
Had he worked on any would that have been a valid excuse to be derogatory to
others over something as childish as what programming language they use?

If you're going to ask me if I had worked on any OS kernels or distributed
version control systems, the answer is no. But I would also never degrade
people who might otherwise be willing to help contribute to my projects based
on some idiotic notion of programming language superiority.

At this point I don't even expect anything better out of him because he did
something great for the world. I expect better just because at this age he
should be an adult.

~~~
bronson
Hint: someone saying that you should rewrite your project in his own favorite
language is NOT someone that you should allow to help or contribute.

~~~
trustfundbaby
Doesn't mean he should insult them ... at some point in a person's life, they
should be above that, but that's just my opinion.

~~~
burgerbrain
Live is too short to justify not having a little chuckle at the expense of
your detractors.

------
jon6
I have used C and C++ extensively (10+ years both). I once tried to implement
the C++ inheritance model in a C program (basically just fill up the virtual
table manually). It was a complete nightmare, wrought with silly mistakes all
over the place.

Probably Linus is right that C++ does not belong in the kernel but for
application level code reinventing all the basic C++ things in C seems like a
waste of time. Linked lists, virtual methods, some form of exception
handling.. why waste your time? I laughed pretty hard when I understood how
the linked list implementation in the Linux kernel works (pointer arithmetic
tricks + sizeof). People don't even invent anything different from whats
already in C++.

The key to using C++ is to find a comfortable subset and stick with it. I
haven't used C++ on projects with more than 3 people yet so I don't know the
pains of agreeing on exactly which subset to use but I imagine it could be
done.

~~~
kabdib
One thing about inheritance: It's not necessarily a good way to model things.
Often it's a procrustean bed where you try to twist your concepts into what
the language will let you express.

I've seen a lot of people use inheritance to save keystrokes. "I can save time
if Plane inherits from Bus, they've both got wheels, after all." That's a kind
of "typing" system . . . but not the kind that people expect :-)

Honestly, the world does not often cleanly decompose into a class tree.
Usually it's pretty messy.

------
mtrn
A discussion which was inspired by this rant by Linus Torvalds on Stack
Overflow: <http://stackoverflow.com/q/1995471/89391> (Is learning C++ a good
idea?)

~~~
2muchcoffeeman
I don't know C++. The accepted response does not start off well.

"C++ is a complex language, and if you don't learn it properly, it's very easy
to shoot yourself in the foot. And that is also why you shouldn't listen to
most non-C++ programmers hate towards C++. Most of the time, they didn't learn
the language properly, so they're not really able to judge the language"

What does that mean? It sounds like, that without some significant amount of
knowledge, you can't understand it's benefits.

Thinking of the languages I know, I think the things they are trying to
improve are apparent with a basic knowledge of the language.

~~~
gravitronic
Most people learn C++ as a feature-by-feature increment over C. This means
they generally write function-oriented programming with objects instead of
object-oriented programming, mix exceptions with returning errors, stick with
pointers and char*'s instead of references and string's, and end up rewriting
data structures before finding out about STL.

That being said I use some features of C++ I like (inheritance and STL) and
while the result is somewhat bastard C/C++ it does what I need well, which at
the end of the day is all we should really ask for from a language.

------
strags
Linus's objections seem centered on the fact that it makes it easier to
generate bloated code. While this may be true, there's nothing a little self-
discipline can't control.

STL and Boost may not make sense for the kernel, but there's nothing wrong
with using C++ classes at their most basic. The kernel would be far more
readable if it used classes and _simple_ inheritance rather than re-inventing
the wheel with structs full of function pointers.

C++ gives you more flexibility with regard to encapsulation as well - it's
hard to argue that that doesn't lead to cleaner, safer code.

~~~
jmj42
"...rather than re-inventing the wheel with structs full of function
pointers."

I think you got that backwards. Structs full of function pointers predate c++.
Going for the ad absurdum, why bother inventing C++, it's just a re-inventing
of the structs full of function pointers wheel?

~~~
strags
You're right - "re-inventing the wheel" is probably the wrong phrase - I used
it because it conveys a sense of needless effort when there is a better
alternative.

Basically, those who don't have access to basic object-orientation are doomed
to implement it themselves in a messier, more verbose form.

~~~
jmj42
I think the argument that Torvalds was making here is that that's exactly what
C++ is. Messy and unnecessary. You can write C++, but if you do so without the
mess, you're so close to C that there's no point in using C++.

I, on the other hand, would argue that C's lack of object-orientation somehow
dooms one to implement it. OOP is _not_ the pinacle of software development.
Further, I would argue that "structs full of function pointers" neither,
necessarily, represents a desire for object-orientation nor is it messy.

~~~
strags
When your source code is full of structs that look like this:

    
    
      struct obj
      {
         struct obj_functions*  functions;
         ...
      }
    
      struct obj_functions
      {
         void (*do_something_with_object)(struct object* obj,...);
         ...
      }
    

... I'd say it's hard to argue that you're not implementing C++ style OOP, and
that it wouldn't be cleaner to use C++.

Now, if you're just going to stick to the basics of C++ (ie. avoid templates,
operator overloading, etc...), then there's a fair argument as to whether it's
worthwhile. Certainly it's not worth rewriting the Linux kernel at this point.

But, I don't think Linus's comment that "C++ is a horrible language" is fair.

(I'm sure most of that is just Linus being Linus).

------
dubajj
This saddens me as C++ is growing into such a beautiful language. C++11 is a
major step forward, and I don't really buy in to complaints that are not about
the current standard.

Bad programming is language agnostic. Disliking a language generally implies
that you don't know enough about it to really get it.

~~~
jgraettinger
Here here! I've really enjoyed using C++11. Feels very clean. Lambdas for
inlined anonymous callbacks in boost::asio? Yes please.

------
bleakgadfly
I find it interesting how 'everyone' seem to hate C++, yet, so many uses it.
If C++ is so bad, why does people continue to code with it? Personally I have
just started to look at C++ due to Microsofts integration with it on
WinRT/Metro for Windows 8.

I mean, MongoDB, Node.js, Microsoft's Windows Runtime (which provides access
to the systems API for both JavaScript, C#/VB.NET and C++), MySQL, Membase,
Haiku, Chromium are all notable examples of software written in C++ that seems
to be quite well.

------
Symmetry
May I recommend that if you're looking for a more considered critique of the
C++ programming language you look at the C++ FQA (Frequently Questioned
Answers) instead?

<http://yosefk.com/c++fqa/>

------
rburhum
Although it is true that certain languages give you the flexibility of writing
"utter crap", I can also write pretty crappy unmaintainable code in pure C
just as easily. Nevertheless, after 14 years of coding in C++, I love how
beautiful my C++ code comes out. All that "OO crap" makes my code easier to
understand, debug, maintain and extend. I would take that at the expense of
how much more difficult it is to create binary compatible libraries in C++
(something quite easy in C). I can see how for a kernel, that would be more
important.

~~~
cageface
I've been working on my own DSP library in C++ on and off over the past year
and a few times I've gone through the thought experiment of rewriting it in
pure C.

Every time I conclude that all I'd gain in the process is the extra work of
finding some third party collection library, adding manual resource management
where I currently use RAII, and rolling my own struct-based object system,
probably with a buch of macro glue.

I don't see how this makes my life any simpler.

------
kung-fu-master
But Mercurial was written in Python and performance is comparable to git. So,
his argument is not correct about the performance reason on choice of C over
C++. Even interpreted Python which was used in Mercurial was not speed
bottleneck. Yes, I know that most of speed critical sections was written in C.
But almost all project in Python.

Also Darcs was written in Haskell and Bazaar with Python.

I hate C++ too (over 10 years of experience). But Linus is full of _BS_ too.

Yes, choice of C language in Git is right choice. But source code of Git is
horrible and unmaintainable mess.

------
WalterBright
C'mon, guys, that posting was 4.5 years ago. It's old news, and has been
repeatedly hashed to death.

~~~
pdmccormick
The good thing about hashing something repeatedly is that the result is always
the same!

------
16s
Why not take the kernel (it's gpl code) and re-write a major part of it in
C++? And then fork that and get others to use it? That would either prove that
C++ can be used in kernel or disprove it. We could call it C++nux ;)

Then, the BSD guys would have even more reason to call Linux garbage and the
OS/language/superiority wars would rage on for even more generations. Wouldn't
that be so cool.

~~~
jiggy2011
That sounds like a lot of effort for nothing but if you fancy doing it, then
it's gpl so nobody is stopping you.

edit: I didn't see the last part of your comment, did you edit it? either that
or I have a sense of humor failure :)

------
mckilljoy
In principle I agree that C is a more appropriate choice in many situations,
but I think his pure hatred for C++ is kind of funny.

~~~
emmelaich
I think it's partly a gambit or defensive permission, or sort of an allergic
reaction to having C++ suggested to him SO MANY TIMES over the last two
decades.

------
nodemaker
I wonder what Linus thinks about Objective C as another as an alternative
approach to Object Orientation in C.

IMO Objective C gets much farther in implementing polymorphism and dynamic
binding than C++ can even dream of.

Although I hear good things about Boost, I think thats like patching the
language instead of fixing the fundamental flaws in its design.

~~~
yannickt
"fundamental flaws in its design"

It would be pretty hard to fix them without breaking backward compatibility.

~~~
nodemaker
Agreed.

------
chj
I've read this "news" like dozens of times, and every time I can't help
laughing. What he is speaking of is generally true. If I am not writing in C,
then I am writing in ASM for speed, or in LISP for less code. C++ just doesn't
fit in my tool chain, because it really doesn't excel in any aspect.

~~~
javadyan
C++ (and other mainstream languages, for that matter) excels in the aspect
that you can actually write useful software with it. Yet, to the date, there
are exactly zero useful pieces of consumer software (e.g. browsers, office
suites, video processing) written in lisp. Thus, I suggest that lisp zealots
stfu about C/C++ already, and either fix their favorite language or invent a
new one.

~~~
hkolek
Yeah, of course, right... that's why we have Lisp programs on space probes
[1], PS2 games written in Lisp [2], PG's Viaweb, Maxima [3] among others, ITA
Software, Emacs, StumpWM, and a ton of other stuff I can't remember right now.
Ah not to forget AutoCAD. I don't give a flying fart whether it's "consumer"
software or not. A ton of useful software has been and is written in Lisp
dialects and there are a lot of application domains that are really hard where
you just _cannot_ use C++ (or some other blub) because it's just not
expressive enough. Often those are not consumer applications because most
consumer applications are really mundane glorified reporting apps that could
be coded in BASIC by a monkey (and if you read TDWTF you get the impression
that happens more often than not).

tl;dr: Obvious troll is obvious.

[1] [http://www.gigamonkeys.com/book/lather-rinse-repeat-a-
tour-o...](http://www.gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-the-
repl.html)

[2] <http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp>

[3] <http://maxima.sourceforge.net/>

~~~
javadyan
Ah, "blub"... the trusty indicator of a brainwashed pg fanboy. Look, I know
that _something_ has been written in lisp, still it is not the kind of
software that people use (directly or indirectly) every day and you know it.
Plus, you're just being disgustingly arrogant by indirectly saying that your
precious lisp is too good to be used for the mundane, everyday software
development.

tl;dr: lisp zealots are funny and arrogant

UPD: FYI, AutoCAD is NOT written in Lisp, it just supports extensions written
in a dialect of Lisp.

------
truncate
I found a response to this
<http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html>

~~~
zvrba
To me, Linus lost all credibility after I've seen what mess Linux kernel code
is, and how well-written BSDs are.

------
captaincrunch
Linus is probably the %1 of people in the world who actually needs to get the
performance gain that C has over C++ - as for the rest of us? Probably doesn't
matter.

~~~
Game_Ender
> needs to get the performance gain that C has over C++

With RTTI and Exceptions disabled you should be able to get almost identical
performance with C and C++. In some cases C++ compiler has additional
information that can allow it to produce faster code as well.

~~~
dedward
Yup, and if you avoid using any of the new language constructs like objects
and whatnot that C++ brings and basically stick to standard C, maybe using
just a bit of C++ sugar here and htere, true.... but at that point you might
as well be using C, and the argument is really moot.

~~~
Game_Ender
You are wrong. Those the only two features that incur any performance penalty
for just existing, and even then it's implementation dependent and in some
cases can be zero (ie. zero cost exceptions). Other things that are possibly
slow, like virtual functions, can be avoided in specific cases when needed.
This is similar to many how C projects use structures of functions pointers,
for abstraction, but not everywhere (including the Linux kernel).

------
api
I don't _completely_ agree, though I do completely agree when it comes to
kernel, embedded, or performance-critical stuff.

One thing I love about Torvalds and that makes him great is that he has zero
respect for fads. CS is unfortunately very, very faddish. Good ideas like OOP
and Agile become fads, and then become universal hammers with everything
becoming a nail, destroying whatever virtues these ideas once had.

------
thepreacher
Its quite fascinating seeing heavy weights have a go at each other. Most of
the discussion here is right over my head but I find myself quite enjoying it.
At least its better that the current boxing heavy weight scene. This is about
the only post on hacker news that I have read comments on from start to
finish. Brilliant all!

------
mad
I submitted an interesting response to this rant a while back.

It makes some good points, despite the inflammatory technique of
characterizing Linus' rant as being caused by a "C-hacker syndrome".

<http://news.ycombinator.com/item?id=3416863>

------
yzhou
I guess what he meant was signal to noise ratio, i mean, Aplayer/Cplayer
ratio. Too many Cplayer programmer start learning c++ without any idea how cpu
and memory works, if you let them to mess with the kernels it would be a
nightmare for Linus.

------
andrewflnr
Why does the guy Linus is replying to think C's portability is BS? Anything
besides the fact that any libraries used in your "portable" program must also
be portable?

------
Moschops
For all his skills, there are no two ways about it. Torvalds is a jerk. The
kind of jerk who leads a technical rebuttal with a personal insult.

------
avgarrison
What is this site? It's full of what appears to be anti C++ propaganda. I am
left wondering, did Linus really say any of this?

~~~
Lipoly
This site also posted this
(<http://harmful.cat-v.org/software/c++/I_did_it_for_you_all>) like it was a
real interview, when in reality...
<http://www.snopes.com/computer/program/stroustrup.asp>

~~~
avgarrison
Interesting find. Now I am very skeptical of this site. Does anyone know if
Linus really said this stuff?

------
danbmil99
Breaking news this hour: Linus hates C++

------
georgieporgie
_sigh_ not this flamewar repost again.

The fact that he leads with "language X sucks because it attracts type Y
programmers" is quite possibly the worst, cheapest, and lowest attack I've
ever seen in technology. It's sad that a technical hero like Linus would
basically behave like such a tantrum-throwing child. It reflects poorly on the
whole tech community.

~~~
petercooper
_The fact that he leads with "language X sucks because it attracts type Y
programmers" is quite possibly the worst, cheapest, and lowest attack I've
ever seen in technology._

We see a similar point being made against Rubyists and Rails developers on HN
quite often, alas. And, worse, in the "I'd learn Ruby but it seemed like there
was too much drama" crowd.

~~~
gnosis
Ruby and Python both benefited enormously in their constant ragging on Perl.

I can't even count the number of times I've heard the "Perl sucks!" mantra
(often from people who have little if any experience with the language).

That sort of attitude reminds me of this diagram:

[http://img822.imageshack.us/img822/9872/programmerheirarachy...](http://img822.imageshack.us/img822/9872/programmerheirarachy.jpg)

------
Alind
But no one can deny that c++ is the most fascinating programming language in
this world. You can either spend or waste as long time as you want to
__LEARN__ this language and never can say I understand ALL.

~~~
Hemospectrum
I deny it. <http://en.wikipedia.org/wiki/J_(programming_language)>

C++ occupies an interesting point on the curve of fascination vs. _utility_ ,
but to call it the most fascinating language (by your own definition
especially) is just hyperbole.

------
nebiros
again? _sigh_

~~~
Kuytu
I feel you.

<http://news.ycombinator.com/item?id=3192238>
<http://news.ycombinator.com/item?id=401544>
<http://news.ycombinator.com/item?id=51451>

