Go: is it me or is the robot-simulator exercise a disaster?

Programming Go
1

I have no idea what I’m supposed to do to solve this. I admit to being a newbie with goroutines and channels, but I feel I should not need to be this lost.

What prerequisites are required to even understand what the Action type is supposed to be? Is it because I’m not a front-end developer and don’t know React?

This exercise has a low completion% but not out-of-line with some of the other harder exercises. What do 175 people know that I don’t?

2

@glennj Is your issue specifically with the Go version or the exercise in general? (Just to be clear). From glancing, I’m guessing its the fact that the stub refers to things (e.g. Action) that aren’t defined anywhere you can see (in fact, not defined anywhere at all as far as I can tell)?

3

Indeed, just the Go version.

I have a gut feeling that this is an exercise that can really benefit from some concept exercises that don’t exist yet (but I’m sure are probably on a roadmap): goroutines, channels, etc.

The appended instruction talk about the exercise as a “physics engine”, so perhaps it’s more comprehensible for people comfortable in the guts of game development.

It seems there are some unspoken assumptions that I’m not seeing. For example, the StartRobot function does not have a Robot entity as either an input or an output. There’s something about contemplating a “thread” as the robot that is eluding me.

4

This exercise, to a far greater extent than the other 80-odd go exercises I’ve done, seems to require a deep understanding of the the test functions before even approaching the solution.

5

When I have time I’ll have a look at this.

This is an exercise I admit I haven’t solved myself yet, and I don’t remember this exercise being revisited in the time I’m a maintainer for Go (a little over a year now). So it’s possible some things are outdated and not in line with everything else on the track.

6

git blame shows some minor changes 7 months ago but the instructions.append have been largely unchanged for 2 years, and the actual example and tests for 7 years.

7

@glennj If you want, send me an mentoring invite and we check together. Should be solvable. I hope. :sunglasses:

8

Thanks for the offer. I need to put this one aside for a while to get a fresh perspective on it.

9

:+1: I just cleaned up the build constraints for the test files. This can already be problem #1. Maybe it gets merged.

10

I just resolved this exercise and have some feedback:

  • You should know about build constraints to understand the test commands. Here even the old obsolete form is written in the Code, which confuses my GoLand installation. The go.mod states Go 1.18 already.
  • While the exercise has three steps, the main code file introduces code for later steps. So could be commented with so notes to make starting with step 1 easier.
  • Step 2 talks about goroutines and channels which is a core feature of Go. I hope I can provide my first suggestions for concept exercises, soon.
  • Talking about a “physic engine” sounds a bit big. At the end the “physic” sounds like it’s only about position projection within the room. With kind of “collision detection”. This “physic” decides if a step is possible or not.
  • With step 3 the concurrent approach makes sense.

In summary you’re quite open with your implementation and you need to understand the tests. While it’s written in the text, especially for step 3, I have to read the tests carefully.