You are right in such a deep sense that I wish I had more than one upvote to give.
This is what people mean when they say a design pattern represents a deficiency in a language: the very fact that it's a design pattern and not, say, a library function is precisely because that language provides no way to abstract it away. Hence, rather than being something that we can turn into a reusable code artifact, the pattern instead becomes a piece of programmer lore, existing only in comments, in design documents or in people's heads.
You're thinking wrong. You're thinking like you're going to only use one language ever in your career. You're not (unless you have a very stunted career).
Learn what you're doing, independent of language. Then also learn what you're doing within the language.
I strongly disagree that I am "thinking wrong". I think you're saying that design patterns are a useful abstract way of thinking about your problem that you then translate into code using whatever tools are available in the language you're using. I think there are some patterns for which this is true, but the majority don't fall into that category.
This is what people mean when they say a design pattern represents a deficiency in a language: the very fact that it's a design pattern and not, say, a library function is precisely because that language provides no way to abstract it away. Hence, rather than being something that we can turn into a reusable code artifact, the pattern instead becomes a piece of programmer lore, existing only in comments, in design documents or in people's heads.