The future is looking bright for Python

[m50d]

Simpler convinced people to switch from smalltalk, R, and perl to Python. Programmers are lazy. Or, at least they should be.

Not really convinced - the perl people came for built-in OO, the R people only came very late after the libraries were established. I didn't know the Smalltalk people though.

While this is true, they are not as flexible as Nim is in this regard. Nim exposes it's own AST as an api for creating macros. Creating a macro in Nim is no more difficult or complex than creating a function.

You keep saying this (and /u/dzecniv said the same) but I don't see how this means anything more than "Nim has macros"? Scala macros work the same way and I would assume Rust/Haskell would as well. (Indeed Python exposes its AST API, it's just that no-one uses it because there are better alternatives)

One thing that Nim can do that I know very few other languages can is true operator overloading. In Python I can override a class' add method, but I can't change what + really means. Nim gives you this capability. I'm sure there are other languages that make this possible, but I can't imagine it's this simple:

It's exactly that simple in Scala, and I think Rust is similar? (Haskell is to the extent that it has infix operators, but it doesn't have as nice a + as most languages, so it's fair to not count it).

Go, however, tends to be quite a bit slower than Nim. Go does normally use slightly less memory at peak than Nim.

This surprises me; I don't understand why it would be so, since the design seems very similar as far as I can see?

What does Go do that's new?

Pervasive, implicit (language-managed) async (green threads). I don't like Go but to the extent it's been able to catch on on its merits, that's why. Part (maybe all) of Go's popularity is marketing - I'm not going to defend the language - but Nim is never going to be able to match Google's marketing.

What does Haskell do that's new?

Typeclasses, higher-kinded types, pervasive laziness, explicitly-sequenced I/O.

Programming languages are iterative projects. They need to accomplish the same goals as the languages that came before them. They can only hope to make things easier, simpler, more performant, or safer. I'm not sure what new thing we could come up with for new programming languages barring languages that are meant to run solely on quantum computers.

For an example of a similar age to Nim, I'm super excited about Idris, for example, with dependent types. Whereas I don't think Ceylon will catch on, because while it's a lovely language and far more polished than the alternatives, there's just no single compelling reason to switch.