Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 9

Зачем на гошке писать системы учета? Основная нагрузка всё равно на базу приходится. А небогатый синтаксис заставляет приседать чаще при постоянно меняющихся требованиях заказчика.

Богатство синтаксиса и тип приложений - ортогональные вещи. На 1С пишут системы учета, а синтаксис там самый бедный из всего, что имеется.
Синтаксис Go и его бедность - это на самом деле как недостаток, так и преимущество. Если смотреть со стороны скорости запила фичи - то кому то покажется, что недостаток. Если со стороны дальнейших многолетних поддержки и развития системы - то это сплошные преимущества. Читаемость и простота кода позволит с меньшей когнитивной нагрузкой годами обеспечивать нужное качество разработки.

"Если со стороны дальнейших многолетних поддержки и развития системы" - ну да, когда ты пишешь на нём какой-нибудь сервер или субд или инфраструктурную утилиту, которая не зависит от желания левой пятки босса или настроения Марь Иванны из отдела работы с талантами (отдела кадров), ну или постоянно обновляемых приказов или разъяснений из налоговой и других нормативных документов. 1С - это готовый фреймворк, который позволяет сразу приступить к реализации бизнес логики, который самому (любой компании), тем более на гошке собрать нереально.

Причем тут фреймворк и язык, чего вы все в кучу смешали?

А на каком языке предлагаете писать? :)

Ну и VK HR Tek - это все-таки больше не система учета а корпоративный портал теперь, но требований заказчиков приходится много реализовывать, да.

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

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

В 90% после запуска профилировщика находится узкое место, на которое никто не думал.

6 лет уже в такой прикладной области работаю и только 2 раза оказалось "место, на которое никто не думал". Один раз была таблица с большим количеством партиций и планировщик постгреса не мог с ней справиться нормально, зависал на пару секунд а второй раз оказалось что что-то с мапами намудрили и как раз слишком много вычислений было. В остальном за 6 лет такой практики всегда было понятно, куда смотреть в первую очередь.

Ну и у нас AMP сейчас настроен, так что высокоуровневые трейсы он показывает, хорошо помогает.

Но конечно я верю что есть проекты, где более интересные проблемы с перфомансом возникают )

А зачем автор 2 раза скопировал параграфы про уменьшение сложности?

Мне кажется эти советы подходят под любой язык программирования. Замените в статье Go на PHP, Ruby или Java и получите ещё лайков )

Зарегистрируйтесь на Хабре, чтобы оставить комментарий