Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 2.2.6

nim-lang.org

Post reply on HN
Print view View original

31–40 of 98 posts

Re: Nim 2.2.6

#31

Post by juki »

pansa2 wrote: post #17
whalesalad wrote: post #13

Earlier quoted context omitted.

I have been meaning to explore Nim for a while because it feels like "golang, but python syntax and dev experience." I vibe coded a simple tool, tt, that allows me to track time to a central log from all my devices. Realllly simple: $ tt stats Time Tracking Stats Total entries: 39 First entry: Oct 21, 2025 23:04 Last entry: Oct 30, 2025 18:29 Tracking since: 228h 34m Days tracked: 5 $ tt "working on xyz today" Logged…

What are the `@` characters for? Are they what makes it feel like Perl? Because other than them I don’t think the equivalent Python code would look much different. Maybe more concise, e.g. you could replace the second section with something like `sorted = entries.sorted(key=lambda entry: entry.timestamp)`.

There are shorter options in Nim too, depending on your stylistic preferences

    let sorted = entries.sorted(proc (a, b: Entry): int = cmp(a.timestamp, b.timestamp))
    let sorted = entries.sorted((a, b) => cmp(a.timestamp, b.timestamp))
    let sorted = entries.sortedByIt(it.timestamp)
I suppose you could change the whole proc to something like

    proc groupIntoThreads(entries: seq[Entry], threshold: int): seq[seq[Entry]] =
      let sorted = entries.sortedByIt(it.timestamp)

      for i, entry in sorted:
        if i == 0 or entry.timestamp - sorted[i - 1].timestamp > threshold:
          result.add(@[sorted[i]])
        else:
          result[^1].add(sorted[i])

Re: Nim 2.2.6

#32

Post by zozbot234 »

Karrot_Kream wrote: post #30
pansa2 wrote: post #23

Earlier quoted context omitted.

> with the simplicity of Python So, not simple at all, then? Python is a very complex language hiding behind friendly syntax. Do you just mean “with the syntax of Python”? Or does Nim’s similarity to Python go more than skin-deep?

How do you find a simple language with abstraction? Pretty much all the "complexity" of the language is juggling its abstraction overhead. Whether that's Haskell's monad transformer stacks or Rust's Send + Sync. Given the space it's tackling I think Nim is a great effort and refreshing as it keeps a Python like syntax with a Pascal-like feel, which I feel is an underexplored evolution of languages.

Abstraction overhead is very much worth it for non-trivial programs. The "simpler" syntax of languages like Python is a one-time initial gain (and even then, it really only "saves" a tiny bit of boilerplate) that ultimately turns into a big drawback as programs grow more complex and your abstraction possibilities are severely limited due to an overly simplistic initial approach to the code.

Re: Nim 2.2.6

#33

Post by wmf »

tinfoilhatter wrote: post #8
synergy20 wrote: post #2

nim is memory safe, python syntax, emits c/c++/js. It really deserves more love and publicity. more mature than zig, much easier than rust.

It's too bad that the BDFL of Nim (Araq / Andreas) treats the language like his personal compiler development playground. This has led to a hard fork of the compiler, many experienced and frustrated developers leaving the community and language behind, and an extremely fragmented ecosystem. He is also very difficult to work with and isn't very welcoming to newcomers. The community "leaders" / moderation team is also…

Zig seems to be even more in flux than Nim yet people can't get enough of it.

Re: Nim 2.2.6

#35

Post by Karrot_Kream »

zozbot234 wrote: post #32
Karrot_Kream wrote: post #30

Earlier quoted context omitted.

How do you find a simple language with abstraction? Pretty much all the "complexity" of the language is juggling its abstraction overhead. Whether that's Haskell's monad transformer stacks or Rust's Send + Sync. Given the space it's tackling I think Nim is a great effort and refreshing as it keeps a Python like syntax with a Pascal-like feel, which I feel is an underexplored evolution of languages.

Abstraction overhead is very much worth it for non-trivial programs. The "simpler" syntax of languages like Python is a one-time initial gain (and even then, it really only "saves" a tiny bit of boilerplate) that ultimately turns into a big drawback as programs grow more complex and your abstraction possibilities are severely limited due to an overly simplistic initial approach to the code.

This sounds to me like you don't like Python's syntax and abstraction model more than anything else. Which is fine, there's plenty of languages out there.

Re: Nim 2.2.6

#36

Post by vintagedave »

tinfoilhatter wrote: post #15
cenamus wrote: post #14

Earlier quoted context omitted.

With hard fork do you mean the 2.x.x version?

Apologies for not providing a link! https://github.com/nim-works/nimskull is the hard fork I was referring to.

> The project was started as a fork of Nim … The overall language will be evolved into something entirely different and incompatible.

A hard fork with a goal of being incompatible _sounds_ more strong behaviour on the part of those who forked, than on the original language owner.

I’m sure there’s a lot of context I’m missing. But what is the story behind this?

Re: Nim 2.2.6

#37

Post by miguel_martin »

tinfoilhatter wrote: post #8
synergy20 wrote: post #2

nim is memory safe, python syntax, emits c/c++/js. It really deserves more love and publicity. more mature than zig, much easier than rust.

It's too bad that the BDFL of Nim (Araq / Andreas) treats the language like his personal compiler development playground. This has led to a hard fork of the compiler, many experienced and frustrated developers leaving the community and language behind, and an extremely fragmented ecosystem. He is also very difficult to work with and isn't very welcoming to newcomers. The community "leaders" / moderation team is also…

> language like his personal compiler development playground

re personal compiler development playground: I don't see this for Nim 2. Nimony/Nim3 is more of a "playground", but rightfully so: he is creating a new major version of the language and aiming to improve the architecture of the compiler.

> He is also very difficult to work with and isn't very welcoming to newcomers

I don't have full context on the drama behind the fork, but I don't see Araq not being very "welcoming". Araq replies on the forums very consistently, replying to new-comer questions, which one might consider as "simple questions". Araq will state his personal & honest opinions, which may come off as abrasive or "un-welcoming" in your opinion. I don't agree with everything he says but that's OK.

From what I can tell the fork seems to be due to differences in direction of the language and w.r.t working together: differences in communication styles. But again, I don't know.

Personally, I see no reason to use the fork (Nimskull) over Nim, nor would I ever see any individual or company picking up Nimskull unless they were very deeply familiar with Nim (this is a small population of people). From a skim of the Nimskull repo, there is no website (there is a copy of the Nim manual), no forums (just some chatrooms), no clear documentation on the future direction, no documentation on differences for someone not familiar with Nim, etc. - why would anyone pick up Nimskull unless they knew Nim well? Please take this as constructive criticism. e.g. if any feature of the language/compiler/tooling is "better" or planned to be better: highlight it, summarize the long GitHub issue/projects discussions in a blog, etc.

Re: Nim 2.2.6

#38

Post by miguel_martin »

jp57 wrote: post #10

Nim has a python-like syntax, but I wish they'd gone farther, using `def` instead of `proc` and a `print` function instead of the `echo` statement. Though even if they did those things, I'm not sure it would really feel like programming Python. As a long-time Python programmer, I was drawn to trying the language partly because of the syntax, but as soon as I tried to write something substantial, Nim's heritage in lan…

If your really want to use the keyword def instead of proc: you can do that with sed.

In all serious-ness, don't do that. I've used Python a lot, but Nim is a different language. Writing the proc keyword helps condition your brain to realize you are writing Nim, not Python.

Re: Nim 2.2.6

#39

Post by elcritch »

almostgotcaught wrote: post #27
netbioserror wrote: post #5

Earlier quoted context omitted.

It doesn't seem as exciting as those because it doesn't have a whiz-bang-pow killer feature (other than very robust metaprogramming), but it's very mature, and breezy to write high-performance software.

> other than very robust metaprogramming lol then i guess zig's comptime isn't a "whiz-bang-pow killer feature" either

It’s not really. Zig emphasis on it to replace generics is somewhat unique, but ultimately it’s not different than what Nim (and D) have also done for many years.

Nim has a full compile time VM. You can even compile it into a program to run Nim scripts.

Re: Nim 2.2.6

#40

Post by cb321 »

While it's ecosystem probably does not even match Julia's let alone Python's or the C/FORTRAN-verses, since Nim has been around for almost 20 years and publicly since 2008, there are still a lot of accumulated packages. Some are listed at: https://github.com/ringabout/awesome-nim for really a large (and even so still incomplete!) list of things you might be interested in. Hard to say how well maintained they are. That said, you do probably have to be prepared to do a lot of work yourself and work around compiler limitiations/bugs. Also, binding to C libs is very straightforward with a near trivial FFI.

I suppose it very much depends on the programmer & setting, but like 3 times I've looked for Rust projects similar to Nim ones and found the performance of the Rust quite lacking. Of course, any language that allows you access to assembly makes things ultimately "only" a matter of programmer effort, but the effort to get performance out of Nim seems very competitive in my experience. I've seen at least one ancient 1990s C project be more flexible and much faster in Nim at like 6% the LOC (https://github.com/c-blake/procs for the curious).

Post reply on HN