If it is cheap on the resources (less cpu and ram) it is probably more expensive on manpower. If it is cheaper on manpower it is probably less resource efficient.

You can take a look at the Web Framework Benchmarks [1] the fastest frameworks aren’t going to be in anything halfway common and even if the programming language is mainstream, the framework is probably not.

Virtual servers are affordable enough and scalability is unlikely to become hardware project for you. Most companies try to go with a “popular” programming language and framework during the time they form because they are more concerned about scaling their teams rather than their tech stack. Even then it might be worth paying a programmer a bit more when you have less competition finding programmers and the language/framework is productive.

Unless you have very specific needs the tech stack probably doesn’t matter much anymore.

[1]: https://www.techempower.com/benchmarks/

I think the sibling reply is spot on.

We've hit a sweet spot with Haskell. It's extremely efficient in both compute resource and manpower. Perfect CPU utilization with minimal memory footprint among garbage-collected languages. But you need to invest a bit into learning how to express your program in Haskell. It's not hard at all, but you just need to get used to it. You get a lot of guarantees in return. And you get self-contained binaries with a GC runtime that you can configure in various ways.

We've also had good experience with Scala, but it is unfortunately very resource hungry and Scala-native libraries often do not perform well. It's not trivial to build jlinked JREs to containerize your app out of the box. There are also issues with the transition from Scala 2 to Scala 3.

As with all JVM languages, you can bound the JVM runtime, but there's a lower threshold for a multitude of standard applications that you just can't reduce. Often you need 128-256 MiB minimum, in contrast to just 30 MiB Haskell; but for comparable performance you may need 1.5 GiB Scala/JVM as opposed to the same 30 MiB in Haskell, which you can safely raise to, 256 MiB say for improved performance.

The JRE going out of memory and crashing you app is a typical scenario if you work in a memory-constrained environment. You can stresstest your app and see when it might crash. In my experience, all our Haskell apps are very resilient. Granted, there are a couple of JVMs better suited for such scenarios, but they come with their own caveats.

All in all, we've been using Haskell for several years with JNI bindings to Java apps, and included Java code bases in our Haskell apps via inline-java. It's been a stellar experience in most cases. For some time we've also researched Scala, and decided to take this route for new projects, but unfortunately we've been disavowed by certain factors that we've recognized as inherent risks for production. And in the meantime, project Panama that improves upon the JNI FFI bindings has been advancing. So we're back to Haskell + Java with a new insights. Go is also a worthwhile ecosystem for scalable apps to explore, with its own idiosyncrasies and limitations regarding the complexity to scale.

I'd take the TechEmpower benchmarks with a grain of salt, though. They are not representative of much of what is claimed and have often been criticized. But it's the most comprehensive comparison to date. You should make sure for yourself that what you're looking at is indeed apples to apples, and not oranges.