What does "highly optimized" have to do with whether it's in the standard library? Highly-optimized cryptography is in the standard library.

▲

dilyevsky 3 days ago | parent | next [-]

Previously Go team has been vocal about sacrificing performance to keep stdlib idiomatic and readable. Guess the crypto packages are the exception because they are used heavily by Google internally and json and some others (like say image/jpeg which had crap performance last time i checked) are not.

Edit: See: https://go.dev/wiki/AssemblyPolicy

▲

ronsor 3 days ago | parent | prev | next [-]

Not to mention that Go is never going to put C code in the standard library for anything portable. It's all Go or assembly now.

▲

pjmlp 3 days ago | parent | next [-]

Which is the right approach, and one of the areas I actually appreciate the work of Go authors.

There is nothing special about C, other that its historical availability after UNIX's free beer came to be.

Any combination of high level + Assembly is enough.

▲

dwattttt 3 days ago | parent | prev [-]

It's amusing to see assembly considered more portable than C.

▲

jitl 3 days ago | parent [-]

No, portable code is written in Go, not C. Platform specific code is written in ASM.

	▲	2 days ago \| parent [-]
		[deleted]

▲

karel-3d 3 days ago | parent | prev [-]

sonic uses a clang-generated ASM, built from C (transformed from normal clang-generated ASM to "weird" go ASM via python script)... I don't think this will be in standard library.