[HN Gopher] NIR: Nim Intermediate Representation
       ___________________________________________________________________
        
       NIR: Nim Intermediate Representation
        
       Author : michaelsbradley
       Score  : 60 points
       Date   : 2023-09-30 21:23 UTC (1 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | gorenb wrote:
       | I'm interested in how this made #2 of the front page in around 15
       | minutes.
        
         | michaelsbradley wrote:
         | The PR was created a couple of hours ago, and I saw it
         | mentioned in the Nim community's Discord server. I did _not_
         | mention in Discord that I submitted the link to HN, but I 'm
         | guessing a fair number of the participants there also browse HN
         | regularly, so that could be a factor.
        
         | PartiallyTyped wrote:
         | HN seems to like Nim and more _exotic_ (though not esoteric)
         | languages.
        
         | hifromwork wrote:
         | My guess is as good as yours, but it could be a moderator
         | action. Sometimes submissions are manually upgraded/downgraded
         | by moderators here (that would be dang).
         | 
         | Related:
         | https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
        
         | Uehreka wrote:
         | It's an article about programming on a website frequently
         | visited by programmers that was posted in the middle of a
         | Saturday afternoon (America time) when a lot of people have
         | read the front page already and might be looking at /new?
         | Doesn't seem so crazy to me.
        
         | suby wrote:
         | I like links like this because I like discussions on
         | programming languages which are just on the periphery of
         | mainstream. Nim, dlang, Odin, Zig, etc
        
       | davidthewatson wrote:
       | "No pointers, no cry" was worth the price of admission. There are
       | features and benefits here that seem magical. I may be
       | misunderstanding, but does this mean that you could compile
       | directly into containers like podman? That is, is the NIR parse
       | able as a container image?
        
         | jjtheblunt wrote:
         | A container image is essentially a generalization of a binary,
         | a folder holding the binary to run with its dependencies in a
         | format that docker/podman can read, unpack/uncompress, mount
         | the folder and thereby its contained dependencies and binary,
         | sets up unix accounting, and run the binary with its support
         | dependencies.
         | 
         | A compiler intermediate representation looks like a collection
         | of data structures that can be used to generate runnable code
         | either immediately as in an interpreter or saved for later use.
         | 
         | I think you've compared very different ideas.
        
       | unclad5968 wrote:
       | Theyre going to change the whole backend essentially just for
       | better not nil and static array bounds checking?
        
         | zem wrote:
         | that "just" strongly underestimates the value add of those two
         | features!
        
         | hashtag-til wrote:
         | Having a structured IR could make it pluggable to the MLIR
         | ecosystem, for example.
        
           | mathisfun123 wrote:
           | Just because it has IR in the name doesn't mean there's any
           | connection. If you want to emit MLIR using nim you can
           | already do this using MLIR's C API, if you want to map nim
           | ast to to existing MLIR IR you can already do this if you
           | provide the necessary control flow analysis, if you want to
           | map nim ir to MLIR you will still need a lowering or nim
           | dialect.
        
       | jadbox wrote:
       | I do really like Nim, being a sister to D lang with similar
       | benefits. The language wars feels like it's getting hotter
       | lately, and I'd live to see D/Nim make a comeback. If any
       | language is going to see new traction, it's going to need to be a
       | compelling alternative for Go/Rust/JS/Python/Java. I'm keeping an
       | eye on Zig here too.
        
         | elcritch wrote:
         | I _really_ enjoy writing code in Nim. The move to the new
         | memory management system turns it into a true systems-language
         | (comparable to C++ + SharedPtr 's or Rust + ARC's everywhere).
         | I've been working on a multi-threaded pure Nim GUI which runs
         | 60fps like a charm and compiles down to a ~3MB binary with no
         | deps outside the system UI libs!
         | 
         | The other part is that Nim's strongly typed and compiles to
         | native code but allows you to do dependent typing _like_ things
         | that lets you be flexible on types:                   type
         | X = object           Y = object           Z = object
         | NotXY = not (X | Y)              proc doSomething(_: NotXY) =
         | echo "hi!"
        
           | mathisfun123 wrote:
           | What is `object` here? Effectively a [?]?
        
             | elcritch wrote:
             | Nope, it's just an empty object, aka an empty C struct.
             | Generics would be like:                   type MyObject[T]
             | = object             val: int             other: T
        
               | mathisfun123 wrote:
               | I don't get it - if empty object doesn't act as a top how
               | does what you wrote demonstrate flexibility?
               | 
               | Edit: oh X, Y, Z are singletons I guess? Still don't see
               | the flexibility or dependent types?
        
             | auxym wrote:
             | It's effectively a struct with no members.
             | 
             | (Nim compiles to C, so in fact it compiles to exactly
             | that).
        
         | winrid wrote:
         | Just needs good IDE support. That's always the issue. Do not
         | like VSCode or the slowness of the Nim plugin. I think every
         | "goto definition" scans the whole code base instead of using an
         | index, so it's slow. I'm faster working in Java, verbosity be
         | damned.
        
           | michaelsbradley wrote:
           | You may fare better hooking VSCode to nimlangserver:
           | 
           | https://github.com/saem/vscode-nim#nim-lanugage-server-
           | integ...
        
       ___________________________________________________________________
       (page generated 2023-09-30 23:00 UTC)