Hacker News Reader

> The number one problem Rust has now is that it’s overall not significantly better than C++ and sometimes the reverse is true.

Maybe we are coming at this from different angles but I disagree. I remember seeing some discussions in the C++ community about challenges with using `std::string_view` that seemed like they were discouraging it and thinking to myself "this isn't a problem in Rust".

In fact, I refactored a crate I maintain from cloning objects all over the place to using references. I looked at what i did with my C++ hat on and realized that I'd consider myself irresponsible to do the same in C++ without a *very* high bar to justify it, not just because of the cost of the global analysis to ensure it was safe but the fact that that global analysis would need to be repeated on every subsequent change. Being in Rust, it compiled and I knew I was good. I even had an idea for reducing even more allocations that I thought was safe (20+ years of C++ experience, 10 in life-or-death mission-critical software) and the compiler found a case where I was wrong and the approach doesn't work.

The keyword is overall. One wouldn’t typically pick a programming language purely based on how well it handles references.

Generally Rust does memory safety better than C++, that’s painfully clear as soon as one uses the language and compares it with what happens in a C++ project with average developers. But memory safety is just one dimension of evaluation.

> The language and the ecosystem are big and complex, very comparable to the complexity of C++. It’s in a different difficulty league compared to C...

I think this is only true if you're already familiar with C-family languages (C and C++). As someone who came to lower-level programming with a JavaScript/Python/PHP background, I found Rust significantly easier to learn than either C or C++ (C was easy to do hello world, but jumped to WTF-level complexity as soon as I needed to interact with a 3-party library).

Let me put it this way: would you trust a developer who was new to C or C++ to write secure code that's free of memory safety issues, undefined behaviour and multi-threading race conditions? You can do that with Rust, and IMO that's a huge win.

> I think this is only true if you're already familiar with C-family languages (C and C++).

This comes up a lot. A lot of people learn C or C++ in school, so the distinction between learning those languages and learning programming in general gets blurry. Being full of UB that "works on my box" also makes things blurry: If you don't know how to write sound programs, have you actually "learned" the language?

I think learning C or C++ takes 2-5 years. Many people forget that, because it was mixed in with learning other things. Many others quit the learning process partway through without realizing it. Rust forces you to actually learn Rust to write Rust, which can make it seem like there's more to learn by comparison. But if you restrict yourself to the safe subset, I think there's actually much less to learn.

C++ and Rust are very deep multi-paradigm languages, with many features that try to cover a lot of domains - that’s why they are complicated. Sure, C++ has the decades of backwards compatibility and weaker memory safety, but in the end it’s clear they belong to the same difficulty class, even if C++ is likely harder to learn.

Provided they never use unsafe blocks and the third party dependencies have been inspected for code safety invariants when called from safe code with bad parameters.

I'd argue that even without the memory safety and outstanding tooling, Rust (at least no-allocator, embedded Rust) maps 1:1 with C and C++ with nicer syntax.

Some examples:

  - No DRY between headers and source files
  - Arrays are explicitly described as such in type signatures, ie not as pointers to the type they contain
  - No pre-processor
  - Cleaner, more explicit pattern matching syntax
  - No prefixing all constants/structs/enums with the module name
  - A struct or enum is declared once, with its name; ie no _t, _e, _s suffix and name duplication
  - Type inference
  - Explicit handling of enum variants

Why is a preprocessor bad? I do tons of platform level programming. Let’s say I’m doing Metal. There is #if ISO, #if APPLETV, #if MACOS stuff around the code. Sure, I could over engineer by trying to pass in some specialization functions but it can get extremely tedious and ugly to deal with. There’s a time and place for both.

If I recall correctly, C# didn’t ship with one but it was added. For one it makes it easier to use the standard build system (just compile all the files referenced) rather than have to use an outside build system that knows when to include linux.xxx and when to incluide windows.xxx etc.

Of course I’m aware of some of the drawbacks but I’d prefer with than without.

Rust has equivalent functionality but it works on syntax trees rather than token streams, so you write `#[cfg(target_os = "macos")]` as an attribute rather than wrapping an arbitrary chunk of text in `#if`/`#endif`.

- use modules

- use std::array and std::vector

- Most stuff can be use with templates and constexpr

- use namespaces

- just like in C++

- auto type inference

- enum classes

It is about time to replace C with C++.

Didn't know that! I've been translating several C and C++ (mostly C) codebases (embedded), and haven't seen those. Probably because C, and older C++ specs / design patterns.

Pattern matching is much more powerful in Rust than in C++, even with Boost libraries. Type inference is likewise more powerful, as you can overload on return type.

Today, by C++26 it should be there, while libraries like CUDA or frameworks like LLVM will keep using it.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p239...

Type inference is powerful enough with generics being Turing complete.

How do modules solve the first one?

The same way as a crate file contains everything.

https://github.com/pjmlp/RaytracingWeekend-CPP/blob/main/One...

"The number one problem Rust has now is that it’s overall not significantly better than C++"

This might be true for your specific use cases, but I've worked on reasonably large projects in both Rust and C++ and the fact that I don't have to chase various issues related to use-after-free, returning local variables, dealing with external libraries or general metaprogramming is definitely causing me to mark Rust as significantly better.

As always, if you're a C++ expert you'll bound to disagree, YMMV etc.

> It’s no coincidence that I’ve only learned a chunk of Rust - I skipped async, concurrency and parts of the standard library which I didn’t need.

I think this is why you don't think it's significantly better. I use JS and Python for most of my work, but when I want something that must do threading correctly or is performance bound, then I go to Rust over C++. That level of safety is the critical value for me.

(I also find it significantly easier to compile Rust than the typical C++ build chain, especially when doing cross platform work, but that's more a compiler than language issue.)

I went through pretty much the exact same process several years ago, coming from the same place of deep C++ expertise. Rust has some cool stuff, but it also requires learning a ton of new practices, and C++ is getting better fast enough that it just doesn't seem worthwhile to switch.

Are you saying that C++ doesn't have you learn a "ton of new practices" over time? That only makes sense if you're still writing C++98.

> Because cargo is so convenient to use, dependencies are completely out of control: adding a single crate can end up pulling in dozens of dependencies. In my case I ended up with ~150 for ~5 crates!

Being able to share code easily is a good thing, and it's one of the biggest draws of Rust compared to C++. You will see the same thing once C++ modules and package managers take off; in fact, if you don't, that means that C++ modules have failed.

> The number one problem Rust has now is that it’s overall not significantly better than C++

Username is definitely relevant! http://www.paulgraham.com/avg.html

> and what makes it worse is that everything seems to be distributed as source and has to be compiled.

You can distribute a binary shared library written in Rust, but make sure you're using a C-style public interface to preserve ABI stability and make it accessible to code written other languages. It's generally feasible to design such an interface and build Rust-friendly wrapper code that can be included in client projects - there are crates that will specifically make this easier. C++ punts on the whole ABI issue and is now facing ecosystem-wide breakage as a result.