[supakeen]

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]

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-696...

In short: yes, the current plan is to phase out other GCs over time.

[supakeen]

Perfect, all except markAndSweep/go, thank you!

[pjmlp]

> 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 (chapter 5)

[turbinerneiter]

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?)

[pjmlp]

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.

[elcritch]

In that regard it's not too dissimilar to Rust's semantics when memory is free'ed (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.

[turbinerneiter]

Ah, that's true.

[baq]

if you want to collect cycles, you have to find them, and may cause pauses.

[beagle3]

> 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.

[loxs]

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

[PMunch]

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]

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]

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]

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.

[nikki93]

https://nim-lang.org/ -- says "statically typed" within the first 7 words of the main description of the language on the homepage... Most of the features happen through the type system (eg. functions are always top-level and looked up through UFCS), and it has generics and so on.

[arc776]

Nim is strongly, statically typed. It's very type safe.

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.

[kodkuce]

I would too love like c# ecosystem for nim but dont think that is possible especially cuz magic macro stuff. Thing i like about Nim is joy of writing and writing less and kinda started to love whitespaces, only cons i can see is there are not like 20 payed people who work full time for lang

[arc776]

I would say one of Nim's biggest strengths is the productivity of Python with the performance of C; it feels like scripting, but you have production ready performance.

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.

[loxs]

To me this is more of an argument against. Although Python was my first language, I've had my share of burnouts because of its lack of types and difficulties in refactoring big code-bases.

[arc776]

> I've had my share of burnouts because of its lack of types and difficulties in refactoring big code-bases.

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.

[nimmer]

Nim has productivity, expressiveness and readability that matches Python. Not the dynamic typing.

[Tiberium]

Don't be misleaded - the only thing Nim really has from Python is the off-side rule (indentation). Nim is statically typed and compiled to native binaries

[arc776]

Yeah I should have stressed that it's just the productivity that matches Python, not the operation. As you say it's similarity is only skin deep with significant whitespace.

In terms of use I find it feels a lot like a better Pascal but with powerful metaprogramming.

[arc776]

Another reason: compile times are super fast compared to Rust and C++ even with lots of metaprogramming.

[nikki93]

I think this is really important for application programming, and one of the things that is promising to me about Nim. Also the metaprogramming / DSL stuff helps create eg. specific DSLs for UI programming and things like that (something we've seen people like with JSX in React for example). Can do things as far as https://github.com/krux02/opengl-sandbox (OpenGL pipeline DSL) or https://github.com/yglukhov/nimsl (literally converts Nim functions to GLSL (!)).

[cb321]

Compile times can be even faster (like 200 milliseconds) with the TinyCC/tcc backend. (Of course, optimization of the generated machine code suffers some.)