Do you think/know of any areas in Go codebase that would enable jump in performance bigger than e.g 10%? I'm very grateful for any work done in Go codebase, for me this language is plenty fast, I'm just curious what's the state of Go internals, are there any techniques left to speed it up significantly or some parts of codebase/old architectures holding it back? And thank you for your work!
I don't think any obvious 10%+ opportunities have been overlooked. Go is optimizing for fast and simple builds, which is a bit at odds with optimal code gen. So I think the biggest opportunity is to use Go implementations that are based on aggressively optimizing compilers such as LLVM and GCC. But those implementations tend to be a few major versions behind and are likely to be less stable than the official compiler.
That being said, I'm sure there are a lot of remaining incremental optimization opportunities that could add up to 10% over time. For example a faster map implementation [1]. I'm sure there is more.
Another recent perf opportunity is using pgo [2] which can get you 10% in some cases. Shameless plug: We recently GA'ed our support for it at Datadog [3].
Go limitation is it’s a high-level language with a very simple compiler where providing true zero-cost abstractions (full monomorphization rather than GC stenciling) and advanced optimizations is a bridge it wouldn’t cross because it means much greater engineering effort spent on the compiler and increasing LOCs by a factor of 5, especially if a compiler wants to preserve its throughput.
Though I find it unfortunate that the industry considers Go as a choice for performance-sensitive scenarios when C# exists which went the above route and does not sacrifice performance and ability to offer performance-specific APIs (like crossplat SIMD) by paying the price of higher effort/complexity compiler implementation. It also does in-runtime PGO (DynamicPGO) given long-running server workloads are usually using JIT where it's available, so you don't need to carefully craft a sample workload hoping it would match production behavior - JIT does it for you and it yields anything from 10% to 35% depending on how abstraction-heavy the codebase is.
Reminder: the Go team consider optimizations in code generation only as far the the compiler is kept fast. That's why the Go compiler doesn't have as many optimizations phases as C/C++/Rust compilers.
As a developer I like that approach as it keeps a great developer experience and helps me stayed focus and gives me great productivity.
I don't really see how one leads to another, could you elaborate? Looking at these protocols, it seems to me that later versions of HTTP attempt to address errors resulting from the overly simplistic design of HTTP/1.1.
You should rather look at go.mod file, and it doesn't look bloated at all. They could maybe drop cobra and use something with less dependencies, they use pflag package already so maybse use only that, but uhh I've seen much, much worse worse, as a daily Go user I'd say it's fine
no. the whole point of go.sum is to see everything. you could have a go.mod with a single item, but if that item is a giant module with hundreds of third party imports (as in this case), its quite misleading.
> I've seen much, much worse worse, as a daily Go user I'd say it's fine
uh where? I am a daily Go user, both professional and personal. and this is one of the most bloated modules I have ever seen.
From my side I'd love to see clear comparison to distroless[1] images, the best info I could find was this Github issue comment[2], although I would expect to find it in https://github.com/wolfi-dev#faq. Or maybe my google-fu failed me :(
I was (one of) the original creators of the Google Distroless project. The main difference is that Original Distroless uses Debian as the upstream. This is great in many ways, but makes it so stuff outside of Debian is hard to package in.
Wolfi is its own upstream - packages are sourced and built directly from source, without another Linux distro.
The rest of the differences stem from here - we get more control over what we package and how, and are able to more quickly add new versions of packages, or roll out CVE patches.
Do you see any significant changes in comparison to the "gcr.io/distroless/static" image, which is commonly used in Go ecosystem? Thanks for answer btw, really appreciate that.
For static, not really just because there's so little in it. For apps that need CGO there's a benefit as more dependencies are required. CGO apps are broken right now IIUC in distroless/glibc-dynamic because of the Debian glibc bump.
For me it's insane that some people "talk" to themselves in their heads, expressing your ideas as words seems so slow in comparison to "thinking in ideas"
Your thinking in ideas is you thinking in your own internal mental vernacular.
What do you do when it comes time to get your point across to others? That's my Achilles heel. If people aren't prepared to really dig in and go through the motions/look things up and vonnect or pick up ideas that I have (that are the sum of many years diving esoteric topics), I might as well just throw my hands up and just do whatever myself. As it's generally a shorter time to materialization than trying to explain it.
I can think in ideas pure non-verbal ideas, and have on occasion noticed that my inner monologue is just describing the idea I've already had.
When I try to shortcut the monologue on the grounds I already know what I'm thinking about, it feels wrong.
This hasn't been much of a problem recently, possibly because my inner monologue has sped up to match that I watch and listen to YouTube and podcasts and audiobooks in ~ double speed.
That was the past, helped by Kubernetes and Docker respective decisions to migrate from Java and Python into Go.
Plenty of them are still Java and .NET based, as the ecosystems counter reacted to Go's adoption hype, and Rust is the new kid on the block specially for cloud native Webassembly projects and eBPF.
WASM is architecture-independent (ARM servers are becoming a thing, for better or worse) and has a lot of investment into sandboxing it performantly (since it also has to run in browsers).
