The pool of talented C++ developers is running dry • Hacker News Board

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

#691

Post by jasmer » Wed, Nov 02, 2022, 11:22 PM UTC

thedracle wrote: post #359

jasmer wrote: post #260

Earlier quoted context omitted.

It's a resonant issue: if everyone is taught Python, it's the tool they will reach for. And of course, Python is much more broadly applicable. I don't like to develop in C++ because it's a tiresome mess of issues that don't exist in modern languages. I don't care about the newer variations or whatever, I still can't do basic things or pull in a library to do it 20 years later so no thanks. That said - it's not going…

I'm really surprised at how stable and widely supported Rust's FFI is. I have several C++ projects that integrate a portion written in Rust, where the Rust project produces a .a file that is ultimately linked with clang into a larger C++ project. I definitely agree Rust has a long road to adoption in embedded/low level systems, and particularly areas with custom compilers/toolchains that rely heavily on system specif…

I agree. But I think it'll be hard to see Rust really make progress until hardware makers worldwide start really doing 'Rust First'. And the problem there, is that Rust is a bit inaccessible to many.

Rust trades of absolutely everything for performance - and that's just not the trade-off we want to make in most scenarios. Even for most embedded systems - something that's easy to program, easy to read, easy to support, great tooling etc. is worth more than a 'a bit faster performance'.

If we were to have created something ideal for embedded systems, it would not be Rust. I think it'd be a bit more like Go. Or just like a 'Safe C' with a lot better built-in libraries.

I like Rust but I fear it is not 'the one' and the bandwagon has already left the station so we have to go with it.

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

#692

Post by bigbillheck » Wed, Nov 02, 2022, 11:23 PM UTC

brink wrote: post #83

datalopers wrote: post #42

Earlier quoted context omitted.

C++ doesn’t require you attend an annual furry convention.

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)

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

#693

Post by icedchai » Wed, Nov 02, 2022, 11:30 PM UTC

I've had C++ projects at work over the years, and generally despise the language (it feels too complex.) I actively avoid it. C is fine. C++, no thanks.

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

#694

Post by Suro » Wed, Nov 02, 2022, 11:31 PM UTC

I did my time in C++, had fun, learnt plenty, then got an offer to do some python with a way better salary. At some point company have to seriously up their offer if they want me to care about ABI breakage, weird bug cause by undefined behavior, and the usual 100k loc of legacy code with 10+MB sized object and no coherent memory ownership.

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

#695

Post by bombolo » Wed, Nov 02, 2022, 11:42 PM UTC

Remnant44 wrote: post #419

jahewson wrote: post #234

Earlier quoted context omitted.

Why waste time writing tests when you could be busy fixing bugs!?

Jokes on you, they probably didn't fix big either ;)

Well the bug reports were like: "I clicked around and the UI froze/crashed"… no info on how to reproduce, no logs, nothing. Just that bit of information.

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

#696

Post by deviantbit » Wed, Nov 02, 2022, 11:45 PM UTC

pencilguin wrote: post #563

deviantbit wrote: post #543

Earlier quoted context omitted.

The difference between C++ today, and what we had 20 years ago is not much. C++ has functionality built in today, we didn't have, but the OS provided, and now the language has many features we wished we had years ago. Example: Variadic templates. When that happened, the problems we would bang our head against the wall with magically vanished. Twenty years ago, every implementation of the std library had serious bugs…

Template metaprogramming is hardly ever needed anymore. C++20 has better built-in features that for most of what was done with it, that compile much faster. Almost all C++ programmers completely ignore it. You can too.

New way? You mean, expanded.

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

#697

Post by robotresearcher » Wed, Nov 02, 2022, 11:52 PM UTC

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…

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?

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

#698

Post by [deleted] » Thu, Nov 03, 2022, 12:03 AM UTC

adrianN wrote: post #356

sentinalien wrote: post #334

Earlier quoted context omitted.

I understand this but I think the biggest driver for software salaries is the sheer number of companies that are interested in hiring software engineers. Plenty of hardware companies are very profitable but do not raise their salaries because there is no market pressure to do so as the more limited job market means EEs/embedded engineers do not switch companies nearly as frequently and switching companies is generall…

Which hardware companies have SaaS margins? I think 10% margin is very good for a hardware company. A software company would aim for multiple times that.

[deleted]

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

#699

Post by worthless-trash » Thu, Nov 03, 2022, 12:11 AM UTC

chaostheory wrote: post #653

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…

I wonder how the Cobol market is doing?

The funny part about cobol is that even if you say you know the syntax, there is site specific implementation details/features which are even MORE critical than just the language.

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

#700

Post by josephg » Thu, Nov 03, 2022, 12:20 AM UTC

tele_ski wrote: post #590

josephg wrote: post #551

Earlier quoted context omitted.

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…

I like you're analogy, but I do think there are features of c++ that are big hills as well. To me it would be SF to LA with some big ups and downs on that long ride. I'm also curious what's difficult about pin in rust? It basically just disables moving of the object for the lifetime of the pin.

> I'm also curious what's difficult about pin in rust?

I understand the concept. It’s the syntax which trips me up. You don’t mark structs as Pin. You mark them as !Unpin. And then, when is it safe to pin_project fields? Every time I read the documentation I understand it for about an hour. 2 weeks later I need to re-read the docs again to convince myself I’m not subtly messing anything up.

I’ve also gotten myself in hot water writing custom Futures, trying to wade through the barrage of compiler errors at the intersection of lifetimes, Pin and async. It’s a lot harder than it needs to be. The compiler holes around GAT, async closures and async trait methods doesn’t help.