How is this a an appropriate answer to a (not totally baseless) complaint about bad developer ergonomics? GP didn't say how hard they tried learning rust. This comes off as needlessly condescending.
More than the syntax, it's the verbosity. The more you have to read the more you have to process. Did anyone in the creators of Rust have a look at the syntax of Crystal, Kotlin, Julia, or Elixir ? They're simple, you really don't have to put a lot of effort into reading.
Rust looks like C took the verbosity of Java as a mandatory requirement and borrowed some cool concepts of Haskell (but not the simplicity of its syntax though).
Interesting, I find rust is pretty dense, but mostly in a good way. It packs a lot of important information into the code, which is useful for reasoning about it. Languages with simpler syntax tend to hide that information (and sometimes because it's irrelevant due to the kind of tradeoffs they make, like all the languages you mention have some form of GC). Haskell I would say is especially hard for me to read, when there's so little syntax the code is just a sequence of functions and symbols without obvious delimiters it becomes a lot harder for me to understand the structure of it.
Part of it is the explicitness mandated by the language (i.e. when dealing with Optionals or Results, you have to deal with both cases or explicitly state which you expect as an invariant). There's also curious (imo) choices on the part of rustfmt that seems to favor density of code that way.
I assert that certain syntaxes work with how certain people think, and don't work with how certain other people think. You can train to get around that to some degree, but it's not entirely a skill issue.
Again, without stating something more substantive about why the syntax is "incomprehensible" to them, my best assessment is always going to be "skill issue".
Wow, this is just doubling down condescension again, while insinuating laziness baselessly. I resent that, especially when it is about a language that has parts that were intentionally designed to yield hard to read code.
Well if I want to write an OS in Fortran, BASIC, nodejs or even assembly, I think it is my choice. If you don't like it, just ignore it, I really don't see the beginning of a problem there.
I understand complaints in other contexts: for instance, if one sends tens of thousands of satellites or burns forests, the mere fact that they are doing it may bother me. But again: what do you care if somebody writes a software project in a language you don't like?
Hmm... if you are part of the creators of the project, of course. Now if you don't like Rust, you should not become a maintainer of a Rust project, it's as simple as that. No need to go complain on every Rust project you find online.
Same for your own project: don't become dependent upon a project that you don't want to have to deal with... If you do, then don't go complain about it: you made the choice to depend upon it.
As someone who does some embedded development and also has a deeper general software background than most full time embedded developers: having a few large players in the MCU and/or industrial automation sector support a from-scratch effort to build a decent embedded OS in Rust, with ditto tooling, would be a game changer.
Most current embedded and RTOS operating systems and development toolchains are just horrific. Hence, most of the things around us that control important things, depend on much weaker foundation that you'd like to imagine.
This is mostly a manifestation of MCU manufacturers having trouble just managing their own challenges and not having the capacity to even start thinking about what it is like to use the devtools for customers.
They love Zephyr because it helps them solve their problems. That it is a pain in the ass for developers isn't something they seem to spend much time thinking about. Or even seem to be aware of the importance of.
You can think of Rust as a containment zone to isolate the kind of people who would be a Rust programmer from people working on actual real things, obviously in C and C++.
