4 ms·

> 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 framework

> 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...

gher-shyu3i 5y ago
> 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.
- sagichmal 5y ago
  > They're working around a weakness in the language. Stack traces in exceptions are definitely a feature. 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.
  - gher-shyu3i 5y ago
    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.
    - sagichmal 5y ago
      > The language authors did not work on large systems. Um. Alright.
closeparen 5y ago
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.

gher-shyu3i 5y ago

> 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.

sagichmal 5y ago
> They're working around a weakness in the language. Stack traces in exceptions are definitely a feature. 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.
- gher-shyu3i 5y ago
  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.
  - sagichmal 5y ago
    > The language authors did not work on large systems. Um. Alright.

closeparen 5y ago

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.