-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Like all other languages voted to the HN front page that claim that they have magically solved memory management, this project's website is simply lying.
Looking at https://github.com/evincarofautumn/kitten/issues/193: "Does kitten require garbage collection?" -- "Nope. [...] The plan is that boxed lists ([…], List) and closures ({…}) are reference-counted" and https://github.com/evincarofautumn/kitten/issues/131: "Explore GC strategies" -- "The C backend currently uses naïve reference counting."
A quick skim of kitten.c confirms that objects have a reference count field and are only really released when it drops to zero. (I didn't find code that increments the reference count, but I find it hard to care.)
The project's website claims:
> Automatic management of memory and resources with no garbage collector.
One can weakly argue that many people mean tracing garbage collection when they speak of garbage collection, and that reference counting is not garbage collection in this narrow sense. This is unhelpful at best.
The FAQ has the claim I quoted above, of which the "when you drop a value from the stack, it gets deallocated" appears to be simply false.
> No, that's not correct.
See the commit for yourself! They removed the sharing between string values when you created a substring a while ago.
https://github.com/openjdk/jdk/commit/f55750d05a04484b719220...