История изменений
Исправление OSBuster, (текущая версия) :
со скриптового языка на скриптовый, что имело мало смысла, банально потому, что на яве в три раза больше строчек писать
Так этому чудаку из топика и Java медленная.
Причём, что Twitter переезжал в бородатые годы, когда и оптимизаций в Python/Ruby/PHP было гораздо меньше и сервера были гораздо медленнее по всем параметрам (скорость CPU и размер кэшей, объём и пропускная способность RAM и т.п.).
10 лет спустя этот разрыв наоборот сократился и разница с мейнстримными скриптовыми языками стала ощущаться ещё менее остро. и стала в разы меньше.
В то время, успешный и прибыльный веб-проект в 2025 не обязательно теперь должен иметь в разы больше пользователей по сравнению с 2012.
Тут, наоборот, ещё попробуй дорасти до такой ситуации, когда тебе именно производительность виртуальной машины бэкенда станет ограничивающим развитие проекта и исчерпавшим возможности для скалирования фактором, а не I/O или что угодно ещё, вплоть до маркетинга.
У меня сейчас под рукой есть средний проект на Ruby: 4 тысячи классов, 203 тысячи строк кода, несколько сотен эндпойнтов, около 200Гб БД и под десять петабайт данных на S3. У проекта годовой ревеню в прошлом году был 80 миллионов USD, но всё это при не больше 2 тысяч единомоментных пользователей.
Это гибридный монолит, где несколько узких мест вынесено было в микросервисы в том числе и на Go.
Всё это крутится на VPN c 14Гб оперативки, где никогда не бывает занято больше 7Гб. И ещё несколько мелких серверов с 1-2.5Гб для обработки очередей задач.
Если предположить, что завтра это бесплатно и за одну секунду переписано на Go, то станет ли это несомненным плюсом? Да нет, разве что на пятьсот долларов в месяц надо будет меньше платить за хостинг (хотя и сейчас с огромным запасом оплачиваются вычислительные мощности, а основная статья расходов это хранение данных).
В то же время эти 4 тысячи классов и 203 тысячи строк кода (это бизнес-логика, не включая код самого феймворка и библиотек), без предыдущего метапрограммирования и кодогенерации в лучших традициях Smalltalk, распухнут в несколько раз со всеми этими портянками почти одинаковых гошных функций на каждый чих, обмазанных портянками if err != nil {} и поддержка и развитие этого всего той же самой командой из нескольких человек сильно усложнится, а скорость внесения изменений вырастет кратно.
В итоге расширение кодовой базы и команды встанет в гораздо большие деньги, чем спичечная экономия на хостинге. Т.е. это гипотетическое переписывание и переезд не то что не оправдано - оно напрямую навредит бизнесу, если он не критически зависим от RPS, и это его главная точка роста. Потому что гошные портянки это такой своеобразный трейдоф за батарейки. Если батарейки в конкретном случае не нужны, то и портянки бойлерплейта эти тоже. В них самих по себе ничего нет, кроме примитивности и многословности.
Плюс сейчас ещё модно дёргать LLM, тут тоже Go никаким боком не помогает и не имеет никаких преимуществ.
Исправление OSBuster, :
со скриптового языка на скриптовый, что имело мало смысла, банально потому, что на яве в три раза больше строчек писать
Так этому чудаку из топика и Java медленная.
Причём, что Twitter переезжал в бородатые годы, когда и оптимизаций в Python/Ruby/PHP было гораздо меньше и сервера были гораздо медленнее по всем параметрам (скорость CPU и размер кэшей, объём и пропускная способность RAM и т.п.).
10 лет спустя этот разрыв наоборот сократился и разница с мейнстримными скриптовыми языками стала ощущаться ещё менее остро. и стала в разы меньше.
В то время, успешный и прибыльный веб-проект в 2025 не обязательно теперь должен иметь в разы больше пользователей по сравнению с 2012.
Тут, наоборот, ещё попробуй дорасти до такой ситуации, когда тебе именно производительность виртуальной машины бэкенда станет ограничивающим развитие проекта и исчерпавшим возможности для скалирования фактором, а не I/O или что угодно ещё, вплоть до маркетинга.
У меня сейчас под рукой есть средний проект на Ruby: 4 тысячи классов, 203 тысячи строк кода, несколько сотен эндпойнтов, около 200Гб БД и под десять петабайт данных на S3. У проекта годовой ревеню в прошлом году был 80 миллионов USD, но всё это при не больше 2 тысяч единомоментных пользователей.
Это гибридный монолит, где несколько узких мест вынесено было в микросервисы в том числе и на Go.
Всё это крутится на VPN c 14Гб оперативки, где никогда не бывает занято больше 7Гб. И ещё несколько мелких серверов с 1-2.5Гб для обработки очередей задач.
Если предположить, что завтра это бесплатно и за одну секунду переписано на Go, то станет ли это несомненным плюсом? Да нет, разве что на пятьсот долларов в месяц надо будет меньше платить за хостинг (хотя и сейчас с огромным запасом оплачиваются вычислительные мощности, а основная статья расходов это хранение данных).
В то же время эти 4 тысячи классов и 203 тысячи строк кода (это бизнес-логика, не включая код самого феймворка и библиотек), без предыдущего метапрограммирования в лучших традициях Smalltalk, распухнут в несколько раз со всеми этими портянками почти одинаковых гошных функций на каждый чих, обмазанных портянками if err != nil {} и поддержка и развитие этого всего той же самой командой из нескольких человек сильно усложнится, а скорость внесения изменений вырастет кратно.
В итоге расширение кодовой базы и команды встанет в гораздо большие деньги, чем спичечная экономия на хостинге. Т.е. это гипотетическое переписывание и переезд не то что не оправдано - оно напрямую навредит бизнесу, если он не критически зависим от RPS, и это его главная точка роста. Потому что гошные портянки это такой своеобразный трейдоф за батарейки. Если батарейки в конкретном случае не нужны, то и портянки бойлерплейта эти тоже. В них самих по себе ничего нет, кроме примитивности и многословности.
Плюс сейчас ещё модно дёргать LLM, тут тоже Go никаким боком не помогает и не имеет никаких преимуществ.
Исправление OSBuster, :
со скриптового языка на скриптовый, что имело мало смысла, банально потому, что на яве в три раза больше строчек писать
Так этому чудаку из топика и Java медленная.
Причём, что Twitter переезжал в бородатые годы, когда и оптимизаций в Python/Ruby/PHP было гораздо меньше и сервера были гораздо медленнее по всем параметрам (скорость CPU и размер кэшей, объём и пропускная способность RAM и т.п.).
10 лет спустя этот разрыв наоборот сократился и разница с мейнстримными скриптовыми языками стала ощущаться ещё менее остро. и стала в разы меньше.
В то время, успешный и прибыльный веб-проект в 2025 не обязательно теперь должен иметь в разы больше пользователей по сравнению с 2012.
Тут, наоборот, ещё попробуй дорасти до такой ситуации, когда тебе именно производительность виртуальной машины бэкенда станет ограничивающим развитие проекта и исчерпавшим возможности для скалирования фактором, а не I/O или что угодно ещё, вплоть до маркетинга.
У меня сейчас под рукой есть средний проект на Ruby: 4 тысячи классов, 203 тысячи строк кода, несколько сотен эндпойнтов, около 200Гб БД и под десять петабайт данных на S3. У проекта годовой ревеню в прошлом году был 80 миллионов USD, но всё это при не больше 2 тысяч единомоментных пользователей.
Это гибридный монолит, где несколько узких мест вынесено было в микросервисы в том числе и на Go.
Всё это крутится на VPN c 14Гб оперативки, где никогда не бывает занято больше 7Гб. И ещё несколько мелких серверов с 1-2.5Гб для обработки очередей задач.
Если предположить, что завтра это бесплатно и за одну секунду переписано на Go, то станет ли это несомненным плюсом? Да нет, разве что на пятьсот долларов в месяц надо будет меньше платить за хостинг (хотя и сейчас с огромным запасом оплачиваются вычислительные мощности, а основная статья расходов это хранение данных).
В то же время эти 4 тысячи классов и 203 тысячи строк кода (это бизнес-логика, не включая код самого феймворка и библиотек), без предыдущего метапрограммирования в лучших традициях Smalltalk, распухнут в несколько раз со всеми этими портянками почти одинаковых гошных функций на каждый чих, обмазанных портянками if err != nil {} и поддержка и развитие этого всего той же самой командой из нескольких человек сильно усложнится, а скорость внесения изменений вырастет кратно.
В итоге расширение кодовой базы и команды встанет в гораздо большие деньги, чем спичечная экономия на хостинге. Т.е. это гипотетическое переписывание и переезд не то что не оправдано - оно напрямую навредит бизнесу, если он не критически зависим от RPS. Потому что гошные портянки это такой своеобразный трейдоф за батарейки. Если батарейки в конкретном случае не нужны, то и портянки бойлерплейта эти тоже. В них самих по себе ничего нет, кроме примитивности и многословности.
Плюс сейчас ещё модно дёргать LLM, тут тоже Go никаким боком не помогает и не имеет никаких преимуществ.
Исправление OSBuster, :
со скриптового языка на скриптовый, что имело мало смысла, банально потому, что на яве в три раза больше строчек писать
Так этому чудаку из топика и Java медленная.
Причём, что Twitter переезжал в бородатые годы, когда и оптимизаций в Python/Ruby/PHP было гораздо меньше и сервера были гораздо медленнее по всем параметрам (скорость CPU и размер кэшей, объём и пропускная способность RAM и т.п.).
10 лет спустя этот разрыв наоборот сократился и разница с мейнстримными скриптовыми языками стала ощущаться ещё менее остро. и стала в разы меньше.
В то время, успешный и прибыльный веб-проект в 2025 не обязательно теперь должен иметь в разы больше пользователей по сравнению с 2012.
Тут, наоборот, ещё попробуй дорасти до такой ситуации, когда тебе именно производительность виртуальной машины бэкенда станет ограничивающим развитие проекта и исчерпавшим возможности для скалирования фактором, а не I/O или что угодно ещё, вплоть до маркетинга.
У меня сейчас под рукой есть средний проект на Ruby: 4 тысячи классов, 203 тысячи строк кода, несколько сотен эндпойнтов, около 200Гб БД и под десять петабайт данных на S3. У проекта годовой ревеню в прошлом году был 80 миллионов USD, но всё это при не больше 2 тысяч единомоментных пользователей.
Это гибридный монолит, где несколько узких мест вынесено было в микросервисы в том числе и на Go.
Всё это крутится на VPN c 14Гб оперативки, где никогда не бывает занято больше 7Гб. И ещё несколько мелких серверов с 1-2.5Гб для обработки очередей задач.
Если предположить, что завтра это бесплатно и за одну секунду переписано на Go, то станет ли это несомненным плюсом? Да нет, разве что на пятьсот долларов в месяц надо будет меньше платить за хостинг (хотя и сейчас с огромным запасом оплачиваются вычислительные мощности, а основная статья расходов это хранение данных).
В то же время эти 4 тысячи классов и 203 тысячи строк кода (это бизнес-логика, не включая код самого феймворка и библиотек), без предыдущего метапрограммирования в лучших традициях Smalltalk, распухнут в несколько раз со всеми этими портянками почти одинаковых гошных функций на каждый чих, обмазанных портянками if err != nil {} и поддержка и развитие этого всего той же самой командой из нескольких человек сильно усложнится, а скорость внесения изменений вырастет кратно.
В итоге расширение кодовой базы и команды встанет в гораздо большие деньги, чем спичечная экономия на хостинге. Т.е. это гипотетическое переписывание и переезд не то что не оправдано - оно напрямую навредит бизнесу, если он не критически зависим от RPS.
Плюс сейчас ещё модно дёргать LLM, тут тоже Go никаким боком не помогает и не имеет никаких преимуществ.
Исправление OSBuster, :
со скриптового языка на скриптовый, что имело мало смысла, банально потому, что на яве в три раза больше строчек писать
Так этому чудаку из топика и Java медленная.
Причём, что Twitter переезжал в бородатые годы, когда и оптимизаций в Python/Ruby/PHP было гораздо меньше и сервера были гораздо медленнее по всем параметрам (скорость CPU и размер кэшей, объём и пропускная способность RAM и т.п.).
10 лет спустя этот разрыв наоборот сократился и разница с мейнстримными скриптовыми языками стала ощущаться ещё менее остро. и стала в разы меньше.
В то время, успешный и прибыльный веб-проект в 2025 не обязательно теперь должен иметь в разы больше пользователей по сравнению с 2012.
Тут, наоборот, ещё попробуй дорасти до такой ситуации, когда тебе именно производительность виртуальной машины бэкенда станет ограничивающим развитие проекта и исчерпавшим возможности для скалирования фактором, а не I/O или что угодно ещё, вплоть до маркетинга.
У меня сейчас под рукой есть средний проект на Ruby: 4 тысячи классов, 203 тысячи строк кода, несколько сотен эндпойнтов, около 200Гб БД и под десять петабайт данных на S3. У проекта годовой ревеню в прошлом году был 80 миллионов USD, но всё это при не больше 2 тысяч единомоментных пользователей.
Это гибридный монолит, где несколько узких мест вынесено было в микросервисы в том числе и на Go.
Всё это крутится на VPN c 14Гб оперативки, где никогда не бывает занято больше 7Гб. И ещё несколько мелких серверов с 1-2.5Гб для обработки очередей задач.
Если предположить, что завтра это бесплатно и за одну секунду переписано на Go, то станет ли это несомненным плюсом? Да нет, разве что на пятьсот долларов в месяц надо будет меньше платить за хостинг (хотя и сейчас с огромным запасом оплачиваются вычислительные мощности, а основная статья расходов это хранение данных).
В то же время эти 4 тысячи классов и 203 тысячи строк кода (это бизнес-логика, не включая код самого феймворка и библиотек), без предыдущего метапрограммирования в лучших традициях Smalltalk, распухнут в несколько раз со всеми этими портянками почти одинаковых гошных функций на каждый чих, обмазанных портянками if err != nil {} и поддержка и развитие этого всего той же самой командой из нескольких человек сильно усложнится, а скорость внесения изменений вырастет кратно.
В итоге расширение кодовой базы и команды встанет в гораздо большие деньги, чем спичечная экономия на хостинге. Т.е. это гипотетическое переписывание и переезд не то что не оправдано - оно напрямую навредит бизнесу, если он не критически зависим от RPS.
Плюс сейчас ещё модно дёргать LLM, тут тоже Go никаким боком не помогает и не имеет никаких преимуществ.
Исходная версия OSBuster, :
со скриптового языка на скриптовый, что имело мало смысла, банально потому, что на яве в три раза больше строчек писать
Так этому чудаку из топика и Java медленная.
Причём, что Twitter переезжал в бородатые годы, когда и оптимизаций в Python/Ruby/PHP было гораздо меньше и сервера были гораздо медленнее по всем параметрам (скорость CPU и размер кэшей, объём и пропускная способность RAM и т.п.).
10 лет спустя этот разрыв наоборот сократился и разница с мейнстримными скриптовыми языками стала ощущаться ещё менее остро. и стала в разы меньше.
В то время, успешный и прибыльный веб-проект в 2025 не обязательно теперь должен иметь в разы больше пользователей по сравнению с 2012.
Тут, наоборот, ещё попробуй дорасти до такой ситуации, когда тебе именно производительность виртуальной машины бэкенда станет ограничивающим развитие проекта и исчерпавшим возможности для скалирования фактором, а не I/O или что угодно ещё, вплоть до маркетинга.
У меня сейчас под рукой есть средний проект на Ruby: 4 тысячи классов 203 тысячи строк кода, несколько сотен эндпойнтов, около 200Гб БД и под десять петабайт данных на S3. У проекта годовой ревеню в прошлом году был 80 миллионов USD, но всё это при не больше 2 тысяч единомоментных пользователей.
Это гибридный монолит, где несколько узких мест вынесено было в микросервисы в том числе и на Go.
Всё это крутится на VPN c 14Гб оперативки, где никогда не бывает занято больше 7. И ещё несколько мелких серверов с 1-2.5Гб для обработки очередей задач.
Если предположить, что завтра это бесплатно и за одну секунду переписано на Go, то станет ли это несомненным плюсом? Да нет, разве что на пятьсот долларов в месяц надо будет меньше платить за хостинг (хотя и сейчас с огромным запасом оплачиваются вычислительные мощности, а основная статья расходов это хранение данных).
В то же время эти 4 тысячи классов и 203 тысячи строк кода (это бизнес-логика, не включая код самого феймворка и библиотек), без предыдущего метапрограммирования в лучших традициях Smalltalk, распухнут в несколько раз со всеми этими портянками почти одинаковых гошных функций на каждый чих обмазанных портянками if err != nil {} и поддержка и развитие этого всего командой той же самой командой из нескольких человек сильно усложнится, а скорость внесения изменений вырастет кратно.
В итоге расширение кодовой базы и команды встанет в гораздо большие деньги, чем спичечная экономия на хостинге. Т.е. это переписывание и переезд не то что не оправдано, оно напрямую навредит бизнесу.