Yes, seems others are also waiting for Nim to get more traction before they start using it.

I fantasize about creating an auto-translator to make any Python package available as a Nim library. Then anyone who thinks "I need Python but faster" would have an easier time trying it out.

But first I should probably leaen Nim! Have just been admiring from afar.

My experience learning Nim is that it's more fiddly and less elegant than Python. The OOP syntax in particular could be streamlined a lot (the Nim by Example macro code demonstrates this). In addition to learning the basic syntax, there are a fair amount of features implemented as pragmas; there's some important things like {.base.} mixed into this sort of junk drawer of stuff. They often felt sort of like an afterthought to me.

Most of the perceived "fiddly" parts of Nim are due to it being statically typed and compiled, in my experience.

Nim intentionally gives you very spartan objects. It is by no means an OOP-first or even an OOP-heavy language. The object type is little more than a storage container for named values, and should be treated as such. There is no magic like what you get with Python objects.

I've said it before, but the frequently thrown around, "it's just like Python but typed and compiled" has probably been a net negative for the language. It is syntatically similar, but once you get beyond those initial appearances it is a very, very different beast. So if you try to write Pythonesque Nim, you're not going to have a good time with it. It's no different than trying to write JavaScript like Python - they're just different languages that don't work the same way.

The macro chapter in Nim by Example is a good tutorial for writing a macro, but I don't know that it's a big improvement. For the most part, it just allows you to remove the `self: ObjectType` from methods that act on an object. I guess that's okay? But even Python makes you include the `self` in class methods.

I like Nim’s “missing postfix syntax”. You can get the feel of OOP when calling procedures without really using OOP.

https://nim-lang.org/docs/manual.html#procedures-method-call...

Nim is first and foremost a procedural language like Go, if you use it as a better Go you'll have a great time, if you try to make Nim more OOP you can use libraries like: https://github.com/bluenote10/oop_utils to make it easier.

Besides that Nim uses UFCS, you can mimic 90% of your OOP needs without using pragmas or methods or anything like that.

I totally believe that. I guess what I really want is high-performance Python. On the other hand, Nim has some years to go before it's mature.

Something like this? https://github.com/yglukhov/nimpy

From the Readme, Nimpy is a language integration tool that lets you call Python from Nim. It also links to Nimporter which allows you to import Nim code as a Python package.

What I'm describing would be the inverse of Nimporter, allowing you to import Python code as a Nim library (without making Python calls). That way, you get the performance of Nim but the years of Python package development. "Transpiler" might be a better word?

I've never worked on anything so difficult so I'm really just spitballing. But... wouldn't it be cool? :)

Ah yes, I misread your intent. That would be very nice to have. There is this breakdown of features[0] present in Nim compared to Python which might be helpful when doing this.

[0] https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programm...

It's already been done! https://github.com/Pebaz/nimporter

see my response to another comment. I think Nimporter is for bringing Nim code into Python, basically by making calls from one language to another. I'm talking about a Python to Nim transpiler, so that the functionality of Python is brought into the performance and under the control of Nim.

Tell me if I'm wrong.