https://github.com/ziglang/zig
there is also V.
but seriously! there's so much more reusable tooling and instrumentation for go, and it's the only language with coroutines and fifo queues as first class syntactic elements.
most programming languages are not built with simplicity as a key value, and go's got enough years behind it that you can depend on it, and unlike almost every other language, it's still possible to pick up ten year old code and use it, almost without any extra effort required.
you can't say that about any ANY other language. with Ken Thompson in the leadership it's got the best pedigree of any language too.
Yeah V is pretty good too.
Go is my daily driver. I love it. I don't use anything else unless there's a reason. A bit opinionated wrt package management but that seems to be improving.
But I do find it annoying that I can't easily reason about stack/heap allocation etc. I would really like it if Go had the option of immutability and borrowing.
We are missing the perfect language.
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.
