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

851–860 of 869 posts

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

#851

Post by boredtofears »

larve wrote: post #247
boredtofears wrote: post #91

Earlier quoted context omitted.

That's insane to me... getting into systems programming recently I am well aware of how much harder it is than web dev.

I’ve been in both web and embedded for the last 20 years, and to me web dev “done right” is just as much if not more complicated than embedded, and very similar. In both cases, you have a distributed systems (everything action you take, system wise, is asynchronous, and very uncertain). Debugging is a pain in both cases, because you have only limited access to the system under test (especially in the field), and thin…

It’s good to know this, I think I take for granted the experience I have in web dev. It’s just intimidating to be at the bottom of a large climb in a new discipline.

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

#852

Post by steveklabnik »

synergy20 wrote: post #850
ostenning wrote: post #430

Earlier quoted context omitted.

I have an EE background but worked in webdev for many years. I got pretty bored with webdev, and had the opportunity to get into embedded Rust development, so I did. Its been really awesome, learnt so much both in embedded but also hardware engineering. But now I think I'll head back to web development for my next job - I think web is better as an employee or as a contractor. It seems to me there is more freedom in w…

fully agree. rust links to its stdlib statically made its binaries too large for many embedded boards though, one reason I could not switch to it. embedded is hard to get remote positions due to hardware involvements, which sucks. on a positive side, the job could be more secure sometimes, but then the low pay truly ruined everything, overall it remains to be negative.

You don't generally use the standard library when doing embedded, especially when they're small.

Some of our Rust programs at work, while simple, are hundreds of bytes.

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

#853

Post by robotresearcher »

germandiago wrote: post #787
robotresearcher wrote: post #697

Earlier quoted context omitted.

Seems to be found by grep fine: % echo 'int x = (int)1.2f;' > foo % grep '(int)' foo int x = (int)1.2f; Does greppable mean something else in this context?

Now find casts that are known to be as unsafe as reinterpret cast for the whole set of types your codebase deals with to audit a violation of the type system. What would you grep? I would grep 'reinterpret_cast' and I would set warning as error for the c-style casts. So you can assume my codebase does not have any. I will find any cast to reference, pointer, etc. for any type. How would you do tjat if you do: (int)a…

That makes sense, thanks. Grepping for C syntax casts with arbitrary stuff between the parens is clearly not going to work.

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

#854

Post by Ragnarork »

epinephrinios wrote: post #833
Ragnarork wrote: post #170

I find it funny that the headline states it as a general trend while it's looking at it only through the prism of "the finance/crypto industry struggles to find C++ developers". Maybe part of the problem is that people don't want to work on your bullshit crypto products, or just on HFT.

Almost all crypto projects use Rust.

My LinkedIn inbox says otherwise.

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

#855

Post by germandiago »

astrange wrote: post #843
germandiago wrote: post #779

Earlier quoted context omitted.

There are more casts than those. Anda reinterpet cast is a superset of a static cast. If you want to narrow, you would use static cast, not reinterpret cast. If you want to reinterpret a set of bytes as another object then you reinterpret cast (actuall use std::bit_cast, will catch more errors,). So yes, you can still do that but consciously. In C you could even turn a cast that is essentially a static cast into a re…

> If you want to narrow, you would use static cast, not reinterpret cast. But if you do that, it's not safe! It's the same as C, which is not safe - it's "implementation defined". Swift would trap on overflow here.

> But if you do that, it's not safe!

static_cast does narrowing foor the case mentioned. reinterpret_cast would just reinterpret the same bit pattern as another type.

Whether it is equivalent or not is another story. For example, casting a float to an int will narrow but also will convert the internal format.

You can catch some overflow by {} initialization.

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

#856

Post by badpun »

pjmlp wrote: post #778
badpun wrote: post #596

Earlier quoted context omitted.

Let's add the fact that no IDE right now fully supports C++ 20. Visual Studio comes closest, but for example modules still don't really work well.

They work good enough that I only use modules on my hobby coding since VS 2022 got released.

I tried it around 6-9 months ago and the modules basically broke Intellisense - in even a smallest project with modules, the update of the Intellisense's internal state took 15-30 seconds. Hopefully it's better now, but I think I'll by trying out zig instead.

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

#857

Post by lumost »

gridspy wrote: post #710
insanitybit wrote: post #654

Earlier quoted context omitted.

I'm fairly proficient in Rust and I think it has its own strengths for learning, but its own downsides too. Pros: 1. Way easier to get "live" help, I've found the barrier to ask for Rust help is lower than any other language I've ever used (and I've used a lot) 2. Way easier tooling like cargo, error messages are far better, especially with regards to generics vs templates 3. Some things are more explicit in Rust. Li…

An accurate summary. I was reflecting exactly your cons when I left gaps in what I said Rust was good for. Con (1) (Existing examples / training) is a legacy language strength in general, C++ is going to lead in this for a long time. Con (2) (Low level data structures) I 100% agree. A toy example of a datastructure in C++ is going to be really easy to express but also dangerous to use. I think you'd really enjoy this…

The big thing to know about rust datastructures is that you need to use unsafe to implement anything cyclic. There is nothing wrong with using unsafe for a few lines of code - just review carefully.

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

#858

Post by inetknght »

cillian64 wrote: post #825
inetknght wrote: post #168

Earlier quoted context omitted.

> I only have a guess as to what a `shared_ptr` or `unique_ptr` type is, and I certainly don't know when to use them, and concepts/traits outlined in the STL documentation seem to be some sort of generalizations that the STL might provide default implementations for, but might not? What exactly is the syntax and/or type of a lambda function and how do they interact with C function pointers? etc., etc. And that's exac…

I tried to find a book which assumes knowledge of and experience with C++98 and brings you up to speed as far as C++17. Do you know of such a thing? I read some of Effective Modern C++ but it seemed to be more a list of footguns and poor design decisions in the later C++ editions.

> Do you know of such a thing?

I'm afraid I haven't read any C++ books. I'm sure that's where some of my strong biases come in; I'm all self-taught with some cppcon videos and attendance sprinkled in for topics that I know I'm weak in.

I can recommend a Slack [0] or Discord [1] though. There are plenty of other C++ people who can make such recommendations.

[0]: https://cppalliance.org/slack/

[1]: https://www.includecpp.org/discord/

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

#859

Post by selfmodruntime »

gigel82 wrote: post #372
selfmodruntime wrote: post #306

Earlier quoted context omitted.

I agree. No matter gray beards bashing Rust on HN every time it comes up, programming in Rust brings me joy and I will never use C++ again if I have a choice.

Interesting; could this be because you've been using outdated C++ ? (legacy codebases started before C++98 tend to be particularly painful) FWIW, I prefer the power of C++ over Rust's hand-holding; but can also see its appeal for someone that's not as confident over the minutia.

No, it‘s exactly the opposite: I enjoyed C++ 11 but trying any feature tacked on beyond that just makes me want to smack my head onto my desk.

The standard isn‘t slowing down: for c++ 23 the committee has announced even more features when compilers haven‘t yet implemented every CPP 17 feature. What good is a standard if no one is following it?

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

#860

Post by robomartin »

riskable wrote: post #562
robomartin wrote: post #547

Earlier quoted context omitted.

> I've even designed an analog hall effect keyboard PCB with integrated IR sensor, dual power regulators (to handle 95 ultra bright RGB LEDs), invented-by-me analog hall effect rotary encoders (incremental and absolute), and more. It wasn't rocket science. Sorry to burst your bubble... Glad you learned enough to do it and had fun with it. Yet, such PCB's are trivial to design. Heck, one could auto-route something lik…

> Yet, such PCB's are trivial to design. No, analog keyboard PCBs are not trivial at all. You have to keep a lot of things in mind when routing your analog VS digital tracks. Especially if you've got per-key RGB LEDs right next to your hall effect sensors (can be a lot of noise if you don't do it right). Not only that but you also have to figure out how to get loads of analog sensors into a microcontroller that may o…

> No, analog keyboard PCBs are not trivial at all. You have to keep a lot of things in mind when routing your analog VS digital tracks. Especially if you've got per-key RGB LEDs right next to your hall effect sensors (can be a lot of noise if you don't do it right).

Sorry. This isn't meant as an insult at all. Yes, this stuff is trivial. I know it might not seem that way to you because you are not an EE. I get it. That does not make it complex. For you, maybe. Not for me or any capable EE.

Yes, having designed plenty of challenging analog products I can definitely say that analog has its own set of challenges. Designing keyboards with hall effect switches isn't in that category.

In fact, I could easily make the argument that high speed digital is actually analog design.

> You don't need to know the specifics of RF in order to design a board that controls some LEDs.

I would like to see your boards pass FCC, CE, TUV and UL certification.

Look, there's nothing wrong with being a hobbyist and having a great time designing stuff. Bravo for having learned enough to have done what you shared. That is definitely something to admire. Just understand that your experience does not give you the ability to fully grasp professional EE reality.

Post reply on HN