uvelichitel

Handler для сервера не указали.

s:= http.Server{
    Addr: ":8080",
    Handler: handler, //здесь
    ReadTimeout: 10 * time.Second,
    WriteTimeout: 10 * time.Second,
    IdleTimeout: 10 * time.Second,
    MaxHeaderBytes: 1 << 20,        //1*2^20 - 128kBytes
  }

Нужно сделать set.Add() для всех элементов array - это дает O(n). set.Add() проверяет на уникальность - это в прямолинейном исполнении еще O(n). Конечно на всех современных движках Set оптимизирован до HashTable. В идеальном мире HashTable.Add имеет сложность O(1), но мы же не в идеальном, на практике думаю можно рассчитывать на O(log(n)) с учетом небходимых периодических аллокаций с ростом Set. Таким образом, по моим сугубо личным, бездоказательным оценкам, рассчитывать можно на O(n*log(n))
И, да, я убежден что быстрее O(n) быть не может. Преобразовать последовательный массив в хештаблицу быстрее O(n) невозможно даже теоретически.

Чтобы выполнить системную команду в Go пользуют os/exec
Чтобы выпало окошко в osx применяют /usr/bin/osascript
Попробуйте что нибудь вроде

package main
import (
	"os/exec"
	...
)

func main(){
...
//Чтобы получить приглашение в консоли
	cmd := exec.Command("sudo", "su")  
	err := cmd.Run()
	if err != nil {
		fmt.Printf("%s", err)
	}
...
//Или чтобы выпало окошко
	out, err := exec.Command("osascript", "-e", "do shell script /path/to/myscript with administrator privileges").Output()
	if err != nil {
		fmt.Printf("%s", err)
	}
...
}

xls (до 2007г.) - проприетарный(без публичной документации), бинарный формат microsoft работать с которым почти бесполезно. Есть однако библиотека https://github.com/extrame/xls (libxls переписанный на Go), которая позволяет открывать и читать бинарные xls файлы.
С новыми форматами xlsx, xlsm толку побольше. Это коллекция xlm запакованная в zip. Соответственно можно распаковать https://golang.org/pkg/archive/zip/ и работать с xml https://golang.org/pkg/encoding/xml/ из стандартной библиотеки или для удобства использовать готовый пакет https://github.com/tealeg/xlsx.
Чтобы просто для интереса посмотреть что лежит внутри foo.xlsx переименуйте его в foo.xlsx.zip и откройте штатным архиватором.

Мало кода, но на первый взгляд это не паника при записи header, а error при попытке tw.Flush(), который вы не проверили. После записи header, нужно залить собственно данные tw.Write(data []byte) и уже потом делать tw.Flush(). Вы в header пообещали залить данные и не залили. Кажется должно быть что то вроде

if err := tw.WriteHeader(hdr); err != nil {
    return err
}
if n, err := tw.Write(content); err != nil { //вот это не видно как вы сделали
    return err
}
if tw.Flush(); err != nil{ //и нужно проверять все ошибки
    return err
}

Race detector достаточно умный, не требует ничего военно-специфического вроде sync.WaitGroup. Чтобы диагностировать race достаточно просто обратиться к незащищенным данным асинхронно.

func TestRaceDeposit(t *testing.T) {
  setBalance(0)
  go Deposit(10)   //Просто этого вызова уже достаточно
  Deposit(10)
  if Balance() != 20 {
    t.Errorf("unexpected balance: value - %d expect 20", Balance())
  }
}

ФП программа не хранит состояние/state, кототое бы могли конкурентно изменять потоки. А в чистом ФП и именования должны быть неизменными/immutable. То есть в чистом ФП конструкция

something = 2
something = 3

нелегальна, противоестественна. Если something = 2, то это навсегда и не может вдруг стать =3. При таком подходе потоки не могут получить одновременный доступ к одному месту в памяти пытаясь изменить переменную состояния. Для обмена данными между потоками можно только использовать специальные примитивы защищеннные под капотом механизмами синхронизации операционной системы(вроде Mutex или Atomic). Например очередь сообщений может быть представлена списком/list которым нельзя манипулировать напрямую, а только методами Queue.Put() Queue.Get(). И в реализации этих методов уже зашиты блокировки от параллельного доступа к памяти.