Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code.
Now it's applied to the other side (Rust is fine, you're just not good enough in it yet to use it properly, that's why you're discouraged).
Well, sometimes the language is not fine, and its ergonomics can be all wrong.
In C it was the type looseness, bad standard library, and presence of many foot guns.
In Rust it's the overt explicitness of the borrow checker, and the friction it adds to one's programming.
I don't care if the author is a Rust expert or total newb. Someone who can write a 3D modeler in C++ is someone who should be able to use any new Algol-derived language with ease in short time, regardless if they hasn't seen a line of code in that language before.
If they can't, something's wrong with your language's ergonomics.
You've picked a very poor example to repeat that tired old addage. You're using an example of someone who admits struggling with memory management issues who has just started learning a programming language which he doesn't master, and after he grew tired of having the compiler warn him that he was writing broken code he decided to keep writing broken code but this time in a language which doesn't warn him about how broke his code is.
How exactly is this case anything other than someone not knowing how to use a programming language insisting on writing broken code?
I mean, the rationale of switching to another language was quitr clearly how the programmer grew tired of the compiler warning him he was making a series of mistakes, and he prefered keeping making the same mistakes without being bothered about pesky memory access problems.
Can you make a citation from the codebase to back up this claim?
The classes in the various <blah>widget.h headers have members that are plain pointers; that might be one place to start looking.
This statement is absurd. It implies that you believe that there are only cosmetic differences between languages, that no language can ever introduce any useful new concepts.
Rust is not hard to learn. However, it contains new things that require you to put in the time to learn them. None of those things are as hard as learning, say, recursion or assignment was when you did it the first time. However, unlike switching between other mainstream "algol-derived" languages, there are actual new things you have to learn. If you go into it just pretending it's a cosmetically different variant of C++, you are going to bang your head on every sharp corner until you quit in frustration.
And having those new concepts is the price of progress. The current programming paradigms are not sustainable in a world where basically every line of code you write is going to end up as a part of the attack surface of some system that will, eventually, get attacked.
Then add knowledge of the ecosystem :)
Well, the fact that you've missed the whole "Algol-derived language" is more absurd to me. Rust, in the end, is C++-streamlined plus fighting with the borrow checker.
Not some huge new paradigm shift in how we construct programs (as would be eg. going from C to Lisp or Idris) -- just making the lifetime aspect of memory management explicit and having the coder handle it (in lieu of e.g. a GC).
In an ideal world, Rust's lifetime management would be automatically derived by the compiler (in several cases, when it's simple, it already is).
Which is why I don't consider it some new paradigm of how to think about programs or how to structure programs (like OO or FP or logical programming are).
I think Rust is exactly that. It makes memory safety a first-class concern for the language. Thinking about it as "fighting the borrow-checker" is like trying to program procedurally in Java, only using classes as holders of static functions, and feeling like you're constantly fighting against objects.
This is exactly the type of work that's gone into the language over the last few years. It's actually quite rare with non-lexical lifetimes (and the advancements before it) that you need to explicitly call out the lifetimes anymore.
I think the language is moving in the direction you want.
I have yet to see anyone jump to Rust on first try and fell in love or could immediately use it in production with no problem. There is a huge learning curve involves.
More than often, ( Or pretty much in every case ) They gave up. It was way too complex, they hated it, it was the first time they actually had to "fight" the compiler just to get shxt done.
And then somehow after 3 / 6 / 12 / 24 months later. On 2nd try it clicked.
It wasn't just Rust 1.0 or Rust 1.2 being harder, and the newest version being easier. It is just, dare I say Human Nature? Or you have been learning Rust in your background thread for few months without you even realising it. And once it clicked, everything you hate about it seems to be God Send to programming and software development.
For a lot of people they may never click, after all Borrow Checked is complex and hard.
Most, and perhaps all of the "friction" that the borrow checker adds to exploratory programming can be fixed with comparative ease by adding a few well-placed `.clone()` calls (for immutable data) and/or changing some type declarations to `Rc<RefCell<…>>` - at a minor cost to performance, in both cases. One might think that Rust needs to do more to support this use case, but given the performance implications, this is one example of how explicit can be far better than implicit. Regardless, it's absolutely the case that you can write "ALGOL" in Rust, just as you can write FORTRAN in any language. The code might not be at peak performance, it might even leak memory in rare cases, but it will do what you expect it to do otherwise.
Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc).
It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.
Rust is both algol-derived, and ocaml-derived. And arguably the borrow checker creates a new paradigm entirely.
