Aleph lacked GC, which Rob Pike considered the main reason for its implementation failure on Plan 9, and initially bounds checking was also missing.
Two key design difference from Go and its two predecessors.
Dis is an implementation detail, Go could offer the same dynamism with AOT toolchain, as proven by other languages with ahead of time toolchains available.
So does Rust. Rust is 'smarter' than Limbo, in that it can avoid using its GC in a lot of cases (but not all, hence why it still has GC to fall back on when necessary), but, I mean, that discovery was the reason for why Rust was created. Limbo was already there otherwise. Every new language needs to try to add something into the mix.
Still, the thoughts were in common, even though the final solution didn't end up being exactly the same.
Rust does not have a garbage collector in any way or form. It's just automatic memory like we're used to (e.g., stack in C++), with the compiler injecting free/drop when an object goes out of scope.
What Rust brings is ownership with very extensive lifecycle tracking, but that is a guard rail that gives compile-time failures, not something that powers memory management.
(If you consider the presence of Rc<T> to make Rust garbage collected, then so is C garbage collected as developers often add refcounting to their structs.)
> so is C garbage collected as developers often add refcounting to their structs.
Absolutely, C also can use a garbage collector. Obviously you can make any programming language do whatever you want if you are willing to implement the necessary pieces. That isn't any kind of revelation. It is all just 1s and 0s in the end. C, however, does not come with an expectation of it being provided. For all practical purposes you are going to have to implement it yourself or use some kind of third-party solution.
The difference with Limbo and Rust is that they include reference counting GCs out of the box. It is not just something you have the option of bolting onto the side if you are willing to put in the effort. It is something that is already there to use from day one.
It is not C using the garbage collector - it is you writing a garbage collector in C. The application or library code you develop with the language is not itself a feature of the language, and the language you wrote the code in is not considered to be "using" your code.
Rust and C are unaware of any type of garbage collection, and therefore never "use" garbage collection. They just have all the bells and whistles to allow you to reference count whatever type you'd like, and in case of Rust there's just a convenient wrapper in the standard library to save you from writing a few lines of code. However, this wrapper is entirely "bolted onto the side": You can write your own Rc<T>, and there would be no notable difference to the std version.
So no, neither Rust nor C can use a garbage collector, but you can write code with garbage collection in any feature-complete language. This is importantly very different from languages that have garbage collection as a feature, like Limbo, Go, JavaScript, etc.
That's right, you can write a garbage collector in C for C to use. You can also write a garbage collector in C for Javascript to use, you could even write a garbage collector in C for Rust to use, but in this case we are talking about garbage collector for C to use.
If you are writing a garbage collector that will not be used, why bother?
This feels like it's into trolling, so one last round:
The C language does not use your C code, it is your C code that uses the C language.
The tools available to C is what the language specification dictated and what the compiler implemented. For example, C might use stack memory and related CPU instructions, because the C specification described "automatic memory" and the compiler implemented it with the CPU's stack functionality. It might insert calls to "memcpy" as this function is part of the C language spec. For C++, the compiler will insert calls to constructors and destructors as the language specified them.
The C language does not specify a garbage collector so it can never use one.
You, however, can use C to write a garbage collector to manually use in your C code. C remains entirely unaware of the garbage collectors existence as it has no idea what the code you write does - it will never call it on its own and the compiler will never make any decisions based on its existence. From C's perspective, it's still just memory managed manually by your application with your logic.
In JavaScript and Go, the language specifies the presence of garbage collection and how that should work, and so any runtime is required to implement it accordingly. You can write that runtime in C, but the C code and C compiler will still not be garbage collected.
The C standard is actually carefully written to allow for placing distinct "objects" in separate memory segments of a non-flat address space, such that ordinary pointer arithmetic cannot be expected to reach across to a separate "object". This is not far from allowing for some sort of GC as part of low-level C implementation, and in fact the modern Fil-C relies on it.
This is actually quite an interesting topic in its own right, but not quite the discussion above, which is about whether C or Rust include a GC or is considered to "use" the GC you hand-rolled or pulled in from a library.
I wouldn't consider FilC's GC a GC in the conventional sense either, in that code compiled with Fil-C is still managed manually, with the (fully-fledged) GC effectively only serving as a way to do runtime validation and to turn what would otherwise be a UAF with undefined behavior into a well-defined and immediate panic. This aspect is in essence an alternative approach to what is done by AddressSanitizer.
I'll have to look a bit more into Fil-C though. Might be interesting to see how it compares to the usual sanitizers in practice.
Your impression that there is a semantic authority misses the mark. While you are free to use English as you see fit, so too is everyone else. We already agreed on the intent of the message, so when I say something like "C uses C code", it absolutely does, even if you wouldn't say it that way yourself. I could be alone in this usage and it would remain valid. Only intent is significant.
However, I am clearly not alone in that style of usage. I read things like "Rust can use code written in C" on here and in other developer venues all the time. Nobody ever appears confused by such a statement even. If Rust can use code written in C, why can't C use code written in C?
> The C language does not specify a garbage collector so it can never use one.
The C language also does not specify a linked list. Go tell your developer friends that C can never use a linked list. Please take a photo when they look at you like you have two heads. Admittedly I lack the ability to say something so outlandish to another human with a straight face, but for the sake of science I put that into an LLM. It called me out on the bullshit, pointing out that C can, in fact, use a linked list.
For what it is worth, I also put "C can never use a garbage collector" into an LLM. It also called me out on that bullshit just the same. LLMs are really good at figuring out how humans generally use terminology. It is inherit to how they are trained. If an LLM is making that connection, so too would many humans.
> In JavaScript and Go, the language specifies the presence of garbage collection
The Go language spec does, no doubt as a result of Pike's experience with Alef. The JavaScript spec[1] does not. Assuming you aren't making things up, I am afraid your intent was lost. What were you actually trying to say?
> C code and C compiler will still not be garbage collected.
That depends. GC use isn't typical in the C ecosystem, granted, but you absolutely can use garbage collection in a C program. You can even use something like the CCured compiler to have GC added automatically. The world is your oyster. There is no way you couldn't have already realized that, though, especially since we already went over it earlier. It is apparent that your intent wasn't successfully transferred again. What are you actually trying to say here?
> This is turning into trolling.
The mightiest tree in the forest could be cut down with that red herring!
[1] The standard calls itself ECMAScript, but I believe your intent here is understood.
> The C language also does not specify a linked list. Go tell your developer friends that C can never use a linked list.
They would not blink because the statement is accurate. To the C language and to the C compiler, there are no linked lists - just random structs with random pointers pointing to god knows what. C does know about arrays though.
> The JavaScript spec[1] does not [specify garbage collection].
I have good reason to believe that you are not familiar with the specification, although to be fair most developers would not be familiar with its innards.
The specification spends quite a while outlining object liveness and rules for when garbage is allowed to be collected. WeakRefs, FinalizationRegistries, the KeptObjects list on the agent record, ...
Just like with Go, it is perfectly valid to have an implementation of a "garbage collector" that is a no-op that never collects anything, which means that the application will continously leak memory until it runs out and crashes as the language provides no mechanism to free memory - for Go, you can switch to this with `GOGC=off`. The specific wording from ECMA-262:
> This specification does not make any guarantees that any object or symbol will be garbage collected. Objects or symbols which are not live may be released after long periods of time, or never at all. For this reason, this specification uses the term "may" when describing behaviour triggered by garbage collection.
If you're not used to reading language specs the rest of the details can be a bit dry to extract, but the general idea is that the spec outlines automatic allocation, permission for a runtime to deallocate things that are not considered "live", and the rules under which something is considered to be "live". And importantly, it provides no means within the language to take on the task of managing memory yourself.
This is how languages specify garbage collection as the language does not want to limit you to a specific garbage collection algorithm, and only care about what the language needs to guarantee.
> [1] The standard calls itself ECMAScript, but I believe your intent here is understood.
sigh.
> For what it is worth, I also put "C can never use a garbage collector" into an LLM. It also called me out on that bullshit just the same.
more sigh. LLMs always just wag their tails when you beg the question on an opinion. They do not do critical thinking for you or have any strong opinions to give of their own.
> To the C language and to the C compiler, there are no linked lists
But are most certainly able to use one. Just as they can use a garbage collector. You are quite right that these are not provided out of the box, though. If you want to use them, you are on your own. Both Limbo and Rust do provide a garbage collector to use out of the box, though, so that's something different.
> The specification spends quite a while outlining object liveness and rules for when garbage is allowed to be collected. WeakRefs, FinalizationRegistries, the KeptObjects list on the agent record, ...
But, again, does not specify use of a garbage collector. It could use one, or not. That is left up to the implementer.
> it is perfectly valid to have an implementation of a "garbage collector" that is a no-op that never collects anything
It's perfectly valid as far as the computer is concerned, but in the case of Go not spec-compliant. Obviously you don't have to follow the spec. It is not some fundamental law of the universe. But if you want to be complaint, that is not an option. I get you haven't actually read the spec, but you didn't have to either as this was already explained in the earlier comment.
> This is how languages specify garbage collection
That is how some languages specify how you could add garbage collection if you so choose. It is optional, though. At very least you can always leak memory. Go, however, explicitly states that it is garbage collected, always. An implementation of Go that is GC-less and leaks memory, while absolutely possible to do and something the computer will happily execute, does not meet the conditions of the spec.
I would say that RC is GC, yes, as it is most definitely technically true. But it was pjmlp who suggested it originally (Limbo also uses reference counting), so we have clear evidence that others also see reference counting as being GC. We wouldn't have a discussion here otherwise.
While RC is a GC algorithm, chapter 5 from GC handbook, it doesn't count when it isn't part of the type system because then it becomes optional and not part of the regular use of the programming language.
Additionally Limbo's GC is a bit more complicaticated than a plain add_ref()/release() pair of library calls.
The person running this who was probably paid thousands of pounds worth of currency should have put in the time to produce a more accurate measure of mental health
Perhaps the reason people keep repeating it is that someone makes the statement without any reasons, provides an alternative again without any reasons.
"Why are you not using docker to sandbox your code?"
"Umm.. someone on HN told me docker is not a sandbox, to use randomtool instead"
Firefox doubled down on using/selling user data for advertising purposes, so that's a big reason for avoiding it.
I held onto it as someone who didn't even like the politics of the people behind it (the beauty of open source), for the sake of browser engine diversity, but changing terms of service of use of personal data was the final blow
It seems irrational to me to switch to chrome (and where else could you switch to?) over data sale concerns. A more rational approach could be a Firefox fork that preserves privacy.
Statistics show that kids brought up with both parents have much better prospects in life.
The decision to have kids should be a deliberate commitment between the parents, not some kind of lottery where one falls pregnant then decides what to do next.
Application toolkits will eventually drop support for X11. GTK will remove it in GTK5. Not sure what Qt's plans are, but I'd have to think X11 support is long for this world there as well.
GNOME is an outlier and not indicative of general trends. They pretty much do what they want, as a silo, ignoring the larger ecosystem. They want you to use their software stack all the way through.
It's a shame about all the political bullshit they injected into the project, which already resulted in it being removed from several package repositories. I hope someone makes another fork in the vein of xlibre, but without political bullshit.
When thinking about Christianity, I personally make the distinction between the Christian faith, and the various Churches i.e. the political institutions that grew around the Christian faith.
In its first few centuries Christianity was community-centered, until about the 4th century when it started getting institutionalized in Rome.
Does that mean to say "the Chinese government regularly subsidizes BYD"? Because the US regularly subsidize Ford, and I don't think you'll find any one that disagrees with that.
Great job in training nigeriens to pick up fossil preservation work. Glad the government is taking a rational approach in collaborating with the US based archeologist.
reply