Modern C++ Won't Save Us • Hacker News Board

Re: Modern C++ Won't Save Us

#161

Post by pjmlp » Tue, Apr 23, 2019, 6:13 AM UTC

ncmncm wrote: post #133

magila wrote: post #53

Earlier quoted context omitted.

While there are obviously still cases where C++ makes sense to use today, those case are overwhelmingly based on the age and maturity of the C++ ecosystem. Now that Rust has proven that a language can provide memory safety without compromising (much) on performance, it is clear that the scope of C++'s supremacy is in permanent decline. As Rust (or another language with similar safety/performance properties) matures a…

If C++ is the new Fortran, Rust might very well be the new Ada. Many of the same relative merits were claimed for Ada as for Rust, and it had the backing of the biggest and best-funded organization in the world, but it faded from view because it did not keep up. Rust could easily go the same way.

Given the market size for Fortran and Ada, that doesn't bound well for Rust.

Re: Modern C++ Won't Save Us

#162

Post by masklinn » Tue, Apr 23, 2019, 6:14 AM UTC

arcticbull wrote: post #78

ajross wrote: post #64

Earlier quoted context omitted.

> It’s definitely easier to reason about than C++ See... I don't think that's true, and argue the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary. I mean, sure, C++ has its crazy edge cases and its odd notions. But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code. Literally hundreds of tho…

I'm not really arguing about the value of that code either, just that it's probably wrong, probably trivially breakable due to the sheer mountain of complexity underlying it. The compiler just happened to let it through because it can't help you. The language doesn't give it enough information to do so effectively. Just off the top of my head, std::move doesn't... move [1]. It just returns an, I kid you not "static_c…

> Just off the top of my head, std::move doesn't... move [1].

I mean that makes sense in a (somewhat nonsensical) way, std::move is a marker for "you can move this thing if you want".

The much weirder part is that even if a value is moved it's not moved, it's carved out, you get to keep a shell value in a "valid but unspecified state". Reusing that value (which the compiler won't prevent) may or may not be UB depending on the exact nature of the operation and state.

Oh and of course that a change / override to the caller and recompile can change the behaviour of the callsite entirely (e.g. a previously moved value is not moved anymore, or the other way around) but that's pretty common for C++.

Re: Modern C++ Won't Save Us

#163

Post by rootlocus » Tue, Apr 23, 2019, 6:15 AM UTC

ncmncm wrote: post #125

nradov wrote: post #108

Earlier quoted context omitted.

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

The whole point of C++ is that it enables writing more powerful libraries, capturing semantics in libraries that can then just be used. C++ is still quite a lot more powerful for this purpose than Rust. Rust will get better at it, over time, but it has a long way to go and C++ is not siiting still. Rust is still a niche language, and if its rates of adoption and improvement do not keep up, it will remain a niche lang…

Is this the "no serious programmer" fallacy?

Re: Modern C++ Won't Save Us

#164

Post by ajxs » Tue, Apr 23, 2019, 6:18 AM UTC

pjmlp wrote: post #158

ajxs wrote: post #154

Earlier quoted context omitted.

The Ada partisans are all out in force here in this thread to defend Ada, all four of us. haha... For what it's worth, niche as Ada may be, it's an _important_ niche. It remains widespread in safety-critical applications, and isn't going anywhere anytime soon. It's really good to see Rust taking lessons from Ada/SPARK in the area of formal proofing! If any language is going to threaten C++, it looks like Rust. I don'…

A large majority of Ada partisans found their corner in Java, C# and C++'s type system improvements over C, and made the best we could from the sour grapes of C's copy-paste compatibility.

Calling myself an Ada partisan is a bit of a stretch. I've recently begun using it for embedded development, which is a domain almost completely dominated by C. That's the angle I'm coming in from.

Re: Modern C++ Won't Save Us

#165

Post by pjmlp » Tue, Apr 23, 2019, 6:19 AM UTC

steveklabnik wrote: post #43

jasonhansel wrote: post #36

Can someone at least make a linter that ensures you only use a "safe" subset of C++?

The Core Guidelines are an attempt at this, but it’s not fully safe. Safer, which matters! But not safe. There isn’t really any useful safe subset of C++. If there were, Rust may never have been created in the first place.

Still, C++ is good enough for the unsafe low level bindings of a Java/.NET application.

Until Rust's tooling catches up with C++/CLI, C++/CX, C++/WinRT + .NET or Java + C++ (Eclipse/Netbeans/Oracle Studio), CUDA, Unreal/Unity, GLSL/HLSL/Metal Shaders allow for, it will stay as a safe way to write CLI apps and a couple of UNIX libs.

I like the language and advocate it often, but I am also very pragmatic regarding the areas I and customers work on.

Re: Modern C++ Won't Save Us

#166

Post by DoingIsLearning » Tue, Apr 23, 2019, 6:20 AM UTC

ajxs wrote: post #76

0xDEEPFAC wrote: post #6

What do you need saving from - Ada has existed for nearly 30 years now ; )

I came here to the comments to post this exact thing, haha. I'm very late to the Ada party, and I'm amazed at how ahead of its time this language was. It's still very usable and modern by today's standards.

> by today's standards

You make it sound like Ada stopped in the 80's.

They don't release standards in rapid succession but 'Ada 2012' has pretty much all of the features that people were asking for in C++ since 2011.

The only issue (on top of the obvious lack of coolness and hype around it) is that professional grade Ada compilers/toolchain are still quite a high cost for single developers or small companies. AdaCore's business model is still pretty much focused on support contracts to big Aerospace/ATC/Defense clients.

Re: Modern C++ Won't Save Us

#167

Post by blub » Tue, Apr 23, 2019, 6:21 AM UTC

mannykannot wrote: post #20

jclay wrote: post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

I do not think it helps to think in emotional terms such as 'hate'. There is nothing wrong with discussing potential problems, and the current utility of the language should not stop us asking whether we could do better in future. FWIW, I use C++, not Rust or Swift, and I have a fair amount of knowledge and experience vested in it, but I think these questions are worth asking.

The questions are worth asking. But the Rust crowd is not asking questions, they're dictating solutions, or rather that one old solution of rewriting everything to Rust.

Meanwhile the Firefox rewrite, the premium example of what they propose is still plodding along and Mozilla PR blogs aside, Firefox is still plugging vulnerabilities in each release and will be for the foreseeable future.

Now let's look at the Swift community... do we have blog posts from them every week about how awesome Swift is and why one should rewrite their working C and C++ code in Swift? No, they keep doing their thing, Swift is becoming better at cross platform, it's also getting some support for machine learning.

That's how one grows a language, through building successful projects, staying positive (and having an entire platform behind it). Not through doomsday scenarios and a constant barrage of criticism.

Re: Modern C++ Won't Save Us

#168

Post by petters » Tue, Apr 23, 2019, 6:22 AM UTC

dearrifling wrote: post #156

petters wrote: post #145

Earlier quoted context omitted.

Initializing the mersenne twister is really hard: https://github.com/PetterS/monolith/blob/master/minimum/core... Edit: There are two links in the code with more info.

One shouldn't std::move in a return. Returning a local is already automatically an rvalue, however explicitly moving it disables copy elision.

You are completely right. That should be fixed

Re: Modern C++ Won't Save Us

#169

Post by pjmlp » Tue, Apr 23, 2019, 6:22 AM UTC

insulanian wrote: post #152

sayusasugi wrote: post #99

Any HN post mentioning C++ will inevitably be invaded by the Rust Evangelism Strikeforce.

And rightly so! What's wrong with spreading awareness about safer alternative? If that wasn't the case in the past, we'd still be programming in Cobol and Fortran.

On the contrary, we had plenty of safer alternatives for systems programming, derived from Algol and PL/I.

Then came an OS, with a symbolic price instead of the typical market prices of competing OSes, alongside source code tapes, and a systems programming language that was the "JavaScript" of system languages.

Re: Modern C++ Won't Save Us

#170

Post by dodobirdlord » Tue, Apr 23, 2019, 6:23 AM UTC

paulmooreparks wrote: post #134

Tracist wrote: post #116

Earlier quoted context omitted.

> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. The whole comment sounds so much like well written satire, but I think he's being serious.

Why is it difficult to believe? I've also written plenty of C++ code without memory bugs. It's not that hard if you play by a few simple rules.

> I've also written plenty of C++ code without memory bugs.

The classic response to this is "That you know of." Consider that even quality-conscious projects with careful code review like Chrome have issues like this use-after-free bug from time to time.

https://googleprojectzero.blogspot.com/2019/04/virtually-unl...

So when people claim that they personally don't write memory bugs I tend to assume that they are mistaken, and that the real truth is that they haven't yet noticed any of the memory bugs that they have written because they are too subtle or too rare to have noticed.