fuck_u_spez

Not really, the way you write, leaves a fingerprint itself, so with a little bit of AI it's possible to link personal/identifiable profiles with pseudonymous/anonymous ones.

Yeah this was my initial reaction way back when I first heard of Rust as well (sometime around 2015 or so I think). TBF it's definitely not on the same level as e.g. Haskell. But it's generally I would say less verbose than go (or at least has verboseness where it makes sense compared to go IMHO).

A good article about this: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

The generic system is also (way) less powerful compared to Rusts (The trait type system/type-classes is really a nice Haskell-inspired thing, that I don't want to miss anymore). Also the lack of sum types and proper pattern matching makes go more verbose IMHO.

That's actually where the title is coming from...

Yeah that's my point, I don't see a use for factories here, because it's possible to just use generic parameters (whether it's constructors or function arguments).

I guess I have to start calling function invocation with generic parameters, fancy names (like "dependency injection" ^^)

I say it's all about data flow and composability, if it's pretty much always in one direction (modular tree structure/architecture) then you just don't need all these "patterns"...

... until you've heard of Rust :)

(I think Go takes all mediocre language features together and makes an even more mediocre language TBH, take error handling for example, or generic programming (which I agree should be used sparingly, but is super useful if you need it))

It's probably a general symptom of what people call OOP nowadays, in a more functional composeable world (where I'm living in currently). You just use function parameters and interfaces (or as Rust calls it "Traits"). But I still think in OOP, this is enough as well and the dataflow is more clear.

Thanks for the write up, but as I said, I know and I've read all about that already. I still cannot see, why a simple function argument and an interface isn't enough (you can probably already call that "dependency injection" if you want to get fancy)

I guess I have just divorced with OOP and the "necessary" "design patterns"...

Things are more simple and less boilerplaty now for me :).

Btw. why don't interfaces work + "as argument" (whether it's a constructor in an OOP context or a function parameter)? I think interfaces are exactly built for such a use-case (without all the boilerplate that's necessary with dependency injection as well as factories).

Btw. to reference the original article where this is from:

https://stevenheidel.medium.com/a-factoryfactoryfactory-in-production-822478b5afbd

I still haven't really understood the use (and use case) of "dependency injection" (and it feels to me I read now everything about dependency injection I could find), to me it seems to be yet another ProblemFactory.