HN Theater @HNTheaterMonth

Sorry, it too me a while to get around to reviewing the suggestions here. I just watched [1] and found Kate's style quite impressing. For instance, I loved the analogies she used (the weird complicated statue, the simple metal ball, the legos) to convey what she means by simplicity], as opposed to what people would normally think "simple code" would mean. I think this is not too different from how great presenters sometimes use cultural references, even memes, to tell a mini-story about their ideas.

Thanks for mentioning her - I'll definitely watch more of her talks.

[1] https://www.youtube.com/watch?v=n0Ak6xtVXno

The "Simplicity: Not Just For Beginners" talk does a great work of touching the problem from the opposite angle : https://www.youtube.com/watch?v=n0Ak6xtVXno

⬐ starbugs

Indeed a great talk.

Here's the related HN discussion link: https://news.ycombinator.com/item?id=18093158

⬐ diegoperini

For some reason Youtube's recommendation algorithm has been pushing me this whole day. Is this the same for you?

⬐ oscii

That's because Kate Gregory is a terrific teacher! I like her talks and teaching style a lot.

⬐ pjmlp

She is one of the best speakers in the C++ community, really love her work.

⬐ teknico

Simplicity and C++? Like speaking of rope in the house of the hanged, as we say in Italy... Congrats for the effort though.

⬐ pdpi

There has been something of a push towards a simpler style of C++, and the speaker (Kate Gregory) is one of the best at articulating how and why it can work.

Incidentally — in principle, most of this talk is applicable to _any_ software engineer. It's just that she's coming from a C++ point of view, and talking at a C++ conference. It's definitely worth a watch.

⬐ tonyedgecombe

You can't make C++ simpler by adding more to the language.

⬐ fsloth

Disagree. In the sense that the code one writes gets simpler. Range based for loop alone does a lot. Auto destructuring of tuples, initialization lists, std::variant... etc. all do their part in making new code less verbose and less bureaucratic. It's just sugaring but it's at least a standard sugaring.

⬐ beached_whale

Also, small functions are generally free to call and are often inlined. So you can keep your function simple and at a consistent abstraction level without paying for it. Do this until proven otherwise, with real perf data. I find a lot of people are afraid of this or they say that they don't know what is going on. I suspect some may also prefer writing in asm and not using abstractions to tell the story.

⬐ veli_joza

The code one writes does get simpler. Unfortunately, the code some dozen developers write ends up with all imaginable ways of writing the same thing. That's my biggest pain with C++.

⬐ fsloth

"the code some dozen developers write ends up with all imaginable ways of writing the same thing."

I do know what you mean. But that's not really the languages problem but of the coding guidelines and using code review to maintain legibility.

⬐ veli_joza

I don't know. I don't have the same problem with Lua and Python. Lua is simply small enough not to have baggage and Python seems to have a healthy community that keeps updated with best practices. It also helps that both languages are designed to be readable. C is also simple enough, as long as code doesn't abuse pointers.

⬐ Yoric

While I agree that C++ has improved a lot, and while all these extensions to the standard library can, when used carefully, considerably increase readability... well, there remains the fact that they still need to be used with extreme care.

See https://github.com/isocpp/CppCoreGuidelines/issues/1038 for an example of what I'm talking about.

So, readability increases, but the mental load of making sure that stuff doesn't break in subtle and non-euclidian ways keeps increasing, at least when refactoring existing codebases.

⬐ fsloth

Yeah, memory handling is still challenging to handle correctly - in the sense it need forethought and constantly remembering what one can and can't do (list iterators good long term references, vector iterators bad long term references, etc). string_view is a good example of a situation where garbage collector would save a lot of headache.

⬐ EliRivers

The simplicity isn't in the language. It's in the programme written with it. That's where it's needed and that's where it counts.

⬐ 01100011

But I seem to remember watching a talk by Kate Gregory in the last few weeks where her main point is that you really need to have a full understanding of the language to program in it. So if C++ has baroque complexity that is shunned by best practices you still need to be aware of it. I know the C++ folks would like to escape their past but there just isn't a good way to do that, short of a clean break with backwards compatibility.

I bet they could actually pull off a break with old code if they would release tools, ala Abseil, which took care of migration for you. I think it's reasonable to accept that legacy code needs to be freshened up every so often to allow the language to evolve. We have Google translate for human languages, why don't we have it for code? It seems like a far easier task.

⬐ mhh__

You can't make C++ simpler but you can make some C++ simpler, as in the programs written in it. C++, the language, is too old and too widely used to be made simple.

⬐ octo_t

This was actually the topic of Herb Sutter's talk[1].

Things like meta-classes will drastically simplify end-user code.

⬐ pjmlp

Sure you can, by introducing language features that make it easier to achive the same while being less error prone.

For example, in template metaprogramming we can get rid of tag dispatch and SFINAE thanks to static asserts, constexpr and if constexpr.

Likewise you might decide to shot your code with C style arrays, or use the STL data types with bounds checking enabled instead.

⬐ beached_whale

static asserts do not replace tag dispatch and SFINAE as they don't affect the overload set, the instantiation has already happened at that point. However, concepts will do this in, probably, c++20. For now, is_detected is like a concepts lite that allows for a big simplification.

One thing to remember though is that there are two things at play here. The library writers tools, like TMP, and the users. The users can do a lot and never worry about SFINAE/tag dispatch. The library writers use it to allow the users of the library to have a potentially very simple experience.

Also, Greenfield C++ can be way different than pre 2011 C++. The cost of things that people would work around has gone way done to zero in some cases. Like returning a value from a function is like constructing it in place at the caller. So that takes away a need to use the heap to allocate it or to copy it when you return it.

⬐ beached_whale

I should say, I mean the overload has already been found at that point.

⬐ pjmlp

Thanks for the correction, I was simplifying, without going into enable_if details and such.

⬐ beached_whale

enable_if is ugly. But a lot of the extra ugliness is people putting everything into the condition and not abstracting the parts of it into other traits. Just like looking at long functions.

⬐ danbolt

I hope that at some point C++ programming can have a solid "good parts" style guide, akin to Crockford's JavaScript book.

I feel a lot of that probably isn't conventionally achievable since C++ covers a lot of situations with different needs, but if 20% of the functionality could cover 80% of the needs at some point I think it'd be great for the language.

⬐ berti

Like C++ Core Guidelines? https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

⬐ AnimalMuppet

Stroutrup's "Tour of C++" might be what you're looking for.

⬐ emsy

I still don't understand why people bother with template metaprogramming. And I genuinely mean it. Other languages have much simpler and nicer constructs and seem to work just fine. And even within C++ you can often solve the problem with more verbose, but simpler code. Every time I read an article or watch a talk on it I have the impression that people use it because they can, not because there's some huge upside in using them. Did I miss the magic "aha" moment?

⬐ namirez

Template metaprogramming is the most powerful feature of C++. It's true that the syntax is clunky, but since I started using templates, I've never looked back to the old style of coding. C++20 will be even more powerful by adding concepts to templates.

⬐ pcwalton

There isn't a defensible reason for untyped templates. Generics and concepts are a better design all around. It's not only error messages that matter: scoping matters more, as the problems with templates in that regard are the reason why C++ has the ADL mess.

Concepts are one of the most important features C++ needs.

⬐ Rusky

Too bad we're stuck with concepts-lite, where templates are still untyped and the scoping is all still done the same old messy way.

⬐ polskibus

Zero-cost abstraction. In most cases constructs in other languages either lack expressiveness (generics in C#) and/or induce runtime costs (boxing/unboxing, etc.).

⬐ krylon

In many (most?) cases, you do not need the performance (which is why people use C#, Java, etc.).

When the performance is needed, the burden of using C++ seems like a small price to pay[0], but a lot of the time, the expressiveness offered by C# or Java, etc. is entirely sufficient. Which is why "enterprisey" software is dominated by Java or .Net, and why certain software like Autodesk Inventor 3D is written in C++.

[0] Which is why browser engines, etc., are written in C++. Maybe one day Rust will replace C++, but for the time being, C++ is the top of the abstraction/performance pyramid.

⬐ None

None

⬐ bluGill

The magic moment is when you realize that your month of pain writing something complex saves the company years of writing the simpler version by hand. In the template a fixed bug is fixed once and for all. In the other version fixing a bug in once place doesn't mean anything about anything else.

Note that for the above to apply you need have a domain where there will be enough uses to make the generic version worth it.

Of course, just like it is fun to write code for the IOCCC, there is some perverse fun in writing complex templates.

⬐ Yoric

I would argue that what you're describing is even truer for generics than for templates. Don't you think?

⬐ bluGill

Generics is why we do templates in C++.

That you can use templates for something else is almost entirely useful only if you want to win something like the IOCCC.

⬐ hfdgiutdryg

With regular inheritance, you affect behavior from the bottom up.

With the "Curiously Recurring Template Pattern", you affect behavior from the bottom up and from the top down.

To be honest, I don't know if it has value for most tasks people care about (outside of libraries, I mean). But it was fantastic for optimizing OOP-abstracted desktop applications. If you have some subset of functions that need to be called a lot, then avoiding virtual functions really helps.

⬐ nitwit005

I'd note that the nicer constructs you see in other languages were often based on people's experiences with C++. You can pretty clearly see some syntax and ideas copied into Java/C#, but it's true elsewhere as well. It's not surprising that newer languages learn from the past.

That said, almost all of those nicer variants do come with some added runtime costs. The general problem of making efficient generic code, without a bunch of boilerplate, and with a nice syntax, seems fairly difficult.

⬐ Const-me

> you can often solve the problem with more verbose, but simpler code.

Sometimes. Other times, templates are simpler.

> I have the impression that people use it because they can

I think people use template metaprogramming because they see it in standard library, but they don’t understand the requirements for C++ STL were very different from the requirements of the code they’re personally developing.

I use C++ templates for following reasons.

1. For data structures such as custom containers.

2. For zero-overhead polymorphism. E.g. when I write algorithms that must work exactly same way with floats and doubles, or with char and wchar_t strings. Or for zero-overhead lambdas, putting them in std::function causes virtual function call overhead, lambdas are usually inlined.

3. For zero-overhead constants. There’s constexpr in modern C++, also modern compilers are good at propagating constants, but still a template argument is more reliable.

When I need complex metaprogramming, I often use other tools to generate the C++ code I need. On Windows it’s usually T4 templates with C# inside them, on Linux usually python. Compared to C++ templates, both T4 and python have much better support in IDEs (visual studio / PyCharm), including debuggers.

⬐ aswanson

Templates make for the most abusively ugly code, at a glance. The syntax interpetaion to translate to natural problem-domain thought is so brutal.

⬐ pjmlp

Because it is the closest that C++ has to something like Lisp macros.

While it will never match the simplicity of Lisp, it is easier to get C++ accepted into most companies than Lisp.

And if one has access to a C++17 compiler, many tricks can now be replaced by more developer friendly constructs.

⬐ pcwalton

I'd argue that the C preprocessor is the closest thing C++ has to Lisp macros. Templates are fundamentally based on static types, which are obviously something Lisp doesn't have.

⬐ Yoric

Well, the C preprocessor is a pretty far cry from the kind of power of Lisp macros. If you want something as powerful as Lisp macros (ish), there isn't much else you can use in C++ land.

⬐ pjmlp

You can do quite a lot with if constepxr and TMO tricks, even stuff like generation of serialization code, even if isn't as clean as a Lisp implementation would be.

And who knows, maybe by C++23 some form of reflection will be finally available.

⬐ pjmlp

That misses the point of duck typing in C++ templates, which is one of their great features, and also the cause of those wonderful instantiation error messages.

In Lisp the same error would be a runtime one.

⬐ mhh__

> Other languages have much simpler and nicer constructs and seem to work just fine.

If you mean ML/Haskell, then I agree.

If you mean other languages filling the same void then I don't. Idiomatic C++ uses templates: They're objectively safer than what preceded them, for one.

⬐ alephr

metaprogramming is useful (for the same reason programming is, computers are great at transforming data. your program is data and it can be much faster to write it with this in mind) and templates are an existing, portable way to do metaprogramming. despite how bad they are designed, that they already exist and are portable puts them in a position where they can be the most cost effective way to do something

⬐ fsloth

Templates should be applied only when the problem obviously becomes simpler by employing them. You start from the non-template version and then you start to see a pattern emerging, and at some point you realize all that compmexity can be traded for another kind of complexity in the form of templates - and sometimes that trade is worth it.

⬐ ur-whale

> still don't understand why people bother with template metaprogramming

Speed.

⬐ blt

They do it because C++ tempts you to strive for perfect expressive syntax and perfect efficiency at the same time. Most languages have limited expressive power (C, Fortran, Pascal) or limited efficiency (Haskell, ML, any JVM or scripting language), so you accept their limitations and move on.

C++ makes programmers become Icarus. Once they escape from the prison of C syntax, they try to fly higher, towards the goal of code that looks like Python but runs like C. They learn that template metaprogramming can help acieve this goal, so they use it. But template metaprogramming is actually the sun, melting their code into a pile of wax and feathers, sending them crashing back down into the ocean to drown.

⬐ infinite8s

Or maybe they should just learn LISP, which gives you both.

⬐ pjmlp

I can say the same about Python for example.

Printing hello world might seem easy, now mastering Python....

⬐ dman

I am genuinely curious about the passion of anti C++ commenters - could you comment on your journey towards your current antipathy towards C++? Did you use it and get burnt? What did you use it for? What were the short comings? How long did you use it for? When did you use it (ie which C++ standard version)?

This is directed not just at the above commenter, but I invite replies from anyone who takes the effort to comment passionately against C++. Perhaps if we can understand some commonalities in peoples grievances, we could go back and address them.

⬐ userbinator

The complexity is just one part of the problem; the constant "fashion" churn --- largely community-driven --- is the other. It's really irritating to see so many changes in the language (and the horde of evangelists seemingly blindly pushing these changes and saying they're unconditionally better, which just smells like snake oil...) and the forcefulness that everyone should continually convert existing --- perfectly working --- code to whatever the current fashion is, when ideally the language should remain static, because I don't think a majority of its users have understood or can make use of most of the features of C++03 or even C++98 yet.

Having worked with C++ for over a decade, I much prefer C. C++ certainly has its useful features, but when I use C I find that I don't miss them much; and sometimes, especially when debugging, the "implicitness" of various things like automatic constructor/destructor calls are better made explicit.

As a rebuttal to the title of this video: "Hidden complexity is NOT simplicity."

⬐ 01100011

I think one of the issues with C++ is that there seems to be this clique of insanely smart people who are focused mainly on the language itself. They're experts in the complexity they've created and they have nothing to do but study that complexity and evangelize it. They're not really considering the audience of mediocre developers whose minds are mostly concerned with problems that need solutions and not language minutiae. A language and libraries are means to an end, not ends unto themselves. Us normies don't always have the luxury of keeping up to date with language changes - we're busy trying to get work done and ship products.

There are hidden costs to technology choices. I work with a smart guy(also a C++ zealot) who loves CMake and constantly evangelizes it. CMake seems great but the problem is that it's yet another language/system which people need to learn to be productive in our environment. GNU Make has its problems, but I can also scoop up a dev off the street and there's a 90% chance they've had experience with GNU Make and can immediately understand what's going on. Now I'm not saying CMake sucks, it's got a lot of great features, but by using it you gave up something without possibly even knowing that you did. Simplicity is a feature. Banality is a feature. Unless you're getting something good in return, don't sacrifice them.

⬐ blub

Normies don't have many choices for low-level development.

It's nigh impossible to write correct C and keep it thay way over the project's lifetime, C++ is too complex and so is Rust.

I think that's why Go is so attractive, it really is reasonably simple to wrap one's head around.

⬐ dataangel

In Rust the compiler tells you if you are doing it wrong. I see lots of complaints about this "complexity" but it's always identifying actual problems. It's also an order of magnitude less complex than C++.

⬐ tormeh

Yeah but that's because Rust is at the same low abstraction level as C++. So you have the same challenges in both, it's just that in Rust the gun refuses to fire when you point it at your foot.

⬐ scottlamb

> I am genuinely curious about the passion of anti C++ commenters - could you comment on your journey towards your current antipathy towards C++? Did you use it and get burnt? What did you use it for? What were the short comings? How long did you use it for? When did you use it (ie which C++ standard version)?

I don't usually write negative comments about C++ but I sure sympathize with them.

I write C++ at my day job (and have for years). My team's codebase is in its teenage years. It's code-reviewed and has decent test coverage, but in many cases the author doesn't know C++ as well as the reviewer, and the reviewer is rushed / trying to not be a huge bottleneck, so stuff slips through. New code gets written to mostly C++11 standards (soon, mostly C++17) and the newest company practices. Old code...still exists...and the new code still has to use it. We've modernized some pieces but not as much as we'd like. Company-wide people do a pretty good job of modernizing a lot of the libraries we use, but my team hasn't kept up as well for various reasons.

I hate memory errors. They're super hard to track down. I've spent significant time doing so. Thank god for ASAN and TSAN at least.

I also don't like crashes in general; my service has to be quite reliable (some operations are critical to big parts of the company and have a 99.9995% success within a certain deadline). And fast, so I can't just rewrite it in Java or Go.

A few examples of the sort of foot-guns C++ has:

* Data races: no equivalent of Rust's Send+Sync auto traits.

* string_view/reference/pointer outliving their backing memory: no lifetime annotations. Even the new proposal for them is very incomplete.

* std::optional and equivalents dereferenced incorrectly: no pattern-matching syntax, the decision for the most obvious way to deference (operator*) to be undefined behavior instead of a crash.

I wish the whole thing were written in Rust. Then the parts I have to pay super close attention to would all say "unsafe" in them. That covers memory safety (including data races). I'd also know to pay pretty close attention to "expect" and "unwrap", which cover most (not all) panics. Of course, more mundane logic errors can exist in any language, but freedom from those problems would be a huge relief.

⬐ berti

There is hope for these, e.g. lifetime in C++20. Herb Sutter's talk at this same conference is really good and covers both of your first examples.

⬐ Rusky

> Even the new proposal for them is very incomplete.

I agree with this assessment of the C++20 lifetimes stuff. It's great, it will probably catch a lot of bugs, but it doesn't catch the worst ones and that's where you need it the most.

⬐ Jabbles

In the >12 years your code has been around, Moore's law suggests that it would have got 2^8 = 256 times faster. Even though that law has slowed, there is significantly more processing power available now than when you started. Are you sure the requirements for your service being "fast" are as critical as you think?

⬐ pjc50

Only if the hardware is updated. I maintain an old MFC codebase that has to run on 15 year old 400MHz MIPS systems that don't belong to us.

⬐ pjmlp

You're keeping a Windows NT alive?!

⬐ pjc50

Windows CE (various extremely obsolete versions). The GUI side is quite convenient, since you can cross-develop from a normal desktop. The systems side is more of a problem, since the user community is almost non-existant.

⬐ pjmlp

Oh I completely forgot there was a MFC variant for CE, hence my NT remark.

⬐ scottlamb

In short, yes:

* CPU time per request: we do more work than we used to on average. For example, we do more asymmetric cryptographic operations now, and since introducing those operations we've increased the lengths of the keys. CPU time per request contributes not only to cost but to user-facing latency.

* overall request rate: we handle >256X as many requests as we did 12 years ago.

Those reasons are particular to my service, but I'd say the continued usage of C++ is convincing proof that plenty of people are willing to go to considerable effort to improve latency and efficiency. It'd be a lot easier to write things in a higher-level, GCed language otherwise.

⬐ jnbiche

> we do more asymmetric cryptographic operations now

Could you use session keys to take some of the load off, exchanged using asymmetric crypto, or are you already doing that?

Also, cool thing about Rust is that you can start writing parts of a C or C++ code base in Rust, and slowly switch over. This is exactly what Firefox is doing with their browser. Could you convince your company to let you try to rewrite a small part in Rust?

⬐ scottlamb

We've already picked the low-hanging fruit in terms of our protocol and implementation.

And no matter how much I'd love to, rewriting in Rust at work is not gonna happen any time soon. There's tons of support built up for the major languages in terms of build tools, IDEs, code cross-referencing, automated refactoring, style guides, libraries, etc. It's understandably a difficult process to get a language added to that list.

Besides, my team struggles to find time to just modernize our C++. I wouldn't want to start converting to another language until I find time/staffing to actually commit to carrying through. And I know from trying it at home that rewriting a project in Rust takes me longer than expected and bindgen's C++ compatibility is less than perfect.

So I get my Rust fix with personal projects instead (when I can find time).

⬐ blake_himself

clang modernize? It'll do the small-scale fixes for you. But, though this was a while ago, it messed up the text when I used it. You could tell what it was /supposed/ to be, though, and wouldn't compile. But it may be better, now.

⬐ snaky

This might be interesting then

> We introduce a new approach for implementing cryptographic arithmetic in short high-level code with machine-checked proofs of functional correctness. We further demonstrate that simple partial evaluation is sufficient to transform into the fastest-known C code, breaking the decades-old pattern that the only fast implementations are those whose instruction-level steps were written out by hand.

> These techniques were used to build an elliptic-curve library that achieves competitive performance for 80 prime fields and multiple CPU architectures, showing that implementation and proof effort scales with the number and complexity of conceptually different algorithms, not their use cases. As one outcome, we present the first verified high-performance implementation of P-256, the most widely used elliptic curve. Implementations from our library were included in BoringSSL to replace existing specialized code, for inclusion in several large deployments for Chrome, Android, and CloudFlare.

http://adam.chlipala.net/papers/FiatCryptoSP19/

⬐ dman

Thanks for taking the time to write such a thoughtful and informative reply.

⬐ stiglitz

I can choose C or C++ in my workplace.

I prefer primitive rather than clever (i.e. pompous) solutions to problems and therefore choose C.

I also do not want to spend a significant portion of my time in the hallway discussing language features, as I hear many C++-choosers doing outside my office most weeks.

From this perspective, I could only be made happy with C++ if features were removed from it. I admit that I’ve hardly given the language a chance, but that is partly because I know I’ll make solutions even more pompous than the ones I’ve seen. I don’t think humans can help it.

⬐ dman

Cannot edit my comment anymore, so am putting this here - wanted to thank everyone who took the time to reply. Signal to noise ratio in the comments was fairly high.

⬐ ndh2

Some more interesting comments here: https://www.reddit.com/r/cpp/comments/9jwdpf/journeys_toward...

⬐ Rusky

I don't think I tend to be a passionate anti C++ commenter, though I agree with the sentiment.

I've used C++ for around a decade, both professionally and as a hobby, in various domains. I use it because I either need (or merely want, in many cases) the control over the resulting end product that it provides.

The grievances are well known, and most are being addressed in some form, so asking random commenters isn't going to change anything.

But for what it's worth: it just feels like the language is a lost cause.

Everything is so irredeemably hard (without breaking back-compat)- from syntax/name resolution/template expansion, and the accompanying problems with error messages and tooling; to build systems and dependency management, and the impossible task of ever getting anything standard there; to memory+thread safety, where every solution is a partial bandaid and there's no light at the end of the tunnel.

It's a big, important, widely-used language. It's just not pleasant to work with- and while that can and will improve, it will always be tied to its rather painful legacy.

⬐ dnautics

I feel the same way about the the "lost cause" (though I never programmed C++ professionally, I did for science fair projects, and played around, a lot, with the BeOS API back in the day - enough to get RSI):

Even JavaScript which kind of felt like a lost cause to me about three years ago has redeemed itself - I was shown a "way to code JavaScript" which exclusively uses ECMA6, keeps very little if no state, and basically everything is a `const fn (...) => {}`. A breath of fresh air in its simplicity and safety. C++ doesn't seem to want to converge to this sort of thing, even as usable subset of the language.

I would say the best quality of C++ is that you can be reasonably certain of what the program is doing at the machine language level (though obviously C is better) but this is going to be overtaken by languages like rust, which have more sophisticated type system and unlike VM languages (which definitely have their place) leave safety considerations in the compiler.

⬐ codr4

Second most of that.

I used to be really passionate about C++ back in the days, but it's just too damn complex. Yes, some new features really help; if I could bring one to a desert island it would be lambdas. Tuning C++ these days is mostly trial and error for me, there are so many gotchas to keep in mind that it's more or less impossible to juggle it all mentally.

From my experience there comes a point where the required effort tips the scales towards more convenient languages for most projects. But by the time you realize you're usually up to your neck in template goo that no one wants to translate.

⬐ flohofwoe

Same here. Been writing C++ since around 1998, was somewhat excited about C++11 (which brought a few good things, like lambdas, and ... uhm...). Since then I have the impression that C++ and I are moving into different directions. Since last year I started writing C code again and enjoy it very much, surprisingly I haven't missed C++ at all since then. That's when I realized that all I want/need is a "slightly better C" (Go is pretty close but already too high level, in the sense that there's too much under-the-hood-magic happening).

⬐ xyzzyz

The biggest thing C++11 brought in my opinion is standardizing scoped_ptr. Now there is absolutely no excuse for typing "new" or "delete" in new code (except of some very limited circumstances).

⬐ merlincorey

> excited about C++11 (which brought a few good things, like lambdas, and ... uhm...)

The auto specifier[0] is frankly the most ergonomic and simple thing which I wish I could have in, say, C.

[0] https://en.cppreference.com/w/cpp/language/auto :: auto specifier (since C++11)

⬐ phao

Yep... The "slightly better C" seems pretty universal as far as I've seen. A lot of people just want that it seems. It's not clear what that would look like though. It's a shame.

Have you seen Terra? http://terralang.org/

⬐ vvanders

Yeah, +1 to all of that.

I spent maybe ~15 years writing C++ over hobby + career timespan. Was a huge proponent of the language but spent the last 2-3 years over in Java land while doing all my greenfield work in Rust.

Came back to another lower level project written in C++/0x14 lately and it's a bit of a shock how my things I 'forgot' even on a modern codebase. Things like implicit constructor conversions, the fact that the type inference is pretty weak still(why can't I just construct unique_ptr w/out the type when I pass it direct[1]). Headers and package management is a total mess.

At this point unless I've got a hard constraint(like QNX or other yet supported platforms) I'm going to reach for Rust just about every time.

[1] Yes I know make_unique() is a thing but it's a C++/0x17 and just patches one part of type inference issues.

⬐ berti

make_unique and friends are C++14 ;) https://en.cppreference.com/w/cpp/memory/unique_ptr/make_uni...

⬐ stackmad

More people should see this!

⬐ jjuhl

This is excellent. Well worth watching. Lots of great advice.