For me, the ecosystem matters as much as the language itself these days (actually more). There are languages that I've used at home just as a learning experience, but ideally, I want a language that I can put into production at work. That means quite a list of criteria: only a small number of languages have a well-supported AWS SDK, for example.
I won't say that Go is mainstream yet, but it feels very "production-ready" in those respects.
I'd say that simplest "production-ready" criterion is this: does it have an officially supported and stable release of a IntelliJ IDE (there is a slight Java-ecosystem bias, but I think it's only slight).
So the mainstream languages are...: C/C++, C#, F#, Go, Groovy, Java, JavaScript, TypeScript, Kotlin, Objective-C, PHP, Python, Ruby, Scala, SQL, Swift, VB.NET (source: https://www.jetbrains.com/products.html).
So, from the top of my head, Erlang, Haskell, OCaml, Perl, Fortran, Cobol and any type of shell script is not production-ready. Nice to have that clarified. :P
I wish that I knew a phrase to mean "has all of the documentation, tools, and libraries that are needed for an average team of developers following common practices to be likely to successfully ship and effectively maintain commercial projects, consistently".
Many really interesting languages and frameworks don't pass this criteria. It doesn't mean that they are a failure: the idea of programming languages that are designed for teaching or research, and are specifically not for commercial use, perhaps used to be more common than it is now.
I'm the opposite; I don't stick much time into learning a language if it doesn't have a high quality vim plug-in and command line tooling. It's fairly shallow, but I want to learn how things work behind the scenes, and I don't like fighting the editor over my preferences. It's a lot of small things, but why not enjoy your hobby time? This is just my personal preference and I understand and respect that there are lots of folks who enjoy their IDEs like I enjoy vim/Unix.
> So the mainstream languages are...: C/C++, C#, F#, Go, Groovy, Java, JavaScript, TypeScript, Kotlin, Objective-C, PHP, Python, Ruby, Scala, SQL, Swift, VB.NET
Of those 18 languages, only 13 are in the TIOBE top 50. Two of them (Apache Groovy and TypeScript) don't appear in the TIOBE top 50 so it's pushing credibility to call them "mainstream" languages -- the Java-ecosystem bias is more than "only slight".
Slight nit, but I don't think it's accurate to say that Go has an "officially supported and stable release of an Intellij IDE". While Gogland is excellent (I use it as my main Go editor at work), I think it's still technically in pre-release.
On a more unrelated note, is Groovy widely used? As someone who doesn't really ever use JVM languages, my impression was that it didn't have the similar usage to Kotlin and Scala, although I might be mistaken.
Apache Groovy's used for scripting on the JVM, like Bash and Perl on Linux. It's OK for glue code, mock testing, and 10-line build scripts in Gradle. But 5 years ago, some of Groovy's backers tried to re-purpose it as a competitor to statically typed languages like Java, Kotlin, and Scala, which is when things went awry. If it had stuck to its knitting, it could have been used widely for scripting classes written in Kotlin and Scala as well as Java. But it didn't even keep up with Java -- it doesn't even have Java 8's lambdas on the eve of Java 9's release.
Django's ecosystem has spoilt me so much that it's very hard to switch to another language, at least as far as web apps are concerned. I would love to play with Rust/Nim more, but most of the side-projects I'm passionate about involve at least a few things that Python has a lib for that would be a huge time sink to rewrite in another language.
> This is an experiment for running Nim code on the ESP8266 ("NodeMCU") microcontroller. The end goal is an extendable framework on which to build autonomous ESP8266 applications, along with an associated web service which acts as a base station providing back-end message aggregation and front-end information display/control panel.
These days I mostly do web, so Django and the whole ecosystem are just missing from Rust, but I'd settle for just the ORM. I found Diesel pretty hard to get started with, unfortunately :/
My other hobby is microcontrollers, and I would love it if I could run Rust on my ESP8266. I can already run MicroPython, but it feels a bit hacky (probably unfairly), and it would be amazing if I could use Rust and easily link in all the C/C++ libraries the Arduino framework has available.
I know this reply isn't useful (I miss all the libraries, woo), but it's as specific as I can get. I started a very simple website uptime monitoring service:
Yeah, Diesel is tough; they're working on better docs which should help out quite a bit.
IIRC someone is working on the ESP stuff...
> I know this reply isn't useful
Naw, it's all good: it's just as much about qualitative as quantitative. It's also because I'm writing a small framework in Rust in my spare time, so "rust for web" stuff is extremely top of mind for me. Thanks for taking the time :)
> they're working on better docs which should help out quite a bit.
That'd be great, because I currently can't find a niche where Rust is so much better than Python that I won't just fall back to that, impeding my Rust progress.
> IIRC someone is working on the ESP stuff...
That's what I heard too, but progress seems stalled. Hopefully, in the end, it'll be easy to run on the ESP, but the biggest problem is the ecosystem (which is also much of the reason why I don't use micropython all the time). There are so many libraries for the Arduino framework that C is hard to escape.
I won't say that Go is mainstream yet, but it feels very "production-ready" in those respects.