The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.
Chewing through TBs of data every hour? Probably not a good idea to use Ruby.
Doing a bunch of really heavy math? Probably not a good idea to choose PHP.
Doing a SaaS service? C++ probably isn't a good choice.
There are some really good general purpose languages that can fit most circumstances (Java, .Net languages, Go). However, I'd be careful to say that you could apply them everywhere.
In fact I think there are certain organizational benefits to partitioning your language use by skills required to maintain that section of code. When you're a startup there's no benefit at all, but as companies grow you can use that to smoothly transition into separate teams with different expectations around testing and feature flexibility.
PHP is faster than Ruby. [1]
PHP from a local script does math just fine. It's the round trip of the request to a PHP server and back that you're associating with poor language performance. In a local scripting environment PHP7 is considerably faster than Python3. [2]
PHP is an extremely popular language as the backend for SaaS, and arguably one of the oldest and most successful. [3]
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[2] https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
[3] https://insights.stackoverflow.com/survey/2020#most-popular-...
It's not helpful to be faster than the language that the parent implied wasn't fast enough.
I think the parent's point was that if the startup's raison d'etre involves "chew[ing] through TBs of data every hour", then choosing a language that can do that 10x faster than another might have a tremendous impact on cost and so the company's value. It might be the difference between successful or not.
More generally, "it depends".
I think to OC is not well formulated: If you're selling a web app or web SAAS, any language the founders know best is the best. Any other stuff, it is not always the case (but it might be!)
I suspect they meant the kind of heavy math that the PHP 8.x JIT is trying to improve performance for.
It depends on the definition of "just fine" really, not to be argumentative. I've written quite a few algorithms processing big numbers (e.g. numbers with digits in the megabytes) and PHP struggles, where other languages like GO are several times faster and often far more easy to parallelise whereas with PHP if I want to try and use the multiple cores my CPU has, I need to look into pthreads or worse, write worker scripts that I execute with backticks or curl, it's clunky for that use-case. I wouldn't even know where to start thinking about how to run my algorithms in the GPU with PHP.
I say this as primarily a PHP developer in my paid profession, and PHP is my go-to for any kind of web development or if I want to prototype an idea - it's a very expressive and intuitive language but there are always use-cases that any language is decidedly unsuited to, even if it's "technically" capable. I wouldn't build a website in native C, even though I know it's "technically" possible for example.
I have yet to work a day job in Rust, but I've worked in Java, C++ and Go so I'd be quite confident applying to a Rust position as long as it wasn't specifically security focused... I would be less confident in how quickly I could pickup Prolog - I think my brain works well for the nuances of the language but I'm less certain.
A lot of interns end up using php(symfony). If they know Perl or Java they can pretty much jump right in. Python they take a little bit though not much more.
When we started a Product B about nine months into my time there, the new team wrote new, well-designed code from scratch, and was also very productive very quickly.
PHP lets you easily shoot yourself in the foot, but it also gives you all the tools you need to leave your feet in very good condition, and it's not difficult to do that either.
"past mistakes" are almost inevitable problems - I've been on both sides of this - creating things which likely caused someone else problems (learning to be better at tests and docs) - and inheriting problems created by someone see ( learning to demand better tests and docs from others when possible).
"past mistakes" have little to do with the language. Recently worked with a large Java codebase spanning back more than a decade. There's plenty of mistakes that have been made. And... there's plenty of 'language shortcomings' around Java too (go back to Java from 15 years ago, lots of shortcomings).
I was on a team that picked node for a project; the whole thing failed. Should I blame it on the language, or the people who made bad choices?
Perhaps the issue is mostly around people/teams that either aren't very good or more to the point don't have a structure in place to guide them and help them get better.
I spent a lot of my career consulting as a mess cleaner, more or less, and even very smart people end up making a mess sometimes. Time constraints, shifting goal posts, all of it.
I’d say the worst thing I ever see, regardless of tools, is premature optimization getting in the way of everything else.
A "smart" and/or a "senior" programmer knows not to optimize prematurely.
But maybe I latched only on this one sentence and missed your point. Sorry if that's the case.
Meta-programming? Yes. Object-oriented programming? Meh. CLOS is nice, but not vastly superior to anything else. Something else? Depends on what that something is.