i dunno about immutability. i mean, i find it problematic that strings are by force in this way locked, since passwords come in this way there's some sanitation issues with that. and there is gonna be some adding of overhead with MMU having a huge map of immutables, and in general, the whole reason to have immutability is to avoid race conditions, and i'm very strict about atomics and mutexes on any shared data.

i'd rather remove immutability from strings and a simple static analysis could reveal what data needs to be mutex protected.

i'd also rewrite the entire 'fmt' library to work with an alias of []byte types and the 'strings' library too, so it's all built to be mutable.

the stack/heap allocation stuff can literally be avoided with GOGC set to zero. you just have to probably write a bunch of libraries that do your memory handling for you. a lot of unsafe stuff could easily be done with freelists managing blobs, it would require an allocation manager.

it would certainly be cool if you could drop in alternative runtime back ends in place of the default one. and if possible, make these blobs shared libraries so they can not be repeated in every binary.

imo, the whole shennanigans with generics was such a waste of time making changes to the language that have really borne minimal benefits. the two issues you name are far more important to broadening the use cases, flexibility and efficiency of the language.

as for avoiding big allocations and stuff, i am always considering this in how i write my code. i tend to do a lot of explicit variable declaration and try to move them explicitly outside of loops since the compiler could miss that and be running allocations pointlessly when a pointer can be reused easily and the GC can easily identify when a big long list of pointers need to be freed up.

things like network handlers, it's pretty easy to just make one collection of buffers and always reuse them so GC doesn't touch them.

good to know you are also a go maxi :) too many wishy washy people with fondness for following what is 'cool', not even considering for a minute that cool is not necessarily practical or secure, or efficient.