13 ms·

Nim version 2.0.0 release candidate

184 points by treeform 4y ago

_Wintermute 4y ago
As a casual nim user, there's plenty I probably don't appreciate enough in there, but thing I'm most looking forward to are the default values for objects.
- cb321 4y ago
  I suspect that is a headliner "syntax" feature for many more serious Nim users. Initialization, like error handling, is one of those things that is easy to mess up.
- isofruit 4y ago
  I am looking forward to them supporting distinct DateTime types (basically used-defined clones of the DateTime type with custom behaviour). Currently using the constructor package to do the same thing, but being able to throw out a dependency is always nice.
fwsgonzo 4y ago
Greatly looking forward to experimenting with zero-overhead interop, as that is a pre-requisite for using it as a configuration language for certain types of high-performance servers
tiffanyh 4y ago
I wonder if anything from this forum thread [1], which is summarized here [2], got implemented. [1] https://forum.nim-lang.org/t/9132 https://forum.nim-lang.org/t/9132 [2] https://gist.github.com/j-james/08cd36b7475d461d6291416381ce98ad https://gist.github.com/j-james/08cd36b7475d461d6291416381ce...
- treeform 4y ago
  Looking at the summery [2] many of the things got implemented, just a quick list: * Remove backwards-compatible switches / deprecated features * Remove every memory option except orc, arc, none, go * Shrink stdlib * Comprehensive stdlib cleanup * Support default values in object construction * Language features designed for parallelism * Lock in --threads:on and --mm:arc/--mm:orc * Official support for overloadable enum names * Robust concurrency/multithreading * Fix bugs!
  - cb321 4y ago
    > * Remove every memory option except orc, arc, none, go I feel like memory option removals remain more "planned/maybe revisable/maybe not really agreed upon as the right direction" with only a change of AMM defaults happening in 2.0. (I'm also not sure what value in removal really is except less to learn about/more inflexibility..). The rest of the list seems represented, though.
maximus-decimus 4y ago
Well, crap. I just bought his book about version 1 lol.
- steve_adams_86 4y ago
  > Don’t panic! One of our design goals was to make it easy to write code that works with Nim version 1 and 2.
- revskill 4y ago
  Please share to me if you don't mind.
  - maximus-decimus 4y ago
    Share the book? Unfortunately I had to buy a physical copy because Andreas refuses to make a pdf version (to avoid pirating I think?). Honestly though, I'm a bit let down in that it doesn't seem to cover what I find the most interesting aspect of Nim : its ability to compile to multiple intermediate programming languages like C, C++ or Javascript and use their libraries. I was hoping to find out how to write VSCode extensions entirely in TypeScript (I know it's possible because the Nim vscode extension itself is now 100% Nim, but there seems to be no tutorial for how to do it online) I had started reading "Nim in Action" and I might finish that first since it does cover FFI, it it is rather old (it was released before version 1.0) You can find Nim in Action on the Mannings website : https://www.manning.com/books/nim-in-action https://www.manning.com/books/nim-in-action
- xigoi 4y ago
  The language didn't change that much.
rayiner 4y ago
Nim’s arc and sink/lent annotations seem a lot simpler than Rust’s owned pointers and region annotations. Has anybody had the opportunity to compare the costs and benefits?
- wyldfire 4y ago
  > Has anybody had the opportunity to compare the costs and benefits? Heap allocators are very significant cost over stack. Nim's designed for different use cases. Rust statically checks memory usage, and provides Arc for use cases that can only be modeled dynamically.
  - zozbot234 4y ago
    Rc and Arc require a general heap in Rust (pending support for local allocators, or Storages or whatever they end up with).
  - actuallyalys 4y ago
    The name is confusing, but Nim's Arc is not the same as Rust's: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc.... Rust (and apparently Swift) uses Arc to refer to atomic reference counting, whereas Nim's means automatic. There's still overhead, but it would be more comparable to Rust's Rc, I believe.
    - pjmlp 4y ago
      Swift uses ARC to mean automatic, and its use comes from Objective-C's ARC.
      - actuallyalys 4y ago
        Huh, the Nim blog post appears to be wrong, then, or I misunderstood it.
  - elcritch 4y ago
    Nim has good stack value support too. Heap vs stack is just treated as more an optimization thing. Rust's borrow checker is most useful for heap memory, not stack. For stack based values Nim's 'var' and 'openArray[T]' are roughly equivalent to simple implicit lifetimes. I don't know the proper parlance vs more complicated lifetime situations like "capturing" a lifetime. Its not too different to C++ references either. Sounds like D will also check for similar "lifetime" violations soon as well. The real difference is heap memory. There Rust's lifetimes allow you to give ownership away. Nim's var parameters can't do that, but instead it gives you fast and cheap non-atomic ref counting. Rusts way does encourage slightly faster code on average at the expense of more effort on programmers. Whether Rust or Nim, allocations are expensive. Though in my experience Nim's allocator is amazing. It can sometimes be faster to use ref's than stack values.
derbOac 4y ago
I was hoping case sensitivity would be implemented but it seems like it was too controversial. I'm thinking at this point there might be too much resistance.
- Symmetry 4y ago
  I've come to increasingly accept it over time? I mean, I'd really like it if my_function() and myFunction() just weren't allowed in the same section of code but if you allow the user to have both it's probably better that they refer to the same function than different functions.
  - tryptophan 4y ago
    It is a strange feature but it does have a good underlying idea. Why would having two functions, named makeFile and make_file in the same program ever be a good idea? Think of it as less of a language syntax feature and more of a code style enforcement paradigm. Good lsp support makes it mostly fine imo.
    - isofruit 4y ago
      Imo it goes beyond that. You have folks from Java etc. coming over with their camel-case as well as python folks with snake-case. Now despite both of them writing in their own styles, their code can interact, because when the java-programmer gives you a `validateObject` procedure from their package, the python developer can just use it as `validate_object`. Not being forced into other people's style choices is a really nice boon to me.
  - thom 4y ago
    It's not so much that anybody thinks that mix is a good idea, but it's just what happens immediately in any C/C++ codebase if you're using any nontrivial combination of libraries at all. The feature is about providing consistency, not ignoring it.
  - v3ss0n 4y ago
    My_function vs myFunction Is fine but do_me vs dome start to differ and do_me vs d_ome vs dom_e start to make things very much different. That's the real problem
synergy20 4y ago
among nim, zig and rust, I'm most likely to learn nim, it has been there for a while and it is solid and has so many good stuff in it, it just needs more 'marketing'. in particular, python really should help its popularity as their syntax are similar and both are very expressive.
- zozbot234 4y ago
  Is syntax really that big of an obstacle to learning a first programming language? The semantics of a C-like language like Nim could hardly be more different to Python's, they're pretty much at opposite ends in the stack.
  - TylerE 4y ago
    Nim feels much more like python than c to me, and the minimal number of non-alphanumeric characters in source is a big part of that.
  - satvikpendem 4y ago
    > Is syntax really that big of an obstacle to learning a first programming language? Of course. Compare, at the extremes, languages like APL or Brainfuck to something like Python or Scratch. Syntax is a huge factor in people wanting to learn to code or not.
    - adalacelove 4y ago
      Those languages have actually very different semantics too. I would say lisp is a better example of the importance of syntax. People obsess (wrongly) about superficial details in my opinion.
      - deleted 4y ago
        [deleted]
      - satvikpendem 4y ago
        I know of an example first hand where syntax only mattered: OCaml vs ReasonML. ReasonML is merely a syntactic change from OCaml as it's simply OCaml underneath, but people, especially coming from web languages like Javascript, liked ReasonML more than OCaml and were more willing to use it. Another example, Gleam (an Erlang BEAM based language like Elixir) [0]: > Shot in the wind, but is there a plan for different syntax? For those who've become comfortable in different fp camps, I can't really see myself picking up curly brackets and C-style code again. I really like the idea(s) of this project, but it's the thought of staring at that kind of code that's just a bit too much. I'd rather do something like [Nim,Scala,Clojure,F#]->JS if I needed to have that. > > Unlikely I'm afraid. We used to have an ML style syntax but once we switched to a more mainstream syntax we had a big surge in popularity and interest. > > I am very fond of the ML syntax, but I think it is the semantics and type system that really matter, so I am very happy to sacrifice syntax in order to make Gleam more widely accessible. [0] https://news.ycombinator.com/item?id=27063049 https://news.ycombinator.com/item?id=27063049
samsquire 4y ago
I am pleased to see a language that focuses on good multithreaded support. I tend to use Java and C for multithreaded problems but having the availability of Nim which looks similar to Python is really promising.
- zozbot234 4y ago
  If you want good multithreaded support and don't care much about ensuring perfect thread-safety at all times, you can't beat Go for real-world use.
  - samsquire 4y ago
    Yes I like Go but I am yet to do any professional development in it. Go is a M:N scheduler with M kernel threads and N lightweight threads I wrote a 1:M:N lightweight scheduler which preempts hot loops. I don't know when Golang preempt goroutines outside of a channel send - I believe it's in stack growth or in other words when a method is called. My userspace scheduler preempts while true and for loops by setting the looping variable to the limit. I wrote it in Java, C and Rust. https://GitHub.com/samsquire/preemptible-thread https://GitHub.com/samsquire/preemptible-thread Does anybody know if Nim loop variables can be easily mutated from another thread? It looks they cannot
    - elcritch 4y ago
      No, not directly but Nim supports async. Effectively it turns the function into an Iterator whose state can be passed around. Those are put into Futures. Its possible to write your own async engine, or you could use the iterator yourself if you really wanted. It's actually not too hard. Checkout: https://github.com/status-im/nim-taskpools https://github.com/status-im/nim-taskpools Edit: also Nim compiles to C, so its possible to do whatever you can do in C with a bit of fiddling. Also theres coro https://nim-lang.org/docs/coro.html https://nim-lang.org/docs/coro.html
  - mikedelago 4y ago
    Elixir fits in here as well, if the workload is thread-bound and not computation bound. I think Elixir's syntax and idioms are better than Go's, but that's personal preference.
mrichman 4y ago
I haven't heard of Nim until now. I've been a Go programmer for years now, and I see a lot of potential. I wonder why Nim hasn't taken off. What's the catch?
- cauthon 4y ago
  A contributing factor may be lack of a major sponsor bootstrapping the user base. Go had Google, Rust had Mozilla, Nim was/is largely indie.
  - darthrupert 4y ago
    Like the most popular language per Tiobe, python.
    - isofruit 4y ago
      To be fair, python back then didn't have great competitors in its space. I guess Perl, but from what I still remember from Perl before I dropped it like a hot potato a couple days in, it wasn't particularly great. Nim does.
      - darthrupert 4y ago
        Python vs Ruby seemed like a real fight for a while, especially when there was Rails and python did not really have anything equivalent.
        cb321 4y ago
        Python languished as an obscure niche language from its inception in the late 80s until at least 2000. I recall discussing it with friends all during the 90s to blank stares and shaking heads. Rapid adoption (of, well, anything) is a network effects game. In the very early 2000s Python really took off (basically Python 2.x). It surely helped that well known companies like Google (pre-IPO, "ad free & proud of it" back then) started openly saying they used it, but like many network effect things, it's probably hard to pin down any one "cause" (but easy to fool yourself into thinking you have, e.g. Google also said they used Perl). The Numeric module existed, but data science was not very strong until Travis united the numarray/Numeric things into NumPy. [1] https://en.wikipedia.org/wiki/History_of_Python https://en.wikipedia.org/wiki/History_of_Python has more details, but it does not have a nice plot/chart of "How weirdly do your software friends look at you when you bring up Python..." which has, shall we say, a "data collection problem". :-) Proxies for such data might be interesting case studies in the sociology of programming languages, though. [1] https://en.wikipedia.org/wiki/NumPy https://en.wikipedia.org/wiki/NumPy
posharma 4y ago
Are there any products/companies that use Nim in production?
- intelVISA 4y ago
  There's a list in the very announcement: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim though I'd imagine the number will remain small as Nim's too artisanal for enterprise to grok.
- michaelsbradley 4y ago
  Status makes heavy use of Nim in production: https://github.com/orgs/status-im/repositories?q=&type=all&language=nim&sort= https://github.com/orgs/status-im/repositories?q=&type=all&l...
- ReneSac 4y ago
  Goodboy Galaxy is a game in development for Game Boy Advance writen in Nim. They did a presentation about coding for GBA in NimConf 2020: https://www.youtube.com/watch?v=sZUM7MhWr88 https://www.youtube.com/watch?v=sZUM7MhWr88
curioussavage 4y ago
This looks great. I’m loving nim for game dev right now. Godot 3.x bindings are working great. There is also a really nice looking binding for unreal engine 5 that is pretty far along
- antifa 4y ago
  Are the nim godot bindings also good for full cross-platform development?
geenat 4y ago
Default values and named parameters, thank you! Golang has neglected both of these. Both seemingly rare yet highly productive features to be found in a compiled language. Love the quick compile times and go-like single binary compilation. Case-insensitivity seems very cool for interoperability. Total underappreciated gem. My only hangup is the syntax feels wordy, but it's leagues better compared to Rust or Go in that regard. A bit concerned about the performance cost of using macros to cut down on the wordiness (I would do this). Otherwise great to see a 2.0 and always keeping a close eye on the Nim ecosystem as I would definitely consider adopting it.
- TylerE 4y ago
  Macros shouldn’t have any performance implications. The whole point is that they happen at compile time.
  - cb321 4y ago
    He did mention "quick compile times" as a draw and macros can slow down compile times/that kind of performance, but sure run-time performance of compiled code should be unimpacted. EDIT: FWIW, compile-times impact mostly just depends on what he wants to do. The macro evaluator not that slow a virtual machine. Simple substitution macros tend to run quite fast. But it's also easy (with loops!) to generate a large pile of Nim code that generates a ginormous pile of C code that the backend might have to chew on for quite a while.
  - geenat 4y ago
    100% about compile times. Sorry, wasn't clear about that.
    - PMunch 4y ago
      Have written quite a lot of macros, unless you're doing something really crazy you should be fine. The one time I've really run into macros slowing down compilation a lot was when I wrote my protobuf library which parses a protoc file during compile-time and generates all the required types and procedures. And that was mostly because the parser I used was really poorly optimized.
diimdeep 4y ago
In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms. It is like TypeScript to JS in C/C++ world. Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.
- elcritch 4y ago
  The distinction between compilation and transpiling is a bit imprecise, but yes. But oddly the basic C that Nim compiles to is fairly resilient and stable. I'd actually expect the Nim compiler to bitrot way less than languages based on LLVM, which have a very short half life. So Nim's approach has some challenges, but surprisingly has less moving parts than you'd think. I'd be confident I could get the current Nim compiler up and running in 5, or 10 years with minimal effort. However, there was a lot of effort to get things like pointers and strings in the stdlib to play nicely across the NimVM, JS, and C backends. Theres some gross details there. But in the end its beautiful.
  - cb321 4y ago
    Besides @elcritch's and @pjmlp's excellent points {language "level" is vague & all compilers translate}, C as a backend target has other virtues (though is by no means The Only Way). E.g., TinyC/tcc optimizes for time to compile (it is a single pass over its input) not generated object code qualities like run-time/file-size. This can give Nim code almost interpreter-like edit-compile-debug devel cycles, but even just changing the default gcc -Og to gcc -O0 can be a huge improvement. [1] (`passL:"-lm" --mm:markAndSweep` and recently `--threads:off` became necessary for tcc due to atomics/C11 dependencies, but it is already a kind of "debugging compilation mode".) Similarly, work on space-saving/alternate libc's like musl [2] can be leveraged, [3] although using `config.nims`/NimScript can also lengthen compile-times by 100 milliseconds or so. [1] https://forum.nim-lang.org/t/8677 https://forum.nim-lang.org/t/8677 [2] https://musl.libc.org/ https://musl.libc.org/ [3] https://github.com/kaushalmodi/hello_musl/blob/master/config.nims https://github.com/kaushalmodi/hello_musl/blob/master/config...
- 4y ago
pyinstallwoes 4y ago
Any die-hard lovers of Nim? Or heavy users? Why do you use it over other languages? What was your ah-ha moment?
- isofruit 4y ago
  I only know a hand full of languages so make of that what you will. I came from a python background and hadn't learned a compiled language before, so I wanted to experiment. Tried Rust for quite a while, but found the syntax not clicking with me though a lot of ideas seemed intriguing (pattern matching and Result types). Didn't want to try C/C++ because I wasn't that hard into figuring out how memory works and at the same time was pretty shocked at how C considers types. That only leaves go after that, which I heard about around the same time as nim. I started out with nim and I liked it enough so I stuck with it. Why I use it over other languages? I feel like I can express myself in english readable sentences (which gives it the python vibe for me) and at the same time I have static typing, a really nice type system in general and very little chance of crap like nullpointers occurring. My first ah-ha moment was pretty much 3 hours in when I noticed I could already already write simple stuff and only needed to consult the std lib docs here and there. The second was when I reimplemented a webserver backend that I previously had in Django (not for practical reasons, just to see how fast it could go even very little optimization) and found it performing roughly 2-5 times faster (measured by looking at request response time), despite having optimized Django's ORM to as few queries as physically possible to get the data I needed. (For reference: That's quite surprising given a decent chunk of that time is literally just network latency)
- moigagoo 4y ago
  As a Python user, I had my a-ha moment with Nim when I realized I didn't need a repl. With Python, I used repl all the time. There's bpython, ptpython, ipython, and probably a couple more great repls because repl is really important for Python development. Nim's INim is no match for those. But here's the great part: with Nim you don't have to test code snippets all the time. I get all my error messages before they happen. This felt liberating after Python.
  - isofruit 4y ago

184 points by treeform 4y ago

As a casual nim user, there's plenty I probably don't appreciate enough in there, but thing I'm most looking forward to are the default values for objects.

cb321 4y ago
I suspect that is a headliner "syntax" feature for many more serious Nim users. Initialization, like error handling, is one of those things that is easy to mess up.
isofruit 4y ago
I am looking forward to them supporting distinct DateTime types (basically used-defined clones of the DateTime type with custom behaviour). Currently using the constructor package to do the same thing, but being able to throw out a dependency is always nice.

fwsgonzo 4y ago

Greatly looking forward to experimenting with zero-overhead interop, as that is a pre-requisite for using it as a configuration language for certain types of high-performance servers

tiffanyh 4y ago

I wonder if anything from this forum thread [1], which is summarized here [2], got implemented. [1] https://forum.nim-lang.org/t/9132 https://forum.nim-lang.org/t/9132 [2] https://gist.github.com/j-james/08cd36b7475d461d6291416381ce98ad https://gist.github.com/j-james/08cd36b7475d461d6291416381ce...

treeform 4y ago
Looking at the summery [2] many of the things got implemented, just a quick list: * Remove backwards-compatible switches / deprecated features * Remove every memory option except orc, arc, none, go * Shrink stdlib * Comprehensive stdlib cleanup * Support default values in object construction * Language features designed for parallelism * Lock in --threads:on and --mm:arc/--mm:orc * Official support for overloadable enum names * Robust concurrency/multithreading * Fix bugs!
- cb321 4y ago
  > * Remove every memory option except orc, arc, none, go I feel like memory option removals remain more "planned/maybe revisable/maybe not really agreed upon as the right direction" with only a change of AMM defaults happening in 2.0. (I'm also not sure what value in removal really is except less to learn about/more inflexibility..). The rest of the list seems represented, though.

maximus-decimus 4y ago

Well, crap. I just bought his book about version 1 lol.

steve_adams_86 4y ago
> Don’t panic! One of our design goals was to make it easy to write code that works with Nim version 1 and 2.
revskill 4y ago
Please share to me if you don't mind.
- maximus-decimus 4y ago
  Share the book? Unfortunately I had to buy a physical copy because Andreas refuses to make a pdf version (to avoid pirating I think?). Honestly though, I'm a bit let down in that it doesn't seem to cover what I find the most interesting aspect of Nim : its ability to compile to multiple intermediate programming languages like C, C++ or Javascript and use their libraries. I was hoping to find out how to write VSCode extensions entirely in TypeScript (I know it's possible because the Nim vscode extension itself is now 100% Nim, but there seems to be no tutorial for how to do it online) I had started reading "Nim in Action" and I might finish that first since it does cover FFI, it it is rather old (it was released before version 1.0) You can find Nim in Action on the Mannings website : https://www.manning.com/books/nim-in-action https://www.manning.com/books/nim-in-action
xigoi 4y ago
The language didn't change that much.

rayiner 4y ago

Nim’s arc and sink/lent annotations seem a lot simpler than Rust’s owned pointers and region annotations. Has anybody had the opportunity to compare the costs and benefits?

wyldfire 4y ago
> Has anybody had the opportunity to compare the costs and benefits? Heap allocators are very significant cost over stack. Nim's designed for different use cases. Rust statically checks memory usage, and provides Arc for use cases that can only be modeled dynamically.
- zozbot234 4y ago
  Rc and Arc require a general heap in Rust (pending support for local allocators, or Storages or whatever they end up with).
- actuallyalys 4y ago
  The name is confusing, but Nim's Arc is not the same as Rust's: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc.... Rust (and apparently Swift) uses Arc to refer to atomic reference counting, whereas Nim's means automatic. There's still overhead, but it would be more comparable to Rust's Rc, I believe.
  - pjmlp 4y ago
    Swift uses ARC to mean automatic, and its use comes from Objective-C's ARC.
    - actuallyalys 4y ago
      Huh, the Nim blog post appears to be wrong, then, or I misunderstood it.
- elcritch 4y ago
  Nim has good stack value support too. Heap vs stack is just treated as more an optimization thing. Rust's borrow checker is most useful for heap memory, not stack. For stack based values Nim's 'var' and 'openArray[T]' are roughly equivalent to simple implicit lifetimes. I don't know the proper parlance vs more complicated lifetime situations like "capturing" a lifetime. Its not too different to C++ references either. Sounds like D will also check for similar "lifetime" violations soon as well. The real difference is heap memory. There Rust's lifetimes allow you to give ownership away. Nim's var parameters can't do that, but instead it gives you fast and cheap non-atomic ref counting. Rusts way does encourage slightly faster code on average at the expense of more effort on programmers. Whether Rust or Nim, allocations are expensive. Though in my experience Nim's allocator is amazing. It can sometimes be faster to use ref's than stack values.

derbOac 4y ago

I was hoping case sensitivity would be implemented but it seems like it was too controversial. I'm thinking at this point there might be too much resistance.

Symmetry 4y ago
I've come to increasingly accept it over time? I mean, I'd really like it if my_function() and myFunction() just weren't allowed in the same section of code but if you allow the user to have both it's probably better that they refer to the same function than different functions.
- tryptophan 4y ago
  It is a strange feature but it does have a good underlying idea. Why would having two functions, named makeFile and make_file in the same program ever be a good idea? Think of it as less of a language syntax feature and more of a code style enforcement paradigm. Good lsp support makes it mostly fine imo.
  - isofruit 4y ago
    Imo it goes beyond that. You have folks from Java etc. coming over with their camel-case as well as python folks with snake-case. Now despite both of them writing in their own styles, their code can interact, because when the java-programmer gives you a `validateObject` procedure from their package, the python developer can just use it as `validate_object`. Not being forced into other people's style choices is a really nice boon to me.
- thom 4y ago
  It's not so much that anybody thinks that mix is a good idea, but it's just what happens immediately in any C/C++ codebase if you're using any nontrivial combination of libraries at all. The feature is about providing consistency, not ignoring it.
- v3ss0n 4y ago
  My_function vs myFunction Is fine but do_me vs dome start to differ and do_me vs d_ome vs dom_e start to make things very much different. That's the real problem

synergy20 4y ago

among nim, zig and rust, I'm most likely to learn nim, it has been there for a while and it is solid and has so many good stuff in it, it just needs more 'marketing'. in particular, python really should help its popularity as their syntax are similar and both are very expressive.

zozbot234 4y ago
Is syntax really that big of an obstacle to learning a first programming language? The semantics of a C-like language like Nim could hardly be more different to Python's, they're pretty much at opposite ends in the stack.
- TylerE 4y ago
  Nim feels much more like python than c to me, and the minimal number of non-alphanumeric characters in source is a big part of that.
- satvikpendem 4y ago
  > Is syntax really that big of an obstacle to learning a first programming language? Of course. Compare, at the extremes, languages like APL or Brainfuck to something like Python or Scratch. Syntax is a huge factor in people wanting to learn to code or not.
  - adalacelove 4y ago
    Those languages have actually very different semantics too. I would say lisp is a better example of the importance of syntax. People obsess (wrongly) about superficial details in my opinion.
    - deleted 4y ago
      [deleted]
    - satvikpendem 4y ago
      I know of an example first hand where syntax only mattered: OCaml vs ReasonML. ReasonML is merely a syntactic change from OCaml as it's simply OCaml underneath, but people, especially coming from web languages like Javascript, liked ReasonML more than OCaml and were more willing to use it. Another example, Gleam (an Erlang BEAM based language like Elixir) [0]: > Shot in the wind, but is there a plan for different syntax? For those who've become comfortable in different fp camps, I can't really see myself picking up curly brackets and C-style code again. I really like the idea(s) of this project, but it's the thought of staring at that kind of code that's just a bit too much. I'd rather do something like [Nim,Scala,Clojure,F#]->JS if I needed to have that. > > Unlikely I'm afraid. We used to have an ML style syntax but once we switched to a more mainstream syntax we had a big surge in popularity and interest. > > I am very fond of the ML syntax, but I think it is the semantics and type system that really matter, so I am very happy to sacrifice syntax in order to make Gleam more widely accessible. [0] https://news.ycombinator.com/item?id=27063049 https://news.ycombinator.com/item?id=27063049

samsquire 4y ago

I am pleased to see a language that focuses on good multithreaded support. I tend to use Java and C for multithreaded problems but having the availability of Nim which looks similar to Python is really promising.

zozbot234 4y ago
If you want good multithreaded support and don't care much about ensuring perfect thread-safety at all times, you can't beat Go for real-world use.
- samsquire 4y ago
  Yes I like Go but I am yet to do any professional development in it. Go is a M:N scheduler with M kernel threads and N lightweight threads I wrote a 1:M:N lightweight scheduler which preempts hot loops. I don't know when Golang preempt goroutines outside of a channel send - I believe it's in stack growth or in other words when a method is called. My userspace scheduler preempts while true and for loops by setting the looping variable to the limit. I wrote it in Java, C and Rust. https://GitHub.com/samsquire/preemptible-thread https://GitHub.com/samsquire/preemptible-thread Does anybody know if Nim loop variables can be easily mutated from another thread? It looks they cannot
  - elcritch 4y ago
    No, not directly but Nim supports async. Effectively it turns the function into an Iterator whose state can be passed around. Those are put into Futures. Its possible to write your own async engine, or you could use the iterator yourself if you really wanted. It's actually not too hard. Checkout: https://github.com/status-im/nim-taskpools https://github.com/status-im/nim-taskpools Edit: also Nim compiles to C, so its possible to do whatever you can do in C with a bit of fiddling. Also theres coro https://nim-lang.org/docs/coro.html https://nim-lang.org/docs/coro.html
- mikedelago 4y ago
  Elixir fits in here as well, if the workload is thread-bound and not computation bound. I think Elixir's syntax and idioms are better than Go's, but that's personal preference.

mrichman 4y ago

I haven't heard of Nim until now. I've been a Go programmer for years now, and I see a lot of potential. I wonder why Nim hasn't taken off. What's the catch?

cauthon 4y ago
A contributing factor may be lack of a major sponsor bootstrapping the user base. Go had Google, Rust had Mozilla, Nim was/is largely indie.
- darthrupert 4y ago
  Like the most popular language per Tiobe, python.
  - isofruit 4y ago
    To be fair, python back then didn't have great competitors in its space. I guess Perl, but from what I still remember from Perl before I dropped it like a hot potato a couple days in, it wasn't particularly great. Nim does.
    - darthrupert 4y ago
      Python vs Ruby seemed like a real fight for a while, especially when there was Rails and python did not really have anything equivalent.
      - cb321 4y ago
        Python languished as an obscure niche language from its inception in the late 80s until at least 2000. I recall discussing it with friends all during the 90s to blank stares and shaking heads. Rapid adoption (of, well, anything) is a network effects game. In the very early 2000s Python really took off (basically Python 2.x). It surely helped that well known companies like Google (pre-IPO, "ad free & proud of it" back then) started openly saying they used it, but like many network effect things, it's probably hard to pin down any one "cause" (but easy to fool yourself into thinking you have, e.g. Google also said they used Perl). The Numeric module existed, but data science was not very strong until Travis united the numarray/Numeric things into NumPy. [1] https://en.wikipedia.org/wiki/History_of_Python https://en.wikipedia.org/wiki/History_of_Python has more details, but it does not have a nice plot/chart of "How weirdly do your software friends look at you when you bring up Python..." which has, shall we say, a "data collection problem". :-) Proxies for such data might be interesting case studies in the sociology of programming languages, though. [1] https://en.wikipedia.org/wiki/NumPy https://en.wikipedia.org/wiki/NumPy

posharma 4y ago

Are there any products/companies that use Nim in production?

intelVISA 4y ago
There's a list in the very announcement: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim though I'd imagine the number will remain small as Nim's too artisanal for enterprise to grok.
michaelsbradley 4y ago
Status makes heavy use of Nim in production: https://github.com/orgs/status-im/repositories?q=&type=all&language=nim&sort= https://github.com/orgs/status-im/repositories?q=&type=all&l...
ReneSac 4y ago
Goodboy Galaxy is a game in development for Game Boy Advance writen in Nim. They did a presentation about coding for GBA in NimConf 2020: https://www.youtube.com/watch?v=sZUM7MhWr88 https://www.youtube.com/watch?v=sZUM7MhWr88

curioussavage 4y ago

This looks great. I’m loving nim for game dev right now. Godot 3.x bindings are working great. There is also a really nice looking binding for unreal engine 5 that is pretty far along

antifa 4y ago
Are the nim godot bindings also good for full cross-platform development?

geenat 4y ago

Default values and named parameters, thank you! Golang has neglected both of these. Both seemingly rare yet highly productive features to be found in a compiled language. Love the quick compile times and go-like single binary compilation. Case-insensitivity seems very cool for interoperability. Total underappreciated gem. My only hangup is the syntax feels wordy, but it's leagues better compared to Rust or Go in that regard. A bit concerned about the performance cost of using macros to cut down on the wordiness (I would do this). Otherwise great to see a 2.0 and always keeping a close eye on the Nim ecosystem as I would definitely consider adopting it.

TylerE 4y ago
Macros shouldn’t have any performance implications. The whole point is that they happen at compile time.
- cb321 4y ago
  He did mention "quick compile times" as a draw and macros can slow down compile times/that kind of performance, but sure run-time performance of compiled code should be unimpacted. EDIT: FWIW, compile-times impact mostly just depends on what he wants to do. The macro evaluator not that slow a virtual machine. Simple substitution macros tend to run quite fast. But it's also easy (with loops!) to generate a large pile of Nim code that generates a ginormous pile of C code that the backend might have to chew on for quite a while.
- geenat 4y ago
  100% about compile times. Sorry, wasn't clear about that.
  - PMunch 4y ago
    Have written quite a lot of macros, unless you're doing something really crazy you should be fine. The one time I've really run into macros slowing down compilation a lot was when I wrote my protobuf library which parses a protoc file during compile-time and generates all the required types and procedures. And that was mostly because the parser I used was really poorly optimized.

diimdeep 4y ago

In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms. It is like TypeScript to JS in C/C++ world. Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.

elcritch 4y ago
The distinction between compilation and transpiling is a bit imprecise, but yes. But oddly the basic C that Nim compiles to is fairly resilient and stable. I'd actually expect the Nim compiler to bitrot way less than languages based on LLVM, which have a very short half life. So Nim's approach has some challenges, but surprisingly has less moving parts than you'd think. I'd be confident I could get the current Nim compiler up and running in 5, or 10 years with minimal effort. However, there was a lot of effort to get things like pointers and strings in the stdlib to play nicely across the NimVM, JS, and C backends. Theres some gross details there. But in the end its beautiful.
- cb321 4y ago
  Besides @elcritch's and @pjmlp's excellent points {language "level" is vague & all compilers translate}, C as a backend target has other virtues (though is by no means The Only Way). E.g., TinyC/tcc optimizes for time to compile (it is a single pass over its input) not generated object code qualities like run-time/file-size. This can give Nim code almost interpreter-like edit-compile-debug devel cycles, but even just changing the default gcc -Og to gcc -O0 can be a huge improvement. [1] (`passL:"-lm" --mm:markAndSweep` and recently `--threads:off` became necessary for tcc due to atomics/C11 dependencies, but it is already a kind of "debugging compilation mode".) Similarly, work on space-saving/alternate libc's like musl [2] can be leveraged, [3] although using `config.nims`/NimScript can also lengthen compile-times by 100 milliseconds or so. [1] https://forum.nim-lang.org/t/8677 https://forum.nim-lang.org/t/8677 [2] https://musl.libc.org/ https://musl.libc.org/ [3] https://github.com/kaushalmodi/hello_musl/blob/master/config.nims https://github.com/kaushalmodi/hello_musl/blob/master/config...
4y ago

pyinstallwoes 4y ago

Any die-hard lovers of Nim? Or heavy users? Why do you use it over other languages? What was your ah-ha moment?

isofruit 4y ago
I only know a hand full of languages so make of that what you will. I came from a python background and hadn't learned a compiled language before, so I wanted to experiment. Tried Rust for quite a while, but found the syntax not clicking with me though a lot of ideas seemed intriguing (pattern matching and Result types). Didn't want to try C/C++ because I wasn't that hard into figuring out how memory works and at the same time was pretty shocked at how C considers types. That only leaves go after that, which I heard about around the same time as nim. I started out with nim and I liked it enough so I stuck with it. Why I use it over other languages? I feel like I can express myself in english readable sentences (which gives it the python vibe for me) and at the same time I have static typing, a really nice type system in general and very little chance of crap like nullpointers occurring. My first ah-ha moment was pretty much 3 hours in when I noticed I could already already write simple stuff and only needed to consult the std lib docs here and there. The second was when I reimplemented a webserver backend that I previously had in Django (not for practical reasons, just to see how fast it could go even very little optimization) and found it performing roughly 2-5 times faster (measured by looking at request response time), despite having optimized Django's ORM to as few queries as physically possible to get the data I needed. (For reference: That's quite surprising given a decent chunk of that time is literally just network latency)
moigagoo 4y ago
As a Python user, I had my a-ha moment with Nim when I realized I didn't need a repl. With Python, I used repl all the time. There's bpython, ptpython, ipython, and probably a couple more great repls because repl is really important for Python development. Nim's INim is no match for those. But here's the great part: with Nim you don't have to test code snippets all the time. I get all my error messages before they happen. This felt liberating after Python.
- isofruit 4y ago