[Ygg2]

> Sure, and when I do the same in Rust I'm also doing manual memory management. So by your definition, both Rust and C are manual memory languages.

You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free.

> So by your definition, both Rust and C are manual memory languages.

No. By my definition what is the default semantics determines if it's manual or automatic. It's CS 101.

But if you want to play these semantics games, you just admitted C is GC language and thus unsuitable for kernel development.

> Uh, even in bog standard Java without any shenanigans you are using an "arena allocator".

No, no you aren't. At least not explicitly. I assume you mean GC, if it has or doesn't have arenas is implementation detail.

It also hinges on Wikipedia being correct that Arena IS manual memory management, which is unsubstantiated at best.

[arghwhat]

> You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free.

I think you're mistakenly thinking of calling out to the (rust-lang maintained) libc crate's malloc/free functions. That's not the case - the standard library provides `std::alloc`, which is the allocator also backing Box and Vec.

> No. By my definition what is the default semantics determines if it's manual or automatic. It's CS 101.

Your definition of default semantics - "in C it's not what the language does but what happens when you call random library functions, while in Rust it's the opposite" - makes no sense at all.

C isn't considered a manual language because of default semantics, but because people have chosen to mainly rely on such paradigm.

> No, no you aren't. At least not explicitly. I assume you mean GC, if it has or doesn't have arenas is implementation detail.

Yes, whether any allocator has an arena is an implementation detail.

Whether you call `malloc` or `new`, or you have Go or Java do a heap allocation for you (which, to nitpick, is not actually the job of the garbage collector), the use of an arena is an implementation detail. In case of GC, the availability of optimizations also depend heavily on whether it's a moving GC.

[Ygg2]

> That's not the case - the standard library provides `std::alloc`, which is the allocator also backing Box and Vec.

Again, emphasis on the word, default. How are you using Box and Vec. Are you by default encouraged to drop them manually via Allocator?

No, you aren't. You're heavily discouraged via usage of `unsafe`, you are discouraged because the compiler does automatic `alloc`/`drop`.

You have to go out of your way to do manual memory management.

> Your definition of default semantics

I showed you what happens when you apply the non-default semantics of a language to C. You end up with nonsensical statements like C is a GC language. Just because a style is possible in language X doesn't mean language X is of that style.

> C isn't considered a manual language because of default semantics, but because people have chosen to mainly rely on such paradigm.

And why is that? Because the default affordance of the language makes it so that way of usage is the most natural to most users. You could put everything in the stack, but that would be extremely torturous for most users, so they use malloc/free.

You give people a knife, of course they will grab it by the handle.