NJVL: Nim's New Intermediate Representation(github.com)
github.com
NJVL: Nim's New Intermediate Representation
https://github.com/nim-lang/nimony/blob/master/doc/njvl-spec.md
9 comments
Nim seems to be almost a pet project of a single individual. Is that just my interpretation or is it an actual representation of reality?
If it is correct, and mostly created by one person - how? Are they a genius? Is creating your own programming language from scratch something anyone can accomplish if they just go for it?
Or is it just something that shouldn't be trusted/used for commercial purposes because it's not as "legit" as a newer language like rust for example?
It's just a weird vibe - it seems like it should be so much more popular than it is.
If it is correct, and mostly created by one person - how? Are they a genius? Is creating your own programming language from scratch something anyone can accomplish if they just go for it?
Or is it just something that shouldn't be trusted/used for commercial purposes because it's not as "legit" as a newer language like rust for example?
It's just a weird vibe - it seems like it should be so much more popular than it is.
The main designer is Andreas Rumpf, but investigating the git commits of the new Nim reveals more people being involved. [1] Whether Andreas is a genius, I have no idea, but he has been doing compiler and language development for over 20 years [2] so he's probably extremely knowledgeable regardless.
[1] https://github.com/nim-lang/nimony/commits/master/
[2] https://en.wikipedia.org/wiki/Nim_(programming_language)
[1] https://github.com/nim-lang/nimony/commits/master/
[2] https://en.wikipedia.org/wiki/Nim_(programming_language)
The BDFL Araq is the primary creator but there's a small team of paid core developers. There's also a number of open source contributors. So it's a commercial project as well. They offer support contracts too.
> If it is correct, and mostly created by one person - how? Are they a genius? Is creating your own programming language from scratch something anyone can accomplish if they just go for it?
Creating a compiler can be one by a single person. Maintaining it is harder, especially for commercial support contracts. That's where teams are needed, and Nim has that.
However a lot of the issues many languages is overcomplicated design. Nim is ardantly a pragmatic language. NJVL is an example of that.
> Or is it just something that shouldn't be trusted/used for commercial purposes because it's not as "legit" as a newer language like rust for example?
I say it can be trusted. It's survived ~20 years. Statistically it'll likely survive another 20.
I'd say it's not too different from Zig or Elixir on the compiler and language side. There's a number companies and open source projects using it.
Sure Rust is going to be bigger but also Rust is far more complicated as a language. Similarly for packages I found there's 10 crates of varying quality and incompatible. With Nim I can take something like Pixie for images and make an image finding library in a day that outperforms opencv without struggling with crates or dev compiler features.
Nim's used at Reddit, Status IM, and more. Especially with LLMS it's pretty easy to switch languages, to make support libraries, get devs productive, etc so there's much less risk these days IMO.
> It's just a weird vibe - it seems like it should be so much more popular than it is.
It should be more popular!
A few things hold back broader adoption IMHO. A big one is that it's a "European" language as Araq and team is European which sort of distances it from the SV and HN zeitgeist. There's a lot to "hype" factor. Nim has a more of a slow and steady adoption like early Python, IMHO.
Secondly it's just found it's niche by focusing on being a systems language with reference counted memory system with excellent metaprogramming. In the past things community issues arose, or lots of people disliked case insensitivity. Those issues have mostly settled though with case insensitivity being phased out.
LSP needs improvement. Nimony is designed to solve that.
> If it is correct, and mostly created by one person - how? Are they a genius? Is creating your own programming language from scratch something anyone can accomplish if they just go for it?
Creating a compiler can be one by a single person. Maintaining it is harder, especially for commercial support contracts. That's where teams are needed, and Nim has that.
However a lot of the issues many languages is overcomplicated design. Nim is ardantly a pragmatic language. NJVL is an example of that.
> Or is it just something that shouldn't be trusted/used for commercial purposes because it's not as "legit" as a newer language like rust for example?
I say it can be trusted. It's survived ~20 years. Statistically it'll likely survive another 20.
I'd say it's not too different from Zig or Elixir on the compiler and language side. There's a number companies and open source projects using it.
Sure Rust is going to be bigger but also Rust is far more complicated as a language. Similarly for packages I found there's 10 crates of varying quality and incompatible. With Nim I can take something like Pixie for images and make an image finding library in a day that outperforms opencv without struggling with crates or dev compiler features.
Nim's used at Reddit, Status IM, and more. Especially with LLMS it's pretty easy to switch languages, to make support libraries, get devs productive, etc so there's much less risk these days IMO.
> It's just a weird vibe - it seems like it should be so much more popular than it is.
It should be more popular!
A few things hold back broader adoption IMHO. A big one is that it's a "European" language as Araq and team is European which sort of distances it from the SV and HN zeitgeist. There's a lot to "hype" factor. Nim has a more of a slow and steady adoption like early Python, IMHO.
Secondly it's just found it's niche by focusing on being a systems language with reference counted memory system with excellent metaprogramming. In the past things community issues arose, or lots of people disliked case insensitivity. Those issues have mostly settled though with case insensitivity being phased out.
LSP needs improvement. Nimony is designed to solve that.
The tree-like syntax interested me but unless this new layer enforces it, there's no guaranteed evaluation order among its backends[1], which IMO kind of defeat it's usability as general purpose IR.
[1] https://github.com/nim-lang/nimony/issues/792
[1] https://github.com/nim-lang/nimony/issues/792
That's an important point you make. A closer-to-SSA IR would have helped in the provided example by forcing the function calls to be completed before their return value being passed to the principal function. I'm surprised Araq dismissed this concern.
I am really only familiar with Python, in which I’m pretty sure that the .py becomes .pyc and then CPython translates .pyc into machine instructions.
How does this differ? Is an IR the same idea as Python’s .pyc?
How does this differ? Is an IR the same idea as Python’s .pyc?
> and then CPython translates .pyc into machine instructions.
What do you mean? CPython is a bytecode compiler and a virtual machine interpreting that bytecode. Or are you talking about the new experimental JIT?
What do you mean? CPython is a bytecode compiler and a virtual machine interpreting that bytecode. Or are you talking about the new experimental JIT?
strictly speaking bytecode isn't IR because typically it's not further transformed - IRs are designed to be further transformed. as with all things these aren't hard and fast rules (plenty of compilers run transformations on bytecode, and there are plenty of interpreters for some IRs).
It also doesn't rely on lexical scopes to do analysis for things like lifetimes, nil tracking, destructors, etc. Instead it uses the versioned variables AFICT to enable those features more directly. Should be much simpler for the compiler implementation for 99% of cases versus traditional SSA blocks.
Unfortunately I'm busy writing Nim code and not able to play with the new Nimony compiler framework. I'm excited about incremental compilation and borrow checking features though.