Suggestion: A better API for `RPC` method in Go about maelstrom HOT 3 OPEN

Ah, I'm not really qualified to speak on this--perhaps @benbjohnson might?

from maelstrom.

@avinassh It's probably a better API to return the message ID, however, you shouldn't need to do message ID tracking for any of the challenges. I think breaking the API will be significantly more painful than it's worth. For that reason, I'd recommend not implementing the change.

from maelstrom.

It's probably a better API to return the message ID, however, you shouldn't need to do message ID tracking for any of the challenges.

Continuing from the previous example, I had a background worker check the store for old messages:

go func() {
	ticker := time.NewTicker(100 * time.Millisecond)
	for range ticker.C {
		randomMsgId := store.Get()
		// randomMsgId is not sent, so resend again
	}
}()

In the above snippet, msgId is randomly generated, where I kept the state. Without message ids, this is painful.

Though I agree that tracking message Ids is not required for any challenges, but when I was solving broadcast challenge, this is how I started working on the solution, it took me a while to realise this is not required at all and later removed the tracking of message ids. So, if someone else were to try the same, I thought we could make it easier.

I think breaking the API will be significantly more painful than it's worth. For that reason, I'd recommend not implementing the change.

I am a bit conflicted about this. The way I am using this library is to initiate the go mod once and then implement the challenges. I assume most people might do the same and not update the library when working on a challenge, but I could also be wrong. But when I think from the point of view of future users, this breaking change is okay as it will improve their experiences.

from maelstrom.