You sure they weren't just using http or something and thus the concurrency was effectively hidden by the library? Almost any services that takes requests of any kind uses goroutines extensively.
Does Go actually have an async story? I know that question risks starting a semantic debate, so let me be more specific.
Go allows creating lightweight threads to the point where it's a good pattern to just spin off goroutines left and right to your heart's content. That's more of a concurrency primitive than async. Sure, you combine it with a channel, and you've created an async future.
The explicit passing of contexts is interesting. I initially thought it would be awkward, but it works well in practice. Except of course when you need to call a blocking API that doesn't take context.
And in environments where you can run a multitasking runtime, that's pretty cool. Rust's async is more ambitious, but has its drawbacks.
Go's concurrency story (I wouldn't call it an async story) is way more yolo, as is the rest of the Go language. And in my experience that Go yolo tends to blow up in more hilarious ways once the system is complex enough.
To be fair, Go’s async story only works because there’s a prologue compiled into every single function that says “before I execute this function, should another goroutine run instead?” and you pay that cost on every function call. (Granted, that prologue is also used for other features like GC checks and stack size guards, but the point still stands.) Languages that aspire to having zero-cost abstractions can’t make that kind of decision, and so you get function coloring.
I'm not sure this is 100% correct. I haven't researched it but why would they perform such a check at runtime if it is 1)material and 2) can be done at compile time. However, even if it is, Go is only trying to be medium fast / efficient in the same realm as its garbage collected peers (Java and C#).
If you want to look at Rust peer languages though, I do think the direction the Zig team is heading with 0.16 looks like a good direction to me.
> why would they perform such a check at runtime if it is 1)material and 2) can be done at compile time
It can’t be done at compile time because it’s a scheduler. Goroutines are scheduled in userland, they map M:N to “real” threads, so something has to be able to say “this thread needs to switch to a different goroutine”.
There’s two ways of doing this:
- Signal-based preemption: Set an alarm (which requires a syscall) that will interrupt the thread after a timeout, transferring control to the goroutine scheduler
- Insert a check to see if a re-schedule needs to happen, in certain choice parts of the compiled code (ie. At function call entry points.)
Golang used to only do the second one (and you can go back to this behavior with - asyncpreemptoff=1), it’s why there was a well-known issue that if you entered an infinite loop in a goroutine and never called any functions, other goroutines would be starved. They fixed that by implementing signal-based preemption above too, but it’s done on top of the second approach.
Granted, the prologue needs to happen anyway, because go needs to check if the stack needs to grow, on every function call. So there’s basically a “hook” installed into this prologue that is a single branch, saying “if the scheduler needs to switch, jump there now”, and it basically works sort of like an atomic bool the scheduler writes to when it needs to re-schedule a goroutine… Setting it to true causes that function to jump to the scheduler.
Go has done a lot of work to make all of this fast, and you’re right that it only aspires to be a “medium-fast” language, and things like mandatory GC make these sort of prologues round to zero in the scheme of things. But it’s something other languages are fully within their rights to avoid, is my point (and it sounds like you agree.)
It sounds like you know about this / have researched it. Are you saying that any go function, even func add(x,y int) { return x + y}, is going to have such overhead in all situations? Why wouldn't Go just inline this for instance when it can? It seems like such an obvious optimization.
If go chooses to inline a function in general, then it doesn’t need to add the prologue to the inlined code, no. The prologue applies to all functions that remain after the inlining is done.
There’s also functions that can be marked as “nosplit” that skip the prologue as well.
But otherwise, it has to be in every function because you might be 1 byte away from the top of go’s (small) stack size, then you call that simple add function, and if the prologue isn’t run the stack will overflow. Go has tiny stacks by default that grow if they need to, with this prologue functioning as the “do I need to split/grow the stack?” check, so it needs to be every function that does it. The scheduler hook is just a single branch that’s part of the prologue, so it’s not that much more expensive if you’re doing the prologue anyway.
One of the issues is that the US, unlike most of Europe, for example, doesn't require registering your address with your locality or police when you move.
The Intel CMOS process 18A, which they have launched a few weeks ago, is the first after almost a decade that is somewhat competitive with TSMC and Samsung.
Good for Intel: their new manufacturing process has demonstrated a much better energy efficiency than the TSMC "3 nm" process that was used to make Intel Arrow Lake and Intel Lunar Lake.
Unknown: TSMC now has a "2 nm" process and the first products using variants of this process are being launched. It is unknown how TSMC "2 nm" compares with Intel 18A, but it is almost certain that the TSMC "2 nm" is better.
Bad for Intel: they had difficulties to achieve high clock frequencies in Intel 18A in comparison with TSMC "3 nm", so most Panther Lake models have lower clock frequencies than their Arrow Lake counterparts. Moreover, it is also pretty certain that for now Intel 18A has much lower fabrication yields than even the latest TSMC "2 nm" process.
It's probably used to aggregate all their data sources to compile profiles. They then match the passport against their database of profiles. To say, yup, this passport is for real person; not a deceased person whose identity was stolen for example.
Haha, I take it as a compliment for now. Being not a native English speaker and managing to tie an LLM is a little flattering. Besides, Sirens are mentioned in Odyssey.
reply