Илья Казначеев

Если у вас проект чисто на разобраться, то не берите никакие фреймворки, делайте на чистом го + grpc + что-то для вашей бд (для постгреса советую go-pg).

Если же у вас продуктивный проект, то тут уже нужно анализировать реальные бизнес требования, что нужно, почему го, почему микросервисы ну и так далее.
Нельзя просто выбирать технологии "потому что захотелось". У всех есть свои плюсы и минусы и области применения.

Goland тут не поможет. Вам нужно реализовать хендлер для JSON-RPC (очевидно), который под капотом что-то делает, и что-то возвращает.

Также очевидно, что нужна какая-то логика, которая по запросу откуда-то соберет этот ответ, и вернет его либо как ответ по сети, либо выведет в терминал.

Для gRPC какой-то хорошей практики в этом плане нет, это просто вызов удаленного действия.
Если ожидаете, что все выполнится быстро, делаете синхронно.
Если ожидаете, что *может* выполниться долго, делаете асинхронно.

Email рассылки действительно делаются часто через очереди, но в вашем случае ничего не мешает просто при старте приложения поднять горутину (или несколько), которые будут читать емейлы из канала и асинхронно отправлять, а там писать в канал откуда вам надо.
Да и сами по себе такие действия как рассылки и прочее обычно выполняются асинхронно, потому нет нужды их дожидаться, чтобы вернуть ответ на запрос.

Много чего, в основном по мелочи.

Например, в линуксе есть крутые настраиваемые графические оболочки, а про тайловые менеджеры на маке можно только мечтать.

Что касается периферии - на линуксе все можно настроить, на маке если что-то не работает из коробки - забить и купить с надписью "работает с мак" (утрирую, конечно, но доля правды есть).

В целом мак очень хорош для лаптопов (софт заточен под железо, что дает хорошую работу батарейки, ну и жесты), а линукс отличная десктопная ось (прям в удовольствие можно все настроить под клавиатуру и большой монитор).

Если ты про школьный аттестат, то он может пригодится один раз в жизни - если при поступлении в ВУЗ у тебя и у кого-то еще совпадут баллы по ЕГЭ.

В ПТУ верно, всех берут. При чем тут вообще фриланс и прочее - не понятно. Иди хоть сегодня на апворк и работай, там ехать нужно, а не шашечки.

Два варианта: стейтфулл и стейтлесс
- стейтфулл - завести таймер (ссылку давали выше) на два часа, и выходить либо по приходу непустого ответа, либо по таймеру.
- стейтлесс - сохранить где-нибудь время начала, и при каждом пустом ответе читать его и сравнивать с текущим временем, при превышении - выйти. В этом случае нужно добавить хранилище (бд, файл, что угодно), но можно не бояться потерять процесс за два часа и вообще больше гибкости.

Все в кучу смешано, но попробую ответить. Вообще не понял, в чем суть данной инфраструктуры, ну да ладно.

Я так понял, у вас клиент-серверное взаимодействие реализовано посредством очередей поверх натса.
Не понятно, зачем у вас клиент хранит данные, хотя этим должен заниматься сервер. Возможно в этом есть некая подмена терминов.

Будем называть это так: есть первый сервис, подменяющий src_ip и dst_ip в пакете из очереди, и отправляющий в другую очередь.
Есть второй сервис, также подменяющий src_ip и dst_ip в пакете из очереди, но уже отправляющий их в сеть напрямую по завершению.
Есть задача в первом сервисе хранить некие персистентные данные.

Вот как бы я это сделал.
Все сервисы лучше делать стейтлесс, чтобы можно было запускать сколько нужно реплик и не бояться, что данные где-то перепутаются. Можно, конечно, запускать одно и пытаться на нем все вытянуть и хранить данные в оперативе, но оперативка не дешевая, а с одним приложением можно упереться определенные ограничения на большой нагрузке.

Итак, я бы сделал несколько сервисов:
- сервис 1, принимающий пакеты из очереди 1, меняющий их, используя данные из бд (и записывая в бд), и пишущий результат в очередь 2
- сервис 2, читающий из очереди 2, меняющий данные, и отправляющий их в интернет (не понимаю, почему назвали его сервером, если там больше логики, то мб. имеет смысл писать в очередь 3, из которой будет читать третий сервис и только отправлять пакеты в интернет)
- опционально сервис 3, читающий из очереди 3 и отправляющий данные в интернет

А также инфраструктура:
- натс
- бд (что больше подходит/нравится, ну я бы взял редис или монгу как самые элементарные)

При этом можно масштабировать каждый сервис (запускать реплики), чтобы справляться с нагрузками. Это можно делать в кубере, а можно еще как-то, дело ваше.

Но вообще выглядит как сильно переусложненная фигня, это можно сделать в одном приложениями с тремя воркерпулами и двумя каналами.

Ну прям из максимально изкоробочных наверное Hugo. Остальные, как gin и иже с ним - скорее тулкиты, нежели вреймворки. Но удобные, несомненно.

Вообще в го принято использовать микрофреймворки, то есть собирать из них нужный продукт, беря только то, что нужно, а не тянуть в проект миллионы строк кода ради всего лишь маршрутизации, как это принято, например, в питоне на примере с Django.

Хорошо это или плохо - открытый вопрос, но нужно это понимать, начиная писать сайт на го.

А так в стандартной либе есть html темплейты, можно писать, используя их, и вообще без фреймворков обойтись.

Попробуйте Rockstar - возможно это то, что вам нужно

https://github.com/dylanbeattie/rockstar

Как правильно отметили комментаторы выше, есть замечательный курс от МРГ, там две части и скоро должна появиться третья. Он условно-бесплатный (можно платить и пройти экзамен на сертификат). Очень годный, там рассматриваются прямо практические задачи и их решение. Подойдет для среднего уровня разработчика, хотя и новичку можно попробовать. По каждой теме есть задания, очень хорошие.
Первая часть
Вторая часть

Также могу порекомендовать порешать задачки на hackerrank.com и codewars.com.

Посмотрите тур по го - но там совсем базовые вещи. Есть и на русском, кажется.

Также неплохо будет почитать про бест праксис - это хорошо изложено здесь, но много.
Также сразу учитесь правильной организации файлов проекта здесь.

Ну и в целом читайте и смотрите все, что попадется под руку, поможет понять Go-way

Если хотите совсем загнаться по юзабилити, то сделайте несколько вариантов комментариев и возможность переключаться меджу ними. Где-то видел такое, удобно.
Например
- по дате добавления (список)
- по топику (дерево)
- по релевантности (лайки)
- etc.

использую GTasks на андроиде. Он синхронизуется с Google Tasks и событиями из Google Calendar. Удобно, что всегда под рукой.
Вообще, все приложения для тайм-менеджмента держу на телефоне, так как рабочие места меняются в течение дня.

В двух словах: у тебя установился второй загрузчик ОС (для убунты) и он ссылается на несуществующие файлы (которые ты удалил). Вот тут описано, какие загрузчики бывают, копай оттуда и снеси загрузчик убунты, тогда вновь обретешь покой.

Совет: если захочешь ставить линуксовые дистрибы вроде убунты, ставь не через винду, а через установочный диск, инсталер сам поможет разбить разделы как нужно, и поставит граб, чтобы удобно преключаться между системами. Это лучше в плане производительности

Вообще, начинать учить язык по книге кажется правильно, но не очень работает. Много хороших новых знаний смешивается, понятия разных уровней накладываются и на практике все равно делаешь не так.

Советую начинать изучение языка с написания кода. Есть много хороших онлайн ресурсов, где можно выполнять задачки в браузере, например Codecademy.
Или решать свои кейсы, хоть по стэковерфлоу, но начать писать. Потом, когда будешь читать книгу, будешь видеть не шквал новой информации, а более глубокое понимание того, что уже умеешь и исправление своих ошибок.

Я так питон учил, сначала на Codecademy курс прошел, потом нашел подработку удаленно, а сейчас Лутца читаю. И именно такое ощущение, когда я понимаю о чем речь, но узнаю тонкости и улучшаю свой стиль.

Идея ничего не стоит. Стоит ее реализация

Насколько я помню, во втором питоне такие строки нужно писать с принудительной кодировкой, в виде u"строка кириллицей"

Поставь сервер с нужной тебе версией, например, xampp. Времени займет уж точно меньше, чем установленный php откатывать.