Перевод статьи технического директора компании CrowdStrike, о том, как и почему они перешли со Scala на Go по мере роста компании с 5 до 200+ человек.
Scala долгое время была частью стека нашей компании CrowdStrike, по сути даже главным языком. Я помогал внедрять Scala когда мы начали разрабатывать наш софт в 2012-м году. На самом деле, это было даже одной из главных причин моего перехода в CrowdStrike. Несколько основных разработчиков были заинтересованы во внедрении Scala, так что это был хороший вариант для всех.
Я перешёл из компании Gravity, которая достаточно активно использовала Scala. Это был основной язык в компании. Я привык к нему, мне он нравился, я видел его мощь и был уверен, что смогу предотвратить некоторые из сложностей, которые я видел в Scala, по мере того, как CrowdStrike будет расти. Мы делали высоконагруженную аналитику, batch-задачи на Hadoop и наш Chief Architect (привет, Биссел!) использовал лямбда-архитектуру задолго до того, как это стало модно.
Недавняя цитата от одного из наших senior-разработчиков заставила меня таки написать этот пост, описывающий, почему мы перевели большую часть нашего стека на Go, и почему новые сервисы мы по-умолчанию теперь пишем именно на Go.
Вместо того, чтобы заставлять ждать читателя до конца поста, я сразу скажу, что Scala не покидает наш стек полностью. По сути, она остается дополнением к Go в тех местах, где он не блещет. Scala является важным звеном в нашем стеке машинного обучения и аналитики. Она работает в связке с Java-продуктами, которые мы используем, и её возможность предоставлять приятный DSL для наших аналитиков, делает Scala до сих пор хорошим выбором. Но она стала больше специализированным инструментом вместо языка по-умолчанию.
Я передам вам эту историю через призму взгляда Технического Директора. Призму, в которой вам нужно расширять компанию с её ранних дней и 5 разработчиков до 200+ программистов по мере роста бизнеса. Это всё о том, чтобы иметь поддерживаемую кодовую базу, в которой люди легко могут переходить из проекта в проект и нанимать новых людей легко и быстро.
Я помню как я впервые увидел потенциальные проблемы в масштабируемости Scala в Gravity ещё в 2009/2010-м. Был конец рабочего дня, когда мы получили информацию о серьёзной проблеме в продакшене у одного из наших крупных клиентов. Несколько человек начали исследовать проблему, и мы смогли локализировать код, в котором случился сбой. Но настоящая проблема оказалась в том, что мы понятия не имели, что этот код делал. Мы упёрлись в странный символ, который мы никогда ранее в наших проектах не встречали. Это spaceship operator <|*|>. Кто-то сказал вслух «что это за хр**нь?». Там происходила какая-то неявная магия, которая была совсем неочевидна. Cmd-B чтобы перейти к методу не помогло, так как наша IDE не могла найти символ (IDE с тех пор улучшились). Быстрое гугление по "<|*|>" тоже не принесло результатов. Мы были загнаны в тупик.
Программист, который написал этот код, был недоступен, так как находился в отпуске, поэтому нам нужно было разобраться самостоятельно. Мы обнаружили недавно добавленную новую библиотеку, которая называлась scalaz, и через несколько часов мы нашли этот мистический символ и разобрались, что он делал, выкатили фикс, и все были счастливы. Но этот момент превратил фикс, который должен был занять пару минут, в многочасовую погоню. Это был момент, после которого я стал видеть раскол в нашей команде разработчиков.
Scala — это очень мощный язык, рождённый в академической среде, и который даёт вам достаточно гибкости, чтобы легко начать писать «write-once» код. Обычно Scala-разработчики разделяются на два лагеря — «Это лучший вариант Java»-лагерь и «Я (сердце) Аппликативные Функторы»-лагерь.
В лагере «Это лучший вариант Java» любят лаконичность Scala и стандартные фичи, которые делают Scala в целом более приятной, чем Java. В их коде есть функциональное программирование, но без фанатизма. В лагере же «Я (сердце) Аппликативные Функторы» функциональный мир расцветает на всю, и народ начинает углублять свои познания, принося свой уже функциональный бекграунд из языков вроде Haskell.
На моём опыте, я разделял эти два лагеря, и в каждом были отличные программисты, так что я не мог сказать, что один лагерь хуже или лучше другого. В полу-функциональном лагере было разве что потенциально больше более универсальных разработчиков, работающих с разными языками, или тех, кто не хотел изучать лямбда-исчисление, чтобы работать над API-сервером.
Как пример, вот кусочек кода одного из проекта, написанного одним из наших опытных Scala разработчиков:
Кто-то из вас посмотрит и скажет, что это блестяще, но кто-то скажет — WTF? Там были тысячи подобных строк кода. Это были те случаи, когда вся команда могла работать с кодом, но половина не хотела иметь с этим кодом дела вообще. Разработчик, который писал это — выдающийся программист, но тот факт, что его код раскалывал всю команду, было проблемой.
По мере роста команды этот раскол становился более очевидным, когда нужно было нанимать новых людей. У Scala есть немало мелких, но неприятных моментов вроде настройки среды разработки, боль с SBT, проблемы с настройкой IDE, медленное время сборки, большие старые JARы… И в добавок к этому большая доза новых концептов ScalaZ, что всё вместе приводило к долгому времени входа в проекты и замедлению продуктивности разработчиков. Теперь нам нужно было отвлекать разработчиков на предварительное обучение новичков, что также замедляло процессы. SBT тоже было отдельной болячкой. Всегда так получалось, что есть только один человек, который действительно понимает, что, блин, делает SBT и может разрулить проблемы у остальных.
И это не было чем-то уникальным в компаниях, на которые я работал. Twitter проходил через эти же проблемы роста, равно как и другие компании, с которыми я имел возможность общаться на конференциях, и другие люди, работающие со Scala, которых я знал. Это известная тема, на самом деле. В то время, когда вы можете быть невероятно продуктивны со Scala в маленьких командах, рост команды больше 50 человек превращается в тяжелую борьбу.
И в этот момент на сцену выходит Go. Одной из причин появления Go была возможность дать программистам быть более продуктивными, уменьшить количество способов, которыми можно сделать одно и то же и иметь очень определённый взгляд на мир с точки зрения компилятора. Я сопротивлялся Go внутренне некоторое время. Я не хотел ещё более раскалывать команду, заставлять людей учить ещё один язык, поскольку у нас и так было уже несколько технологий в стеке. У нас было внутреннее правило даже не рассматривать технологию, пока не будет хотя бы 3 человека, которые будут готовы поддерживать проблему с этой технологией в продакшене в 3 часа утра. После того, как меня достаточно в него потыкали (спасибо, Sean Berry), и необходимое количество в 3 человека было набрано, я углубился в изучение Go и увидел, что он решает нам массу проблем со Scala на организационном уровне.
Быстрое время компиляции, маленькие бинарники, один файл, встроенное форматирование, отличный инструментарий из коробки, встроенные тесты, профайлеры, отличная модель для конкурентного программирования? Ухты, продано! Мы успешно сделали тестовый проект на Go, потом ещё один, потом ещё, увеличили количество разработчиков, которые взялись за Go, и вскоре Go стал предпочитаемым языком, который люди сами выбирали. Вы можете прыгнуть в любой проект на Go и сразу же понять, что он делает. Скучаю ли я по иммутабельным типам и некоторым великолепным фичам в Scala? Конечно да, но я думаю, поддерживаемость кода слишком важна тут, чтобы упустить Go.
Ещё одним из преимуществ Go было расширение пула разработчиков, которых мы могли нанимать. Мы могли нанять практически любого программиста с разным бекграундом и знать, что он освоит Go за пару недель. Со Scala всегда сначала есть кривая обучения в JVM, мир Java контейнеров, тёмная магия тюнинга JVM и так далее.
Новые разработчики входили теперь в игру за недели, а не за месяцы. Сейчас у нас большинство наших проектов написаны на Go, и последний сопротивляющийся Go программист буквально на днях написал свой первый Go проект и сказал мне следующее: «Ухты, я прочёл код библиотеки один раз и я знал, что она делает. Я прочёл код Scala-версии библиотеки 4 раза и до сих пор не понимаю до конца, как она работает. Теперь я понимаю, почему вы так запали на Go». Это был один из наших senior-разработчиков, который ранее работал в одной из крупнейших web-компаний мира. Весь этот процесс перехода на Go был целиком инициирован снизу нашими разработчиками, и был выбором команды.
Сейчас мы обрабатываем сотни тысяч сообщений в секунду и терабайты данных в день с нашими сервисами на Golang.
В этой статье я не хочу поругать Scala или ScalaZ(я люблю ValidationNel!), но хочу дать больше контекста из реального продакшн мира с более чем 7-летним опытом в двух компаниях. Я по-прежнему использую Scala, и мне нравится играться со Scalding. Некоторые из наших следующих амбициозных проектов будут скорее всего на Scala, но я больше не считаю, что делать его основным языком будет правильным выбором, особенно по мере роста команды. Go с тех пор стал моим языком по-умолчанию.
Go делает процесс разработки слишком простым.
Scala долгое время была частью стека нашей компании CrowdStrike, по сути даже главным языком. Я помогал внедрять Scala когда мы начали разрабатывать наш софт в 2012-м году. На самом деле, это было даже одной из главных причин моего перехода в CrowdStrike. Несколько основных разработчиков были заинтересованы во внедрении Scala, так что это был хороший вариант для всех.
Я перешёл из компании Gravity, которая достаточно активно использовала Scala. Это был основной язык в компании. Я привык к нему, мне он нравился, я видел его мощь и был уверен, что смогу предотвратить некоторые из сложностей, которые я видел в Scala, по мере того, как CrowdStrike будет расти. Мы делали высоконагруженную аналитику, batch-задачи на Hadoop и наш Chief Architect (привет, Биссел!) использовал лямбда-архитектуру задолго до того, как это стало модно.
Недавняя цитата от одного из наших senior-разработчиков заставила меня таки написать этот пост, описывающий, почему мы перевели большую часть нашего стека на Go, и почему новые сервисы мы по-умолчанию теперь пишем именно на Go.
Вместо того, чтобы заставлять ждать читателя до конца поста, я сразу скажу, что Scala не покидает наш стек полностью. По сути, она остается дополнением к Go в тех местах, где он не блещет. Scala является важным звеном в нашем стеке машинного обучения и аналитики. Она работает в связке с Java-продуктами, которые мы используем, и её возможность предоставлять приятный DSL для наших аналитиков, делает Scala до сих пор хорошим выбором. Но она стала больше специализированным инструментом вместо языка по-умолчанию.
Я передам вам эту историю через призму взгляда Технического Директора. Призму, в которой вам нужно расширять компанию с её ранних дней и 5 разработчиков до 200+ программистов по мере роста бизнеса. Это всё о том, чтобы иметь поддерживаемую кодовую базу, в которой люди легко могут переходить из проекта в проект и нанимать новых людей легко и быстро.
Я помню как я впервые увидел потенциальные проблемы в масштабируемости Scala в Gravity ещё в 2009/2010-м. Был конец рабочего дня, когда мы получили информацию о серьёзной проблеме в продакшене у одного из наших крупных клиентов. Несколько человек начали исследовать проблему, и мы смогли локализировать код, в котором случился сбой. Но настоящая проблема оказалась в том, что мы понятия не имели, что этот код делал. Мы упёрлись в странный символ, который мы никогда ранее в наших проектах не встречали. Это spaceship operator <|*|>. Кто-то сказал вслух «что это за хр**нь?». Там происходила какая-то неявная магия, которая была совсем неочевидна. Cmd-B чтобы перейти к методу не помогло, так как наша IDE не могла найти символ (IDE с тех пор улучшились). Быстрое гугление по "<|*|>" тоже не принесло результатов. Мы были загнаны в тупик.
Программист, который написал этот код, был недоступен, так как находился в отпуске, поэтому нам нужно было разобраться самостоятельно. Мы обнаружили недавно добавленную новую библиотеку, которая называлась scalaz, и через несколько часов мы нашли этот мистический символ и разобрались, что он делал, выкатили фикс, и все были счастливы. Но этот момент превратил фикс, который должен был занять пару минут, в многочасовую погоню. Это был момент, после которого я стал видеть раскол в нашей команде разработчиков.
Scala — это очень мощный язык, рождённый в академической среде, и который даёт вам достаточно гибкости, чтобы легко начать писать «write-once» код. Обычно Scala-разработчики разделяются на два лагеря — «Это лучший вариант Java»-лагерь и «Я (сердце) Аппликативные Функторы»-лагерь.
В лагере «Это лучший вариант Java» любят лаконичность Scala и стандартные фичи, которые делают Scala в целом более приятной, чем Java. В их коде есть функциональное программирование, но без фанатизма. В лагере же «Я (сердце) Аппликативные Функторы» функциональный мир расцветает на всю, и народ начинает углублять свои познания, принося свой уже функциональный бекграунд из языков вроде Haskell.
На моём опыте, я разделял эти два лагеря, и в каждом были отличные программисты, так что я не мог сказать, что один лагерь хуже или лучше другого. В полу-функциональном лагере было разве что потенциально больше более универсальных разработчиков, работающих с разными языками, или тех, кто не хотел изучать лямбда-исчисление, чтобы работать над API-сервером.
Как пример, вот кусочек кода одного из проекта, написанного одним из наших опытных Scala разработчиков:
import scalaz._
import scalaz.std.list._
import scalaz.syntax.monad._
import scalaz.syntax.monoid._
import scalaz.syntax.traverse.{ToFunctorOps => _, _}
class Foo[F[+_] : Monad, A, B](val execute: Foo.Request[A] => F[B], val joins: Foo.Request[A] => B => List[Foo.Request[A]])(implicit J: Foo.Join[A, B]) {
def bar: Foo[({type l[+a]=WriterT[F, Log[A, B], a]})#l, A, B] = {
type TraceW[FF[+_], +AA] = WriterT[FF, Log[A, B], AA]
def execute(request: Request[A]): WriterT[F, Log[A, B], B] =
self.execute(request).liftM[TraceW] :++>> (repr => List(request -> request.response(repr, self.joins(request)(repr))))
----- REDACTED -------Кто-то из вас посмотрит и скажет, что это блестяще, но кто-то скажет — WTF? Там были тысячи подобных строк кода. Это были те случаи, когда вся команда могла работать с кодом, но половина не хотела иметь с этим кодом дела вообще. Разработчик, который писал это — выдающийся программист, но тот факт, что его код раскалывал всю команду, было проблемой.
По мере роста команды этот раскол становился более очевидным, когда нужно было нанимать новых людей. У Scala есть немало мелких, но неприятных моментов вроде настройки среды разработки, боль с SBT, проблемы с настройкой IDE, медленное время сборки, большие старые JARы… И в добавок к этому большая доза новых концептов ScalaZ, что всё вместе приводило к долгому времени входа в проекты и замедлению продуктивности разработчиков. Теперь нам нужно было отвлекать разработчиков на предварительное обучение новичков, что также замедляло процессы. SBT тоже было отдельной болячкой. Всегда так получалось, что есть только один человек, который действительно понимает, что, блин, делает SBT и может разрулить проблемы у остальных.
И это не было чем-то уникальным в компаниях, на которые я работал. Twitter проходил через эти же проблемы роста, равно как и другие компании, с которыми я имел возможность общаться на конференциях, и другие люди, работающие со Scala, которых я знал. Это известная тема, на самом деле. В то время, когда вы можете быть невероятно продуктивны со Scala в маленьких командах, рост команды больше 50 человек превращается в тяжелую борьбу.
И в этот момент на сцену выходит Go. Одной из причин появления Go была возможность дать программистам быть более продуктивными, уменьшить количество способов, которыми можно сделать одно и то же и иметь очень определённый взгляд на мир с точки зрения компилятора. Я сопротивлялся Go внутренне некоторое время. Я не хотел ещё более раскалывать команду, заставлять людей учить ещё один язык, поскольку у нас и так было уже несколько технологий в стеке. У нас было внутреннее правило даже не рассматривать технологию, пока не будет хотя бы 3 человека, которые будут готовы поддерживать проблему с этой технологией в продакшене в 3 часа утра. После того, как меня достаточно в него потыкали (спасибо, Sean Berry), и необходимое количество в 3 человека было набрано, я углубился в изучение Go и увидел, что он решает нам массу проблем со Scala на организационном уровне.
Быстрое время компиляции, маленькие бинарники, один файл, встроенное форматирование, отличный инструментарий из коробки, встроенные тесты, профайлеры, отличная модель для конкурентного программирования? Ухты, продано! Мы успешно сделали тестовый проект на Go, потом ещё один, потом ещё, увеличили количество разработчиков, которые взялись за Go, и вскоре Go стал предпочитаемым языком, который люди сами выбирали. Вы можете прыгнуть в любой проект на Go и сразу же понять, что он делает. Скучаю ли я по иммутабельным типам и некоторым великолепным фичам в Scala? Конечно да, но я думаю, поддерживаемость кода слишком важна тут, чтобы упустить Go.
Ещё одним из преимуществ Go было расширение пула разработчиков, которых мы могли нанимать. Мы могли нанять практически любого программиста с разным бекграундом и знать, что он освоит Go за пару недель. Со Scala всегда сначала есть кривая обучения в JVM, мир Java контейнеров, тёмная магия тюнинга JVM и так далее.
Новые разработчики входили теперь в игру за недели, а не за месяцы. Сейчас у нас большинство наших проектов написаны на Go, и последний сопротивляющийся Go программист буквально на днях написал свой первый Go проект и сказал мне следующее: «Ухты, я прочёл код библиотеки один раз и я знал, что она делает. Я прочёл код Scala-версии библиотеки 4 раза и до сих пор не понимаю до конца, как она работает. Теперь я понимаю, почему вы так запали на Go». Это был один из наших senior-разработчиков, который ранее работал в одной из крупнейших web-компаний мира. Весь этот процесс перехода на Go был целиком инициирован снизу нашими разработчиками, и был выбором команды.
Сейчас мы обрабатываем сотни тысяч сообщений в секунду и терабайты данных в день с нашими сервисами на Golang.
В этой статье я не хочу поругать Scala или ScalaZ(я люблю ValidationNel!), но хочу дать больше контекста из реального продакшн мира с более чем 7-летним опытом в двух компаниях. Я по-прежнему использую Scala, и мне нравится играться со Scalding. Некоторые из наших следующих амбициозных проектов будут скорее всего на Scala, но я больше не считаю, что делать его основным языком будет правильным выбором, особенно по мере роста команды. Go с тех пор стал моим языком по-умолчанию.
Go делает процесс разработки слишком простым.
x2bool
Забавно наблюдать, как меняется мода: еще недавно все хипстеры писали на Ruby, потом много шума было вокруг Scala, и, вот, теперь Go это наше всё! Интересно, какой язык будет следующим?
divan0
Может быть это не хипстеры, а люди, которые используют правильные технологии для правильных задач, и постоянно развиваются по мере того, как меняется мир? :)
kekekeks
Пока что я вижу в новостях на всяких opennet-ах кучу утилит на Go, целью написания которых является написание их на Go.
divan0
Утилиты типа Docker, Consul, Vault и Kubernetes?
Возьмите пример этой статьи — люди пишут код для себя. Вы об их софте, который решает необходимые им задачи, вряд ли узнаете на opennet-е.
kekekeks
ctrlok
Не ради докера, но это не правда.
kekekeks
Не правда что именно?
ctrlok
>>> в которой нельзя поменять конфиг, не пересоздав контейнер
контейнер это не какая-то виртуальная машина, это просто процесс, ограниченный всякими неймспейсами и сигрупами. Соответственно рассматривать контейнер надо именно как такой процесс, с которым можно взаимодействовать так же как с обычным процессом в чруте. Кроме прочего, в самом докере для упрощения есть механизмы волюмов и конфиги можно доставлять не при помощи всяких ansible, но и при помощи инфраструктуры докера, формируя из конфигов отдельные дата контейнеры (если вы хотите версионировать конфиги, тегировать их и так далее). Ну то есть докер скорее расширяет возможность доставки конфига, чем нет.
Ещё можно маунтить какволюмы файлы с обычной ОС.
kekekeks
Не говоря уже о ряде странных технических решений типа невозможности задать контейнеру заранее заданый IP-адрес (с тем чтобы не издеваться с конфигами nginx-а на хосте, например) и пробросе по-умолчанию портов через прокси-процесс, что приводит к весьма забавным эффектам при попытке пробросить в контейнер диапазон из пары тысяч портов (нужно для вещей типа фрисвича).
ctrlok
В смысле учите матчасть? Это процесс ограниченый неймспейсами и сигрупами. Могу запустить такой же процесс без докер контейнера.
Сетевые устройства могут быть, а могут и не быть, если ты делаешь network=host
То есть chroot и jail это тоже контейнер?))
В смысле? Я могу хоть прямо в его ФС залезть в хостовой машины.
ctrlok
например, вот гифка.
kekekeks
docker execвообще слышали? Выдержка из хэлпа:Если контейнер — это процесс, то как в процессе можно запустить команду? Докероконтейнер — по сути та же OpenVZшная виртуалка, но с набором слоёв aufs в качестве корневой ФС и с пользовательским исполняемым файлом в качестве процесса init.
Есть запущенный контейнер, например:
Добавьте сюда проброшенный порт не прибегая к командам docker rm и docker create, пожалуйста.
ctrlok
… Изначально утверждение было про поменять конфиг не рестартуя контейнер, но ок :) Я уже привык к тому что люди меняют аргументы на ходу.
но вообще можно стартовать в net=host и тогда ничего никуда можно не пробрасывать. Нетворкинг с пробросами это дополнительные плюшки и они реализованы при помощи iptables. Или при помощи новых сетевых драйверов (там можно много чего накрутить)
fralef.me/docker-and-iptables.html
Смысл в том что это доволнительные сетевые плюшки, которые вы можете прикрутить и к обычному процессу. Например, я могу и обычный процесс запустить в неймспейсе с ограничением по какому-то интерфейсу.
ctrlok
ну и чтобы не быть голословным, то вот гифка :)
kekekeks
Вы НЕ поменяли конфиг контейнера, вы поменяли iptables. Когда контейнер перезапустят (
По-умолчанию задействован не iptables, а процесс прокся, отключать которую можно только с версии 1.7 (см.docker stop+docker start) ваши портмаппинги слетят.userland-proxy)В общем, из разговора с вами сложилось впечатление, что:
1) вы не осознавали, что в контейнере может быть несколько процессов и обзываете контейнер процессом.
2) вы не осознаёте, что у контейнера есть состояние файловой системи, что контейнер можно останавливать и заново запускать, сохраняя это состояние
3) вы не понимаете как внутри работает докер и, по всей видимости, не пользуетесь половиной его возможностей
4) вы кидаетесь гифками, на которых делаете не то, о чём вас просят
Поведение достойное тролля или воинствующего школьника с ЛОРа. Далее какую-либо дискуссию продолжать не вижу смысла.
ctrlok
Вы произвольно меняете условия задачи сразу после того как я предложил решение. Это показательно.
creker
Мне кажется это скорее вы с самого начала не поняли человека. Я прекрасно понял, о чем он говорил изначально. Меня самого парит докер этим — уже упомянутые маппинги портов залочены за контейнером, их нельзя менять не удаляя и пересоздавая его. По крайней мере, я не знаю такого способа. Хотя, казалось бы, вот тебе JSON'чик со всеми конфигами. Бери да меняй. К слову, автозапуск я так вручную и добавлял туда, и все работало.
ctrlok
ну вот я только после его последнего комментария сумел догадаться в чём у kekekeks проблема.
ctrlok
Ну слетят, и что? на самом деле я просто востановил правила iptables из того времени когда процесс был запущен с мапингов портов.
1) вы врубаетесь что вы путаете контейнер, неймспейсы, сигруппы и всё на свете в одну гиганскую кашу, после чего говорите выводы типа «нельзя изменить конфиг файл не рестартанув»?
2) это вообще каша. Откуда вы это взяли после того как я вам показал как я меняю ФС в контейнере?
3) очень странное утверждение после того как я вам показал несколько вариантов решения вами же поставленных и по вашим словам «невозможных» задач.
4) сформулируйте конкретнее, я бы прочитал ваши мысли, да вот телепаты в отпуске.
Обвинять меня в школьничестве немного по-детски, наверное :)
ctrlok
Хотя, если вы изначально имели ввиду конфиг контейнера, а не конфиг файл внутри ФС, то я действительно не понял условие задачи. Хотя мне кажется что вы могли 100 раз сказать где я ошибся с условием, потому что я в первом же комментарии рассуждал о том как доставлять конфиг файлы.
ctrlok
ну и если бы я хотел вас протролить, я бы предложил сделать docker exec в контейнер в котором не ранается ни один процесс, вы ведь как раз эту команду упоминали :)
ctrlok
ну и по существу. Достаточно тупо обвинять инструмент который декларирует иммутабельность в том что сущности, которые он создает иммутабелены.
Приведите, пожалуйста, практические примеры задач в которых надо менять контейнеры после создания и нельзя пересоздавать.
x2bool
Эммм… лично я люблю плюшки из новых языков программирования, но когда компания переезжает со Scala на Go, сразу ясно что это за люди. Вряд ли там сидят суровые прагматики. В этом случае причина перехода скорее в тяге к новому, чем в необходимости.
divan0
В этом и дело. Когда у вас 5 человек, где вы лично держите в голове код вашего сервиса — плюшки могут быть аргументом. Когда у вас 200+ человек, ваши плюшки — это помеха и торможение процессов.
Эта статья мне очень понравилась именно тем, что хорошо это демонстрирует.
x2bool
Разъясните мне тогда, пожалуйста, такую вещь: когда компания, про которую в статье идет речь, обожглась, используя Scala, они решили уйти в Go. Они туда пошли за чем? За простотой? А что тогда они не ушли в Java?
Они всего-навсего пошли за другими, более модными плюшками, прикрываясь тем, что Go проще, и что Scala не масштабируется (какая ирония, учитывая название языка!).
divan0
Не знаю, работали ли вы в компаниях, которые растут с 3х человек до 50+, но ваши рассуждения очень поверхностны. «Пошли всего-навсего за плюшками» совсем не отражает тех процессов, когда рост компании приводит к реальным затыкам и проблемам в разработке и поддержке кода.
Тут же вообще весь процесс был инициирован снизу, самими разработчиками, поэтому вопрос «за чем они ушли» не совсем корректен. Они ушли, потому что Go позволял им быстрее и качественнее получать результат в масштабе компании. Только и всего.
kazmiruk
Не такие уж и поверхностные рассуждения. Сами разработчики инициировали процесс? А сколько из инициировавших разработчиков реально работало с Go в крупных проектах до этого? Думаю в лучшем случае единицы, так как язык довольно молодой, а на момент событий, описываемых автором и того младше. Т.е. реально у разработчиков не было опыта разработки коммерческих продуктов на Go и весь переход был обусловлен тем, что разработчика хлебом не корми, а дай поучить что-нибудь новое, да еще и за з\п. В итоге начался процесс перетягивания толпы специалистов с одной технологии на другую. И то, как я понял по статье не просто перетягивание. Теперь при найме разработчика он должен обладать навыками и в scala, и в go, так как часть кода все также написана на scala. Следовательно никто не дает гарантии, что новый разработчик секты Go не будет часами втупливать на какую-то legacy утилиту компании на scala. И что тогда поменялось? Может просто стоило делать ревью, ввести более строгий code style на scala, а не рубить с плеча?
divan0
Мне кажется, у них все чуть более грамотно построено, чем вы только что описали. Согласитесь, описанные вами проблемы сильно зависят от деталей процессов компании, которых мы не знаем.
Понятно )
kazmiruk
Я не гадаю, а говорю о том, что прочитал только что в статье. Не исключено, что причины вообще не такие, как описаны (если у Вас есть более подробная информация — изложите в статье и мы не будем гадать). Но по статье я вижу, что у них отсутствовал единый стиль (о чем автор сам сказал выделив две группы в команде), не было ревью (иначе 2 примера из статьи не прошли бы проверку), каждый разработчик старался повысить JSI (что абсолютно подтверждается примером с тем, что они не смогли разобраться в коде когда автор кода был в отпуске), а еще их старшие разработчики, работавшие в «крупнейших компаниях мира» не могут понять scala код и разобраться как работает SBT. Думаю это говорит достаточно об авторе оригинальной статьи и команде.
divan0
Не думаю. Статья довольно сжатая, чтобы рассказать обо всех разработчиках, описать детали, особенно на разных стадиях роста компании. Поэтому неверно будет хвататься за один описанный случай и экстраполировать его все процессы компании. Кроме того, у меня, к примеру нет опыта управления командой из 200 человек, и я не уверен, что в реальном бизнесе просто найти 200 людей, которые могут разобраться во всем досконально, особенно если на это уходят месяцы. Тут бывает сложно найти одного минимально толкового человека, а тут 200!
Или у вас есть другой опыт, и вы считаете, что найти 200 великолепных scala-гениев достаточно просто, нужен просто хороший тех.дир.?
kazmiruk
В том и дело, что Вы сами судите по сжатой статье о том, что у них все было идеально в организации, но scala мешала жить, а только благодаря Go все стало как в раю. А почти каждый комментирующий пытается убедить Вас в том, что не все так просто. Про мой опыт — Вы так спрашиваете об это у каждого, как будто это что-то изменит. Да, людей, которые управляли бы 200 разработчиками в мире единицы. Но это не значит, что эти люди принимает всегда только верные решения. Отвечая на Ваш вопрос — я управлял максимум 8 разработчиками. Да, это очень трудная задача даже с куда меньшими количествами. Но с другой стороны опыт Демарка и Спольски говорит, что 200 разработчиков не всегда лучше 20, особенно, если нет возможности нанять «scala-гениев» и начинаешь брать людей, которые не могут разобраться в sbt.
divan0
Вам не надоело еще приписывать мне слова, которые я не говорил? Я понимаю, что легко сказать шаблонную фразу, приписать её собеседнику и с ней бороться, но зачем? Где я сказал, что «у них все было идеально». Вот, пожалуйста, скопируйте текст из моих комментариев, где я такое говорю. Жду.
А вот тут уже начинается интересное и по сути. Безусловно, это не значит, что решения верные. Но это также и не значит, что нужно игнорировать чужой опыт, и с пеной у рта доказывать, что «просто плохой менеджер». Это признак некомпетентности. Любой действительно опытный и грамотный руководитель и программист никогда не будет кидаться подобными суждениями. Мне как раз эта статья нравится тем, что автор достаточно аккуратно пишет и о выборе технологий, и не бросается в крайности, а подчеркивает компромиссы и практичность решений. И это создает очень большой контраст с комментаторами на хабре, которые, не имея даже близко такого опыта, знают «как правильно» и у которых все неучи и неумехи.
kazmiruk
Да хотя бы вот эти фразы «Заменяемость решает тем. что, как и описано в статье, можно взять человека почти с любым бекграундом и за недели иметь программиста, способного писать и поддерживать проекты на Go. Гайдлайны не нужны, потому что в Go очень мало способов сделать одно и то же разными способами, он сам по себе гайдлайн.», «как именно нужно было решить проблему сплита и нарастающего эффекта сложности входа в проект с помощью Хорошего Менеджера, причем так, чтобы это было явно лучше перехода на Go». Эти фразы я понимаю таким образом, что не перейдя они с «кривой» scala, все бы пошло прахом, а вот перешли на Go и все шикарно и другого выходы не было. Именно отсюда я и «приписал» Вам слова, просто описав суть в более короткой форме. Про «идеально в организации» — на основе того, что Вы постоянно пытаетесь спросить а есть ли у других такой крутой опыт. Я это понимаю как очень высокую оценку работы тех лида с Вашей стороны.
Что ж Вы сами начинаете оценивать мою компетентность и игнорировать мой опыт, ведь это признак некомпетентности? Мало того, а что я должен делать с этой статьей? Молиться на нее, так как я не управляю 200 программистами? Я ее прочитал пытаясь получить новый опыт и понял, что почерпнуть я с нее ничего не могу, так как в своей команде я такого не допущу (также как и не допустят другие члены команды), так как мы пишем код не для того, чтобы заюзать модную штуку, а чтобы он работал стабильно и делал то, что от него требуется.
Взята из оригинальной статьи. Автор добавил эту приписку на сотни таких же комментариев, недоумевающих как такое можно было допустить в коде проекта. Т.е. по сути они писали говнокод, никак его не контроллировали, все пошло под откос (причем это было при предыдущем тех лиде судя по всему, этот вроде как не виноват. Но он сам же пишет, что на своем предыдущем месте работы также code review не использовался). В итоге приняли решение: перейти на Go и внедрить codereview (утрирую, а то Вы сейчас снова начнете бросаться фразами «где такое написано?!»). Ок, все получилось, все счастливы. Что же нам все таки помогло вылезти из ямы? Code review? Нет, конечно же это было Go ) Да, хороший тех лид, нечего сказать )
Да он вообще никак не пишет о выборе технологии.
То ли его пчела ужалила, то ли он проводил недели бессонные пытаясь понять куда двигаться. Почему Go, почему не хаскел, почему не php, почему не 1С?! Поэтому не надо приписывать автору того, что он не говорил ;)
divan0
Ну как же никак, если вся статья о выборе одной технологии и частичному отказу от другой?
Автор описывал процесс, который уже свершился. Почему вы ожидаете от него табличного сравнения языков — мне не ясно.
Отсутствие системы код-ревью — это не совсем «говнокод». Тем более да, речь шла о компании, в которой он работал до этого. И, насколько я понимаю, spaceship operator — это фича языка. а не говнокод — как тут пытались уже сказать «а-ля вставить unicode-символ в код для диверсии». Это разные вещи.
Кстати, а вы у себя в компании какой системой контроля версий пользуетесь?
kazmiruk
Да вот так. Выбор технологии это как минимум обоснование, а не:
Так это Вы утверждаете, что автор:
я же лишь Вам указал, что ни о каком выборе он не пишет. Лишь констатирует факт без обоснования.
И все таки отсутствие код-ревью в команде, которая пишет в разных стилях это почти диверсия.
Жаль, что вся дискуссия с Вами свелась к необходимости кидать цитаты, так как иначе Вы каждый раз утверждаете, что не говорили этого. В целом я понял Вашу точку зрения и не вижу необходимости переубеждать. Именно поэтому я и употребил термин «сектант Go», а не «программист на Go».
VolCh
Плюс как раз в том, что можно брать человека вообще без опыта в Go и через несколько недель он уже сможет выдавать результаты.
Был выполнен тестовый проект. Наверняка не «Hello, world».
А так про любой язык, на котором реализовали крупный проект, можно сказать «а кто реально работал с * в крупных проектах?»
monah_tuk
Мне вот больше интересно, а вопросов на ревью не возникло по поводу того кода на скала, что вызвал коллективный ступор?
ЗЫ не программист на скала.
ShadowsMind
О чем Вы вообще говорите, о каких еще хороших демонстрациях этой статьи!? Попытки рассуждать и делать выводы, опираясь на мнение какой-то одной компании(к тому же толком никому не известной) не есть хорошо.
По вашему в Twitter, Linkedin и других продуктах написанных на Scala работает 5 человек!? Да и посмотрите на Opensource проекты на Scala(какой там размер и количество контрибьюторов, для примера Spark например чекните) и не набрасывайте больше на вентилятор.
Там даже в комментах к оригиналу правильно люди пишут, что «команда» не удосужились почитать «scala best practices»… Налажали и побежали на новый язык. Мне почему то кажется, что они и когда на Scala переходили не понимали особо зачем им это надо, а просто поддались «тренду».
divan0
Да ну, прислушиваться к опыту других — не есть хорошо? Уверен, если бы статья была о переходе с Go на Scala, вы бы сказали ровно наоборот.
Нет. С чего вы это взяли? Тем более, что автор упоминает, что эти компании столкнулись с теми же проблемами.
Вполне может быть. Но мне кажется, на тот момент, когда они выбирали Scala, это было вполне разумным решением. Но технологии меняются и прогрессируют, так что не вижу никакой проблемы в опыте этой компании.
solver
>Но технологии меняются и прогрессируют
Хм… т.е. Go это прогресс по сравнению со Scala?
creker
Только переход на Go это не прогресс, по крайней мере не в их случае. Это попытка прикрыть реальную проблему — менеджмент. Они начали писать на Scala без явного понимания, как это потом все поддерживать. Дошли до критической массы, когда проблемы уже не подъемные — перешли на Go. Последний никак не решает проблемы, которые есть у этой команды. Он лишь немного помогает в этом контексте, но в конечном итоге все проблемы этой команды приведут к тому, что и Go код они больше не смогут поддерживать. Опять переходить на что-то другое и переписывать с нуля? Или может додумаются, что проблема не в технологиях?
divan0
Странно, а технический директор этой компании считает иначе. И раз уж мы заговорили о вопросах правильного менеджмента, спрошу, а у вас сколько максимальная команда была под вашим управлением?
А что решает? Расскажите.
Да нет, не додумаются. Куда им.
creker
Аргумент «сначала добейся» начинает уже утомлять. Что не пост от вас, то одно и тоже.
Хороший менеджер.
И я так думаю. Поэтому ждем, когда они разочаруются в Go и перейдут на новую модную технологию. Что у нас там на повестке дня?
И после таких комментариев вы еще кого-то упрекается за тон.
mirrr
Тут скорее не аргумент «сначала добейся», а вопрос «какой у тебя опыт в рассматриваемом вопросе?». Нужно же понимать на сколько компетентен твой оппонент.
divan0
Вас обидел вопрос о том, какой опыт у вас в вопрос менеджмента? Забавно.
Причем тут «сначала добейся». Вы говорите о вещах, в которых практический очень важен. Говорите очень уверенно, поэтому резонно предположить, что вы не школьник, флудящий на хабре, а опытных тех. дир, который знает, что говорит, и имел опыт решения подобных организационных проблем методом «хорошего директора».
Ждите, конечно. Тут в комментариях уже целая очередь ожидающих, пообщайтесь )
Я всё-таки попрошу вас не прятаться за фразами «у вас тут одно и то же», а рассказать, как именно нужно было решить проблему сплита и нарастающего эффекта сложности входа в проект с помощью Хорошего Менеджера, причем так, чтобы это было явно лучше перехода на Go. Желательно случай из личной практики, а не «мне так кажется». Спасибо.
kekekeks
Я знаю несколько хипстерокоманд, которые главным образом живут за счёт очередного инвестора, которому втюхали хрень про передовые технологии. И у них почему-то популярны Ruby/Scala/Go, да.
divan0
А какие еще вы знаете команды, которые используют Ruby/Scala/Go и при этом «хипстерокомандами, живущими за счет очередного инвестора» сложно назвать? Назовите, пожалуйста, объективности ради. Если не знаете. я подскажу.
taliban
Там же написали почему ушли, в статье есть четкое перечисление почему они выбрали го, плюшек у го по сути и нет как таковых, у него строгость языка, простота языка, низкий порог входа. Время обучения одного человека и поддержка проекта стоит немалых денег, го (отнюдь не плюшками) в данной ситуации это решил. По сути и питон решил бы тоже их проблемы, возможно, но го быстрей, а им нужна была скорость.
stardust_kid
Не переживайте, в .net некоторые фичи из этих языков тоже появятся, лет через 7-10.
x2bool
C# и .NET сейчас шагают вперед с такой скоростью, какой многие позавидуют. Вы бы хоть уточнили про какие фичи говорите!
kekekeks
Скорее всего про какой-нить паттерн-матчинг и прочую функциональщину. Наличествует в избытке в F# и Nemerle.
creker
И это все есть в списке желанных фич C#.
DoctorChaos
Забавно, что во времена моды на Ruby, здравомыслящие люди точно так же отмечали, что весь этот информационный шум (вроде данной статьи, без обид ;) и восторженные выкрики «Я НАШЕЛ СВОЙ ЯЗЫК!» — не более, чем временное явление, вызванное новизной.
И точно так же, как вы сейчас, адепты отвечали, что никакая это не мода и что серебрянная пуля наконец-то найдена, и что Ruby — это реально ответ на главный вопрос жизни вселенной и всего такого.
Kroid
А она и найдена. Под определенный тип задач руби с рельсами подходит ни чуть не хуже, чем пару лет назад.
divan0
Зачем вы приписываете мне то, чего я не говорил, и даже более — говорил прямо противоположное?
KlonD90
Шум схож повод разный. Люди взрослеют и начинают понимать, что программы пишутся не для «уляля я знаю математику и программирование, а теперь моя программа математически доказуема, не трогай ее своими грязными руками невежда», а для других людей и чем проще она написана тем лучше. Т.е. от функциональности и сверх высокоуровневых абстракций обратно к простому народу. Конечно при этом го оперирует акторами прямо во всю но делает это максимально просто.
divan0
На dotGo'15 у Пайка был доклад как раз на эту тему — о том, как за простотой спрятана большая сложность, и баланс вот этого — что дать народу, а что спрятать под капотом — как раз самое важное и ключевое в дизайне языка.
www.youtube.com/watch?v=rFejpH_tAHM
nwalker
> Features add complexity. We want simplicity.
> Features hurt readability. We want readability.
Пфф. Нет, с Пайком мне не по пути, и в Go я никогда не буду видеть того, что нужно мне. «Simple made Easy» Рича Хикки гораздо сильнее впечатляет.
nwalker
Нет в Go никаких акторов. Модель акторов подразумевает first-class исполнители, обменивающиеся сообщениями адресно.
В Go CSP, где first-class объектами являются каналы, по которым исполнители обмениваются сообщениями.
KlonD90
Хрен морковки слаще? Модель акторов это модель, писать в ее стиле и считать горутины акторами никто не мешает по сути ну и порождать горутины вполне можно и без каналов, каналы примитив для обмена данными между горутинами, да типа основной он, но это никак не мешает модели акторов.
nwalker
Формально, конечно, особой разницы нет, потому что каналы легко выражаются через акторы, а акторы — чуть сложнее через каналы.
Фактически же разные подходы — читай, разные first-class citizens — приводят к разным решениям в итоге, и если сравнивать имеющиеся реализации, акторы все же выразительнее и позволяют иметь из коробки больше.
deniskreshikhin
У хипстеров все стабильно кстати javascript, node.js, coffeescript и т.д.
googol
Народ потихоньку слезает с javascript server-stack на Go.
leMar
Хипстеры, это те люди которые с гордостью носят рубашки и очки в которых ходил мой дед? Тогда бейсик. Ну или PHP, на худой конец.
rg_software
Мир мало меняется: посмотрите на место языков Scala и Go в рейтинге TIOBE. Это все действительно пока что хипстерские развлечения. Можно подумать, что перед наси первая в мире контора, которая выросла до двухсот человек.
divan0
TIOBE — это тот индекс, где считают количество поисковых запросов «LANG programming language»?
Ну да, главные хипстеры вроде Google, Dropbox и SpaceX только балуются. А серьезные гиганты рынка вроде rg software используют только правильные технологии с объективно правильным дизайном, ага.
rg_software
Жаль, что вы не в курсе метода определения рейтинга TIOBE, можете ознакомиться подробнее на досуге.
В любом случае, вы же не думаете, что именно такой гигант рынка как я, вывел все языки первой десятки TIOBE в первую десятку?
В этом рейтинге хорошо то, что его можно проследить хоть на 20 лет назад. Так вот, за последние десять лет в top 10 не изменилось решительно ничего (восемь из десяти языков те же). А если посмотреть на окрестности языков Scala и Go, вообще складывается очень интересная картинка реальной востребованности, моды и тому подобных вещей.
Кстати, если подскажете альтернативный рейтинг, основанный хоть на каких-то данных, буду очень благодарен.
divan0
А чем мое понимание метода TIOBE отличается от описанного? Не считая, пропуска одного слова «результатов поисковых запросов». Проясните?
И как это дает вам право игнорировать объективность и называть монстров рынка хипстерами?
Есть некоторые попытки составить рейтинги по данным с гитхаба — githut.info
Есть занятный рейтинг от RedMonk — redmonk.com/sogrady/2015/07/01/language-rankings-6-15
А так да, задача довольно нетривиальная, но TIOBE довольно часто высмеивается за несерьезность. Тоесть он (как и другие рейтинги) может дать понимание, что C++ популярнее FORTRAN, но для более свежих языков мало что даст. Не говоря уже о том, что зачастую людям нужны не абсолютные цифры (скажем, учитывающие тонные legacy кода), а тренды.
kekekeks
Гитхаб — плохой показатель. Он показывает степень активности в опенсорсе людей, использующих тот или иной язык. Дотнетчики, например, традиционно в опенсорс не лезут и компоненты вместо этого пытаются продать.
divan0
Да, гитхаб только по опен-сорс проектам может дать срез. это очевидно.
rg_software
Хорошо, будем считать, что мы оба понимаем методы TIOBE одинаково. Теперь про объективность. Объективность возможна только путём анализа численных данных. Слова вроде «монстры» или «хипстеры» ни о чём не говорят. Поэтому top 10 — это объективность, даже если методы расчёта рейтинга вам не нравятся. Предложите другой критерий, основанный на числах, а не разговорах.
«Тренды» (если опять обратиться к цифрам) ровно в том, что top 10 за последние десять лет более чем стабилен.
Гитхаб — интересно, хотя я вот им не пользуюсь. «Монстры рынка», кстати, тоже не пользуются (ну, выкладывают, может, чего-нибудь иногда в открытый доступ). RedMonk — тоже интересно, согласен, но всё же и эти ребята зачем-то ограничивают поиск сайтами Github и Stackoverflow. Довольно странно выбранный критерий, ну да их дело.
Я не то что бы сильно критикую, но просто как-то экстравагантно опираться на рейтинги, по сути сводящимися к кастрату TIOBE: те ищут двух десятках сайтах, а эти на двух. Возьмём уж тогда оригинал.
divan0
Так, давайте вернемся к вашему изначальному комментарию. Вы сказали «мир мало меняется», опираясь на рейтинг TIOBE.
Тут я не согласен, так как мир меняется достаточно стремительно — ещё 10 лет не было айфонов и мобильного рынка приложений как класса, не было AWS, не было контейнеров, железо было дороже и медленее и тд и тп. Инструментарий меняется в ответ на меняющийся мир, и мне непонятно, почему так много людей вместо того, что развиваться, инвестировать в себя, изучать новые технологии, сидят на университетских знания и с пеной у рта доказывают, что их язык — единственный и неповторимый, а все остальное не нужно (это я об отдельных комментаторах выше). Вот често не понимаю.
rg_software
Вот для меня все эти айфоны и AWS ничего не меняют, потому что программирование — это процесс мышления прежде всего, а человеческий мозг мало меняется не только за десять, но и за сто лет.
Я же не против развития языков и технологий. Пусть появляются новые средства, скажем, для меня это Python, который я стал осваивать уже в достаточно зрелом возрасте.
Меня расстраивает, что каждый раз нам предлагают старое средство в новой обложке: вот, простота, трудно написать откровенный шлак, обезьяна освоит. Ну что, у человечества память как у золотых рыбок? Ведь и Fortran, и Basic приходили ровно с той же риторикой. И это неплохо, но ничего нового, а главное — не это ключ к хорошему и качественному будущему.
Инвестировать в себя нужно, но вот делать это правильно мало кто хочет. А я бы сказал, что чем выучить десять языков, надо взяться за два и освоить их досконально, вот от корки до корки. Ну как с иностранными языками: да, хорошо, что я могу в кафе и такси объясниться на десяти языках, но всё-таки для реального дела нужны знания совершенно иного масштаба. И в этом смысле мне кажется, что ценен специалист, который полностью владеет своим инструментом. А если владеет, то вопрос инструмента уже глубоко вторичен.
И данная статья тоже описывает печальную реальность. ОК, ребята, вы не знаете, что такое starship operator в Scalaz. Ну а на черта вы тогда в это дело влезли? Пользуйтесь теми инструментами, в которых разбираетесь, ё-моё…
divan0
Вот и напрасно, потому что мышление — это абстракции в мозгу, а не конкретные инструменты, и люди, которые застряют на одном инструменте, остаются неизбежно позади.
Не очень понимаю, почему вас это расстраивает. Так развивалась инженерная мысль с самого начала. Решались задачи, люди искали способ уменьшить «привнесенную сложность», придумывали новое, внедряли, реагировали на новые проблемы и сложности, которые появились взамен, искали или улучшали способы и так далее. В купе с тем, как меняется мир, этот процесс достаточно естественный и интересный.
Сейчас эпоха облаков, других скоростей разработки и аггрегированного опыта уже нескольких поколений программистов. Будет неверно считать, что ничего не меняется и не должно меняться. Сейчас важно уметь уже не биты ксорить, а строить распределенные системы, и понимать отличие CP от AP. Или, к примеру, еще 15 лет нормального тестирования не было в принципе ни в одной компании, а сейчас уже язык без встроенного тулинга для тестов считается неполноценным.
Реальность такова как есть, печальность привносите вы :)
DoctorChaos
<удалено>
rg_software
Вот я как раз печальность не привношу — я именно за то, чтобы люди пользовались инструментами, которыми хорошо владеют. Тогда и печали не будет. Знаете, в учебниках любили анализировать, какого рода ошибки программисты совершают чаще всего. Вот такое впечатление, что современный мир — это не про облака и другие скорости разработки, а про некомпетентность. Если почитать чужой код (приходится...), то оказывается, что 90% ошибок — это не классические ошибки логики или ошибки по невнимательности, а банальное незнание азов собственного инструментария.
Так что какие уж тут скорости разработки, право слово. Быстро разрабатываем, потом ещё неделю разгребаем тот ужас, что люди понаписали.
taliban
Если бы все было как вы хотите, то сидели бы все на асемблере или с, ибо «люди пользовались инструментами, которыми хорошо владеют» зачем учить что-то новое, если я итак хорошо владею этим. И вообще я рад что вы ошибаетесь практически на всей ветке :) Консерваторы хороши лишь на больших проектах, и после окончания таких проектов они должны всю жизнь поддерживать их, а молодым путь в новые сферы.
rg_software
Почему вы думаете, что я ошибаюсь? По крайней мере, я пытаюсь хоть как-то обосновывать свою логику, а не просто раздавать эпитеты.
.
Про «людей, сидящих на ассемблере» вы хватили уж совсем далеко — Фортран уже в пятидесятых годах существовал.
Разговоры про «консерваторов» и «молодых» — это вообще та ещё глупость. Нам постоянно ведь говорят, что инструмент это всего лишь инструмент, и не надо делать из него религии. Ну так давайте же и не делать, почему люди не хотят следовать своим рецептам?
Вот представьте, что я владею инструментом Х, и рассчитываю, что могу написать на нём некий проект за десять месяцев. Теперь вот есть новый инструмент Y, на освоение которого уйдёт год (будем реалистами, это крайне оптимистичная оценка), но затем я смогу справиться уже не за десять месяцев, а за восемь за счёт более высокой продуктивности (не надо предлагать мне увеличить продуктивность вдвое, это будет откровенное враньё).
Сколько проектов мне нужно закончить, чтобы получить выгоду от нового знания? Это не консерватизм, это абсолютно рациональное поведение. А если человек ещё ничего не умеет, и выбирает первую/вторую/третью для себя технологию, то ему тоже надо руководствоваться не какими-то абстрактно высокими соображениями, а мыслями о том, какая технология его сможет прокормить.
Пусть это будет что угодно, хоть Smalltalk, лишь бы он видел для себя будущее в этой области.
VolCh
Это рациональный консерватизм — пессимистичные оценки затрат ресурсов и выгоды от них.
rg_software
Да ради бога, если мне предоставят другие оценки, я за них радостно ухвачусь. Любой из нас хочет работать эффективнее и не тратить часы на ерунду. Некоторые вещи самоочевидны (визуальный html редактор против ручного написания html тегов в тексте), но вот с языками программирования далеко не всё так просто.
Как писал Брукс, если бы хоть один язык давал гарантированно 5% прироста производительности по сравнению с конкурентами, все бы уже на нём сидели.
Xu4
Я согласен с основной вашей мыслью, что нужно быть профессионалом хоть в чём-то, а не просто прыгать с цветочка на цветочек. Но я так же согласен и с тем, что оценки нужно делать не опираясь на оптимизм или пессимизм.
Здесь очень много лукавства. Блокнот можно изучить за пару минут. А, например, если действительно интересен Python, то можно уже через пару месяцев изучения что-нибудь вроде этого писать (я этот код написал примерно через полтора месяца после того, как начал учить Python):
rg_software
Хорошо, давайте тогда поговорим о технологии, которая называется «язык программирования общего назначения». Я настаиваю, что быстрее, чем за год нельзя освоить ни один новый язык программирования общего назначения на более-менее профессиональном уровне. Чтобы просто писать не задумываясь, а не нырять в справочник каждые пять минут.
То, что приведённый код на Питоне можно накатать через два месяца обучения — верю легко, но меня интересует именно профессиональная разработка ПО, а не упражнения в однострочниках.
Xu4
У вас есть какие-то фактические выкладки? Если нет, мы можем провести эксперимент, но я попрошу оплатить моё время. Это примерно 96 тысяч долларов.
rg_software
Я не думаю, что этот эксперимент поможет, потому что в лучшем случае это докажет исключительно вашу личную способность к такому скоростному обучению.
А какого рода выкладки вас могут устроить хотя бы в теории? Желательно, чтобы они не требовали нереальных денег и ресурсов с моей стороны.
Xu4
Для примера, носитель английского активно использует около 40 000 слов в речи. Я понимаю под носителем того, для кого он является родным (и такой человек, получается, является, в некотором роде, профессионалом в своём языке). По данным languagemonitor на 1 января 2014-го в английском языке было больше миллиона слов. Получается, что для профессионализма нужно обладать словарным запасом примерно в 4 процента от общего количества слов.
По аналогии с этим, можно взять количество слов в языке программирования (включая сюда названия функций и классов стандартной библиотеки), выкинуть операторы (так как они являются знаками препинания) и выбрать 4% самых используемых (например, воспользовавшись данными из API Github в качестве отправной точки). Получится количество слов, которое нужно изучить для того, чтобы не лазать постоянно в
словарьдокументацию, когда пишешь на этом языке.Далее, по непроверенным данным, человек, изучая английский, может запоминать до 5-10 слов в день. Если распространить это на изучение языка программирования, то эти 4% слов нужно будет разделить на 5 и мы получим количество дней, нужное для запоминания профессионального словарного запаса.
Вот, примерно так я бы оформлял мысли, когда мне нужно было бы на чём-то настаивать.
lair
В этом месте у вас ошибка. Между носителем языка и профессионалом в его (языка) употреблении гигантская пропасть, хорошо видная по существованию таких профессий как «редактор» и «корректор».
И снова, аналогия неверна. В естественных языках гигантская избыточность (именно поэтому так мало отношение активного вокабуляра к общему корпусу), а в языках программирования она меньше на порядки (и отличается в зависимости от языка), поэтому выбирать вам придется не единицы процентов, а десятки.
Вы, конечно же, знаете, что помимо словарного запаса есть еще грамматика (управление), словоупотребление, идиомы, стилистика и еще много мелочей, которые отличают человека, знающего язык, от человека, который выучил словарь? Ровно то же самое и с языками программирования.
Для изучения (естественного) языка нужна практика. Много практики. Причем практики, ориентированной на тот род деятельности, который ожидается (в IELTS, скажем, четыре разных экзамена — Listening, Speaking, Reading, Writing). Ровно то же самое возникает при изучении языка программирования: одно дело научиться его читать, другое дело — научиться его писать (кстати, навык письма еще не подразумевает навыка чтения, как ни странно). Как вы собираетесь оценивать необходимые для этого часы?
PS С одной стороны, приравнивать операторы к знакам препинания неверно, потому что в языках программирования операторы имеют существенно большее значение, нежели знаки препинания в языках естественных. А с другой стороны, не надо выкидывать знаки препинания из естественных языков, если вы не хотите однажды быть застреленным пандой.
Xu4
Но, всё же, этот человек разговаривает на более или менее профессиональном уровне, ведь ему не приходится каждые пять минут заглядывать в словарь. Это очень важный момент, так как я эти формулироваки использовал из-за отдельных фраз в предыдущих комментариях. Просто мне хотелось бы обратить ваше внимание, что такие формулировки изначально не у меня появились — я просто их принял.
Вы логично всё описываете, но я, в общем-то показывал, как можно перейти от выражения «быстрее, чем за год нельзя освоить ни один новый язык программирования общего назначения на более-менее профессиональном уровне» к выражению «новый язык программирования можно изучить примерно за X дней» — в этом выражении немного больше фактов, чем в первом. И его можно уточнять в деталях, получая более точный вариант в итоге. Я не давал точные цифры — просто ход мыслей, который позволяет хоть какую-то привязку сделать.
lair
Нет. Вы путаете «профессионально» и «без словаря». Это совершенно разные вещи (для естественного языка). Впрочем, для языка программирования — тоже: знание документации еще не достаточно для того, чтобы профессионально программировать (более того, и не необходимо).
К сожалению, ваш ход мысли ошибочен почти во всех своих пунктах. Правильный, на мой взгляд, ход мысли здесь называется «программа курса», благо ровно для этого они и придуманы — дать организации предсказуемые сроки и результаты.
Впрочем, есть и более простой подход: «правило» десяти тысяч часов.
Xu4
Вы не совсем поняли мою мысль. Я вам процитирую того человека, который это определение ввёл.
Я, как я выше написал, просто принял такую формулировку, чтобы не скатываться в тысячу постов с выяснением истинности каждого слова.
Согласен, программа курса позволяет дать привязку точнее. :)
lair
Эта формулировка неверна ни для естественного языка, ни для языка программирования. Как следствие, принимать ее за основу бессмысленно.
Xu4
Я думаю оригинальный автор этой формулировки вас обязательно прочитает, несмотря на то, что вы в неё кунаете меня.
lair
Я, как вы выражаетесь, «кунаю» вас в то, что вы выбрали неправильную постановку, добавили к ней неверную аналогию, но почему-то считаете, что результаты этого все еще применимы для оценки.
rg_software
Я думал, мне не придётся пояснять, что программист — это не тот, кто без проблем читает код, но и тот, кто пишет. Обычному носителю языка редко приходится сочинять даже на родном языке более-менее внятные тексты. А программисту приходится, что подразумевает активное владение, а не пассивное, что требует совсем иных усилий.
Если требуется только читать и комментировать код — да какие проблемы, я так с десяток языков знаю весьма неплохо. Но на профессиональном активном уровне всё куда скромнее.
rg_software
К сожалению, ваши выкладки относительно естественного языка уже неверны: помимо активного запаса вам абсолютно необходим пассивный запас, который, по крайней мере, на порядок выше. Вряд ли вы активно используете слова вроде гнедая или форзац, однако представляете себе значения этих слов. Кроме того, помимо слов важны сочетания: важно понимать, что «морская свинка» и «свинка» — это совершенно разные вещи, никак не связанные между собой, а количество сочетаний уж совсем несравнимо с количеством слов. Таким же образом абсолютно неверно сводить изучение языка к изучению словаря.
Кстати, для естественных языков подобные выкладки имеются. Например, чтобы изучить английский на уровне C2 (а это по сути и есть профессиональное использование), потребуется 700-800 часов обучения с учителем, можете попробовать прикинуть, сколько лет жизни это в реалистичных условиях (ну и понятно, что 16 часов в день учиться бессмысленно, организм столько не вынесет).
Так что если бы я и в самом деле взялся за выкладки, то подошёл бы с другого конца: берём приличный учебник по языку (из списка рекомендованных в каком-нибудь достойном вузе), заставляем человека выполнить хотя бы 3/4 домашних заданий, затем написать хотя бы один полноценный проект (не слишком большой, но полноценный). Вот это мне кажется больше похоже на правду.
Xu4
Если укладывать 800 часов в год, то получится примерно 14 часов в неделю — два часа в день. Если делать перерыв в выходные — три часа в день пять дней в неделю.
Выглядит как лёгкая прогулка. К тому же, вы в этой цифре учли всё: и основы языка и построение предложений и т.п.
lair
Только выглядит.
Впрочем, что важнее, это 800 (1200) часов занятий с учителем. «Принято считать», что для того, чтобы это было эффективно, нужно еще два раза по столько (или хотя бы столько же) самостоятельных занятий.
Год фулл-тайм. Если выдержите (на самом деле, если вспомните обучение в ВУЗе — поймете, что не выдержите).
Xu4
Я всё так же считаю, что 800 часов в год — это примерно 14 часов в неделю — два часа в день. Выглядит лёгкой прогулкой. Если судить по моему опыту (по таймшитам у меня в этом году чуть меньше 400 часов обучения) это вообще не напряжно. Даже если бы время возросло в два раза — до пресловутых 800 часов, вряд ли бы это стало чем-то больше, чем лёгкая прогулка.
Согласен с вашими выводами, что фулл-тайм учёба — это тяжело. Понимаю, почему вы выделяете выражение «принято считать» в кавычки — я похожее соотношение только в информации об американских колледжах видел, и то только в ситуации с лекционными занятиями. Лабораторные занятия домашней работой не сопровождаются.
Если же брать ситуацию с ВУЗом, в Министерстве образования пишут, что соотношение должно быть 70% (с преподавателем) к 30% (самостоятельные занятия). Если ваши 1200 часов применить к российской системе образования, то получится 1560 часов. Либо это будет фулл-тайм в течение 9-ти месяцев, либо год с загрузкой 5-6 часов в день. Не год фулл-тайма.
А если перейти к реалиям — ближе к ситуации, о которой шла речь с самого начала (когда человеку, знающему язык программирования X, нужно выучить язык Y), не вижу ни одной причины тратить тысячу часов на занятия с учителем. Чему учитель будет учить человека, который и так программирует? Впустую ему читать лекции по программированию? Он и так умеет. Ему просто нужно новый синтаксис выучить и набор слов, чтобы не лазать в документацию — всё. У меня подобное заняло примерно 3 месяца, когда я учил Python. Сделаем скидку на мою «гениальность» и увеличим срок в два раза — шесть месяцев на изучение нового языка. Вы хотя бы раз учили новый язык программирования (не программирование с нуля, а новый язык программирования — в дополнение к уже изученным)? Вам требовался год на это? Вам требовался учитель, который вам 1200 часов выдержки из документации декламировал или вас морально поддерживал, типа: «ну, не пугайся, давай, допиши ещё ввод из STDIN»?
rg_software
По правде говоря, я вот сейчас наступлю на горло собственной песне, но вот эти цифры «800 часов» мне самому кажутся слишком оптимистичными. Посмотрите, сколько лет мы учим родной язык в школе, и всё равно когда дело доходит до сочинения даже простеньких текстов, у людей уже возникают проблемы.
Сам я имел опыт изучения финского языка на групповых курсах в похожем интенсивном режиме: 4 часа в день плюс домашние задания пять дней в неделю. Это было очень утомительно, и по факту (это уже не личный опыт, а более-менее объективная статистика) считалось хорошим результатом за три семестра человека натаскать на средний уровень государственного экзамена (а это вовсе не уровень C2, а гораздо слабее).
Впрочем, мы и в представлении о компьютерных языках расходимся: «Ему просто нужно новый синтаксис выучить и набор слов, чтобы не лазать в документацию» — ну и какой смысл тогда в изучении нового языка? Это же получается по старому выражению о том, что программу в стиле Фортрана можно написать на любом языке. Ясное дело, если вы учите старый язык в новой обложке, и трёх месяцев хватит. Суть же в том, чтобы на спинномозговом уровне освоить новый принцип написания программ, а пока он не освоен, то смысла в этом образовании мало — работайте тогда со старым языком, всё равно удобнее.
Xu4
Вообще, C2 — это 1200 часов, а не 800 (это для C1 нужно столько часов). Я просто не стал поправлять чуть раньше, чтобы не отвлекаться.
Я думаю, человек, которому не хочется учить новый язык программирования или технологию, найдёт тысячу причин, которые подтвердят, что это очень сложно, очень долго и по временным затратам не оправданно. Я тоже так делаю.
В любом случае, для меня этот разговор был очень полезным. Спасибо. :)
rg_software
Спасибо и вам :)
Ну с одной стороны да, тысяча причин, с другой стороны как объективно оценить, стоит оно того или нет? Я ведь по сути поднимаю эту дискуссию, но стопроцентно обоснованных ответов у меня нет.
Если бы были готовые ответы — занимает столько-то времени, сэкономит столько-то. А так одно гадание получается.
lair
(Я боюсь, что наше основное разногласие — в критериях профессионального владения)
Завидую. У меня учебная нагрузка за последний год была меньше, а сил на нее ушло больше.
Это верно не для всех предметов (особенно учитывая, что то, куда вы ссылаетесь — это не рекомендация и не норматив, а просто объяснение, что такое «очная форма») и не для всех форм обучения.
А вы не задумывались о том, что «мои» (на самом деле — кембриджские) 1200 часов расчитаны на конкретную систему образования?
То есть вы считаете, что языки друг от друга отличаются только синтаксисом?
Учил. Но ни одним из тех, которые я учил за последние пару лет, я не владею профессионально.
Год нужен не на это. Год нужен на то, чтобы набрать опыта с разнородными задачами.
Xu4
Я думаю, вы просто в какой-то момент по инерции начали думать, что я называю профессиональным владением ситуацию, когда человек не лазает в документацию. Я повторюсь, иногда я считаю, что можно не придираться к словам человека, чтобы перейти к сути и не плодить слишком много текста. У каждого человека своё видение того, что значит профессионализм. На тот момент, я услышал, что одним из граничных условий является: «на более-менее профессиональном уровне. Чтобы просто писать не задумываясь, а не нырять в справочник каждые пять минут». У меня эта фраза не вызывает достаточно отторжения, чтобы тыкать человека в его ошибки. Зато она добавляет конкретики, на которую можно опираться. В противном случае, мы с ним ещё пару дней бы спорили, что такое «профессиональное владение» — и это была бы пустая трата времени. Это не позволило бы сразу взять и начать что-то оценивать.
Языки программирования отличаются синтаксисом и словами, которые в них есть. Остальные различия — в прокладке между стулом и монитором. Опытная прокладка найдёт тысячу способов сделать код лучше, используя особенности синтаксиса и подбирая правильные слова. К этому вполне можно всё свести. С другой стороны, можно усложнять любые явления до бесконечности, вводя дополнительные абстракции вроде pythonic way и т.п. — хотя это всё, опять же, является свойствами программиста, а не языка программирования. Сами подумайте, вы понимаете, что программа написана на конкретном языке программирования, когда видите её исходный код — синтаксис и слова. Какие ещё нужны признаки, чтобы отличить один язык от другого?
lair
Идиомы, очевидно.
lair
Тематический (к посту) пример:
Go-way:
Возьмем другой язык. Вот так будет, если просто «заменить синтаксис и слова»:
А вот так — если писать идиоматично:
И вот такие вещи и вырабатываются опытом и обучением.
Xu4
Этот код будет работать в обоих ваших языках?
lair
Конечно, нет.
Xu4
А почему? Потому что синтаксис не подходит — отличается — да?
lair
Отличающийся синтаксис — это только следствие. Он и в первом примере отличается, просто результирующее поведение более-менее одно и то же, поэтому можно сделать «дословный перевод». А реальное отличие состоит в том, что в первом языке просто нет таких концептуальных сущностей и механизмов, которые позволяли бы сделать (семантически) то же самое.
Xu4
Отличающийся синтаксис — это факт, который помогает понять, что язык отличается. А остальные вещи уже характеризуют программиста, который писал этот код.
lair
Ну уж нет. Каждому (по крайней мере, хорошему) языку присущи концептуальные решения, абстракции, идиомы и много других хороших (и плохих) вещей, которые, собственно, и определяют его смысл и ценность. Синтаксис — это только их следствие.
Собственно (и вам это уже написали), программиста, который берет от языка синтаксис, но игнорирует его семантику, нельзя считать владеющим этим языком на профессиональным уровне.
Xu4
А я это отрицал где-нибудь? Я пишу про то, что языки можно различать про синтаксису и словам, которые в него входят, а вы утверждаете, что программиста, который берет от языка синтаксис, но игнорирует его семантику, нельзя считать владеющим этим языком на профессиональным уровне.
Вам не кажется, что я говорю про цвет помидоров, а вы про расстояние между точками А и Б? Я вам доказываю, что он красный, а вы мне противоречите и говорите, что вы суперточной рулеткой замеряли расстояние, и оно равно 10 метров, поэтому помидор не красный.
Хотя, вполне может быть, что именно я замеряю расстояние и делаю выводы о цвете на этом основании. Вы не напомните, о чём мы вообще спорим?
lair
Мы спорим о том, за сколько можно выучить язык на профессиональном уровне. В данную точку дискуссии мы пришли через промежуточный пойнт «для того, чтобы выучить язык, недостаточно выучить ключевые слова и синтаксис».
Собственно, это следствие того, что из моего вопроса «вы считаете, что языки отличаются только синтаксисом» вы сделали вопрос «как отличать языки», хотя это далеко не одно и то же.
(кстати, хорошая иллюстрация к тезису о владении естественным языком и о словарях)
Xu4
Это ваш вопрос был? Я на него ответил. Вы ведь про язык спрашивали, а не про программиста.
А на вашу ремарку про уровень профессиональным владением я ответил, что споры на эту тему — пустая трата времени. Я так считаю, потому что это тема, которую нельзя измерить — это набор субъективных характеристик, а не объективных. Может я как-то неубедительно это говорил, из-за чего показалось, что я только для вида это прямым текстом говорю, а сам провоцирую на разговоры об анализе профессионализма? Если вы мне на такие провокации укажете, мне это очень поможет, так как я смогу в будущем формулировать мысли точнее — чтобы в них было меньше поводов для того, чтобы съезжать на другие темы.
Про профессионализм, я считаю, что для владения языком нужно знать его синтаксис и слова. И всё это — 1% от знаний и навыков, которые делают профессионалом. Остальные знания и навыки лежат в других предметных областях.
lair
… и если этот ответ «да», то я не могу с ним согласиться. Языки можно (иногда) отличать по синтаксису, но отличаются они не только синтаксисом.
Я не видел этого вашего ответа.
Xu4
Вот здесь я про это писал. Дополнительно, я это ещё раз процитирую.
Xu4
Они отличаются в своей полезности многими параметрами, но понимать, что вот здесь один язык, а там — другой, можно по синтаксису и по использованным словам. Всё дело в формулировках. Вы выбрали такую формулировку вопроса — мой ответ в неё хорошо укладывается.
lair
В моей формулировке вопроса явно сказано «чем языки отличаются». А вы отвечаете на вопрос «как их можно отличить». Это разные вещи.
Xu4
Тогда, если уж мы про формулировки говорим, то вы спрашивали только про синтаксис, а я сказал, что это синтаксис и слова. То есть, к простому «да», мой ответ тоже нельзя свести. Логично ведь?
lair
Может быть, логично, но бессмысленно. «Синтаксис и слова» все равно меньше, чем концепции.
Xu4
Можно обратиться к тому, как работает интерпретатор языка, чтобы понять, что остальные признаки — это результат восприятия конкретного человека, а не объективный признак языка. Всякие идиомы в первую очередь должны быть синтаксически верны. Интерпретатор делает синтаксический анализ. Была идиома или нет — интерпретатор выдаст ошибку, если синтаксис неправильный, или если встречается некорректное для этого языка слово.
lair
Мне не интересны «объективные признаки языка». Язык — это концепция, которая только потом находит выражение в грамматике.
Xu4
А мне интересны объективные признаки, а не субъективные. Какой нам тогда смысл вообще спорить, если я про цвет говорю, а вы — про расстояния? Он же ни к чему не приведёт — только к раздажению.
lair
Объективные признаки в человеческой индустрии? Очень мило, но не выйдет. Они, конечно, есть, но для формализации конкретной решаемой задачи их не хватит.
Xu4
И это ваше личное мнение, которое я уважаю, хотя и не принимаю. Я благодарен, если вы мне его не навязываете.
VolCh
На каком языке написан этот код:
? Какие объективные критерии вы использовали?
Xu4
На JavaScript. А на PHP он интерпретироваться не будет — потому что код на PHP должен содержать <?php перед кодом по синтаксису. Если это добавить явно, это уже будет ошибкой при интерпретации на JavaScript. То есть, условие про одинаковый текст, который работает в обоих интерпретаторах, не выполняется.
VolCh
А кто сказал, что это полный текст файла?
Xu4
Это читерство, я считаю. Потому что, например, знак «=» может использоваться в большинстве языков программирования. Если я вас попрошу угадать, что делает этот код:
=, что вы скажете? Присваивает что-нибудь? А я вам отвечу после вашего ответа: «а с чего вы взяли, ведь он являлся частью конструкции ==».VolCh
Это достаточно длинный код, синтаксически корректный минимум для двух языков. Требование «должен содержать <?php» относится не к коду на PHP, а к одному из способов его передачи транслятору. Для других способов директива <?php не требуется. Например,
Xu4
А у вас нет, кстати, какого-нибудь примера, который покажет, что по синтаксису и словам нельзя определить, что это конкретный язык, а по другим признакам можно? Просто посмотреть на код и с уверенностью утверждать, что это код на каком-то конкретном языке, но не из-за синтаксиса и слов, а из-за других признаков.
Я согласен, что конструкция for, которую вы приводили, может работать и в PHP и в JS. Но вы сами сможете её отнести к конкретному языку, руководствуясь какими-то ещё признаками, которые выходят за рамки моих утверждений про синтаксис и слова?
Вы ведь это мне хотите показать — то, что я заблуждаюсь про только синтаксисическо-словесную разницу для определения принадлежности?
poxu
С этой конструкцией, сложнее, а если воткнуть в цикл перебор элементов массива, то в javascript это будет работать быстрее, чем в php.
VolCh
Вот этот пример кода с большей вероятностью написан на PHP, чем на JS. Во-первых, переменные начинаются с $, что для JS нетипично (кроме переменных только из $-ов), во-вторых, написал его я ))
Именно. Код может быть синтаксически корректным для нескольких языков, но его истинную принадлежность выдаёт стиль, используемые парадигмы, паттерны и т. п. Причём истинная принадлежность необязательно совпадает с языком, на котором этот код писался. Грубо говоря, в продакшене может выдаваться в браузер посетителя JS-код, но на самом деле это код PHP, даже если для PHP он не совсем синтаксически корректный.
Xu4
Вот видите, вы употреблятете выражения «с большей вероятностью», «нетипично», «необязательно», «может». Они выдают предположение об истинной принадлежности, но не истинную принадлежность, доказанную объективными признаками. С их помощью нельзя точно сказать, что вот этот код написан на языке А, а этот — на языке Б. Но с помощью синтаксиса и слов языка — можно.
Если код на языке А синтаксически корректен, то никто не сможет оспорить, что этот код истинно является кодом на языке А — он работает. Даже если он написан с использованием каких-то стилей, паттернов и парадигм языка Б, невозможно оспорить, что он имеет право быть кодом на языке А. И кодом на языке Б он не станет только из-за того, что в нём используются парадигмы и стили из языка Б. Он им станет только если его синтаксис корректен для языка Б. Субъективные признаки дадут возможность сделать предположение о том, что код с определённой вероятностью принадлежит к языку Б. Но если по синтаксису этот код не является Б, он им не станет, даже если субъективных признаков будет миллион, а в каждом блоке комментариев в коде будет пометка, что это код на языке Б.
VolCh
Я вам привёл простейший пример, что нельзя. А ведь есть языки, синтаксис которых настраивается «на лету», которые после определенного «прогрева» могут понимать любой синтаксис.
А если работает не так, как задумывалось, то всё равно работает?
Не путайте «код» и «синтаксический корректный код». Если я в коде на PHP допущу синтаксическую ошибку (возможно как раз делающую его корректным кодом для JavaScript, например, вместо -> поставлю .), то это всё равно будет код на PHP. Синтаксически некорректный, но код на PHP.
Xu4
Вы привели простейший пример того, что, по вашему мнению, истинную принадлежность выдаёт стиль, используемые парадигмы, паттерны и т. п. По моему мнению, это необъективные признаки. Для меня пример выглядит некорректным, потому что в его сути лежат субъективные явления.
Ну да. Никто ведь ведь не в курсе, какие задумки были у прокладки между клавиатурой и стулом. Можно авторитено заявить, что это язык А, потому что у него корректный синтаксис для этого языка. Если синтаксис верен, то можно уверенно говорить, что это язык А. Если синтаксис неверен, никакие другие субъективные признаки не дадут 100%-й уверенности, что это код на языке А. Это может быть «вероятно, код на А» или «скорее всего, код на А», или «с очень большой вероятностью, код на А», но не определённо точно код на языке А.
Вот для примера:
Объективно, это код на PHP. Из комментариев понятно, что нужно сварить щи, но код этого не делает. И, если ещё подумать, он работает не так, как задумывалось, потому что восклицательные знаки не выводятся. Он от этого разве перестанет быть кодом на PHP?
Ну да, будет считаться кодом на PHP. Просто будет ругаться на что-нибудь вроде «Object of class XXX could not be converted to string» (если не существует XXX::__toString()). Это не синтаксическая ошибка. Это оператор конкатенации (в ваших обстоятельствах, во всяком случае, когда вы поменяли «->» на точку), который является частью синтаксиса PHP. В то же самое время, он будет считаться кодом на JavaScript.
Мне, вам, кому-то ещё третьему-четвёртому-пятому можно считать этот код только кодом на PHP и говорить, что это стопроцентно не код на JavaScript, если это нужно. Но это субъективное мнение, которое объективным признаком не может стать.
Вот, например:
Я считаю это кодом на JavaScript. Оппонент считает это кодом на PHP. И оба мы правы, потому что нет объективных признаков, чтобы стопроцентно отнести этот код к одному языку. Но мы можем спорить, что $ — признак PHP, или что в JS нет trim (я на это отвечу то же самое, что вы мне сказали чуть раньше). И всё равно мы оба останемся правы, потому что со стопроцентной уверенностью можно будет сказать что-то о принадлежности к конкретному языку только после того, как из объективных признаков это станет точно известно. Нетипичность использования $ в JS и то, что оппонент лично код написал на PHP — это субъективные признаки. Он может через несколько минут передумать и сказать, что писал на самом деле на JS — и этот аргумент будет таким же субъективным как и тот, где говорилось про PHP — и это не добавит ровным счётом ничего к объективным оценкам (не убавит тоже, кстати).
* * *
Если совсем хорошо подумать, то синтаксис, за который я так упорно цепляюсь, тоже не может быть объективным признаком, потому что можно интерпретатору PHP скормить «Войну и мир» под видом программного кода. Он выдаст ошибки, но это будут ошибки PHP. Их можно будет просто поправить, и всё заработает — «Война и мир» с самого начала была кодом на PHP, просто с ошибками была написана.
И раз синтаксис становится субъективным, то у него такое же право влиять на принадлежность к языку, как и у стилей, используемых парадигм, паттернов и т.п. Единственный объективный признак — контекст исполнения (пока не доказано обратное). :)
Xu4
У меня один знакомый, кстати, часто использует $ в имени переменных на JS. Для него это типично. Я не понимаю до конца, чем он руководствуется при этом, потому что переменные без доллара он тоже использует рядом, но, в общем-то, его код работает нормально и ошибок не выдаёт.
webkumo
Обычно это делается для различения переменных обёрнутых jQuery и не обёрнутых.
Xu4
Я это всё веду к тому, что я критерии различия указываю, и объясняю, почему они помогают различать вещи. Но меня оспаривают тем, что есть куча других критериев, и не объясняют, как именно они помогают различать вещи.
Ситуация, когда один и тот же код работает в нескольких интерпретаторах, мои слова не опровергает, потому что в то же самое время не находится каких-то других критериев, которые гарантированно покажут различие.
Я не утверждаю, что любой вообще код можно различить, опираясь на синтаксис и слова, ведь существует код, который может работать и там и там. Я говорю про то, что не требуется дополнительных критериев, чтобы оценивать принадлежность. И если в коде используются идиомы, характерные для языка A, но он работает в языке Б, у него одинаковое право быть кодом как на языке A, так и на языке Б. Но если будет различаться синтаксис, то у него не будет возможности быть одновременно кодом на языке А и на языке Б.
Xu4
Я надеюсь, наличие <?php — это объективный критерий? Ведь это часть синтаксиса.
Xu4
Согласен, что не объективный — из-за этого примера:
Без него тоже можно интерпретировать код как PHP.
poxu
Как быть со случаями, когда один и тот же текст будет синтаксически корректным для двух разных интерпретаторов, но выдаст совершенно разные результаты?
Xu4
Например?
VolCh
Есть, как минимум, частично совместимые языки, например, С и C++ или PHP и JS, когда как минимум подмножество синтаксически корректного кода, а то и весь код на одном является и синтаксически корректным кодом на другом. Семантика же при этом может отличаться, например в нюансах типа наличия автоматической сборки мусора или других правил приведения типов.
Xu4
Знание точных наук, алгоритмическое мышление, способности к математике и анализу. И прочее, и прочеее, и прочее. И куча всего остального, не относящегося к конкретному языку программирования вообще. Вот, это моё мнение про профессионализм. Оно может быть неправильным, но я не буду спорить об этом.
rg_software
> видите её исходный код — синтаксис и слова
Я уже написал в другом месте, но мысль важная, поэтому повторю.
За любым языком стоит некая «новая философия», в противном случае непонятно, ради чего данный язык создавался. Неужели тысяч уже существующих языков мало?
Соответственно, профессиональное владение — это, разумеется, владение именно философией и идиоматикой данного языка. Причём именно на уровне письма. Если ей не владеть, то нет никакого смысла заморачиваться с его изучением. Для меня эти вещи самоочевидны, поэтому я их просто пропускал в диалоге.
Допустим, некто с опытом C «знает» также C++, но никогда не использует ключевое слово private, хотя и знает, что оно означает. По моему определению («пользоваться без словаря»), он, конечно, «владеет», но профессиональным владением назвать это никак нельзя.
Человек должен без запинки выдавать код, соответствующий идеологии используемого языка, иначе это просто профанация какая-то.
webkumo
«Это не позволило бы сразу взять и начать что-то оценивать.»
Лучше всё-таки для начала сойтись в определениях… Ну чтобы не делать никому не нужную работу
Родственные (синтаксически языки): java, c, c++ — вот так взять и перейти с одного языка на другой… да на профессиональном уровне… имхо побольше года понадобится:
— отвыкнуть от старого синтаксиса (и не лепить его автоматом),
— принять language way (аннотации+генерики/макросы+шаблоны функций, и многое другое),
— изучить систему фреймворков в нужной области деятельности
и это я далеко не все нюансы перечислил.
Т.е. переходя с одного языка на другой, ты в лучшем случае теряешь условную ступеньку — был сеньором — станешь мидлом, был мидлом — станешь джуном. Условно, но близко к этому. А потом уже за год-два практики ты вернёшь старую ступень.
vladon
Самое интересное, что хипстерам очень нравится Rust, он становится модным. И это — наконец-то — что-то хорошее среди «хипстерского».
grossws
Хипстерам он, к счастью, будет тяжеловат.
А в области embedded он может оказаться вполне интересен.
schroeder
А где про Катю? Про Катю где, я вас спрашиваю!?
divan0
Про Катю в другой статье.
namespace
Ваня, если хочешь завлекать людей в свой клуб, то нужно меняться. С недавних пор статьи про Go без Кати просто не читают…
leMar
Можно раскрыть тайну, про что шутка? Про танцовщицу?
Starche
Часть 1 habrahabr.ru/company/dcoin/blog/272695
Часть 2 habrahabr.ru/post/273333
PHmaster
Спасибо, мил человек, нагуглил и прочитал обе статьи про Катю. Теперь хотя бы в курсе последних тенденций в Go-тусовке. Буду ждать продолжения.
P.S. Обновились комменты — а тут уже люди и ссылки выложили, так что кому-то и гуглить не придется.
mannaro
Вызываю c-darwin
evnuh
Суть статьи
Функциональщина плохо читаема, у нас в команде каждый писал как хотел, мы нанимали новичков без опыта, которых приходилось обучать, перешли на Go, т.к. у него более С-подобный синтаксис и вообще он сам код форматирует и компилирует всё в один файл, ваааау, нашим новичкам понравилось, мы теперь тоже можем не умничать и 2+2 писать как 2+2.
divan0
Непонятно, почему каждый Go-хейтер отличается таким неуважением к чужому опыту и мнению. Ещё более непонятно, почему считает необходимым это своё неуважение написать на в комментариях на хабре.
evnuh
Я пересказал суть статьи, указав на проблемы, которые были у автора. С чем конкретно вы не согласны? С тем, что у них не было стандартов написания кода? Если бы они были, тогда бы 3 человека не стояли над кодом четвёртого и не пытались бы разобраться, что это за символ такой.
Что приходилось учить новичков? Чему учить-то? Нанимая в команду программистов их ничему учить не надо, если процессы и архитектура выстроены как положено. Объяснять — да, но не УЧИТЬ.
А из плюсов перехода на ГО автор описал самые типичные фичи golang, ничего нового. Так в чём моя интерпретация вашего перевода не совпадает с фактами?
P.S. я люблю и пишу на golang, в прошлых ваших статьях я его иногда защищал. Нужно быть реалистом и относиться ко всему без предвзятости. Тут же я вижу большие проблемы в команде, которые завуалировались механизмами написания на Go, он просто не даёт им совершить те же ошибки. Но это в то же время значит, что не будь у них типичных болячек неумелого IT лида, им бы не пришлось переписывать всё.
divan0
Прежде всего с тональностью вашего комментария. Ну и дальше:
Как будто ценность статей измеряется «новизной». Я. хоть и читаю вообще все статьи про Go, в этой статье увидел достаточно нового, чтобы захотеть её перевести. А сам аргумент «ничего нового» — так себе. В вашем комментарии тоже ничего нового ведь.
Именно.
Интереса ради, а у вас был опыт управления компанией, которая выросла с 5 до 200 человек?
solver
>Прежде всего с тональностью вашего комментария.
И тут Go-шники ведут себя как маленькие обиженные детки.
Хорошо хоть хабр не их комьюнити площадка, а то бы и тут начали выпиливать всех, кто посмел своей тональностью обидеть их горячо любимый Go.
divan0
Тоесть, по вашему, если кому-то не нравится насмешливая тональность, в которой автор приносит свои предрассудки — то это «маленькие обиженные детки»? )
Как-то вы болезненно реагируете на то, что кому-то подобная тональность не нравится, вам не кажется?
namespace
Чет ты какой-то сильно микроагрессивный, вообще не попадаешь в нормы поведения (golang.org/conduct) сообщества! Сейчас тебя забаним и пулл реквесты от тебя принимать не станем, понял?
П.С. Ссылки не работают? 0_O
dordzhiev
Да, Пайк бы точно не одобрил такое поведение…
creker
Почитайте Пайка на форумах. Любитель язвить и провоцировать людей, вместо поддержки конструктивной беседы.
dordzhiev
Но кто же тогда составлял это? Почему же гоферы не следуют ему?
divan0
Это что-то новенькое. Покажите мне где Пайк язвит и провоцирует людей, вместо поддержки конструктивной беседы.
creker
Только недавно читал про подсветку синтаксиса для Go groups.google.com/forum/#!topic/golang-nuts/hJHCAaiL0so, где Пайк кидался только шуточками и язвительными комментариями в духе «подсветка синтаксиса для детишек, я выше этого». В итоге пришел еще один человек из команды Go и заткнул рот тем, кто начал катить бочку на Пайка за такой настрой. Замечательная атмосфера просто.
Это типичный такой жирный троллинг.
divan0
Нет, Почитайте тред. Он начинается со слов «Новый Холивар», в котором Пайк, который относится к программистам, не любящих подсветку синтаксиса, в духе треда и ответил, и вполне невинно.
Но вы же себя только что изобразили знатоком постов Пайка, так что приведите, пожалуйста, ещё примеры, где Пайк «язвит» и «провоцирует людей, вместо поддержки конструктивной беседы». Я же полагаю, вы не станете называть единственный пример с текстом «новый холивар» конструктивной беседой?
По моим наблюдениям, Пайк отвечает очень лаконично, и там где нужен действительно его ответ — всегда по сути. Так что ваши наезды мне не сильно понятны.
creker
И опять вы свернулись в клубок и выпустили иголочки. Никто на вашего Пайка не наезжал. Я всего лишь заметил, что он тот еще троль. Что тут говорить, я так же отвечал вам, когда мне надоело уже видеть непробиваемое фанбойство.
Я бы это вам посоветовал, ибо так нагло врать нехорошо. Никто там про хиловары не заикался. А Пайк всего лишь пришел и вбросил, больше ничего он не добавил в ту беседу.
divan0
У меня к вам был простой вопрос — покажите ещё примеры, где Пайк «троллит», «язвит» и «провоцирует людей». Ведь если из 1000 ответов Пайка лишь один, и то, с натяжкой, подходит под ваше «не наезжание», то значит вы не правы и оскорбляете незаслуженно человека троллем. Я вас прошу либо доказать мне, что ваши слова — не пусты, либо признать ошибку.
А ваши личностные выпады в адрес всех подряд совсем не к месту.
poxu
Думаю, если привести ссылку по которой Пайк вежливо, коротко и по делу даёт ответ на поставленный вопрос, это будет не менее показательно.
divan0
Это 99% его ответов. И товарищ крекер это прекрасно знает.
poxu
Товарищ крекер может и знает, а вот я, например, ничего, кроме этого самого треда про подсветку не видел никогда. Да и многие другие тоже.
divan0
А что мешает зайти в группы golang-dev и golang-nuts и вбить в поиск «rob pike»?
poxu
Я попробовал, чего-то ничего показательного не нашёл. В основном какие-то другие люди рассказывают что-то про Роба Пайка.
Может, вы найдёте пример какого-нибудь ответа Роба Пайка? Вы их видели много, знаете где найти и какой выбрать. Вы наверняка сделаете это быстрее и самое главное лучше, чем я.
divan0
Как это всё странно. Ну держите.
poxu
Спасибо!
Вообще любопытно, как Пайк по сравнению с Линусом Торвальдсом. Ну то есть понятно, что пассажа, подобного пассажу с NVidia у Пайка наверное не найти. Но вообще он где-нибудь оглашал своё мнение по поводу того, как надо реагировать на косяки разработчиков?
divan0
Не знаю, он достаточно лаконично и кратко высказывается. В стиле «чем меньше скажешь, тем меньше поводов неправильно трактовать». Возможно, иногда слишком кратко, но уж точно не тролль и не язвитель, как это зачем-то придумал комментатор выше.
Была разве что статья у него про критиков: habrahabr.ru/post/197398
grossws
Зато Пайк бы одобрил, что ссылки не работают. Ибо подсветка синтаксиса и rich text не нужны.
ffriend
Вроде про опыт и мнение в комментарии ничего не было, я прочитал это как критику статьи в первую очередь. И критика вполне справедливая, т.к. причинно-следственные связи в описании решений похрамывают. Да, действительно, в Scala есть проблема многообразия стилей и подходов, и вопрос не только в читабельности, но и в банальной совместимости библиотек. Но решается это банальным введением конвенций, что гораздо проще, чем изучение нового языка и переписывание существующей кодовой базы.
Что ещё более нелогично, так это то, что Scala всё ещё осталась в инструментарии этой компании. Т.е. если раньше было 2 стиля программирования на Scala, то теперь осталось всё те же 2 стиля плюс другой язык. И чего, спрашивается, они этим добились?
Скорее всего, описанная проблема — это только вершина айсберга, и на самом деле были гораздо более веские причины сменить язык. Но о них в статье ничего не сказано, почему она и вызывает недоверие.
Starche
Чего вы сразу в штыки-то?
Вот я не являюсь го-хейтером, потому что я вообще почти не знаком с го) Говорят отличный язык, всё никак руки не доходят попробовать.
Но в статьей действительно об эттом
Кстати, о чём это говорит: го дружелюбен к новичкам, что очень неплохо на мой поверхностный взгляд. В общем, будьте проще, не надо рычать на всех, с кем вы не согласны.
divan0
Понимаете, один и тот же посыл можно сказать совершенно разными словами. Какова была цель и суть комментария, в котором автор придумал/приписал некоторые вещи, чтобы придать своей оценке надменно-насмешнического оттенка?
И почему люди, так ратующие за «будьте проще ко всем, с кем вы не согласны» не могут быть проще к тем, кто не согласны с ними?
MetaDone
В эфире — ставшая почти регулярной рубрика «Переезжаем с *langName* на Go»
Или это такая активная пропаганда, или же действительно стоит что-то запустить на Go
divan0
Меня как-то коробит сама постановка вопроса — «стоит что-то запустить на Go».
Язык — это инструмент для решения задач, ни больше, ни меньше. Запускать что-то ради языка — это как копать яму ради лопаты.
Если слышите, что много людей хвалят инструмент — познакомьтесь, оцените его подходящесть для ваших задач и исходите из прагматических соображений.
MetaDone
наверно не так выразился — «стоит что-то запустить на Go» — это в Вашей формулировке «познакомьтесь, оцените его подходящесть для ваших задач и исходите из прагматических соображений»
divan0
Ну тогда да, поддерживаю.
dmitryklerik
Обратите внимание что статьи пишут одни и те же люди, то что про Go «много говорят» в основном объясняется их продуктивностью в написании статей.
divan0
Вы наверное хотели сказать «обратите внимание, что на хабр делают переводы одни и те же люди»? Статьи пишут совершенно разные люди.
tyderh
Я (сердце) отличные переводы
Stepanow
Видимо, автор не мог выбрать какой символ ? использовать.
TheShock
Только благодаря вашему комментарию понял, что означает то «сердце».
vayho
Почему статью не назвали «Как мы перешли со Scalaz на Go»? Как бы Scalaz != Scala. Я например не использую эту либу в своем коде, потому что в стандартной скале и так много готовых хороших абстракций. Так же Scalaz не советуют использовать и текущие разработчики Scala.
miolini
Может потому что разработчики себя именовали Scalа-разработчиками, а не Scalaz-разработчиками?
dom1n1k
Так и что же та кракозябра означает?
namespace
Не задавай глупые вопросы, а просто переходи на Go, что ты не понимаешь?
cs0ip
На самом деле этот вопрос интересовал многих scala-разработчиков (как я понимаю, сейчас эту штуку убрали, или переместили...).
И благодаря поисковику по подобным операторам я таки вышел на вопрос на SO. Если его долго читать, то наверно можно разобраться.
symbolhound.com/?q=%3C|*|%3E
stackoverflow.com/questions/2545248/function-syntax-puzzler-in-scalaz
А вот тут исходник сего оператора: github.com/scalaz/scalaz/blob/release/6.0.4/core/src/main/scala/scalaz/MA.scala#L52
Но вообще, это скорее пример того, как scala использовать не нужно.
remal
Ошибка автора, как мне кажется, в неверной расстановки приоритетов при оценке коллег. Как только половина людей (по его словам) говорит «wtf», то автор кода, имхо, никак не может называться «выдающимся программистом».
Написать сложный one-liner много ума не надо. А вот написать код так, чтобы он легко читался и содержал как можно меньше шума…
https://youtu.be/TSAlj04_tkA (часть 1)
https://youtu.be/cPXTozVjSHo (часть 2)
В свое время этот доклад совершенно перевернул мое видение. Крайне советую всем посмотреть независимо от языка.
aml
При том, что я с вами согласен (в плане оценки коллег), я бы хотел ещё одну мысль в копилочку добавить: язык программирования задаёт рамки, которые могут затруднить или облегчить написание трудночитаемого кода. Go не даёт писать хитрый, сложный, нечитаемый код просто потому, что из него изъяли кучу конструкций, и этим он хорош.
grossws
С использованием достаточного количества каналов и select'ов тоже можно нагородить. Как и в случае других языков, вопрос в том, насколько быстро дадут по рукам линейкой.
igrishaev
Почему не взяли Кложу? Легче Скалы, но тот же JVM.
ShadowsMind
У меня такое ощущение, что «кто-то» там явно проплачивает все эти «переходы» на Go, уж больно обоснования бредовые и притянутые за уши… )
divan0
Да, именно так всё и происходит в реальном мире )
taliban
Да ладно, много конечно воды налили, но по сути го перекрыл доступ «умникам» к их «мега гениальным» конструкциям кода, чего не получалось сделать тимлиду в оффлайне палкой или чем он там пользуется. В конкретном случае го выполнил свою роль на ура именно простотой.
terryP
Я ничего не хочу сказать плохого про Go, но статья выглядит как «Мы не способны ввести единый стандарт кодирования в нашей команде, зато способны заставить всех разработчиков учить новый язык и теперь у нас три стандарта кодирования (два от scala и один от GO)». Если есть проблема с механизмом сборки SBT почему не взять другую систему сборки? Если проблемы в том что команда пишет в двух разных стилях, почему не разделить команду на разные проекты или железно заставить писать в одном стиле? Как code review пропустил код, написанный так, что его никто в команде больше не понимает?
В целом, решение чисто административных проблем, описанных в статье, переходом на новый язык выглядит как попытка переименовать милицию в полицию, в расчете что это победит коррупцию.
psylosss
.
divan0
Ну вот вы хорошие вопросы задаёте, но почему-то упускаете вопрос «Если есть язык, который людям больше нравится и подходит под задачи лучше — почему бы последовательно не перейти на него, особенно если позволяют сроки/планы». Повторюсь, язык это просто инструмент решения задачи, это не религия. Если есть инструмент более подходящий — почему бы не использовать его?
creker
Язык инструмент решения задачи, но не инструмент решения проблем менеджмента. Статья не имеет никакого отношения к «Если есть язык, который людям больше нравится и подходит под задачи лучше — почему бы последовательно не перейти на него, особенно если позволяют сроки/планы»
divan0
Статья имеет прямейшее к этому отношение.
taliban
Вы же сами писали что изначально го никто не знал, и вам пришлось его учить. А тут вдруг «есть язык, который людям больше нравится». Это полностью противоречит тому что написано в статье :) Надо было просто навалять тому кто каракулину вставил в код, а если бы возникать начал, то уволить. тогда другие начали бы попроще код писать, в итоге всем было бы легче работать. идти на поводу у разработчиков не дело, прислушиваться нужно, но не потакать.
terryP
Я не упускаю, просто причины, указанные в статье, почему был осуществлен переход со Scala на Go — нелепые (говорю с точки зрения бывшего менеджера команды похожего размера, что в статье). Соотвествено, либо в статье не указаны реальные причины перехода, либо автор некомпентентен. В любом случее, доверять такой статьи нельзя категорически.
divan0
Не хочу поставить под сомнение вашу квалификацию, но на Хабре про любую статью о переходе на Go пишут то же самое. Как будто смена технологий в стеке компании — это отречение от религии, и нужно любой ценой до последнего держаться за один язык.
VolCh
Пускай чисто административные проблемы. Но их же решили путём принятия административного решения: «теперь пишем на Go» :)
psylosss
200 человек в одной команде? У них не с инструментами проблемы, у них с организацией процесса разработки проблемы. 200 человек внезапно оказались слишком разными? Просто удивительно. Всё-таки не каждый хороший разработчик автоматически становится хорошим руководителем. А статья не про Go, да, а про техдира-неумеху, который продолжает наступать на грабли.
divan0
Возможно, хотя в статье нет подробностей о том, как команды были разбиты. Хотя есть намеки на то, что было много команд.
А у вас сколько было максимум в команде, которой вы управляли?
psylosss
В статье вобще нет подробностей почти ни о чем, кроме поиска непонятного бага и хвалебных од Go. У меня 20см а у вас?
divan0
Да там полно подробностей, и весьма интересных. Вы либо невнимательно читали, либо чрезмерно предвзяты ко всем статьям про Go.
psylosss
Разумеется я чрезмерно предвзят ко всем статьям на Go. Я всё ещё не похоронил мысль о том, что он мне когда-нибудь пригодится. Но каждый раз я завершаю чтение с одними и теми же мыслями и выводами. Наверное, мешает личная симпатия к некоторым аспектам языка (к слову, документация, комьюнити, читабельность, поддерживаемость и масштабируемость к этим аспектам не относится, а для меня это важные вещи, поэтому для меня Go вряд ли когда-нибудь станет языком по-умолчанию).
Разумеется, я прочёл статью внимательно. И конечно же там много подробностей (три часа ночи, три программиста, Scala, Scalaz, .......). Но они не про Go.
Мне было бы очень любопытно взглянуть на кусок их кода на Go, взятый из примерно того же уровня абстракции, что приведённый фрагмент на scala.
divan0
Это слишком заметно.
Да, господи, ничего в этом ужасного нет. Пишите на чём вам удобнее.
Вы так пишете, будто статьи на хабре пишутся для вас лично и всем очень важно знать вашу реакцию.
psylosss
Действительно, я оставил несколько комментариев под вашими переводами. Но я не раскаиваюсь.
Можно попродробнее на этом моменте? Что навело вас на эту мысль? И, если вас не затруднит, детализируйте пожалуйста — «так пишете» — это как именно?
divan0
Вы слишком много и часто акцентируете внимание на своем «я». «Я делаю вывод», «я похоронил мысль», «мне важно», «у меня 20 см» и тд. Выглядит это несколько странно.
psylosss
Для кого это выглядит странным?
matiouchkine
Спасибо, кстати, вот этот тред позволил мне, наконец, понять, чем меня так этот весь шум про го напрягает: активные сторонники всегда агрессивнее, косноязычнее и просто тупее, чем сомневающиеся, причем вот со всем этим джентльменским набором: «сколько человек ты прогибал», «иди мимо, это не для тебя» и так далее.
На простые вопросы ответить не хотят (не могут?), «Гугл переходит на го» в качестве вечного аргумента (у гугла столько слабосвязанных сервисов, что я не удивлюсь увидеть у них и ним/немерле в продакшене), в общем, от коммьюнити явно попахивает школотой.
При этом, как вы совершенно верно заметили, сам-то язык, может быть, и ничего. Просто я не вполне понимаю, зачем лично мне, профессионалу более-менее, выбирать команду и язык по принципу «обезьяна справится с порогом входа». Ну пусть обезбяны справляются, я очень рад за них, спецам-то это все зачем?
divan0
Ваш комментарий, безусловно, демонстрирует образцовое общение. :)
matiouchkine
А я и не претендую, я уже давно пишу комментарии, как мне нравится. И общаться с вами у меня никакого желания не было, поэтому я вам ничего и не написал.
divan0
Вы целых два комментария написали от вашего «нежелания общаться». ))))
matiouchkine
О, четыре смайлика, что может быть красноречивее.
Повторяю еще раз для особо одаренных: первый комментарий был написан не вам, а последующие меня вынудило написать остаточное воспитание; меня научили в публичных беседах указывать на невменяемость собеседника ради остальных участников.
divan0
Точно остаточное )) Понятно, откуда у вас -20 кармы тут.
taliban
Не надо обижать активных сторонников, вы щас высказали мнение из серии «блондинки тупые а брюнетки нет» :) Будьте лояльными, мы не все агрессивные, от людей зависит, как и в другой отрасли.
matiouchkine
А я вообще считаю, что активные сторонники любого языка — люди ограниченные. Для одних задач хорошо подходит эрланг, для других — R, для третьих — си, для четвертых — java/scala. Своя безусловная ниша есть у lua, javascript, LISP, FORTRAN, SQL.
Таких задач, для которых лучше всего подходит го, насколько могу судить, нет. Ну, если не считать задачей «нанять двести обезьян по дешевке».
Поэтому как только товарищ начинает предъявлять «сперва добейся», товарищ идет нахрен. А так-то я со всей максимальной лояльностью :)
divan0
Именно то, что я пытаюсь донести в каждом втором комментарии.
Ещё один обиженный. :) Как попускать каждую статью — так герои, а как ответить, сколько людей было в подчинении — так сразу в гопников играют. Ну и публика тут.
poxu
А вы не могли бы описать спектр задач, для которых Go подходит лучше всего остального?
divan0
poxu
Офигенная картинка! Откуда она?
divan0
Из внутреннего доклада.
poxu
Лучшего ответа на мой вопрос дать наверное было нельзя :)
grossws
И к какой части embedded оно так прекрасно подходит? Или в данном случае embedded это linux @ arm9/arm11/arm cortex-a/mips?
creker
Даже меньше. Достаточно посмотреть на поддерживаемые комбинации GOOS и GOARCH golang.org/doc/install/source
VolCh
А по каким критериям вы определяете лучше подходит язык или хуже?
Экономические в их число не входят, да?
matiouchkine
> А по каким критериям вы определяете лучше подходит язык или хуже?
По производительности, количеству и внятности кода, который нужно будет написать профессионалу, чтобы эту задачу решить.
> Экономические в их число не входят, да?
Не входят. Этот вопрос не про качество языка вообще, он лежит в перпендикулярной плоскости. Если бы статья была озаглавлена «как мы сэкономили бабла на качестве нашего продукта за счет найма хомяков» — я бы вообще слова не сказал.
VolCh
Производительность (и программы, и программиста) — критерий важный прежде всего с экономической точки зрения. Количество кода — тоже. Внятность — аналогично.
Экономический критерий самый важный для коммерческой и близкой к ней разработки. И если какой-то язык позволяет решить задачу при найме 10 хомяков, а другой наймом одного профи, который хочет денег как 20 хомяков, то первый язык лучше при прочих равных.
matiouchkine
А, простите, я просто думал, что хабр хоть в какой-то мере остался сообществом программистов. Как программисту, мне хотелось бы тут обсуждать преимущества языков не с экономической точки зрения. Мне хватает необходимости уделять экономическому аспекту проблемы кучу времени. Потому что в нашей скромной компании я вынужден принимать технологические стратегические решения.
Но и даже в этой ситуации я не вижу преимуществ го. Историй успеха нет. «Мы переписали все с руби на скала» и получили 20? преимущество — слышал. «Аккуратно переписали проксирование и получили 40?» — было. Написали свою виртуальную машину для обработки PHP — помню. А вот выбросили виртуальную машину Java в пользу го и теперь все круто — только на уровне недотеп из никому не известных компаний.
Да и само понятие «экономический аспект» вы понимаете неправильно. Наша контора, например, пока растет быстрее, чем развивается го. Поэтому на сегодняшний день я даже не рассматриваю го в качестве варианта на «попробовать микросервисы». Банально нет данных на отзывчивость под нагрузкой. А мы на одной неверной транзакции можем обанкротиться. Это не сервис гугла, и не инстаграм, где недопоказ картинки обернется максимум воплями имярека в бложике.
Так что экономически го тоже не фонтан. Если не пытаться сэкономить три копейки прямо сейчас, полностью наплевав на потенциальное будущее.
VolCh
Хотите обсуждать красоту синтаксиса? Можно. Но вот сколько задач вы сможете решить с помощью того или иного языка за один период рабочего времени — это уже экономический аспект. Равно как и сколько рабочего времени потребуется другим программистам, чтобы начать полноценно поддерживать эти ваши решения. И сколько серверов потребуется, чтобы ваши решения обслуживали 100500 запросов.
Так «не фонтан» или «нет данных»?
matiouchkine
Видите ли, в продакшене «нет данных» ? «не фонтан».
Эрланг 30 лет боролся за свои 15 девяток. Я уже довольно давно решения для задач бизнеса выбираю не в детском саду.
VolCh
В продакшене «нет данных» эквивалентно «мы ленивы и не провели тестирования».
matiouchkine
Да ну? Куда ваши экономические критерии-то подевались? У меня нет свободных даже трех программистов, чтобы попробовать перевести что-нибудь на го и «провести тестирование».
А тестирование fps в вакууме — это вон к диванному аналитику с таким штатом в подчинении, что там можно полк отрядить тестировать.
VolCh
На нет и суда нет. Так бы сразу и говорили, что ресурсов на стратегические исследования у вас нет.
matiouchkine
У меня есть ресурсы на проведение стратегических исследований. У меня нет ресурсов на «попробовать хипстерский язык из-за невнятных статеек на хабре».
Я не могу себе позволить пробовать все, что нынче модно. Я вынужден выбирать. И основной критерий выбора — наличие очевидных плюсов в сравнении с имеющимся стеком. У го таких плюсов нет, пока что, по крайней мере.
VolCh
Видимо у Гугла, Дропбокса, Хероку, Докера, Монги и т. д. есть ресурсы на «попробовать хипстерский язык из-за невнятных статеек на хабре» :) Вот прямо мониторят Хабр и начинают после этого пробовать.
Не нет плюсов, а вы не знаете этих плюсов, потому что судите об языке лишь по «невнятным статейкам на хабре».
matiouchkine
> Видимо у Гугла, Дропбокса, Хероку, Докера, Монги
Да, у гугла ресурсов больше. Это довольно внезапно, согласитесь, так-то обычно я привык к обратному.
> вы не знаете этих плюсов, потому что судите об языке лишь по «невнятным статейкам на хабре»
О, аргументы «ad hominem», это я люблю. «Это я бомбил Балканы, я зарезал Корвалана и Александра Мирзояна я планировал убить.»
Мне даже добавить-то нечего, настолько это все смешно и по-детски.
creker
А назовите, пожалуйста, причину, по которой тот же докер выбрал Go? Я из их презентаций не слышал киллер фичи, из-за которой он был выбран. И складывается как раз ощущение, что был выбран, потому что модно и интересно, а потом внезапно взлетело. Сам докер то внезапно взлетел, в его success-story не видно никакого планирования долгосрочного. Была внутренняя утилита, переписали для народа — внезапно взлетело.
VolCh
www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go/18-Why_GoThe_Five_Reasons_Why
grossws
Там же прекрасно описаны больные места go, о которые они побились головой.
VolCh
Плюсов в общем случае это не отменяет.
grossws
Естественно, но обзор куда более полноценный и взвешенный, нежели эти хипстерско-восторженные статьи про go на хабре (не все, но от данного автора — почти всегда).
Поэтому по вашей ссылке можно узнать о сильных и слабых сторонах go куда быстрее и полнее, чем с хабра.
taliban
Не думали что я могу быть активным сторонником нескольких языков? Не стоит путать активных сторонников и фанатиков. Я лично знаю 3 языка, и мне нравится выбирать между ними и писать на разных, я люблю изучить что-то новое, но при этом у меня есть личные предпочтения, и я старюсь быть обьективным глядя через призму своего опыта а не кричать с пеной у рта что го «самыйлучшийилучшенегонетиникогаднебудет!!!!». Так что не нужно преувеличивать.
psylosss
Ткните носом, пожалуйста. А я в ответ ткну вас в намёки о том, что команда была одна.
divan0
«предоставлять приятный DSL для наших аналитиков»
или вот
«Сейчас у нас большинство наших проектов написаны на Go, и последний сопротивляющийся Go программист буквально на днях написал свой первый Go проект и сказал мне следующее: «Ухты, я прочёл код библиотеки один раз и я знал, что она делае»
— очевидно, что если был разработчик, который сопротивлялся Go, значит у него была возможность работать над продуктами на Scala, а значит он был в своем микро-тиме.
Хотя, в любом случае очевидно, что 200 человек требуют определенную организацию и иерархию. Но в статье, и вправду. деталей про это нет. Можете написать автору, если очень интересно, думаю он с удовольствием откликнется.
psylosss
Речь о конкретной команде 50+ человек. И безо всяких там намёков. Вы внимательно читали статью?
kazmiruk
Я может бесконечно далек от создания действительно крупных проектов, но команда из 50 человек?! Да управление и коммуникация в такой команде будет отнимать 99% времени. Неужели никто не читал Тома ДеМарко?
potan
В общем, компани хотят пользоваться готовыми недорогоми доступными на рынке разработчиками, а вкладываться в образование сотрудников не хотят.
divan0
А вы как бы поступали, если бы у вашего тима был выбор между двумя инструментами, которые подходят примерно одинаково, но на один вход занимает месяцы, а на другой недели?
potan
Я бы предложил любителям использования scalaz прочитать по ней лекцию. Пара часов в неделю хватило бы, что бы подтянуть команду к общему уровню.
К тому же я не соглашусь, что инструменты «примерно одикановы». Scala лучше приспособлена для написания обобщенного и повторно используемого кода, в том числе DSL. С ростом проекта это может стать очень полезным.
divan0
Интересно, но человек с достаточно хорошим опытом в этом плане пишет ровно наоборот. У вас другой опыт? Поделитесь?
potan
В частности разработка достаточно примитивного DSL у нас помогла в разработке тестов — написанные на Scala получились проще и в общем то читабельнее, чем на питоне. (С небольшой поправкой — мы продолжили использовать асинхронное API, которое применяется и в основном коде, что оказалось не совсем просто объяснить питоновским тестерам.)
vayho
Вход в Scala занимает месяцы? Это где вы такое прочитали?
divan0
В статье же. И речь не про Scala, а про проекты на Scala, как я понял, ну или и то и другое.
VolCh
potan
Ну я в Scala пришел практически не зная Java — через Haskell и C++. Тюнить jvm приходилось очень редко и проблема как правило легко гуглилась.
vayho
Возможно у них в компании все так печально, у меня на первой работе на устновку JVM давали 4 часа. Ну и тюнингом новички обычно не занимаются. Да и какой там тюнинг, в 99% случаев его нет вообще, кроме 3х параметров "-server -Xms -Xmx". Java контейнеры это бинарники, просто JVM ориентированные, никакого там сюрприза для человека который например пользовался gcc до этого нет.
stingray
Статья произвела, так скажем, гнетущее впечатление.
Во-первых, про spaceship operator. В go можно использовать уникод в именах переменных: play.golang.org/p/CcskBn6Y8Y. Так что запутать код можно на отличненько, если захотеть.
Во-вторых, и видимо это главный движущий фактор всех этих переходов, на Go очень хорошо получается «тяп ляп и в продакшен», а за счёт отсутствующей системы типов каждый раз приходится переписывать базовые вещи типа коллекций, что, видимо, повышает, как это, instant gratification?
Не поймите меня превратно — я сам пишу на go довольно много, но то, что код на Go легче поддерживать, чем на Scala — опасное заблуждение :(
ЗЫ. Есть некоторые паттерны, которые превращают вашу жизнь в ад. Например:
os.Stdin, os.Stdout = os.Stdout, os.Stdin // lol
ну или чуть менее адово, но тоже весело:
io.EOF, io.ErrClosedPipe = io.ErrClosedPipe, io.EOF
Я уже не говорю о — нет, даже не о if err != nil, а о func (s *Foo) Bar() { if s == nil {… // прощайте запястья
divan0
Вы утверждаете, что вот тот spaceship operator это то же самое, что вставить нарочно уникод символ для запутывания? И что, они, после того, как разобрались, кто написал это, не поняли диверсию? Или это всё же не одно и тоже?
Это вы так называете низкий порог входа? То-есть, по вашему, чем сложнее технология (в идеале несколько лет на хелло ворлд), там качественнее будет продакшен?
Обоснуйте, пожалуйста. Всё таки статью не школьник писал, а человек с приличным опытом и в Scala, и уже в Go.
С какой стати код с подменой переменных стал «паттерном»?
SirEdvin
жду следующих переводов этой же компании про «как мы перешли от Go к Pascal», потому что в Го есть кодогенерация и никто из нас не понимал, что она делает. А программист который это написал, был в отпуске.
Как отметили комментаторы выше — это просто попытка уйти от проблемы. Такие статьи — отличная антиреклама для Го
divan0
Что-то мне подсказывает, что вы не дождётесь)
Пока что я встречал только одну статью об уходе с Go (на питон), написана она была мозилловцем, который ратовал за Rust, и доказывал, что «питон сравним по использованию памяти с Go» с пометкой «если у Go потекут горутины» )))
Думаю, наоборот )
SirEdvin
Ну или «Почему Go не решает проблемы».
Потому что с такими как у них процессами разработки все произойдет так:
1. Они будут кодить/быдлокодить на Go, потому что писать на новом языке нужно привыкать.
2. Зафигашат кучу кодогенерации при помощи сторонних самонаписанных утилит.
3. Никто кроме тех, кто их написал не будут знать, как они работают.
4. Вуяла, проблем стало еще больше.
Вы вот словили тонны возмущения в комментариях и ничего не поняли?
Возмущения не потому, что Go — плохой язык или все любят Scala, а потому что статья совершенно мерзко относится к Go.
В статье сразу выставлен на показ корень проблем компании — у них не настроен процесс разработки. У них нет взаимозаменяемости между программистами, если один из них ушел в отпуск. У них нет code review, который пропустил такой кусок кода. У них нет приблизительных стандартов. У них вообще нет ничего, кроме стиля «каждый кодит как хочет».
Главный мотив статьи:
В корне ошибочен. Go этого не делает. И это очевидно для всех, кроме вас и технического директора.
Ну а про анти-рекламу. То, что именно такая статья, которая имеет в себе очевидно ложный посыл и еще кучу ложных (Системы сброки для Go лучше, чем системы сборки из мира Java) и откровенно глупых фактов (Мы не осилили SBT только один из 50 человек знал, как она работает) дает впечетление, что для Go нельзя написать ничего лучше. Нельзя написать статей в стиле «Мы переписали наш адекватный проект с Scala на Go и получили 2-х кратный прирост производительности». Или «мы перешли со Scala на Go и смогли переписать наш ужасный код, который решал ужасную проблему в более простой форме».
divan0
Радует ваша уверенность в предсказании будущего ) У вас всё так просто и понятно.
Поверьте, всю эту «тонну возмущения» пишут одни и те же люди, которых я знаю уже по никам наизусть. Тут у них своя тусовка Go-хейтеров. Они все знают, как правильно управлять командами 200+ человек. но сильно обижаются, когда спрашиваешь, был ли у них опыт управления хоть одним человеком. Так что не обольщайтесь.
Вы отчасти правы, но лишь в теории. В мире нет компаний, у которых все идеально, люди работают как роботы по гайдлайнам, и в организационном плане никаких проблем. Это миф. Даже гиганты, которые тут добились хороших успехов, имеют массу головой боли. Не нужно себя обманывать — я поэтому и спрашиваю людей, был ли у них реальный опыт или они теоретизируют, опираясь на картинку в голове.
И именно поэтому, инструмент тоже играет важную роль, принося дополнительную сложность (accidental complexity) в том числе в организационные процессы разработки.
Ну а вы тут не правы в том, что вы взяли один пример, который автор привел для демонстрации, экстраполировали его на всю компанию, на все процессы и считаете, что понимаете степень их компетентности и уровня организации.
Зато мудрые хабравчане без опыта менеджмента всё видят. Эх, ваши б познания да в благое русло — столько денег могли бы срубить! )
Ну я понял ваш посыл, но считаю его в корне неверным из-за излишней предвзятости. Считаете, что после этой статьи тысячи программистов разбегутся и поставят на Go крест — пожалуйста, считайте. Я же убежден, что эффект будет иной.
SirEdvin
У вас проблемы с Go-хейтерами. Вы в каждом человеке видите такого.
Подскажите тогда, раз вы у нас опытный и продвинутый, как именно Go решает такие проблемы как:
И по этому над этими проблемами нужно работать. Если вы думаете, что в Go нельзя написать код, который никто не поймет, я уже привел вам выше пример. А еще там есть С-шный вставки прямо в комментариях. И так далее.
А еще в Go нет стандартного инструмента для сборки с управлениям зависимостями.
А еще в нем куча других организационных проблем.
divan0
Да нет, это вы мне приписываете. У нас вообще с вами дискуссия в стиле " — Вы считаете, что 2х2=5. — Нет, я так не считаю.". Скучно же.
Код-ревью не решает, конечно же. Заменяемость решает тем. что, как и описано в статье, можно взять человека почти с любым бекграундом и за недели иметь программиста, способного писать и поддерживать проекты на Go. Гайдлайны не нужны, потому что в Go очень мало способов сделать одно и то же разными способами, он сам по себе гайдлайн.
Никто ж не спорит. Вопрос в том, насколько эти проблемы сравнимы с проблемами при использовании других языков на практике.
rg_software
Знаете, безотносительно Go я слабо верю в простоту.
Ведь мы это всё уже проходили. Помните 1996 год? :)
Java появилась ровно с тем же набором аргументов: C++ толстый язык, в нём масса сложного (указатели, препроцессор), масса всяких legacy-инструментов (include макросы и т.п.), а мы сейчас сделаем простое и удобное. И что? Прошло 20 лет, и теперь Java такой же монстр. И с C# та же точно история, сравните с чего язык начался, и к чему пришёл.
Соответственно, простой язык — это что-то вроде Эсперанто: либо он неизбежно начнёт усложняться от столкновения с реальным миром, либо обречён на использование некой узкой тусовкой (пусть даже и вполне достойной). Иного я не видел до сих пор, и не понимаю, почему что-то должно стать иначе.
divan0
Верю. Я знаю немало программистов, которые считают, что чем сложнее технология, тем она правильная. Или даже в другой форме — что сложную технологию нужно учить, потому что это даст финансовую выгоду. Но я прямо противоположного мнения, и, к счастью, мои взгляды совпадают с массой трудов, книг и статей на эту тему.
Во-первых, не с ровно таким же. Go — это первый язык, где «выпиливание фич» сделано намеренно, принципиально и бесжалстно, и в том числе, из-за опыта Джавы. Во-вторых, даже если бы это было так — вы же не станете экстраполировать частное на общее. Законы логики ж помешают делать такой вывод :)
Не начнёт, авторы год за годом повторяются — язык меняться не будет. И их достаточно много атакуют за это, студенты-любители эксепшенов и дженериков. :) А с миром реальным он давно уже столкнулся, поверьте.
rg_software
ОК, он меняться не будет, и значит, останется ровно там же, где и был.
Это тоже вполне нормальный метод существования: вот наши принципы, и мы не будем прогибаться.
Надо понимать, что Java / C++ / C# ровно потому и сидят уже десять лет в десятке, что готовы изменяться и усложняться.
В данном случае «сложность» — это не самоцель, фраза «чем сложнее технология, тем она правильная», конечно, бредова. Сложность — это что-то вроде функциональности MS Word: любому нормальному юзеру 90% всех функций нафиг не нужно. Проблема в том, что разным юзерам нужны разные 10%, и именно потому Word и лидер рынка, хоть от него и плюются.
Соответственно, у авторов языка есть выбор: либо становится монстром а-ля Word и обслуживать огромную массу пользователей с разными потребностями, либо становиться нишевым продуктом. Как раз эта логика подтверждается огромной массой практических примеров из самых разных областей.
divan0
Вам и если язык меняется — плохо, и если не меняется — тоже плохо. Как тяжело жить! :)
rg_software
Да мне-то нормально: я к росту сложности отношусь философски. Непонятно, как видят будущее своих детищ адепты простоты.
terryP
Странная логика. В чем отличие Java/С# от C++? В том что выпилили половину фич C++: макросы, указатели, хитрые способы работы с памятью, деструкторы и т.д. В Java 1 сознательно оставили процентов 20 от всех фич и возможностей С++. Так что говорить что Go такой первый язык — нелепо.
divan0
Ну, если вы правы, и в Java 1 действительно 20% от функционала С++, то наверное, и вправду, не первый. Но я не знаю так детально историю Java, не могу оценить насколько вы правы.
rg_software
Ну так «Убить дракона» номер N: реинкарнация.
sentyaev
По моему мнению толковый программист разберется с языком, это не проблема.
Когда новый человек приходит в проект, он тратит много времени на знакомство с предметной областью, а не языком.
SirEdvin
Кодогенерация и сишные вставки решают.
На Go много способов сделать так, что бы код выглядел ужасно. Он собственно и будет так выглядеть, если вы пересадите программиста со Scala на Go.
solver
У меня ощущение, что для адептов Go, есть специальные лагеря для тренировок поведения в комьюнити. По типу спецназовских. Где их специально натаскивают использовать все самые идиотские методы ведения дискуссий. Например софистики.
Редко увидишь такое слепое и самоуверенное следование своим выдуманным кумирам.
Ну как можно оспаривать мнение «целого технического директора компании из 200+ человек»?? Это же почти бог, который никогда не ошибается. Ему надо просто внемлить. И никак иначе.
У тебя нет опыта управления командой из 200+ человек? В топку. Ты лох и ничего не можешь иметь слова в этом вопросе. И пофиг, что все адекватные управленцы в один голос говорят, что если можешь управлять 10 людьми, то сможешь и 200. Принципы управления не изменятся.
И да, я сейчас говорю про управлять, а не числиться на должности управленца.
divan0
Каким кумирам? )
Как-то вы слишком болезненно все воспринимаете. Слово может иметь каждый, но, согласитесь, когда человек без опыта рассказывает «как надо» и оскорбляет человека с опытом, который ещё и делится с миром своим опытом, то это выглядит не в пользу первого. И Go тут не причем, это абсолютно любой темы касается.
Нет, это неадекватность отдельных хабраперсонажей создает закалку )) Повеселили, спасибо )
Megaprog
Почему не перешли со Scala на Java? Почему не отказались от SBT в пользу Maven? Потому что не модно?
divan0
Думаю, можно написать автору в твиттер. А в чём преимущества перехода на Java, по сравнению с Go?
terryP
В том что можешь продолжать использовать весь свой старый код на scala/java, свои привычные IDE и свои привычные инструменты разработки, в том что остается пусть урезаный, но функциональный стиль? В том что программистов Java любого уровня на рынке полно (в отличии от Go), а любой (скорее всего) программист на scala знает Java? Так что такого революционного дает Go по сравнению с Java, чтобы стоило отказываться от всего описанного выше?
vayho
Вы забыли что количество готового кода на Java несравнимо больше чем на Go, ну это так мелкое дополнение.
divan0
Возможно. Но этим и ценны подобные статьи, рассказывающие о реальном опыте, что по ним можно судить насколько те или иные моменты действительно проблемны или нет. К примеру. то что автор пишет про «расширился пул программистов, которых можем нанимать» кореллирует с моими наблюдениями в других компаниях, перешедших на Go, но идет в разрез с вашей гипотезой о том, что количество программистов на Java может быть преимуществом.
rg_software
А можно вернуться к моим любимым циферкам: например, зайдём на linkedin и посчитаем количество людей с разными языками в профиле.
guai
Это когда было-то? Сейчас есть офигенная замена скале и яве — цейлон. С год назад зарелизился, недавно 1.2 выкатили. Поддержка в эклипсе и в идее (пока сырая, но быстро прогрессирует).
ov7a
Офигенный тимлид, ага. Не знает о том, что спецсимволы в гугле игнорируются и несколько часов делает то, что grep делает за несколько секунд.