I used to work in a Perl shop and must admit that the language is very simple for tasks like these, but as you mentioned it's not fast at execution time. I'm now a Go programmer professionally but I taught myself the language while in college purely out of interest and eventually found my way to the job, not the other way around. I've recently been learning a little rust because of how much that language comes up in conversations around Go. I find the concept of the borrow checker nice but I have to admit I feel lost like I am in most flavors of new fancy framework js. That's not to say Rust is really anything like js, but the learning appears the same to me as someone who's convinced they could learn just about any programming language if it was necessary (over time I've seen procedural, OOP, declarative and functional stuff but never programming logic outside of the prolog code I wrote in school).

Go isn't made for your specific task at hand but it's a very easy language to pick up and it has good directory traversal standard library code and good regex (even though with time perl's has been optimized to be faster and I think it's written in C++) but more than anything Go is "cloud native" programming in that an awful lot of new microservice tech stacks are centered around it, docker and kubernetes are written in it, and there's a thriving community whose focus is generally web-first and performance-oriented. This means for your use case there might already be a large cohort of gophers that have asked the stackoverflow questions for you

I personally would push you towards the NYT Profiler for Perl before I would towards Rest, but that's because I know you wouldn't waste any time being able to get to the task at hand and then make it go faster, and I expect all but a few rustaceans would be able to do so with the same speed.

Whatever you pick I wish you the very best of luck!

Clojure is a Lisp dialect, so if you like Lisp that's probably the way to go. Scala is more popular and broadly used, and has a larger job market especially for data engineering. Both are functional but Scala is more interoperable with Java libraries, probably a big factor in its popularity. I prefer Scala for a number of reasons, but in terms of jobs Scala is the clear leader.

Scala has more momentum. It is good for back-end programming. The popular big data framework Spark is written in Scala. Spark is a marketable skill.

If you need to program something very dynamic like old school A.I., Clojure is attractive. You would chose Scala if prefer a statically typed language, and Clojure if you prefer a dynamically typed language.

It's not clear exactly what you mean by "high money", you mean financial support to the language, money paid for a job, economic health of the market the language is positioned on?

In any case, it's very hard to give any advice here, since you'd need to provide details on the intended usage, what sector, kind of product/service, team size, potential customer type... Both languages are very general purpose and decently supported, each have its own pros and cons, both are functional as approach, and neither is really mainstream.

I've picked Node.js here but honestly it's a toss up between that and Go around this. It really depends on your background and skillset around "get something going fast" for one of these languages. Based on not knowing that I've suggested Node because it can be easier to prototype quickly and built right is performant enough. The scaffolding provided around Node.js services (Koa, Restify, NestJS) means you can get up and running pretty easily. It's important to note that the tooling surrounding this is good also, such as tracing, metrics et al (important when you're building production ready services).

You'll get more scalability and perf from go, but balancing them out I would say that you'll get pretty far with a well built Node.JS service (our entire site with over 1.5k requests/m scales easily and holds it's own with 4 pods in production.

Without knowing the scale you are building for and the systems you are using around it it's hard to say for certain this is the right route.