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…

It’s all about experience IMHO, just start small projects (and in my experience ignore all these “design patterns”, I learned quite a lot of patterns, but I’m not really using any of them nowadays, maybe sometimes intuitively, (as this thread shows, “dependency injection” which can be a fancy term for generic function parameters).

Well maybe learn them, but take everything with a grain of salt, I think. Intuitively thinking is often better (with the drive to do it better). Try to write code such that it’s easily readable exactly focused on the problem that it’s trying to solve, not anything fancier (this is actually a very simple but effective Mantra). Otherwise it often leads to overengineering (all these “design patterns” for example…), or premature optimization. (E.g. something like the popular book “Clean code” is IMHO full of antipatterns, like the examples are definitely not something I would do, they are inefficient, boilerplate, and often make the code unreadable).

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

I couldn’t believe it, tried it out, what the actual heck? I mean I get all these weird string vs number comparison but sorting actual numbers and this comes out? What kind of drugs were the designers of javascript (or at least this function) on… Who thought it was a good idea to sort numbers lexicographically??

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.

In germany, netcup has a quite good price/performance ratio