Personally, I agree. I've never seen a bad team succeed because of a good language, and I've never seen a good team fail because of a bad one. We argue over languages not because it makes or breaks companies, but because that's the most obvious feature of our days. We form tribes around languages the way non-programmers do around sports teams, and as with sports teams, minor differences get blown up into major social divisions. It's our own version of the streetlight effect: https://en.wikipedia.org/wiki/Streetlight_effect
I'm all for people arguing about language features when they are actually designing languages. But as far as building businesses around software, I think "Language X is a secret weapon" is absurd. If a good team picks something they're happy working in, then the biggest problem with a project will almost never be the language they picked.
People argue about languages because they all have different trade-offs for performance/efficiency, initial development time, developer cost, developer availability, and maintenance.
The differences are real, and they have real effects on the profitability and the prospects of success/failure of any project.
Management quality and culture do too, obviously. But you can assume that for a given level of management competence, different languages will still create different business outcomes.
My guess is no, because people make fine businesses out of nominally unscalable technologies all the time. Rails is a notorious performance pig, for example, but there are plenty of successful businesses built in it. When server bottlenecks become an issue, modest performance tricks and ops magic are applied, and suddenly per-server performance is no longer the problem. And still, despite being a pig, Rails is a great place to start, because its real power is not CPU efficiency, but ease with which you can get something workable up and then iterate.
There is no language that is so fast that it's infinitely scalable out of the box. Every software company that grows hits performance problems with naive uses of the tools at hand. Every successful one figures out how to make things work. And making technologies serve the human purpose at hand isn't a characteristic of good languages; it's a characteristic of good teams.
The biggest issue, might be one that (sadly too) many low-level languages share: with the move to UTF-8 as the only sane choice for text, there are no string/char datatypes any more. No reason one can't use procedures/functions to deal with strings in assembly, but it would require a bit more planning than in a language that have "native" UTF-8 support.
[ed: I think Kollibri OS proves both points: it's a working OS, but they've yet to port from 32bit to 64bit even though they upstream they forked from (Menuet OS) has a 64 bit version (that's not Free software/open source).
Another "big" asm OS project is: https://github.com/ReturnInfinity/Pure64 ]
To buy you what? Not even what the Java SDK has as built-in libs. And 5 kloc in "several days"? I doubt it.
>And then I can build a compliant JavaScript implementation on top of this, in order to be able to parasite on 200k npm packages (actually, did this already).
Link or it didn't happen.
Besides, there's no point in using Forth if you're gonna end up running your stuff in a "compliant JavaScript implementation" (which takes much more than "several days" anyway).
To get a powerful core language on top of which I can build anything in just a couple of hundreds of lines (e.g., a complete JavaScript - in order to get the rest of the libraries for free). Or a JVM. Or .NET CLR. Or whatever else.
> And 5 kloc in "several days"? I doubt it.
I did this as an experiment once. From bare machine code on a new architecture, via a very basic Forth, to Lisp and then C and everything else. Did not take much time to do.
> Link or it didn't happen.
Did not publish it yet for a variety of reasons, but may include this JavaScript compiler in my next code drop soon, stay tuned (see my github).
> Besides, there's no point in using Forth if you're gonna end up running your stuff in a "compliant JavaScript implementation"
The question was that having only Forth would not leave me crippled - I'll get all the power I want in just few days. And this kind of JavaScript implementation is more than just JavaScript. It allows me to use anything coded in JavaScript seamlessly from any other language built on top of the same meta-language.