I won't say that Go is mainstream yet, but it feels very "production-ready" in those respects.
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).
Sounds about right :)
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.
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.
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".
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:
https://gitlab.com/stavros/panoptes
I didn't get very far before the difficulty of integrating Diesel just stalled the whole thing.
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 :)
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.
One of the advantages of compiling to C and C++.
> 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.
The thing that eventually makes me grab Go time and time again is how damn easy it is to drop into code of some library - even (and maybe especially) the standard library, something I rarely did or do in any other language. With Go there's little friction to do this, for multiple reasons. The source of truth for pretty much any project is almost exclusively Github, godoc.org documentation has links directly into the source-code for every single function and struct, and it forces you to set up a dev env that let's you understand it's structuring, where your libraries and it's code will end up. About the last part I had some mixed feelings at first, but after a while you appreciate it that the libraries you're using aren't tucked away somewhere in some system directory. Add to that that Go is a simple, pretty readable language, and you end up with a very transparent library system. Would I ever even think about jumping into the paramiko library (which I used on multiple occasions)? Not at all, so I didn't. The first time I used the crypto/ssh lib, I also didn't think about jumping into the code, but somehow, I did because it was the natural thing to do, and made me understand the internals and SSH a lot better (paramiko was slightly easier to get started with though).
Another thing I really like is that the language encourages not writing 'applications' but rather libraries that can be reused by virtually anyone, and your final application will be a relatively small front-end shim for it. While this is not hard in Python, creating a separate library for smaller stuff somehow always felt as overhead, while in Go it feels like the natural thing to do. In python, there's yet another ton of overhead if you want to add something to PyPI - while in Go it's a `git push` away. This also creates serious issues and pitfalls, but it makes contributing a library a lot easier.
note that it is possible to pip install from git repos and it's actually very easy. you're just not expected to have to do that :)
[0]: https://nim-by-example.github.io
Wow. That's cool. I'll have to look into this.
The experience so far has been outstanding. Nim has functioned flawlessly with a minimum of magic. It seems to work very cleanly and the compiler is cleanly integrated, but still swappable (ie between gcc, clang, ming..) Nicely color-coded, too.
Exceptions are caught with full tracebacks, and pre-compile checks quickly point out exact location of syntax errors. (Good, clear error messages are surprisingly missing from many languages.)
Here's an awesome example; in my first day of coding, I was able to replicate python's "+" string concatenator ("hello" + "world" versus "hello" & "world" in Nim) with a one-liner:
proc `+` (x, y: string): string = x & y
This is pretty amazing; not only is it readable and concise (and more than a passing similarity to python's lambda, of course) but nim comes with the ability to define new operators right in the language, and the compiler raises an error if operators, procs, types, etc would introduce ambiguity.Nim compiles quickly and its type inference (where it guesses what type of variable you're working with) makes strong typing mostly painless, and you still get all of the advantages (type safety, speed) of static typing.
There are some trade-offs that are made (obviously), but the language designers seem to make trade-offs in favor of speed and robustness over language features -- but this still leaves a lot of room for features.
I also like how the syntax has a lot of similarities to Python's. The only thing I've missed so far is a nim interpreter, so that I can get up to speed faster on the syntax or try things out quickly. The tutorial on the Nim website is definitely not for beginning coders (who would probably be quickly scared off by words like lexical), but it quickly covers the language syntax for experienced coders and seems to borrow a lot of the best ideas from other languages.
Nim is basically awesome. The few downsides are that the standard library is still pretty light (but that gives you an opportunity to build something great and have it be widely adopted), that there's no interpreter, and that the tooling is still a bit lighter than older languages. All of these will be improved with time.
And, it's fast. Really fast. Compare nim in these benchmarks[1] to any other mid-level (or even low-level) language and it really shines. It's generally much faster than Go, for instance.
template `+`(a, b: string): string = a & b
But probably C compiler is smart enough to inline your proc :)Try running `nim secret` on the command line, it's not perfect but it's enough to play around a bit.
There are some companies using Nim, but they're not in this list
I remember that debugging it was a bit of a pain if just not a real option then. Maybe things have changed.
Out of curiosity: You use Nim professionally? Do you work for a company? What kind of software do you make? And what sort of people or organizations are your customers?
I wonder if python 4 could make this happen.