5 ms·

Congrats, Nim is really becoming more and more mature as time goes on and showing new features like these are great though they do come off a bit as "a not done

Congrats, Nim is really becoming more and more mature as time goes on and showing new features like these are great though they do come off a bit as "a not done language"? What is the plan for ARC/ORC stability and possible default? Are we looking at 1.6 or later (1.8?). Will the GCs (since ARC isn't really a GC) be deprecated at that time?

Tiberium 6y ago
One of the links in the end of the article leads to the RFC which talks exactly about this, see last commit by Araq especially: https://github.com/nim-lang/RFCs/issues/177#issuecomment-696113293 https://github.com/nim-lang/RFCs/issues/177#issuecomment-696... In short: yes, the current plan is to phase out other GCs over time.
- supakeen 6y ago
  Perfect, all except markAndSweep/go, thank you!
beagle3 6y ago
> Will the GCs (since ARC isn't really a GC) be deprecated at that time? Not sure why you don't consider ARC a gc - it is, with the caveat that it doesn't break cycles on its own. If you have cycles you aren't going to break on your own, use ORC.
pjmlp 6y ago
> Will the GCs (since ARC isn't really a GC) be deprecated at that time? Any form of reference counting is definitely a GC. http://gchandbook.org/contents.html http://gchandbook.org/contents.html (chapter 5)
- turbinerneiter 6y ago
  I guess the more interesting questions is whether it happens at compile time or run-time - ARC definitely injects derefs at compile time and therefore there are no gc-"pauses" at runtime. (Right?)
  - baq 6y ago
    if you want to collect cycles, you have to find them, and may cause pauses.
  - pjmlp 6y ago
    There are always pauses at runtime, when a reference reaching the count of zero starts a domino effect of references being decreased to zero. Which is why in most high performance RC, you get a tracing GC in disguise, because the actual deletion is moved into a background cleaning thread. An example of this in production is the C++/WinRT framework for COM/UWP.
    - turbinerneiter 6y ago
      Ah, that's true.
    - elcritch 6y ago
      In that regard it's not too dissimilar to Rust's semantics when memory is free'ed (https://news.ycombinator.com/item?id=23362518 https://news.ycombinator.com/item?id=23362518). Nim's ARC does inject refs/decrs, but they're not atomic which means it's overhead can be pretty minimal. I don't know if ObjC/Swifts ARC uses atomics or locking. GTK's object system for example uses locking which makes it pretty expensive.
loxs 6y ago
Is there a good reason to invest time in Nim for someone who already knows and likes Rust?
- PMunch 6y ago
  It entirely depends on what kind of things you want to do. For example if you want to program microcontrollers with a modern language and 0 overhead over C then Nim is a great language to learn. Or if you want to write a web front-end and back-end in the same language that compiles to JS and C respectively then Nim is yet again a great language. Or if you just want to get into programming with macros to boost your productivity or make nice patterns in your code, then Nim is a great language. Or if you are just curious as to what else that is out there, then Nim is a great language.
  - loxs 6y ago
    I am more interested in having a great ecosystem and tooling. Probably I just want a better, faster and safer Java/C#/Go. All of these seem to be quite true with Rust.
    - arc776 6y ago
      Whilst there is a pretty well fleshed out stdlib, since Nim can compile to C, C++, Javascript, and even LLVM, you can use any library written for those languages/platforms. That's a huge mass of ecosystems that are natively accessible. Nim's FFI is excellent and makes this very easy without worrying about the ABI (since you're compiling to the target languages). There's also excellent interop with Python with embedding Python within Nim or calling Nim from Python.
      - loxs 6y ago
        This sounds like "wishful programming" without type safety (or needs writing types as libraries). The only place where I've seen this working well is in TypeScript and it has a massive community (and Microsoft) behind its back. Currently I write backends in Rust and frontends in TypeScript and it works really, really well.

Tiberium 6y ago

One of the links in the end of the article leads to the RFC which talks exactly about this, see last commit by Araq especially: https://github.com/nim-lang/RFCs/issues/177#issuecomment-696113293 https://github.com/nim-lang/RFCs/issues/177#issuecomment-696... In short: yes, the current plan is to phase out other GCs over time.

supakeen 6y ago
Perfect, all except markAndSweep/go, thank you!

beagle3 6y ago

> Will the GCs (since ARC isn't really a GC) be deprecated at that time? Not sure why you don't consider ARC a gc - it is, with the caveat that it doesn't break cycles on its own. If you have cycles you aren't going to break on your own, use ORC.

pjmlp 6y ago

> Will the GCs (since ARC isn't really a GC) be deprecated at that time? Any form of reference counting is definitely a GC. http://gchandbook.org/contents.html http://gchandbook.org/contents.html (chapter 5)

turbinerneiter 6y ago
I guess the more interesting questions is whether it happens at compile time or run-time - ARC definitely injects derefs at compile time and therefore there are no gc-"pauses" at runtime. (Right?)
- baq 6y ago
  if you want to collect cycles, you have to find them, and may cause pauses.
- pjmlp 6y ago
  There are always pauses at runtime, when a reference reaching the count of zero starts a domino effect of references being decreased to zero. Which is why in most high performance RC, you get a tracing GC in disguise, because the actual deletion is moved into a background cleaning thread. An example of this in production is the C++/WinRT framework for COM/UWP.
  - turbinerneiter 6y ago
    Ah, that's true.
  - elcritch 6y ago
    In that regard it's not too dissimilar to Rust's semantics when memory is free'ed (https://news.ycombinator.com/item?id=23362518 https://news.ycombinator.com/item?id=23362518). Nim's ARC does inject refs/decrs, but they're not atomic which means it's overhead can be pretty minimal. I don't know if ObjC/Swifts ARC uses atomics or locking. GTK's object system for example uses locking which makes it pretty expensive.

loxs 6y ago

Is there a good reason to invest time in Nim for someone who already knows and likes Rust?

PMunch 6y ago
It entirely depends on what kind of things you want to do. For example if you want to program microcontrollers with a modern language and 0 overhead over C then Nim is a great language to learn. Or if you want to write a web front-end and back-end in the same language that compiles to JS and C respectively then Nim is yet again a great language. Or if you just want to get into programming with macros to boost your productivity or make nice patterns in your code, then Nim is a great language. Or if you are just curious as to what else that is out there, then Nim is a great language.
- loxs 6y ago
  I am more interested in having a great ecosystem and tooling. Probably I just want a better, faster and safer Java/C#/Go. All of these seem to be quite true with Rust.
  - arc776 6y ago
    Whilst there is a pretty well fleshed out stdlib, since Nim can compile to C, C++, Javascript, and even LLVM, you can use any library written for those languages/platforms. That's a huge mass of ecosystems that are natively accessible. Nim's FFI is excellent and makes this very easy without worrying about the ABI (since you're compiling to the target languages). There's also excellent interop with Python with embedding Python within Nim or calling Nim from Python.
    - loxs 6y ago
      This sounds like "wishful programming" without type safety (or needs writing types as libraries). The only place where I've seen this working well is in TypeScript and it has a massive community (and Microsoft) behind its back. Currently I write backends in Rust and frontends in TypeScript and it works really, really well.