I think the main issue people who don't like the syntax have with it is that it's dense. We can imagine a much less dense syntax that preserves the same semantics, but IMO it'd be far worse.

Using matklad's first example from his article on how the issue is more the semantics[1]

    pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> {
      fn inner(path: &Path) -> io::Result<Vec<u8>> {
        let mut file = File::open(path)?;
        let mut bytes = Vec::new();
        file.read_to_end(&mut bytes)?;
        Ok(bytes)
      }
      inner(path.as_ref())
    }

we can imagine a much less symbol-heavy syntax inspired by POSIX shell, FORTH, & ADA:

    generic
        type P is Path containedBy AsRef
    public function read takes type Path named path returns u8 containedBy Vector containedBy Result fromModule io
      function inner takes type reference to Path named path returns u8 containedBy Vector containedBy Result fromModule io
        try
            let mutable file = path open fromModule File 
        let mutable bytes = new fromModule Vector
        try
            mutable reference to bytes file.read_to_end
        bytes Ok return
      noitcnuf
      path as_ref inner return
    noitcnuf

and I think we'll all agree that's much less readable even though the only punctuation is `=` and `.`. So "symbol heavy" isn't a root cause of the confusion, it's trivial to make worse syntax with fewer symbols. And I like RPN syntax & FORTH.

[1] https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

People often misuse unreadable when they mean unfamiliar. Rust really isn't that difficult to read when you get used to it.

> littered with too many special symbols and very verbose

This seems kinda self-contracticting. Special symbols are there to make the syntax terse, not verbose. Perhaps your issue is not with how things are written, but that there's a lot of information for something that seems simpler. In other words a lot of semantic complexity, rather than an issue with syntax.