They're working around a weakness in the language. Stack traces in exceptions are definitely a feature. golang doesn't offer it out of the box, which is why the abomination of a framework I was telling you about had to be written. Similar things had to be done to work around the lack of generics, or the lack of composability of goroutines, or even in normal functions because of lack of composability of error handling.
> Sometimes I truly don't understand the context that my peers are working in. Totally incoherent...
Exactly what I think when I see people writing large projects in golang, and all the messes they have to go through to work around its limitations.
OK, I understand this is your position. I don't share it, nor do the authors of the language. So I guess it's not a truism.
Um. Alright.
Patently false.
> Also, one of said frameworks I was referring to generates mocks for your app and wraps errors so you automatically get stack traces in errors that are being passed around. Something already solved in Java and C# and practically any language with exceptions.
You're speaking as if generating mocks and adding stack traces to errors are... features? They're not! Generating mocks almost totally defeats the purpose of using them, and stack traces have no business being attached to errors in the general case.
Sometimes I truly don't understand the context that my peers are working in. Totally incoherent...