Exceptions are great when you don't want to handle errors properly, but when you do want robust error handling I find the "return a value" pattern much better. Notably even C++ is looking into implementing this!
It works because Rust has pattern matching and generics as well. Just having a Result type isn't going to help with error handling much, and Go is not getting generics Rust style nor pattern matching any time soon.
Let us be reminded that Go errors as values are purely a convention, nothing in the language mandates their use. On the other hand panic/defer/recover are language constructs.
Option types demand pattern matching and similar techniques for working with those types. Otherwise you just have "if (x.isDefined) a else b" blocks of code everywhere.
Sure there is, many important language features boil down to forcing users to do the right thing (not necessarily the easy thing).
In highly concurrent languages like Go, there’s not always a meaningful stack to unwind, and you end up having to pass error values around anyway. So I can easily sympathize with the decision to stick with one mechanism for error handling.
this just causes the users to use another language for their projects instead
A language that provides a lot of freedom when it comes to expressiveness without offering much in the way of constraints (to truly convey the purpose of a given piece of code with the least amount of ambiguity possible) will almost definitely turn into utter crap in contact with junior developers, and will often be a source of pain for more experienced ones once the project is nontrivial, whether they realize it or not.
Not to mention working together with more junior people, in which case it will be you doing the hand-holding instead, because the tools don't