Hacker News Reader

Comment by usrnm | Hacker News Reader

I don't know. I switched to go a year ago after 10+ years of C++ and, if anything, I realized that C++ was not so bad. Not bad at all. It's old and overly complicated, but it's also very powerful and even beautiful at times. Go is just bad, the runtime is great, but it's attached to a slightly upgraded version of C. It's not even much safer, I've seen more leaks in this year than probably 5 years of C++ before that.

I know, the post is about C++ and Rust, but I'm tired of this "C++ is abandonware, just switch to a modern language" narrative.

View on HN

'"C++ is abandonware, just switch to a modern language" narrative.'

I think this narrative is still valid. For the love of god, if you don't need to use C++ for a greenfield project, don't. I say this as a person who needs to write C++ daily.

Otoh, if you do need to use C++, it's likely there are no good alternatives, so unless you are Microsoft, Google or Facebook ready to invest few billions to a new language ecosystem, the most pragmatic approach is to, indeed, just use C++.

As a C++ dev, I definitely disagree. C++ has a lot of advantages, like an enormous pile of easily-usable existing C and C++ code that you can hook in easily into any project.

Chances are if there's a problem to be solved, someone has solved it in C or C++ and the code is out there already.

It also has a lot of great support in terms of toolchains. Almost everything everywhere supports it out of the box, and you have your pick of any tools you want.

It also works on fairly simple principles, so anyone with experience in programming can work in it without learning a completely new way of thinking. [Even if their code won't be amazing at first]

I must apologize if the below sounds acerbic. I've used C++ professionally close to two decades and developed a keen feeling of everything that is bad in it. (Still need to use it though).

In general I agree with Mark Russinovich. Use a garbage colleted language, and if you really want a non-gc language choose Rust (which I really should learn).

https://twitter.com/markrussinovich/status/15719951172335042...

There are cases when one should choose C++, but those are the exceptions. Graphics, computational geometry and so on are strong reasons to use C++ still. But not everyone needs that stuff.

For moving strings and numbers around in a stereotypical business domain there are much better languages. C#. Python. Etc.

"an enormous pile of easily-usable existing C and C++ code that you can hook in easily into any project."

A lot of it is to help with the fact that the standard library in C++ is anemic.

This is one of the reasons though why one would want to use C++. Some libraries exist only in C++, and yes, it's a good reason to use the language.

"It also has a lot of great support in terms of toolchains."

CMake? VCPKG? Conan? MSBuild? Meson? Scons? Bazel? Make? Xcode? The-android-thingy? How do you mix and match those?

All of those are bloody horrible. And their combinations to the second power so. The only good thing in modern times is that most open source projects have picked up CMake with a fairly standard way of project configuration, which enables actually to reuse other's people code with surprising ease.

The toolchains make a horrible language a doubly terrible.

"It also works on fairly simple principles, so anyone with experience in programming can work in it without learning a completely new way of thinking. [Even if their code won't be amazing at first]"

Calling C++ simple is a new one to me. It's an industrial language that is not a total failure. Yes, people can write programs with it. The problem is there are much safer and better languages to write general programs, thus selecting C++ is giving yourself an intentional handicap in term of value created.

As an example of the complexity choosing C++ over something like C# gives you -

To what extent is a C++ codebase cross compilable and runnable in say MacOS after you develop it in Visual Studio on Windows? That's right, you can't tell, the only way to verify your standard C++ has the same runtime behaviour is to run it on the said platform. And fix all the bugs. So to actually write cross platform code, you need to have some proficiency in all of the platforms to have any level of guarantee that the code actually works in it's intended runtime.

Thus, a C++ codebase needs to come with a warning label telling every OS and processor it has been tested in. Most popular libraries are tested and run in all of the relevant platforms so this is not an issue for users. But I'm pretty sure the number of platform specific fixes per codebase is not trivial to make something work even remotely similarly.

>Make? VCPKG? Conan? MSBuild? Meson? Scons? Bazel? Make? Xcode? The-android-thingy? How do you mix and match those?

Almost everything I've seen is in Cmake, or can be easily interacted with it.

But in general, just pick something you like and stick with it. Sure, they're not perfect, but this list is actually a point I was making - you have a huge array of mature solutions out there already.

>Calling C++ simple is a new one to me. It's an industrial language that is not a total failure. Yes, people can write programs with it. The problem is there are much safer and better languages to write general programs, thus selecting C++ is giving yourself an intentional handicap in term of value created.

C++ is a simple language with complex things you can choose to use. If you understand the basic principles of loops, variables, functions, arrays, etc, you can write in C++ right away. You can layer on greater complexity with libraries and the STL, better patterns etc as you go, but you can start simple. That's a great benefit to someone learning, IMO.

C++ is as complex as you make it. I prefer to write fairly simple C++ personally and only break out the harder parts when absolutely needed. For example, I really don't like lambdas, so I just don't use them. And I can still solve anything I need to without them.

> Almost everything I've seen is in Cmake, or can be easily interacted with it. But in general, just pick something you like and stick with it. Sure, they're not perfect, but this list is actually a point I was making - you have a huge array of mature solutions out there already.

Installing library is

cargo add X npm install X implementation(“X”)

Show me how to import library in CMake. And then also show me how to import library that doesn’t have CMakeLists.txt file.

> C++ is a simple language with complex things you can choose to use. If you understand the basic principles of loops, variables, functions, arrays, etc, you can write in C++ right away. You can layer on greater complexity with libraries and the STL, better patterns etc as you go, but you can start simple. That's a great benefit to someone learning, IMO. C++ is as complex as you make it. I prefer to write fairly simple C++ personally and only break out the harder parts when absolutely needed. For example, I really don't like lambdas, so I just don't use them. And I can still solve anything I need to without them.

Good luck explaining to team that they can only use subset of C++. Also good luck when advanced C++ dev advocates for feature X and now whole org has to learn about X and its drawbacks. Or when the dev leaves and rest of team doesn’t know how the hell it works.

Sounds to me like you’re writing all of this from hobby or hobby OSS project perspective. Which is completely fine, but doesn’t apply to orgs.

I'm writing this from the experiencing of maintaining large legacy C++ projects as well as developing new ones. I only do this for work, not as a hobby, nor anything OS.

>Show me how to import library in CMake. And then also show me how to import library that doesn’t have CMakeLists.txt file.

I'm not sure how this is a gotcha. I'm not that familiar with Cargo, but I think the equivalent would just be something like:

TARGET_LINK_LIBRARIES(myProgramName Eigen3::Eigen)

in cmake. Not very hard.

Also...why does it matter if there's a cmakelists.txt file? How is that a bad thing?

>Good luck explaining to team that they can only use subset of C++

You learn as you go, like literally any other language. You don't need to understand every single line and function call in a program to make changes or add things to it. As you come across something you need to modify, you learn a bit about the features being used.

Now, if you have a real go-getter on the team who has covered the entire project in the most advanced features used in the most obscure ways, sure, it's going to suck for anyone just starting. But that's a problem again, in literally any language. And not a fault of C++, frankly.

> I'm not sure how this is a gotcha. I'm not that familiar with Cargo, but I think the equivalent would just be something like:

> TARGET_LINK_LIBRARIES(myProgramName Eigen3::Eigen)

Include how the library gets in your build, not how you link it.

> Also...why does it matter if there's a cmakelists.txt file? How is that a bad thing?

Maybe because it gets dramatically harder than having `cargo install x`? Or did they solve it recently where any autotools/meson/whatever gets pulled into project without any blood sacrifices to pass all compiler flags properly?

> You learn as you go, like literally any other language. You don't need to understand every single line and function call in a program to make changes or add things to it. As you come across something you need to modify, you learn a bit about the features being used.

How can you make you changes to something you don't understand and make sure that it still works? Also, this is absolute nightmare from perspective of team and org cohesion.

> But that's a problem again, in literally any language. And not a fault of C++, frankly.

No, it's not. Aside from maybe Scala, I can't think of any mainstream modern programming language where you have to actively create your own sublanguage to make it bearable.

>Include how the library gets in your build, not how you link it.

Kind of depends. If you're in a Linux environment or something like MSYS, you'd just need the relevant Eigen package (in MSYS: mingw-w64-eigen3), which then you can link against. You could build it from source instead I suppose, and it has its own cmakelists which you just add as a subproject if you want to go that route.

This isn't rocket science. Could it be easier? Sure. But it's not terrible either.

>How can you make you changes to something you don't understand and make sure that it still works? Also, this is absolute nightmare from perspective of team and org cohesion.

You learn about how the part you're modifying works. Ask for some assistance from the team members. Read the docs. Look up anything from libraries/stdlib that you don't understand, go into the debugger and watch as the state changes. Build the knowledge gradually.

The next thing won't be as difficult. Don't try to take in the entire project at once, that's an overload of information for any non-trivial project. Again, that's true in literally any language.

It sounds like you are operating in an existing org with a mature codebase. In this context, where the existing product is implemented using C++, continuing to use the language makes perfect sense.

I implement and maintain C++ for my day job so sure, it's not that bad ... it's only bad when you compare it to the state of the art in other language ecosystems.

"This isn't rocket science. Could it be easier? Sure. But it's not terrible either."

I don't know how to measure "terrible". I agree it's not rocket science. And it's much better than two decades ago.

But still, compared almost to any other industrial language (which of course have their own set of problems) the default experience setting up and maintaining a cross platform project is abysmal.

By "abysmal" I mean that defining the build is not a project goal in itself that requires meticulous design and expertise, and is something that just works out of the box.

If you work only in posix land the experience is far less uncomfortable, of course.

Everything that you’ve listed also applies to any modern mainstream language.

Rust doesn't have those decades worth of libraries and tool development baked into it. Nor does any fairly new language.

Java has incredible tooling, far more advanced than whatever exists in C++ world. If you're looking specifically for "fairly new" language then Kotlin is your bet. Tooling is almost on par with Java. Can utilize ALL of Java ecosystem on JVM. Multiplatform (JVM, JS, native).

C#, TS if you're looking outside of JVM.

How much of C++ ecosystem Qt uses compared to the size of Qt itself? Or Chrome?

Yeah, Go is a better C alternative in terms of language space.

If one cares about language design beyond the ideas explored in Oberon and Limbo, not so much.

If you mean Go is closer to C than Rust is to C, I guess that's correct. But neither are alternatives to C.

They certainly are, outside the religious UNIX and embedded groups that cannot grasp anything beyond C.

You keep going on as if C programmers only use it because they are not as smart as you, who punts C++ all the time.

I wonder if you are unable to understand that for some people and some problems, having fewer footguns is a benefit.

Lots of experience meeting such folks for several decades, since 1993, to be more precisely.

Lots of Usenet discussions on the matter, and other places.

It sounds like a very long winded way of agreeing that you are, indeed, unable to understand why fewer footguns is seen as a benefit.

Only by those that never bothered to understand ISO C legalese, and actual implementations.

You ever wrote firmware for a wireless sensor that fits in 16k of flash?

My first computer developing software was a Timex 2068.

Have you ever produced commercial software for 8 bit machines?

8 bits yes. But can't actually care about the register size of the uP I use. Currently it's ARM.

What's important is the RAM and ROM limitations.

Plus meeting latency deadlines.

Power requirements.

That the program never gets shut down for years.

That there will be no one to intervene when something goes wrong.

Current product I work on has shipped a few million units. If someone needs to replace one that's failed it costs more than the unit itself.

It'd been nice not to use C. Be nice if C had a few improvements to make it more ergonomic and safer.

Then those outside groups should make a software foundation that's attractive enough to replace UNIX.

I see Debian today tinkering with two additional kernels - FreeBSD and Hurd, and both are written in C.

Until some kernel 100% written in Rust/Go/modern C++ starts being attractive for OS integration there is absolutely no point in claiming it's possible and even a better choice.

C has lost a lot of ground since 30 years ago, rightfully. User applications with GUI used to be written in something like C89. Games too. It's some people that just cannot grasp that it and its ecosystem have a huge merit over 'alternatives' when it comes to the ground it retained and still holds today.

Doing a top down rewrite of an OS is an absurd task, so regrardless of merit, C is going to retain its place there by momentum. If it’s going to be replaced at all, it will be incrementally, and until recently, the powers that be have kept other languages out of that space (and for good reason, since multiple languages interacting have complexity costs, again regardless of individual language merits).

But we have started seeing just a bit of Rust support in Linux now…

Can I use Go to program my STM32 MCU?

Via TinyGo.

Interesting, it's quite the opposite to me. I've been in C++ programming since TurboVision times (don't miss them), built many projects in C++, but Golang feels like fresh air to me, at least for server applications.

Probably it's mostly about runtime/libraries than language itself.

Aside of embedded applications and hardcore number crunching (core part of it) I can't find a single use for C++ in 2023.

Games come to mind and anything that needs performance.

Starting from scratch, Rust is a fine option there, but it lacks publicly available platform integrations, or any engines as powerful as Unreal. It’s to be seen if that momentum advantage can be overcome anytime soon.

On the core levels – yes.

I think this is a fair view, but C++ has a lot of flaws. It's good enough that it's very hard to justify switching away from it, and it will be a good resume language for quite a long time, but I would hesitate to start any new project in it.

I never recommended Go :-) I'd personally rather program C++ than Go, so I can see where you're coming from! That said, C++ is abandonware, switch to a modern language :-) :-)

Reply on news.ycombinator.com