Correct.

ocaml has potential but I strongly dislike the numeric operators, and I'm not a huge fan of the syntax in general.

OCaml with python like syntax would be damn near perfect. I could even overlook the operator thing.

This is not to deny that Rust also has other sources of complexity. But, most of Rust’s complexity can be traced to its fundamental goals of safety and performance. If you’re willing to sacrifice one of those, there are much simpler and easier languages to use.

I programmed Ruby for years before learning Rust, and aspects of Rust's library and language inspiration from Ruby are obvious to me: the closure syntax closely resembles Ruby's blocks, for example, and much of the core iterator APIs match their Ruby counterparts. It's a very different language overall, of course!

(Then of course there's the part where many early Rust contributors came from the Ruby community.)

If you think strong typing is "ceremony" then you probably spend most of your time writing (and documenting) code and not reading, refactoring, or collaborating on it.

The time people spend writing unnecessary, buggy unit tests (that static analysis can do in better languages) is far greater than the time to just use the type system.

Most languages don't even force you to be explicit anymore. They infer the types, so you don't even write extra code. You just get better errors and speed.

Lifetime annotations help how you use and exchange certain data, but you can get away without them unless you need them. For shared data structures (when synchronization primitives are too much) and highly performant code.

You can write high level Java, Ruby, and Python code in Rust if you want to. Writing Actix or Axum web handlers feels no different than Golang or Python/Flask.

    let mut v = Vec::new();
    v.push(m_foo);

Here's another example:

    let f: Vec<i32> = vec![1, 2];
     let f2: HashSet<f32> = f.iter().map(|n|n.into()).collect();

What you're actually seeing is a trap a lot of programmers fall into where if something is unfamiliar then it's treated as if it's incorrect.

But it leaves that work to the developer, thousands of hours of testing and reviewing to ensure no little corner case is missed.

I think the argument that unsafe is used making the language have “holes” is somewhat misdirected. When I see a rust implementation of a doubly linked list with unsafe I know exactly where I’m on my own (a few lines) and where the compiler does the job for me (the rest of it). It’s not as if that means safety or flexibility is out the window. It means “do the manual safety review on these two lines”.

That's not true, because you can wrap unsafe code in safe interfaces and use it from safe code.

With C, you can only do these kinds of safety guarantees with a lot of discipline. With Rust, you can offload much of your discipline to the compiler.

I hear what you’re saying, but that hasn’t been my experience with rust. I love C, but I’ve been writing rust for the last couple of years. And rust has stolen my heart.

You’re right that unsafe rust is a bit less ergonomic than just writing C. Sometimes I miss void pointers. I definitely miss how fast C compiles. But most rust isn’t unsafe rust. Even deep in my custom in-memory btree implementation I think more than half of my methods are safe. And safe rust is a fabulous language when you can use it. There’s all these bugs you just can’t write.

Early on with rust I had this magical experience. My program segfaulted in one of my tests because of memory corruption. It was “spooky action at a distance” where the segfault happened well after the buggy code was executed. Bugs like this are awful to track down in C because the bug could be literally anywhere. But when I looked at the trace, there was only one unsafe function which could be causing the problem. (Since I could rule out all my safe code). Sure enough, 10 minutes later I had a fix.

I have a skip list for large strings that I ported from C to rust. I still have no idea why, but the rust code ran about 20% faster out of the box than the original optimized C code. And yet, the code is significantly smaller and easier to work with. I’ve added a few more optimizations since then - it’s about 10x faster than the C code now. The new optimizations are all from tricks I never got around to adding in C because I was afraid I might break something.

And then there’s the things rust does well that aren’t in C at all. Cargo is incredible. Monomorphization is the right tool for a lot of problems, like custom collections. (Higher performance and types? Yes please!) Parametric enums & match statements are so much better to work with than C enums and unions. Then there's rust's std, which is fantastic. I use Option, Result, Vec, BtreeMap, PriorityQueue, the OS-agnostic filesystem API, and so on daily.

So yeah, I hear you about C being lovely. But I think rust is even better. Rust is a bit of an ordeal to learn but I'm really glad I learned it. Its a joy to use.

It would be more impressive if Rust had an actual type checked variadic print format function like C++ 23's std::println - nobody should be under any false impression about how impressive that feature is, but the type safe macro is effective, that'll do pig.