net: gnet like net for lightweight and zero alloc / no goroutine per connection etc.

[kolinfluence]

Proposal Details

there are a lot of networking "frameworks" e.g. https://github.com/panjf2000/gnet nbios, netpoll etc, all designed to work around std net limitations.

i understand std net is important but can we have a lightweight version? i'm suggesting so because we have net/ip and netip/ip. so maybe we can also have netlite or something similar.

requesting only these features for the netlite, netx would be fine as well. a super lightweight version, gnet like

1. no goroutine creation per connection
2. as fast as gnet or faster.
3. zero alloc if possible.

i've tested a lot of custom made net versions (because go-net is really too resource intensive) and hope this can be part of the roadmap.

p.s. : suggesting so because std net makes golang feel too slow, supporting a lightweight net framework with io_uring (in future) but currently can be anything (but std net) will put golang in the spotlight as so: https://www.techempower.com/benchmarks/#section=data-r22&hw=ph&test=plaintext

[seankhliao]

This seems to work perfectly well outside the standard library, and usage numbers do not indicate that it is a particularly popular package. See https://go.dev/doc/faq#x_in_std

[ianlancetaylor]

This is very vague. It's hard to see what action we can take.

[kolinfluence]

@ianlancetaylor, I suggest developing a highly streamlined version of the standard libraries (in particular for net) that the community could support in part. According to the TechEmpower benchmarks, the standard library performs suboptimally.

Having worked primarily in environments that prioritize minimal allocation, I've managed to significantly reduce allocations, but I wonder if we could also introduce an extremely optimized and reduced version of Go's packages.

I'm curious whether Go has anything akin to Rust's "nightly" builds, or focused on "zero allocation" and "extreme performance" for particularly demanding applications. e.g. 3 versions

1. nightly ([experimental], shouldnt we use another version of golang instead of including it as part of the std compiler? just thinking to myself)
2. extreme performance (minimal zero alloc)
3. pure zero alloc (with goasm or similar.)

(i understand the rationale and complexity of maintaining more versions, and i know about tinygo)

While I understand this may not be a priority, I believe there's interest within the community for such high-performance capabilities. i know there's vlang etc. but there's potential for Go to establish a similarly high-performance environment.

@seankhliao it's not highly used but all these net packages are developed coz they are designed for performance. i didnt mention there's evio too. and gain and more will appear for sure.

p.s. : i went through the whole net ordeal and needing to switch to use some of these custom made net packages after hitting performance issues.

[ianlancetaylor]

Thanks, I understand the general goal. What I'm saying is that this is very vague. The proposal process is for analyzing specific proposals for changes. It's not for developing complex ideas. See https://github.com/golang/proposal#readme. I'm going to take this out of the proposal process.