I’ve been researching programming languages to find a good, high level language that compiles to a single binary that is preferably pretty small. After tons of research, I landed on Nim and used it to make a quick txt parser for a project I’m doing.

Nim seems absolutely fantastic. Despite being sold as a systems programming language, it feels like Python without any of its drawbacks (it’s fast, statically typed, etc.) - and the text parser I made is only a 50kb binary!

Has anyone here tried Nim? What’s your experience with it? Are there any hidden downsides aside from being kinda unpopular?


Bonus: I want to give a shoutout to how easy it is to open a text file and parse it line-by-line in this language. Look at how simple and elegant this syntax is:

import os

if paramCount() == 0:
  quit("No file given as argument", 1)

let filepath = paramStr(1)

if not fileExists(filepath):
  quit("File not found: " & filepath, 1)

for line in lines(filepath):
  echo line
  • atzanteol@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    19
    arrow-down
    7
    ·
    13 days ago

    it feels like Python without any of its drawbacks

    Uses whitespace for code blocks though. I figured we’ve moved past that.

    • popcar2@programming.devOP
      link
      fedilink
      arrow-up
      10
      arrow-down
      3
      ·
      13 days ago

      I don’t get the hate for whitespace personally. It was maybe an issue 15 years ago, but modern code editors easily solve its issues. You can collapse whitespace blocks, the editor can automatically replace spaces with tabs, etc.

      • atzanteol@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        10
        arrow-down
        5
        ·
        13 days ago

        It solved a problem that didn’t exist and created problems that hadn’t previously existed.

        There’s a reason every python “intro” begins with “spend 20 minutes setting up an editor to deal with whitespace” properly.

        It makes moving code harder. It makes jumping around code blocks harder. Often the ide can help but sometimes it can’t.

        In any curly-brace language these are things I simply don’t need to even think about. But in Python it’s a pain.

        Yes it’s not the end of the world. Yes I can spend hours fine-tuning my editor. But… Why should I even have to? Why create these hurdles for no gain?

        • sirdorius@programming.dev
          link
          fedilink
          arrow-up
          6
          ·
          edit-2
          13 days ago

          No clue what you’re talking about honestly. I’ve worked on a 7 million line python codebase, and while python had tons of issues, whitespace was not one of them. You can easily move things around and have never seen a bug due to bad indentation.

        • BackgrndNoize@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          12 days ago

          20 mins setting up an editor, lol what fantasy world are you living in, I’ve been using Python for years never had to do much other than install some VScode extensions

        • bitcrafter@programming.dev
          link
          fedilink
          arrow-up
          5
          arrow-down
          4
          ·
          13 days ago

          I spend a huge amount of time working with Python and regularly do things like refactoring and do not run into all of this pain that supposedly exists, and never have. I think that you should stop speaking on behalf of “everyone”.

              • atzanteol@sh.itjust.works
                link
                fedilink
                English
                arrow-up
                4
                arrow-down
                1
                ·
                edit-2
                13 days ago

                The best argument I’ve heard for whitespace blocking is “it’s not that bad when you get your text editor configured”. That’s an excuse, not a reason.

                • hikaru755@lemmy.world
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  12 days ago

                  Idk know what editor you’re using, but it worked perfectly fine out of the box with IntelliJ. Nothing compared to the hassle of setting up a proper Eslint setup for typescript, honestly.

                  And I’m not trying to defend python here, I don’t touch that language except under duress, and I do prefer C-style code blocks as well. But this is kind of a pointless argument.

                • bitcrafter@programming.dev
                  link
                  fedilink
                  arrow-up
                  2
                  arrow-down
                  4
                  ·
                  13 days ago

                  A text editor that indents a block when you press “tab” is not hard to find and takes all of 30 seconds to set up.

  • TechnoCat@lemmy.ml
    link
    fedilink
    arrow-up
    11
    ·
    edit-2
    13 days ago

    I wrote a small program that hits a few NWS endpoints and prints out formatted to the terminal. I wrote it in fish, typescript, rust, and nim. Most of my experience is in typescript, rust, java, and kotlin. Nim was my favorite of the bunch. Some syntax things were not my cup of tea, but when you have programmed in so many languages it starts to not matter and feels more like lipstick.

    My biggest con with nim was that most of the nim libraries I came across are unmaintained and incomplete and undocumented. I think the language and toolset is pretty great though.

  • FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    8
    ·
    13 days ago

    I just use Rust for this. You can make the binaries fairly small if you put a bit of effort in. Plus it’s not a niche language, and you get the benefit of a huge community. And your code is pretty much fast by default.

    The only real downside is the compilation time, which is a lot better than it used to be but still isn’t great.

    • communism@lemmy.ml
      link
      fedilink
      arrow-up
      5
      ·
      13 days ago

      Yeah tbh I’m not sure what the reason for using a systems programming language other than either Rust or C would be. Rust by default for safety (and it’s as performant as any other systems language), C if you either need to work with an existing C codebase or want to be able to more easily do unsafe stuff. Or if you need to compile quickly. I’m sure the other languages have their benefits but not to the extent where I would both want to learn it and have use cases for it where I would choose that language over Rust or C for a project.

      • sus@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        13 days ago

        Nim is more “high level, automatic memory management by default, but you can go 100% manual if you need to”, though the reality of doing that is basically the opposite of rust’s “everything you need to do is well-documented and solid”

  • Ephera@lemmy.ml
    link
    fedilink
    English
    arrow-up
    6
    ·
    13 days ago

    I don’t have proper experience with it, I just built a small prototype with it back in 2021, to evaluate it for a project. But yeah, apparently these were my notes:

    Nim: Significant whitespace [derogatory], no interfaces/traits, imports throw random functions into scope like in Python (plays a big role with supposed object-orientation, as methods don’t get imported along with a type; they’re loosely attached and just imported along), somewhat ugly syntax

    Apparently, past-me wasn’t as big on the syntax. 😅

    But I can see why, because this is the code I wrote back then, apparently (I wanted to create a OS configuration framework à la Puppet, Ansible etc.):

    main.nim:

    import strformat
    import role, host
    
    let host2 = Role(
      description: "sdadsj",
      code: proc (host: Host) = echo "sakjd"
    )
    
    echo host2
    
    
    type Role2 = ref object of RootObj
      description: string
    method deploy(self: Role2) {.base.} = discard
    
    
    type KWriteConfig5 = ref object of Role2
      cheese: string
    method deploy(self: KWriteConfig5) = echo fmt"Deploying: {self.cheese}"
    
    
    let test = KWriteConfig5(
      description: "Deploy KWriteConfig5.",
      cheese: "cake"
    )
    
    test.deploy()
    
    
    let rolerole = Role2(
      description: "RoleRole",
    )
    
    rolerole.deploy()
    

    host.nim:

    type Host* = object
    

    role.nim:

    import host
    
    type Role* = ref object of RootObj
      description*: string
    method deploy(self: Role) {.base.} = discard
    

    Certainly some syntax elements in there where I have not even the faintest guess anymore what they would do…

    • atzanteol@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      9
      arrow-down
      3
      ·
      13 days ago

      Apparently, past-me wasn’t as big on the syntax. 😅

      You were right. Using whitespace for code blocks is literally the worst option.

        • bitcrafter@programming.dev
          link
          fedilink
          arrow-up
          4
          ·
          13 days ago

          Lisp syntax would not even necessarily be that bad if in practice people did not lump all of the closing parentheses in a place where it is really hard to visually match them with their respective opening parentheses so that it is hard to immediately see what is going on. (I have been told that the trick is to read the whitespace instead of the parentheses, but that does not actually help because the whitespace is not significant in Lisp!)

          • FizzyOrange@programming.dev
            link
            fedilink
            arrow-up
            2
            ·
            13 days ago

            Yeah I agree. Presumably they don’t do that though because you’d end up with pages of nothing but ).

            I never understood why they don’t add just a little syntactic sugar. You don’t need much to take it from a mess of brackets to something comprehensible.

            • anton@lemmy.blahaj.zone
              link
              fedilink
              arrow-up
              2
              ·
              12 days ago

              I never understood why they don’t add just a little syntactic sugar. You don’t need much to take it from a mess of brackets to something comprehensible.

              It was in the original design, but not the first implementation. By the time someone got around to it, people where used to S-expressions.

  • AstroLightz@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    13 days ago

    How is compiling Nim binaries compared to Python? I know on Python, the most common choice is PyInstaller, but that only compiles binaries for the type of system it is executed on.

    • sus@programming.dev
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      13 days ago

      Nim is a compiled language by default, and supposedly cross-compilation is usually as simple as

      apt install mingw-w64
      nim c -d:mingw myproject.nim
      

      though I haven’t really tried doing it (and my general impression of nim is anything “slightly obscure” like cross-compilation still has a non-zero risk of running into unexpected thorny bugs)

    • popcar2@programming.devOP
      link
      fedilink
      arrow-up
      5
      ·
      edit-2
      13 days ago

      The small binary part is just for fun - but generally my use case is to have an easy to use language that can cross compile easily so I can just pass binaries to the person I’m working with.

      • vermaterc@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        13 days ago

        I believe single binary compilation is not that uncommon these days. You can do that with Go or C#. Apart from obvious ones like c++.

        I mean, I don’t want to discourage you, but from my experience choosing not popular language is not a good Idea if you want to actually accomplish something