You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem of unicode is that this tends to bloat the binary size [1]. Now the package bytes imports the package unicode. Even if you want to use just byte.Buffer, you have to import unicode indirectly, which is unfortunate. Would it be possible to separate bytes package into APIs that are related to Unicode and the others, probably in Go2?
If the goal is to reduce binary size then I dont think just splitting bytes is worth the churn in either Go 1 or Go 2.
Many other packages strings, fmt, reflect will still require unicode to be imported making the number of go programs after the split not importing Unicode very small still.
The ergonomics when programming of having to reason in which package to find the corresponding bytes function that previously were all together in one package is I think not worth the 22k byte saved.
To tackle this problem for all packages I think (apart from avoiding adding unicode dependencies were possible) is to work on compiler and linker optimisations making the imported parts of unicode smaller. e.g. #38784
This also has the advantage of not requiring Go 2 incompatibilities.
Many other packages strings, fmt, reflect will still require unicode to be imported making the number of go programs after the split not importing Unicode very small still.
Fair enough. Focusing on reducing the binary size of unicode itself makes much more sense.
The problem of
unicode
is that this tends to bloat the binary size [1]. Now the packagebytes
imports the packageunicode
. Even if you want to use justbyte.Buffer
, you have to importunicode
indirectly, which is unfortunate. Would it be possible to separatebytes
package into APIs that are related to Unicode and the others, probably in Go2?[1] For example: hajimehoshi/ebiten#1157 (comment):
unicode.init
takes 22359 bytes IIUCThe text was updated successfully, but these errors were encountered: