Согласен. Но все равно хочу увидеть задачу, в которой Go by design без дженерикс не справляется.
Вот, к примеру, хорошая реализация B-Tree, которая зачастую в других языках решается с помощью generics. По-моему, очень красиво и элегантно: godoc.org/bitbucket.org/santucco/btree
Согласен, что встроенные типы особым статусом наделены, но неспроста же.
Насчет generics и «commander и голова» — ну, это же не «Пайк единолично не хочет generics» :) Хочет же, хоть и неохотно ) Но не видит пока-что способа действительно красиво это сделать.
Я лично пока-что не понимаю, какой есть use-case, когда необходим generics. Те примеры, которые я видел решаются интерфейсами, а иногда через reflection (что не слишком красиво, согласен). Я продолжаю искать в реальных задачах способ наткнутся на ситуацию, когда упрусь в необходимость generics — но пока что этого не случалось, и адекватных ответов по этой теме я не видел. Люди, как правило, просто хотят решать задачу тем же путем, которым они привыкли в прошлых языках.
Это другая тема, это про точки с запятой. Опять же, это все в спецификации, которая читается целиком за час.
Формально, в Go используются точки с запятой, но они не обязательны — лексер их сам расставляет, руководствуясь простыми правилами. В данном примере лексер ставит точку с запятой после ')' — поэтому и ошибка. Этот пример, кстати, там же, в спеке языка :) golang.org/doc/effective%5Fgo.html#semicolons
С главной страницы mosh: The Mosh package should be installed on both the client and server. Please find your platform below for installation instructions.
Ну вы еще порты ssh-сервера меняйте при работе из дому и с работы, и возмущайтесь ) В вашем варианте, конечно, не будет работать.
Такое можно реализовать с использованием внешнего сервера (тогда и NAT-панчинг можно красиво сделать), но это уже совсем другой сервис.
Это не проблема, а реальный юз-кейс. Если вы мне скажете, что никто не дает коллегам/другу логин/пароль на свой тестовый сервер для какой-то быстрой помощи, а заводит отдельного юзера каждый раз — то я вам не поверю, хотя, безусловно, соглашусь, что это было бы правильнее. Но люди такие люди же :)
См. ответ выше. habrahabr.ru/post/243651/#comment_8134843
В общем случае, безусловно. Для каждого пользователя свой UNIX-юзер, да. Но в том частном случае, с которым приходится иметь дело мне — это внутренний сервер, который реинсталлится каждый раз после билда проекта, и регулярно приходится заходить то одним, то другим людям, проверять/исправлять какие-то вещи. В силу определенных (хардварных) причин, мне код проще запускать и тестить прямо на сервере, что я регулярно и делаю. Создавать на каждого члена компании UNIX-пользователя, просто чтобы screen не перехватывался? Ну, не, спасибо, тем более что этот сервер в такой же конфигурации должен идти в продакшн и там менеджмент доступа вообще отдельным путем регулируется.
Mosh все-таки тут правильнее этот вопрос решает, с точки зрения security. Неудобнее иногда, но правильнее.
Извините, что игнорирую ваш сарказм, но расскажу один момент.
Когда я только познакомился с Go, самым странным для меня было то, что компилятор выдавал ошибку на неиспользованный импорт или неиспользованную переменную. И, более того, изменить это поведение нельзя было — ну там, какой-то опцией командной строки например.
WTF, подумал я — что за ограничение свободы слова и посягательство на базовые права человека? Да какое право они имеют мне диктовать, оставлять или нет неиспользованные импорты? Хочу и оставляю, я свободный человек! Да и вообще, это же офигеть, как неудобно. Что это они вообще придумали, идиоты. Я то знаю как нужно — я же привык как в других языках.
Прошел год, когда я словил себя на мысли, что не представляю, во что бы превратились списки импортов в моих программах, не будь это ошибкой компиляции. Наверное в то же, что и в типичных C++ программах в больших проектах. Более того, сейчас я понимаю, насколько это решение было правильным, хоть и казалось спорным по-началу.
Роб Пайк, кстати, рассказывал подробно по всем дизайнерским решениям языка — что за этим стояло, сколько месяцев или лет они обсуждали все возможные решения и почему пришли именно к такому. У меня есть огромное доверие к Кену и Робу — думаю, их опыт в программировании и работы с разными программистами и командами больше моего в огромное количество раз, и когда мне вначале, еще не испробованная фича кажется «неправильной» — скорее всего, я просто сноб и боюсь изменить свои убеждения. Но хорошо, что я не боюсь :) Те вещи, за которые я бы раньше на C++ или Python даже не взялся, сейчас я пишу за пару дней. Чего и вам желаю. :)
Если вы чаще, чем раз в месяц меняете туда сюда видимость методов, то, наверное да, Go вам не подходит. А если еще и «я так не привык» для вас затмевает все остальные преимущества, которые дает Go (и которые даже не затрагивались в этой статье) — то тем более )
Товарищи минусующие, я, конечно, понимаю, что у вас есть свое представление о дешевизне копирования и я даже готов послушать ваши аргументы, но эта тема поднималась в Go-комьюнити с 2009-го года не раз и ответ на вопрос «использовать поинтер или значение в качестве ресивера» даже вынесено в FAQ — рекомендую познакомиться: golang.org/doc/faq#methods_on_values_or_pointers.
Для тех кому вправду интересно: pointer в качестве ресивера используется если значение наверняка нужно менять или если тип ресивера — большая структура. Для базовых и простых типов, которые не нужно менять — рекомендуется использовать значение. Там есть еще парочка моментов, которые стоит учитывать, но в целом как-то так.
В примере статьи значение менять не нужно и тип очень простой. Минусуйте дальше :)
Я думаю, это правильное решение. Допустим, разрешили built-in типам добавлять свои методы. Что будет, если чей-то package, включенный в мой код переопределяет метод String() для int? Или два разных package-а, реализуют одинаковый метод для built-in типа. Как такие вещи разруливать?
Кроме того, новое поведение у типа — подразумевает, что этот тип представляет некую новую сущность. Ну там «источник данных», а не просто «строка». Тоесть это разные сущности, и правильнее дать им разные имена.
Да, gopher у них удачный очень вышел. Мне больше намного нравится, чем Google-овский — на конференции dotGo в Париже раздавали. Оно такое чувство, будто его камазом сбили и переехали ) А этот крутой. Я его, кстати, подарил девочке из Будапешта, которая движок Prezi писала — она на Lviv IT Arena делала презентацию, как Go в Prezi используется, и это была одна из самых мимимишных презентаций, которые я видел )))
Не пошел мне screen, сколько не пытался к нему привыкнуть.
Да и тут он не замена: проблему лагов не решает, и реконнект прозрачный не сделаешь.
Кроме того — вот взять «восстановление сессии»: в mosh я просто открываю ноут и жду 10 секунд и могу работать. Со screen, как я понимаю — мне нужно заново переконнектиться, ввести пароль (если по паролю), запустить screen. Это в затратах на телодвижения — 0 vs 10 :) В бесконечное количество раз, тоесть )))
Вот, к примеру, хорошая реализация B-Tree, которая зачастую в других языках решается с помощью generics. По-моему, очень красиво и элегантно:
godoc.org/bitbucket.org/santucco/btree
Насчет generics и «commander и голова» — ну, это же не «Пайк единолично не хочет generics» :) Хочет же, хоть и неохотно ) Но не видит пока-что способа действительно красиво это сделать.
Я лично пока-что не понимаю, какой есть use-case, когда необходим generics. Те примеры, которые я видел решаются интерфейсами, а иногда через reflection (что не слишком красиво, согласен). Я продолжаю искать в реальных задачах способ наткнутся на ситуацию, когда упрусь в необходимость generics — но пока что этого не случалось, и адекватных ответов по этой теме я не видел. Люди, как правило, просто хотят решать задачу тем же путем, которым они привыкли в прошлых языках.
Acme гляну, интересно )
Формально, в Go используются точки с запятой, но они не обязательны — лексер их сам расставляет, руководствуясь простыми правилами. В данном примере лексер ставит точку с запятой после ')' — поэтому и ошибка. Этот пример, кстати, там же, в спеке языка :)
golang.org/doc/effective%5Fgo.html#semicolons
Такое можно реализовать с использованием внешнего сервера (тогда и NAT-панчинг можно красиво сделать), но это уже совсем другой сервис.
См. ответ выше. habrahabr.ru/post/243651/#comment_8134843
Mosh все-таки тут правильнее этот вопрос решает, с точки зрения security. Неудобнее иногда, но правильнее.
Когда я только познакомился с Go, самым странным для меня было то, что компилятор выдавал ошибку на неиспользованный импорт или неиспользованную переменную. И, более того, изменить это поведение нельзя было — ну там, какой-то опцией командной строки например.
WTF, подумал я — что за ограничение свободы слова и посягательство на базовые права человека? Да какое право они имеют мне диктовать, оставлять или нет неиспользованные импорты? Хочу и оставляю, я свободный человек! Да и вообще, это же офигеть, как неудобно. Что это они вообще придумали, идиоты. Я то знаю как нужно — я же привык как в других языках.
Прошел год, когда я словил себя на мысли, что не представляю, во что бы превратились списки импортов в моих программах, не будь это ошибкой компиляции. Наверное в то же, что и в типичных C++ программах в больших проектах. Более того, сейчас я понимаю, насколько это решение было правильным, хоть и казалось спорным по-началу.
Роб Пайк, кстати, рассказывал подробно по всем дизайнерским решениям языка — что за этим стояло, сколько месяцев или лет они обсуждали все возможные решения и почему пришли именно к такому. У меня есть огромное доверие к Кену и Робу — думаю, их опыт в программировании и работы с разными программистами и командами больше моего в огромное количество раз, и когда мне вначале, еще не испробованная фича кажется «неправильной» — скорее всего, я просто сноб и боюсь изменить свои убеждения. Но хорошо, что я не боюсь :) Те вещи, за которые я бы раньше на C++ или Python даже не взялся, сейчас я пишу за пару дней. Чего и вам желаю. :)
Для тех кому вправду интересно: pointer в качестве ресивера используется если значение наверняка нужно менять или если тип ресивера — большая структура. Для базовых и простых типов, которые не нужно менять — рекомендуется использовать значение. Там есть еще парочка моментов, которые стоит учитывать, но в целом как-то так.
В примере статьи значение менять не нужно и тип очень простой. Минусуйте дальше :)
Кроме того, новое поведение у типа — подразумевает, что этот тип представляет некую новую сущность. Ну там «источник данных», а не просто «строка». Тоесть это разные сущности, и правильнее дать им разные имена.
Авторы, разумеется, сами над проблемой думают и планируют в mosh 1.3 чего-то придумать.
Да и тут он не замена: проблему лагов не решает, и реконнект прозрачный не сделаешь.
Кроме того — вот взять «восстановление сессии»: в mosh я просто открываю ноут и жду 10 секунд и могу работать. Со screen, как я понимаю — мне нужно заново переконнектиться, ввести пароль (если по паролю), запустить screen. Это в затратах на телодвижения — 0 vs 10 :) В бесконечное количество раз, тоесть )))