1. 17
  1.  

  2. 5

    Coverage of the purported topic was pretty light. I think event loop was only mentioned in a single sentence.

    The intro was decent (although illustrating moores law with a 2005 graph topping out with itanium 2 was strange). But it was clearly setting up for a very different talk.

    There’s actually a very important point that event loops are concurrent, but not parallel. Makes a huge difference when you’ve got a 40 core server. But I never saw this even mentioned.

    1. 3

      If I understand this correctly it explains why Go doesn’t allow explicit stack vs heap allocation. Pointers from the heap back into the stack would be incompatible with stack relocation. In the Go I’ve written there are a fair number of situations where I have a goroutine running a loop in which a value is allocated, filled, and then sent by value into a channel without retaining a local reference. I wonder if in cases like this can be found statically at compile time to avoid the copies that (I think) happen with the current compiler.

      1. 1

        I believe the Go compiler actually uses escape analysis to determine whether to place data on the heap or stack so you can declare a local var in a function and then pass a reference to that var to some other part of the code and exit the function without destroying that var. Even though it looks like it was on the stack, the compiler actually detects that it’s needed outside the scope of the function where it’s declared and allocates it on the heap. No copies necessary.

      2. 1

        But…there is an event loop. It’s just at an abstraction layer the developer doesn’t have to care about.