Соотвественно хайпа в нём мало… что не мешает ему иметь сообщество разработчиков, сравнимое по размеру с такими языками, как Swift или Ruby… что достаточно удивительно, если вы вспомните, что Google не продвигает его так агрессивно, как Apple продвигает Swift и шума, подобного тому, что поднят вокруг Ruby-on-Rails тоже нету.
Не буду говорить за всех, но лично я узнал о существовании Ruby и Ruby-on-Rails когда игрался с бесплатными системами управления проектами и наткнулся на Redmine. Про Swift слышал чуть-чуть. Зато про Go из каждого "утюга".
И какой он хороший, и какой он плохой. И почему все должны равняться на него, и почему его нужно выбросить, забыть и никогда не вспоминать. Я не знаю насколько он широко используется, но упоминается практически везде.
Так что хайпа вокруг него куда больше, чем вокруг других языков появившихся после 2000 года, как мне кажется.
Ничего не мешает, это просто два разных подхода к решению одной проблемы. В каком-то одном случае будет удобен один вариант, в другом — другой.
Если ядро призвано только синхронизировать интерфейсы взаимодействия, то, возможно, проще будет поддерживать консистентность используя кодогенерацию, так как она обеспечивает меньшую свзяность проектов между собой. А если должна быть еще какая-то общая бизнес-логика, то лучше писать ядро.
И я не являюсь сторонником кодогенерации в Go, просто Вы одним махом записали всю кодогенерацию, как нечто ужасное.
А если вернуться к Go, то она еще и реализована довольно не удобно — ее нужно запускать каждый раз в ручную (по крайней мере из того, что я слышал).
Если уж кодогенерацию использовать, то модификация исходников для кодогенерации должна автоматически приводить к перегенерации кода в момент компиляции, а этого в Go нет.
Клиент и сервер могут быть написаны на одном языке, но быть независимыми проектами и разрабатываться разными командами. И тогда Thrift будет их стыковать. Т.е. и клиент, и сервер будут зависеть от некоторого третьего продукта, который будет представлять собой набор файлов Thrift.
Не такая она и ужасная. Местами очень даже полезная, взять тоже Thrift. Всему есть место, кроме копипасты. Копипасте тоже есть место, но очень редко и в исключительных случаях.
Так два дня тратятся на демо и ретро, и если на демо еще можно не привлекать всех разработчиков, то на ретро и планирование — нужно. Такова идея скрама. Эта та цена которая платится за возможность команды оперативно реагировать на меняющиеся требования к разрабатываемому ПО и предсказуемость сроков завершения (такое мнение у меня сложилось при чтении статей и заметок посвященных скраму). Мне ближе и комфортнее когда есть спецификация, ТЗ, бюджет и сроки. И никаких ретро, демо и ежедневных собраний.
Это правильно считать, что эффективное время будет 5 часов в день. 8 часов в день — это пришел и не отвлекаясь занимаешься задачей, обед и снова занимаешься задачей уже до конца рабочего дня. Ни каких телефонных разговоров или чатов. Ни каких взаимодействий между коллегами. Так редко когда получается. Или кто-нибудь позвонит, или кто-то что-то спросит. Спросить может и по рабочим вопросам, например, по ранее реализованной фичи, является ли странное поведение багом или фичей. А может кто-то из коллег попросит помощи. Так что если человек не проводит на работе 10 — 12 часов, то 8 часов тратить на задачу постоянно — не получится. В конце концов, человек может себя в какой-нибудь день плохо чувствовать и работать менее эффективно. Так что и без орг вопросов не получится тратить по 8 часов в день.
P.S.
Я к автору статьи не имею никакого отношения, исключительно мой личный опыт и опыт коллег.
А почему между серверами не сделать взаимодействие через обычный сокет, это разве не будет эффективнее и проще — меньше данных будет передаваться или я ошибаюсь?
А длина токена именно 256 байт у гугл, не бит (я не знаю, просто удивила такая длина)?
Особенно важно для коллекций: возвращайте Collections.emptyList() вместо null.
Мотивация у этого предложения та же, что у рекомендации использовать Optional?
На мой взгляд возвращать Optional имеет смысл когда в результате действия мы можем ничего не вернуть. Если говорить о коллекциях — нам есть разница пустая коллекция или "ничего" (тоже самое касательно строки, пустая строка — может быть валидным результатом). Так как пустая коллекция сама по себе тоже может быть результатом. При этом нельзя рассматривать пустой Optional как ошибку выполнения.
Думаю, просто провайдеры IaaS и SaaS будут укрупнятся и сокращение штата IT сотрудников в непрофильных компаниях, частично (а может и полностью), нивелируется расширением провайдеров и аутсорсинговых компаний. Как итог — рост минимальных требований к IT сотрудникам, уменьшение их зарплаты и уменьшение стоимости использования IaaS и SaaS для конечных пользователей.
На полностью собственной инфраструктуре останется гос. сектор (хотя логичнее появление специального облака), оборонная промышленность и некоторое количество очень крупных IT компаний (аутсорсеры, производители коробочного ПО), а остальные частично или полность перейдут на IaaS и SaaS.
Но опасатья, что IT специалисты останутся без работы — преждевременно. Опять же рост исследований в IT сфете бубет создавать, как научные, так и инженерные вакансии.
Ну я говорю, про условно домашнее применение. Да и с покупкой железа под Linux несколько сложнее надо искать смотреть на сайте производителя. Хотя сейчас, для некоторых устройствах, пишут на упаковке, что совместимо с Linux. Но совместимость, означает, что либо драйверов не нужно вовсе (чаще будет работать с граниченным функционалом) или есть драйвера на сайте производителя, но их установка не всегда тривиальна, чаще, гораздо сложнее чем запустить Setup.exe и следовать инструкциям.
Мне тоже Libre Office хватает с головой, и если что-то надо куда-то отправить или где-то показать, то делаю pdf — и никаких проблем. Но когда нужно отправить документ с вставленными картинками, а поверх картинок еще текст под наклоном написанный, вот тут все и разъезжалось в разные стороны. Но такое по разному отображалось и в разных версия MSO.
Кстати 1С 7.7 у меня запускалась на Windows Vista, без виртуалки, да и на Windows 7 тоже. Причем была версия которая требовала перкодировки БД и после этого она переставала работать нормально на Windows XP (требовалась перекодировка), а была версия и с патчем, в которой перекодировки не требовалось. Но это речь о 1С которая работала с локальной БД. А с необходимостью виртуалки я столкнулся позже с каким-то Банк-Клиентом, толи он сам, то ли часть отвечающая за криптографию не работали под Windows 7. Да и под линуксом у меня такое было. Мне понадобился кросс-компилятор для Symbian OS, он был или под Windows или под Linux c ядром 2.xx. А в тот момент уже все популярные дистрибутивы перешли на 3.xx и только debian еще можно было скачать со старым ядром.
Гораздо сложнее установить драйвера и ПО для большинства принтеров, сканеров (есть те который, просто подключил и все работает, но такие мне попадались редко). А если кто-то использует какие-нибудь хитрые мультимедийные клавиатуры и мышки, то их настройка может занять кучу времени, точнее поиск того как это сделать, сама настройка, скорей всего, закончится правкой нескольких строк в каком-нибудь конфиге.
Необходимость иметь именно MS Office, да еще и желательно конкретной версии, так как документ отредактированный в более новой версии может (и такое не редкость) криво отобразится в предыдущей версии. Проверял на 2016, 2010 и 2007 офисах, речь идет об docx файлах. С doc файлами проблем меньше, но и возможности редактирования меньше. С презентациями тоже грустно — сделанная в Open (Libre) Office с большой вероятностью криво откроется в MS Office.
Это, пожалуй, самое основное. По поводу Photoshop — не знаю, мне вполне хватает GIMP, а для векторной графики Inkscape. Я их и на Windows использую. У кого спрашивал по поводу сравнения Photoshop и GIMP, единственный реальный аргумент был в том, что интерфейс Photoshop удобнее. К GIMP сложно привыкнуть после него. Еще слышал, что Photoshop более функционален, но так никто точно и не назвал, чего именно не хватает в GIMP. Исключение — проприетарные конверторы из RAW которые идут вместе с фотоаппаратами. Но это опять же из области поддержки оборудования. Для своего я нашел конвертор, к сожалению, он расчитан на работу фотоаппарата со сменными объективами и не может автоматически исправить искажения созданные моим встроенным объективом с переменным зумом.
И в этом весь прикол что проголосовать не могу, а возможно и вообще не смогу из-за некоторых не указанных и не указываемых личностей.
Увы, но такова политика данного ресурса. Вы можете ее или принять, или перестать пользоваться. От того, что Вы напишите "+1" в комментариях рейтинг комментария/статьи/автора не изменится. Этот комментарий будет только замусоривать ленту, вызывать недовольство общественности и как результат — уменьшение рейтинга и кармы.
Кому как, я могу писать комментарии, но из меня статьеписатель просто никудышный.
Относитесь к комментариям как к мини-статьям на заданную (публикацией) тему. Тогда и ваш рейтинг не будет уменьшаться, а возможно и поднимется. Часто из комментариев можно получить много полезной информации, и не хотелось бы, чтобы обсуждение прерывалось бессмысленными комментариями.
Тему для публикации придумать не просто, согласен. Но, может быть, Вы читаете какой-нибудь тематический блог на другом языке и можете сделать хороший перевод. А может у вас есть собственный проект — попробуйте его презентовать, вдруг общественности это понравится. Можно попробовать сделать обзор программы (или плагина), которая вам сильно помогает. Или Вы сталкивались с какими-нибудь сложностями в работе и можете поделиться опытом.
Не обязательно, чтобы ваша статья несла что-то принципиально новое. Систематизация разрозненных знаний тоже может быть полезна и хорошо принята модераторами и пользователями Хабра.
Не буду говорить за всех, но лично я узнал о существовании Ruby и Ruby-on-Rails когда игрался с бесплатными системами управления проектами и наткнулся на Redmine. Про Swift слышал чуть-чуть. Зато про Go из каждого "утюга".
И какой он хороший, и какой он плохой. И почему все должны равняться на него, и почему его нужно выбросить, забыть и никогда не вспоминать. Я не знаю насколько он широко используется, но упоминается практически везде.
Так что хайпа вокруг него куда больше, чем вокруг других языков появившихся после 2000 года, как мне кажется.
Если ядро призвано только синхронизировать интерфейсы взаимодействия, то, возможно, проще будет поддерживать консистентность используя кодогенерацию, так как она обеспечивает меньшую свзяность проектов между собой. А если должна быть еще какая-то общая бизнес-логика, то лучше писать ядро.
А если вернуться к Go, то она еще и реализована довольно не удобно — ее нужно запускать каждый раз в ручную (по крайней мере из того, что я слышал).
Если уж кодогенерацию использовать, то модификация исходников для кодогенерации должна автоматически приводить к перегенерации кода в момент компиляции, а этого в Go нет.
P.S.
Я к автору статьи не имею никакого отношения, исключительно мой личный опыт и опыт коллег.
А почему между серверами не сделать взаимодействие через обычный сокет, это разве не будет эффективнее и проще — меньше данных будет передаваться или я ошибаюсь?
А длина токена именно 256 байт у гугл, не бит (я не знаю, просто удивила такая длина)?
На мой взгляд возвращать Optional имеет смысл когда в результате действия мы можем ничего не вернуть. Если говорить о коллекциях — нам есть разница пустая коллекция или "ничего" (тоже самое касательно строки, пустая строка — может быть валидным результатом). Так как пустая коллекция сама по себе тоже может быть результатом. При этом нельзя рассматривать пустой Optional как ошибку выполнения.
На полностью собственной инфраструктуре останется гос. сектор (хотя логичнее появление специального облака), оборонная промышленность и некоторое количество очень крупных IT компаний (аутсорсеры, производители коробочного ПО), а остальные частично или полность перейдут на IaaS и SaaS.
Но опасатья, что IT специалисты останутся без работы — преждевременно. Опять же рост исследований в IT сфете бубет создавать, как научные, так и инженерные вакансии.
Мне тоже Libre Office хватает с головой, и если что-то надо куда-то отправить или где-то показать, то делаю pdf — и никаких проблем. Но когда нужно отправить документ с вставленными картинками, а поверх картинок еще текст под наклоном написанный, вот тут все и разъезжалось в разные стороны. Но такое по разному отображалось и в разных версия MSO.
Кстати 1С 7.7 у меня запускалась на Windows Vista, без виртуалки, да и на Windows 7 тоже. Причем была версия которая требовала перкодировки БД и после этого она переставала работать нормально на Windows XP (требовалась перекодировка), а была версия и с патчем, в которой перекодировки не требовалось. Но это речь о 1С которая работала с локальной БД. А с необходимостью виртуалки я столкнулся позже с каким-то Банк-Клиентом, толи он сам, то ли часть отвечающая за криптографию не работали под Windows 7. Да и под линуксом у меня такое было. Мне понадобился кросс-компилятор для Symbian OS, он был или под Windows или под Linux c ядром 2.xx. А в тот момент уже все популярные дистрибутивы перешли на 3.xx и только debian еще можно было скачать со старым ядром.
То с чем сталкивался я:
Это, пожалуй, самое основное. По поводу Photoshop — не знаю, мне вполне хватает GIMP, а для векторной графики Inkscape. Я их и на Windows использую. У кого спрашивал по поводу сравнения Photoshop и GIMP, единственный реальный аргумент был в том, что интерфейс Photoshop удобнее. К GIMP сложно привыкнуть после него. Еще слышал, что Photoshop более функционален, но так никто точно и не назвал, чего именно не хватает в GIMP. Исключение — проприетарные конверторы из RAW которые идут вместе с фотоаппаратами. Но это опять же из области поддержки оборудования. Для своего я нашел конвертор, к сожалению, он расчитан на работу фотоаппарата со сменными объективами и не может автоматически исправить искажения созданные моим встроенным объективом с переменным зумом.
Увы, но такова политика данного ресурса. Вы можете ее или принять, или перестать пользоваться. От того, что Вы напишите "+1" в комментариях рейтинг комментария/статьи/автора не изменится. Этот комментарий будет только замусоривать ленту, вызывать недовольство общественности и как результат — уменьшение рейтинга и кармы.
Относитесь к комментариям как к мини-статьям на заданную (публикацией) тему. Тогда и ваш рейтинг не будет уменьшаться, а возможно и поднимется. Часто из комментариев можно получить много полезной информации, и не хотелось бы, чтобы обсуждение прерывалось бессмысленными комментариями.
Тему для публикации придумать не просто, согласен. Но, может быть, Вы читаете какой-нибудь тематический блог на другом языке и можете сделать хороший перевод. А может у вас есть собственный проект — попробуйте его презентовать, вдруг общественности это понравится. Можно попробовать сделать обзор программы (или плагина), которая вам сильно помогает. Или Вы сталкивались с какими-нибудь сложностями в работе и можете поделиться опытом.
Не обязательно, чтобы ваша статья несла что-то принципиально новое. Систематизация разрозненных знаний тоже может быть полезна и хорошо принята модераторами и пользователями Хабра.
Я не знаю, могут ли read-only пользователи голосовать за комментарии, но написать публикацию, которая пройдет модерацию — не самое сложное дело.