> I don't see much room for a new language that isn't memory-safe in 2022. IMHO these are the only valid reasons for unsafe code in a systems language: 1. in

> I don't see much room for a new language that isn't memory-safe in 2022. IMHO these are the only valid reasons for unsafe code in a systems language: 1. interfacing with unsafe external code (e.g. call the kernel directly) 2. implement the language runtime/GC itself 3. access hardware capabilities not exposed in the language (e.g. SIMD, GPU, memory-mapped IO, memory barriers) These are semi-valid to bad reasons for unsafe code: 4. generate new machine code to, e.g. implement a guest language 5. explore the performance ceiling for a very specific code pattern that would otherwise be inline asm For Virgil, I am at reasons 1 and 2. For Wizard, I am at 4 and 5.