otto не ставит себе задачу заменить vagrant, а лишь упростить работу с ним и с остальными инструментами от hashicorp.
Ну, на данный момент otto и vagrant вполне себе существуют параллельно, но в будущем otto будет использоваться как единый тул (с вагрантом под капотом, но люди ничего об этом знать не обязаны). Этому даже отдельная страничка посвящена на сайте otto: www.ottoproject.io/intro/vagrant-successor.html
vault — мне как php разработчику не совсем ясно как с ним работать, кроме вызова консольных команд не обнаружил никакого api. Продукт стабильный, но очень ограниченный в этом плане.
Он не ограниченный, просто сфера ваших занятия не пересекается с тем, для чего делался vault. Основные клиенты vault — это большие организации, сложные инфраструктуры, энтерпрайз и так далее, где количество людей, машин, сервисов и требований велико, и чем больше, тем очевидней необходимость в решении, подобном Vault.
API у него через HTTP: vaultproject.io/docs/http/index.html
nomad на данный момент не увидел смысла в его практическом применении.
Сейчас главная драка идет уже не за контейнеры, а за средства для их оркестрации. Микросервисы (и не очень мини-) пишут все налево и направо, но правильно менеджить и управлять этим все также сложно. Есть масса решений — Mesos(+Marathon), Docker Swarm, Kubernetes, AWS ECS и тд, но у всех еще большой порог вхождения и высокая сложность. Nomad — это еще один игрок на этом рынке, и хотя еще совсем необкатанный, но с очень мощным бэкграундом (он основан на трех научных работах от Google и Беркли), и выглядит очень приятно, особенно на фоне других решений.
Этот ползунок был с самого начала, GOGC называется. Он определяет порог роста хипа, после которого нужно запускать GC. GOGC=100 (по умолчанию) означает, что если размер кучи на 100% больше (тоесть, вдвое) количества занятой реальной памяти, то нужно запускать GC.
Вот тут подробнее есть: habrahabr.ru/post/265833 и тут m0sth8.github.io/runtime-1/#1
Ну и еще в подкасте golangshow.com периодически внутренности обсуждаются.
Вот именно что, я спрашиваю как изготавливаются параметризированные контейнеры, а вы мне в ответ о шаблонах и паттернах которые человек не хочет или не может пересмотреть по мере того, как он пытается освоить новый язык.
Наоборот — я говорю, что злоупотребление пустым интерфейсом в Go есть признак борьбы с языком, а вы все увели в контейнеры.
Мне интересно как живётся без дженериков.
Отлично живётся. Go не дает стимулы создавать ложные текучие абстракции там где они не нужны. Как говорят. плохая абстракция намного хуже дупликации кода, и именно поэтому в отдельных случаях в Go нормально повторить код для двух разных типов, хотя это и происходит крайне редко.
Как вам уже написали, авторы Go не против дженериков, но они не знают, как их реализовать, чтобы это ни было также отстойно, как в других языках. Это не политическое решение, а техническое. Дженерики — это всегда компромисс и усложнение языка, и наивность некоторых, что достаточно «больше поработать над компилятором» тут никак не меняет ситуацию.
Ну и напоследок, возможность писать типизированные алгоритмы в Go есть, и зачастую там где людям хочется «дженериков» в Go можно подойти к проблеме иначе. Но я вижу, у набежавших хейтеров сама мысль об этом вызывает неадекватную реакцию. Поэтому еще раз оставлю ссылку на интересный документ, который поможет прояснить ситуацию «Как это в Go нет дженериков, но на нем пишут большие и качественные продукты».
И мой вопрос — как часто вы пишете свои типизированные контейнеры? Можно в % от основного кода, или сколько раз в день, или сколько типизированных контейнеров вы написали в прошлом месяце?
Я вам так скажу — то время, которое вы потратили на написание комментариев тут, достаточно, чтобы освоиться с Go и написать какой-нибудь реальный код. Как только для вас процесс написания кода станет важнее процесса «освоения языков», вы поймете всё, о чём я писал выше :)
Ну а я о чём. И без генериков пишут, и на го пишут. Только какой ценой? ;)
Ну вот, когда вы захотите узнать ответ на этот вопрос, а не навязать свое представление, тогда и будет шанс не тратить время на пустые бессмысленные дискуссии :)
Нет, вы все равно определяете функцию Less() для каждой комбинации «тип элемента» + «вид сортировки». Swap() и Len() всегда одинаковы для слайсов(массивов), но в более сложных вариациях тоже может понадобится переопределение и вам тоже придется это делать.
Ну и если вы три строчки экономии в данном конкретном примере готовы променять на все остальные преимущества, которые дает Go, то мне понятно, почему D так и не нашел свою нишу.
Высоконагруженный производительный софт и на С пишут
Да на всем пишут. Вопрос — какой ценой.
параметрический полиморфизм в том или ином виде есть в подавляющем большинстве современных статических языков
Класс, что ж народ так страдает тогда на этом «подавляющем большинстве современных статических языков», раз у вас там идиллия?
Все эти «споры ни о чем» не отменяют одного — статья не имеет ни одного выдерживающего критики аргумента. Можно честно признаваться в том, что ты привык к чему-то, или больше душа лежит — но нести откровенную чушь, выставляя это «минусами языка» уж явно не стоит. Ради своей же репутации.
Слушайте, ну не видите для себя надобности в языке — не учите. Зачем тратить свое и чужое время, чтобы сообщать, что для ваших задач какой-то язык не подходит?
Есть много студентов и программистов, которым языки интересны сами по себе. Go тут не игрок, Go создан для тех, кому интересней писать реальный продакшн код, быстро и качественно, чем возиться с выразительными языками.
Конкретная проблема — реализация типизированных контейнеров
В программировании обычно другие проблемы. Какие типы и структуры данных использовать — это уже решение разработчика. Вам же менеджер не приносит ТЗ с текстом «сделай мне типизированный контейнер, и желательно именно так, как ты привык в своем любимом языке».
Так как контейнер-то сделать?
Ответил выше. В третий раз буду игнорировать вопрос.
Таки в каких случаях пихать можно, а в каких – чужие паттерны?
Вы ждете ответ на такой вопрос в одном комментарии?
Мне странно объяснять такие простые вещи — сам по себе кастинг интерфейсных типов это ни плохо, ни хорошо. Иногда он нужен, чаще — нет. Любой (со средним соображением), кто не полениться потратить вечер-два, чтобы освоить основу языка, поймет, где нужно «пихать», а где не нужно.
Рад, что мы пришли к консенсусу. Собеседники, которые не могут что-то понять, пока не попробуют, а не пробуют, потому что не могут понять, это да, проблема.
Ad-hoc polymorphism что ли? Не ново. При определённой широте взглядов можно сюда хоть duck typing из питона или плюсовых шаблонов, хоть всякие ML'ные семейства систем типов приписать.
Ясно, вы все ищете ответ на вопрос «какая есть новинка в Go, которую невозможно сделать в другом языке». Если для вас на данном этапе развития, как разработчика, это главный фактор для выбора языка, то, Go, конечно же вам не подходит. Go о другом и для другого.
Пожалуйста, каков тогда «правильный» способ это сделать в Go?
Что «это»? Вы же понимаете, что речь не об отдельных контейнерах, а о массе других случаев, когда народ продолжает мыслить «дженериками» и пытаться их пхать везде где нужно и не нужно. Или не понимаете?
Ну так давайте тогда называть вещи своими именами — вы пишете на языке Х, где жить нельзя без дженериков. Где-то вы читаете, что в другом языке дженериков (в привычном для вас понимании) нет, но при этом Google, Dropbox, CloudFlare и куча других компаний пишут высоконагруженный производительный софт.
Вместо того, чтобы задаться вопросом «Ага, видимо в других языках что-то немного иначе, чем в моем любимом Хаскеле, видимо нужно изучить вопрос повнимательнее» вы решаете просто «Язык — отстой, потому что там нет того и в том виде, к чему я привык в Хаскеле».
Ну окей, что тут скажешь.
Паттерны — это плохо, особенно, когда человек не способен за их рамки выходить. Есть даже известная фраза, что «Паттерны — это баг-репорт на ваш язык».
То что вы описали — это не «общая идея», а «наиболее отличительная черта». У Go есть три таких черты:
— уход от концепции управления потоками
— convention over configuration — единый формат (go fmt) и тд
— объекты, определяемые поведением (interfaces)
Но единственная задача которую преследует язык — это облегчать ежедневный труд программистов. Он не берет отдельными фишками, он берет всем дизайном языка и тулинга в целом. Это сложно понять, пока не пишешь на Go, соглашусь.
Ну, на данный момент otto и vagrant вполне себе существуют параллельно, но в будущем otto будет использоваться как единый тул (с вагрантом под капотом, но люди ничего об этом знать не обязаны). Этому даже отдельная страничка посвящена на сайте otto: www.ottoproject.io/intro/vagrant-successor.html
Он не ограниченный, просто сфера ваших занятия не пересекается с тем, для чего делался vault. Основные клиенты vault — это большие организации, сложные инфраструктуры, энтерпрайз и так далее, где количество людей, машин, сервисов и требований велико, и чем больше, тем очевидней необходимость в решении, подобном Vault.
API у него через HTTP: vaultproject.io/docs/http/index.html
Сейчас главная драка идет уже не за контейнеры, а за средства для их оркестрации. Микросервисы (и не очень мини-) пишут все налево и направо, но правильно менеджить и управлять этим все также сложно. Есть масса решений — Mesos(+Marathon), Docker Swarm, Kubernetes, AWS ECS и тд, но у всех еще большой порог вхождения и высокая сложность. Nomad — это еще один игрок на этом рынке, и хотя еще совсем необкатанный, но с очень мощным бэкграундом (он основан на трех научных работах от Google и Беркли), и выглядит очень приятно, особенно на фоне других решений.
Вот тут подробнее есть: habrahabr.ru/post/265833 и тут m0sth8.github.io/runtime-1/#1
Ну и еще в подкасте golangshow.com периодически внутренности обсуждаются.
Со скрипом, да.
Наоборот — я говорю, что злоупотребление пустым интерфейсом в Go есть признак борьбы с языком, а вы все увели в контейнеры.
Отлично живётся. Go не дает стимулы создавать ложные текучие абстракции там где они не нужны. Как говорят. плохая абстракция намного хуже дупликации кода, и именно поэтому в отдельных случаях в Go нормально повторить код для двух разных типов, хотя это и происходит крайне редко.
Как вам уже написали, авторы Go не против дженериков, но они не знают, как их реализовать, чтобы это ни было также отстойно, как в других языках. Это не политическое решение, а техническое. Дженерики — это всегда компромисс и усложнение языка, и наивность некоторых, что достаточно «больше поработать над компилятором» тут никак не меняет ситуацию.
Ну и напоследок, возможность писать типизированные алгоритмы в Go есть, и зачастую там где людям хочется «дженериков» в Go можно подойти к проблеме иначе. Но я вижу, у набежавших хейтеров сама мысль об этом вызывает неадекватную реакцию. Поэтому еще раз оставлю ссылку на интересный документ, который поможет прояснить ситуацию «Как это в Go нет дженериков, но на нем пишут большие и качественные продукты».
docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#
И мой вопрос — как часто вы пишете свои типизированные контейнеры? Можно в % от основного кода, или сколько раз в день, или сколько типизированных контейнеров вы написали в прошлом месяце?
Ну вот, когда вы захотите узнать ответ на этот вопрос, а не навязать свое представление, тогда и будет шанс не тратить время на пустые бессмысленные дискуссии :)
Ну и если вы три строчки экономии в данном конкретном примере готовы променять на все остальные преимущества, которые дает Go, то мне понятно, почему D так и не нашел свою нишу.
Да на всем пишут. Вопрос — какой ценой.
Класс, что ж народ так страдает тогда на этом «подавляющем большинстве современных статических языков», раз у вас там идиллия?
Все эти «споры ни о чем» не отменяют одного — статья не имеет ни одного выдерживающего критики аргумента. Можно честно признаваться в том, что ты привык к чему-то, или больше душа лежит — но нести откровенную чушь, выставляя это «минусами языка» уж явно не стоит. Ради своей же репутации.
В вашем примере на D то же самое по сути, только более ограничено.
Есть много студентов и программистов, которым языки интересны сами по себе. Go тут не игрок, Go создан для тех, кому интересней писать реальный продакшн код, быстро и качественно, чем возиться с выразительными языками.
В программировании обычно другие проблемы. Какие типы и структуры данных использовать — это уже решение разработчика. Вам же менеджер не приносит ТЗ с текстом «сделай мне типизированный контейнер, и желательно именно так, как ты привык в своем любимом языке».
Ответил выше. В третий раз буду игнорировать вопрос.
Вы ждете ответ на такой вопрос в одном комментарии?
Мне странно объяснять такие простые вещи — сам по себе кастинг интерфейсных типов это ни плохо, ни хорошо. Иногда он нужен, чаще — нет. Любой (со средним соображением), кто не полениться потратить вечер-два, чтобы освоить основу языка, поймет, где нужно «пихать», а где не нужно.
Рад, что мы пришли к консенсусу. Собеседники, которые не могут что-то понять, пока не попробуют, а не пробуют, потому что не могут понять, это да, проблема.
Ясно, вы все ищете ответ на вопрос «какая есть новинка в Go, которую невозможно сделать в другом языке». Если для вас на данном этапе развития, как разработчика, это главный фактор для выбора языка, то, Go, конечно же вам не подходит. Go о другом и для другого.
Метод? Вам достаточно в цикле переложить:
Если сильно часто делаете подобное (интересно, зачем?), то можете создать функцию-обертку, да.
Ответил выше.
Что «это»? Вы же понимаете, что речь не об отдельных контейнерах, а о массе других случаев, когда народ продолжает мыслить «дженериками» и пытаться их пхать везде где нужно и не нужно. Или не понимаете?
Вместо того, чтобы задаться вопросом «Ага, видимо в других языках что-то немного иначе, чем в моем любимом Хаскеле, видимо нужно изучить вопрос повнимательнее» вы решаете просто «Язык — отстой, потому что там нет того и в том виде, к чему я привык в Хаскеле».
Ну окей, что тут скажешь.
То что вы описали — это не «общая идея», а «наиболее отличительная черта». У Go есть три таких черты:
— уход от концепции управления потоками
— convention over configuration — единый формат (go fmt) и тд
— объекты, определяемые поведением (interfaces)
Но единственная задача которую преследует язык — это облегчать ежедневный труд программистов. Он не берет отдельными фишками, он берет всем дизайном языка и тулинга в целом. Это сложно понять, пока не пишешь на Go, соглашусь.