I feel there are dimensions to "ease" and Go and Elixir went different directions on them. Go is very "simple" in that you can look at it and generally easily understand what it's doing.
Elixir and its ilk tends to make it easy to do what you want to do.
In Go you have to re-write things over and over because the abstractions are low, but they're easy to do. In Elixir you can use the built in libs/abstractions, but you have have no idea how they work.
This is a gross simplification of both sides of course, but I often see Go-people arguing a different point than their counterpoint in <other language> is trying to make.
Go is a language that always felt painfully obtuse to me. It always seemed hard to do basic things. To be fair I've only used it begrudgingly and never on my own work. The only thing I ever enjoyed about Go was the fast compilation.
I agree and dislike the language immensely. Some colleagues of mine like it for the runtime and compile time, which I guess is fine, but my beef with them is that they mistake motion for action.
They consider themselves "productive" because in go "...the code just flies from my fingers...", when what they're doing is reimplementing the same things over and over because the language doesn't support it.
HAVING to type a lot of stuff, even if it's easy to type, isn't productive. It's just a lot of typing.
This is not my experience. Just yesterday I had to debug an error in staging that had cropped up because erlang had changed its public API for ssh_file in OTP/23. Despite being three private libraries down (and in an obscure option, and being not well documented) I had the bug identified in 30 minutes and the patch rolled out on all three library levels in another hour.
The biggest help was IO.inspect, and then the next biggest was elixir_ls, which had used typespec analysis and highlighted the error for me in my ide.
