Так везде, где эффект от разработки не научились считать. Для банка разработчик — постоянные расходы: то памяти им мало, то кресла нужны, то мониторы. А ощутимой непосредственной прибыли никакой.
Безопасность. Тут скажу просто — казалось бы глупые требования безопасности почти всегда растут из реальных кейсов и чьей-то кровью написаны. Просто глядя на требование, не всегда видно, откуда оно взялось.
Чьей кровью писаны правила «заявка должна отлежаться» и тому подобное? Не знаешь, чем объяснить всякую непотребщину и техничкескую глупость, объясняй соображениями безопасности. Так все делают.
Всё куда прозаичнее. Главная цель любой безопасности — отсутствие инцидентов. Чем меньше активности в компании, тем меньше этих самых инцидентов. Это относится и к сопровождению. Нет новой системы, нет лишней работы. Потому сабботаж любого внедрения любой системы — правило, а не исключение. Со стороны безопасности — закручивание гаек в ущерб здравому смыслу и продуктивности. А чрезмерное усиление безопасности ведёт к компроментации оной. Люди начинают пароли писать на бумажках приклеивая к монитору, пробивать доступы из подсетки в подсетку и пр.
Читал достаточно кода на Go (на Java — ещё больше), имею сказать, что в Go значительно проще понять, какие ветки породили ту или иную ошибку.
Тут, конечно, не только обработка ошибок, но и в целом подход к написанию программ: меньше динамики (в Java динамика — часть парадигмы языка). Но, когнитивная нагрузка при чтении исходников после введения check/handle в Go, конечно, возрастёт. Надеюсь, не сильно.
Для меня наоборот. Или вы сравниваете простой написанный сервис на golang и что-то монструозное со spring на Java? Так дело не в сложности языка, а в сложности фреймоворка. На golang ситуация лучше не станет.
Да, я сравниваю Go с Java или C#. И дело не только (да и не столько) в Spring. Просто, Spring — это такой мейнстрим в Java размером с Амазонку.
Все современные языки общего назначения (а не общего, — тем более), идут в комплекте со своей моделью проектирования. Ну, или, если хотите, Java-way, C#-way, Go-way, Ruby-way etc.
Это неустранимые особенности языков. У Java, кроме злоупотреблений с рефлексией и манипуляцией байт-кодом, главный бич: многословность, сиречь — тиражирование сущностей без необходимости.
Подскажите? Я знаю только статический анализ и форматирование (впрочем, статическим анализом вам все равно нужно будет занятся). Если вы походите с туза и скажите про асинхронищину, то есть тоже нужно заниматься, как и в любом другом языке, в силу ее сложности.
А с чем сравниваем? Скажу сразу, что сравнивать Go и Python бессмысленно. Это языки из разных ниш.
Я не о том, что они открывали в свободный доступ. Процитирую:
About a year ago, we decided to migrate our performance-critical backends from Python to Go to leverage better concurrency support and faster execution speed.
Если я правильно прочитал, то Google достал legacy код на С/С++ и они решили сделать себе С с человеческим лицом.
Нет, неправильно. Там же в первой главе, сразу: Go was designed and developed to make working in this environment more productive. Besides its better-known aspects such as built-in concurrency and garbage collection, Go's design considerations include rigorous dependency management, the adaptability of software architecture as systems grow, and robustness across the boundaries between components.
Следовательно, остальные ваши рассуждения про Си к теме никак не относятся, комментировать их бессмысленно.
Когда вы пишите большой проект на golang, вам приходится заниматься такими штуками, которые в других языках работают сами по себе.
А есть штуки, которые в Go есть, а в других языках ими нужно заниматься.
Я имел ввиду, что простота синтаксиса работает в обе стороны. Чем больше у вас кода, тем больше возникает дублирования, потому что из-за простоты синтаксиса вам от нее не избавится. И приходит время, когда дублирования очень много.
Код на Go для меня понятнее, чем на Java или C#. А дублирование кода или нет — дело десятое.
Стыдно признаться, но по указанной ссылке прямого указания про то, что Google не занимается корпоративным софтом не обнаружил. Что вы имели в виду, приведя эту ссылку на википедию?
Как раз нет. Go не создан для корпоративной разработки, и именно это многим в нем нравится.
Полагаю, вы в курсе, что Go создан Google? Полагаю, вы догадываетесь, что Google его создал и развивает для своей корпоративной разработки. Пожалуйста, посмотрите первоисточник: https://talks.golang.org/2012/splash.article
В частности, оттуда: Go is a programming language designed by Google to help solve Google's problems, and Google has big problems.
Как мы видим, «big problems» это не совсем то, что вы обозначили как «простые функциональные компоненты». Кстати, что это за понятие?
Он создан для простых функциональных компонентов, но как только вам приходится писать на нем большие приложения, все эти «удобные» решения превращаются в то, что вы делаете из go язык, к которому вы привыкли.
Тут дело в том, что Go стал модным и подтянулось много так называемой «школоты» которые кроме Go мало, что видели. И именно такие громче всех кричат, что нет бога кроме Go. Да и особенности рунета вносят свою лепту.
Примитивизм Go привлекает меня тем, что наконец-то можно писать в любимом стиле «что вижу, то пою». Без факторей, декораторов и IoC-контейнеров с AOP-ями.
Главным образом, Go сравниваю с Java, C#. Сравнения — не в пользу последних. Видно, что Go создан для корпоративной разработки, оттуда многие «странные» решения типа ошибки компиляции при неиспользуемом импорте.
И это совершенно отвратительно. Потому что тебе потом хочется предложить человеку новый фунционал, а у него библиотека docker-api отстает на несколько версий, как вот тут.
Что конкретно отвратительно? Вести разработку библиотек в открытом виде?
Если нет готового, сделайте форк этой утилиты — допишите API. Мне понадобился gowsdl, я просто поправил под себя.
Мне вот кажется, что все логично. Строить долгосрочные проекты на продуктах, поддержки которых вам никто не гарантирует довольно печальное занятие.
Гарантий нет, даже, если вы купите какой-либо фреймворк/библиотеку/продукт. У вендоров даже есть опция: при покупке какого-либо продукта предусматривается доступ к исходным кодам, если компания-продавец почила в бозе.
А для Go идеология Google — развивать и затягивать из открытых исходников к себе. А не развивать у себя, и открывать уже вовне.
Так везде, где эффект от разработки не научились считать. Для банка разработчик — постоянные расходы: то памяти им мало, то кресла нужны, то мониторы. А ощутимой непосредственной прибыли никакой.
Чьей кровью писаны правила «заявка должна отлежаться» и тому подобное? Не знаешь, чем объяснить всякую непотребщину и техничкескую глупость, объясняй соображениями безопасности. Так все делают.
Всё куда прозаичнее. Главная цель любой безопасности — отсутствие инцидентов. Чем меньше активности в компании, тем меньше этих самых инцидентов. Это относится и к сопровождению. Нет новой системы, нет лишней работы. Потому сабботаж любого внедрения любой системы — правило, а не исключение. Со стороны безопасности — закручивание гаек в ущерб здравому смыслу и продуктивности. А чрезмерное усиление безопасности ведёт к компроментации оной. Люди начинают пароли писать на бумажках приклеивая к монитору, пробивать доступы из подсетки в подсетку и пр.
Тут, конечно, не только обработка ошибок, но и в целом подход к написанию программ: меньше динамики (в Java динамика — часть парадигмы языка). Но, когнитивная нагрузка при чтении исходников после введения check/handle в Go, конечно, возрастёт. Надеюсь, не сильно.
Все современные языки общего назначения (а не общего, — тем более), идут в комплекте со своей моделью проектирования. Ну, или, если хотите, Java-way, C#-way, Go-way, Ruby-way etc.
Это неустранимые особенности языков. У Java, кроме злоупотреблений с рефлексией и манипуляцией байт-кодом, главный бич: многословность, сиречь — тиражирование сущностей без необходимости.
А с чем сравниваем? Скажу сразу, что сравнивать Go и Python бессмысленно. Это языки из разных ниш.
Предлагаете обсудить ABAP? Знакомы с ним?
About a year ago, we decided to migrate our performance-critical backends from Python to Go to leverage better concurrency support and faster execution speed.
На чём и как написаны и переписаны сервисы, — я без понятия.
gsuite.google.com
Ну и билинг они для этих и других сервисов вряд ли покупали.
Go was designed and developed to make working in this environment more productive. Besides its better-known aspects such as built-in concurrency and garbage collection, Go's design considerations include rigorous dependency management, the adaptability of software architecture as systems grow, and robustness across the boundaries between components.
Следовательно, остальные ваши рассуждения про Си к теме никак не относятся, комментировать их бессмысленно.
А есть штуки, которые в Go есть, а в других языках ими нужно заниматься.
Код на Go для меня понятнее, чем на Java или C#. А дублирование кода или нет — дело десятое.
Полагаю, вы в курсе, что Go создан Google? Полагаю, вы догадываетесь, что Google его создал и развивает для своей корпоративной разработки. Пожалуйста, посмотрите первоисточник:
https://talks.golang.org/2012/splash.article
В частности, оттуда:
Go is a programming language designed by Google to help solve Google's problems, and Google has big problems.
Как мы видим, «big problems» это не совсем то, что вы обозначили как «простые функциональные компоненты». Кстати, что это за понятие?
Не понял вашу мысль. Кто что из чего делает?
Примитивизм Go привлекает меня тем, что наконец-то можно писать в любимом стиле «что вижу, то пою». Без факторей, декораторов и IoC-контейнеров с AOP-ями.
Главным образом, Go сравниваю с Java, C#. Сравнения — не в пользу последних. Видно, что Go создан для корпоративной разработки, оттуда многие «странные» решения типа ошибки компиляции при неиспользуемом импорте.
Что конкретно отвратительно? Вести разработку библиотек в открытом виде?
Если нет готового, сделайте форк этой утилиты — допишите API. Мне понадобился gowsdl, я просто поправил под себя.
Гарантий нет, даже, если вы купите какой-либо фреймворк/библиотеку/продукт. У вендоров даже есть опция: при покупке какого-либо продукта предусматривается доступ к исходным кодам, если компания-продавец почила в бозе.
А для Go идеология Google — развивать и затягивать из открытых исходников к себе. А не развивать у себя, и открывать уже вовне.
Возможно, имелось в виду «сайд-эффекты»?