Live data from Hacker News

The pool of talented C++ developers is running dry

efinancialcareers.com

761–770 of 869 posts

Re: The pool of talented C++ developers is running dry

#761
post #413
post #209

I’ll offer a perspective unrelated to pay: It’s a pain to start learning C++, and even after you do, older devs will roast the hell out of your code because your book/tutorials of choice forgot to mention a crucial (in their opinion) feature that you absolutely should/shouldn’t use! Not to mention you’ve only programmed on Mac/Linux so far & windows is totally different, has a different compiler, different ways to in…

As someone who has been writing C++ at Google, this exactly. Despite all the tooling, guidelines and "internal magic", C++ is still an abomination. And no it has nothing to do with memory management, I actually do like C. I love how Eric Raymond describes it as "anti-compact", because, well, it really is. C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific…

This is exactly equivalent to saying all existing C++ programmers should be demoted to doing only maintenance work, or fired.

As such, it is in violation of site terms and conditions, and damned rude.

Re: The pool of talented C++ developers is running dry

#762

Earlier quoted context omitted.

> C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason) Too bold statement. There are still lots of reasons to keep using C++. LOTS.

There are lots of reasons to keep using C++ on existing projects in C++ but there are not many reasons to choose C++ for a new project.

This is exactly equivalent to saying that all existing C++ coders should be demoted or fired.

It is, among worse things, damned rude.

Re: The pool of talented C++ developers is running dry

#763

Earlier quoted context omitted.

> 1. because it is greppable and unsafe But it is not unsafe, or rather, the C++ casts aren't more safe. They have the same semantics. There are differences casting between class types, but with numeric types the issues are how to handle the value not fitting in (or being imprecise) in the destination type. Casting a value to int in C++ that overflows is still UB. It doesn't fix C's other strange numeric issues eithe…

they are unsafe because if you try to cast something that's not valid the compiler won't let you. you can then choose to ignore it and be unsafe, or figure out the problem and fix it.

You can still cast INT_MAX to short no matter how you spell the cast, and the result won't be correct.

Re: The pool of talented C++ developers is running dry

#764
post #83

Earlier quoted context omitted.

Or be a part of a discord group that flies a pride flag in your face for 6 months of the year. A helping of ideology is what I've really been looking for in a programming language.

I wrote several hobby projects in scala but once I realized what kind of people were in that community I decided not to have anything more to do with it. (And I'm not talking about Tony Morris)

Well, what kind of people?

Re: The pool of talented C++ developers is running dry

#765
post #679

Earlier quoted context omitted.

Try doing (serious) high frequency trading in rust, then come back to me.

Jane Street is doing it in Ocaml (which is pretty similar to Rust + GC) and they seem to be pretty serious. Are you working at a more "serious" company where they only use languages with the safety level of Assembly?

a) Yes I run technology at a more serious HFT firm than Jane Street. b) Jane Street also use FPGAs, so you cannot exactly say they just use ocaml, it’s more nuanced than that, they are using a mixture of technologies. I think they made a very unfortunate choice early on and are still paying for it.

Re: The pool of talented C++ developers is running dry

#766

Earlier quoted context omitted.

If people think C++ is hard to learn and attracts opinionated people boy are they in for a surprise when they start using Rust.

Learning rust is like cycling over 2 big hills. It’s exhausting and painful if you’re in any way out of shape. Learning C++ is like cycling from SF to LA. It starts easy enough and every day you’re making a lot of satisfying progress. But you have so far to go because of all the features and quirks of the language. It’s probably easier to get started learning C++. But it’s also much faster to finish learning rust and…

It would also be easy to get started learning Rust, if people cared enough about doing it. The best way to learn Rust as a first programming language is to start with pure value-oriented programming at first, liberally using .clone() when necessary. Then introduce borrowing, with shared and mutable references; continuing with features involving interior mutability (Cell, RefCell etc.).

This is admittedly quite different from the way people usually learn C++, but it makes sense on its own terms. It's much closer to how higher-level languages like ML and Haskell are taught, and people have successfully learned those languages in introductory programming courses.

Re: The pool of talented C++ developers is running dry

#767

Earlier quoted context omitted.

There are lots of reasons to keep using C++ on existing projects in C++ but there are not many reasons to choose C++ for a new project.

This is exactly equivalent to saying that all existing C++ coders should be demoted or fired. It is, among worse things, damned rude.

The only thing worse would be if you were a C++ programmer in the coal industry...

Re: The pool of talented C++ developers is running dry

#768

Earlier quoted context omitted.

> C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason) Too bold statement. There are still lots of reasons to keep using C++. LOTS.

There are lots of reasons to keep using C++ on existing projects in C++ but there are not many reasons to choose C++ for a new project.

That's only true if you're writing code with zero dependencies, which is rarely the case.

Re: The pool of talented C++ developers is running dry

#769

Earlier quoted context omitted.

I don't think that's true. I started C++ using the 'cfront' system, the major push wasn't because C was somehow lacking, it was because it was fashionable to do object orient programming which is hard in C. Various horrible patterns were invented using function pointers so C programmers could feel like they were doing object oriented programming and all of them sucked. When cfront turned up, the first versions basica…

Yes, OOP kind of sucks. But you can use C++ without OOP if you so wish. C# is much better but still it isn't a systems programming language due to garbage collection. So while you can solve some classes of problems easier and better, it can't replace all of C++ use cases.

That depends on the point of view.

Writing compilers, linkers, running bare metal on embedded hardware are all systems programming tasks.

Re: The pool of talented C++ developers is running dry

#770
post #494

Earlier quoted context omitted.

Mark Russinovich (of Sysinternals fame), thinks Rust should be the non-GC language of choice moving forward. https://twitter.com/markrussinovich/status/15719951172335042...

If people think C++ is hard to learn and attracts opinionated people boy are they in for a surprise when they start using Rust.

Microsoft has apparently ported DWrite to Rust (the C++/WinRT team is now having all the fun in Rust/WinRT, while ignoring the lack of tooling in C++/WinRT after they killed C++/CX), Azure IoT unit is adopting Rust on Azure Sphere alongside C while not supporting C++, and at Ignite Mark Russinovich did mention they are planning to port some sysinternals tools into Rust as kind of POC.
Post reply on HN