[extremely "looking to start a fight" voice] of course it's possible to write an OS kernel in a garbage-collected language. even linux has ref-counted kobjects 
i think it's very funny that modern computer touchers have decided that reference counting isn't garbage collection and i'm like 60% sure it's just because computer touching culture spent a few generations under the control of the kind of guy who thinks garbage collection is for babies, but you can do reference counting in C so it must not be the same kind of thing
i think that garbage collection is cool actually and if you want to be a big tough weenie about your programming chops then you should put your money where your mouth is and stop using dynamic memory allocation entirely
do you think i could convince the suckless dweebs that malloc should be considered harmful and every program should reserve all its memory with a single global 64k array
oh right they make a point of pride out of never calling free because "the operating system is going to reclaim the memory anyway" so that isn't going to work
i make a lot of hay about how silly the "unix philosophy" is but you know i think there absolutely is merit in building a managed dynamic system where only the most fundamental functionality is implemented at the machine level and is partitioned into minimal self-contained units. i just think that the specific abstract machine that unix builds this way is pathologically badly designed
but on the topic of garbage collection: it doesn't solve general resource management. all of the problems with manual memory management apply to file descriptors and sockets and locks and so on. and, it isn't necessarily an appropriate solution for managing general data in every part of every application in every environment.
but that doesn't mean garbage collection is bad. it doesn't mean it shouldn't be implemented in the One Language to Bind Them All. it doesn't even mean it shouldn't be the default behavior. it just means that the question of whether to use garbage collection to handle a certain class of data should be under the programmer's control, and at a finer granularity than the question of what programming language to write your entire thing in.
@sjolsen "I use processes as a lightweight abstraction to create allocator pools" 
@87flowers@mk.absturztau.be@sjolsen@tech.lgbt as a data point, zig sort of forces you to avoid dynamic allocation by making it painful, and due to this i have written software that makes no dynamic allocations.
@monoidmusician@sjolsen i heard someone describe them as duals … but like, in the sense that they are complementary, not direct opposites
@40whirl@sjolsen the generations are still counting! (not in a generational gc)
@sjolsen I mean I think there's a valid argument that often reference counting is more obvious and thus easier to reason about when it's going to do stuff but that only really applies in like. the Linux Kernel and things written directly in C because there you kind of know most of the time how many refcounts you should have and rely on it most of the time as a fallback.
But like we could probably innovate stuff back into GC stuff. Also as an aside I think it's also partially that GC has come to mean some combo of "can collect cycles" and "is invisible to the programmer" which isn't always true (weak references still need to exist)
@sjolsen also there's an interesting example in the form of Apple's "ARC" reference counting for Objective-C and now Swift which is externally very similar to GC'd languages but is called reference counting