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.
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.
Multiple things:
1) Camunda w/ a Postgres RDS DB. Works for more complex stuff that’s expressed in BPMN
2) If the workflow involves mostly automated stuff and is not running for years, AWS SWF (usually coupled with an API for checkpointing state, keeping track of wflows)
Not OP, but we built a product around it and though Camunda is reliable and fast enough for our use, the developer experience is pretty gross.
The BPMN gets saved out as an XML document, but the editor doesn't do a good job of making the format consistent. This makes changes to the BPMN basically impossible to code review without downloading the old and new copies and visually inspecting, which is a chore for large workflows. Especially when variable inputs and outputs require clicking into each node.
Small code snippets in either JS or a Java plugin (jar) can be embedded and used to massage variables and track state. These are also difficult to code review and test as you essentially need to write a harness that mimics Camunda to run them.
All of our new products are using simpler workflows via FaaS and queues (RabbitMQ). If we ever needed large workflows again I'd lean towards something like Airflow.
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.
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...)
Exactly this, work would pay for it but I didn't ask, I already had a personal subscription and I use it at least as much outside of work as I do at work.
It's not quite infinite, I think. Each of the stat bonuses is limited to 50 levels IIRC, so there is an effective limit of 800 paragon levels (16 stats * 50 levels each - would take quite a while to reach).
Not true. Once you get past 800, it's just primary stat/vit upgrades. So power upgrade per paragon is actually higher on average (because you don't need to waste into useless stats like gold)
