Я понял не так. Я думаю, эксперты нужны для того, чтобы судья приняла во внимание их экспертное заключение. А будет оно базироваться на 100 аккаунтах или на миллионе на трудозатраты судьи по идее не повлияет. А перепроверять экспертов вроде не входит в полномочия судьи, она то может в этом вообще не разбираться, т.к. это не её область.
Да дело то не в отрицании. Просто язык тем лучше, чем больше он даёт механизмов защиты от этой кривизны и лени. И тем хуже, чем легче словить последствия от них.
Тем не менее, через 3 месяца после выхода Go 1.0 она уже была. А сколько лет с релиза D 1.0 прошло до включения в GCC?
а дженерики не раскалывают сообщество
Потенциально раскалывают. Но языку уже 10 лет, теперь он может себе позволить хоть несовместимую версию 2.0 выпустить, это уже не сильно заафектит его популярность.
Всё, что вы перечислили, на популярность не влияет вообще.
Поделитесь тогда своим мнением почему D настолько непопулярен?
В этом я могу вас понять. Но D, к сожалению, закопали сами разработчики, сначала расколов и так небольшое комьюнити на Phobos и Tango прям аккурат в момент релиза 1.0. А потом и полгода не прошло, как бросились вторую мажорную версию языка пилить. В довершение ко всему этому ещё и не уловили тренд на OpenSource. Тем самым отложив интеграцию с gcc лет на 10.
А программисту хочется хотя бы иметь ощущение, что авторы ЯП понимают, что они делают, и придерживаются хоть какой-то генеральной линии. Возможно, в этом и причина популярности Go. Да, генеральная линия его разработчиков - треш и угар, но они неукоснительно её придерживались, как минимум, 8 лет.
Ну, там основной смысл в том, что вы можете начать думать в терминах процессов - на верхнем уровне всё есть процесс. Когда это реализуется на уровне отдельной библиотеки, то такого кайфа уже не будет. Так как авторы других библиотек далеко не всегда будут поддерживать эту модель.
Я вообще за минимальный и тупой язык
Как же вы с Haskell уживаетесь? Я бы не назвал его ни минималистичным, ни тупым.
Лично мне распределённый STM больше понравился.
По-моему, DSTM, как и CloudHaskell, тоже давно заброшен.
Жаль. Строго типизированные акторы были бы интересны. Но это, наверно, на уровне самого языка надо делать, т.к. объём работ большой и авторы отдельной библиотеки на одном энтузиазме далеко не уедут.
Во-первых, некорректно с темы фреймворков на тему самих языков перепрыгивать.
А во-вторых, с каждым коментом ты закапываешь D всё глубже и глубже. Я интереса ради зашёл в их багзиллу ??♂️ И что я вижу: 4719 issues found. Видимо, с тех пор как ты заходил в issues tracker своего любимого ЯП, он успел ещё почти 2k issues набрать.
И чего ты сравниваешь с GHC, который себя как исследовательский проект позиционирует? Или ты посмотрел на Elixir с его 26 issues и обосрался от зависти? xD Можешь даже 249 issues от Erlang/OTP приплюсовать. А то вы со своим D даже хипстерский Crystal в 4 раза по кол-ву issues обогнали.
Блин, чувак, пиши себе на D, никто ж тебе не запрещает.
Но нафига ты влез в ветку сравнения Elixir c Haskell, которые оба уже много лет имеют веб-фреймворки, до которых vibe.d как до луны что по фичам, что по стабильности (88 issues у Yesod и 26 у Phoenix). А ты пытаешься нас убедить, что 384 - это мало. Нет, это over дохера для веб-фреймворка. Ладно бы это только цифра была, ты зайди на Github, посмотри, что по большинству issues никакого обсуждения нет, им даже не присвоены никакие метки. С таким подходом к разработке кол-во issues будет только расти год от года и сколько там среди них багов никто не знает, потому что их никто тупо даже не читает. Что это, если не заброшенность?
Зрелому проекту частые релизы ни к чему.
Зрелому то да, только vibe.d до зрелости пока не добрался. Где пруфы, что авторы принципиально не планируют версию 1.0? На их сайте я такого тезиса не увидел. Или вы просто выдаёте желаемое за действительное?
К сожалению, да. Чтобы код был понятнее, он должен быть лаконичным и отделять happy path от всего остального, а если ещё DSL можно сделать, то в итоге может и правда даже ребёнок поймёт. Вот только в Go нельзя by design сделать ни то, ни другое, ни третье.
Я описал много пунктов, а не только скорость компиляции. Они экономят время в совокупности, а не по отдельности.
Описали. Но все эти пункты применимы и к другим языкам. У Go тут нет какой-то уверенной позиции по этим пунктам. Разве что по простоте деплоя он в лидерах.
А взять тот же инструментарий, гоферы в итоге определились с управлением зависимостями? Я на нём писал то всего год, и то 5 разных вариантов видел, и это в то время, когда почти каждый ЯП уже шёл со стандартизированным менеджером зависимостей. Так что по инструментарию Go где-то в рядах догоняющих с большой тягой к изобретению велосипедов.
Ещё раз: выше в коментах вспомнили, что именно скоростью компиляции авторы Go оправдывают свои спорные решения. Никто вроде не утверждал, что они в этом преуспели.
А по поводу статьи, вы специально искали график, где D выглядит лучше всего?)
Ну, и вы всерьёз считаете активным проект, у которого между версиями 0.9.4 и 0.9.5 проходит примерно год? А 384 issues намекают, что стабильность весьма условна. На половину из них даже никакого ответа нет, что на практике, скорее всего, значит что нет ни одного человека, который занимается поддержкой этого проекта за зарплату.
Кхм, Haskell меня нисколько не пугает. А вот то, что вы пытаетесь тут всунуть какой-то сырой фреймворк, разработка которого зачахла года 4 назад так и не дойдя до стабильной версии, выглядит неумно.
Получилась опять ситуация, что язык применяют не для того, где он силён. Быстрая компиляция больших кодовых баз для микросервисов как раз роли не играет.
Согласен, в диапазоне $40-$70/час вполне можно найти хороших специалистов, которые возможно и 100+ часов в месяц смогут уделить, а не как агенство.
А что не так? Слабая статическая типизация)
Я понял не так. Я думаю, эксперты нужны для того, чтобы судья приняла во внимание их экспертное заключение. А будет оно базироваться на 100 аккаунтах или на миллионе на трудозатраты судьи по идее не повлияет. А перепроверять экспертов вроде не входит в полномочия судьи, она то может в этом вообще не разбираться, т.к. это не её область.
Ух-ты, целых 100 аккаунтов? Просто космический объём работы и потрясающая репрезентативность исследования!!!1!1!
Ну вот, сначала 64 Mb - неинтересно, а потом удивляетесь, почему Java за прожорливость недолюбливают.
Да дело то не в отрицании. Просто язык тем лучше, чем больше он даёт механизмов защиты от этой кривизны и лени. И тем хуже, чем легче словить последствия от них.
Тем не менее, через 3 месяца после выхода Go 1.0 она уже была. А сколько лет с релиза D 1.0 прошло до включения в GCC?
Потенциально раскалывают. Но языку уже 10 лет, теперь он может себе позволить хоть несовместимую версию 2.0 выпустить, это уже не сильно заафектит его популярность.
Поделитесь тогда своим мнением почему D настолько непопулярен?
Могу предложить вам попробовать Elixir. Сообщество дружелюбное, теоркат знать не требуют, инструментарий удобный: iex, mix, hex.
В этом я могу вас понять. Но D, к сожалению, закопали сами разработчики, сначала расколов и так небольшое комьюнити на Phobos и Tango прям аккурат в момент релиза 1.0. А потом и полгода не прошло, как бросились вторую мажорную версию языка пилить. В довершение ко всему этому ещё и не уловили тренд на OpenSource. Тем самым отложив интеграцию с gcc лет на 10.
А программисту хочется хотя бы иметь ощущение, что авторы ЯП понимают, что они делают, и придерживаются хоть какой-то генеральной линии. Возможно, в этом и причина популярности Go. Да, генеральная линия его разработчиков - треш и угар, но они неукоснительно её придерживались, как минимум, 8 лет.
Да, они. Но к JVM у меня какая-то личная неприязнь. Всё, что я на ней видел, имело медленный старт и дико жрало память.
Возможно, в Akka.NET тоже что-то подобное есть, но до F# я пока не добрался)
Ну, там основной смысл в том, что вы можете начать думать в терминах процессов - на верхнем уровне всё есть процесс. Когда это реализуется на уровне отдельной библиотеки, то такого кайфа уже не будет. Так как авторы других библиотек далеко не всегда будут поддерживать эту модель.
Как же вы с Haskell уживаетесь? Я бы не назвал его ни минималистичным, ни тупым.
По-моему, DSTM, как и CloudHaskell, тоже давно заброшен.
Жаль. Строго типизированные акторы были бы интересны. Но это, наверно, на уровне самого языка надо делать, т.к. объём работ большой и авторы отдельной библиотеки на одном энтузиазме далеко не уедут.
Во-первых, некорректно с темы фреймворков на тему самих языков перепрыгивать.
А во-вторых, с каждым коментом ты закапываешь D всё глубже и глубже. Я интереса ради зашёл в их багзиллу ??♂️
И что я вижу: 4719 issues found. Видимо, с тех пор как ты заходил в issues tracker своего любимого ЯП, он успел ещё почти 2k issues набрать.
И чего ты сравниваешь с GHC, который себя как исследовательский проект позиционирует? Или ты посмотрел на Elixir с его 26 issues и обосрался от зависти? xD
Можешь даже 249 issues от Erlang/OTP приплюсовать.
А то вы со своим D даже хипстерский Crystal в 4 раза по кол-ву issues обогнали.
Блин, чувак, пиши себе на D, никто ж тебе не запрещает.
Но нафига ты влез в ветку сравнения Elixir c Haskell, которые оба уже много лет имеют веб-фреймворки, до которых vibe.d как до луны что по фичам, что по стабильности (88 issues у Yesod и 26 у Phoenix). А ты пытаешься нас убедить, что 384 - это мало. Нет, это over дохера для веб-фреймворка. Ладно бы это только цифра была, ты зайди на Github, посмотри, что по большинству issues никакого обсуждения нет, им даже не присвоены никакие метки. С таким подходом к разработке кол-во issues будет только расти год от года и сколько там среди них багов никто не знает, потому что их никто тупо даже не читает. Что это, если не заброшенность?
Зрелому то да, только vibe.d до зрелости пока не добрался. Где пруфы, что авторы принципиально не планируют версию 1.0? На их сайте я такого тезиса не увидел. Или вы просто выдаёте желаемое за действительное?
К сожалению, да. Чтобы код был понятнее, он должен быть лаконичным и отделять happy path от всего остального, а если ещё DSL можно сделать, то в итоге может и правда даже ребёнок поймёт. Вот только в Go нельзя by design сделать ни то, ни другое, ни третье.
Описали. Но все эти пункты применимы и к другим языкам. У Go тут нет какой-то уверенной позиции по этим пунктам. Разве что по простоте деплоя он в лидерах.
А взять тот же инструментарий, гоферы в итоге определились с управлением зависимостями? Я на нём писал то всего год, и то 5 разных вариантов видел, и это в то время, когда почти каждый ЯП уже шёл со стандартизированным менеджером зависимостей. Так что по инструментарию Go где-то в рядах догоняющих с большой тягой к изобретению велосипедов.
Ещё раз: выше в коментах вспомнили, что именно скоростью компиляции авторы Go оправдывают свои спорные решения. Никто вроде не утверждал, что они в этом преуспели.
А по поводу статьи, вы специально искали график, где D выглядит лучше всего?)
Вы, видимо, веткой изначально ошиблись, т.к. Haskell предлагали мне. А вы с чего то решили пованговать что я видел, а что нет.
Под "зачахла" я подразумеваю, что активность коммитов существенно снизилась, см. график по ссылке, продублирую вам её: https://github.com/vibe-d/vibe.d/graphs/contributors
Ну, и вы всерьёз считаете активным проект, у которого между версиями 0.9.4 и 0.9.5 проходит примерно год? А 384 issues намекают, что стабильность весьма условна. На половину из них даже никакого ответа нет, что на практике, скорее всего, значит что нет ни одного человека, который занимается поддержкой этого проекта за зарплату.
Кхм, Haskell меня нисколько не пугает. А вот то, что вы пытаетесь тут всунуть какой-то сырой фреймворк, разработка которого зачахла года 4 назад так и не дойдя до стабильной версии, выглядит неумно.
Как тут выше вспомнили, Go создан таким невыразительным ради того, чтобы быстрее компилировать огромные кодовые базы.
А маленькую программульку почему бы не написать на более выразительном языке? Кода получится в 2-3 раза меньше и объять взглядом его будет ещё проще.
Получилась опять ситуация, что язык применяют не для того, где он силён. Быстрая компиляция больших кодовых баз для микросервисов как раз роли не играет.