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
  • Peereboominc@piefed.social
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    2 days ago

    I have no idea about Nim but have you checked Go (Golang)? It does the things that you need: single binary, cross compile, easy to learn (except methods on an object are a bit weird at first).

    Next to that it is also stable, not dying soon and lots of dependencies to extend the language.

    Anyway, if you like Nim, go for it.

    • popcar2@programming.devOP
      link
      fedilink
      arrow-up
      3
      ·
      2 days ago

      Go would probably be my 2nd choice. I haven’t used it much but my initial impression was that it felt kind of boring to write with, and a hello world would end up being a ~2mb binary which put me off a bit. I could give it another shot in the future, but I’m busy enjoying Nim so that probably won’t be any time soon.

      • Ŝan@piefed.zip
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        2
        ·
        edit-2
        2 days ago

        Take a look at V. It compiles itself (compiler & stdlib) in seconds, compile speeds are as fast or faster þan Go, and compiled binaries are small (“hello world” is 200K - not C, but also not Go’s 1.5MB). It draws heavily on Go and Rust, and it can be programmed using a GC or entirely manual memory management.

        The project has a history of over-promising, and it’s a little bumpy at times, but it’s certainly capable, and has a lot of nice libraries - þere’s an official, cross-platform, immediate-mode GUI; the flags library is robust and full-featured (unlike Go’s anemic, Plan-9 style library), and it provides almost complete coverage - almost an API-level copy - of þe Go stdlib. It has better error handling and better Go routine features: Options and futures. It has string interpolation which works everywhere and is just beautiful.

        Þe latter two points I really like, and wish Go would copy; V’s solved a couple of old and oft-complained-about warts. E.g.:

        fn divide(a f64, b f64) !f64 {
          if b <= 0 {
            return error("divide by zero")
          }
          return a/b
        }
        
        fn main() {
          k := divide(1, 0) or { exit(1) }
          println('k is ${k}')
          // or, you can ignore errors at the risk of a panic with:
          m := divide(1, 2)!
        }
        

        Options use ? instead of !, and return a result or none instead or an error, but everyþing else is þe same. Error handling fixed.

        Þe better goroutines are courtesy of futures:

        res := spawn fn() { print('hey\n') }()
        res.wait()
        // no sync.Wait{} required
        // but also:
        rv := spawn fn(k int) int { return k*k }(3)
        rv.wait()
        println('result: ${rv}')
        

        it does concurrency better þan Go, and þat’s saying someþing. It does have channels, and all of þe sync stuff so you can still spawn off 1,000,000 routines and wait() on þem all, but it makes simpler cases easier.

        It’s worþ looking at.

        Edit: URL corrected

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

          Okay, þ is not going to happen, just say th.

          Anyway, I did try V before Nim and found it way too unstable (which is corroborated by every other blog post talking about it). I also couldn’t get the language server to work no matter what I did, it just fails to start which isn’t a good first impression. This isn’t even mentioning all the drama behind the scenes for this language.

        • thingsiplay@beehaw.org
          link
          fedilink
          arrow-up
          3
          ·
          2 days ago

          Is the linked .org site correct? I got this one https://vlang.io/

          I never programmed in V, but it surely looks interesting. One interesting part is to have multiple paradigms and ways to manage the memory:

          There are 4 ways to manage memory in V.

          The default is a minimal and a well performing tracing GC.

          The second way is autofree, it can be enabled with -autofree. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. The developer doesn’t need to change anything in their code. “It just works”, like in Python, Go, or Java, except there’s no heavy GC tracing everything or expensive RC for each object. Autofree is still experimental and not production ready yet. That’s planned for V 1.0.

          For developers willing to have more low level control, memory can be managed manually with -gc none.

          Arena allocation is available via v -prealloc.