Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pros and Cons of Nim

onlinetechinfo.com

Post reply on HN
Print view View original

51–60 of 86 posts

Re: Pros and Cons of Nim

#51

Post by PMunch »

m4r35n357 wrote: post #30

Nim currently in uber-cool phase. I love it. After adding a million requested features it will end up bloated like all the others . . .

Nim has been trimming stuff out of its stdlib instead of adding them lately. And because of its huge focus on meta-programming almost anything can fit in an external package anyways (even async is a module in Nim, without any specific support in the compiler). The Nim language as such seems to be "complete" as it is now, and I'd say it's quite unlikely to gain bloat in any way that would affect people not using the bloated parts (i.e. the compiler will still stay fast).

Re: Pros and Cons of Nim

#52

Post by beagle3 »

tomp wrote: post #44

> Memory leaks are not a concern as Nim uses one of several available garbage collectors. The new ARC option works with reference counting instead of a GC. Using "no memory leaks" and "reference counting" in the same sentence is #fakenews . Reference counting leaks cycles unless accompanied with a tracing GC (at which point reference counting makes little sense).

> Reference counting leaks cycles unless accompanied with a tracing GC (at which point reference counting makes little sense).

Python proves otherwise. Reference counting gives you deterministic memory use and finalization except when a cycle is involved. The tracing GC helps for those cases (and libraries) that do introduce cycles.

If each one of your objects is in a cycle, then -- yes, reference counting makes no sense. If only 1% of your objects are in a cycle, it makes 99% sense.

Re: Pros and Cons of Nim

#53

Post by beagle3 »

rlp wrote: post #26

I'm a big fan of Nim, but I really wish it supported cyclic type declarations in separate files and out-of-order functions without forward declarations. As it is, I'm constantly structuring things around those limitations. Big projects often end up squeezed into a single huge file (or a few huge files).

consider `include` instead of `import` if you want to break things down to smaller files.

Also, I'm with Araq on this one -- in my experience, every time I reached for a cyclic-cross-file-type-declaration, there was a much simpler acyclic solution I found later.

Re: Pros and Cons of Nim

#54

Post by tomp »

beagle3 wrote: post #52
tomp wrote: post #44

> Memory leaks are not a concern as Nim uses one of several available garbage collectors. The new ARC option works with reference counting instead of a GC. Using "no memory leaks" and "reference counting" in the same sentence is #fakenews . Reference counting leaks cycles unless accompanied with a tracing GC (at which point reference counting makes little sense).

> Reference counting leaks cycles unless accompanied with a tracing GC (at which point reference counting makes little sense). Python proves otherwise. Reference counting gives you deterministic memory use and finalization except when a cycle is involved. The tracing GC helps for those cases (and libraries) that do introduce cycles. If each one of your objects is in a cycle, then -- yes, reference counting makes no s…

Python is a trivial special case as it has no concurrency. In a single-threaded language, that indeed makes sense. Multi-threaded RC is extremely tricky to implement efficiently, so unless you can prove there's no cycles (or you don't care it it leaks memory), it makes little sense.

Re: Pros and Cons of Nim

#55

Post by beagle3 »

The_rationalist wrote: post #47
pjmlp wrote: post #43

Earlier quoted context omitted.

Actually type safe, with support for various kinds of automatic memory management. Pascal dialects, while much safer than C, suffer from use-after-free and possible memory leaks, also you don't need to mark unsafe code as such. This includes any modern Pascal variant.

Why use nim over Kotlin with AOT?

I'm not familiar enough with Kotlin to give a real answer, but from what I do know the following might be relevant:

* Backends: Nim compiles to JS both directly, and indirectly (emscripten) with various trade-offs (e.g. 64 bit ints require emscripten). It also compiles to C, C++ and Objective C giving you the simplest most efficient FFI to those languages one can hope for (including e.g. exception handling) while at the same time addressing the largest set of platforms (got a C compiler? you can use Nim). And you also have (almost but not yet quite production quality) native code compiler NLVM. What's the platform range of Kotlin's AOT?

* Metaprogramming: Nim's metaprogramming ability is second only to Lisp[0], I think, and only because Lisp has reader-macros (whereas you can't ignore Nim's syntax with macros, as flexible as it is). For example, Nim's async support (comparable to Python and C#) is a user-level library. So is, for example, pattern matching. Can Kotlin do that?

* Size: Nim compilation through C produces standalone and (relatively) tiny executables; it matters for embedded platforms. How does Kotlin fair in this respect?

[0] Lisp, scheme and other Lisp derived languages, of course.

Re: Pros and Cons of Nim

#56

Post by m4r35n357 »

PMunch wrote: post #51
m4r35n357 wrote: post #30

Nim currently in uber-cool phase. I love it. After adding a million requested features it will end up bloated like all the others . . .

Nim has been trimming stuff out of its stdlib instead of adding them lately. And because of its huge focus on meta-programming almost anything can fit in an external package anyways (even async is a module in Nim, without any specific support in the compiler). The Nim language as such seems to be "complete" as it is now, and I'd say it's quite unlikely to gain bloat in any way that would affect people not using the b…

Great to hear. Just hope they can resist the inevitable flood of "good ideas" and stick to their design.

[EDIT] recognized your nick from IRC a while back, my "good idea" is still to add support for 80-bit floats ;)

Re: Pros and Cons of Nim

#57

Post by beagle3 »

sagichmal wrote: post #7
lactobacillis wrote: post #6

Earlier quoted context omitted.

People complain about lack of generics and proper try/except/finally in Go. Nim has both.

And no native concurrency.

Why do you say that?

It's far from perfect but it does work (and has for a few years), and it helps you by requiring proof that actions are disjoint. There is work now on including Z3 which would work this much smarter.

https://nim-lang.org/docs/manual_experimental.html#parallel-...

Re: Pros and Cons of Nim

#58

Post by ptx »

The_rationalist wrote: post #47
pjmlp wrote: post #43

Earlier quoted context omitted.

Actually type safe, with support for various kinds of automatic memory management. Pascal dialects, while much safer than C, suffer from use-after-free and possible memory leaks, also you don't need to mark unsafe code as such. This includes any modern Pascal variant.

Why use nim over Kotlin with AOT?

I'm hopeful that Kotlin/Native will improve in these areas (excepting the last one) but:

* Faster compilation.

* Tooling is less memory-hungry.

* C++ interop.

* Macros.

Re: Pros and Cons of Nim

#59

Post by The_rationalist »

ptx wrote: post #58
The_rationalist wrote: post #47

Earlier quoted context omitted.

Why use nim over Kotlin with AOT?

I'm hopeful that Kotlin/Native will improve in these areas (excepting the last one) but: * Faster compilation. * Tooling is less memory-hungry. * C++ interop. * Macros.

Why macros vs decorators?

Re: Pros and Cons of Nim

#60

Post by beagle3 »

tomp wrote: post #54
beagle3 wrote: post #52

Earlier quoted context omitted.

> Reference counting leaks cycles unless accompanied with a tracing GC (at which point reference counting makes little sense). Python proves otherwise. Reference counting gives you deterministic memory use and finalization except when a cycle is involved. The tracing GC helps for those cases (and libraries) that do introduce cycles. If each one of your objects is in a cycle, then -- yes, reference counting makes no s…

Python is a trivial special case as it has no concurrency. In a single-threaded language, that indeed makes sense. Multi-threaded RC is extremely tricky to implement efficiently, so unless you can prove there's no cycles (or you don't care it it leaks memory), it makes little sense.

Oh, so now it's about "efficiently". Goal posts have moved.

No, it's not hard at all to implement efficiently as long as objects don't cross a thread boundary (and e.g. Nim's older GC used to enforce that condition, an old version of K tracked it and switched to "lock; xadd" to count references when something did cross a thread boundary IIRC, which made it inefficient only for those objects that crossed the boundary which usually weren't many.

It's way simpler than multithreaded mark&sweep, for example. Regardless - it makes a lot of sense. It might not make a lot of sense to you, but it does in general in most contexts.

Post reply on HN