Considering that people developing programs that target embedded devices seem to do their development on a normal host (where Zig already runs), I think it would make sense to integrate other libc implementations via packages, that get downloaded automatically when you target specific embedded targets.
Similar to how c/c++ is suspected to be handled when llvm is removed from the compiler, that it gets downloaded as package when you use it.
But I also wonder whether the existing bundled libc implementations could get further “treatment” to add additional tricks used by picolibc?
What makes picolibc smaller, is it removing features, sharing more code, removing optimizations, reducing generality / removing special cases?
Could you get similar results if you started with a normal libc but applied a specific set of optimizations, maybe even specifically written for this purpose to it?
So if picolibc is a set of things you can’t really replicate through some automated process, I think it would be better as a package, if you somehow can replicate it or get similar results, through applying some transformation to a “normal” libc then that would seem more interesting.
I think ultimately somebody would have to be familar with Zigs bundled libcs and how picolibc is implemented, to be able to say whether it makes sense to mix them in any way.
I think it is relatively unlikely that adding picolib to the existing bundle makes sense, from a compressability and similarity to the existing elements viewpoint.
And as soon as it is its own unit, it seems appropriate to make it some package (maybe even an official package that is seen as part of the language).
Another thing I wonder about, is how an embedded libc would look like when you start from scratch, in the context of using it from Zig and using Zigs features.
For example whether comptime or specialized build steps would make its design more flexible / elegant or easier to optimize in some automated manner.
I think an implementation that is written in Zig would have a higher likelihood to end up in the initial language distribution / download (I also think there was an issue for creating a Zig libc implementation).
Personally I think putting things in packages is good and keeping the initial download to the most common things, I don’t think packages should be seen as a lower level of support/importance.
But which package/implementation gets more Zig/community attention and support, then has an effect on which approaches are more supported and better integrated into the language.
I think a libc written in Zig would just naturally lead to more Zig developers working on it, and the compiler is more likely able to create highly optimized builds of it.
