Design patterns exist to paper over language deficiencies. Use a language which is not deficient.

https://www.cognitect.com/blog/2007/5/17/design-patterns-are...

I agree. Doesn't contradict anything I said. So I will assume you posted the link in support of my argument :)

There's some truth to this, since some design patterns can simply be implemented "for good" in a sufficiently powerful language, but I don't find it's true in general. Unfortunately, it has become something of a thought-terminating cliché. Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win.

> Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win

Then I would say you have not arrived at the optimal solution. Keep looking.

Just my two cents - but a general purpose language is going to need to be coupled with design patterns in order to be useful for different tasks.

I'm using MVC design patterns for some codebases, I'm using DDD plus Event sourcing and Event Driven for others.

I suspect that you are thinking of a small subset of design patterns (eg. Gang of Four derived patterns like Visitor, Strategy, or Iterator )

> I'm using MVC design patterns for some codebases, I'm using DDD plus Event sourcing and Event Driven for others.

All examples of OO nonsense. There is only one pattern you need (functions) (tongue-in-cheek): https://fsharpforfunandprofit.com/fppatterns/

Edit: Also consider using the ELM architecture instead of MVC: https://guide.elm-lang.org/architecture/

I typically reach for Go when I am building things, bubbletea, a TUI library uses the Elm architecture and enforces it on people using it.

Did not like, Won't use again.

MVC is well understood and works perfectly in my experience.

edit:

Even though you were tongue in cheek about F# - this stood out on the page

> The functional programming community has design patterns and principles as well.

IMO the ELM architecture only works with pure functions. It doesn't work with languages which cannot provide this compile time guarantee. Also functional programming needs a different mindset / training. You won't benefit from it until you understand what it actually brings to the table (and what it leaves out).

I have to ask - I like some of the paradigms of Functional programming (IMO it makes concurrent programming a lot easier because state is never shared)

Why hasn't it cut through, like OO did?

and

Beam has been around since the 90s, had a good marquee project (RabbitMQ) but still has low adoption

I am not sure I if I can speak to that in general but personally I discovered functional programming late. Object oriented programming was all the rage when I got initiated and that is all that was taught in colleges.

Like what?

First class functions and iterators are probably examples of what they mean, in terms of language features that obsolete (GoF) design patterns