Hacker News new | ask | show | jobs
by fioawjpoifajio 1884 days ago
I've never thought of myself as a C++ dev (or a PHP dev, or Rust dev, or Haskell dev).

I write computer programs. I don't "invest" in a language and only take jobs that use that language.

Learning more languages is almost always good. Not because you're learning more languages, but because you're learning more modes of thinking which will apply to any future language you learn.

5 comments

I agree in the abstract, but Rust is a step-function improvement compared to most other mainstream languages. It is hard to go back to writing, say, C or C++ once you have a few years of Rust experience—not because you've lost competence in them but because Rust offloads most of the complexity onto the compiler in a way that's simply not possible with older languages. You really start leaning on the affine types, the compile-time mutability xor aliasing checks, the pervasive checking of thread-safety...
> It is hard to go back to writing, say, C or C++ once you have a few years of Rust experience ... You really start leaning on the affine types, the compile-time mutability xor aliasing checks, the pervasive checking of thread-safety...

C++ has semi-official Core Guidelines issued by prominent members of the ISO-WG21 standard committee, that describe how to express these things idiomatically. Of course Rust can actually check these things automatically and achieve something close to actual memory safety, but there are ways to at least make a meaningful effort in C++.

The key part is "Rust offloads most of the complexity onto the compiler".

Yes you can make a meaningful effort in C++, but one of the great benefits of Rust is that effort is handled by the compiler instead.

The burden isn't all that great, as most good C++ code ends up looking like how you'd write the Rust code anyways.
New C++ code that your team has written, sure. What about all the libraries that you integrate with, that all have different models for allocating/using/freeing buffers? Or system APIs? (At best for those you can build a wrapper layer, and the wrapper layer is subject to the same errors as C/C++ classically is.)

One of the things that struck me as a major advantage about Java and garbage collected languages is that you can simply combine code from different libraries without worrying about what's freeing the objects, because that's the GC's job. With Rust, the memory management model takes over this responsibility without runtime cost (or minimal cost -- perhaps freeing something from the heap, if you allocated it there, but definitely not GC).

With C++, unless the library that you're using is using the same smart point library as you, from the same language version, then aren't you stuck writing wrappers around the libs you want to use?

Types like std::async seem to have changed in every recent revision of C++ version (11, 17, 20). Can you reliably find multiple open source libraries that you could integrate into a codebase that uses futures and async/await?

(It's been a long time since I've done much C++ professionally. I'm asking skeptically but genuinely.)

While true, I don't need to rewrite those libraries and can just use them rigth away, and this is why C++ keeps being my to-go language for native libraries, despite some of its flaws.

I can spend all my development budget on the problem instead sacrificing part of it to building an ecosystem.

Sure, they end up looking similar, but the point is that with C++ the developer carries the burden of making sure everything is correct and doesn't prevent you or other developers from breaking outside the bounds of what is "good" - either on purpose, or accidentally, e.g. when refactoring.

With Rust, the burden of checking all of that is shifted to the compiler, and that reduces cognitive load for the developer.

While Rust is a big help regarding memory corruption errors, you still need to watch out for the remaining 30%.
The Core Guidelines are great, but don’t attempt to go as far as Rust.
Microsoft and Google are taking care it does.

I would watch the upcoming VC++ static analysis talk regarding its progress.

https://visualstudio.microsoft.com/de/pure-virtual-cpp-event...

I don’t know what specifically you mean by “it does” but if you mean “goes as far as Rust,” that’s simply not true. It’s never even been a goal of the project.
Indeed, the goal has been to be as close as possible to Rust, given the constraints of C++ semantics.

Note I mean the work being done by Microsoft and Google on top of Core Guidelines on their syntac analysers, which on Microsoft's case are active by default as background process that validate your code as you type.

It will never be as good as Rust is able to, but in some domains a "worse is better" solution will already be better than nothing, because they aren't going to port their code to something else.

I have been following such efforts (esp. of MS) in C++ for years - progress is so slow. Feels like a slug that halfs it's speed regularly and thus will never arrive at the finish line
Me too, however I am the opinion that I rather having something that improves the status quo than nothing at all, specially because there are millions of C and C++ lines of code that no matter what will never be rewritten.

I will consider Microsoft is fully into Rust when Azure Sphere supports Rust instead of being a C only SDK, despite its security marketing.

https://techcommunity.microsoft.com/t5/internet-of-things/de...

The first step in reducing those 70% is to actually use the tools that exist, but unfortunelly the macho attitute is still quite prevalent.

https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...

Those that are open to embrace Rust, are most likely already using static analyzers.

Learning a language in depth along with its extensive standard library can buy you months or even years of expertise. This is especially true in languages like C++ (a language with massive depth, such as template metaprogramming) or C# (a language with a massive set of libraries, ASP.NET alone can take years to truly master).

This is what companies are paying big bucks for, immediate competency and productivity.

The extensive standard library and the big libraries or frameworks that are the gold standards for their niches, in that language's ecosystem.

For example Hibernate for Java ORM, Spring as the big Java "LEGO brick bucket", Rail for Ruby web development, etc.

If you ever need to work with PHP, use PHP/Hack developed by Facebook: https://hacklang.org/

It's a compiled language built partially in Rust, being rewritten entirely in Rust, JIT compiled using HHVM: https://hhvm.com/

I don't believe it's compatible with existing PHP codebases, but you could probably convert one over, catching safety issues while you did it.

Hack a modern and highly productive language that's in many ways as nearly sophisticated as Rust. (How many other languages have both opaque and transparent type aliases, for example? https://docs.hhvm.com/hack/types/type-aliases ). It has a mature async/await system, for another example. One feature it's missing is the macro system that Rust has, though.

I agree but many job postings contain stuff like "3+ years of professional experience in language x".
Honestly as someone (on the team) hiring for a job where someone else wrote the job posting, ignore the number. Just read that as "do you think you enjoy maintaining a codebase written in X".

Job postings are the fucking worst.

Yes but with time you gain experience in one or more languages and you can choose a job with the ones you like (or tolerate more). You don't need to pick or specialize one to apply for this kind of postings.
I've never actually found that to be enforced. None of my jobs have shared a tech stack, all of them have included such language. YMMV of course.
They don't enforce the number of years, but they could ask you quite deep questions about the language.

Even if you're a senior Python/Javascript developer, with experience in C# in the past, etc., if they start grilling you about Ruby, you probably won't prove that you're as equally productive as a similarly smart dev that is an actual senior Ruby dev.

I think your statement implies that you and I do not agree at a very fundamental level.
I'm saying that the world is a big place.
> Learning more languages is almost always good

Learning for the sake of learning and betting on it for employment and professional use are very different beasts.