
Why I'm Choosing C++ - flappyjack
http://www.cjdrake.com/why-im-choosing-c.html
======
JanneVee
Some people are missing the general point of the text.

Sometimes I like the "shiny new stuff" that is presented on the frontpage
here. I take it for a spinn to see what I like about it and what I don't like
about it.

But other times I just want to hack together something. Then I go and use the
tools that I know. Imperative programming with Python, C++, JavaScript and C#
with a sprinkle of functional ideas.

Why? Because it is about getting things done, and not learning the idioms of
the new shiny stuff. You can try to convince me of the virtues of going with
something less mainstream, but I have inertia... And some of you reading this
have that too.

I occasionally see comments here with some reflections of "guilt" over that
they don't use the new language/framework du jour. I don't feel "guilt" and
not going to apologize that I use the tools that I use. This is how I've
solved programmatic problems most of my life and I'm going to continue doing
so. But it doesn't mean that I'm not trying to learn something else. Maybe
someday I'll be doing functional programming with a language that
automatically parallelizes my code, but right now I just can't shift my
mindset to do it. I'm too busy building stuff with the tools at my disposal.

~~~
greggman
I haven't read the OP so I'm responding to your post. I am/is/was a C/C++
programmer from the mid 80s until 2013. That's the last time I wrote some C++,
not that I've given it up just haven't need to to write any.

What changed for me was I learned HTML/CSS/JavaScript and in particular WebGL.
Now I kind of get, upset may be too strong a word but, basically I can't stand
not being able to share something easily. I see people making simple visual
things in C++ or Python or GO and I'm like "why are you making me jump through
hoops to see your creations? Why couldn't you just put it on the web so in one
click I could see it and/or interact with it?"

I'm not saying there's no place for C/C++ or any of those other languages. I
am saying though that if what you want to make is something interactive or
visual (or audio) and you can do it in such a way that you can put it on the
web PLEASE do that! C/C++ run it through emscripten. C# (well, if it's unity
at least might be able to export to the web). I don't know of the Go->Web or
Python->Web paths but mostly if it's not on the web I'm not likely to download
and install an SDK just so I can check out your Go program.

If you're making an app or backend something fine, whatever, but if you're
just making a visualization, a graph, a simple game for fun but not profit,
please consider learning the tech that will lead to the least amount of
friction for your audience. Most of the time that will be web.

~~~
JanneVee
Well that is half of my point. I mentioned JavaScript, because I use it if I
want most people to see my stuff. But what is wrong with a executable for C++
or C#? Where is my obligation to distribute a executable for every platform
that results from my fun side projects? I don't think maintenance is fun and I
usually skip that part on my side projects. Either you can see it or you
can't... it might bother you... but it doesn't bother me the least. They are
supposed to be fun...

------
eridius
Modern C++ is certainly good compared to old C++, or compared to C. But this
article completely glosses over why the author chose not to go with Rust. From
just the article alone, my impression is basically that the author just
decided to lump Rust in with all the other "shiny" languages and didn't really
look into it much. And that's a real shame, because unlike any of the other
languages that are listed, Rust is basically a better alternative to C++ for
almost any usage of C++ that doesn't require interoperating with existing C++
libraries (or vending new C++-specific APIs).

~~~
santaclaus
> Rust is basically a better alternative to C++ for almost any usage of C++
> that doesn't require interoperating with existing C++ libraries

What often isn't mentioned is that C++ has a much more diverse ecosystem than
Rust. C++ has four major compilers, three major standard library
implementations, and 30 years of associated tooling and library development.
Occasional serious issues in GCC and libstdc++ (or Clang and libc++, or in
Microsoft, ...) do crop up, and the ability to cross reference alternative
toolchains is quite valuable. If Rust can hit enough critical mass the
ecosystem will develop, but it isn't there, yet.

~~~
dikaiosune
But those same features make it very bewildering and difficult for newcomers.
Four different compiler behaviors to read about in any area not defined by the
standard, tooling that can require a long and complex setup from an expert,
and 30 years of differing opinions about good development practices crufting
up learning resources.

~~~
fsloth
"But those same features make it very bewildering and difficult for newcomers"

Yes, that is very true.

"tooling that can require a long and complex setup from an expert"

If one is on windows, one can 1. install visual studio community edition and
2. click "new project".

Sure, it's nowhere close to npm or Rusts's crates or go's dependency
management but that's bit hyperbolic way to express it. I can waste hours
trying to get Rusts' dependencies working if I'm using something bleeding
edge.

~~~
dikaiosune
Not having used C++ on Windows, I have to take that at face value. But getting
autotools or cmake set up as a new C++ developer...not super fun. Also,
spending lots of time setting up bleeding edge features is different than
trying to get a single working build with a couple of fairly standard
dependencies.

~~~
fsloth
"But getting autotools or cmake set up as a new C++ developer...not super
fun."

Yes, this is the main reason I prefer visual studio :). I know my way around
unixes but since I don't use them for my daily work I forget most of the
things I would need to remember to be productive.

~~~
Aeolos
Until you need to build a cross-platform cmake-based project on windows. Which
means modifying the system path using the lovely "environment variables" panel
straight from the Win95 era, downloading and compiling dependencies (half of
which fail to compile on MSVC due to lacking standards-compliance), dll hell
and all the other MS cruft.

Contrast to apt-get install foo-dev or brew install foo on Linux and MacOS
respectively.

~~~
fsloth
"Contrast to apt-get install foo-dev or brew install foo on Linux and MacOS
respectively."

Having a project that builds painlessly on third party developer machines
requires effort from the project and is not guaranteed automatically by the
chosen platform.

Apt-get also can fail if the dependency chain does not match exactly the
configuration required by the project one wants to build.

The best way to build software on windows is different, perhaps even less
elegant, but claiming that Linux/OS X builds are automatically correct does
not match my experience.

Projects which have an incentive to provide a windows build usually can be
built out of the box pretty painlessly, even with CMake.

From my experience, the best indicator of a pain free build on a platform is
the number of users the project has on the said platform, not the platform.

------
lifthrasiir
I think the modern C++ is indeed a good alternative to other modern languages
listed in the OP for _who already knows the pre-modern C++_. That is, you
still don't get an automatic correctness (of sort) implicitly provided by all
those modern languages, and you being able to avoid the traps is not a proof
that it would be universal. I really hope that C++ Core Guidelines [1] are
successful enough that it is actually enforced and thus you _finally_ get the
correct feedback from the compiler, but until that point, I'm not choosing
C++.

[1]
[http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines....](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html)

~~~
santaclaus
With ranges pretty much a sealed deal, if we can get modules and reflection,
to boot, C++ is going to feel hella fresh.

~~~
Aeolos
With the amount of pushback and bikesheding, I don't expect reflection to
happen this decade at all. For me, modules would be killer. This is right now
the single biggest issue facing large C++ codebases.

------
dikaiosune
As someone who recently tried to do "modern" C++ with no background in C or
C++, it was absolutely horrifying compared to my nice cuddly managed language
runtimes. I get that it's not meant to be a language that's quick to pick up,
but the languages that OP decided not to use _are_ quick to pick up in
comparison. And several of them offer many comparable features (whether you're
evaluating the metaprogramming, the performance, etc.).

~~~
jmspring
No background being key. Learning takes time. Coming from older versions
forward of C/C++ (though most people don't crow about a particular version) is
easier than what you propose.

Having a strong foundation in classic languages and an ability to adapt to
modern paradigms seems way easier than the reverse.

~~~
dikaiosune
Absolutely, that's a much better way to put it. But it's a situation that (I'd
wager) many more developers are in, as opposed to already knowing an older
dialect of C or C++. Given the growth the field is still undergoing, and the
number of devs who never need to learn one of "the classics," I don't think
it's bad to point out that there are good alternatives to C++ that are easier
for someone versed in managed languages to pick up if they need some of C++'s
strengths.

~~~
jmspring
Given the cyclical nature of this field, adaptability should be a core
component of one's aresenal.

For instance at a low level, machine to machine communication, C over the
internet, Node APIs, etc shouldn't matter to getting things done...

API and functionality can be decoupled, but you will still need to have
someone available to understand the path from A to Z

------
nemo1618
>I want to congratulate the C++ standards committee for all the work they've
been doing lately. And they're not even slowing down! The roadmap for C++17
looks like we'll get even more fantastic features...

This is exactly why people avoid C++. More features != better language.

~~~
izacus
C++ is an officialy supported option for pretty much any platform out there -
including iOS, Android and Windows. Together with relevant debuggers
(eventhough the Android/NDK GDB integration leaves something to be desired).

Rust isn't there yet and when opting for a longterm project you want
stability, access to experienced developers and good time-tested libraries. I
love the idea of Rust but I'd still not consider it for use-cases we use C++
in for at least a few years still.

~~~
fsloth
Thanks, you wrote the exact thing I wanted to point out.

For some reason people seem to forget there are still programmers for whom the
only platform they need support for is not just the deployment server.

------
0xFFC
I genuinely don't understand C++ direction, where it goes?

C++ does change too much, language (specifically in this level,python is okay
to change) aren't suppose to be stable as much as possible ? every 2,3 year
they literally add new language to existing C++.

What decision should existing library take? rewriting whole library? rewriting
critical part ? in these case almost all of developers time should be devoted
on rewriting existing C++ code.

look at C. They don't add shitpile of feature to the standard every 2,3
years.The may fix some criteria.But it does not even count in compare with
what C++ committee doing.

p.s. one of my friends in college used to joke about C++. He calls C++ :
"feature adding contest".

~~~
danieldk
_C++ does change too much, language (specifically in this level,python is okay
to change) aren 't suppose to be stable as much as possible ? every 2,3 year
they literally add new language to existing C++._

Well, before people were complaining that C++ didn't change enough. The core
language did not really change from 1998 to 2011 and that was showing. That
said, I cannot really see what the complaint is about, since you can still
program in C++ as if it's C++98 or C++03.

(I share most common critiques of C++ and think Rust is probably its
replacement. However, it's a fact of life that there are major C++ codebases
out in the wild and there will be for the next 50 or 100 years. So, it makes
sense to evolve the language for such projects.)

~~~
easytiger
> before people were complaining that C++ didn't change enough

Mostly people who didn't use it.

~~~
AnimalMuppet
On the contrary. It was precisely the people who _did_ use it, and knew that
what they wanted it to do would be so much easier if it just had reference-
counted pointers... or move semantics... or...

------
pcwalton
I'm struggling to see how the Verilog vs. VHDL mailing list post the author
linked to argue in favor of C++ (which, as far as I can tell, consists of
various rants about specific aspects of VHDL that have nothing to do with
higher-level languages) is relevant to C++ vs. Rust at all. Why not argue
specifically against Rust's safety features instead of giving tenuous
analogies to hardware description languages, of all things?

------
democracy
I recently tried C++11/14 features in my Eclipse IDE with GCC and I actually
enjoyed it. It does feel like a new great language.

I wish Java had __auto __type (the idea I believe Java people omitted for
several reasons).

I also think the C++ community is really great - and this reason alone is able
to give this platform a promising (than for many others) future. The youtube
conference videos are awesome and I learned quite a bit from these lads (even
doing Java full time).

------
fishnchips
Based on the few years I spent working in big C++ shops the obvious thing is
that the popularity of C++ is largely based on previous popularity of C++ -
internal libraries, easily hired external developers etc. That, and the
constant development of C++ - because the language is regularly getting new
features (and cool features at that, I mean look at C++11) there is little
incentive for folks to say "this language is dead, let's move somewhere else".
With a large pre-existing C++ codebase you have a choice of writing SWIG
wrappers, embarking on a quixotic task of rewriting core libraries natively in
your language of choice or just going with the flow. The first thing destroys
your soul and the second one is a career killer so I would expect C++ to have
great many years ahead of it despite sometimes atrocious compilation times.

~~~
AlexeyBrin
Hopefully the compilation time will be drastically reduced in C++17 with the
addition of modules to the language. Obviously, this won't be of much help if
you work with an old codebase or old libraries.

~~~
fishnchips
Which is unfortunately the case for the places I've been. Modules could
perhaps persuade some folks to start new codebases in C++ but these days you
have less incentive to do so given a choice of decent systems programming
languages. Surely I'm a sample of one but being a reasonably competent C++
coder I tend to start most of my new projects in Go.

------
happywolf
Anyone here uses D? I recall it was kind of popular a few years back, and its
features look very similar to Rust. Thoughts?

~~~
aidenn0
Andrei Alexandrescu points out one major issue being that D went with a GC
first approach, and even though the GC is optional, the library support isn't
as good.

For at least some problems people will not want to use a GC, and D's story
there isn't as good as Rust's.

~~~
Ace17
To me, garbage collection is a hack, trying to workaround the fact that we
don't know how to deal with ownership. This is something Rust and C++ get
right (unique_ptr, the whole Rust ownership system), and I would definitely
prefer D being based on an ownership system, rather than a rogue thread
randomly scanning your memory for things that look like addresses.

However, the garbage collection in D turns out not to be an issue in practice.
In D, you do have destructors and deterministic deallocation when you want to
(in one word: RAII).

~~~
theseoafs
> To me, garbage collection is a hack, trying to workaround the fact that we
> don't know how to deal with ownership.

Eh. Often the whole "ownership" thing is irrelevant. For a lot of high-level
programs, trying to express things in a Rust-ish "ownership" style with
pointers adds a lot of syntactic and semantic overhead.

~~~
danieldk
_Often the whole "ownership" thing is irrelevant._

I don't see how it can ever be irrelevant, unless you use immutable data
structures everywhere. Does your class/struct provide getters? Ownership! You
have to think about what you return. When you are not careful, the calling
code can break invariants of the data structure. Consider the following Go
code:

    
    
       type Foo struct {
           sortedSlice []Bar
           // ....
       }
    
       func (f *Foo) sorted() []Bar {
          return f.sortSlice // Outside world can break invariants.
       }
    

Now the outside world has access to internal state and can break invariants
(make sortedSlice unsorted). You have to decide to: make a copy (and waste
time) or document this fact (and put the burden on the user of _Foo_ ).
Suddenly, knowing from the signature what the ownership is and having the
compiler fail on violations, looks pretty useful!

Tony Hoare once called the null pointer his one billion dollar mistake. I
think the lack of ownership semantics (or immutability) is an even bigger
mistake. Some of the most difficult and aggravating bugs that I encountered
(even in relatively simple web services) were caused by (a lack of
understanding of) ownership. Throw in some concurrency and you have bugs that
occur frequently, but are terribly hard to reproduce consistently.

------
edwinnathaniel
I don't mean to hijack this thread but I've been wanting to learn C++ for
desktop-app and game related side hobby. I'm wondering if I could get some
suggestions on where to start given my background as a Java and JavaScript
developer (I do mainly web-application/back-end development) by day and had
done C for the majority of my university courses (I take a few system-
programming type of courses: OS courses, Computer Network courses, Dist. Syst,
and DB). I did a bit of C++ for algorithms/data structure courses and am
familiar with basic C++ (new/delete, OOP in C++ to some extend, STL).

I'm afraid Java spoiled me with GC, cross-platform libraries (especially the
concurrency API, Joda-Time, Joda-Money, etc), JUnit, SCM (build, dependency
management by Maven), great cross-platform IDEs that I'm really having hard
time dragging my feet to C++.

Should I start with C++14 and skipped anything before that?

Any tips in how to deal with dependency-management and build in general?

What about unit-testing framework and some best practices?

~~~
fsloth
"What about unit-testing framework and some best practices?"

A random collection of anecdotal stuff and opinions that comes to my head:

For common utilities for game development stb libraries are fantastic:
[https://github.com/nothings/stb](https://github.com/nothings/stb)

For general idea how to structure code you could google "data oriented design
c++".

Try not to structure your solution around class hierarchies but prefer data
pipelines.

Write your code so that it's easy to debug.

Prefer to structure your solutions around stl containers and stl algorithms.

Avoid using inheritance as long as it does not reduce code complexity. If you
use inheritance prefer to use only abstract base classes. Do not use template
metaprogramming unless you are absolutely sure it's the most simple way to
solve your problem. Avoid multiple inheritance like the plague. Ignore my
advice if your problem is such that they don't make sense.

Try not to solve any other problem than the one you have immediately in front
of you, and solve it as fast and simply as possible. Do not try to create some
"framework" to solve your problems but prefer simple code. Refactor your code
as your program progresses. This point might be obvious - but for me
personally has been the most difficult thing to learn - writing agressively
simple code is the best thing I've learned. This does not mean that the
abstractions that are implemented are necessarily simple - just that the
implementation is as easy to read, easy to debug and easy to reason about it's
dependencies, as possible.

If you can trade off complexity of dependency with a little bit more code,
prefer little bit more code. I.e. if you have an itch to include a library
because you need a single function, think hard about implementing or copy
pasting the function to your codebase. Once you are confident enough that you
know you need something, only then include it.

Learn some OCaml :) - really, I feel like much better C++ programmer after I
understood how a properly designed language with a static type system works.
(I hear "Real world OCaml" is a good book).

~~~
Aeolos
> Learn some OCaml :) - really, I feel like much better C++ programmer after I
> understood how a properly designed language with a static type system works.
> (I hear "Real world OCaml" is a good book).

This.

Or F#.

------
agibsonccc
FWIW: I've found C++ to be a necessity when trying to put together cross
platform numerical software[1] that works on the gpu as well as cpu (with all
the right auto vectorization etc) The killer app for me is being able to
interop with any language (jni, or cython) easily. I know rust and go have
good ffis (light years of ahead of java where I spend a lot of my time)

This is definitely a niche compared to normal web development though. A lot of
what I like is what's already been mentioned: the mature ecosystem. I'm sure
the new contenders will mature over time. I'm really looking forward to using
rust. I can't justify learning it yet though ;/

[1]:
[https://github.com/deeplearning4j/libnd4j](https://github.com/deeplearning4j/libnd4j)

------
petke
I have never been as excited for the future of cpp as I am now. Cpp17 and
cpp20 are going to be revolutionary when it comes to concurrency an
parallelism.

In cpp17 we get couroutines. Its like await in c# only more general and
powerful. In cpp20 we will get parallel executors. Kindof like cppamp and
openmp only more general and powerful. It will bring supercomputing
mainstream.

Its exciting times for cpp. There are already some experimental
implementations to try out. There are also a bunch of other big features
coming out. Modules, concepts, transactional memory, compile time reflection,
ranges, views, etc.

People can hate on cpp all they want. I'm super excited, and think they are
missing out on the future.

~~~
pcwalton
Both of these have been done for years in other languages.

The claim that parallel executors bring supercomputing mainstream is puzzling
to me, because OpenCL has been around for a long time, is more widely
supported, and is far easier to run on e.g. GPUs than the full C++ language.

~~~
petke
Its not been done as general as this though. Check out this link if you have
the time. Especially the last 15 minutes. Its by the ceo of openmp and its
very interesting. [http://youtu.be/0mwHJ0950tA](http://youtu.be/0mwHJ0950tA)

~~~
petke
I find it surprising how little interest there is on hn about cpp in general.
This video about the future of cpp is the best i have seen this year. My guess
is the demographics of hn is just wrong for cpp. Its mostly web developers
here?

~~~
autoreleasepool
Yes, HN in general is anti-C++, a quick search for previous discussions proves
this. For some inane reason, the language makes a lot of people upset and
pouty. People love to hate it. To be honest, it's getting old. It's the same
bitter sentiments over and over.

I turn to reddit for substantive C++ discussions.

EDIT: fwiw, I've found the actual cpp community to be a delight.

~~~
pcwalton
> For some inane reason, the language makes a lot of people upset and pouty.

People here have cited specific problems with C++ over and over. There are
legitimate criticisms of the language that aren't "inane".

Personally, my biggest issue is that it's not memory safe, which leads to
people making the same memory management mistakes we've been making since the
'70s. At the same time, attackers have seen ways to weaponize use after free
in ways that were not thought of when C++ was designed—and C++'s vtables make
it much easier to do so. RAII and smart pointers have not proven to be an
effective way to mitigate this, as a trip to any Web browser's bug tracker
will demonstrate.

I do not believe this specific problem can be effectively fixed in C++, even
with the ISO Core C++ lifetime checker, for reasons that I've elaborated on at
length before.

~~~
autoreleasepool
> There are legitimate criticisms of the language that aren't "inane".

Please don't misquote me. I did not say criticisms of C++ were inane.
Obviously there are many legitimate criticisms.

What I said was the reason people get so upset about C++ must be inane. IMO
there's no good reason for an adult to get upset over a programming language.

------
makecheck
C++ has definitely changed in important ways, and I continue to use it for
several things (both to manage legacy code and by choice for newer code).

Having said that, C++ really, _really_ needs to start throwing out its bad
ideas and creating sane defaults that mercilessly break backward-
compatibility. This applies throughout the standard library and the language.
It can be done in phases (e.g. identify bad behavior; introduce an opt-in
compiler mode per file to change defaults and not allow the bad practices;
wait a few years and change the default; wait a few more years and remove the
old mode forever). C++ also really ought to provide a standard way to
partition unsafe behavior from safe behavior; the vast majority of programs do
_not_ need the crazy things that are possible in C++, and it shouldn't be a
big deal to require extra keywords or compiler modes to enable dangerous
language features.

~~~
pcwalton
> C++ also really ought to provide a standard way to partition unsafe behavior
> from safe behavior

I'm not really sure this is going to be feasible, assuming by safe you mean
memory-safe like most other languages. The ISO Core C++ lifetime profile is a
very interesting attempt, and I hope it works out, but there are serious
issues I see around shared_ptr and aliasing that lead me to doubt how much use
it'll get.

------
hp
If you need a bunch of library features not found in the C standard, you could
switch languages or you could ... use a library. "Use language builtin hash
table or write your own hash table" are not the only two options as this
article suggests!

Quite a few hash tables out there, and very complete standard-library-like
utility libraries too. (aside: failure to use one of these is a major cause of
bad, bug-ridden C code, containing for example calls to dangerous old-school
string API from the standard library. If your C is of any size and you don't
have a good string abstraction you are doing it wrong.)

There are lots of circumstances where I'd use something besides C, for sure.
But if I was using C for a good reason, and needed a hash table, in most cases
I would not write my own.

------
markpapadakis
I moved to C++ in 2000, from C, because it made it easier for me to do more
with less code, and as consequence of that, require less time to build what
was needed and less time to debug and maintain it. I have looked at various
other contenders over the years for a replacement, not because I felt I needed
one, but because they all had something interesting to offer, and because the
buzz have gotten to me. I have concluded that C++, especially with the recent
‘modernization’ initiatives (C++11/14/17) is as good as it gets for me,
considering my needs and expectations, and obviously factoring in my
familiarity with the language.

Most popular programming languages nowadays are providing fancy runtime
features (GC, introspection and reflection, dynamic dispatch) at the expense
of performance and unpredictable operation. You may get some control over the
execution semantics, but not much. For most use cases, I suppose this is fine,
but when you go deeper or higher(in the Y performance and scalability axis),
you start to question your choice and realize you don’t know what is really
going on, especially if the profilers tell you that the culprit is the
language runtime, and so you end up spending your time working around the
language limitations instead of doing ‘real’ work.

The prevailing opinion nowadays is that C++ is complex, and use of templates,
operation overloading, and even hierarchical objects structure, makes it hard
to understand what is going on. It certainly mystifies many ‘pure C’
developers who are eager to come out and speak against the language, as if
they are on some sort of mission to bash it, or just because they are not
familiar with the language themselves and, well, if other like minded people
are speaking against it, they may as well join them.

C++ _is_ is a superset of C, and everything availed by C++ is optional — you
absolutely don’t need to use anything you don’t want to use, or don’t feel yet
comfortable using. I don’t understand why this just escapes more people who
speak against it. Maybe because it’s not helping their cause, whatever it is.

There are brilliant people who will work around the limitations of a language
and deliver incredible products, frameworks, libraries (Aeron -
[https://github.com/real-logic/Aeron](https://github.com/real-logic/Aeron)
comes to mind). There are languages that are better suited to many tasks than
C++ - where performance is a big concern, but managed runtime environments and
writing high level code makes more sense (or maybe you just care about
compilation times, a very valid concern). There is no perfect programming
language.

There is only the language that works best for you and your needs. For me,
that is C++, and I can’t wait for the C++17 updates.

------
kilon
last time I used C++ was back in 1996 and my conclusion was that is a horrible
language with even more horrible libraries like MFC which made me quit it for
Delphi. 20 years later on, being mainly a python dev and lately working with
lisp and smalltalk, I decided to go back to C++ because I will be using Unreal
Engine heavily for making games. So I was eager to see what have changed in
the mean time and whether that would change me my belief that C++ is the worst
language I ever used .

After several tutorials, text books, learning the new features in C++ 11 etc,
my mind has changed. C++ is a horrible language trying to get better. Beyond
the usual crap and total disregard of good design that this language and its
libraries exhibit , it does not fail to suprise me something like
fstream.good() to detect that the file has not reach its end , its just blows
the mind.

But C++ is a necessary evil in my case, so the torture continues.

~~~
pjmlp
As someone that went Turbo Pascal/Delphi => C++ as Borland lost touch with the
developer community, the biggest problem to replace that necessary evil is
getting newer languages into OS vendor SDKs.

On my case, if the language is not part of the SDK, usually it no use
discussing its use with the customers.

At least C++ is way safer than C, if one cares to use its features.

~~~
kilon
There lies the problem, C++ reigns king in making games and many other area of
coding. The language may be horrible but there are ways to avoid the horrible
stuff and use some libraries that are far better design. Nowdays for example I
would use something like QT which is very well made, to avoid MFC.

Thats the issue with offering an alternative to C++, its not enough to offer a
better design language you also need to replace countless of C++ libraries
that very capable , mature and very well established. Hence why there is no
true C++ replacement out there beyond Java.

Delphi was awesome in countless diffirent ways but just lacked the library
support to make it as popular. But at the time was as popular as python is
nowdays with around 1 million developers and Borland C++ had 2 million.
However at the same time VB had around 6 million and Visual C++ much more than
that.

C++ is way safer than C but also way more complex. Which comes as no surprise
why C is the go to choice for small libraries. Frankly I rather go C++ as
well.

~~~
pjmlp
At work we migrated from C++ to JVM and .NET languages around 2006.

So where we get to use to still use C++?

Interfacing with hardware, COM libraries, JVM/CLR agents and lately portable
native code across mobile OSes.

Someday using Rust, D, Go, Swift will be an welcome option, but they aren't
there yet, at least for the type of customers we work with.

------
beshrkayali
> Programming languages have a lot in common with religions. You can spend
> your life searching for the "one true" way, and either find enlightenment,
> or discover you were worshipping false idols.

True that.

------
irq
I really wanted to read this but the font size is microscopic on mobile. And
if you zoom in, you have to scroll horizontally, a lot. Nigh unreadable.

~~~
copperx
All modern browsers have a "reading mode."

~~~
reustle
Do they? I'm on chrome mobile and chrome desktop and can't find anything like
a reading mode.

~~~
Ygg2
I think GP meant Firefox. It has reading mode in android and desktop versions

------
Apocryphon
I'd be curious to know if anyone's ever used Objective-C as an OO language
substitute for C++.

~~~
bboreham
I learned Objective-C in 1988 (yes, really), as a serious competitor to C++
for the project we were embarking on. But, prior to AutoRelease its memory
management made it basically unusable.

I became something of a C++ expert for the next 20 years. I turned down a job
in 1994 because it was in Objective-C and I perceived limited future.

Later, wishing to build iOS apps, I re-encountered Objective-C. I guess I had
the choice to write substantially in C++, but Objective-C is good enough for
most app stuff and I never bothered.

