I do all my work in Python, and I've been using Nim in last couple of months - it took me a week or two until I was able to be productive in Nim.
Don't expect Python's large ecosystem, nor some Python goodies, but if you're looking for a readable, writable, high-performance post-Python language - Nim is the way to go!
No, Python was invented at a time when its closest competitor was Perl - and you need only compare typical Perl with typical Python to appreciate that Python really was a usability revelation.
But that was nearly 30 years ago. I do think we can do better now.
• the language is consistent (everything is an object, or a pointer to an object rather, you can only pass by pointer, scope and namespace that make sense all the time, etc...)
• you can learn it gradually, you can start using it even if you know only 10% of the language
• Amazing documentation. The official tutorial is easy to read, and by the time you are through with it you are fairly proficient with python
• error message that tells you exactly what the error is and where it is happening. A lot of other languages do that now, but that wasn't the case 25 years ago.
• inline help / magical docstring (`a=4 ; help(a)`)
• The REPL, especially being able to get into the REPL with your apps (`python -i`)
• batteries, again 25 years ago, no language came with such a huge standard library
• PEP 8, the grandfather to gofmt and rustfmt. Makes a big difference when working on a team
• the Zen (`import this`)
And of course as the language grew in popularity:
• the ecosystem (pypi.org)
• the amount of resources, from books to website, the answer to every questions you can think of in SO, very active and helpful mailing list/usenet group, active and helpful /r/Python
for foo in bar:
pass
# Why is "foo" in scope here???Block and function scoping both "make sense all the time." Whether or not you personally are accustomed to a language's design decisions does not have any bearing on whether or not those decisions "make sense."
In the particular case you cited, of course it is natural that `foo` is in scope outside of the loop; it appears in a line outside of the loop. This is trivially evident in the indentation.
For that, it matters whether they're coming from another function-scoped language (or are familiar with one), and whether they're used to having their variable declarations being obvious or not.
For me, when I was first learning Python, this scoping issue was a significant pain point. This is obviously an anecdote, not data, but again for purposes of "people first coming to the language" it's relevant.
Obviously once one has worked in Python for a while one internalizes things like this, just like one internalizes various things in other languages that are obvious pain points for beginners.
For the case of experienced programmers, the behavior is consistent and simple. In what way does this not "make sense?" Does Haskell's normal order evaluation not "make sense?" Does Ruby's optional parentheses for method calls not "make sense?" Does a regular expression literal syntax not "make sense?" Does JSX not "make sense?" Do public/protected/private modifiers in Java not "make sense?"
Stop confusing a match to your personal comfort zone for actual quality or fitness-for-purpose.
Let's look at our example again:
for foo in bar:
pass
# Why is "foo" in scope here???
Now I understand why that happens (in terms of what the loop actually desugars into), and you understand why it happens. But it's not as consistent and simple as you're trying to make it out to be. You have to really understand what a for-in loop is doing under the hood to explain the behavior.
You seem to feel that I'm attacking Python or something. I'm not. It's a nice language to work in, with a lot to recommend it. But it's not a language I'd choose as a poster child for scope and namespace making sense all the time unless you really dig into what's going on "under the hood".
> Does Haskell's normal order evaluation not "make sense?"
No opinion, really; not enough intimate familiarity with the problem space to have one.
> Does Ruby's optional parentheses for method calls not "make sense?"
Again, no opinion.
> Does a regular expression literal syntax not "make sense?"
It depends on the regexp. If your regexp is simple enough, it's fine. In far too many cases you end up with a write-only monstrosity. Also, you say "syntax" as if there were only one; there are multiple and some make more sense than others.
> Does JSX not "make sense?"
Again, no opinion.
> Do public/protected/private modifiers in Java not "make sense?"
It depends on how they're used.
> Stop confusing a match to your personal comfort zone for actual quality or fitness-for-purpose.
Stop confusing "doesn't always make sense" for "doesn't make sense" (totally different statements, there), and the former statement for a statement about quality of fitness-for-purpose. Lots of things are considered high-quality and fit for purpose while still having flaws. Possibly flaws that could not have been avoided without sacrificing other goals. But determining that requires first admitting that the flaws exist and then evaluating them. If we either pretend that the flaws don't exist, or that flaws existing is somehow an indicator that the entire system is unfit for purpose, it's hard to think productively about the design of the next system.
Maybe the ecosystem is the only reason left today. The reasons for initial adoption 25 years ago and the reasons for widespread usage today probably aren't the same reasons. Numpy, Anaconda & Jupyter notebooks didn't exist then, and now they're a huge reason for Python usage. I can't even think of a language that comes with a standard library that rivals Python's, let alone the ecosystem.
Because Nim syntax will be familiar to Python developer. Sometimes all you need to change is add variable declarations and rename `def` to `proc`.
Haskell has a much steeper learning curve. Been there, struggled with that. If I would recommend a functional language to Python developer, I would go with F#.
Why not Cython, which gives speedups in those ranges, is more familiar to Python developers and fully integrated into the Python ecosystem?
I like Python; I just wish I could say the same for its developers...
Including Cython. I mean, if you've got a C library, sure, interface it with Python; but unless you want something to be called from something else in addition to Python, dropping to C for performance needn't be the default choice in Python; that's the whole reason Cython exists.
> and a few (like Go) which offer better ergonomics than Python by itself
I find Go’s ergonomics to be worse than Python but better, mostly, than Java.
> all while besting it in performance by one or more orders of magnitude.
And, still, including Cython.
> I find Go’s ergonomics to be worse than Python but better, mostly, than Java.
This is surprising. I'm a Python developer, and I still prototype new features in Go.
You can do that in Nim - it compiles to C.
If you have no previous knowledge of C, with Nim you get C-like speed with Python-like easy to write syntax.