3 ms·

Nim's a pleasant language to read/write! Out of curiosity, what aspects have you found challenging to learn? One caveat of imitating Python's syntax is that the

Nim's a pleasant language to read/write! Out of curiosity, what aspects have you found challenging to learn? One caveat of imitating Python's syntax is that the semantics are not the same as in Python and are closer to Pascal/Ada in many ways. If you haven't read through the Nim-for-Pythoners [1] it'd be good. I read the "nim manual" [2] constantly and just use ctrl-f. Though Nim Basics by narimiran is a nice tutorial form [3]. There's a few standard links: 1: https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programm... 2: https://nim-lang.org/docs/manual.html https://nim-lang.org/docs/manual.html 3: https://narimiran.github.io/nim-basics/ https://narimiran.github.io/nim-basics/

deleted 5y ago
[deleted]
jillesvangurp 5y ago
I just read through a bit of their documentation. So, I only have all of five minutes of experience with Nim. But it looks like a pleasant language to work with. I could see this becoming popular and it looks like something I could figure out pretty easily. I did not see any allocs/de-allocs, which suggests some kind of garbage collector is being used? I guess a lot of that is straightforward with stack allocated data structures going out of scope. But that would put this language in the same realm as Go and not Rust/C/C++, which don't rely on garbage collectors. I'm mainly doing Kotlin currently, which also has a multi platform compiler (with native, js, and jvm compilers). Though particularly the native compiler is a bit a work in progress. But, Nim could be considered similar to that as well. Though obviously the languages are very different, what is similar though is a focus on programmer convenience. It's something I really appreciate in Kotlin and it seems this language has a lot of that too. It will be interesting to see how this language grows and evolves. Looking at Rust and Go in recent years, there are a bunch of gnarly topics that inevitably come up like how to deal with asynchronous stuff and co-routines, generics, error handling, etc. Kotlin also had its fair share of that. That's when languages get more complicated. I think Rust is a good example of a language that has a pretty high level of complexity at this point. Just a first impression. But mostly a good one.
- _dain_ 5y ago
  There is a choice of garbage collectors (including none at all, although a lot of the stdlib breaks in that case). The "main" one the language is moving to is ARC/ORC. See here for more info: 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...
- zozbot234 5y ago
  > I think Rust is a good example of a language that has a pretty high level of complexity at this point. I'd say the opposite. Just look at how it compares to C++. Even Swift is a rather complex language when compared to Rust.
- elcritch 5y ago
  > I did not see any allocs/de-allocs, which suggests some kind of garbage collector is being used? I guess a lot of that is straightforward with stack allocated data structures going out of scope. But that would put this language in the same realm as Go and not Rust/C/C++, which don't rely on garbage collectors. Nim use a new GC they call ARC, which is just a clever combination of non-atomic/locking reference counting and move semantics. That combination enables the GC to be realtime capable and deterministic. It's also doesn't have GC pauses or issues with enormous heaps, but it requires more work when multi-threading. In theory Nim sounds be more similar to Go than Rust/C/C++, but with ARC you can use Nim where you'd use C/C++ (or turn off GC entirely). I'm using it on embedded RTOS'es and routinely getting exactly the same memory allocations with only a single integer add/sub overhead. Actually, many larger Rust programs end up using `Rc<mystruct>` a lot, which should result in an almost one-to-one correspondence on generated code to what Nim+ARC produces. > I'm mainly doing Kotlin currently, which also has a multi platform compiler (with native, js, and jvm compilers). Though particularly the native compiler is a bit a work in progress. But, Nim could be considered similar to that as well. Probably not a bad comparison. Kotlin sounds like a pragmatic language with just enough "functional concepts" to make it more productive but not type/theory heavy. > It will be interesting to see how this language grows and evolves. Looking at Rust and Go in recent years, there are a bunch of gnarly topics that inevitably come up like how to deal with asynchronous stuff and co-routines, generics, error handling, etc. Ouch, those are tough topics. I avoid Nim's async because it requires cycle detection (ARC w/ cycle detection) on embedded. Rust has difficulty with closures and async for similar reasons IIRC. Luckily Nim's error handling/async/co-routines are all pretty standard otherwise. There's some work to be done in Nim for improving modules and removing nill'able types from the standard library. But nothing that should cause the gnarly topics Rust/Go have been facing (:fingers-crossed:).

deleted 5y ago

[deleted]

jillesvangurp 5y ago

I just read through a bit of their documentation. So, I only have all of five minutes of experience with Nim. But it looks like a pleasant language to work with. I could see this becoming popular and it looks like something I could figure out pretty easily. I did not see any allocs/de-allocs, which suggests some kind of garbage collector is being used? I guess a lot of that is straightforward with stack allocated data structures going out of scope. But that would put this language in the same realm as Go and not Rust/C/C++, which don't rely on garbage collectors. I'm mainly doing Kotlin currently, which also has a multi platform compiler (with native, js, and jvm compilers). Though particularly the native compiler is a bit a work in progress. But, Nim could be considered similar to that as well. Though obviously the languages are very different, what is similar though is a focus on programmer convenience. It's something I really appreciate in Kotlin and it seems this language has a lot of that too. It will be interesting to see how this language grows and evolves. Looking at Rust and Go in recent years, there are a bunch of gnarly topics that inevitably come up like how to deal with asynchronous stuff and co-routines, generics, error handling, etc. Kotlin also had its fair share of that. That's when languages get more complicated. I think Rust is a good example of a language that has a pretty high level of complexity at this point. Just a first impression. But mostly a good one.

_dain_ 5y ago
There is a choice of garbage collectors (including none at all, although a lot of the stdlib breaks in that case). The "main" one the language is moving to is ARC/ORC. See here for more info: 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...
zozbot234 5y ago
> I think Rust is a good example of a language that has a pretty high level of complexity at this point. I'd say the opposite. Just look at how it compares to C++. Even Swift is a rather complex language when compared to Rust.
elcritch 5y ago
> I did not see any allocs/de-allocs, which suggests some kind of garbage collector is being used? I guess a lot of that is straightforward with stack allocated data structures going out of scope. But that would put this language in the same realm as Go and not Rust/C/C++, which don't rely on garbage collectors. Nim use a new GC they call ARC, which is just a clever combination of non-atomic/locking reference counting and move semantics. That combination enables the GC to be realtime capable and deterministic. It's also doesn't have GC pauses or issues with enormous heaps, but it requires more work when multi-threading. In theory Nim sounds be more similar to Go than Rust/C/C++, but with ARC you can use Nim where you'd use C/C++ (or turn off GC entirely). I'm using it on embedded RTOS'es and routinely getting exactly the same memory allocations with only a single integer add/sub overhead. Actually, many larger Rust programs end up using `Rc<mystruct>` a lot, which should result in an almost one-to-one correspondence on generated code to what Nim+ARC produces. > I'm mainly doing Kotlin currently, which also has a multi platform compiler (with native, js, and jvm compilers). Though particularly the native compiler is a bit a work in progress. But, Nim could be considered similar to that as well. Probably not a bad comparison. Kotlin sounds like a pragmatic language with just enough "functional concepts" to make it more productive but not type/theory heavy. > It will be interesting to see how this language grows and evolves. Looking at Rust and Go in recent years, there are a bunch of gnarly topics that inevitably come up like how to deal with asynchronous stuff and co-routines, generics, error handling, etc. Ouch, those are tough topics. I avoid Nim's async because it requires cycle detection (ARC w/ cycle detection) on embedded. Rust has difficulty with closures and async for similar reasons IIRC. Luckily Nim's error handling/async/co-routines are all pretty standard otherwise. There's some work to be done in Nim for improving modules and removing nill'able types from the standard library. But nothing that should cause the gnarly topics Rust/Go have been facing (:fingers-crossed:).