Node.js timers are very efficiently implemented. Their implementation (described in a detailed article about how they work) can easily handle very large numbers of timers.
They are kept in a doubly linked list that is sorted and only the next timer to fire has an actual libuv system timer associated with it. When that timer fires or is canceled, the next one in the list becomes the one attached to an actual libuv system timer. When a new timer is set, it is just inserted into the sorted list and, unless it becomes the next one to fire, it just sits in the list waiting its turn to be next. You can have thousands of these very efficiently.
Here are a couple resources on how these timers work:
How many concurrent setTimeouts before performance issues?
How does nodejs manage timers internally
The first reference contains a bunch of comments from the actual nodejs code that describes how the timer linked list system works and what it's optimized for.
The second article gives you a little higher level description of how its organized.
There are other efficiencies so that when one timer gets to the start of the list and it fires, then after calling that callback, node.js checks the front of the list for any other timers that are now ready to fire also. This will sweep up any other timers with the same "target time" as the first one and also any others that have come due while these various other callbacks were running.
When you have thousands, it will take slightly longer to insert a new timer into the sorted linked list if there are lots of timers in there, but once it is inserted, it hardly matters at all how many there are because it's only ever looking at the next one to fire. So, the process of sitting there with even tens of thousands of timers pending is just one system timer (representing the next timer event to fire) and a bunch of data. All that data for the other future timers isn't costing you anything just sitting there.
For Javascript, similar to the python's first solution, i could spawn as many setTimeouts as necessary, but the problem is that all timeouts work on the main thread, but like i said, the tasks are not resource intensive and I only need accuracy to the second.
It seems to me that nodejs could handle your quantity of setTimeout() calls just fine. If you had an issue in node.js, it wouldn't be because of the number of timers, but you would have to be certain that you apply enough CPU to the problem if you have more work to process than one core can handle. You could expand core usage with nodejs clustering or with a work queue that uses Worker Threads or other nodejs processes to help with the processing. node.js is, by itself, very efficient with anything I/O related so as long as you're not doing major CPU-intensive computation, a single node.js thread can handle a lot of event processing.
Keep in mind that Javascript timers make no accuracy guarantees. If you bog down the CPU, some timers will fire later than scheduled because they aren't pre-emptive. But, if your tasks are not CPU-intensive, then you may be just fine.
