I think the syntax of Rust isn't very appealing, but that's not a good reason to /not/ look at it.
Convince me? :)
I suspect this will turn into a flamewar fairly quickly, but my 2 cents is that Rust has a much steeper learning curve in every way, but it's more ergonomic in the long-run.
Other people will rightly suggest using the right tool for the right job. I just don't happen to do work that makes sense in Go.
1. For work, my team just wasn't going to switch to Rust. From a Python shop, Go has enough pushback. Which tells you a lot about my shop lol. I'm still holding out for Rust on a future project that I think can't be Go, and has to be Rust.
2. For work and home, Go just feels easier and faster in mental overhead with the exception of one thing[1]. Which ultimately means if I need to blindly program my way through a vague feature description, and then find out it's way different than they said, it's easier to refactor and retroactively fix a bad design in Go than Rust.
3. For work and home, Rust had a terrible dev UX when cross compiling HTTPS. I was trying to cross compile my HTTPS Rust binary, an easy task in Go, and in Rust it was a massive headache. In Go it's an afterthought. This will improve in time I'm sure, but the easiest solution in Rust was to not do it, compile on the platform it's running on.
[1]: As said, I find Go to have less overhead than Rust; Except, for any type of optional value. Go's lack of enum types and Rust's Option<> is a huge blow for me. I absolutely love Option in Rust.
Also think a lot the popularity comes from social factors rather than practical considerations. It's like an "I fought the borrow-checker, and won!" t-shirt for your resume. The guys writing Redox--yeah, that's a practical use for Rust. The guys writing web frameworks in it... no comment.
1) I don't really understand how an abstraction can be premature optimization, unless you mean "optimization" in the human sense -- optimizing the coder's time instead of the machine's resources.
2) Rust was invented to rewrite a major web browser... so it wasn't premature optimization for its original intended purpose/users. They knew what they were going to need.
2) Other part of the sentence was "typical programming tasks." Browser dev is fairly rarified compared to things like webapps, CRM, embedded, etc. It's like every kid today has Rust on his resume, but when I look at their work history, they've never even pushed the performance boundaries of Python...
If you come from a "normal" background I guess you can already program in python or ruby or java or C
From this kind of background I would love towards functional programming (Haskell or Closure) or the actor model (BEAM languages or maybe pony) or Rust.
The reality is that go forgot the last 10/20 years of progress in programming languages theory. It is true that this makes a really simple programming language but it is also true that the complexity of any task does not disappear if you use a simple programming language but it will be simply shuffle around in the code itself.
On the other side rust is pushing the state of the art in programming languages. This means that the language itself is more complex to learn, but once you master it the language itself will take care of part of the complexity in your code.
As always it is a trade-off.