[weinzierl]

I love how they clearly state their goals at the beginning. This makes it immediately clear what it is about. Especially an importantly:

"Non-Goals"

"Change the way the Go team works or make them change their decisions."

Not every project (and very much not every fork) is a political statement against the original. Sometimes people are glad what others do and want them to continue. Still, wanting their own different version to coexist is completely OK.

[jonathanstrange]

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.

[Leotard6963]

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?

[jen20]

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).

[mst]

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.'

But there was e.g. https://github.com/eloraiby/alt-std for rust, and for D there's a couple listed here - https://wiki.dlang.org/Alternative_Standard_Libraries

So if you're coming at it thinking in those terms, it's 'obviously' the right term to use to describe it.

Note that (a) I wasn't confused at all (b) it makes complete sense people -are- confused by it, and you're not at all wrong.

[tialaramex]

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?

[iudqnolq]

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.

[Leotard6963]

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.

[anonacct37]

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.

[dolmen]

The major question that the README should answer are:

As a Go developer, can I expect to be able to build modules that will work both with both Go's stdlib and pcz std (maybe using build tag guards) ?

Are you building a completely separate ecosystem or can we expect some overlap?

[Leotard6963]

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.

[diogenes4]

I think it does what it says on the label but maybe I'm missing something.