Everytime that I have turned away from Rust, despite trying half a dozen times is due to its super busy and alien looking syntax. I just can't parse the code.
Rather, I think the problem is that the syntax is 100% fine in isolation, but has some issues when taken together with experience in other languages — when you skim the code, some parts of it beg to be looked at like C++, while other parts push you to read it like a functional language. Unsurprisingly, neither fully works, which makes the experience jarring. Once you accept that Rust is its own language with its own rules and stop trying to borrow (hah!) from your experience with other languages, it feels much better.
You literally just got a user experience report claiming that it is.
There's no winning over everyone. Of course Rust's syntax will be completely jarring if you're coming from Crystal or Ruby.
In my personal experience it's a little jarring at first and then it completely goes away.
* The need to put :: before <> in expressions for generic parameters, but not in type signatures.
* Using :: instead of just . even though most of the time the naming convention will delineate the difference anyway
* Error handling with futures
* Self-referential structs
* Passing a shared pointer through multiple move closures
IMHO the frustration involved in these things is not typically worth being more explicit. The :: thing may seem a bit pedantic, but it is simply more physical effort (Shift-colon-colon vs dot) and creates more visual noise.
If/when all of the things above are addressed, I think Rust could give Python a run for its money.
I don’t mind the syntax because I find it explicit enough, but terse enough in certain cases. It’s similar but different and so it rhymes with my past in C++, but it’s not the same.
https://crystal-lang.org/reference/overview/http_server.html
I have heard this a lot, and I am not sure I agree. I agree that the limiting factor for how long a project takes to finish is never going to be how fast you can type, but when I am really in flow I am actually typing pretty quickly, and I don't really like more friction when it's not necessary.
Of course it's a matter of taste, but the argument that it's english-like never made sense to me either. There is no english sentence construct with "do ... end" or "wile ... end".
Patricia Asa has an excellent presentation[0] on how she tried to learned C# and one of the biggest things she discovered was these bad cross-over abstractions held her back.
I think there is such a thing as liking what's familiar, but there are also design decisions which are simply easier to read or easier to parse. Another one would be semicolons: I have never missed semicolons one bit in a language where they're not required.
I dutifully wrote semicolons for years, but just a short stint of Scala and I don't like using them anywhere now.
I'm trying to learn Rust, working through various programming exercises, but it looks and feels very foreign to me.
One example is the closure syntax. Compared to Go where closures look just like function definitions, closures in Rust look needlessly complex.
I also always find myself wanting to type mut &a instead of the correct &mut a. The former just seems more obvious to me, a reference to a is &a. Mutable a is mut a. So a mutable reference must be mut &a.
Then the lifetime syntax, I don't even know what to think of that, but that's probably more because I'm struggling asking myself "Should I use a lifetime here, or am I doing something else wrong that is preventing the compiler from figuring it out."
Maybe these things make more sense to people coming from C.
In the same vein I think Typescript error messages are absolutely horrific. Furthermore, I keep seeing people who start using Typescript to "make it like my preferred language xyz".
Coincidentally these devs 1) hate Javascript 2) end up writing a massively over engineered OO big ball of mud
These reasons are why I avoid Typescript where I can.
I'm still not so experienced though so maybe it gets better.
There are many things like this in Rust where if you just follow the compiler errors until you can make it happy, things will end up really convoluted and baffling. They'll also probably not perform as well. To really use Rust you have to absorb what's actually going on underneath its protections, and not just the errors that surface from them. This isn't easy, and is probably the dividing line between people who stick with it and people who decide it's not for them.
You get about 50% of this picture for free (thinking in terms of stack, heap, references) if you've done C/C++ before. The other 50% is completely unique to Rust. But the key is to read the Book, follow guides, etc. Rust isn't really something you can learn just by hacking it out on your own, unfortunately.