78
submitted 1 year ago* (last edited 1 year ago) by popcar2@programming.dev to c/programming@programming.dev

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
top 50 comments
sorted by: hot top new old
[-] TechnoCat@lemmy.ml 14 points 1 year ago* (last edited 1 year 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.

[-] atzanteol@sh.itjust.works 10 points 1 year 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.dev 14 points 1 year 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 6 points 1 year 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 9 points 1 year ago* (last edited 1 year 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.

[-] bitcrafter@programming.dev 4 points 1 year 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".

load more comments (6 replies)
[-] BackgrndNoize@lemmy.world 3 points 1 year 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

[-] Joker@piefed.social 7 points 1 year ago

I thought we moved past that complaint 20 years ago. It’s not as if you won’t indent your code anyway.

[-] atzanteol@sh.itjust.works 8 points 1 year ago

We moved past it because everone realized it was a stupid idea. Rust, go, etc abandoned it and rightly so. It causes more problems than it's worth.

[-] bitcrafter@programming.dev 5 points 1 year ago

A more fundamental difference between Rust and Python is essentially that the former is expression-based whereas the latter is statement-based, so arguably you need delimiters for code blocks in Rust because an expression can contain a block that itself has statements in it, whereas there is (sadly) no equivalent in Python. (Having said that, even if this weren't the case, it would probably still have used curly braces for delimiters because it wants to look a bit like C++ to make it more palatable for that group, not because deep wisdom was involved.)

There are lots of things to not like about Python, but the lack of curly brackets that would just be redundant anyway is not one of them. You hardly alone in your opinion, but you are not speaking for "everyone" either.

[-] atzanteol@sh.itjust.works 4 points 1 year ago

I deal with the syntax on a daily basis though. Moving code around is objectively more difficult with Python since IDEs can't always know where the block should be tabbed to. Sometimes it is correct at guessing, sometimes not. And when it's not all I can think of is "why the fuck am I dealing with this?". It's a non-issue in proper languages. Just simply doesn't exist. The IDE there can know where things should be tabbed to. It's a problem created explicitly by the language syntax.

load more comments (1 replies)
load more comments (4 replies)
[-] FizzyOrange@programming.dev 2 points 1 year ago

Seems like they allow () code blocks too, so it's kind of the worst of both worlds...

[-] psycotica0@lemmy.ca 10 points 1 year ago
[-] Ephera@lemmy.ml 10 points 1 year 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 4 points 1 year ago

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

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

[-] FizzyOrange@programming.dev 9 points 1 year ago

I dunno I would say Lisp syntax is probably the worst option. Or APL style.

[-] bitcrafter@programming.dev 4 points 1 year 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 2 points 1 year 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 2 points 1 year 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.

load more comments (1 replies)
[-] who@feddit.org 10 points 1 year ago* (last edited 1 year ago)

I picked it up because I liked the syntax and systems programming capabilities. At least on the surface, it's fast and expressive.

My main criticisms of the language: the meta-programming features can quickly draw the programmer into unpleasant complexity, and the official docs don't make it easy to discover small bits of important info when you don't already know where to look. (And the latter problem makes the former worse). It's a work in progress, of course, and I believe these problems could be fixed.

I got productive with Nim in a month or two. I dropped it when I found that the BDFL is both routinely insulting to people, and hasty in closing legitimate bug reports. These are both big red flags in my book. I don't want to have to interact with him again, and I don't want any of my work to depend on him.

[-] FizzyOrange@programming.dev 9 points 1 year 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 5 points 1 year 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.

[-] msa2@mastodon.sdf.org 9 points 1 year ago

@communism @FizzyOrange Sometimes you want modern features and safety without the headache that is writing Rust. Rust is a complicated language. I just want something simple without a million footguns.

[-] FizzyOrange@programming.dev 4 points 1 year ago

Rust is fairly well known for not having footguns (except async Rust at least) and for not being a headache.

I guess it can be more complex than something like Python or Typescript though. I would say that extra complexity is not a big deal compared to the pain you'll have to deal with working with a language as niche as Nim though.

[-] msa2@mastodon.sdf.org 2 points 1 year ago

@FizzyOrange Footguns as in C. Headache as in rust.

[-] FizzyOrange@programming.dev 2 points 1 year ago

Headache isn't a word I'd associate with Rust. More with Ruby or Python (at least until uv mostly saved us).

[-] TehPers@beehaw.org 2 points 1 year ago

uv is love. uv is life.

I'm still trying to get people at work to use it. It's one of the few tools out there that takes Python from intolerable spaghetti to readable and maintainable.

[-] bitcrafter@programming.dev 1 points 1 year ago

I have found that conda proves to be

. . .

a fairly good

. . .

alternative to pip as well.

[-] TehPers@beehaw.org 1 points 1 year ago

conda isn't much of an alternative to pip. It's more of an alternative to venv. Unless you're referring to conda's dependency management, which I've admittedly never used.

And until pip uninstall foo uninstalls unused transitive dependencies too, you'll have to drag me back.

[-] communism@lemmy.ml 2 points 1 year ago

I'm not really sure what people mean by Rust being a headache/weird/hard/etc honestly. It was a learning curve but nothing crazy, and I've come to really like the ways Rust works—it makes my life way easier in the long run to be able to solve problems at compile time so I don't have to debug undefined behaviour at runtime. But to each their own of course—if another language works for you then it works for you.

[-] sus@programming.dev 2 points 1 year ago* (last edited 1 year 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"

[-] speq@lemmy.dbzer0.com 9 points 1 year ago

I like Nim very much. It's like Python to write in, very expressive and easy to read, but compiled. I think it's a very good choice for small utilities as well as systems programming.

What I don't like is some people in the project being dicks to others but I just use the language and try not to care about it.

[-] AstroLightz@lemmy.world 3 points 1 year 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 7 points 1 year ago* (last edited 1 year 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.dev 2 points 1 year ago* (last edited 1 year ago)

What the other person said. Cross compiling is as simple as adding a flag assuming you have the dependencies. I tried it and it works well (though my programs are pretty simple). See also the official docs on cross-compiling.

[-] Peereboominc@piefed.social 2 points 1 year 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.dev 3 points 1 year 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.

load more comments (4 replies)
[-] SlartyBartFast@sh.itjust.works 2 points 1 year ago

Scary movie

[-] BillyCrystalMeth@slrpnk.net 2 points 1 year ago

Never tried Nim, but I saw this on lobste.rs and thought of you: https://miguel-martin.com/blog/nim2-review

[-] insomniac_lemon@lemmy.cafe 1 points 1 year ago* (last edited 1 year ago)

I haven't done enough to consider myself a programmer, but I could've written your post. It hits a niche that I have long wanted from programming.

You should check out the Godot 4 bindings if you haven't already (gdext-nim, see my post on !nim@programming.dev). There's also one for Raylib (specifically, Naylib).

My biggest functional gripe (that I can say for certain is not just me) was that support for (Bellard's) TCC was dropped. It was nice for quick prototyping, though Clang is a pretty efficient middleground/default.

load more comments (3 replies)
load more comments
view more: next ›
this post was submitted on 31 Aug 2025
78 points (97.6% liked)

Programming

28356 readers
354 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS