Nim 2 doesn’t require gc, with arc/atomicArc. The only thing you really need to be careful about is when you use ref types or custom owning types. Otherwise, manual memory management can be done in Nim pretty easily.

Hypothetically you could importcpp fns, classes, etc when compiling with nim cpp

▲

cb321 6 days ago | parent [-]

We have zero disagreement here (actually true of all responses to my comment - an odd circumstance on HN). What you call "`ref` types" is what I meant by "GC'd types". I actually like that the Nim compiler changed from `--gc=X` to `--mm=X` a while back as the key distinction is (& has always been) "automatic vs. manual".

Elaborating on this cross-talk, any academic taxonomy says reference counting is a kind of GC. { See, the subtitle or table of contents of Jones 1996 "Garbage Collection: Algorithms for Automatic Dynamic Memory Management", for example. } Maybe you & I (or Nim's --mm?) can personally get the abbreviation "AMM" to catch on? I doubt it, but we can hope!! :) Sometimes I think I should try more. Other times I give up.

Before the late 90s, people would say "tracing GC" or "reference counting GC" and just "GC" for the general idea, but somehow early JavaVM GC's (and their imitators) were so annoying to so many that "The GC" came to usually refer, not just to the abstract idea of AMM, but to the specific, concrete separate tracing GC thread(s). It's a bit like if "hash table" had come to mean only a "separately chained linked list" variant because that's what you need for delete-in-the-middle-of-iterating like C++ STL wants and then only even the specific STL realization to boot { only luckily that didn't happen }.

▲

tialaramex 5 days ago | parent [-]

The open addressed hash tables basically don't exist for a long time. The various strategies for collision handling in these tables are from the 1980s or later and if you don't have a collision strategy you can't use this as a general purpose container. I'm pretty sure I never used a hash table which didn't use separate chaining until at least the 1990s and perhaps later.

So that's maybe a bad example. In the same way I think it's fine that "Structured programming" is about the need to use structured control flow, not the much later idea of structured concurrency even though taken today you might say they both have equal claim to this word "structured".

In contrast it is weird that people decided somehow "Object oriented" means the features Java has, rather than most of what OO was actually about when it was invented. I instinctively want to blame Bjarne Stroustrup but can't think of any evidence.

▲

cb321 5 days ago | parent [-]

I can't speak to what libraries you used, but both techniques have been broadly used in common practice since the 1950s. According to the "History" subsection in Knuth TAOCP v3 at the very end of 6.4 (whose very first edition written in 1972 covered OA with various probe/collision strategy ideas), both open addressing & separate chaining were co-invented at IBM in 1953/54 by Luhn & Amdahl. You may be confusing the Celis 1985 Robin Hood hashing work with just the open addressing part? Anyway, as you say, it may be a strained example/analogy. "OO" & "concurrency" both have a lot going on, too.

Anyway, like the "major" modes of hash collision resolution, reference counted GC has also been around concurrently (haha) with ref tracing GC since the dawn of modern computing. Unix hard-links (& other things) codify ref counting into filesystems.. Python has always had ref-counted GC, older Lisp more focused on tracing GC, etc., etc. Popularity measures are notoriously difficult.

Mostly people like to abbreviate { like having a search $PATH instead of using /bin/foo everywhere }. The whole point of abstraction is to neglect details. Neglect naturally leads to forgetting (or never learning/knowing). Ignorance leads people to cross-talk (or worse willfully misinterpret/project). Cross-talk leads to suffering. Yoda out. ;-)

EDIT: Also, speaking of abbreviation & clarity, in Nim "arc" has, at least until this writing, always stood for Automatic Reference Counting, not Atomic Ref Counting as seems the more rusty terminology and is vaguely suggested by @miguel_martin, to whom I originally replied with an "arc/atomicArc", though it seems like, in Nim 3, it may become both Automatic & Atomic, but probably not changing its abbreviation to "AARC".

	▲	tialaramex 5 days ago \| parent [-]
		None of the schemes I was aware of pre-date Celis in 1985 but it's apparent upon actually reading Celis [which I hadn't done previously] that he's only improving on an existing state of the art, so I was entirely wrong about that. That state of the art was pretty dire by my reckoning, but it's clear that it would have worked so I was entirely wrong and I apologise for being so assertive when in fact I clearly didn't know what I was talking about.