> Sounds like they were trying to force the language to be something it's not
They're getting around the lack of features in the language. Most languages that I know of have mature DI solutions, and those are needed for writing any non-trivial app.
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.
> Most languages that I know of have mature DI solutions, and those are needed for writing any non-trivial app.
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...
> You're speaking as if generating mocks and adding stack traces to errors are... features
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.
The language authors did not work on large systems. If their position did hold any merit, we wouldn't have seen many people try to solve the shortcomings of their language.
Sometimes these "everyone else is wrong about everything they think is obvious and only I know the truth" takes can be interesting, but usually when accompanied by some kind of reasoning or presentation of an alternative.
They're getting around the lack of features in the language. Most languages that I know of have mature DI solutions, and those are needed for writing any non-trivial app.
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.