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?
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?
In short: yes, the current plan is to phase out other GCs over time.
Any form of reference counting is definitely a GC.
http://gchandbook.org/contents.html (chapter 5)
(Right?)
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.
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.
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.
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.
Currently I write backends in Rust and frontends in TypeScript and it works really, really well.
Nim being able to compile to Javascript and, say, C means you can write your server and web client in the same language. This means you can share code between client and server which is particularly handy for having modules with type declarations imported by both for example, so you have a unified place to update them.
You also get to use Nim's strong type guarantees and metaprogramming when outputting Javascript. An example of why this is useful is generating say, RPC calls from a static JSON file that are automatically unified between server and client.
Another productivity benefit is compiling to C, C++, and Javascript means you can natively use libraries from those languages.
If you want to go deeper, check out the extremely powerful metaprogramming capabilities that rival Lisp and I would argue are much more advanced than Rust. The end result of this is very nice syntax constructions which means easy to read code, and again translates to high productivity with no performance loss.
In terms of use I find it feels a lot like a better Pascal but with powerful metaprogramming.
Nim is strongly, statically typed. Also, I agree and aside from performance it's why I started using Nim instead of Python for my gamedev hobby. Dynamic typing isn't good for large projects. Nim has great type inference though, so you get the readability of Python but with strong compile time type guarantees.
Eg;
type SpecialId = distinct int # This int is now type incompatible with other ints
proc handleId(id: SpecialId) =
# ... do something with id.