Live data from Hacker News

C++20, How Hard Could It Be

docs.google.com

221–230 of 444 posts

Re: C++20, How Hard Could It Be

#221
post #53

Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a s…

The real solution, which decades from now will be the eventual common-place, but no one dares to imaging the possibility today is that when languages deprecate a feature, the compilers deliver code-mods that migrate your code-base perfectly. But people are afraid of going that route because of the bad press around Python 2 / 3. We need a new generation of developers that don't remember that. Today, there's already st…

UB throws a huge wrench into all of this. The behavior of a C++ program is defined by a combination of the code, the compiler, the compiler flags, and the target archecture. You can't write a source to source translator that preserves the semantics of a program with UB without that extra information about how it was compiled. It's a very hairy problem.

Re: C++20, How Hard Could It Be

#222
post #201

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

Honest question: is it easy to find good C++ programmers these days?

that's a good question, I have yet to find a good beginner friendly modern c++ education material, be it a book or some course, that can make c++ learning simpler, to the point and enough to start to work with the language before diverting into those deep concepts.

Someone needs to write a c++ 101 book, followed by 201 and 301 for beginner, intermediate, and advanced users.

Re: C++20, How Hard Could It Be

#223
post #56

Earlier quoted context omitted.

This how i got traumatized by rust: i had a simple task, 1 day long. Write a routine, use a standard output format, theb parse the results. It was to be presented in front of 20 peers the next day. Decided to try the last part in rust... Did a few tutorials, not all of them "worked," but i scratched my head and moved on. Started writing the parser. No examples worked. Couldn't put together any reference code. Even co…

Embarrasing that you are so unaware that you present this story as anything but a failure on your own part. Yeah, so you chose a language that you didn’t know for a task that you needed done in 24 hours? Whew, that’s an unforced-error story for the campfire.

I dont feel embarrassed. I'm glad I took the chance. I take chances like that regularly. I don't consider it a failure at all. My team and manager considered me a badass and leader for taking the leap, and we all had a good laugh, too.

"If you want to succeed, you must double your number of failures."

I have had so many suprises and successes by taking chances like that. And even when I don't come out ahead in the short term, I at least get exposure to and practice on new things.

Re: C++20, How Hard Could It Be

#224

Earlier quoted context omitted.

> what options do I have? I have to pick up c++ in this case. it falls to the saying "a language is either blamed, or nobody uses it". You could just use C.

or use a subset of c++ that does everything c does, plus OOP, RAII and smart pointers for free, and it compiles and links with c code smoothly as well. the only price to pay is that libstdc++ runtime must be present, which is just a few MBs that can even fit for small embedded boards.

This is what I do. Write C in C++. You don't have to use all the fancy new shit. I'll never understand why people get so upset about it.

Re: C++20, How Hard Could It Be

#225

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a large body of experience with those languages. I suspect, but can't say with any certainty, that we'll wind up in a world where the use case for C++ shrinks significantly. Rust and Go will eat into the share of new Greenfield systems that would have normally gone to C++ or even C.

I like to live in the embedded world and there I think Rust will shortly start to push out C and C++ at the wide-spread, commercial level. This is where my head is at, maybe it helps you formulate your opinion:

First, embedded C++ is not the same a full C++ (with features or library parts missing to accommodate the constrained environment). So I might never see some of the C++2x or even C++1x features. I really don't care about the C++2x standards since I might not see them in the next 10 years.

Second, memory and concurrency issues are real, even when you don't allow dynamic memory allocation after the system is initialized. We test, then test, and then run more tests, and turn on a lot of linters and analyzers but at the end of the day, they're bandaids. You can write terrible code in Rust, but you have to work harder to do it.

Third, if you really need an environment where memory is as fungible as play dough but want something portable (like inside a kernel), there will always be C. Setting up a C callable environment from assembly is well understood. In theory, calling into Rust shouldn't be any harder. But reading disassembled object files from C is generally reasonable assembler for the C I wrote. I haven't really tried doing that with Rust.

Fourth, it will take 5 years or so, but eventually we'll see commercially supported RTOS implementations for Rust that help companies to shield themselves from liability. For example, something like Threadx (AzureRTOS now). This will help push money in a virtuous cycle of better tooling -> more projects -> more money for tool venders -> better tooling.

Fifth, there will be Rust bindings to cover just about everything you do with C++ now (like game development) with high quality, idiot-proof, and portable semantics. You will find that junior developers or fresh-outs will have their skin crawl when asked to write "unsafe" code.

Sixth, there's counter evidence to support a lack of adoption of new languages. Ada provides many of the same concurrency and memory safety guarantees as Rust, and has been available since 1983, but it is not widely adopted. It is harder to use and requires significant developer training. If Rust is significantly more challenging for developers, it may go the way of Ada.

But that's in the future. If I had to start a new project today (for a braking system on a train, for example), I would start with C, a validated RTOS, and commercial toolchain. If I had to light up my kid's halloween costume? Embedded Rust as a learning exercise. The rendering engine for a VR headset (with limited batter and compute), probably C++.

Re: C++20, How Hard Could It Be

#226

Earlier quoted context omitted.

Sometimes you need to avoid GC or have direct control of your threading model and you need a language that is more expressive than C. Your only two options here with broad adoption are C++ and Rust, both of which are very complicated languages. Other languages like Zig, Ocaml, and Erlang have legitimate claims to similar performance to C++/Rust with expressiveness, but they do not have the same adoption.

See my comment elsewhere in this thread, where I argue that Go is a good replacement for C/C++ for almost all purposes.

I have spent several years writing C++ in circumstances where Go is a terrible C++ replacement. In these cases, you either need manual control of memory or you have extremely tight requirements on either speed or memory usage. In both cases, Go falls short, and C++ actually works relatively well (so does Rust - everything I am saying about C++ here applies to Rust as well). Despite C++ having a large spec and being complicated, it pushes all of that complexity to compile time. At runtime, you pay nothing for the complexity of the language.

Please elaborate to me as to why Go is an appropriate C++ replacement for:

* Trading systems that use direct NIC access and need sub-microsecond execution times.

* Performance-oriented databases (like ScyllaDB or Aerospike). Like trading systems, these are characterized by having custom shared-nothing (often stackless) asynchronous runtimes that need direct control of syscalls, and optimized IPC and synchronization primitives.

* Libraries like memcpy, math libraries, compression libraries, and encryption libraries, which need both SIMD intrinsics and minimal overhead compared to assembly implementations (Go fails on the second part of this criterion - even the Go calling convention has significant overhead). And no, you do not need to write these in assembly: C and C++ versions are far more readable and equally fast.

* Memory allocators, which cannot circularly depend on another memory allocator.

* Embedded systems with constrained memory footprints.

* Hardware drivers.

* Code for non-CPU machines, like GPUs or DSPs.

Almost all the real use cases for Rust, C, or C++ are not suitable for Go. Go is only a suitable replacement for systems programming languages in places where Java is also a suitable replacement: when you have a powerful computer and fairly loose constraints, and you are primarily doing business logic.

Re: C++20, How Hard Could It Be

#227

Earlier quoted context omitted.

> what options do I have? I have to pick up c++ in this case. it falls to the saying "a language is either blamed, or nobody uses it". You could just use C.

or use a subset of c++ that does everything c does, plus OOP, RAII and smart pointers for free, and it compiles and links with c code smoothly as well. the only price to pay is that libstdc++ runtime must be present, which is just a few MBs that can even fit for small embedded boards.

I've written firmware, systems software, drivers and plenty else this way. Just because the language gives you rope doesn't mean you _have_ to use all of it. I enjoy how terse and straightforward even good ol' structured non-object oriented code can be.

Re: C++20, How Hard Could It Be

#228
post #201

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

Honest question: is it easy to find good C++ programmers these days?

I think it is significantly more difficult to find programmers with domain expertise in the kinds of applications C++ is often used for than the language itself. There are quite a large number of good C++ programmers who have never worked anywhere close to the metal, OS, high-performance, etc, and those skills are often more difficult to learn and come by than the language.

A large amount of C++ development is still focused on enterprise and UI apps, even though one could argue that it is not the best language for that purpose.

Re: C++20, How Hard Could It Be

#229

Earlier quoted context omitted.

Mostly deprecations mean something was deemed to be a bad idea, which means it's at the very least worth taking a moment to evaluate whether somehow they were a good idea when you did them. For example should I have a method whose parameters are volatile? Well, why did I do that? It didn't do anything in C++ 17 and it still doesn't do anything in C++ 20 but now it's deprecated. Programs are written first and foremost…

> Programs are written first and foremost to be read by other humans extremely bold assumption. plenty of write-only or use-once code in the wild.

I think if write-only code were the norm, then APL would be more popular.

Re: C++20, How Hard Could It Be

#230
post #201

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

Honest question: is it easy to find good C++ programmers these days?

[deleted]
Post reply on HN