Things I hate about Rust, redux

> 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 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'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

"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.

> 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.

> You have to link each test file which can be slow

Using Mold [0] as the linker might help. Written by the author of lld.

  Program (linker output size):  GNU gold | LLVM lld |  mold

  Chrome 96 (1.89 GiB):            53.86s |   11.74s | 2.21s

  Clang 13 (3.18 GiB):             64.12s |    5.82s | 2.90s

  Firefox 89 libxul (1.64 GiB):    32.95s |    6.80s | 1.42s

edit: add citation, info, times, link, will -> might, and formatting.

That's a great thought, I'm going to keep that one tucked away as a question in my back pocket.

You can easily segfault in pure Python:

  import sys
  sys.setrecursionlimit(1048576)
  def recurse(): recurse()
  recurse()

Ada has a set of High Integrity Restrictions that define pragmas that turn off exceptions:

"No_Exceptions - Raise_statements and exception_handlers are not allowed. No language-defined run-time checks are generated; however, a run-time check performed automatically by the hardware is permitted."

Source: http://www.ada-auth.org/standards/12rm/html/RM-H-4.html

If the underlying operating system or board support system have similar support then panic situations would be avoided entirely.

While this is a highly-specialized case, it is defined and supported by high integrity Ada implementations / runtimes.

But most languages don't have all their libraries willing to intentionally panic, so it's not a big deal in practice.

Vanilla python can also segfault, in certain edge cases.

    eval((lambda:0).__code__.replace(co_consts=()))

Sometimes to have the assurance means in some specific code, not always: the code is entered via some entry point, and guaranteed to reach one of its exit points without hitting a panic.

I think it's a property that you could validate via static analysis in relatively strongly-typed languages. I agree it would be impossible for Python, just because everything can change at runtime.

To do so in C# requires messing with C libraries, but generally most behaviour that could actually segfault throws an exception instead.

Author here: I haven't written any Zig, but I've read a little bit about `comptime` (which I thought was very cool).

I like compile-time programming, but I also recognize that it's programmer catnip: we love it because it lets us be clever, including in ways that aren't conducive to maintainability. That's a big part of why I like Crystal's macro system: I think it does a good job of balancing readability, expressivity, but also constraining the programmer away from compile-time gymnastics.

But like I said, I have no Zig experience, so it's very possible that Zig has much better ergonomics than I'm afraid of!

Rust initially didn't require `dyn` prefix for dynamic dispatch (trait object types), but the lack of syntactic distinction was confusing to users. Rust is low-level enough that there is a semantic difference which one you use (Rust calls it "object safety"), so you can't just pretend there's none.

Rust is also very focused on performance, and Rust users do care about making such trade-offs consciously. You care about binary size, I may care about inlined autovectorized code.

Can these code changes be automated with a tool?

One of the strengths of Go and Java is the ease of writing tools. C++ on the other hand is a mess since it's hard to look through templates (concepts probably help) and macros (good luck).

Not sure I agree with this. The relative similarity between static and dynamic dispatch in C++ is pretty confusing (to me) (edit: as in, 'virtual' vs non-'virtual' methods).

Instead of enums, how about something similar to Scala's sealed trait syntax to tell the compiler that I'm actually doing a static dispatch?

I'm just relearning Rust after first using it in the pre-1.0 days. Predicting what kind of iterator I'm going to get in what circumstances has definitely been a stumbling block for me. Sometimes it makes sense in retrospect (String::chars() must be producing copies not references, because it doesn't hold data as char internally, duh), but it is an area of the language where I frequently get unexpected compiler compiler errors.

For me, the reason I like an explicit `.iter()` is because its more refactor-friendly. If I have an existing loop over `&collection` but want to call an iterator method, I have to switch to `collection.iter().enumerate()`.

Another thing that would have avoided the whole 'IntoIterator for arrays' issue would have been implementing IntoIterator for arrays. What benefit would your version provide over the 2021 edition as-is, and why would it be worth the major consequence of fracturing the iterator system into T, &T, and &mut T, as opposed to &T and &mut T just being special cases of T?

I'd like to see a `#[no_panic]` tag similar to the `#[no_std]` one.

Raw identifiers can be used to get around any reserved keyword. So r#type would be as idiomatic a workaround as any. Arguably a lot clearer than the alternatives.