Okay i will admit i did word that a bit backwards since you typicaly select your language according to what you are trying to do.
That is some impressive analog circuitry simulation in VHDL. Works in a pretty elegant way too. Tho most will tend to use SPICE for this.
For an analogue problem with a little digital control, Spice is probably better.
The analogue capabilities of VHDL are merely one small example of system design, where digital logic is a small part of the system and where the boundaries between technologies are fluid and will change during the course of a project's lifetime.
One extreme example of the boundaries being ill defined is in the high frequency trading world. That mob puts the
entire protocol stack in FPGAs. That includes the MAC layer, the transport protocols, and the business rules.
I don't mean to ignore other languages until you find a problem that requires one. But you can get a pretty good idea of what a language is good at by googling around a bit and looking trough some tutorials for it, no need to actually learn it by writing your own code.
Most language tutorials are poor. The last good white paper I read was in 1996, by James Gosling on the philosophy of Java.
Yes object oriented programing is a significant step up from your usual raw C but not so significant that a good C programmer couldn't wrap there head around the concept of it by reading a few quick tutorials.
Quick tutorials are likely to omit key fundamentals. One example is Python's GIL which prevents it having any scalability on multiprocessor machines.
Quick tutorials are unlikely to show how well solutions can be maintained and enhanced with different staff.
Id say the important thing is just to not judge a programing language by how it looks at first glance, some languages are ugly to look at (the definition of ugly depends a lot on what you are used to a language looking like) but are still great at getting the job done.
Especially if you get into web development you enter a world of a gazilion different languages and libraries that are constantly changing, a lot of them doing the same thing but in a slightly different way,
That's a classic example of "languages" with miniscule differences. Know they exist and why, learn one if the need arises.
Knowing 2 or 3 languages well is better than knowing 10 languages badly.
You'll never know many languages well. But you need to know enough to avoid hammering in screws.
The worst example of that was someone that had to get a value from one Unix process to another. He knew databases, so he did it by one process adding a row to a table, and the other process doing database queries. Sockets? What are they?