So, this is something that we've considered for a while now, after all these years writing production code in Nim, we long for Python's lack of static checking; in the end there is always a Nim code snippet that tests the part of the Nim compiler we touched anyway, the static type system doesn't speed up Nim's core development. Python is simply more productive to work in, especially considering its ecosystem. For example, we want to add machine learning to the Nim compiler, if the Nim compiler were written in Python, it would be as simple as import machinelearning.
However, it is well known that Python code can sometimes be slow if it's CPU bound. So these CPU bound parts of the Nim compiler will be written as Python extension modules in C. Writing a product in two vastly different programming languages allows us to use each language for the part where it shines, C for speed, Python for the glue code. The perfomance critical parts inside the Nim compiler are probably: The lexer, the parser, the semantic checker, the overloading resolution mechanism, the VM for macro evaluations and the code generators. Thankfully C is a well understood language with a friction-less type system, for example, I think we can get away with modelling the Nim AST in C via a single void* type.
We have been working on this in the last couple of months secretly and these improvements will be part of the upcoming version 1.2 release.
Writing performant code in C these days? How absolutely immoral! Have you considered our lord and saviour Rust? /s
Also, I love this part: "The perfomance critical parts inside the Nim compiler are probably: The lexer, the parser, the semantic checker, the overloading resolution mechanism, the VM for macro evaluations and the code generators. " --> that's the entire compiler right there boiz
"I think we can get away with modelling the Nim AST in C via a single void* type"
This one line killed me haha
I'm strongly opposed to that plan! While I fully agree that Nim (currently) does a lot of uncool stuff (e.g. static typing) I do not consider Python and C good choices. Instead of Python we should be bold and directly walk into where the future is: AI based image interpretation instead of Python, which while being widely liked still implements, pardon me, an old-school boring paradigm. We should not allow ourselves to be blocked by frankly meaningless dictums like a PL having to be "text based"! As for C I almost agree if it were not for the stubborn newer standards introducing anti-freedom stuff like "restrict" and, as I just learned by even GCC inventing "safety" devices like "access". Reason: All of that costs performance. Sorry, some might not like to hear it, but every check, every "safety feature", and in fact even superficial type checking costs performance either at compile time or at run time.
I do however fully propose our BDFL's plan to use void pointers and would infect strongly urge the Nim team to only support void pointers. No more nice and dandy - but performance hungry and attention demanding - integers, floats, and what not (let alone signed and unsigned!) but only 'ptr void'. If something can't be expressed by void pointers it's not worth to be expressed anyway.
today I don't eat fish (lolllll) on April 1st
rewrite all that in Python ........... and why not in gwbasic with the one opening on the assembler