Comments 24
Похоже что буквально все, в разрез go way.
Реимплеминтировали руби на готрунтайме.
Сегодня мы уже ушли от Beego и Gorm
<Шумно выдохнул...>
Ну раз ушли, следующая статья обещает быть интересной. Ждём.
Несколько печально, что изначально не попробовали на go писать, как на go.
Но я рад, что многократно отказывался от ваших hr.
Не. Опять проходить азы гошки, ждать, когда команды дойдут до того, что монстрячие фреймворки не нужны, или что не нужно рядом с типом сразу писать его интерфейс. Так можно потерять года 3-4 на рост команды, а интересных задач даже рядом не будет.
А что делать эти 3-4 года? Без роста-то?
Ну ребята сами пишут, что у них ушла пара лет, чтобы из монстрячего фреймворка до gorm дойти. Сколько ещё уйдёт лет, чтобы от gorm до чего-то без 150 аллокаций памяти на update дойти? Ну и второй момент, заметьте, что в статье ребята не упоминают о разработке своих инструментов. А это на уровень ниже даже mail.ru, который неплохой easyjson сделал.
Ох ты ж! Rest наглядно.
Статья в целом приятная, удивил вот этот кусок:
Были смешные истории, когда человек реализовывал какую-то фичу, и только на код-ревью или вообще случайно узнавал, что, оказывается, нужно делать Go-сборку. А задача уже закрыта.
Это прямо из ряда вон, очень странное отношение к работе, может быть какая-то редкостная скриптовая закостенелость мышления...
(для тех кто не программирует на Go серьезные системы — в мире Go полноценные фреймворки не получили большого распространения; удобнее оказалось делать на узкозаточенных микрофреймворках, что реализуют небольшую часть функционала)
Beego и не go way выбран был в пользу плавного перехода для программистов(надо еще и фичи писать параллельно) Когда люди писали на RoR MVC им проще понимать куда код кидать в beego.
Далее мы с именем NewrelicStop регистрируем функцию startSegment, которая просто вызывает Go-агент и открывает новый сегмент обращения к базе данных.
Тут наверно имелось ввиду NewrelicStart
Продуктовая разработка на Go: история одного проекта