Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern C++ Won't Save Us (2019)

alexgaynor.net

Post reply on HN
Print view View original

131–140 of 266 posts

Re: Modern C++ Won't Save Us (2019)

#131

Post by jcelerier »

Iv wrote: post #108
Animats wrote: post #24

My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…

It took me a while to understand what C++ was: a quest for the highest level semantics possible with the lowest performance overhead. It is a quest started a long time ago with a lot of dead ends and circumvolutions. The quest is still valid but really, the complexity that C++ has given birth to is not worth it anymore. Other languages restarted from a blank state and are probably better bets. I almost switched to D…

> It took me a while to understand what C++ was: a quest for the highest level semantics possible with the lowest performance overhead.

I find it interesting that it took you a "while" even though Stroustrup was already defining like that before C++98: https://books.google.fr/books?id=hS9mDwAAQBAJ&pg=PT151&lpg=P...

Re: Modern C++ Won't Save Us (2019)

#132

Post by jillesvangurp »

ppg677 wrote: post #36

Yet C++ is what Google, Facebook, Microsoft and others still use for their most mission critical software.

Each of those is also using and promoting Rust now as an alternative. Security is a major driver for that as each of those has been dealing with security issues in their C++ code bases regularly. They won't stop using C++ overnight of course but they are vastly less likely to use it for new things and are actively replacing C++ components with Rust equivalents at this point as well. In Google, which developed Go for the same reason, Rust is also competing with that.

Re: Modern C++ Won't Save Us (2019)

#133

Post by viraptor »

HexDecOctBin wrote: post #34
Animats wrote: post #24

My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…

> three issues: "How big is it", "Who owns it", and "Who locks it" The issue with this kind of thinking is the belief that there is a "it", not "they". Say, you are writing a HTTP server [1]. A beginner mindset (what seems to be demonstrated in this post) with start allocating left and right, for every HTTP header, for every piece of string, for every piece of metadata record, etc. Thus, "how big is it" become no big…

Your comment reads like you disagreed in some way with the parent, but then you showed a scenario and defined it in a way you can answer the important questions. Just drop the "we don't care" part and they're all good answers that can be used to model the ownership and usage.

The lack of locks in this scenario is important in itself and can be expressed in types. (It shows for example that as long as the whole process is migrated to another thread, you can have safe N:M scheduling) The process ownership of the arena can be well defined as well.

The "alternative strategy" as you described it doesn't have different questions - just different answers.

Re: Modern C++ Won't Save Us (2019)

#134

Post by jb1991 »

Many of the comments here are focusing on Rust as the obvious alternative, but it's great that the article twice also mentions Swift and Rust together as the obvious choices. If Swift ever gets more adoption outside Apple's platforms, it will be a game-changer. It's a very elegant language with much stronger typing than C++. It feels like writing in a scripting language but retains the type and memory safety.

Re: Modern C++ Won't Save Us (2019)

#135

Post by jcelerier »

dgs_sgd wrote: post #100
jandrewrogers wrote: post #82

Earlier quoted context omitted.

I think it is fair to point out that it requires a comparatively high degree of skill and experience to use C++ well relative to many other languages. Most people do not use C++ well because doing so is quite difficult and requires a large investment of time. This is not helped by the fact that it has an enormous amount of legacy baggage that is technically valid code that no one should ever use — there is an entire…

As someone not very acquainted with C++ I was under the impression that the vast standard library was one of the great selling points of the language. What are some examples of defects that force programmers to rewrite parts of it?

depends where you come from. If you come from Python, Java, you'll find that there's a lack of support for networking, etc. and that it is not vast at all. After all we lack a W3CEndpointReferenceBuilder (https://docs.oracle.com/javase/10/docs/api/javax/xml/ws/wsad...).... not sure how it's possible to be productive without that.

If you come from C you'll think that there are allocations everywhere and judge it unfit for purpose (even if in my experience, C libraries and software tend to allocate much more than C++, and use worse datastructures like linked lists, etc. just because it's easier to code in C).

Finally the C++ committee and standard library implementers refuses to break ABI / API, which means that : * the C++ standard is not able to follow the state-of-the-art for e.g. hash maps, as the fastest hash maps (if you only care about speed of insertion / retrieval, which is let's be honest 99.5% of the use cases out there) because unordered_map has strict requirements that these newer hash maps do not satisfy. * things like regex stay broken

Re: Modern C++ Won't Save Us (2019)

#136

Post by volta83 »

lmm wrote: post #31
AnimalMuppet wrote: post #8

> There are significant challenges to migrating existing, large, C and C++ codebases to a different language – no one can deny this. Nonetheless, the question simply must be how we can accomplish it, rather than if we should try. Um... no. Not every (or even most ) existing large C/C++ codebase should be migrated to another language. "But security vulnerabilities! And crashes!" I admit all that. But a program can be…

This amounts to saying that we should accept codebases continuing to contain exploitable vulnerabilities indefinitely. Perhaps for codebases that have a finite expiry date that's tolerable, but for a codebase that's expected to be maintained indefinitely I don't see how it can possibly be worthwhile - a rewrite will be a one-time cost, whereas exploitation is an ongoing cost that will surely exceed the one-time cost…

> This amounts to saying that we should accept codebases continuing to contain exploitable vulnerabilities indefinitely.

Right, why shouldn't we?

I have a CLI application for storing TODOs. It never accesses the network, I don't really care if it crashes, it does not have an expiry daye.

I have a constant amount of time to work on it. To me it is more value to put that time into new features that save me a couple of seconds here and there as a daily user, than to put all the time allocated for months or a year of working on the app to re-write it in a different language to remove the occasional monthly crash I don't care about.

For me, the decision is a no brainer: my time is better spent in the stuff that adds more value, and "avoiding exploitable vulnerabilities" is not it.

I suppose that this is the situation for many apps.

You are claiming that this is wrong. Prove your claim.

Re: Modern C++ Won't Save Us (2019)

#137

Post by jcelerier »

pornel wrote: post #2

UB-invoking dereference in std::optional is such a baffling design choice. The whole point of an optional type is to prevent accidental unchecked access to the value. Sure, sometimes it's useful for performance to skip the check when it's already known-safe from the context, but such dangerous optimization should have been behind a method like `beware_of_the_nasal_demons()`, not an innocent-looking convenience syntax…

> The whole point of an optional type is to prevent accidental unchecked access to the value

no ? it is to model the idea of "a value is there or is not there". definitely nothing more. If replacing a T* t by a optional& incurs a meaningful performance cost (like a branch) then optional just won't be used

Re: Modern C++ Won't Save Us (2019)

#138

Post by pjmlp »

jandrewrogers wrote: post #120
pjmlp wrote: post #116

Earlier quoted context omitted.

That is the agenda usually pushed by anti-GC crowd, others think differently. https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.astrobe.com/ https://dlang.org/ https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm http://joeduffyblog.com/2015/11/03/blogging-about-midori/

It isn’t an “anti-GC crowd”, it is based in pretty solid theoretical computer science with large amounts of empirical evidence behind it. GC-based environments are incompatible with schedule-based safety, optimization, etc which are major optimizations and design elements in modern systems. No one has ever demonstrated a systems architecture that can outperform a state-of-the-art schedule-optimized design. This resul…

And I make money replacing C++ systems with ones written in AOT/JIT managed languages, with different kinds of automatic memory management.

The last time I did full stack C++ development was in 2006, nowadays its use is constrained to a couple of unavoidable native libraries, or GPGPU shaders.

Not everything can be proved in practice when management prefers to give money to the ones that sabotage projects like Windows Dev team has done to Longhorn and Midori efforts.

Are you aware that for quite some time any of your Bing searches using Asian servers were powered by Midori?

Thankfully this is a problem that eventually will get fixed by generational evolution, pity I won't be around to fully witness it.

Re: Modern C++ Won't Save Us (2019)

#139

Post by echelon »

127 wrote: post #129

Here's the point of view from someone who has only written 1 piece of production software with both C++ and Rust. Trying to write C++ I was constantly fighting accidental memory copies. With Rust all of this was trivial and everything works as I expect. This is pretty much the reason I chose Rust over C++. As a beginner I have no idea how I would begin to elegantly write immutable data, parallel code. With Rust it's…

C++ is a garbage language. There's literally nothing worse. Not PHP, not Perl, not Bash nor VBScript.

C++ is literally the worst language.

You have to be an arcane wizard to write safe C++. Your code reviewers have to be all-seeing oracles. You're asked to follow this pattern called RAII, but the language does nothing to tell you this or enforce it.

Creating declarations and header files is so ceremonious and tiring that it's a pain to prototype. By the time your ideas are concrete, you've already introduced bugs.

Anyone who says they can program C++ safely is either a robot or is lying.

Mozilla's single most important contribution is Rust. It's a literal godsend for systems programming. The ecosystem is maturing more and more every year, and it's now just about time we put C++ out to pasture. There's no saving it.

Re: Modern C++ Won't Save Us (2019)

#140

Post by eptcyka »

Animats wrote: post #24

My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…

I don't see `unsafe` being used as an escape hatch IMO.
Post reply on HN