Ничего не нужно от Linux? Хм. В новых ядрах средства для профилирования и трейсинга все лучше и лучше. При разработке Tarantool должно быть очень и очень полезно.
Если говорить о демонах, то в тот момент когда от Feature команды приходит запрос о каком-то функционале, то мы договариваемся о том какие изменения в API понадобятся и делаем их. Тут все просто, т.к. стороны всего две.
Если говорить о взаимодейтсвии между четырмя мобильными командами (iOS, Android, Windows Mobile, Mobile Web), платформой, веб командой, то у нас есть отдельная небольшая выделенная команда, которая занимается только API. По одному участнику из вот этих вот команд. Их задача договориться со всеми, понять и предугадать все возможные проблемы, записать результат в документ. По этому документу будут дальше работать люди, реализующие задачи.
Но я сам далек от всего этого и от команды, рабтающей с API. Думаю что коллеги вам еще ответят более конкретно :-)
Мне немного стыдно, но у нас для Go практически нет юнит тестов.
Мы, команда сишников, привыкли к тому что писать на Си юнит тесты сложно. Возможно, но требует настолько много усилий, что мы не видим в этом профита. Мы привыкли полагаться на свои небольшие функциональные/smoke тесты, написанные на Python и на полноценные подробные функциональные тесты, которые пишет наш отдел тестирования на PHP.
И вот эта вот привычка перешла на Go и мы пока не уделили этому должного внимания, чтобы ее перебороть. Все так же полагаемся на функциональные тесты, написанные отделом тестирования.
Хочу заметить что в Go довольно развиты инструменты для рефакторинга. И вот эти инструменты вместе с строгой типизацией позволяют вам быть более уверенными в правильности кода при рефакторинге. А ведь именно для этого часто пишут юнит тесты, так ведь?..
Интеграционные\функциональные тесты, как я уже написал, пишет отдел тестирования. Мы постарались сделать так, что демон на Go извне никак не отличается от демона на Си. Те же протоколы, те же конфиги, все то же самое. Так что отдел тестирования зачастую даже не задумывается о том, на чем написана система.
Go появился в Badoo из C/C++ команды, а не PHP команды. А нам сишникам как раз ближе Go. Уже после этого Go начали использовать и те люди, которые большую часть времени используют PHP.
Но, в любом случае, я не думаю что похожесть — это сильная причина. Кто-то ищет такой язык, который не похож на его основной язык. Таким образом он сможет решать большее количество разных задач.
Go, например, в отличие от nodejs или PHP, дает строгую типизацию. Для тех кто всю жизнь использовал не строгую, строгая может оказаться тем самым, что им всегда не хватало.
А вообще стыдно вам должно быть за такой вопрос! :-)
Я вот даже сохранил себе цитату, т.к. очень часто ее приходится вспоминать:
A great way to end the conversation early and avoid learning anything is to ask questions like:
— Why aren't you using Y?
— You should be using Z! (this isn't a question)
Go классный, няшный, интересный. Он активно развивается, но развивается с осторожность, не распыляясь налево и направо. И он позволяет нам быстро и эффективно решать наши задачи.
Быстро и качественно решенные задачи — плюс для бизнеса, няшность и интересность — плюс для разработчика.
Что касается полного ухода с PHP на Go, то ответ однозначный — нет.
Те задачи что решаются на ПХП решаются им прекрасно. Да, многие ворочают нос от ПХП, но это инструмент, который очень долгое время нас не подводил. Мы знаем как его готовить, у нас десятки и десятки людей, которые пишут на нем и миллионы и миллионы строк кода, написанных на нем.
Бонусы полного перехода на что-то иное (даже на Го) слишком призрачны.
Но, с другой стороны, я думаю что кол-во Go кода будет однозначно расти. И какие-то ПХП-шные части могут быть на нем переписаны.
Очень страшное письмо. У меня почти все завязано на личный домен в Google Apps, например.
Даже не представляю пока как все это переводить куда-то. Да и куда?..
Я так понимаю что речь о налоге на добавленную стоимость: «Мы не будем включать налог на добавленную стоимость в сумму оплаты за использование G Suite».
Вы ошибаетесь в том, что считаете что разработчики решают как будет выглядеть сайт/приложение. Этим занимается продуктовая команда, которая использует для принятия каких-то решений и A/B тесты и данные от BI команды и отзывы от пользователей и свой прошлый опыт.
К тому же, зачастую не так просто найти баланс между простотой и наполненностью фичами. Вон тот же Linux в несколько раз мощнее MacOS, но именно MacOS считается более удобной и user friendly.
Badoo и остальными нашими приложениями пользуются не только программисты 20 лет, но и простые люди, далекие от хитрых и мощных UI.
У меня лично около 5 положительных отзывов от самого ближайшего окружения. Люди находили себе пары и даже сиделок для ребенка на Badoo. Не совсем понимаю о чем вы говорите. Конретики бы.
Вы используете все эти новомодные слова или рассказываете теоретически? Просто все то что вы говорите выглядит красиво, но бьюсь об заклад что в реальности проблем 100500. Придется все свои существующие продукты переделывать так, чтобы они укладывались в видение Kubernetes как должно быть. А это примерно как «давайте перепишем все на Go».
Если говорить о взаимодейтсвии между четырмя мобильными командами (iOS, Android, Windows Mobile, Mobile Web), платформой, веб командой, то у нас есть отдельная небольшая выделенная команда, которая занимается только API. По одному участнику из вот этих вот команд. Их задача договориться со всеми, понять и предугадать все возможные проблемы, записать результат в документ. По этому документу будут дальше работать люди, реализующие задачи.
Но я сам далек от всего этого и от команды, рабтающей с API. Думаю что коллеги вам еще ответят более конкретно :-)
Мы, команда сишников, привыкли к тому что писать на Си юнит тесты сложно. Возможно, но требует настолько много усилий, что мы не видим в этом профита. Мы привыкли полагаться на свои небольшие функциональные/smoke тесты, написанные на Python и на полноценные подробные функциональные тесты, которые пишет наш отдел тестирования на PHP.
И вот эта вот привычка перешла на Go и мы пока не уделили этому должного внимания, чтобы ее перебороть. Все так же полагаемся на функциональные тесты, написанные отделом тестирования.
Хочу заметить что в Go довольно развиты инструменты для рефакторинга. И вот эти инструменты вместе с строгой типизацией позволяют вам быть более уверенными в правильности кода при рефакторинге. А ведь именно для этого часто пишут юнит тесты, так ведь?..
Интеграционные\функциональные тесты, как я уже написал, пишет отдел тестирования. Мы постарались сделать так, что демон на Go извне никак не отличается от демона на Си. Те же протоколы, те же конфиги, все то же самое. Так что отдел тестирования зачастую даже не задумывается о том, на чем написана система.
Go появился в Badoo из C/C++ команды, а не PHP команды. А нам сишникам как раз ближе Go. Уже после этого Go начали использовать и те люди, которые большую часть времени используют PHP.
Но, в любом случае, я не думаю что похожесть — это сильная причина. Кто-то ищет такой язык, который не похож на его основной язык. Таким образом он сможет решать большее количество разных задач.
Go, например, в отличие от nodejs или PHP, дает строгую типизацию. Для тех кто всю жизнь использовал не строгую, строгая может оказаться тем самым, что им всегда не хватало.
А вообще стыдно вам должно быть за такой вопрос! :-)
Я вот даже сохранил себе цитату, т.к. очень часто ее приходится вспоминать:
Go классный, няшный, интересный. Он активно развивается, но развивается с осторожность, не распыляясь налево и направо. И он позволяет нам быстро и эффективно решать наши задачи.
Быстро и качественно решенные задачи — плюс для бизнеса, няшность и интересность — плюс для разработчика.
Что касается полного ухода с PHP на Go, то ответ однозначный — нет.
Те задачи что решаются на ПХП решаются им прекрасно. Да, многие ворочают нос от ПХП, но это инструмент, который очень долгое время нас не подводил. Мы знаем как его готовить, у нас десятки и десятки людей, которые пишут на нем и миллионы и миллионы строк кода, написанных на нем.
Бонусы полного перехода на что-то иное (даже на Го) слишком призрачны.
Но, с другой стороны, я думаю что кол-во Go кода будет однозначно расти. И какие-то ПХП-шные части могут быть на нем переписаны.
А тут вот Google будет платить. Не понятно в чем разница.
Даже не представляю пока как все это переводить куда-то. Да и куда?..
К тому же, зачастую не так просто найти баланс между простотой и наполненностью фичами. Вон тот же Linux в несколько раз мощнее MacOS, но именно MacOS считается более удобной и user friendly.
Badoo и остальными нашими приложениями пользуются не только программисты 20 лет, но и простые люди, далекие от хитрых и мощных UI.
Подводя итоги, мне кажется вы совершаете такую же ошибку, как и те, кто пишет что «Stack Overflow можно написать за выходные»
Просто оплатить потраченное на эти несколько серверов в Amazon?
Закопайте уже ее…