> while the Nim compiler is essentially a community hobby project that has made the concept of a "compiled Python" a reality already. I checked out Nim a few y

> while the Nim compiler is essentially a community hobby project that has made the concept of a "compiled Python" a reality already. I checked out Nim a few years ago because I have a large Python project that I'd like to move to a compiled language. In my experience, if you get on the forums and do any kind of comparison between Python and Nim, you will quickly get responses of "Nim isn't Python, so quit trying to make it like Python". I think Nim would have been much more successful if it was more like Python, and if Python compatibility was one of its goals. Just as an example, a subrange a..b in Nim is closed on the right, unlike Python, and a..<b is the open Python version. They could just as easily have made a..b open and used a..=b for the closed interval, for Python compatibility. I'm not saying Nim had to be the perfect Python compiler and compile all Python code unmodified. Based on what I've read, Python is too dynamic for this. But in cases where there was the choice to either be compatible with Python or "do something unique", Nim often takes the unique path, and not always for any good reason IMO.