Я всегда мечтал поработать в FAANG и тут подвернулась возможность, почему бы и нет

Я думаю это не про it (по ощущениям)

В России тоже кажется зп больше 200к будет в большинстве городов больше 5%, но это не говорит о том что обычный middle+ не может получать 200к

https://www.levels.fyi/companies/google/salaries/software-engineer/levels/l4/locations/ireland

https://www.levels.fyi/companies/amazon/salaries/software-engineer/levels/sde-ii/locations/ireland

Вот тут говорится что для разработчика 130-140к - это норм

https://www.youtube.com/watch?v=AT_T4z0bnjg
вот тут рассказал примерно это же, но немного дополнил

Я хотел показать, что если что в функции SendEmail есть паника, не обязательно ее явно вызывать, может быть обращение к nil интерфейсу или что-нибудь такое, то это приводит к падению сервера. Я вызвал явно панику для того, что бы было проще понять почему здесь паника, а не потому что это считается хорошей практикой, может быть нужно это было пояснить в статье.
Но я с тобой согласен, вызывать явно паники считается bad practice в Golang, правильнее возвращать явные ошибки из функции.

Спасибо, не знал

Да, все правильно

Кто работает с C/C++, знает, что компилятор можно попросить заинлайнить функцию. А как в Go? 

Можно только попросить, но inline не обязывает компилятор C/C++ встраивать функцию
поэтому выглядит что не сильно отличается С/С++ от Golang в этом плане
https://stackoverflow.com/questions/1759300/when-should-i-write-the-keyword-inline-for-a-function-method

Но кажется довольно удобно
Можно решить данную задачу в C++ несколькими строчками (так как next_permutation изменяет строку, нужно еще ее вернуть, поэтому несколько)

Если собирать в каждом воркере свою сумму и при завершении воркера суммировать все результаты, то мы не знаем суммарное количество до завершения, а часто хочется иметь прогресс(сейчас 50 ошибок и тотал 50123,12), если не нужно знать суммарное количество до завершения, то суммировать в воркере и потом получить тотал с использованием каналов, mutex или атомиков можно (в данном случае ты прав, наверное самое оптимальное решение будет с использованием канала).
Наверное можно собирать периодически тотал со всех воркеров(допустим раз в 10 секунд), но это уже немного другая задача

Спасибо большое, обязательно гляну

Используя каналы можно решить данную задачу и будет наверное проще это сделать.
Я сильно не погружался еще в каналы(я на golang не так давно пишу), но если посмотреть runtime/chan.go, то можно увидеть, что в каналах используется mutex(там не sync.Mutex, но все равно используется mutex). Поэтому, если выбирать каналы, то получается выбирать mutex. Но mutex под капотом использует атомики, поэтому если задачу можно решить с использованием atomic, то скорей всего это будет более оптимальное решение по времени, чем с использованием mutex(но все нужно мерить в каждой конкретной задаче, может быть прирост будет минимальный или его вообще не будет).
В этой статье я хотел показать как пользоваться атомиками для float64 и ничего больше, я не хотел показать этой статьей, что решение моей задачи оптимально именно с использованием атомиков(в каждом конкретном случае нужно мерить и находить компромис между поддерживаемым и читаемым кодом и скоростью его выполнения).
Решение с атомиками, получилось не сильно сложное, как мне показалось, поэтому его можно рассмотреть при выборе решения задачи.