This puzzle was a clever way of introducing the idea of opcodes, loading/storing values, and assembly in general to someone that may not have been exposed to it before. I watched a talk by the creator of Advent of Code this weekend and he made a point that he has to design these puzzles for someone that may never have taken a CS class before. I could really see the result of that care and foresight in this puzzle.

You can find my solution repo here.


I start by parsing the input into a slice of strings, converting it to a slice of ints, and then returning that slice.

// Reads input file, splits into a string slice, converts those elements to an
// int slice and returns it.
func prepInputD2() []int {
	f, err := os.Open("./input/day2.txt")
	scanner := bufio.NewScanner(f)
	// Assumption: all input data is on a single comma-separated line
	input := scanner.Text()
	inputSlice := strings.Split(input, ",")
	numSlice := make([]int, len(inputSlice))

	for i, val := range inputSlice {
		val, err := strconv.Atoi(val)
		numSlice[i] = val

	return numSlice

From there, I made the modifications to the input inside of my call to day2Puzzle1 before passing that slice to my compute function. The computation process isn’t that interesting, but you can find it in the repo if you want to check it out.

The second puzzle involves iterating through the possible nouns and verbs to find the pair that creates the desired solution. There is probably a more elegant way to solve this, but brute forcing it here seems to work just fine.

func day2Puzzle2(intcodes []int) int {
	tempcopy := make([]int, len(intcodes))
	for noun := 0; noun < 100; noun++ {
		for verb := 0; verb < 100; verb++ {
			copy(tempcopy, intcodes)
			tempcopy[1] = noun
			tempcopy[2] = verb
			result := compute(tempcopy)
			if result == 19690720 {
				return 100*noun + verb
	return -1

When it came to the second part of the puzzle, this is where I learned (after some confusion) that Go doesn’t “pass by value” - although I’m not sure how to say that concept in Go-language (ha) yet. I had a test case that called prepInputD2() and passed that into day2Puzzle2 - it would pass while the actual function call would fail. After a few moments of chin-stroking, I realized that I hadn’t been refreshing the input data after calling day2Puzzle1, so the pre-compute modifications that you have to make were getting made for the call to part 2’s solution. This was screwing everything up!

Eventually, I figured it out and I learned more about Go - so it was definitely a success. For the record, I’m really enjoying the language so far. There are some things that are a little weird (only for loops) and some things that are a little bit like bumper bowling (I can’t compile with an unused import?)…but overall I’m finding it to be nice and refreshing.

Looking forward to day 3 (which I will be a day late on).

You can find my solution repo here.