iqhater

но открыл для себя особенность, что если передавать ссылку в горутину, в горутине будет самое последнее значение переменной в цикле

это не 'особенность', это основная фича ссылок. В любом ЯП.

Сама переменная - это некоторая область в памяти, в которой записано то, что в этой переменной содержится.
При передаче параметра по значению ('без ссылок') создается еще одна такая же область в памяти, куда копируется содержимое исходной переменной. И код вызванной функции работает уже со своей копией.

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

Очевидно, что когда два куска кода одновременно могут писать читать в одно и то же место памяти - они мгновенно 'видят' изменения, вносимые каждым.

И, естественно, в общем случае без дополнительных усилий это не thread/goroutine/etc. safe. Причем в случае, если сама переменная - что-то посложнее int, то эффект от такой одновременной работы может быть гораздо более занятным, чем просто изменение значения.

Я пару недель назад перевёл сборку фронта с rollup на esbuild. Время сборки упало с 13с до 200мс (x65 ускорение). У коллег на M1 это время стало вообще 40мс

Из минусов заметил только отсутствие таргета ES5 (ну как заметил, об этом в доках пишут везде). Кстати, перевод таргета на ES6 уменьшил размер бандла незначительно (в основном за счёт сокращения function() в ()=>)

Больше проблем нет

нет в жизни ничего хуже чем работа на заказ в россии
лучше пилить один продукт и заниматься своими проектами

Попробуй поднять 300 кг, если никогда до этого не занимался тяжелой атлетикой.
Думаешь через 5 месяцев станет легко?

Мозг также само развивается не так быстро, как хочется.
Это только кажется что прочитал 10 книг и стал умнее. Надо решить тысячу задач, чтобы мозг привык их решать и начал оптимизировать собственные процессы.

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

Попробуйте следовать https://www.atlassian.com/ru/git/tutorials/compari...

К проблеме которую вы описали:

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

Не сливайте feature-ветку пока она не будет полностью протестирована и code-rewiew'ирована.
Склеивайте комиты в feature-ветке, чтобы их в итоге было не больше 1-3.

Из собственного опыта могу сказать, что чем крупнее и неспешнее проект - тем проще следовать git-flow.
А вот когда 1-2 разработчика и нужно вот сейчас ещё вчера запилить 10 фич... бывает сложновато.

Это вопрос дисциплины и организованности. Как ставятся задачи, как вы фокусируетесь на текущей фиче (нельзя носиться по всему проекту и фиксить по пути всё что под руку попалось). Организации самого проекта в конце концов - как изолированы компоненты и т.д.

Задавать окружающим вопросы. Ртом. Повторять пока не станет понятно

Бенчмарки - это хорошо, но очень важно понимать что именно там меряли и почему результаты именно такие.

Несколько лет назад я тоже делал бенчмарки Python, PHP, Node, Go.
Для меня были важны две вещи:
1 - скорость ответа сервера/кол-во запросов в секунду
2 - объём сервиса в памяти, т.к. от этого зависит стоимость ресурсов

На тесте, где сервисы не делали запросы в базу - из всех четверых лучше всего отработал Go с приличным отрывом, цифры, к сожалению, уже не помню.

Но вся эта разница сошла на нет, как только добавился всего один простой SQL запрос в базу, в таблицу с 10 строками. И на этом фоне разница по скорости ответа была меньше 10%.

Иными словами если ваш сервис работает с базой - критической разницы по скорости работы между Go/Rust/PHP/Node/Java, особо не будет.

Другое дело если ваш сервис не будет делать запросы в базу, или будет кешировать результаты запросов, тогда вы почувствуете ощутимую разницу.

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

Один экземпляр Go занимал в памяти порядка 6мб RAM, при том, что Pytho+Django порядка 60мб.
Node уже не помню сколько, но что-то близкое к Python'у.

Вот тут уже, когда серверов у вас будет много - количество серверов с Go у вас будет в 10 раз меньше, соответственно расходы за эти сервера у вас будут в 10 раз меньше :)

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

Где-то читал статью, что у людей было API на порядка 40 серверов на Node, после переписывания на Go - серверов осталось два, из которых второй запасной :)

Не надо загружать ветки. Ветка - для разработки. master - для "боевого кода".

Релизуем фичу в ветке, проверяем, если считаем, что все ок, мержим ее в мастер.
На коммит в мастер стартует CI/CD, который прогоняет тесты (они ведь у вас есть, правда?) и, в случае успешной сборки, проливает код на прод.