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

In Defense of C++

dayvster.com

Post reply on HN
Print view View original

141–150 of 470 posts

Re: In Defense of C++

#141

Post by viraptor »

Night_Thastus wrote: post #75
zahlman wrote: post #39

Earlier quoted context omitted.

> I never want to see another Wheel error until the day I die. What exactly do you mean by a "Wheel error"? Show me a reproducer and a proper error message and I'll be happy to help to the best of my ability. By and large, the reason pip fails to install a package is because doing so requires building non-Python code locally, following instructions included in the package. Only in rare cases are there problems due to…

Unfortunately that Wheel situation was far enough back now that I don't have details on hand. I just know it was awful at the time. As for significant whitespace, the problem is that I'm often dealing with files with several thousand lines of code and heavily nested functions. It's very easy to lose track of scope in that situation. Am I in the inner loop, or this outer loop? Scrolling up and down, up and down to fig…

> Am I in the inner loop, or this outer loop? Scrolling up and down, up and down to figure out where I am.

Find an IDE or extension which provides the nesting context on top of the editor. I think vs code has it built in these days.

Re: In Defense of C++

#142

Post by wojciii »

vlovich123 wrote: post #132
worik wrote: post #116

Earlier quoted context omitted.

None of that is a problem There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle. Then repeated foot guns going off, no toes left, company bankrupt and banking system crashed, again

> There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle. I've observed the existence in larger projects of "build engineers" whose sole job is to keep the project building on a regular cadence. These jobs predominantly seem to exist in C++ land.

How is that even possible?

Wasn't CI invented to solve just this problem?

Re: In Defense of C++

#143

Post by doctorshady »

The one thing I'll say here is age of the language really is and always has been a superficial argument; it's only six years apart from Python, and it's far less controversial of a language choice: https://en.wikipedia.org/wiki/History_of_Python .

Either way, it's hard not to draw parallels between all the drama in US politics and the arguments about language choice sometimes; it feels like both sides lack respect for the other, and it makes things unnecessarily tense.

Re: In Defense of C++

#144

Post by jimbob45 »

pclmulqdq wrote: post #129
duped wrote: post #103

Earlier quoted context omitted.

Every modern language seems to have an answer to this problem that C and C++ refuse to touch because it's out of scope for their respective committees and standards orgs

C++ has a plethora of available build and package management systems. They just aren't bundled with the compiler. IMO that is a good thing, because it keeps the compiler writers honest.

You say that as if Cargo, MSBuild, and pip aren’t massively loved by their communities.

Re: In Defense of C++

#145

Post by vlovich123 »

wojciii wrote: post #142
vlovich123 wrote: post #132

Earlier quoted context omitted.

> There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle. I've observed the existence in larger projects of "build engineers" whose sole job is to keep the project building on a regular cadence. These jobs predominantly seem to exist in C++ land.

How is that even possible? Wasn't CI invented to solve just this problem?

You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system where everyone does the bare minimum to meet the near term task only and it devolves into a mess no one wants to touch over enough time.

Your choice: do you have the most senior engineers spend time sporadically maintaining the build system, perhaps declaring fires to try to pay off tech debt, or hire someone full time, perhaps cheaper and with better expertise, dedicated to the task instead?

CI is an orthogonal problem but that too requires maintenance - do you maintain it ad-hoc or make it the official responsibility for someone to keep maintained and flexible for the team’s needs?

I think you think I’m saying the task is keeping the build green whereas I’m saying someone has to keep the system that’s keeping the build green going and functional.

Re: In Defense of C++

#146

Post by jandrewrogers »

MBCook wrote: post #104
IshKebab wrote: post #20

Terrible article. > you can write perfectly fine code without ever needing to worry about the more complex features of the language Not really because of undefined behaviour. You must be aware of and vigilant about the complexities of C++ because the compiler will not tell you when you get it wrong. I would argue that Rust is at least in the same complexity league as C++. But it doesn't matter because you don't need…

> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues. Even if we take this claim at face value, isn’t that great ? Memory safety is a HUGE source of bugs and security issues. So the author is hand-waving away a really really good reason to use Rust (or other memory safe by default language). Overall I agree this seems a lot like “I li…

I think this is a case of two distinct populations being inappropriately averaged.

There are many high-level C++ applications that would probably be best implemented in a modern GC language. We could skip the systems language discussion entirely because it is weird that we are using one.

There are also low-level applications like high-performance database kernels where the memory management models are so different that conventional memory safety assumptions don’t apply. Also, their performance is incredibly tightly coupled to the precision of their safety models. It is no accident that these have proven to be memory safe in practice; they would not be usable if they weren’t. A lot of new C++ usage is in these areas.

Rust to me slots in as a way to materially improve performance for applications that might otherwise be well-served by Java.

Re: In Defense of C++

#147

Post by nothrabannosir »

duped wrote: post #103
bluGill wrote: post #100

Earlier quoted context omitted.

that idea that packages and builds belongs to simple problem, large projects need things like more than one laguage and so end up fighting the language

Every modern language seems to have an answer to this problem that C and C++ refuse to touch because it's out of scope for their respective committees and standards orgs

On the front page right now:

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised (stepsecurity.io)

935 points by jamesberthoty 16 hours ago | flag | hide | 730 comments

Maybe obstreperous dependency management ends up being the winning play in 2025 :)

Re: In Defense of C++

#148

Post by pclmulqdq »

jimbob45 wrote: post #144
pclmulqdq wrote: post #129

Earlier quoted context omitted.

C++ has a plethora of available build and package management systems. They just aren't bundled with the compiler. IMO that is a good thing, because it keeps the compiler writers honest.

You say that as if Cargo, MSBuild, and pip aren’t massively loved by their communities.

"Massively loved" and "good decision" are orthogonal axes. See the current npm drama. People love wantonly importing dependencies the way they love drinking. Both feel great but neither is good for you.

Re: In Defense of C++

#149

Post by jjaksic »

summerlight wrote: post #96

> in C++, you can write perfectly fine code without ever needing to worry about the more complex features of the language. You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language. Only if you have full control on what others are writing. In reality, you're going to read a lot, lots of "clever"…

Being able to cut 90% of code sounds like someone was getting paid by LoC (which is also a practice from a time when C++ was considered a "modern" language).

Re: In Defense of C++

#150

Post by jandrewrogers »

vlovich123 wrote: post #132
worik wrote: post #116

Earlier quoted context omitted.

None of that is a problem There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle. Then repeated foot guns going off, no toes left, company bankrupt and banking system crashed, again

> There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle. I've observed the existence in larger projects of "build engineers" whose sole job is to keep the project building on a regular cadence. These jobs predominantly seem to exist in C++ land.

I’ve only ever seen this on extraordinarily complex codebases that mixed several languages. Pure C++ scales really well these days.
Post reply on HN