Hacker News Reader

Comment by afavour | Hacker News Reader

I've always been aware of C++ (obviously!) but it seemed impenetrable to me coming from my experience with C# and JavaScript. So I was really pleasantly surprised when I tried it out a while ago using the C++20 standard: it felt entirely usable! But then I tried Rust, which felt like that plus a pile of even better stuff. It's been difficult to find a reason to go back since but I'm glad to see even more progress is being made.

View on HN

The reason is not the language itself but what it lets you do. E.g., if you want to use Unreal Engine or write an audio plugin, learn C++ for that.

If you want to mess around with machine learning, learn enough Python for it.

Id you want to make a mobile app, learn Swift or Kotlin.

That should be the case for every language.

I get that this crowd will nerd out on language specifics.. but at the end of the day if we're good engineers we should use the best tool for the job.

There are a zillion reasons that C++ is still widely used (existing software, brand new software that relies heavily on existing libraries / game engines), so it's really nice to have lots of helpful features being added to the language and the standard library.

I'm ambivalent about Rust, but its best feature compared to C++ is a universal package manager and build system. I like vcpkg well enough, but it's not Cargo, it can't be.

Also like memory safety

Latest VS has AI integration with the static analyser, I am yet to try it out.

If we get a C++ Copilot as "borrow checker" that is already quite an improvement, even if not perfect.

What if Rust gets a Copilot to make working with borrow checker trivial?

Hmm, another idea: what if a language's compiler itself use an LLM to find invariants and issues (like race conditions) in the code?

That would be even better, naturally there still exists the whole ecosystem issue.

In any case, taken to the extreme, the language won't matter any longer, beyond some druids with the knowledge to implement Star Trek like computing models.

We will be left to architect roles.

The thing that really ticks me off about RUST is it has compiler optimizations that can’t be turned off. In C++, you can typically turn off all optimizations, including optimizing away unused variables, in most compilers. In RUST it’s part of the language specification that you cannot have an unused variable, which, for me kills the language for me since I like having unused variables for debug while I’m stepping through the code.

>which, for me kills the language for me since I like having unused variables for debug while I’m stepping through the code.

If they're unused, then they're not helping with debugging either...

It's quite a bizarre reason

Not true. Their debugger might display the value of the variables, which are unused outside the debugger. There are other options in Rust though, like logging. Create your "unused variable", and then use it in a debug log or dbg macro, etc.

v = function_call(); // inspect v in debugger but it's 'unused' to the compiler.

At least this is how it works in C and C++.

There isn't a Rust language specification, and you can use

  #![allow(dead_code)]

at the root of the crate

I'm not sure what you mean by "optimizing away unused variables", so I'm interpreting it as variables that are literally unused after declaration.

Related: https://xkcd.com/1172/

> In RUST it’s part of the language specification that you cannot have an unused variable

I believe you're confusing Rust with Go. In Rust, an unused variable is just a warning, unless you explicitly asked the compiler to turn that warning (or all warnings) into an error.

This is just wrong? You can absolutely have unused variables in Rust. It's a compiler warning, not an error.

What you cannot have, is uninitialized variables which are used.

If your development style demands uninitialized variables, you can set them to `= unimplemented!()` during development.

And as someone else said, if all you want is unused variables without warnings, you can say at the top of the root of the crate (`main.rs` or `lib.rs`):

    #![allow(dead_code)]

It might be worth noting that unimplemented!() is a thin wrapper around panic!(), so if execution makes it to that line, your program will crash.

Rust actually does allow uninitialized variables, even in safe code. But it'll be a compiler error if you try to use them in any way before initializing them, so this is mostly just a curiosity: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Unused variables just generate warnings. It will still compile.

The tradeoff is C++ is an amazing language for building a type system and zero overhead abstractions, where Rust is extremely limiting in that area (orphan rule, constant evaluating const-generics, no implicit pedagogically equivalent type conversions, users don't define what move semantics mean, terrible variadic programming, macros can't interact with CTFE or generics, functions/lambdas cannot be const-generics). Some of that will probably improve over time, though, although metaprogramming in Rust advances slower than C++ since 2014 and it has to play catch up already.

I learned C++ in the late 90s and didn't touch it until recently and all the new stuff basically melted my brain. It feels like a different language now.

As someone who learned JavaScript in the late 90s I feel the same way sometimes! If I'd gone away from the ecosystem and returned recently I think it would feel extremely alien.

Indeed. I was working in/on C++ back in the late 80s and the 90s and I decided a few years ago to do a project with it.

I took the approach of learning it as a brand new language that I knew nothing about, and especially avoiding thinking about what I already knew about C++ and especially C. The result was a language that yes, is a pleasure to work in.

Of course some context could not be ignored: there are about six ways to do many things because of back compatibility. But that back compatibility is why so many people use it. I write in one style, and just know the others for reading other people's code.

Yeah, that's me, I used C++ professionally throughout the 90s and early 2000s, then switched to C# (and C for embedded). Unfortunately, the C++ code bases I work with are equally old so I also have to look for a brand-new project to re-learn modern C++.

Just like any other language.

Users of 1996's Java won't recognise Java 21, or 2001's C# versus C# 12.

Reply on news.ycombinator.com