Yes, it clearly has a sharper learning curve than Python. But I think idiomatic Rust feels a lot like a good Python implementation of the same thing would, in ways I can’t quite explain. The borrow checker is certainly something to come to grips with, but it also nudges you to write code the way you should probably be writing it anyway. Don’t pass complex structures around and mutate them everywhere. Don’t return 5 kinds of object from the same function. Don’t go crazy with inheritance vs plain, understandable, testable functions.
Ruby is probably the most-similar popular language - a good choice for small projects/prototyping/exploratory programming. Personally I'm still using Python for this, but I'm basically still writing Python 2.7 (plus f-strings).
For larger projects, Go seems to follow the "Zen of Python" better than Python itself nowadays.
If you have access to f-strings then you have had to change quite a few things that are mutually incompatible between 2.x and 3.x. Perhaps you feel like your Python 3 code (which requires at least 3.6) is "basically still 2.7" because you aren't using things like type annotations (and actual tooling to check them), or the walrus operator, or the match statement. But all of these things are entirely optional, and plenty of people feel that they're actually un-Pythonic.
> you have had to change quite a few things that are mutually incompatible between 2.x and 3.x
I made those changes while still targeting 2.7: around 2018 I was writing code for 2.7 that was forward-compatible with 3.x, as was common at the time. Since then, f-strings have been worth adding to my toolbox - most of Python 3's other new features haven't been.
At this point, there are good solutions to most of the problems. It is just hard and awkward to avoid the standard library bits and the common tools (e.g. use uv instead of pip, requests instead of urllib, pytest instead of unittest, marimo instead of jupyter, trio instead of asyncio...).
Of course having a "batteries included" language where the batteries hurt you is not great.
Nim is often recommended as an alternative to Python, but how similar is it? I know it has Python-like significant indentation, but I'd have thought syntax is the least important consideration when choosing a language?
To be honest, the similarity is skin-deep only:
* Python: VERY dynamic, interpreted, interactive
* Nim: Static typing, compiled, non-interactive ("inim" gives it a good try tho)
That said, Nim has great metaprogramming facilities, and one of its similarities with Python is that it requires very very little scaffolding to get your program going. Unlike Java, or C, you don't need to write up classes and functions, it can literally be just a straightforward script written in Nim and it'll compile an executable from there.
It also has great modularity, so you can split up your solution into whatever makes the most sense to you.
So... I think the best way is to try it.
I'm pretty sure that if you like Python you'll like Nim.
This answer's @pansa2's question in a way that more leans on one aspect of Nim's greater syntactic & code transformation flexibility (which is great!), but I suspect pansa2 was more interested in differences in "idiomatic Nim" from Python for which there are more details here: https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programm...
