Leotard6963

Note that this project is not an attempt to replace the Go runtime, but here is what we will do:

Precondition: in Go, each goroutine has its own `g` structure (like TCB, but for controlling goroutines) and its address is stored in the `g` register, which is reserved by the go compiler, active goroutines can call a function runtime.getg() to obtain the value of the `g` register.

In the official runtime, the `g` structure is a concrete type and the scheduler is implemented globally in the runtime package.

But we have made the `g` structure customizable (still requires a fixed header expected by the function prologue & epilogue and linker), so custom g implementations may contain a link to a custom scheduler, and the scheduler can decide how to handle an active goroutine.

> "goroutines" that automatically suspend themselves

The automatic suspend and resume happens by

- calling `runtime.entersyscall` from a running goroutine - and calling `runtime.exitsyscall` from an finished systemstack

all these operations can interact with the custom `g`, thus can interact with the custom scheduler.

Yes, that's one of our motivations to build this std!

The feature of generating go packages from C in `ffigen` still needs significant work to be done (mostly dealing with C calling conventions on different platforms), and the generated go package only works with dynamic libraries (as it uses the pragma `go:cgo_import_dynamic`).

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.

Thanks, but the actually hard things are done by the Go team, the design of the interface type and availability of runtime type information made it relatively easy to complete that final goal, but let's go find out!

"platform native sdk" is the collection of apis exposed on that platform exclusively (think win32 apis, android ndk).

The project is to build a stdlib, and by its nature is to be used by developers to build applications just like the official Go std.

Yes, we are re-implementing (some of) the official std, but with careful redesign, and probably won't provide a lot of familiar apis, this is largely because packages from the official std often do implicit allocations with the assumption of GC running.

And Yes, we are defining brand new interfaces as well, in order to improve usability and fix inconsistent user experience.

For your specific example `os.WriteFile` (names mentioned below may subject to change):

The api won't make it inside the std, because the local filesystem will be implemented as a `fs.FS` (concrete type `*sysfs.FS`), so you can have multiple `sysfs.FS` instances each at its own working directory, and the `os.WriteFile` will be replaced with `fs.WriteFile(fsys fs.FS, path *fs.PathBuf, wctx *io.WriteContext) io.Status`, where `fs.PathBuf` is our solution to handle all kinds of path styles (windows, unix, cygwin, utf8, utf16, end-null) and operations (join, base, dir).

So this is the std made for you, and to make it compile, you have to import the runtime package explicitly.

Currently pcz is building applications with the `compiling-runtime` option, so variables implicitly escaped from the stack will cause compile error.

For variables you are sure living on the stack, you can use `mark.NoEscape(&v)` to obtain its pointer (a hack to cheat escape analysis found in the official runtime & reflect package), and the variable will be freed on function return.

For variables you want to control lifecycle, call `alloc.New` or `alloc.Make` with a explicit allocator, which can be an allocator whose storage is on the previous call stack (and there is a default goroutine local allocator thread.G().G().DefaultAlloc()) to allocate a non-stack-local variable, and call `alloc.Free` with the same allocator to free that variable.

The use of `make` is discouraged as go compiler does mid-stack inlining and escape analysis, so the return value of a `make` can be either on stack or on heap, thus to free it, the allocator needs to compare the address to thread.G().Stack.Lo and thread.G().Stack.Hi.

> dropping GC, dropping runtime concurrency

Making GC/goroutine optional & customizable requires building a std works with no GC/goroutine.

> dropping std

relax, this is a new std, let's spare the baby some hope?

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.

> converge or diverge

Neither, though the final result can be similar, but at project level, tinygo and pcz has very different approaches to achieve the final result:

- tinygo chose the hard path to write a llvm backed toolchain with some custom behavior that compiles Go code (using official std) to llvm targets.

- pcz chose the easy path to write a stdlib from scratch that compiles to desired targets using the official Go toolchain.

One major benefit of pcz's approach is you can import packages from the pcz std module like you do with any other Go package, the development experience can remain unchanged.

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?