go-server suggestions

[davidmdm]

Hi,

I loved your NodeJS/TS vs Go video and I thought I would check out the code, and I wanted to make some suggestions... In the end it snowballed, and there seems to be a lot of changes but I assure you it is mostly just gofmt that has formatted the code.

Here are the notable changes suggestions by order of importance:

• Fixed a race in your HandleNewConnection Handler, where the OtherSocket variable could have been corrupted. I suspect the reason you never ran into this issue is that you ran on a single core and so only one goroutine could run at a time.
• Made the channels return Messages and not pointers to Messages. By using pointers you force the Go runtime to allocate to the heap and put additional pressure on the GC... This might me an over optimisation and could actually end up being worse. But my gut is that in this situation its better to not be creating thousands of messages on the heap if you can avoid it.
• Refactored the server function, and removed the needless Socket interface...

Anyways, Loved your video, was hoping you would check out these suggested changes, and no worries if you don't want to merge. I did go a little overboard.

Best of luck, and can't wait to see your next video.

[ThePrimeagen]

My Friend. I am pretty weak at Go, so this is great. I am going to leave this PR up and use it for the next version of this program.

Could you help me understand this pointer thing? When I allocate and pass without pointer, does it copy? Or is it more like rust and move "ownership?"

Any additional resources would be great.

[davidmdm]

Thanks. Sure no problem. Basically Go uses escape analysis to see if a variable will live beyond the lifetime of the function. If it can safely do so it will allocate it on the stack, and if it cannot it will allocate it on the heap.

So in your case by making FromSocket -> *Message Because we are returning a pointer to a message the message value itself must outlive the function and will be allocated on the heap, where it will be referenced by the pointer you are returning.

By returning the value, we know that we will be passing the Message by value (copying) around a lot, but avoids putting pressure on the GC finding and eliminating those Messages that were previously being allocated on the heap.

Does this mean that Values over Pointers is always going to give superior performance? Not always. Sometimes copying large pieces of memory between functions is not as effective as copying a pointer to that memory around. In your case though, I am thinking it is a fair bet that it should relieve pressure on the Go GC, but it would have to be proven.

You can read this article about escape analysis in Go for more details: https://medium.com/a-journey-with-go/go-introduction-to-the-escape-analysis-f7610174e890

[ThePrimeagen]

I'm just starting the go client now. I'll be using this as my strategy.

I'll ping you once it's done, if you could give it a review that'd be great.

[ThePrimeagen]

if you haven't looked at the latest implementation, i tried to follow your advice ;)

[ThePrimeagen]

i closed this because the server is completely different.