[HN Gopher] NJVL: Nim's New Intermediate Representation
___________________________________________________________________
NJVL: Nim's New Intermediate Representation
Author : generichuman
Score : 44 points
Date : 2025-10-30 01:44 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ebb_earl_co wrote:
| 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?
| BoingBoomTschak wrote:
| > 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?
| digdugdirk wrote:
| 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.
| plainOldText wrote:
| 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)
| elcritch wrote:
| 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.
| elcritch wrote:
| It's an interesting take on an IR. It's goal is to support the
| current C/C++/JS backend but also to make generating native
| assembly easy to do as well.
|
| 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.
| fuhsnn wrote:
| 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
___________________________________________________________________
(page generated 2025-11-01 23:00 UTC)