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.
Yeah, I agree with most not so interesting code (which is surprisingly much, if I think about it, especially average frontend/backend apps, client side oriented boilerplaty code (say e.g. React UI...)).
But coding a nice smart architecture, something novel/innovative (I think where the art of software engineering really lies IMHO)... well I'm not even thinking anymore about using AI (for now at least), it just confuses me, writes dumb code, and writing back and forth with it is cumbersome (to get better code), so that I just code it myself (being a fast typer is reallly helpful I think...). (I'm using it often though as some kind of StackOverflow replacement, but letting the AI code...? nah).
I think it'll likely take a few years still where I really seriously can/have to think about using AI productively in these cases (where it may even teach me a few things about language features I haven't known yet)...
Yeah he's kinda a wannabe Elon, but I think he hasn't really found a fan base as Elon has, I'm not sure anyone really likes him lol