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

111–120 of 266 posts

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

#111

Post by saagarjha »

v8dev123 wrote: post #71
andyxor wrote: post #14

C++ is a beautiful, pragmatic and very efficient language, just constrain your use of it to STL, and avoid Boost and other over-engineered dependencies. The Ockham's razor principle of code design is not only important but essential when using large mature languages that have many surprising and nuanced ways to skin a cat. Being too clever with C++ is a recipe for disaster. Avoid OOP (inheritance in particular) and t…

OOP and Boost also Templates has benefits when it comes to increasing barrier of static reverse engineering. For example, Security researcher "Marcus Hutchins" famously echoed that Boost is a cluster fuck of OOP sadness [0] Similarly, a close friend of mine "Omer Yair" mentioned [1], "A well written OOP malware might be harder to RE statically than a poorly written C code. Writing OOP malware badly though just makes…

I mean they do but not by as much as to actually matter.

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

#112

Post by pjmlp »

mamcx wrote: post #47
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 mindset is the Cobol mindset. Sound reasonable today. Is crazy to keep it for long. And the billons of dollars wasted on "fix" C/C++ with discipline have proven is the wrong.

Lets take a second to remember C is only about 10 years younger as Cobol.

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

#113

Post by throwaway17_17 »

tejohnso wrote: post #59
HexDecOctBin wrote: post #34

Earlier quoted context omitted.

> 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…

Wow, Casey doesn't hold back. Clearly, without hesitating says that 100% of code written in RAII* style sucks. Interesting considering Stroustrup considers RAII to be "the basis of some of the most effective modern C++ design techniques." I'd like to hear Casey's comments on TDD. *RAII style is lumped together with try/catch, smart pointers, tons of malloc/free new/delete

Does TDD here mean ‘Type Driven Development’ a la Idris or, as I assume (and seems more likely) does it mean Test Driven Development?

If you mean test driven, I don’t think I have heard Casie discuss anything remotely close to the standard presentation of TDD strategies. I would imagine, based on watching a large amount of Casie streaming, both alone and with Blow, that he would view testing (as in TDD) as unproductive for his particular style of development and his goals as a programmer. But, since it’s in my brain now I will ask him next time I catch a live stream just to satisfy my curiosity.

I can’t speak to any discussions specifically about TypeDD. But would bet Casie would be wholly uninterested and consider it theoretical academic fluff that pulls away from the fundamental data transformation work of development.

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

#114

Post by adev_ »

dbrueck wrote: post #57
FpUser wrote: post #41

Those C++ bad, complex, unsafe etc. etc articles are starting to get boring. If one wants to shoot him/herself in a foot it is fine. C++ offers countless possibilities. It (and plethora of libraries) also offers quick way to write sophisticated and performant applications without much fuss. Make your choice. I personally use C++ to great advantage and find it very productive and safe. And while being good programmer…

In a way, I agree. To me, C++ is an absolute train wreck of a language and choosing it for a new project borders on malpractice. But if people want to use it and it doesn't affect me, there's a limit to how much energy I'm willing to spend trying to talk them out of it... especially if they are a potential competitor, in which case I might nod encouragingly when I hear they're using it.

> To me, C++ is an absolute train wreck of a language and choosing it for a new project borders on malpractice.

Personnally I tend to think exactly the opposite. And choosing a brand new hype language because "it's shiny and fun" on new projects that will have to be there for 20 years is just a sign of being immature and a malpractice.

There is no guarantee your shiny language will be alive nor even supported on my next gen platform. When for sure, the good old safe set: C++, C, JS, python, Java will be there and alive, even in 20 years from now.

And the result you will probably struggle and spend more time to get your nice shinny Rust code running correctly on iPhone/Android 20/NG-Cloud than you will ever to debug a damn core file in C++.

To comment ironically on your post. It is more to "zealots" and "evangelist" like you that I personnally refuse to talk. These people are often more interested with playing with the last fancy tech available than producing anything useful and sustainable in their work.

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

#115

Post by pjmlp »

ppg677 wrote: post #36

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

I moved away from full C++ development in 2006, yet C++ still is the tool I reach for in native code, because many libraries are only available in C++ or C, and I definitly will not be writing C unless obliged to do so.

Microsoft had a project to move Windows mostly into .NET, sabotaged by their Windows team, which a decade later rebooted the ideas using COM instead, an idea that has been a commercial failure, while everyone just keeps migrating to .NET.

Microsoft Security team pushed a best practices paper that new projects should use:

1. .NET

2. Rust

3. C++ with Core Guidelines, with Visual C++ analysers turned on

4. They also have a security annotations for C and C++ code (SAF)

Google castrates the use of C++ to app developers in Android to writing native libraries to be consumed by Java and Kotlin, is behind the effort to adopt hardware memory tagging alongside ARM, the reason why Linux kernel no longer uses VLAs and the big pusher for Rust on the Linux kernel.

So it is not just simply "they use C++".

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

#116

Post by pjmlp »

jandrewrogers wrote: post #98
01100011 wrote: post #91

Earlier quoted context omitted.

When you're writing systems software you need systems software engineers and most of them are far more competent in C/C++ than, say, Rust, Ada, Go, etc. We choose C/C++ because it's what we know and what our colleagues know, but I think a lot of us wish there was a better alternative.

Not to take away anything from your post, but Go is not a systems language. No language with a mandatory garbage collector can make that claim since it makes some systems code effectively impossible to implement.

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/

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

#117

Post by pjmlp »

01100011 wrote: post #109
jandrewrogers wrote: post #98

Earlier quoted context omitted.

Not to take away anything from your post, but Go is not a systems language. No language with a mandatory garbage collector can make that claim since it makes some systems code effectively impossible to implement.

I agree, but some people don't. When I interviewed at Google a couple years ago, they were rewriting the Fuchsia network stack in Rust. It was currently written in Go. My jaw about hit the floor when I heard that. I'm guessing they realized it was a mistake, but then again maybe the Go version was just a temporary placeholder. IDK, didn't get the job.

Better hold your jaw with both hands while reading this,

https://www.f-secure.com/en/consulting/foundry/usb-armory

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

#118

Post by throwaway17_17 »

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…

That is an interesting take, I don’t really disagree (regarding the high-level semantics/lowest overhead). I do question the use of ‘highest’ as the qualifier for the semantic level, but certainly would support a claim that the goal was some indeterminate high with regards to the semantic level. Even at the inception of C++ as something different than C with classes, there were at least a few languages with a higher semantic level than where C++ is today. Although I do not think there was any then current strategy for making those languages as low overhead as C in practice. So as time has progressed and the cruft and complexity have built up I think they have now decided to find the highest level they can reach, while maintaining backwards compatibility and the low overhead requirements.

I am inclined to agree that a green field language is probably a better bet for achieving the goal, but I am not sold on any of the current contenders. So I still plod along doing my performance sensitive development in stripped down C++ and plug away at my pet language project.

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

#119

Post by pjmlp »

jvanderbot wrote: post #20

Is there a safe subset of C++ defined somewhere? Can I turn off some of these ridiculous "features"? As we add so much to the language, the number of footguns increases quadratically.

Yes, C++ the good parts is known as C++ Core Guidlines,

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

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

#120

Post by jandrewrogers »

pjmlp wrote: post #116
jandrewrogers wrote: post #98

Earlier quoted context omitted.

Not to take away anything from your post, but Go is not a systems language. No language with a mandatory garbage collector can make that claim since it makes some systems code effectively impossible to implement.

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 result is expected in theory. There are several optimality theorems, treated as a soft limit, that only hold true if you don’t control the schedule. The requirements of GCs guarantee you don’t control the schedule. State-of-the-art system designs, in non-GC environments, aren’t limited by those theorems and frankly run circles around GC-based systems. I work with a lot of companies that run nothing but managed languages and even they don’t believe that produces an optimal system, just an adequate one for non-intensive use cases. And that is a legitimate position.

You clearly are deeply invested in the superiority of GCs for all use cases. That’s fine. I make a lot of money replacing them with empirically much higher performance systems. There isn’t a lot of computer science to support the pro-GC position if performance is the objective. And to be clear, the loss of performance is integer factor, not something that can be trivially dismissed.

Post reply on HN