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

The pool of talented C++ developers is running dry

efinancialcareers.com

Post reply on HN
Print view View original

731–740 of 869 posts

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

#731

Post by astrange »

germandiago wrote: post #631
astrange wrote: post #623

Earlier quoted context omitted.

My experience with C++ is that every five years I come in and see people claiming that not only should I never do whatever I was told five years ago, but actually it was never popular and nobody ever did it. Mostly about ways to allocate objects or use smart pointers. I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++. Do they just like hitting keys on the keyboard?

> I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++ 1. because it is greppable and unsafe 2. because there is also static_cast and dynamic_cast 3. Because in C (int) is all three at once and not greppable -> C will let you do whatever, C++ will not let you do with a static_cast everything you can do with a (T) cast. All in all, it is nice to ask, but if you do not know what you are talking about e…

> 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 either, like how `unsigned short` * `unsigned short` produces `int`.

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

#732

Post by ahepp »

chaostheory wrote: post #674
germandiago wrote: post #637

Earlier quoted context omitted.

True. I also like Python. The problem is when you need 30 servers instead of one to manage your load, though, lol.

I also love Python the language, but it’s hard to keep using it when it’s so slow. Parallel processing helps, but it’s still slow. Definitely dumping pandas the first chance I get. It’s one of two major bottlenecks with the other being anaconda for Windows. Maybe the culprit is running Python on Windows since it relies on so many parts of nix?

I thought parallelism was pretty limited in python due to the GIL (global interpreter lock, iirc)?

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

#733

Post by timbit42 »

greyhair wrote: post #726
jjav wrote: post #644

Earlier quoted context omitted.

> And what can be used instead of C++? For most use cases Java is a better option. Very fast, without any of the pain. If you truly must not have a VM (rare), there's still C. Perhaps rust.

I think this is probably the most salient point. C/Rust then Java. I don't know why people hate on Java so much. And I think C lives fine along side Rust.

Java forces OOP and it's verbosity is worse than COBOL.

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

#734

Post by butterisgood »

I find a subset of C++ to be pretty enjoyable to use to be honest. But I think if I hadn’t cut my programming teeth on it so early in my life I would probably share the opinion of most of my coworkers about how it’s a bit of a monstrosity.

It’s difficult to argue that it isn’t.

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

#735

Post by timbit42 »

programmer_dude wrote: post #680
adgjlsfhk1 wrote: post #567

Earlier quoted context omitted.

Julia is solving many of the same problems as C++. GPU compute, HPC, high performance algebra kernels are all well within Julia's purview. It's not (at least yet) good for things like writing OS kernels but there is a large amount of overlap with C++.

Isn't Julia a dynamically typed language?

Yes, but it's strongly typed, which is more important.

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

#736

Post by timbit42 »

germandiago wrote: post #617
ayberk wrote: post #413

Earlier quoted context omitted.

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…

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

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

#737

Post by intelVISA »

ahepp wrote: post #727
intelVISA wrote: post #570

Earlier quoted context omitted.

As a C++ enjoyer I would 100% have learned Rust if it was around when I started... just for Cargo alone. Problem is now I've already done my time in the Makefile trenches there's little incentive in me re-learning another systems lang and having to compete with lots of smarter people, with more Rust exp, for jobs whilst giving up all my arcane knowledge of CMake and friends. Rust being popular atm is great for C++ if…

> it siphons away a new gen of systems programmers over to another lang allowing me to sell my dark services for more coins I've always been curious about whether it really works this way. First order, one would consider supply and demand leading to increased wages. But whenever I've looked into the reports of "COBOL programmers are getting paid a fortune because there are so few of them alive!", the reality has been…

No doubt, though it's worth considering the tech industry is a bit more diversified now than the days of COBOL number crunchers and Space Invaders. What you're describing seems closer to PHP vs. Javascript than something as entrenched as idio-matic legacy C++.

And heck, if I'm wrong I'm sure somewhere like AWS will entomb me as an SRE, or some such, so even long after I'm RMA'd my spaghetti abominations can continue to haunt the cloud.

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

#738

Post by BenFrantzDale »

germandiago wrote: post #631
astrange wrote: post #623

Earlier quoted context omitted.

My experience with C++ is that every five years I come in and see people claiming that not only should I never do whatever I was told five years ago, but actually it was never popular and nobody ever did it. Mostly about ways to allocate objects or use smart pointers. I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++. Do they just like hitting keys on the keyboard?

> I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++ 1. because it is greppable and unsafe 2. because there is also static_cast and dynamic_cast 3. Because in C (int) is all three at once and not greppable -> C will let you do whatever, C++ will not let you do with a static_cast everything you can do with a (T) cast. All in all, it is nice to ask, but if you do not know what you are talking about e…

A reinterpret_cast is something that shows up very rarely, so it’s fine that it’s not concise. And when it is used, it usually can do with a function naming it. I try to have a “no raw reinterpret_cast” view unless it’s chars to unsigned chars for string stuff. And as others have said, it’s grepable and can’t cast away constness. If I’m handing a const unsigned char* to a function taking a char* that I know wind modify the data, I don’t want that to be (char*)ptr. I want it to be const_cast(reinterpret_cast(ptr)) because yikes, it should stand out because it’s awful.

And then I’d wrap that godawful cast in a function overloading the legacy C interface, so the overload has one job: to encapsulate the logic that the legacy function isn’t const correct. So then I’d have like void wrappedFoo(std::string_view s) { foo(const_cast(reinterpret_cast(s.data())), s.size()); } with lots of comments about the cast.

Post reply on HN