That guy is a lengendary blogger! And I have read that post. It was very eye opening. I always struggle when I write an (internal) API that has sync (blocking) and async (non-blocking) sections and methods. It quickly becomes very difficult to reason about!
I have to side with those saying Go has greater readability, and is easier to use and learn. I know there is a strong push (and arguably corporate backed) to put Rust in everybody faces or present it as being superior, but we still need to be realistic and honest. Not saying that Rust doesn't have its places where it can shine, just that a lot of people are going to find Go to be easier to deal with overall, and it was partially designed to be that way.
>I know there is a strong push (and arguably corporate backed) to put Rust in everybody faces or present it as being superior
No part of my comment was doing this, and this bit is entirely unnecessary and adds nothing to the comment you wrote except fan religious wars about languages.
Sure. But just due to Go type system being pretty basic I've never came across Go code I could not immediately grock, not so with Rust. Even bugging some pretty savvy Rust devs for help it sometimes took them a decent amount of time to pin down whats going on.
I work mostly with Rust, and have been for years, and no I wouldn't say that Rust is easy to read. It's easier to read than most legacy languages, but it's nothing like Golang.
Depends where someone comes from. If they are from a weakly or dynamically typed language (C, python, Javascript) then Go is quite ok. If you're coming from Haskell, OCaml, or Rust, then sure Go might be frightening.
Python is generally considered quite strongly typed, though dynamic. That is because Python has relatively few implicit conversions, and especially few that are surprising ("1" + 1 is an error, not 2 or "11"; and unsigned short + unsigned short does not equal a signed int).
That’s because Go does not have async code. It has sync code on an async runtime. Like e.g. Erlang/Elixir.