During downtime between 2 jobs, I used to look at different languages for like half a day each, just to see what they did differently compared to the ones I already knew. I was mostly interested in concepts, not syntax.
This has helped me to be quicker when picking up new languages or even frameworks. Because, well, nothing is ever really new, right?
(Note that I would not recommend this strategy to a complete beginner. You need something to compare what you are discovering to.)
As for recommendations, I would suggest you look at what kind of problem you're trying to solve. If you could benefit from the infrastructure something like Java EE provides you, choose Java or kotlin (those are mostly interchangeable). For scripting, choose bash or python. For client-side web stuff, JavaScript. And so on.
Process modeling requires some reading up front, I think. Integration into our application was relatively easy - activities implemented as Java classes with a reasonably good API.
As for results, we are quite happy with camunda. No issues with performance, incident handling, etc. We have about 100k new process instances/day, with 5-10 steps per process (3 different processes), some of which run over multiple days.
Our system is based on the Camunda process engine (in a Java EE environment). There's a central process server (or cluster) running the process engine, with events to start process instances.
Workflows are defined using bpmn and then executed by the engine. Errors are reported to the process engine as "Incident", which then show up in the management ui/apis. These can be retried any number of times.
We also have an older system based on Carnot/Stardust/IPP. This one used JMS messages everywhere.
None of course, but I think that's the point of the complaint. For a feature supposed to increase convenience, it didn't go as far as it could have. Still, I'm glad var is in there. (Now, my employer just needs to get off of Java 8...)