quic-go needs to go, quickly #1

New Issue

2025-01-19T15:49:07-07:00

sashakoshka commented

2025-01-19 15:49:07 -07:00

Reasons why:

The API is a bit unpleasant to use
The doc comments don't discuss goroutine safety so we have to just guess
It pulls in way to many dependencies

The dependency issue is the dealbreaker here. Most of the deps it pulls in have to do with testing or prometheus. We already know the code works because these unit tests are presumably being run upstream, so these dependencies are just dead weight here. We don't need or want prometheus because having a web server packaged in every application is extremely silly, and without that prometheus is useless. It's even more dead weight that go has to churn through.

The solution would probably be to maintain a downstream "clean" version with an automatic procedure to run the tests (as a sanity check), delete all test files, delete everything related to prometheus, and finally run go mod tidy. It would be set up to pull when there is a release from upstream (because presumably all tests will pass if it is really a release), run the procedure, delete the old release, and create a new one.

This is not necessary for the functionality of this package so it can wait a little bit, but this should be done before a stable release.

Reasons why: - The API is a bit unpleasant to use - The doc comments don't discuss goroutine safety so we have to just guess - It pulls in way to many dependencies The dependency issue is the dealbreaker here. Most of the deps it pulls in have to do with testing or prometheus. We already know the code works because these unit tests are presumably being run upstream, so these dependencies are just dead weight here. We don't need or want prometheus because having a web server packaged in every application is extremely silly, and without that prometheus is useless. It's even more dead weight that go has to churn through. The solution would probably be to maintain a downstream "clean" version with an automatic procedure to run the tests (as a sanity check), delete all test files, delete everything related to prometheus, and finally run `go mod tidy`. It would be set up to pull when there is a release from upstream (because presumably all tests will pass if it is really a release), run the procedure, delete the old release, and create a new one. This is not necessary for the functionality of this package so it can wait a little bit, but this should be done before a stable release.

sashakoshka commented

2025-01-21 18:10:02 -07:00

More problems with the module:

It outputs log messages if your kernel is configured a certain way, and this cannot be disabled
It outputs even more log messages if you set a certain environment variable, and this cannot be disabled
There does not seem to be a straightforward way to create a connection, having to dig through the source code to figure it out

More problems with the module: - It outputs log messages if your kernel is configured a certain way, and this cannot be disabled - It outputs even more log messages if you set a certain environment variable, and this cannot be disabled - There does not seem to be a straightforward way to create a connection, having to dig through the source code to figure it out

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sashakoshka/hopp#1