6 ms·

I am ... confused by Nim a bit. Nim on the surface has a dream set of features: python like syntax, strong types, compilation to C, good garbage collection, goo

I am ... confused by Nim a bit. Nim on the surface has a dream set of features: python like syntax, strong types, compilation to C, good garbage collection, good metaprogramming... OTOH there seems to be a rapid accumulation of features. The language wants implement the "next shiny thing" (e.g. ownership ala rust) or at least that is how it appears to me from the outside. For those people using Nim -- how do you cope with the ever increasing scope of the language? Isn't there a possibility that things aren't going to be well baked/abandoned? I like the philosophy of evolving your language slowly and consolidating before adding newer and newer features. Do you think the pace of change in Nim is OK?

anaphor 6y ago
A lot of the things you mention are pretty self-contained (you have to enable specific compiler flags), or they're implemented using the macro system or templates, and so in theory at least it's not bloating the compiler. Compared to something like Haskell (GHC), I think Nim is pretty lightweight and not too bloated.
kbd 6y ago
> OTOH there seems to be a rapid accumulation of features... I think you're stretching your narrative a bit. They're working on a new GC algorithm that (if you watch Rumpf's very interesting presentation[1] on it from today) is a significant performance improvement over their current GC. What features are you referring to regarding the "ever increasing scope of the language"? [1] https://www.youtube.com/watch?v=aUJcYTnPWCg https://www.youtube.com/watch?v=aUJcYTnPWCg
- sidkshatriya 6y ago
  It is an impression (possibly an unfounded/unfair one) and the whole point of my question is for others to give me their opinions. Nim is certainly a feature-full language. Look at the left sidebar on https://nim-lang.org/docs/manual.html https://nim-lang.org/docs/manual.html and you will see a lot of things listed! I wonder how many of those features work well with others, how many work partially and how many are somewhat abandoned. I'm looking to add Nim to my arsenal in the future. I'm positive on the language -- please don't misunderstand. I just wanted some opinions!
  - planetis 6y ago
    Everything that is new or was causing problems, moved under expiremental https://nim-lang.org/docs/manual_experimental.html https://nim-lang.org/docs/manual_experimental.html These are the features you are describing, the ones needing more refinement.
    - planetis 6y ago
      stuff like concepts and code reordering are planned to eventually became stable. Nowadays everything is decided in the RFCs repo https://github.com/nim-lang/RFCs/issues https://github.com/nim-lang/RFCs/issues before a PR hits the main repo.
  - kbd 6y ago
    > Look at the left sidebar... Look at the Go language manual for comparison[1]. Go is simple (some would argue, simplistic) and there's a lot there too. Programming languages are complex beasts. "Number of things in the sidebar of the manual" is a poor way to judge a programming language. > I like the philosophy of evolving your language slowly and consolidating before adding newer and newer features. The Nim book[2] came out in 2017 and the language has maintained compatibility with it through their 1.0 release. Nim seems pretty stable and "well baked" to me. One of the awesome things about Nim is that many features in the language can be implemented through macros. (AFAIK their async/await feature is implemented in Nim itself through macros.) So, I get the impression that Nim has a very solid core and builds things on top of that core. The fact that they can implement Rust-style move/borrow semantics without significantly changing the language is a really good sign to me of the language's power/design. Personally, I wish Nim was what we were all using instead of Go. Nim has all the strong typing features (like generics) that Go is still working on, while also having the equivalent of goroutines and channels (though I haven't played with those in Nim myself yet), pleasant syntax, strong metaprogramming features, very strong operator overloading that helps make it suited for domains like data science, can generate a static binary, and on and on. I'd strongly recommend everyone take a look :) I'm personally psyched that a repl (INim) is being worked on (and works now), because a good repl is something I really value in a language. There's a short presentation about it from today's conference as well[3]. The fact that the author keeps mentioning IPython gives me great hope for it. Edit: in fact, upon rewatching, that INim video would be a great sales pitch for the language for you, as the author details his trip through a bunch of different well-known languages and why Nim meets the sweet spot of everything he's looking for. [1] https://golang.org/ref/spec https://golang.org/ref/spec [2] https://www.manning.com/books/nim-in-action https://www.manning.com/books/nim-in-action [3] https://youtu.be/Qa_9vut4TzQ https://youtu.be/Qa_9vut4TzQ
- pansa2 6y ago
  > > OTOH there seems to be a rapid accumulation of features... > I think you're stretching your narrative a bit. They're working on a new GC algorithm... The thing is, according to the documentation [0], Nim already has six different garbage collectors. [0] https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html
  - kbd 6y ago
    Do those represent a "rapid accumulation of features" that create an "ever-increasing scope of the language" as the OP claims, or are they just tuning options? Keep in mind the Nim team didn't create the Boehm or Go garbage collectors, and the new arc/orc are the same, with orc having a cycle detector. If anything, it's a testament to the design and stability of the language that the GC algorithm is swappable. Edit: for comparison, Java has four different GC algorithms to choose from[1] with a whole lot of options for tuning[2]: [1] https://www.baeldung.com/jvm-garbage-collectors https://www.baeldung.com/jvm-garbage-collectors [2] https://www.oracle.com/java/technologies/javase/vmoptions-jsp.html https://www.oracle.com/java/technologies/javase/vmoptions-js...
  - gmfawcett 6y ago
    Many languages have pluggable GCs. Modern Java VMs have at least four (serial, parallel, CMS, G1). As long as they are interchangeable, it's not really a language design issue.
    - sorokod 6y ago
      also ZGC and Shenandoah
arc776 6y ago
> Nim on the surface has a dream set of features It's "too good to be true" is for real. The lack of friction when developing in Nim is what makes it so fun to code in (IMO). Metaprogramming in particular is just great in Nim and give you a lot of scope for doing things that would otherwise require new language features. > how do you cope with the ever increasing scope of the language? I've been using Nim pretty intensively for several years. From my perspective the language design has been very stable, even since before 1.0. I don't feel like the scope is expanding, and I don't think it really needs to either because the core language is built to be expanded with metaprogramming. None of my code breaks when updating versions (and I do a lot of heavy metaprogramming). Nothing seems to be abandoned, only refined, and there's a big effort towards backwards compatability so breaking changes are exceedingly rare. The only one I only remember was some time ago when seq (the variable sized list type à la C++ vector) became not nil, so I had to replace `if list != nil` with `if list.len > 0`, so a good change IMO. Most of the new things have been mechanical under the hood improvements and ownership is one of those. As I understand it, when using gc refs, you'll get free extra speed, better multithreadding, and better compile-time checks. No code needs to be changed, and when it's considered ready it will replace the previous GC, and you can add extra annotations for performance. It's refinement of the GC using ownership rules rather than a whole new set of rules for your program. The stdlib is very stable (at least from my experience), and again great effort is spent on backwards compatability. Stdlib focus is on being small and "essential", so there's a high bar for stuff getting into it, and probably why it's rare for anything to change API there. So personally the pace of change has been great - basically my code's just got free speed boosts when it's already fast enough :)
- codetrotter 6y ago
  > Metaprogramming in particular is just great in Nim and give you a lot of scope for doing things that would otherwise require new language features. Metaprogramming is v alluring to me, but I’ve been wondering, people that write code super heavy on the metaprogramming, doesn’t revisiting code and debugging become much more taxing?
  - planetis 6y ago

anaphor 6y ago

A lot of the things you mention are pretty self-contained (you have to enable specific compiler flags), or they're implemented using the macro system or templates, and so in theory at least it's not bloating the compiler. Compared to something like Haskell (GHC), I think Nim is pretty lightweight and not too bloated.

kbd 6y ago

> OTOH there seems to be a rapid accumulation of features... I think you're stretching your narrative a bit. They're working on a new GC algorithm that (if you watch Rumpf's very interesting presentation[1] on it from today) is a significant performance improvement over their current GC. What features are you referring to regarding the "ever increasing scope of the language"? [1] https://www.youtube.com/watch?v=aUJcYTnPWCg https://www.youtube.com/watch?v=aUJcYTnPWCg

sidkshatriya 6y ago
It is an impression (possibly an unfounded/unfair one) and the whole point of my question is for others to give me their opinions. Nim is certainly a feature-full language. Look at the left sidebar on https://nim-lang.org/docs/manual.html https://nim-lang.org/docs/manual.html and you will see a lot of things listed! I wonder how many of those features work well with others, how many work partially and how many are somewhat abandoned. I'm looking to add Nim to my arsenal in the future. I'm positive on the language -- please don't misunderstand. I just wanted some opinions!
- planetis 6y ago
  Everything that is new or was causing problems, moved under expiremental https://nim-lang.org/docs/manual_experimental.html https://nim-lang.org/docs/manual_experimental.html These are the features you are describing, the ones needing more refinement.
  - planetis 6y ago
    stuff like concepts and code reordering are planned to eventually became stable. Nowadays everything is decided in the RFCs repo https://github.com/nim-lang/RFCs/issues https://github.com/nim-lang/RFCs/issues before a PR hits the main repo.
- kbd 6y ago
  > Look at the left sidebar... Look at the Go language manual for comparison[1]. Go is simple (some would argue, simplistic) and there's a lot there too. Programming languages are complex beasts. "Number of things in the sidebar of the manual" is a poor way to judge a programming language. > I like the philosophy of evolving your language slowly and consolidating before adding newer and newer features. The Nim book[2] came out in 2017 and the language has maintained compatibility with it through their 1.0 release. Nim seems pretty stable and "well baked" to me. One of the awesome things about Nim is that many features in the language can be implemented through macros. (AFAIK their async/await feature is implemented in Nim itself through macros.) So, I get the impression that Nim has a very solid core and builds things on top of that core. The fact that they can implement Rust-style move/borrow semantics without significantly changing the language is a really good sign to me of the language's power/design. Personally, I wish Nim was what we were all using instead of Go. Nim has all the strong typing features (like generics) that Go is still working on, while also having the equivalent of goroutines and channels (though I haven't played with those in Nim myself yet), pleasant syntax, strong metaprogramming features, very strong operator overloading that helps make it suited for domains like data science, can generate a static binary, and on and on. I'd strongly recommend everyone take a look :) I'm personally psyched that a repl (INim) is being worked on (and works now), because a good repl is something I really value in a language. There's a short presentation about it from today's conference as well[3]. The fact that the author keeps mentioning IPython gives me great hope for it. Edit: in fact, upon rewatching, that INim video would be a great sales pitch for the language for you, as the author details his trip through a bunch of different well-known languages and why Nim meets the sweet spot of everything he's looking for. [1] https://golang.org/ref/spec https://golang.org/ref/spec [2] https://www.manning.com/books/nim-in-action https://www.manning.com/books/nim-in-action [3] https://youtu.be/Qa_9vut4TzQ https://youtu.be/Qa_9vut4TzQ
pansa2 6y ago
> > OTOH there seems to be a rapid accumulation of features... > I think you're stretching your narrative a bit. They're working on a new GC algorithm... The thing is, according to the documentation [0], Nim already has six different garbage collectors. [0] https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html
- kbd 6y ago
  Do those represent a "rapid accumulation of features" that create an "ever-increasing scope of the language" as the OP claims, or are they just tuning options? Keep in mind the Nim team didn't create the Boehm or Go garbage collectors, and the new arc/orc are the same, with orc having a cycle detector. If anything, it's a testament to the design and stability of the language that the GC algorithm is swappable. Edit: for comparison, Java has four different GC algorithms to choose from[1] with a whole lot of options for tuning[2]: [1] https://www.baeldung.com/jvm-garbage-collectors https://www.baeldung.com/jvm-garbage-collectors [2] https://www.oracle.com/java/technologies/javase/vmoptions-jsp.html https://www.oracle.com/java/technologies/javase/vmoptions-js...
- gmfawcett 6y ago
  Many languages have pluggable GCs. Modern Java VMs have at least four (serial, parallel, CMS, G1). As long as they are interchangeable, it's not really a language design issue.
  - sorokod 6y ago
    also ZGC and Shenandoah

arc776 6y ago

> Nim on the surface has a dream set of features It's "too good to be true" is for real. The lack of friction when developing in Nim is what makes it so fun to code in (IMO). Metaprogramming in particular is just great in Nim and give you a lot of scope for doing things that would otherwise require new language features. > how do you cope with the ever increasing scope of the language? I've been using Nim pretty intensively for several years. From my perspective the language design has been very stable, even since before 1.0. I don't feel like the scope is expanding, and I don't think it really needs to either because the core language is built to be expanded with metaprogramming. None of my code breaks when updating versions (and I do a lot of heavy metaprogramming). Nothing seems to be abandoned, only refined, and there's a big effort towards backwards compatability so breaking changes are exceedingly rare. The only one I only remember was some time ago when seq (the variable sized list type à la C++ vector) became not nil, so I had to replace `if list != nil` with `if list.len > 0`, so a good change IMO. Most of the new things have been mechanical under the hood improvements and ownership is one of those. As I understand it, when using gc refs, you'll get free extra speed, better multithreadding, and better compile-time checks. No code needs to be changed, and when it's considered ready it will replace the previous GC, and you can add extra annotations for performance. It's refinement of the GC using ownership rules rather than a whole new set of rules for your program. The stdlib is very stable (at least from my experience), and again great effort is spent on backwards compatability. Stdlib focus is on being small and "essential", so there's a high bar for stuff getting into it, and probably why it's rare for anything to change API there. So personally the pace of change has been great - basically my code's just got free speed boosts when it's already fast enough :)

codetrotter 6y ago
> Metaprogramming in particular is just great in Nim and give you a lot of scope for doing things that would otherwise require new language features. Metaprogramming is v alluring to me, but I’ve been wondering, people that write code super heavy on the metaprogramming, doesn’t revisiting code and debugging become much more taxing?
- planetis 6y ago