Rust developers concerned about complexity, low usage

This is a thing people experience at the beginning, but once you get over the hump, for many, it is not descriptive of what it's like.

It’s quite the opposite. It may not be worth learning Rust for small simple programs, but it has an entire toolbox of features for dealing with complex problems and large programs.

For example, dealing with multi-threading and low-level memory management without the assistance of thread-safe types and borrow checker adds mental overhead of verifying and upholding all the requirements manually.

> Rust is renowned for imposing a high cognitive load on all but the most trivial tasks.

By whom exactly? I think it's actually the exact opposite. It completely frees you from having to think about entire classes of bugs.

Rust is memed for that by people who don’t actually program Rust.

In practice it is absolutely the opposite. Rust makes really challenging problems extremely tractable, and takes an enormous amount of mental overhead off the table.

That cognitive load around ownership and sharing already existed in C and even assembly, we were just managing it very poorly without tooling.

I'm an old programmer. I started with Java, learned Ada because I thought it'd be the next best thing. Then learned Cpp for windows programming, then php. Then a job with Java, then embedded work with C. And coursework in C. My thesis was a data structure implemented in C and Java. Then a decade and a half of Cpp because robotics and ROS dominates that area. Distrbuted robotics in Cpp. Along the way Python took off, I've used R and Matlab for research for years at a time. Now Rust is here.

I have never stopped "thinking in C" from my few years of embedded work near the operating system or on bare metal. It's the language that makes the most sense when you study CPUs. The concepts match OS apis. It is simple to write C glue for any of the above languages. C libraries are not mangled. Etc etc. C feels like the language that computers and software are made with, and all other languages just try to hide that by building someone on top of it. I say that as a feeling but it might just be true.

Now Rust is here and I love it when it tries to be like C. It's clean, pure, I believe the compiler when it says something (not like Cpp), and the mental leap to the borrow checked matches ownership dynamics from C pretty well.

I hate it when it tries to be like Python or JavaScript, pulling 1000 libraries for something flashy and simple. But that's us, the programmers. The language is strict because it's the core of C without the generality. If C is the wilderness, Rust is the national park. It's beautiful, sparse, you can get lost for days, but it's safer.

> I think it's interesting that C still exists despite great efforts to kill it.

You won't get rid of C until UNIX/POSIX goes away, that is why C is still around mostly.

Now i fully agree with WG14's incompetence, it is impossible to understand that in 40 years, it was so hard to add proper string and array types to the language, between new native types, additional struct based standard library functions, or fat pointers, one approach would definitly have worked out, if they bothered.

> These guys haven't been able to come up with a non broken version of strcpy with 40 years of trying.

strcpy() is there for historic reasons, and is staying for compatibility. Functions like strtok() and in fact most functions in <string.h> are awful -- don't use them for new code.

In the same way, zero-terminated strings are there for historic reasons. They weren't a C invention. And they are staying for compatibility. There's no practical way to get rid of them.

I don't think that it would be useful to add another string type to the C library. The types of programming where C is useful today, you need memcpy and snprintf, that's about it. To add another standardized string type would only lead to a situation where we now have 15 incompatible solutions, and none of them are good for everyone.

Built in string types are more useful for languages with some form of automated resource management where one is used to mindlessly concatenating and splitting strings. The types of programming where that's a valid approach, don't use C in the first place. It's a bad fit.

Btw. zero-terminators are not entirely bad. They are an in-band signal (and can be easily completed using an additional out-of-band signal). And that can be quite useful, for example when looking at a plain binary. The space saving part that comes with zero terminators for small text strings is another thing, but admittedly has become irrelevant.

IMHO, if you stick to just unsafe rust, it’s got similar ergonomics to Zig. And the lack of safety in Zig to me is a move in the wrong direction for a language created so recently.

The safety is the added complexity because so much of what we regularly do can fail in ways we don’t think about.

The alternative so far has been to introduce some kind of automated memory management like reference counting or a GC.

Rust in fact gets much simpler (but slightly verbose) if you wrap everything in an Arc.

That’s why I say in another comment that Swift is the closest to a more accessible Rust. Granted, until Swift 6, it won’t go as far as Rust for thread safety. But for everything else, it is Rust without having to think about as much while writing.

I really, really hope that the energy cross platform Swift has been seeing lately continues and accelerates. It’s not perfect, but I find it productive and enjoyable to write. It strikes a nice balance between being strict and getting out of your way and doesn’t come off as pedantic as some languages with similar syntax.

I doubt it, what makes Swift, just like Objective-C, it is the frameworks and IDE tooling.

GNUStep went nowhere.

I tried out Swift on Windows and really enjoyed it. The experience was 100x better than I expected.

And if one feels like using a Rust like type system, there is enough to chose from between Kotlin, Scala, F#, and even Haskell dialects.

There are many people, like me, who dislike anything Java: the language, the runtime/SDK, and anything built on top of these. I even refuse to install anything that requires the JRE. Might be an irrational stance, but my early experience of JRE hogging my machine turned off it forever.

The CLR is supposed to be open now, but in practice, the ecosystem around it is still basically Microsoft.