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

[tialaramex]

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

[iudqnolq]

My bad

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