Clearly a repo about websockets and their comparison...

I saw your video on YouTube and was surprised that the bullet game code written in Rust was not performing as good as (if not better than) Go. This made me curious and I went through the Rust code.

I've created an alternate implementation of the game in Rust which doesn't use any Mutex and very few channels. Hopefully this one should perform better than the current implementation.

To compile and run:

cd rust-alternate/
cargo build --release --bin server
./target/release/server start

If you want to change log level:

RUST_LOG=error ./target/release/server start

You can test this using the same game_player.rs in current code.

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.

First things first, I don't think the node.js can out perform golang.

That being said when running a SYSCALL heavy code with a lot of delegation you should bump the thread pools size from 4 to 128 at least (using the env UV_THREADPOOL_SIZE).

More docs here: http://docs.libuv.org/en/v1.x/threadpool.html#thread-pool-work-scheduling

Scaffolding out an elixir version. You know you want it.

The files we need to work from are:

• elixir/lib/tbg/game.ex
• elixir/lib/tbg_web/channels/game_socket.ex

Why bother? It's interesting.

https://github.com/phoenixframework/phoenix_site/blob/master/posts/blog--the-road-to-2-million-websocket-connections.markdown

removes the sync.mutex out of the message queue in favor of a lock less concurrent safe queue.

go fmt on the master branch seems out of date or something as go fmt now forces tabs. Merge #12 first to see actual changes. Or hit that ignore whitespace diff button

I think this in memory queue is faster than channels, but it doesn't block so it would require more refactoring likely with sleeps to handle an empty queue in order to replace all the channels with the queue implementation. This is very useful in real world environments where the queue is rarely starved. If the sleeps aren't tuned right and the queue was starved it would add latency over the channel implementation, however under significant load the queue would never starve and be faster than channels.

I was hoping to learn server programming by watching the VODs from the start, building and running the commits: https://github.com/ThePrimeagen/tyrone-biggums/blob/1ddb63fac0a26c6c37ec39ceb7b6175b127fdcbc/README.md?plain=1#L37

But it seems like you where streaming on youtube when you started the project, then set the past live streams to private.

Could you set the past live streams to unlisted and provide the links please?

While the overall diff might look like a complete rewrite, I stuck with your approach and simply made incremental changes, commit-by-commit. Overall this is still not how I'd implement a server (if RxJS and Node were requirements for some reason), it's just a refactor of what's here. See commits for details.

High Level:

1. There were several places where you were creating subscriptions but not unsubscribing them or cleaning them up.
2. There was a LOT of unnecessary RxJS in this example. As an example, there were a couple of cases where a Subject was being used to create a unicast observable, or to wrap what was already multicast with an observable.
3. There were other unnecessary abstractions I'd have steered clear of that might also be hurting your callbacks implementation.
4. The tests never worked for me. Two were broken out of the gate. I deleted the rxjs-related tests that no longer align with the implementation. I didn't add new tests, however. If you want to test those, the function that create the Observables are exported from the modules they live in, and you can test those in isolation provided mocks of things like sockets, etc.
5. I was unable to run any of your tests. In your videos it seems you're running some Netflix-specfic python script under ~/work when you spin up your docker image.

As a whole, this example would make a great sample to use to showcase incremental refactoring of code that wasn't meeting requirements. In all, it didn't even take that long. Incremental refactor is a skill I can't recommend enough.

There may be some argument that "I didn't do this the RxJS way". But there is no RxJS way. I can't control what weird tutorials or explainers are out in the wild. It's just a set of tools.

All of that said:

1. IMO, I would never implement a "high speed game server", especially one this simple, in Node. 🤷
2. Callbacks (aka no/little abstraction) will always beat any additional abstraction. Especially if that abstraction isn't well leveraged.
3. This is probably still slower than callbacks. I'm sure you'll editorialize that on YouTube or Twitter as "A disaster" or a "toilet fire" (your exact words), but do what you will.

At this point the ball is in your court. I'm attempting to help you with your comparison, good luck with your YouTube channel.

Hey !! Thanks for the amazing video https://www.youtube.com/watch?v=h7UEwBaGoVo I am trying to do some optimizations in the typescript project (in terms of web server choice, code organization, and more) But I am running into an issue while running the benchmarks for ts.

I started the server using $> node typescript/dist/index.js callback localhost 9999 started client using $> cargo +nightly run --bin test_client 2 localhost --path / --port 9999

Running the client is crashing the server with

undefined:1
!join foo0
^

SyntaxError: Unexpected token ! in JSON at position 0
    at JSON.parse (<anonymous>)
    at WebSocket.<anonymous> (/Users/shreymehta/projects/tyrone-biggums/typescript/dist/server/socket.js:13:34)
    at WebSocket.emit (events.js:315:20)
    at Receiver.receiverOnMessage (/Users/shreymehta/projects/tyrone-biggums/typescript/node_modules/ws/lib/websocket.js:1098:20)
    at Receiver.emit (events.js:315:20)
    at Receiver.dataMessage (/Users/shreymehta/projects/tyrone-biggums/typescript/node_modules/ws/lib/receiver.js:528:14)
    at Receiver.getData (/Users/shreymehta/projects/tyrone-biggums/typescript/node_modules/ws/lib/receiver.js:446:17)
    at Receiver.startLoop (/Users/shreymehta/projects/tyrone-biggums/typescript/node_modules/ws/lib/receiver.js:148:22)
    at Receiver._write (/Users/shreymehta/projects/tyrone-biggums/typescript/node_modules/ws/lib/receiver.js:83:10)
    at writeOrBuffer (_stream_writable.js:352:12)

I can see this project is being worked upon daily. Can you please point me to the commit at which this comparison was done?

Consider the following frameworks to make server side development coconut oil smooth.

• Axum https://github.com/tokio-rs/axum/blob/main/examples/websockets/src/main.rs
• Poem https://github.com/poem-web/poem/blob/master/examples/poem/websocket-chat/src/main.rs