Comments 112
Вы предлагаете усложнять язык просто чтобы программистам было о чем похоливарить и чем потешить ЧСВ?
Наоборот, это круто, когда язык простой в освоении, но при этом не дубовый, как php ранних версий. php усложняли потому, что на нем стремились писать все более объемные проекты. Зачем — долгий разговор, но так было.
Го имеет достаточно четкую направленность, его не рассчитывают как ЯП для энтерпрайза например. Но когда программисту на php, питоне или чем-то еще нужно будет сделать какой-то сервис быстрым, то большим плюсом будет то, что Го просто освоить. Сервис на Го и напишут, а не будут придумывать где бы найти спеца по С или подобному прямо сейчас и не забьют, оставив на медленном (но знакомом языке). Ну по крайней мере, вероятность этого достаточно высокая.
Проста это ниша Го. В том числе и помогает решить проблему отсутствия разработчиков на старте. Делать из Го очередную Джаву — в чем смысл, если Джава уже есть?
Наоборот, это круто, когда язык простой в освоении, но при этом не дубовый, как php ранних версий. php усложняли потому, что на нем стремились писать все более объемные проекты. Зачем — долгий разговор, но так было.
Го имеет достаточно четкую направленность, его не рассчитывают как ЯП для энтерпрайза например. Но когда программисту на php, питоне или чем-то еще нужно будет сделать какой-то сервис быстрым, то большим плюсом будет то, что Го просто освоить. Сервис на Го и напишут, а не будут придумывать где бы найти спеца по С или подобному прямо сейчас и не забьют, оставив на медленном (но знакомом языке). Ну по крайней мере, вероятность этого достаточно высокая.
Проста это ниша Го. В том числе и помогает решить проблему отсутствия разработчиков на старте. Делать из Го очередную Джаву — в чем смысл, если Джава уже есть?
Кажется автор имел в виду не усложнение ради усложнения\элитарности, а намеренное ограничение языком Go доступных программисту выразительных средств. Как может выглядеть путь развития Go программиста? Какие инструменты язык предоставит ему для совершенствования своего кода? Какими новыми навыками Go программист будет располагать через несколько лет?
Между тем стоит заметить, что современные яп постоянно наращивают арсенал выразительных средств, пример тому — ecmascript 2015, новая версия которого на порядок улучшила лаконичность кода.
Между тем стоит заметить, что современные яп постоянно наращивают арсенал выразительных средств, пример тому — ecmascript 2015, новая версия которого на порядок улучшила лаконичность кода.
В Lisp (в разных его вариациях) «выразительных средств» изначально немного. Но сделать ими при желании можно практически всё. Количественная метрика синтаксического сахара «из коробки» — ИМХО, далеко не лучший показатель «совершенствования кода». Вот возможность этот самый «сахар» при желании замутить самому, а не дожидаться, пока добрые разработчики тебе это дадут — (тоже ИМХО) хорошая и годная метрика, и немало движения в эту сторону наблюдается и в «модных» языках.
Lisp это язык совершенно иного сорта, он изначально расчитан на легкое расширение и создание собственных выразительных средств, сравнивать с ним некорректно.
Тут вопрос, как жить с изначально (by design) простым языком, дальнейшее расширение\усложнение которого этому «by design» и противоречит.
Кстати, почему Go, а не Nodejs?
Тут вопрос, как жить с изначально (by design) простым языком, дальнейшее расширение\усложнение которого этому «by design» и противоречит.
Кстати, почему Go, а не Nodejs?
Чего-то вообще не понятно, при чем здесь язык и путь развития программиста. Программист по профессии решает задачи, он не изучает языки ради забавы. Go решает задачи, и свои задачи он успешно решает без необходимости что-то в него еще добавлять. Он простой, но мощный. Развитие программиста это умение решать все новые задачи. Go этому никак не мешает — он никак не мешает развиваться как архитектору. Более того, его модель конкурентности породила более ценные разговоры в интернетах, чем обсуждение какой же сложный язык я выучил — как по-лучше замутить всякие паттерны конкурентные, которых полно. Каждый предлагает что-то свое со своими ограничениеми. Вот оно развитие программиста.
Освоить новую версию C# и заучить новые синтаксические конструкции — это никаким местом не развитие программиста. Количество выразительных средства, которые я могу использовать, никак не улучшает меня как программиста. А навыки я будут приобретать от решения задач, а не изучения языка. И не важно, Rust это будет или Go
Освоить новую версию C# и заучить новые синтаксические конструкции — это никаким местом не развитие программиста. Количество выразительных средства, которые я могу использовать, никак не улучшает меня как программиста. А навыки я будут приобретать от решения задач, а не изучения языка. И не важно, Rust это будет или Go
Давайте за пример возьмем php4 (да, я утрирую, но для аналогии не помешает), помогает ли его простая структура программисту больше концентрироваться на Api приложения, его архитектуре и алгоритмах? Скорее нет чем да, вероятно программист будет тратить добрую часть своего времени на борьбу с ограничениями языка, вместо того, чтобы просто воспользоваться встроенными возможностями.
В конце концов синтаксис\экосистема языка изучается один раз, это не столь большая плата за использование более мощного инструмента.
Посмотрите на современные мультипарадигменные\объектные\функциональные языки, они действительно настолько сложны, чтобы это вызывало проблемы?
В конце концов синтаксис\экосистема языка изучается один раз, это не столь большая плата за использование более мощного инструмента.
Посмотрите на современные мультипарадигменные\объектные\функциональные языки, они действительно настолько сложны, чтобы это вызывало проблемы?
Опять. Я не вижу связи между развитием программиста и объемом спецификаций языка, который он использует. Что до вопроса про PHP. Применительно к Go, да. Его простота и одновременная мощь позволяют концентрироваться на решении задачи. Это было и есть его главное достоинство, которое дало ему очень серьезный буст в популярности.
Какими новыми навыками Go программист будет располагать через несколько лет?
Неужели пусть развития программиста состоит в использовании все большего количества синтаксического сахара? Мне всегда казалось, что программист развивается по мере написания все более сложных, эффективных и расширяемых программ. Завитушки есть смысл добавлять когда их реально не хватает, а не потому что мидлам нечем понты перед джунионари покидать.
Новые выразительные стредства\Сахар как раз и вводятся в целях борьбы со сложностью, дабы программист мог писать более эффектиный, расширяемый, а главное понятный код. Конечно в некоторых случаях сахаром злоупотребляют, в некоторых он входит в противоречие со старыми концепциями и нарушает совместимость легаси кода, но конечная цель — все же помочь программисту, разве это не так?
Это все так, если изначально чего-то не хватает. Если Го (в рамках тех проектов, для которых он предназначен) позволяет писать понятный и простой код без синтаксического сахара, то не надо его туда добавлять.
Добавление таких вещей говорит о том, что ЯП используют не совсем так, как задумывали разработчики. Когда на php начали писать не personal home pages, а все более сложные сайта, а потом еще и корпортаривные системы, естественно, разработчикам языка пришлось как-то бороться с тем ужасом, который творился в коде сложных систем.
Го предназначен для сравнительно небольших и быстрых сервисов. Если не пытаться писать на нем ERP, то и расширение синтаксиса не понадобится. А пытаться, с моей точки зрения, не стоит.
Добавление таких вещей говорит о том, что ЯП используют не совсем так, как задумывали разработчики. Когда на php начали писать не personal home pages, а все более сложные сайта, а потом еще и корпортаривные системы, естественно, разработчикам языка пришлось как-то бороться с тем ужасом, который творился в коде сложных систем.
Го предназначен для сравнительно небольших и быстрых сервисов. Если не пытаться писать на нем ERP, то и расширение синтаксиса не понадобится. А пытаться, с моей точки зрения, не стоит.
За несколько лет стоит изучить больше одного языка, иначе так и останешься «мясом»
его не рассчитывают как ЯП для энтерпрайза например
А чего не хватает для энтерпрайза и почему?
Я не предлагаю усложнять язык го. Я говорил о том, что мне было бы интереснее писать на более сложных языках.
Соотвественно, для бизнеса этот язык тоже очень хорош — берешь всех подряд, грубо говоря, школьников и студентов, совсем чуть-чуть обучаешь, и вуаля, у тебя команда.
И эта команда успешно разваливает твой бизнес…
(занудным голосом) Программирование как таковое и язык, посредством которого оно выражается — две большие разницы. Человек, не понимающий алгоритмов, матана и дискретки (как минимум), но знающий язык — это кодер («мясо»), а не программист.
(даже вспомнила в очередной раз забытый пароль для этого комментария) Всё так. Когда языки становятся простыми — важно не КАК писать, а ЧТО писать. И вот тогда-то куда легче пожалеть о том, что прогуливал статистику и дискретную математику, нежели о том, что выбрал «не тот язык». Язык — это инструмент. Просто инструмент. Важен не инструмент per se, а то, что при его помощи производится. И «мясом» человека делает скорее нежелание производить нечто отличное от стандартной круглой «болванки» (на этом месте посмотрела на свою старую писанину и густо покраснела).
Про мясо. А Вы не замечаете, что программистов (любого уровня) в компании называют ресурсами? Даже не персоналом, а обезличенным, математически сухим определением «ресурсы».
Далеко не все люди, работающие програмистами, любят челлендж ради челленджа и не всех мотивирует сложность. Многие хотят в 18:00 выключить комп и выкинуть это все из головы. Многие просто не хотят брать работу домой, дома у них нежно лелеемый сервис/робот/игра, сделанные на любимом языке.
Это, конечно, правильно, но с другой стороны хочется, чтобы и работа была не просто хорошо оплачиваемая, но и интересная. А интересная работа в программировании (да и не только там), как правило, связана с челленджами разной степени сложности. Поэтому обычно не «челлендж ради челленджа», а челлендж ради саморазвития и морального удовлетворения. А если это еще и с целями фирмы совпадает (оптимальный вариант, при определенном опыте легко достигаемый), то и для повышения личного благосостояния :-)
Хотя следует оговорить, что челленджи можно найти практически везде и с любым языком. Впрочем, избегать их можно тоже везде.
Хотя следует оговорить, что челленджи можно найти практически везде и с любым языком. Впрочем, избегать их можно тоже везде.
Если работодатель набирает команду, то он обычно знает, в чём отличие программиста от человека, знающего язык программирования.
Программирование не ради программирования затевалось. Суть программирования в автоматизации и как следствие, в экономии ресурсов. Не важно что это деньги, время или энергия. Программирование вещь прагматичная. А вы хотите какого-то соревнования на бензопилах.
Сравнение с PHP очевидное, чего уж. Язык без капли «элитарности» (впрочем и без некоторой врождённой косолапости, как у «языка персональных страничек»). Но реплика «Где архитектура, где головоломные паттерны, о которых можно поспорить с коллегами?» непонятна. Архитектура и паттерны — они где обычно и к языку особого отношения не имеют. Да, можно конечно вспомнить книжку Александреску и другие книжки, про то, как с помощью изящной крнструкции из костылей можно обойти архитектурные ограничения языка, но изящество архитектуры не в этом.
Но я то тут мимо проходил, на Go не пишу, и, так уж вышло, стать у этого языка моим основным скорее всего шансов нет. Просто нету у меня интересов в соответствующей экологической нише.
Но я то тут мимо проходил, на Go не пишу, и, так уж вышло, стать у этого языка моим основным скорее всего шансов нет. Просто нету у меня интересов в соответствующей экологической нише.
Как по мне хороший программист всегда сможет выделиться из толпы кодеров
Только если ему позволят это сделать.
А у кого позволение нужно спрашивать?
Ни у кого. У человека работающего на конвеере никакой возможности «выделиться из толпы» не существует в принципе. Он просто не может работать лучше, хуже и т.д.
Ту так же, программист может выделиться из толпы кодеров, поскольку существует спрос на его услуги, а его профессия позволяет ему это сделать в силу своей спицифики, например потому, что те же «сложные» C/C++ еще много где используются.
К сожалению, в идеале, бизнесу не нужны 100000 программистов-инженеров, обладающих умением решать алгоритмические задачи, знающих несколько языков и т.д, нужны всего 1000 таких спецов + 990000 кодеров «на конвеере», которые будут писать то, что им скажут с минимальным количеством ошибок. (Все числа взяты с потолка, естественно).
Ту так же, программист может выделиться из толпы кодеров, поскольку существует спрос на его услуги, а его профессия позволяет ему это сделать в силу своей спицифики, например потому, что те же «сложные» C/C++ еще много где используются.
К сожалению, в идеале, бизнесу не нужны 100000 программистов-инженеров, обладающих умением решать алгоритмические задачи, знающих несколько языков и т.д, нужны всего 1000 таких спецов + 990000 кодеров «на конвеере», которые будут писать то, что им скажут с минимальным количеством ошибок. (Все числа взяты с потолка, естественно).
Удобно всё валить на систему, корпорации и бизнес. Вот только если у человека есть амбиции и навыки, он найдёт как выделиться, особенно в наше время. Самый банальный способ: завести проект на гитхабе.
Сейчас время возможностей для программистов. Новые направления не успевают появляться. Руководители жалуются на нехватку грамотных кадров, а компании готовы платить. Вы о каком конвейере говорите?
Сейчас время возможностей, с этим никто не спорит. Важно понимать, что здесь главное, это самое «сейчас». И очень хочется надеяться, что это сейчас продлиться как можно больше.
Дело не в какой то системе или злом умысле. Цель любого бизнеса — получение прибыли. Иначе это не бизнес. А для увеличения прибыли нужно уменьшать издержки, увеличивать количество произведенной продукции, увеличивать цену. Поэтому то, что языки программирования развиваются в сторону упрощения, уменьшения порога вхождения, уменьшения возможностей сделать ошибку и стоимости ошибки — это вполне естественный, хотя и глубоко печальный факт.
А по поводу нехватки грамотных кадров. Именно так, уже есть нехватка специалистов при избытке кодеров.
Дело не в какой то системе или злом умысле. Цель любого бизнеса — получение прибыли. Иначе это не бизнес. А для увеличения прибыли нужно уменьшать издержки, увеличивать количество произведенной продукции, увеличивать цену. Поэтому то, что языки программирования развиваются в сторону упрощения, уменьшения порога вхождения, уменьшения возможностей сделать ошибку и стоимости ошибки — это вполне естественный, хотя и глубоко печальный факт.
А по поводу нехватки грамотных кадров. Именно так, уже есть нехватка специалистов при избытке кодеров.
это вполне естественный, хотя и глубоко печальный факт.
Чем же он печален? Тем, что рутину теперь делают за тебя? Ну что же, инструменты развиваются в любой области. Раньше операции на глазах были практически невозможны, зато сейчас в любой клинике лазером могут подкорректировать зрение. Это тоже грустно?
Вот есть заказ на проект, с заранее оговоренной суммой. Основное требование — надёжность, на скорость по большей части плевать.
Вася пишет на скучной джаве, у него память сама подчищается, ошибки отлавливаются, а времени он тратит на всё это немного, так что успевает спать по ночам. Проект он сдаст через месяц, а потом поедет отдыхать.
А вот Петя пишет на интересном C, у него насыщенная жизнь: нужно постоянно следить за ресурсами, освобождать память вручную, следить за указателями, чтобы за диапазон не вышли. Он вручную анализирует ошибки по их кодам, стектрейсы составляет сам и все ночи сидит в дебаггере. Через полгода он ещё возится, деньги уже кончаются (полгода ведь надо что-то есть и где-то жить).
Причем тут избыток кодеров? Потребность отрасли в специалистах столь высока, что рынок не успевает их готовить.
Суть программирования в повышении качества жизни. В создании новых благ для человечества. То что это выгодно бизнесу – лишь следствие этого процесса. И да, программировать должно быть легко, чтобы решать более сложные задачи, делать более умный функционал, расширяя возможности конечного потребителя. Так что ничего печального в этом не вижу.
Я вас не понимаю, вы желаете решать сферические задачи в вакууме за килограммы денег!?
нужны всего 1000 таких спецов + 990000 кодеров «на конвеере»
Возможно, проблема в том классных спецов нужна 1000, а их единицы. Крайне редко когда наоборот, заурядностей найти всегда легче, чем талантов, поэтому спецы-то без работы не останутся никогда.
Никогда не сталкивались, что при собеседовании тебя спрашивают, работал ли ты с фрейворком Х, и если нет, то на этом собеседование заканчивается, при том, что ты работал с фремворками A, B, C, D и т.д. И изучение фреймворка X у тебя займет времени меньше, чем необходимо для вхождения в проект.
Очень много компаний ищут либо уже готовых специалистов, либо кодеров. А развивать и тянуть человека до уровня специалиста могут позволить себе только единиицы.
Очень много компаний ищут либо уже готовых специалистов, либо кодеров. А развивать и тянуть человека до уровня специалиста могут позволить себе только единиицы.
Фреймворк фреймворку рознь. Питоновский фласк изучить можно за день-два. Но без реального опыта разработки на нём, знания самого фреймворка мало что дадут.
Ситуации тоже бывают разные. Например, уволился человек, который писал какую-то часть проекта или проект на фреймворке X. Нужно срочно найти замену. Никто не станет рисковать, и брать человека без опыта, лучше сразу найти знающего специалиста. Если же есть команда, но требуются лишние руки, то часто принимают людей даже без знания языка, лишь бы был обучаем. А в конце испытательного срока всё встанет на свои места.
Почему-то народ упорно не разделяет понятия «освоить синтаксис» и «изучить язык». Освоить синтаксис языка и его основы можно за одни выходные — это «да».
Но освоить Golang — это не так просто. Очень и очень часто я вижу код Golang, по которому сразу видно, на чем писал автор раньше: Java, PHP, C#… Попытки впихнуть чужеродные конструкции или абсолютное отсутствие мыслей о работе GC со своим кодом. Как итог получается рабочий и читаемый код на Golang, который жутко противоестественен и чаще всего медленный или опасный. Тут, как правило, и запихивание всего и вся в горутины, и изобилие типа interface, и использование unsave, и конечно же пренебрежение пакетом sync и количеством создаваемых ссылочных типов.
Нередко попадаются в руки «шедевры» на Golang, которые работают со скоростью PHP 5.6, если код переписать в лоб.
Это конечно лично мой опыт, но программисты, которые не допускают классических «гошных» ошибок (отлично перечислены «50 частых ошибок») получаются где-то через полгода, через год получается хороший разработчик на Golang.
На мой взгляд, легкость Golang обманчива. Он прост в основах, но не примитивен. Сделать на нем качественный продукт проще и быстрее, но с этим не справится «мясо».
У Роба Пайка была интересная мысль, что Golang похож на игру Го — простые правила, но в итоге вариаций партий в порядке больше, чем в шахматах, где правила намного сложнее. В Golang простые основы, но без умения программировать, без хорошей алгоритмической базы это не поможет неумелому «программисту».
У Golang хорошее будущее, поскольку он позволяем сместить акцент с освоение конкретного языка программирование, на изучение программирования в более общем смысле. Я не много времени трачу на сам кодинг, но продумывание api, архитектуры приложения и его алгоритмов — это тратит столько же времени, сколько и всегда. Программирование не становится примитивным от того, что язык программирования прост в своих основах.
Но освоить Golang — это не так просто. Очень и очень часто я вижу код Golang, по которому сразу видно, на чем писал автор раньше: Java, PHP, C#… Попытки впихнуть чужеродные конструкции или абсолютное отсутствие мыслей о работе GC со своим кодом. Как итог получается рабочий и читаемый код на Golang, который жутко противоестественен и чаще всего медленный или опасный. Тут, как правило, и запихивание всего и вся в горутины, и изобилие типа interface, и использование unsave, и конечно же пренебрежение пакетом sync и количеством создаваемых ссылочных типов.
Нередко попадаются в руки «шедевры» на Golang, которые работают со скоростью PHP 5.6, если код переписать в лоб.
Это конечно лично мой опыт, но программисты, которые не допускают классических «гошных» ошибок (отлично перечислены «50 частых ошибок») получаются где-то через полгода, через год получается хороший разработчик на Golang.
На мой взгляд, легкость Golang обманчива. Он прост в основах, но не примитивен. Сделать на нем качественный продукт проще и быстрее, но с этим не справится «мясо».
У Роба Пайка была интересная мысль, что Golang похож на игру Го — простые правила, но в итоге вариаций партий в порядке больше, чем в шахматах, где правила намного сложнее. В Golang простые основы, но без умения программировать, без хорошей алгоритмической базы это не поможет неумелому «программисту».
У Golang хорошее будущее, поскольку он позволяем сместить акцент с освоение конкретного языка программирование, на изучение программирования в более общем смысле. Я не много времени трачу на сам кодинг, но продумывание api, архитектуры приложения и его алгоритмов — это тратит столько же времени, сколько и всегда. Программирование не становится примитивным от того, что язык программирования прост в своих основах.
То же самое хотел сказать про простоту изучения.
Добавлю еще, если кому-то кажется, что Go не хватает ООП и наследования — значит Вы просто еще не освоили этот язык.
Если кажется, что основное нововведение Go — это горутины, то значит Вы еще не понимаете этого языка.
Часто говорят, что Go простой и потому неинтересный. Я скажу иначе — это революционный язык, который смог доказать, что язык, воплощающий множество современных концепций, может быть простым. Где сложность не мельтешит перед глазами, хотя и присутствует внутри.
Добавлю еще, если кому-то кажется, что Go не хватает ООП и наследования — значит Вы просто еще не освоили этот язык.
Если кажется, что основное нововведение Go — это горутины, то значит Вы еще не понимаете этого языка.
Часто говорят, что Go простой и потому неинтересный. Я скажу иначе — это революционный язык, который смог доказать, что язык, воплощающий множество современных концепций, может быть простым. Где сложность не мельтешит перед глазами, хотя и присутствует внутри.
Поддержу. Даже более того, скажу что go в принципе пригоден для более интересных задач, нежели написание просто бизнес-логики.
Проект, которым я занимаюсь, связан с обработкой видео на FPGA. И вы, возможно, удивитесь, но высокоуровневый софт в количестве 2-х утилит (для экспериментального образца устройства) изначально мы начали создавать на go. В набор функций софта в том числе входит веб-интерфейс, работа с памятью, работа с аппаратным кодеком, управление железом, передача данных, различные алгоритмы обработки видеоданных.
Пока я еще ни разу не пожалел о том, что go был выбран для разработки. И причин тому несколько.
Во-первых, он позволяет быстро прототипировать алгоритмы не отвлекаясь на синтаксические и прочие особенности непосредственно языка и библиотек.
Во-вторых, у него достаточно возможностей и быстродействия для общения с нижележащим железом.
В-третьих, имеются достаточно любопытные инструменты, позволяющие профилировать и оптимизировать софт.
Так вот по поводу синтаксической простоты языка — это преимущество в основном в начале работы в проекте — как при старте проекта, так и при добавлении новых участников разработки.
Далее куда более важно понимание архитектуры и логики проекта. И тут сам язык отступает на второй план. Без такого понимания неважно на каком языке вы пишите код — хоть на go, хоть на rust'е.
Так что мой вывод для топикстартера — учите любые языки, но в первую очередь лучше учитесь проектировать проекты, а затем уже программировать программы )
Проект, которым я занимаюсь, связан с обработкой видео на FPGA. И вы, возможно, удивитесь, но высокоуровневый софт в количестве 2-х утилит (для экспериментального образца устройства) изначально мы начали создавать на go. В набор функций софта в том числе входит веб-интерфейс, работа с памятью, работа с аппаратным кодеком, управление железом, передача данных, различные алгоритмы обработки видеоданных.
Пока я еще ни разу не пожалел о том, что go был выбран для разработки. И причин тому несколько.
Во-первых, он позволяет быстро прототипировать алгоритмы не отвлекаясь на синтаксические и прочие особенности непосредственно языка и библиотек.
Во-вторых, у него достаточно возможностей и быстродействия для общения с нижележащим железом.
В-третьих, имеются достаточно любопытные инструменты, позволяющие профилировать и оптимизировать софт.
Так вот по поводу синтаксической простоты языка — это преимущество в основном в начале работы в проекте — как при старте проекта, так и при добавлении новых участников разработки.
Далее куда более важно понимание архитектуры и логики проекта. И тут сам язык отступает на второй план. Без такого понимания неважно на каком языке вы пишите код — хоть на go, хоть на rust'е.
Так что мой вывод для топикстартера — учите любые языки, но в первую очередь лучше учитесь проектировать проекты, а затем уже программировать программы )
дайте, пожалуйста, ссылку на «50 частых ошибок» на Golang
Очень странная позиция, Антон. Начнем с того, что не «берем студентов и школьников и они пилят в проекте», а «берем студентов и школьников и учим их десять лет структурам данных и алгоритмам».
Простота building blocks системы вовсе не равносильна простоте творения. Скажем, английский язык куда проще русского а писать на нем куда приятнее и выразительнее. С этим многие не согласятся, давайте съедем на программирование.
Есть язык erlang. сложный. На нем ничего не написано.
Есть язык C++. Не такой сложный, на нем многое написали. Все работает неправильно.
Есть язык Java. Очень несложный. Все работает кое-как, написали много.
Есть язык Python. Очень простой. Написали много не работает почти ничего.
Есть язык PHP. Простой. Написали много. Что-то работает.
Есть язык Delphi. Простой. В принципе работает. Но вышел из употребления.
Есть язык С. На самом деле сложный. Систем написали сложных много. Но вышел из употребления.
Есть языка Scala. Сложнее Java, проще C++. Написали в последние годы много. Не работает вообще ничего.
Есть язык Lisp. Простой. Но не имеет аппаратной поддержки. Не написали вообще ничего.
Есть язык Closure. Взяли Lisp, сделали в 100 раз сложнее и убожественнее и все равно ничего не написали.
А язык go это замена С на рынке. Возможно, даже не go а его дальнейшие эволюции.
Еще раз простота инструмента — не гарантия простоты целевой системы.
А чтобы написать с челленджами и не быть мясом нужно:
1. Иметь язык который стройно создан и имеет дизайн в своей структуре. И все как минимум базовые библиотеки в большинстве случаев работают.
2. Знать алгоритмы и структуры данных. Программа — это алгоритмы и структуры данных.
Такие дела, Антон. Такие дела.
Простота building blocks системы вовсе не равносильна простоте творения. Скажем, английский язык куда проще русского а писать на нем куда приятнее и выразительнее. С этим многие не согласятся, давайте съедем на программирование.
Есть язык erlang. сложный. На нем ничего не написано.
Есть язык C++. Не такой сложный, на нем многое написали. Все работает неправильно.
Есть язык Java. Очень несложный. Все работает кое-как, написали много.
Есть язык Python. Очень простой. Написали много не работает почти ничего.
Есть язык PHP. Простой. Написали много. Что-то работает.
Есть язык Delphi. Простой. В принципе работает. Но вышел из употребления.
Есть язык С. На самом деле сложный. Систем написали сложных много. Но вышел из употребления.
Есть языка Scala. Сложнее Java, проще C++. Написали в последние годы много. Не работает вообще ничего.
Есть язык Lisp. Простой. Но не имеет аппаратной поддержки. Не написали вообще ничего.
Есть язык Closure. Взяли Lisp, сделали в 100 раз сложнее и убожественнее и все равно ничего не написали.
А язык go это замена С на рынке. Возможно, даже не go а его дальнейшие эволюции.
Еще раз простота инструмента — не гарантия простоты целевой системы.
А чтобы написать с челленджами и не быть мясом нужно:
1. Иметь язык который стройно создан и имеет дизайн в своей структуре. И все как минимум базовые библиотеки в большинстве случаев работают.
2. Знать алгоритмы и структуры данных. Программа — это алгоритмы и структуры данных.
Такие дела, Антон. Такие дела.
> Есть язык Closure. Взяли Lisp, сделали в 100 раз сложнее и убожественнее и все равно ничего не написали.
Во-первых, Clojure. Во-вторых, Apache Storm. Хорошее такое «ничего».
Могу ещё практически по каждому из пунктов накидать аналогичного — но всё же, я бы поостереглась использовать столь категоричные кванторы.
Во-первых, Clojure. Во-вторых, Apache Storm. Хорошее такое «ничего».
Могу ещё практически по каждому из пунктов накидать аналогичного — но всё же, я бы поостереглась использовать столь категоричные кванторы.
Есть язык erlang. сложный. На нем ничего не написано.
«Эрланг учится за две недели, за год можно выучить до 26 эрлангов.»
Написано на нём довольно много. Всё работает обычно 24/7, его для этих целей и создавали.
Ну и так по каждому пункту. Если уж писать аналогии, то более честные.
А язык go это замена С на рынке
С чего вы это взяли? Go ничему не замена, он сам по себе. Дальше каждый сам решает, что он заменит. Google, вот, взял его на замену С++ в основном.
Го решает свои задачи, Си свои…
Знаю несколько компаний, где демонов пишут на Го (и гордятся этим), но с таким же успехом их можно реализовать и на питоне, и на пхп. И очень многое зависит ИМХО от задачи, например: я обсчитываю стату и мне памяти на пхп не всегда хватает (думаю на питоне не хватит тоже). Реализую массивы на си и все в ажуре.
Другая ситуация: в рекламной сети нужно опросить удаленные агенты (на это уходит более 10-13 мс), быстро обсчитать кучу данных, которые хранятся в оперативке, вычислить оптимальный баннер и успеть отдать и уложится в 20 мс (требование партнеров). Опять же, приходится писать демона на Си, который общается с WEB мордой на пхп.
Знаю несколько компаний, где демонов пишут на Го (и гордятся этим), но с таким же успехом их можно реализовать и на питоне, и на пхп. И очень многое зависит ИМХО от задачи, например: я обсчитываю стату и мне памяти на пхп не всегда хватает (думаю на питоне не хватит тоже). Реализую массивы на си и все в ажуре.
Другая ситуация: в рекламной сети нужно опросить удаленные агенты (на это уходит более 10-13 мс), быстро обсчитать кучу данных, которые хранятся в оперативке, вычислить оптимальный баннер и успеть отдать и уложится в 20 мс (требование партнеров). Опять же, приходится писать демона на Си, который общается с WEB мордой на пхп.
Ээ, на erlange то не написали? А RabbitMQ?
varanio Не бойся и просто начни писать на Go.
UFO just landed and posted this here
вот я тоже читаю эти невероятные истории успеха осваивателей go за выходные и поражаюсь.
да, синтаксис можно за выходные выучить без проблем,
но с такими знаниями написать на языке что-то мало-мальски сложное вам не удастся.
и вряд ли «мясо» прямо так прибежит и начнет писать развесистые сетевые приложения или сложную конкуретную логику.
помимо какого-то мифического «знания языка», ИМХО, гораздо важнее опыт и базовые знания,
которые слабо зависят от синтаксиса языка и его сложности.
так вот, go как раз и позволяет делать достаточно сложные вещи с меньшим оверхедом на язык и его тонкости
да, синтаксис можно за выходные выучить без проблем,
но с такими знаниями написать на языке что-то мало-мальски сложное вам не удастся.
и вряд ли «мясо» прямо так прибежит и начнет писать развесистые сетевые приложения или сложную конкуретную логику.
помимо какого-то мифического «знания языка», ИМХО, гораздо важнее опыт и базовые знания,
которые слабо зависят от синтаксиса языка и его сложности.
так вот, go как раз и позволяет делать достаточно сложные вещи с меньшим оверхедом на язык и его тонкости
Мне, например, кажется что Go это грубо говоря аналог Kotlin. Интересный, маленький порог вхождения, и красивый синтаксис… Неужели это не так?
Нет. Kotlin на порядок выразительнее. Go это скорее такая Java 1 — ужасно топорная, но приносящая некоторые широко известные в узких кругах фичи широкой аудитории разработчиков.
Вот вам простой пример красивого синтаксиса Go
func FindRatesTo(rates []ExchangeRate, rateTo string) []ExchangeRate {
result := Rates {}
for _, r := range rates {
if (r.To == rateTo) {
result = append(result, r)
}
}
return result
}
usdRates := FindRatesTo(rates, «USD»)
И вот тоже самое на сложной Scala (Хотя на Котлине или Java8 тоже самое будет примерно):
val usdRates = rates.filter(_.to == «USD»)
func FindRatesTo(rates []ExchangeRate, rateTo string) []ExchangeRate {
result := Rates {}
for _, r := range rates {
if (r.To == rateTo) {
result = append(result, r)
}
}
return result
}
usdRates := FindRatesTo(rates, «USD»)
И вот тоже самое на сложной Scala (Хотя на Котлине или Java8 тоже самое будет примерно):
val usdRates = rates.filter(_.to == «USD»)
Согласен полностью. Отсутствие generics превращает рутину в… рутину. Можно набрать в проект много мяса, и быстро начать разрабатывать, только вот похоже, что БЕЗ мяса на Го не очень то и попишешь…
Многие зациклены на подобных примерах. И это понятно почему, обучение программированию начинается с алгоритмов и структур данных.
Имея опыт в 20 лет программирования, я со всей ответственностью могу сказать, что приведенный Вами пример во многих областях, где применяется Go, большая редкость. Да что мои слова, достаточно почитать проекты на гитхабе.
Хотя в принципе от хороших дженериков в Go не отказался бы. И Kotlin мне тоже очень нравится.
Имея опыт в 20 лет программирования, я со всей ответственностью могу сказать, что приведенный Вами пример во многих областях, где применяется Go, большая редкость. Да что мои слова, достаточно почитать проекты на гитхабе.
Хотя в принципе от хороших дженериков в Go не отказался бы. И Kotlin мне тоже очень нравится.
Из ваших слов следует, что Go не применяется в проектах обработки данных…
Да вообще в проектах где используются структуры данных.
Може тогда пояснить, в каких проектах удобно использовать Go?
Да вообще в проектах где используются структуры данных.
Може тогда пояснить, в каких проектах удобно использовать Go?
Советую внимательно прочитать мой комментарий. Т.е. никак не следует.
А чтобы понять в каких проектах удобно использовать Go можно воспользоваться вот таким поиском на гитхабе. И кстати, о данных. На том же гитхабе если воспользоваться поиском graph database и посмотреть на самый популярный проект, то это будет google/cayley. На чем написана? О сюрприз!
А чтобы понять в каких проектах удобно использовать Go можно воспользоваться вот таким поиском на гитхабе. И кстати, о данных. На том же гитхабе если воспользоваться поиском graph database и посмотреть на самый популярный проект, то это будет google/cayley. На чем написана? О сюрприз!
>Советую внимательно прочитать мой комментарий. Т.е. никак не следует.
Разве?
>Имея опыт в 20 лет программирования, я со всей ответственностью могу сказать, что приведенный Вами пример во многих областях, где применяется Go, большая редкость.
Я привел пример обычного фильра по коллекции. Это вообще банальный пример и применятся повсеместно. Т.е. из вашего камента следует, что на Go писать софт, где надо обрабатывать коллекции, не принято и это большая редкость.
Вот мне и инетересно, что это за софт такой, где не применяется обработка данных.
И да, поиск по гитхабу дает ответ на вопрос «на чем вообще пишут софт», но никак не отвечает на вопрос «где УДОБНО применять Go». Ибо даже написанный и рабочий проект не говорит о том, что выбранная технология именно удобна для этого. Зачастую понимание удобства приходит потом, но смысла переписывать уже особо нет. Или же выбранная технология не дает никаго удобства, она просто не хуже других.
Разве?
>Имея опыт в 20 лет программирования, я со всей ответственностью могу сказать, что приведенный Вами пример во многих областях, где применяется Go, большая редкость.
Я привел пример обычного фильра по коллекции. Это вообще банальный пример и применятся повсеместно. Т.е. из вашего камента следует, что на Go писать софт, где надо обрабатывать коллекции, не принято и это большая редкость.
Вот мне и инетересно, что это за софт такой, где не применяется обработка данных.
И да, поиск по гитхабу дает ответ на вопрос «на чем вообще пишут софт», но никак не отвечает на вопрос «где УДОБНО применять Go». Ибо даже написанный и рабочий проект не говорит о том, что выбранная технология именно удобна для этого. Зачастую понимание удобства приходит потом, но смысла переписывать уже особо нет. Или же выбранная технология не дает никаго удобства, она просто не хуже других.
И опять неправильно понимаете. Да вы почитайте код. Даже и базу данных возьмите какую-нибудь. Там небольшое алгоритмическое ядро а к ней большой-большой обслуживающий код. Т.е. чисто по соотношению строк тупого кода — его всегда гораздо больше. По разным причинам. Поэтому фильтр на appende вам мозоль нигде не натрет, это точно.
К хорошему привыкаешь. Попишешь на C# с его
Не напрягает, если бы для чего-то важного, тут как раз руками оптимальнее. А вот когда для одноразовой задачки язык заставляет писать тупые циклы, это неприятно.
myList.Where(...).GroupBy(...).OrderBy(...) и когда приходится что-то пописать на Си или Дельфи, думаешь: какое наказание, писать это всё руками.Не напрягает, если бы для чего-то важного, тут как раз руками оптимальнее. А вот когда для одноразовой задачки язык заставляет писать тупые циклы, это неприятно.
Ну, важно соотношение многих факторов. Я вот на haskell писал в 700 строк то, что на Go занимает 3000. Могу свой monad tutorial написать, т.к. знаю монады на уровне алгебры. И чего же это я от него отказался? А того отказался, что преимуществ больше — код легко читается, легко обслуживается, стандартная библиотека приятно удивляет, писать легко и приятно. Пусть и многословно.
Хотя противопоставлять C# я, конечно же, не стал бы: судя по тому, что я о нем слышал, очень хороший язык. Да и более зрелый, просто в силу возраста. Просто мне не доводилось на нем кодить. Думаю Go со временем нагонит, хотя Фицпатрик пугает консерватизмом в своих последних презенташках.
А насчет «где удобно» — да везде на серверах. Проблемы будут если большая и сложная предметка, по ней бы код генерить конечно, а не руками писать. Но я и тут нашел свой ответ чемберлену.
В целом согласен. Причем обычно именно опытные программисты соглашаются со мной что Go не топорный, а наоборот удивительно хорошо продуманный язык. Недаром его делают такие крутые старички как Керниган и Пайк, а также такие успешные в индустрии люди как Фицпатрик.
А то, что вы программируете на простом для освоения языке, никак не может сделать вас «мясом». Если же человек — мясо, то никакая scala не сделает его крутым программистом.
А то, что вы программируете на простом для освоения языке, никак не может сделать вас «мясом». Если же человек — мясо, то никакая scala не сделает его крутым программистом.
Тут речь не о том, «мясо» человек или нет. Речь о том, как на это смотрят работодатели. Им сказали: если у вас есть проект, который можно и нужно «закидать мясом», ведите его на Go. Соответственно, вакансии будут под это строиться. И если вы хотите «умный» проект, но ваш основной язык Go, то придётся долго искать.
А что почитать для изучения с 0?
На русском какие книги, форумы?
Просто хочу попробовать простейшие програмки.
И возможно ли делать простейшие exe с интерфейсом пользователя?
На русском какие книги, форумы?
Просто хочу попробовать простейшие програмки.
И возможно ли делать простейшие exe с интерфейсом пользователя?
Спасибо.
У меня Win 10
Ставлю Git в первый раз как правильно настроить при установке?
А что выбирать при установке инсталятора?
Git 2.8.1
Путь C:\Program Files\Git
На следующем пункте галки ставить все?
далее директорию в пуск оставляю как есть
На следующем этапе что выбрать?
На следующем этапе стиль что выбрать?
Конфигурация терминала Use Windows?
Конфигурация экста опций галки оставлять?
У меня Win 10
Ставлю Git в первый раз как правильно настроить при установке?
А что выбирать при установке инсталятора?
Git 2.8.1
Путь C:\Program Files\Git
На следующем пункте галки ставить все?
далее директорию в пуск оставляю как есть
На следующем этапе что выбрать?
На следующем этапе стиль что выбрать?
Конфигурация терминала Use Windows?
Конфигурация экста опций галки оставлять?
del
Такие вопросы тут не спрашиваются, если Win 10 и вообще нет навыков, то сначала понять бы как вообще Git работает (https://try.github.io/levels/1/challenges/1).
Установить Go (https://golang.org/doc/install), начать читать документацию, причём внимательно.
А потом можно и cmder (http://cmder.net/) скачать, раз окружение тяжело настроить
Установить Go (https://golang.org/doc/install), начать читать документацию, причём внимательно.
А потом можно и cmder (http://cmder.net/) скачать, раз окружение тяжело настроить
> Ну то есть выгода языка го для бизнеса понятна, а как насчет программиста? Какая мотивация на перспективу?
Никчемные мешки мяса — хотят стать чем то большим, ищут смысл их предназначения, там где его нет.
Просто писать продкашн код который полезен бизнесу — им не достаточно. Нужно обязательно кому то доказать свою псевдоэлитарность и креативность.
Никчемные мешки мяса — хотят стать чем то большим, ищут смысл их предназначения, там где его нет.
Просто писать продкашн код который полезен бизнесу — им не достаточно. Нужно обязательно кому то доказать свою псевдоэлитарность и креативность.
В чем-то я с автором согласен. Особенно это касается порога вхождения и большого количества специалистов. Пример: C# удобнее и прозрачнее Java'ы, эффективность среднего программиста выше => найти его легче => меньше ЗП. Это невыдуманная цепочка, я отталкиваюсь от ставок крупных контор-интеграторов — шарписты дешевее джавистов. И вполне возможно, что Go ждет то же самое…
пришлось немного повозиться
1. Скачал go1.6.1.windows-amd64.msi
2. Переменные среды
GOROOT=C:\Go\
GOPATH=C:\Users\Nikita
создал пуль как в статье C:\Users\Nikita\Go\src\golang-book\chapter2
запускаю cmd.exe
пробую узнать версию go перехожу в папку
cd C:\go\bin
далее go version
в ответ go version go1.6.1 windows/amd64
Значит все ок
пробую как в статье
создал файл main.go в C:\GOPATH\Go\src\golang-book\chapter2
и далее как в статье все наконец-то заработать через полтора часа. долго тупил с путём.
1. Скачал go1.6.1.windows-amd64.msi
2. Переменные среды
GOROOT=C:\Go\
GOPATH=C:\Users\Nikita
создал пуль как в статье C:\Users\Nikita\Go\src\golang-book\chapter2
запускаю cmd.exe
пробую узнать версию go перехожу в папку
cd C:\go\bin
далее go version
в ответ go version go1.6.1 windows/amd64
Значит все ок
пробую как в статье
создал файл main.go в C:\GOPATH\Go\src\golang-book\chapter2
и далее как в статье все наконец-то заработать через полтора часа. долго тупил с путём.
Такое ощущение что большинству профессиональных программистов не хватает цели ради цели.
Т.е. впихни в go функцию bf_eval() которая на вход будет принимать только brainfuck — все сразу язык полюбят, потому что можно выразить себя. А просто eval(2+2), это мы ещё на первом курсе проходили, так скучно. Почему не выбирать язык по задаче(если это аргументировано) — я не понимаю.
Ну т.е. в моей работе админом тоже хватает неприятных обязанностей, но плевать ядом на какой-нибудь libssl даже в голову не придёт.
Т.е. впихни в go функцию bf_eval() которая на вход будет принимать только brainfuck — все сразу язык полюбят, потому что можно выразить себя. А просто eval(2+2), это мы ещё на первом курсе проходили, так скучно. Почему не выбирать язык по задаче(если это аргументировано) — я не понимаю.
Ну т.е. в моей работе админом тоже хватает неприятных обязанностей, но плевать ядом на какой-нибудь libssl даже в голову не придёт.
Странно, но никто не удивляется, что профессональному водителю хочется водить спортивные или комфортабельные машины, а не разбитую копейку, профессиональный фотограф вряд ли захочет снимать мыльнецей даже если ему за заплатят больше. И только желания программистов писать хороший и эффективный код на языке который им нравится — блаж и глупость.
Конечно блажь и глупость.
Если водителю платят деньги за то чтобы он водил именно копейку — будь добр води. Вне работы можешь хоть пачками всякие феррари об стены бить.
Если фотографу платят деньги за то чтобы он снимал мыльницей (фетиш у заказчиков такой) — он будет снимать. Работа такая.
Если мне заплатят за то чтобы я FoxPro на OS/2 поднял — ну, подниму. Хотя я полуось уже не помню когда видел.
Так почему программисты воротят нос от того что им придётся писать на Go/VB/QBasic в рабочее время?
Не нравится водить/фоткать/поднимать/писать — ну так не работай, за спиной палач не стоит.
Если водителю платят деньги за то чтобы он водил именно копейку — будь добр води. Вне работы можешь хоть пачками всякие феррари об стены бить.
Если фотографу платят деньги за то чтобы он снимал мыльницей (фетиш у заказчиков такой) — он будет снимать. Работа такая.
Если мне заплатят за то чтобы я FoxPro на OS/2 поднял — ну, подниму. Хотя я полуось уже не помню когда видел.
Так почему программисты воротят нос от того что им придётся писать на Go/VB/QBasic в рабочее время?
Не нравится водить/фоткать/поднимать/писать — ну так не работай, за спиной палач не стоит.
Большая часть программистов стала программистами не по причине любви к большим деньгам, а по причине интереса к данному роду деятельности, странно пытаться применять к ним метод работы «от забора до обеда».
Между тем тот самый «челлендж» — это не более, чем обратная сторона тяги к программированию\исследованию и фактически является профессиональной чертой разработчика.
Между тем тот самый «челлендж» — это не более, чем обратная сторона тяги к программированию\исследованию и фактически является профессиональной чертой разработчика.
Не нравится водить/фоткать/поднимать/писать — ну так не работай, за спиной палач не стоит.
Вы в курсе что, скажем, слесарь-сантехник может зарабатывать в раза два больше чем админ? Вот представьте к вам придут и скажут иди работать слесарем мы денег вдвое заплатим. Пойдете?
Если водителю платят деньги за то чтобы он водил именно копейку — будь добр води. Вне работы можешь хоть пачками всякие феррари об стены бить.
Подойдите к гонщику Формулы 1 и предложите водить копейку даже за большие деньги или к чемпиоу мира по боксу и предложите поработать вышебалой. В обоих случая, вас в лучшем случае пошлют. Деньги это хорошо, но денеги это все-таки не все. Многие программисты могли бы пойти в 1С или САПР и получать зарабатывать возможно больше и легче (по крайне мере в первое время), но неужели вы считаете что деньги это вообще единственный критерий при выборе профессии?
Фотографу платят за результат. За фотографии соответствующего качества в соответствующий срок. Водителю тоже платят за результат — за то что бы доехать куда надо за нужное время и как вариант за нужное время и куда надо довезти пассажир или груз с нужным качеством поездки.
Съемка мыльницей просто затруднит получение нужного результата или сделает его невозможным. И фотографы используют профессиональную технику именно поэтому. Водитель такси на разбитой копейке вряд ли привлечет клиентов и уж точно не выиграет гонку или не перевезет аналогичный грузовику груз.
Человек, который демонстрирует процесс съемки мыльницей для удовлетворения фетишей заказчиков — это не фотограф, это в лучшем случае актер.
Может и языки программирования стоит оценивать с точки зрения эффективности достижения результата (включая дальшейшую поддержку и развитие)? Ведь все эти хитрые шаблоны проектирования и синтаксический сахар изобретаются для решения практических проблем, а не просто так.
Впрочем это в равной мере вопрос и вам и автору предыдущего комментария. Да и автору исходной статьи. Все-таки задача программиста — это создание программ решающих проблемы пользователей, а не абстрактная сложность или простота кода.
Съемка мыльницей просто затруднит получение нужного результата или сделает его невозможным. И фотографы используют профессиональную технику именно поэтому. Водитель такси на разбитой копейке вряд ли привлечет клиентов и уж точно не выиграет гонку или не перевезет аналогичный грузовику груз.
Человек, который демонстрирует процесс съемки мыльницей для удовлетворения фетишей заказчиков — это не фотограф, это в лучшем случае актер.
Может и языки программирования стоит оценивать с точки зрения эффективности достижения результата (включая дальшейшую поддержку и развитие)? Ведь все эти хитрые шаблоны проектирования и синтаксический сахар изобретаются для решения практических проблем, а не просто так.
Впрочем это в равной мере вопрос и вам и автору предыдущего комментария. Да и автору исходной статьи. Все-таки задача программиста — это создание программ решающих проблемы пользователей, а не абстрактная сложность или простота кода.
Собственно, очень интересно знать мнение тех, кто постоянно пишет на го, поделитесь плиз, что вас мотивирует на будущее.
Тем, что Go это единственный язык в индустрии, компилятор и синтаксис которого не мешают и никак не препятствуют решению задач, которые из года в год по мере роста опыта становятся всё труднее по своей природе. И позволяет строить архитектуры любой сложности, сложность которых также растёт вместе с опытом.
Old programs read like quiet conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler. Who’d have guessed sophistication bought such noise?
— Dick Gabriel
UFO just landed and posted this here
И корявые дженерики плохо, и отсутствие дженериков в Go плохо.
Нужны хорошие дженерики, как показано выше в комментариях
Нужны хорошие дженерики, как показано выше в комментариях
Теперь давайте поговорим о фильтрах. Если спросить у гугла, то выяснятся любопытные подробности:
1) Роб Пайк год назад набросал (я так понимаю на коленке) простенькую библиотеку, которая реализует концепцию apply/filter/reduce.
2) Комментарий самого Пайка в вольном переводе звучит так: «Я ЭТО не использую. И вам не советую».
3) Тем кого напрягает отсутствие встроенного в язык кейворда, можно посоветовать заглянуть внутрь функций: там все сделано достаточно близко к потрохам самого Go и даже при добавлении в стандартную библиотеку или даже сам язык — вряд ли сильно изменится.
4) Глядя на то, что имеем в итоге, становится ясно — проще цикла-фильтра пока ничего не придумали. Да и тот можно завернуть в красивую обертку при желании.
Ссылка на саму библиотеку от Роба Пайка
Ссылка на тестовый пример на Go Playground
1) Роб Пайк год назад набросал (я так понимаю на коленке) простенькую библиотеку, которая реализует концепцию apply/filter/reduce.
2) Комментарий самого Пайка в вольном переводе звучит так: «Я ЭТО не использую. И вам не советую».
3) Тем кого напрягает отсутствие встроенного в язык кейворда, можно посоветовать заглянуть внутрь функций: там все сделано достаточно близко к потрохам самого Go и даже при добавлении в стандартную библиотеку или даже сам язык — вряд ли сильно изменится.
4) Глядя на то, что имеем в итоге, становится ясно — проще цикла-фильтра пока ничего не придумали. Да и тот можно завернуть в красивую обертку при желании.
Ссылка на саму библиотеку от Роба Пайка
Ссылка на тестовый пример на Go Playground
Мне почему-то кажется, что рефлексия сильно замедляет процесс работы кода. Можно, конечно же, накрутить через неё всяких крутых штук, но тогда Вы получите что-то равно по скорости Руби, а ничего круче Руби с такой же скоростью придумать нереально.
Вывод — Го может принимать только не замедляющие его работу фичи, а значит рефлексия это то, что Пайк будет советовать не использовать.
Сравните эти идеи с идеями zero cost abstractions в рантайме — и получите, что Go это плохо спроектированный для функциональщины язык.
MyFilteredList = MyList.Where(item => item.field > 1)Нет тут рефлексии, всё определяется в compile-time.
MyFilteredList = MyList.Where(item => item.field > 1)
Вы точно уверены, что это Go код? В Go лямбды обозначаются не так:
func(item) bool {
item.field > 1
}Да и на Ruby это не похоже.
myFilteredList = myList.select{|i| i.field>1}Но, если вы взяли код из C#, то какое это отношение имеет к моему комментарию?
Тут смысл в том, что указанная sergey_k библиотека сделана с помощью рефлексии. Поэтому конечно все там будет медленно, да и Пайк совершенно ясно в своих статьях говорит, что рефлексией в Go пользоваться следует в ограниченном числе случаев.
Не имею ничего против compile-time. Даже более чем уверен, что рано или поздно в синтаксических конструкциях появится что-то подобное.
Мне пока неясен один момент: если реализация MyList подразумевает в основе своей работу с неким непростым хранилищем данных серьезного объема — как эта конструкция отработает в реальности?
Мне пока неясен один момент: если реализация MyList подразумевает в основе своей работу с неким непростым хранилищем данных серьезного объема — как эта конструкция отработает в реальности?
MyList должен быть такой, что по нему можно итерировать. В худшем случае получается цикл по всем элементам и вызов ф-ции из where для каждого элемента. В языках с дженериками и специализациями (в том же c#) могут быть специализации для особых типов MyList.
В реальности, при разработке этого синтаксиса для c#, Microsoft держал в уме сценарии работы с БД и вместе с этим синтаксисом одновременно выкатил пару ORM своей разработки. Например, если MyList — это lazy-коллекция из таблицы БД, будет сгенерирован SQL-запрос типа «select * from MyList where field > 1». Также есть трюки, позволяющие эффективное делать цепочки таких вызовов (
В реальности, при разработке этого синтаксиса для c#, Microsoft держал в уме сценарии работы с БД и вместе с этим синтаксисом одновременно выкатил пару ORM своей разработки. Например, если MyList — это lazy-коллекция из таблицы БД, будет сгенерирован SQL-запрос типа «select * from MyList where field > 1». Также есть трюки, позволяющие эффективное делать цепочки таких вызовов (
List.Where(item => item.field > 1).OrderBy(item => item.Name).First())Sign up to leave a comment.
Перспективы языка го для программиста