I don't think the goals are explained very clearly. Or, to put it another way, after the goals were explained I still had no idea what it actually does or replaces.
Sorry to cause the confusion, we are building a stdlib for Go, and all these goals are related to the development experience when using our stdlib, and we are not aiming at anything like replacing the official go stdlib (which we also enjoy work with).
Were the confusion caused by the choice of project name `pcz` instead of `xxxstd`? or any suggestion for us to improve?
I think the confusion is caused by the notion of a separate library that is also “stdlib” - which is the version that comes with the official distribution.
This comment is the first time I realised it was not intended to be a drop-in replacement for the Go standard library (in a musl - glibc kind of relationship).
There are a number of languages where there's been an alternative standard library developed, the problem is 'by stdlib do you mean standard-for-the-language or standard-for-you-to-code-against.'
Actual stdlibs tend to be magic. Take Rust's NonZeroU8. This type is an unsigned byte which isn't zero, but as a result the bit pattern where zero would fit is unoccupied and thus Option<NonZeroU8> is also a single byte. This allows code which has the safety and convenience of modern type safety where we can't screw up and forget that None isn't just zero - yet also the performance of a C-style sentinel trick where you just treat zero as indicating None, maybe using macros.
But, you can't make such types in your own Rust. If you wish you had NonSixU8, a type which can't be six, the only way to make it would be to base it on NonZeroU8 and use some sort of XOR scheme. The standard library is blessed with the ability to do this even though it's not available to mortals and that blessing is only open in practice to the actual standard library for the entirely practical reason that only they can co-ordinate with the compiler team to ensure it happens - if the Rust compiler re-defines how niches work the library team have to change NonZeroU8 at the same time.
So while the actual stdlibs get to do magic, which makes them stand out from a popular third party library like SDL or zlib, these "alternatives" don't.
If they provide all the same stuff as the "real" standard library that makes sense, but when they instead provide different stuff and they can't do magic I don't see any difference from any other library. Is SDL an "alternate stdlib" if we and some friends all use it all the time?
One of my favorite parts of Rust is just how little magic there is. Go to the docs for NonZeroU8 and click source. The code is macro heavy to template out all the different nonzeros so it's not very readable to beginners. But you can see it uses the attributes rustc_layout_scalar_valid_range_start and rustc_nonnull_optimization_guaranteed.
Those are unstable, so you have to use another attribute opt in to using them. But you can absolutely put them on your own type.
There's nearly nothing in the Rust stdlib you can't write yourself. OIf I recall correctly one example is the function Box::new which constructs a heap allocated smart pointer to it's argument. It "magically" skips allocating the argument on the stack of the caller in some situations.
> Those are unstable, so you have to use another attribute opt in to using them. But you can absolutely put them on your own type.
They are, as their name suggests, deliberately perma-unstable rust compiler (rustc) only. You technically can use them in types anyway (and if you go look at the nook crate, I have, that's why I know so much about them) but because they're perma-unstable that's a terrible idea and you clearly shouldn't use this.
Even if they were just unstable, (like say const traits) you can only do this in nightly Rust, it's not available in stable Rust and as the people who'd decided "Oh, const traits, those sound great, I'll just use them and eventually they'll be stable" discovered, nope, that's not what we meant when we told you they're not stable. We meant what we said, and those traits just plain went away (probably they'll be back eventually, but maybe not).
But I agree the stuff that's "just" unstable isn't compiler magic, after all the intent is, even if it doesn't always work out, that those features eventually get stabilized. These are perma-unstable because they're compiler internals. They are magic.
You are right, the pcz std won't be a drop-in replacement to the official std as they have different modulepath.
We decided to make it this way so:
1) you can import packages from the pcz std module like you do with any other Go package without setting `GOROOT` to an unofficial std.
2) and because of 1), you can import packages from pcz std in your go application but still using the `go` command rather the `pcz` command.
In the future, we may provide drop-in replacement for applications using official std by introducing a compatibility module and a cli flag to redirect imports using packages from the official std to that module.
After looking at the page it seems pretty clear overall but the biggest source of confusion to me is emphasis of "a new stdlib". To me it seems like a good chunk of their goals start with "a new compiler/runtime". They are replacing the go command.
The fact that requires a different standard library seems like a consequence of the first decision but it's unclear.
Thank you for your suggestions, but I'm afraid the best we can do is to list packages compatible with both std.
The problem is, in order to build a std, we have to use a lot of <ABIInternal> stuff in assembly, and use internal/abi.FuncPCABIInternal in Go, so we can not make any promise regarding to the inter-std-compatibility for the time being, unless the Go project decided to make these features stable.
