Я использовал как MobX, так и Redux. И ещё кучу менеджеров состояний. И мне было всегда удобно, не превращался код в кашу. Что я делаю не так? Как закривить руки, чтобы прямо в кашу?
Спасибо за статью. Радостно видеть, что кто-то задумается даже сегодня о такой "скучной" вещи, как качество программного обеспечения. Было интересно, а ниже... много критики. Почему? Надо попытаться разобраться в проблеме, которую поднимаете. А не просто повторять цитаты хейтеров различных стеков или красивые идеи, которые куда глубже, чем кажется.
Первое, что бросается в глаза сходу - вы преподносите Electron как нечто плохое, хотя забывается - View у программного обеспечения может быть любой, он может банально меняться от платформы к платформе. И для того, чтобы ПО было качественным - функциональная часть должна быть отвязана от пользовательского интерфейса. Который вообще должен быть не более, чем клиентом. Заменяемым. И проблема первая, которая чаще вредит качеству - это смешение логики, а не использование конкретного средства визуализации. Ну то есть, в большей части случаев проблема не в платформе - а в прокладке между клавиатурой и креслом, которая пихает в клиент - явно не свойственную ему задачу. Так и получается "интерфейс", который весит какие-то не реальные значения. А потом ещё обрастает очень странной, не свойственной ему логикой. И становится ещё хуже.
Второе, все про тот же Electron. Это прожорливость. Внезапно, он потребляет меньше того же JavaFX. И чуть больше того же Swing. И при этом подходит под другой важный критерий ваш же - скучная технология. Внезапно, надо поискать способ древнее, чем использовать в качестве клиента банальный web, с анимацией через JS. По существу, кроме различного "сахара" - Electron не дает ничего. Плюс вопрос потребления - это ведь вопрос не столько платформы (она "ест" по современным меркам не так, чтобы и много), а человека. Фреймворки? Не используйте и все. Может для вас станет открытием - но и на TUI можно потреблять гигабайты. Отношение к electron-софту сформировано чаще всего из специалистов низкой компетенции... простите, но это как судить о "битлах" по тому как "Вася напел". Быть может стоит обратиться к хорошим практикам, улучшению квалификации, а не охоту на платформы-ведьмы? Правда, тут есть "но", не требуется решать задачу забивания гвоздей для полки архитектором с 40 летним стажем. Полка выйдет золотая. Поэтому - качество специалистов (и их стоимость) должны коррелировать с решаемой проблемой.
Третье, про потребителей и качество - не совсем так. Потребителя волнует возможность решить проблему. Программа - лишь инструмент. И если цена решения выше наличия проблемы - он не будет её решать. Достаточно, чтобы решение было дешевле, чем "ничего не делать". И это нормально. Вы ведь не всегда едите здоровую еду, хотя какой-нибудь фаст-фуд не более чем аналог некачественного софта. Да, вредит. Но проблему решает, пусть и с последствиям. И тут надо честно сказать - это проблема владельца продукта, найти как сделать продукт лучше с полезной для меня точки зрения. Если для меня не проблема +500мб потребления, то я не буду платить за понижение потребления. Ведь продукт и так решает мои проблемы. Иными словами - качество должно быть необходимое, а не сферическое и в вакууме. Внезапно, вероятно любимый вами Linux отнюдь не высокого качества. А написан он, кстати, на стабильных и скучных технологиях.
Четвертое, про скучный стек. Простите, а что вы под ним понимаете? Если всякие Python - то сразу, мимо. Мало того, это виртуальная машина (которая может работать с нюансами в зависимости от реализации и платформы), так ещё и с кучей зависимостей на каждый чих (а внутри этих зависимостей может быть вообще Си-бибиотека, которая будет собираться под каждую платформу). Хорошо, тогда предположим С++/С? Языки с UB, без внятного управления пакетами и с разницей поведения в зависимости от ОС? Такой себе выбор. Rust (он по многим критериям подошел бы)? Новодел, который не имеет серьезного промышленного применения (молод), да ещё и не скучный. Java? Кушает много, опять же - ВМ с кучей версий, куча библиотек. Даже приведенная картинка с базами... вы будете смеяться, но какая-нибудь Mongo может в части кейсов использования вести себя куда предсказуемее PGSQL, а в части наоброт. Иными словами - "скучный" стек так же исходит от решаемой проблемы. И он может оказаться вполне себе нестабильный, потребляющим массу ресурсов и так далее. Потому, что использовать что-то другое окажется просто финансово не выгодно и этот вот "идеальный" софт никому не будет нужен за такую цену.
Пятое, долговечное ПО. Красивая идея, которая в реальном мире недостижима. Дело в том, что вы можете гарантировать сборку софта через 20 лет только если все зависимости лежат в проекте и только одна команда занимается правкой этого кода. И то - нет гарантии, что через 20 лет компилятор "пережует" такое легаси. Ведь языки тоже будут меняться. И да, лучше писать все библиотеки самому, так вы гарантируете отсутствие внезапных багов. К чему я? Вы готовы за блокнот платить по паре тысяч баксов? А почему нет? Ведь вы получите долговечное ПО! А знаете почему нет на самом деле? Цена проблемы куда ниже цены софта. Долговечное ПО стоит применять только там,где это оправдано финансово. Где цена ошибки куда выше, а проблему не решать - нельзя. В остальных случаях - это работа, которая не будет оплачиваться. Я не думаю, что многие программисты согласятся работать бесплатно всю жизнь. Все же семья, дети, свои потребности. Коммунизм не настал. А open source просто другой способ монетизации.
Шестое, про пример про фото. А оно надо многим? Если я хочу сделать фото себя с друзьями на даче или застолья семьи - зачем мне вот все это, про искусство? Вы смешиваете понятия - профессионального продукта и потребительского. Сегодня человеку не нужно чего-то сложнее телефона с ИИ, который заменит часы фотошопа. Фотографу нужна навороченная аппаратура, куча знаний и прочее. Ведь он делает фото не для положить в альбом и "вспомнить молодость", а делает некий предмет публичного потребления, который аналогично картине - должен нести смысл, а не просто сохранять обрывок эмоций, понятный только паре людей. Или, вы предлагаете, перед тем как снимать утренник ребенка пройти курсы оператора и режиссера, и снимать на проф. аппаратуру?
Седьмое, проблемы "ужаса творческих людей". Вы сами давно смотрели сложное и умное кино, аналогичные книги и так далее, вместо пинаемого в статье "нетфликса" или просмотра спортивной программы\блога или просмотра мемчиков? Не так, чтобы эпизодами, а вместо и постоянно. Мало того, я могу предположу, что филолог будет в ужасе от вашей статьи (хотя бы из-за бедности языка, кучи заимствованных и жаргонных слов). Поэтому - не стоит обвинять массы. Вы тоже вносите лепту, исходя из ваших же суждений. Но, это все не так важно на самом деле. Вы ведь не будете копать яму для дачного туалета с применением нанороботов. А чтобы поставить его - вы не привлечете архитектора, а для отделки дизайнера. Почему? Потому, что вы решаете проблему "сходить в туалет на даче", а не "погадить, думая о вечности". И да, если человек хочет отдохнуть - смотреть фильмы Траковского, Джармуша или Линча такая себе идея. А вот крутить ему на фоне "проходняк с нетфликса" (который даст возможность мозгу отдохнуть) - вполне себе нормальное решение. Внезапно, мозгу нужен отдых и постоянная его работа приведет только к проблемам. То есть, опять же... надо идти от проблемы.
Восьмое, про хороший интерфейс. Хороший интерфейс должен быть понятным. А красота - понятие субъективное. Кому-то приятнее видеть TUI, кому-то строки в терминале. А кому-то подавай свистелки и перделки. Но от формы он не становится плохим. Он станет плохим, если вы не будете понимать как решить свою задачу - то есть найти решение своей проблемы. И эргономика должна быть впереди всего остального. Тут, конечно все осложнено пользовательским опытом, но тут имеем, что имеем. И надо работать над привитием. Кстати, интересный момент - красивый интерфейс может быть неудобным. Когда-то, если помните, были популярны файловые менеджеры, которые в 3D показывали файловое пространство. Красиво, эффектно. Пользоваться было невозможно. Потому и умерло.
Восьмое, мнение творческих людей не всегда для человека. Мало того, чаще всего - это решения из разряда "наркоманами для инопланетян". Давайте проведем эксперимент. Я могу гарантировать, что большую часть потребностей ваших вполне себе решит банальный Emacs с плагинами. Предлагаю вам настроить и пользоваться только им пару месяцев. Это качественное ПО, которое покроет большую часть потребностей. Это и плеер, и меседжер, и браузер, и почтовый клиент... да что угодно, чего не хватает - можете реализовать на ELisp, который стабилен и предсказуем. Я даю гарантию, что вы будете заменять вот это хорошее решение, на более простые и плохие - даже если пойдете на это. Почему? Решение проблемы будет слишком дорогим. Вам придется освоить сложный софт, освоить язык ELisp, освоить интерфейс, поменять привычки... И вы до сих пор этого не сделали, замечу.
Написание компилятора - не самый худший выбор для изучения С или С++. И что-то изучать в процессе реализации интересной для тебя задачи - вполне нормально. Торвальдс не имел 15 лет работы на Си к моменту написания первой версии ведра ведь тоже. Да и получил много критики, кстати, по поводу реализации. Не ошибается, по-факту, только тот, кто ничего не делает. Да и у большинства ярых критиков статистически достижений куда меньше, чем твой компилятор.
Нужна будет помощь с написанием прикладных библиотек или чем-то еще, обращайся. Буду рад подключиться и помочь. С самим компилятором маловероятно - не моя тема, сильно не моя. Хотя и интересует.
Offtopic: позор Хабру. Статья явно написана под влиянием личных претензий. Есть куча open source решений далеко не лучше компилятора Rave, но автора статьи они не трогают. И почему-то мы не увидим подобной статьи о других продуктов от того же критика. Без юродства, критика полезная по сути, а вот подача - какое-то "гнобление" конкретного человека. Ведь можно было даже в статья показать ка сделано не правильно, как можно улучшить, а добить - как сделать хорошо. От этого остается послевкусие, что критик сам не может сделать то, о чем пишет.
Хм. Статья интересная, спасибо. Критика местами понятна. А теперь к критике статьи.
По большому счету, а почему бы автору статьи не присоединиться к разработке и не показать как надо? Я понимаю энтузиаста, который пилит Rave, ответ "я делаю компилятор в одиночку" далеко не глуп. Человек вероятнее всего сконцентрирован на внесение фич, а не правильности кода компилятора. В целом, это нормальный продуктовый подход. Если условная версия 1.0 будет интересна сообществу - имеет смысл все это прибрать. Нет, так зачем страдать? Опыт в любом случае (ценный) получен. Да, можно было многое сделать лучше. Но работающий компилятор представляющий какую-то законченную версию языка лучше, чем красиво недописанный продукт.
В целом - автор статьи столько потратил сил на чтение кода и написание этого материала, что мог бы вполне сделать пару MR. Open Source жеж, не нравится что-то - поправь и кинь MR. Не думаю, что автор языка будет против.
Замечу. Автор Rave не продает его, за разработку денег не получает. И не обязан бросаться все исправлять и менять свой road map. И не обязан вносить любые правки по замечаниям. И критика его за это - странная.
А так, по существу такой критики. Забавно получается - автор Rave написал какой-то работающий компилятор своего языка. Пусть он и плохо написана, но работает. А языка автора статьи для оценки его компилятора... не помню, чтобы видели. Nuff said.
Спасибо за статью, в любом случае. Объем впечатлил. А вот содержание... давайте по-порядку.
Глобальные проблемы с которыми столкнулось человечество на текущий момент
Это то, чтоб было еще с ХХ века. И мало что поменялось. И проблема тут не в том, что кто-то ангажирован (в капиталистическом строе - это не решаемая в принципе проблема), а скорее в не корректной идентичности каждой приведенной. А последнее ведет к тому, что определяется не корректно основополагающая причина. А их, на самом деле, всегда две - предельно низкий уровень образования основной массы людей и ориентация капиталистической идеологии на индивидуальные достижения группы, а не общие достижения социума. При повышении уровня образования и привитии правильных ценностей - все перечисленные проблемы имеют достаточно тривиальные решения, кстати говоря.
Отказ от денежного обращения и внедрение нейросетей как попытка ослабить влияние глобальных проблем
Не решает ни одну проблему. Деньги как таковые - это универсальный инструмент определения ценности для последующего обмена. Таким образом мы определяем, что условные пять кило гречки равный условным 20 литрам воды. Деньги - это инструмент, а негативные его факторы - проблема людей, а не инструмента.
Особенно наивно думать, что отказ от денег может помочь в борьбе с неравенством или помочь с понижением уровня стресса.
К сожалению не вспомню кто проводил эксперимент (давно читал работу), но был ученый, который пытался сделать общество без денег на отдельно взятом острове. Итогом стало изобретение социумом аналога денег, т.к. нужен был универсальный инструмент для определения ценности при обмене. А проблемы которые были - они так и остались. Ведь они в природе человека, а не в бумажках.
Ну а использование нейросетей... ознакомьтесь с трудами Жана Фреско, у него были подобные суждения - он предлагал управления отдать компьютерам. Если коротко - не взлетело и не взлетит. Нейросети - это не интеллект, а его эмуляция. И серьезные решения отдавать им - это примерно как стрелять себе в ногу.
Перейдём к конкретике. Концепция Глобального Социального Контракта
А у вас тут еще больше воды, чем было до. Забавно то, что ваши "очки" - суть те же деньги. Просто вы их обозвали иначе, чтобы было не как у клятых капиталистов. А по факту - назовите хоть горшком, сути не меняет. В не ту проблему предлагаете решать.
На а улучшения жизни за счет ИИ... вот я могу сказать как специалист по анализу - если взять всю историю планеты, то мы придем к выводу, что человеческое общество создало куда больше проблем и наносило исключительно вред. Как вы будете защищать ИИ от мысли, что проблема планеты - это человечество? Предполагаю - тут вы ничего нового не придумаете и предложите аналоги законов робототехники Азимова. Но есть одно "но" - нейросети не могут мыслить и предлагать то, чего не знают. Без человека вы не обойдетесь.
Переход к новой системе ценностей
Вот тут уже появляются светлые идеи, которые вы, правда, тоже переизобрели. Один из известнейших романов об этом - "Город" К. Саймака, который повествует как раз о необходимости человечеству новой философии, которая бы вывела цивилизацию из тупика. Очень рекомендую к прочтению - прекрасное произведение, которое наталкивает на мысли. Конечно, какой-то конкретики в нем вы не найдете (за ней лучше обратиться к философским течениям), но итог к которому придет цивилизация с современными ценностями и нормами - описаны вполне не плохо. Кстати, проблемы вы так же оттуда могли бы почерпать, там куда лучше детерменированны причины и следствия, чем у вас.
В тексте - опять просто вода. Как организовать процесс формирования ценностей? Какие критерии полезности они должны нести и какие методы оценок требуется использовать? Как они должны интегрироваться в новые поколения? А как в старые? Как мотивировать общества переходить на них? Какая система противовесов должна вводится для индивидов, которые не принимают эту систему?
В целом, по тексту - вы сделали плохую компиляцию идей утотопистов (вроде упомянутого Ж. Фреско), коммунистов (отказ от денег, равенство - можно взять любого философа этого направления, начиная с Маркса) и приправили чуть техношизой (ИИ, "компутеры" - правда тут вторите упомянтому Фреско часто). Плюс набрали ворох пугалок в качестве основания у фантастов-антиутопистов, причем так и не смогли определиться в итоговом влиянии проблемы на конкртеные показатели (их в принципе нет). И похоронили немногие светлые идеи просто океанами воды, сведя их к красивым лозунгам.
Для того, чтобы менять мир к лучшему - надо решать реальные проблемы. А это не лозунги "давайте жить правильно", а конкретные шаги по идентификации понятия "правильно", интеграции его во все системы жизни.
Если хотите менять мир - начинайте, у вас есть все для этого. Сформируйте лозунги в цели, цели разбейте на задачи. И с этим уже - показывать людям, чтобы вдохновить и найти единомышленников. Покажите окружающим пример - люди потянутся, если идеи на самом деле будут стоящие.
А пока... просто очень много наивного текста на Хабре, уровня канала РЕН-ТВ, где для полного комплекта не хватает только Рептилоидов.
Для использования вместо Pure C - надо выкидывать GC и как-то давать интерфейс работы с памятью. Это сложно и противоречит изначальной цели Go - быть простым.
Для использования вместо С++ - не гибокий, мало возможностей (в том числе работы с памятью) и слабая реализация элементов ООП.
Плюс конского размера бинари и невозможность использовать через какой-нибудь FFI.
А вот как альтернатива Python и подобным языкам для того, чтобы плодить web - вполне себе альтернатива, если нужна асинхронщина а в NodeJS не хочется, а в Erlang не можется.
Очень интенсивно недавно развивался, потом как-то затухло.
Мало с ним поработал. Так, для пары простых микросервисов заюзал. Не могу ничего плохого сказать - это один из череды "простых и производительных" языков, вроде Julia, Crystal, Elixir и им подобных. Чаще всего видел их позиционирование как "работа над ошибками Python/Ruby/$LanguageName". Но тут, думаю, проблемой стало позиционирование - Crystal и Elixir взяли такой хороший курс на Web, Julia пытается прижиться в наших ML и числодробилок...
А вот куда Nim приложить предлагают, я так и не смог понять. Были, на сколько помню, потуги его затащить в gamedev, но вроде как не взлетело (хотя могу ошибаться).
Как альтернатива Python... а зачем, если есть Julia? Последнее время она и в web стала хорошо уметь (прекрасный фреймворк Genie уже до 5 версии обновили), имеет свои notebooks (Pluto.jl) для датасаентистов и т.п. Плюс из неё можно делать вызовы Python-кода.
Любой язык, чтобы стать успешным, должен быть инструментом конкретной ниши, для конкретной ЦА. Надеюсь Nim найдёт своих пользователей. Язык то очень даже не плохой.
Ничего не имею против Elixir. Более того могу сказать, он мне нравится.
Я имел ввиду то, что берётся для сравнения в статье изначально более требовательный к погружению стек. Всё же вхождение в Erlang-окружение (а у Elixir много инструментов и подходов от "родителя") сложнее, чем JVM или NodeJS. Но да, Elixir не корректно "выбрасывать" из сравнения. Это язык, который на порядок лучше Golang и он вполне себе хорошая альтернатива для миграции с Ruby/Python.
Про Rust... это специфичный инструмент. Я не могу сказать, что он плохой. Он как раз требовательный, сложный и функциональный. Кстати, уж если заговорили про него - его экосистема ничуть не хуже Golang, а местами даже куда лучше. И если уж сравнивать компилируемые языки между собой - то оставить без внимания его было бы не верно. Как не верно и "забыть" сравнивать Golang с Dlang, который умеет всё то же самое, что и первый и ещё сверху много приятного (нормальные ошибки, дженерики, шаблоны, etc.). Последний, кстати, не на много сложнее изучить, чем Golang. В том числе за счёт достаточно простого и понятного синтаксиса.
За ссылку на рейтинг спасибо, как раз хотел посмотреть каков тренд и менялся ли).
Про продакшен код за пару дней изучения - не удивительно. Именно такую задачу и ставил Google. Вернее, чтобы "даже питонисты могли быстро влиться и начать писать производительный код". Это делает Golang хорошим инструментом, но не хорошим языком.
Далее - Scala, Rust, Julia иди Crystal не эзотерические. Вполне себе инструменты. NodeJS тем более. Но сравнивают почему-то с Elixir. Niff said.
Про экосистему. Я уже писал, что она хороша там где была интересна Google. Найдите ODM для той же ArangoDB или Couchdb. А это вполне промышленный СУБД. И нет никакого в этом go way (в случае с Golang - это просто агитка, чтобы не писали сложного, инструмент не заточен), есть интерес основного инвестора. И именно поэтому почти всегда не портит - есть пакеты не интересные корпорации, а остальные - на свой страх и риск.
Про IDE, извините. Я настраивал 7 лет назад Emacs под Dlang, Python и NodeJS. Потом накрутил еще модули для Julia. Вопрос инструмента и рук.
Про init.py - скорее особенность и условие. Тут не хорошо и не плохо. Функция main у K&R тоже условность.
Про инструментарий вообще не в кассу. Julia - похоже. На Nodejs еще раньше сделали, чем Golang. Древний Common Lisp умеет очень многое (сложно найти чего нельзя сделать через снапшот). Дебаг легких потоков - Erlang. А так из промышленного удобный инструментарий и IDE - идеи Smalltalk никто не отменял. Другое дело, что порог входа инструментов - низкий. Правда их функциональность соответствует порогу входа.
Проблемы со сборками... Давайте не сравнивать Python , а возьмем Dlang или Rust. У них их тоже нет. И C они редко дергают. Иными словами - мало удивительного. Плюсы компилируемого языка. И минусы. Так как на С давно уже это написано, зачем велосипедить? Ну а так - если честно, я встречал проблемы с зависимостям. В Python только под Wondows. И были проблемы с установкой каких-то пакетов под форточкамит и в Golang. Хотя может за 4 года, что я не прикасался - что-то поменялось.
Ага. Видел я в продакшене обработку. Примерно на уровне Python'новского try/catch+pass. Если ошибка - упасть, если не ошибка - делать. Другая крайность if-hell с диким уровнем вложений. Без нормальной типизации и единой точки обработки. Ничем не лучше callback hell, лапша.
Линейный код никто не запрещает писать на Python, Erlang, JS (asunc/await, generators) и кучи других языков. Собственно не линейный код свойственный языкам где кроме вызова callbacks нет ничего. А таких уже почти нет. Про лямбды - for тоже лямбда). Ничего, живут с ней все.
Пункт 7 можно применить к любому языку. Вообще любому. Главное, чтобы команда применяла best practice и работала с code style. Говнокодить можно на любом языке. Что чаще всего и делают. А сказки переносимости опыта - идеальная ситуация, которой не будет скорее всего.
Универсальность сериализации есть в любом языке, который проповедует "код есть данные". На Lisp 1 еще. В ФП не сложнее, как и в ООП. Чуть побольше пары строк, но не rocket science . Smalltalk, Julia, Ruby...примеров можно найти при желании много. Даже древний TCL позволял (своими руками такое делал). Но может не понял задачу какую имеете ввиду.
Стабильность - Erlang, CL, Racket, Clojure, Scala, Haskell...да даже Nodejs (мой сервис работал один несколько лет без передёргивания), ну в самом деле. Тут ничего нового. Erlang тот же в целом идеал на счет стабильности - что-то стало работать не так, пристрели и заспавни. Ну а GC вполне себе защищает от утечек (тут опять Go ничего не привнес). И тут можно вспомнить еще и тот же D (все было еще в нем + гора сверху). Или даже Rust с его подходом из современных.
Установка... А тут что нового? Тонны языков с бородатых лет. С современных тоже хватает. Тоже ничего нового. Либо я не так вас понял. Но, банально - даже на Racket я могу всю VM упаковать, со всеми либами. У мейнстримных языков это тоже давно есть.
А недостатки...
Да, согласен - исключений нормальных нет. Видимо и не будет. В XXI веке смотреть на это больно.
Дженериков таких лучше бы не было (судя по спеке). Ситуация напоминает лямбды в Python.
Про фреймворки - лозунги рекламы, они нужны. В том числе и "жирные". То, что их нет скорее показатель ниши и сложности сделать из на Go.
Про ORM/ODM - мир СУБД не ограничен PGSQL и еще парой реляционных баз. И язык запросов - не только SQL. СУБД много. И ORM хорошо подходят под микросервисы, позволяют работать с высоким уровнем абстракций. Там где нужно лопатить терабайты данных Go мало что может предложить (Julia, R и Fortran он не замени ), нет нужных инструментов тоже. Вот и получается - как все на Golang. Примитивные решения для небольших вещей.
Итог - Golang стал популярным благодаря маркетингу. У него нет приемуществ кроме предельно низкого порога входа (правда в D он не выше в тех же границах использования) и заточенности под определенные задачи (gRPC , частично network).
З. Ы.: писал как на Python, так и на Golang. И даже в пьяном угаре не стал бы советовать последний.
Думаю, для Python-разработчика проще перейти на Julia (а она умеет ещё и Python код выполнять через биндинги). А если вы рубист - то Crystal.
А теперь по пунктам. Есть немного критики
Производительность: а чем это отличается от следующего пункта?
Скорость языка имеет значение: давайте разделять задачи. В рамках web (для которого Golang получил наибольшее распространение) - есть два основных узких места. Это - база данных (тут Golang ничего не сделает) и обработка JSON (и тут он медленный). Так, что "+/-" у этого аргумента. И как ни смешно, для микросервисов, которые часто работают с JSON прекрасным выбором является NodeJS. Не хуже Aio у Python. Прекрасно показыают себя Julia и Crystal. Ну а такие стеки как Erlang, Elixir, Java, Haskell, Racket... да масса на самом деле... работает с данными узкими местами не хуже. Если говорить об оптимизации на низком уровне - лучше Pure C я пока ничего не встречал. Даже Rust просто даёт не защищённый режим, где вы можете сделать "быстро". Но тут да, вопрос где именно надо сделать быстро. Вполне возможно, что Golang в этой задачи легко "сольёт".
Продуктивность разработчиков и ограничение креативности: Код, который вы показали - выглядит отвратительно, это ИМХО. Большая часть тех, кто работал на Python, думаю, так же скажут. Ранние выходы, куча странных нотаций, своеобразный и многословный синтаксис. Про ограничения... за ними скорее в Rust. Если нужна "золотая середина", то я сказал бы DLang. Ну а на Python настроенный линтер и аннотации типов в целом решают проблему без смены языка.
Параллелизм и каналы: ничего нового, на самом деле. "Новизна" - скорее маркетинг. Легкие потоки давно есть в Erlang, Racket, etc. Асинхронщина - Promise и разные его аналоги есть уже очень давно. В Python есть инструменты, чуть сложнее синтаксически (хотя не на много), слабый аргумент для смены "рабочей лошадки". Уж тогда смотреть в сторону Julia, которая по синтаксису ближе к Python, но умеет все перечисленное и много всего сверху.
Быстрая компиляция: сомнительный плюс, интересен больше в dev-режиме (на проде - не так принципиально, но бывают случаи). Скорее интереснее REPL и горячая замена кода. Erlang и Lisp тут никто не превзошёл. Разве что рядом Julia (которая по сути - DSL над Lisp).
Возможность собрать команду: смотря какого уровня нужна. У Golang часто та же проблема, что и у Python - средний по больнице уровень кандидатов достаточно низкий. Про API и возможности язка - Golang в целом не принёс ни одной новой идеи. Это хороший энтерпрайзный язык, который делался под конкретные цели и экосистемы. И там он хорош, но за рамками них...Мало чем лучше Python, если мы не говорим о синтетических тестах или очень узких кейсах.
Сильная экосистема: сильнее, чем на NodeJS я не видел экосистемы (без шуток). Если честно. И уж тем более на Golang менять ради экосистемы, отказываться от Python - это бред. Та же Julia выстреливает в том числе потому, что она совместима с экосистемой "ползучего". Golang... стандартно, где-то даже ощутимо хуже. Ощущение как от Dart - если Google хотели так применять, то всё в целом "ок". Если нет - то в лучшем случае никак. И в чём тут аргумент против Python?
Gofmt, принудительное форматирование кода: а в Python форматирование является частью синтаксиса. А ещё есть куча инструментов, которые делают это в других экосистемах. А ещё есть IDE, которые из коробки это умеют. В общем - ещё один недоаргумент, который ещё раз подтверждает - оснований переходить с Python на Golang просто нет.
gRPC и буферы протокола: вообще слабый аргумент. Ещё одна ниша, которая нужна конкретно Google и затачивалась под их конкретные задачи. Тем более - gRPC умеет куча экосистем и стеков. Шутка ли - даже в древний Common Lisp находил реализации. Python - уж тем более не исключение. Про "плюсы" и "минусы" самого gRPC можно спорить очень долго. Скажу лишь пару аргументов "против" - фронт и gRPC лучше не дружить (приходится проксировать через Gateway и делать что-то REST-подобное на фасаде), тотальный вендорлок гугла. Ну а автогенерённый код... он и в Африке автогенерённый. Хотя да, на Golang это всё наиболее прозрачно (кстати, в Dart было не хуже, пока Google не замкнули язык на Flutter). Но ниша слишком узкая. Да и на Python не на много хуже обстоят дела.
Итого: не убедили. Из 8 причин - ни одной существенной.
А вот недостатки... давайте отдельно, тоже.
Отсутствие фреймворков: вот тут то, что я писал. Если Golang интересен в этой нише Google - будет инструмент, нет - не будет. В Web ещё не так всё плохо (есть зайчатки), а вот в каком-нибудь вопросе ORM/ODM для разных СУБД будет примерно так же как в Raku - пишешь сам, поддерживаешь сам.
Обработка ошибок: да нет её толком. Это сложная и ресурсоёмкая тема. И как правило - она усложняет инструмент. Golang проектировался, чтобы быть простым. Поэтому... просто плодим if, улыбаемся и машем (и после этого кто-то сетует на JS с его Callback/Promise Hell).
Управление пакетами: А ведь это важно. Особенно для enterprise. А почему нет? Правильно, все интересные пакеты Google будут мейнтейниться Google. И будет всё хорошо. А остальной рынок мало интересен для создателей Golang.
Бонусом уж совсем понесло.
Сравнение Golang и Elixir: а почему именно Elixir? А не сравнить с изначально более выигрышной NodeJS, не сравнить с простой, быстрой и понятной Julia. Не сравнить с элегантным и не уступающим ни в чём Crystal. Вы бы ещё с LFE сравнили. Или со Scala. Да, они подходят под "асинхронщину" и "параллельщину". Но явно рассчитанные на уровень в среднем выше, чем у среднего python-разработчика (ему просто много из ФП не нужно).
Итого по статье - спасибо, было интересно. Но эффект обратный. Вы скорее доказали, что Golang не стоит внимания, а сообщество его сторонников - не может аргументировать выбор инструмента (мало чем подкрепленные аргументы).
З.Ы.: про ридер-макросы. Избегают в общелиспе их скорее потому, что мало кто умеет применять и это задача далеко не для junior'a. Да и сама библиотека макросов должна проектироваться, а не появляться стихийно. Но проблема есть, да. Убрать их с одной стороны - уберечь людей от некоего пула ошибок, который очень сложно дебажить потом. А с другой - убрать большую часть свободы, которая и есть основная фича лиспов (можно сказать, что код как данные - не полностью реализуется без этого). Поэтому что наличие фичи, что её отсутствие - спорные решения.
Приятно было отвечать, человеку интересующемуся лиспами. На самом деле в РФ это не такое частое явление. Почему-то у нас считают язык мёртвым (хотя по ощущениям в мире он переживёт многие хайповые ЯП, просто потому что даёт всё тоже самое уже давно).
Да, согласен. Clojure и выделяется часто как отдельное семейство в lisp-family (некоторые просто его выносят вообще из семейства и говорят, что это просто "лисп подобный язык"), который имеет свои особенности, семантику и возможности. Сравнение с общелиспом его... тут скорее а надо ли? Они решают разные задачи. Clojure скорее язык для систем с высокой нагрузкой, где надо работать с большим количеством подключений и операций (тут видимо его ближайшие конкуренты Scala, Erlang, Haskell). А Common Lisp все жё язык общего назначения, который в целом для написания любого софта подходит, но делает это хуже чем специализированные языки.
За библиотеку спасибо. Посмотрю, заинтриговали. Хотя использование Clojure для меня осложнено в pet projects в первую очередь скоростью работы. Банальная авторизация с выпуском JWT занимает ЕМНИП 500-700ms на локалхосте. Это не такая частая операция (да и может я криворук), но CL раза в полтора-два с половиной быстрее при том же кейсе.
Да, согласен с вами про clojure и CL они на самом деле эквивалентны по функциональности, но как раз отсутствие ридер-макросов очень сильно вносит корректировки в применение их (tagged тут не полная замена всё же). Ну и да, макросы в Clojure сразу принадлежат к какому-то неймспейсу (что скорее хорошо, но немного ограничивает).
Про MOP и ООП - я тут скорее имел ввиду, что в Clojure модель не уникальная для языков в целом (вполне дефолтно на самом деле для ФП языка), а вот для Lisp (который всё же не только Lisp-1) уже не такой стандартный вариант. На сколько помню в Scheme она вообще на основе hashtables сделана. И не могу сказать, что это хорошо. Но тема скорее холиварная и касается вкуса фломастеров.
Про типы данных - для примера pair (как в том же CL), boxed integers (нет полного набора числовых типов), нет сигнального протокола исключения (хоть это и не совсем к этому, но всё же).
Так же к отличием Clojure от CL, Scheme можно отнести: case-sensitive, множество специальных типов данных (литералы, вектора, отображения, регулярные выражения, анонимные функции и т.д.), множество добавочного синтаксиса и отличий в синтаксисе (банально в том же let), другой flow исполнения (насколько помню связывание в let работает так же как let* в Scheme), нет части стандартных функций (car, cdr, etc.), nil по другому себя ведёт, поддержаны ленивые вычисления... Отличий на самом деле от общелиспа и схемы - много. Я не говорю, что они плохие, но они есть. И существенные.
Clojure я бы назвал неким Lisp-1.5, который более production/enterprise ready. Но от этого всё вроде и похоже, но не так.
З.Ы.: против Clojure ничего не имею, писал на нём какое-то время свои pet projects. Но вернулся в итоге на CL из-за всех этих нюансов.
Спасибо за статью и в целом, что вспомнили про Lisp. Но хотелось бы внести ясность по тому, как сейчас обстоят дела.
Напрочь забыты реализации Common Lisp. Он жив, жил и будет жить. Это один из самых богатых представителей lisp-family как со стороны батареек (за исключением Clojure), так и по количеству реализацией. Есть и платные, есть и свободные. На любой вкус.
Если говорить о Scheme, то тут надо брать конкретную реализацию. Она не одна и есть нюансы (в отличии от CL по ощущениям их больше). А ведь ещё есть и экосистема Guix, которая построена на нём (ЕМНИП, кто пользуется - поправьте), и NixOS построенная на ней. Об этом как-то забыли.
Racket - изначально был диалектом Scheme, потом стал отдельным языком в lisp-family (он очень далеко уже ушёл от Scheme). От него был отпочковался такой диалект как Typed Racket и ещё несколько. Racket как и Scheme ближе к ФП, чем тот же Common Lisp, некоторые диалекты Racket являются в целом прямым конкурентом тому же Haskell, но с сохранением особенностей семейства. Одним из отличий является наличие гигиенических макросов и в целом направленность Racket на решение задач через разработку DSL. Ну и да, не только в Clojure все хорошо с асинхронностью и параллелизмом. В Racket как минимум не хуже.
Clojure - самый спорный представитель всего lisp-family. Многие считают, что он не относится к лиспам вообще, а лишь походит на них синтаксически. В частности, в Clojure сильно обрезана система макросов, немного по другому строится в работа самого языка (всё же на JVM). Объектная модель с мультиметодами - тоже уникальная особенность языка, она не использует мета-объектный протокол. Ну и для lisp-family в нём очень много синтаксиса, который не является частью экосистемы а просто есть как сахар. Нет и некоторых вполне дефолтных типов данных. Все лиспы можно описать как (a(b(c))). С Clojure этого не пройдёт.
Если говорить о JVM - ABCL и Kawa все же больше лиспы, чем Clojure. И заслуживают внимания не меньше, если не больше.
Напрочь забыт PicoLisp, который является языком и СУБД в одном, развивается небольшим, но очень уютным комьюнити. И как раз он сейчас, ИМХО, наиболее интересен как "язык = платформа".
Есть реализация Lisp для виртуальной машины Erlang, которая пока только в зайчаточном состоянии, но уже представляет интересный проект. И если сравнивать с Clojure имеет куда больше фишек по параллельным и асинхронным операциям, да ещё и может использовать OTP.
Если говорим об Emacs и EmacsLisp, то тут скорее правильно говорить как о платформе. Сам по себе Emacs ближе к ОС, язык которой и выступает EmacsLisp. Собственно, на Emacs можно реализовать хоть веб-сервер, хоть CRM, хоть игровой движок. Проблема основная в изначальной не общей направленности. Но всё же. Язык и платформа - живы и переживут всякие Eclipse или поделия JetBrains.
А еще есть далекие потомки, такие как OpenDylan (не взлетевший но развиваемый язык от огрызочной компании, лисп без скобок) или JS (внезапно, это переделанная сильно "схема" для браузера).
Ну и на последок, не раскрыта в статье самые главные особенности lisp-family, которые обеспечивает языку такой почтительный срок жизни - "код есть данные" и "кровавый патчинг". Любой настоящий lisp способен воспринимать изменения кодовой базы и обрабатывать код, мутировать его. Он является одним из лучших вариантов для построения систем, которые пишут другие системы. Динамически, прямо в рантайме. ЕМНИП, ближе всех к этому из академических языков подошёл РЕФАЛ, но он уже закопан очень глубоко. Более или менее то же самое предлагал TCL, но он давно не развивается.
Я ничего не буду шутить, просто оставлю тут немного наблюдений:
Дуров обещал, что реклама никогда не появится в Telegram. Она появилась.
Дуров говорил, что проект Telegram никогда не будет делать платную подписку для пользователей. Она появилась "по просьбе самих пользователей".
Дуров говорил, что не будет сливать информацию о своих пользователях, последнее время все чаще Telegram передаёт данные спецслужбам %country_name.
Дуров говорил, что уехал из страны чтобы не было давления на него из-за бизнеса. Оказалось совсем не по этой причине.
Дуров говорил, что сообщения Telegram хранятся в защищённом виде и даже команда разработчиков не сможет их прочитать. Оказалось хранятся в открытом виде.
Дуров говорил, что он не анализирует данные пользователя и переписки. Оказалось анализирует.
Дуров говорил, что Apple делает лучшие смартфоны и ПК. Стал говорить, что компания делает плохую технику после выброса Telegram из яблочного маркета...
Дуров говорил, что telegram стал лидером рынка. Оказалось только в РФ и ближнем СНГ...
И такой список при желании можно продолжать очень долго. Telegram - просто ещё одна социальная сеть, которая просто ориентированна на нативные клиенты и подачу контента через чаты. Ни более и не менее. Это не защищённый мессенджер. Это посмешище... Больше всего радует, что человек потом начинает "отвечать на критику" просто, по-русски, переводя стрелки. Telegram никак не защищает данные и хранит переписки в открытом виде? Так WhatsApp сотрудничает с ФБР. И шут с ним, что он делает (Дуров) так же. Если не будет нужен PR ход как было в РФ... В общем - Дуров остался верен себе. Никакой аргументации и пустые обещания
Так нет черенка, в том-то и дело. Я же писал выше - у любой большой компании много хейтеров. И они пишут. Но давайте так - на заборе тоже много пишут, но процент правдивости этого как правило ничтожный.
В своем комменте написал как обстоят дела в компании с позиции человека, который достаточно долго в ней работает и знает, как на самом деле обстоят дела.
А про "везде так" - имел ввиду, что у всех enterprise компаний есть свои минусы. К примеру, я не видел ни одного крупного игрока, кто согласиться использовать тот же Red или Io как основной стек. В стартапе - пожалуйста (им терять всё равно нечего), в Enterprise - нет (там ведь есть клиенты, которые платят за продукт).
Вот, что всегда не любил в современном ИТ - это мнение, что если компания не рассказывает на право и налево о гироскутерах, не внедряет хипсторские решения, которые появились вчера, то она обязательно - галера. Хотя последнее - скорее к стартаперам и прочим хипсторам. Но они кричат громче. Вот и мнение формируется.
Мой комент - реакция не статью. Обидно читать не правду про место, где ты уже почти 4 года и знаешь как на самом деле обстоят дела.
Я в компании почти 4 года. Ни разу такого не было. Да, когда подходит время к выпуску - публикуется новость, что надо посмотреть на участок ответственности команд, определиться с версиями решения проблем или сдвинуть сроки задач. Но такого, чтобы штрафовали за количество багов или "работаем пока не поправим" - не было ни разу.
Я больше 13 лет на рынке и могу сказать, что в целом ТЕНЗОР - лучше на рынке не нашёл за всё время. Раньше менял место работы каждый год, потому-то что-то не устраивает. Тут осел и не планирую покидать, ибо нет того, что не устраивало бы.
Я использовал как MobX, так и Redux. И ещё кучу менеджеров состояний. И мне было всегда удобно, не превращался код в кашу. Что я делаю не так? Как закривить руки, чтобы прямо в кашу?
Осильте уже что-то сложнее MobX. Внезапно будет и Redux не плох, если применять его к месту и руками.
Спасибо за статью. Радостно видеть, что кто-то задумается даже сегодня о такой "скучной" вещи, как качество программного обеспечения. Было интересно, а ниже... много критики. Почему? Надо попытаться разобраться в проблеме, которую поднимаете. А не просто повторять цитаты хейтеров различных стеков или красивые идеи, которые куда глубже, чем кажется.
Первое, что бросается в глаза сходу - вы преподносите Electron как нечто плохое, хотя забывается - View у программного обеспечения может быть любой, он может банально меняться от платформы к платформе. И для того, чтобы ПО было качественным - функциональная часть должна быть отвязана от пользовательского интерфейса. Который вообще должен быть не более, чем клиентом. Заменяемым. И проблема первая, которая чаще вредит качеству - это смешение логики, а не использование конкретного средства визуализации. Ну то есть, в большей части случаев проблема не в платформе - а в прокладке между клавиатурой и креслом, которая пихает в клиент - явно не свойственную ему задачу. Так и получается "интерфейс", который весит какие-то не реальные значения. А потом ещё обрастает очень странной, не свойственной ему логикой. И становится ещё хуже.
Второе, все про тот же Electron. Это прожорливость. Внезапно, он потребляет меньше того же JavaFX. И чуть больше того же Swing. И при этом подходит под другой важный критерий ваш же - скучная технология. Внезапно, надо поискать способ древнее, чем использовать в качестве клиента банальный web, с анимацией через JS. По существу, кроме различного "сахара" - Electron не дает ничего. Плюс вопрос потребления - это ведь вопрос не столько платформы (она "ест" по современным меркам не так, чтобы и много), а человека. Фреймворки? Не используйте и все. Может для вас станет открытием - но и на TUI можно потреблять гигабайты. Отношение к electron-софту сформировано чаще всего из специалистов низкой компетенции... простите, но это как судить о "битлах" по тому как "Вася напел". Быть может стоит обратиться к хорошим практикам, улучшению квалификации, а не охоту на платформы-ведьмы? Правда, тут есть "но", не требуется решать задачу забивания гвоздей для полки архитектором с 40 летним стажем. Полка выйдет золотая. Поэтому - качество специалистов (и их стоимость) должны коррелировать с решаемой проблемой.
Третье, про потребителей и качество - не совсем так. Потребителя волнует возможность решить проблему. Программа - лишь инструмент. И если цена решения выше наличия проблемы - он не будет её решать. Достаточно, чтобы решение было дешевле, чем "ничего не делать". И это нормально. Вы ведь не всегда едите здоровую еду, хотя какой-нибудь фаст-фуд не более чем аналог некачественного софта. Да, вредит. Но проблему решает, пусть и с последствиям. И тут надо честно сказать - это проблема владельца продукта, найти как сделать продукт лучше с полезной для меня точки зрения. Если для меня не проблема +500мб потребления, то я не буду платить за понижение потребления. Ведь продукт и так решает мои проблемы. Иными словами - качество должно быть необходимое, а не сферическое и в вакууме. Внезапно, вероятно любимый вами Linux отнюдь не высокого качества. А написан он, кстати, на стабильных и скучных технологиях.
Четвертое, про скучный стек. Простите, а что вы под ним понимаете? Если всякие Python - то сразу, мимо. Мало того, это виртуальная машина (которая может работать с нюансами в зависимости от реализации и платформы), так ещё и с кучей зависимостей на каждый чих (а внутри этих зависимостей может быть вообще Си-бибиотека, которая будет собираться под каждую платформу). Хорошо, тогда предположим С++/С? Языки с UB, без внятного управления пакетами и с разницей поведения в зависимости от ОС? Такой себе выбор. Rust (он по многим критериям подошел бы)? Новодел, который не имеет серьезного промышленного применения (молод), да ещё и не скучный. Java? Кушает много, опять же - ВМ с кучей версий, куча библиотек. Даже приведенная картинка с базами... вы будете смеяться, но какая-нибудь Mongo может в части кейсов использования вести себя куда предсказуемее PGSQL, а в части наоброт. Иными словами - "скучный" стек так же исходит от решаемой проблемы. И он может оказаться вполне себе нестабильный, потребляющим массу ресурсов и так далее. Потому, что использовать что-то другое окажется просто финансово не выгодно и этот вот "идеальный" софт никому не будет нужен за такую цену.
Пятое, долговечное ПО. Красивая идея, которая в реальном мире недостижима. Дело в том, что вы можете гарантировать сборку софта через 20 лет только если все зависимости лежат в проекте и только одна команда занимается правкой этого кода. И то - нет гарантии, что через 20 лет компилятор "пережует" такое легаси. Ведь языки тоже будут меняться. И да, лучше писать все библиотеки самому, так вы гарантируете отсутствие внезапных багов. К чему я? Вы готовы за блокнот платить по паре тысяч баксов? А почему нет? Ведь вы получите долговечное ПО! А знаете почему нет на самом деле? Цена проблемы куда ниже цены софта. Долговечное ПО стоит применять только там,где это оправдано финансово. Где цена ошибки куда выше, а проблему не решать - нельзя. В остальных случаях - это работа, которая не будет оплачиваться. Я не думаю, что многие программисты согласятся работать бесплатно всю жизнь. Все же семья, дети, свои потребности. Коммунизм не настал. А open source просто другой способ монетизации.
Шестое, про пример про фото. А оно надо многим? Если я хочу сделать фото себя с друзьями на даче или застолья семьи - зачем мне вот все это, про искусство? Вы смешиваете понятия - профессионального продукта и потребительского. Сегодня человеку не нужно чего-то сложнее телефона с ИИ, который заменит часы фотошопа. Фотографу нужна навороченная аппаратура, куча знаний и прочее. Ведь он делает фото не для положить в альбом и "вспомнить молодость", а делает некий предмет публичного потребления, который аналогично картине - должен нести смысл, а не просто сохранять обрывок эмоций, понятный только паре людей. Или, вы предлагаете, перед тем как снимать утренник ребенка пройти курсы оператора и режиссера, и снимать на проф. аппаратуру?
Седьмое, проблемы "ужаса творческих людей". Вы сами давно смотрели сложное и умное кино, аналогичные книги и так далее, вместо пинаемого в статье "нетфликса" или просмотра спортивной программы\блога или просмотра мемчиков? Не так, чтобы эпизодами, а вместо и постоянно. Мало того, я могу предположу, что филолог будет в ужасе от вашей статьи (хотя бы из-за бедности языка, кучи заимствованных и жаргонных слов). Поэтому - не стоит обвинять массы. Вы тоже вносите лепту, исходя из ваших же суждений. Но, это все не так важно на самом деле. Вы ведь не будете копать яму для дачного туалета с применением нанороботов. А чтобы поставить его - вы не привлечете архитектора, а для отделки дизайнера. Почему? Потому, что вы решаете проблему "сходить в туалет на даче", а не "погадить, думая о вечности". И да, если человек хочет отдохнуть - смотреть фильмы Траковского, Джармуша или Линча такая себе идея. А вот крутить ему на фоне "проходняк с нетфликса" (который даст возможность мозгу отдохнуть) - вполне себе нормальное решение. Внезапно, мозгу нужен отдых и постоянная его работа приведет только к проблемам. То есть, опять же... надо идти от проблемы.
Восьмое, про хороший интерфейс. Хороший интерфейс должен быть понятным. А красота - понятие субъективное. Кому-то приятнее видеть TUI, кому-то строки в терминале. А кому-то подавай свистелки и перделки. Но от формы он не становится плохим. Он станет плохим, если вы не будете понимать как решить свою задачу - то есть найти решение своей проблемы. И эргономика должна быть впереди всего остального. Тут, конечно все осложнено пользовательским опытом, но тут имеем, что имеем. И надо работать над привитием. Кстати, интересный момент - красивый интерфейс может быть неудобным. Когда-то, если помните, были популярны файловые менеджеры, которые в 3D показывали файловое пространство. Красиво, эффектно. Пользоваться было невозможно. Потому и умерло.
Восьмое, мнение творческих людей не всегда для человека. Мало того, чаще всего - это решения из разряда "наркоманами для инопланетян". Давайте проведем эксперимент. Я могу гарантировать, что большую часть потребностей ваших вполне себе решит банальный Emacs с плагинами. Предлагаю вам настроить и пользоваться только им пару месяцев. Это качественное ПО, которое покроет большую часть потребностей. Это и плеер, и меседжер, и браузер, и почтовый клиент... да что угодно, чего не хватает - можете реализовать на ELisp, который стабилен и предсказуем. Я даю гарантию, что вы будете заменять вот это хорошее решение, на более простые и плохие - даже если пойдете на это. Почему? Решение проблемы будет слишком дорогим. Вам придется освоить сложный софт, освоить язык ELisp, освоить интерфейс, поменять привычки... И вы до сих пор этого не сделали, замечу.
Забей на критику.
Написание компилятора - не самый худший выбор для изучения С или С++. И что-то изучать в процессе реализации интересной для тебя задачи - вполне нормально. Торвальдс не имел 15 лет работы на Си к моменту написания первой версии ведра ведь тоже. Да и получил много критики, кстати, по поводу реализации. Не ошибается, по-факту, только тот, кто ничего не делает. Да и у большинства ярых критиков статистически достижений куда меньше, чем твой компилятор.
Нужна будет помощь с написанием прикладных библиотек или чем-то еще, обращайся. Буду рад подключиться и помочь. С самим компилятором маловероятно - не моя тема, сильно не моя. Хотя и интересует.
А так - успехов тебе и проекту!
Offtopic: позор Хабру. Статья явно написана под влиянием личных претензий. Есть куча open source решений далеко не лучше компилятора Rave, но автора статьи они не трогают. И почему-то мы не увидим подобной статьи о других продуктов от того же критика. Без юродства, критика полезная по сути, а вот подача - какое-то "гнобление" конкретного человека. Ведь можно было даже в статья показать ка сделано не правильно, как можно улучшить, а добить - как сделать хорошо. От этого остается послевкусие, что критик сам не может сделать то, о чем пишет.
Хм. Статья интересная, спасибо. Критика местами понятна. А теперь к критике статьи.
По большому счету, а почему бы автору статьи не присоединиться к разработке и не показать как надо? Я понимаю энтузиаста, который пилит Rave, ответ "я делаю компилятор в одиночку" далеко не глуп. Человек вероятнее всего сконцентрирован на внесение фич, а не правильности кода компилятора. В целом, это нормальный продуктовый подход. Если условная версия 1.0 будет интересна сообществу - имеет смысл все это прибрать. Нет, так зачем страдать? Опыт в любом случае (ценный) получен. Да, можно было многое сделать лучше. Но работающий компилятор представляющий какую-то законченную версию языка лучше, чем красиво недописанный продукт.
В целом - автор статьи столько потратил сил на чтение кода и написание этого материала, что мог бы вполне сделать пару MR. Open Source жеж, не нравится что-то - поправь и кинь MR. Не думаю, что автор языка будет против.
Замечу. Автор Rave не продает его, за разработку денег не получает. И не обязан бросаться все исправлять и менять свой road map. И не обязан вносить любые правки по замечаниям. И критика его за это - странная.
А так, по существу такой критики. Забавно получается - автор Rave написал какой-то работающий компилятор своего языка. Пусть он и плохо написана, но работает. А языка автора статьи для оценки его компилятора... не помню, чтобы видели. Nuff said.
Спасибо за статью, в любом случае. Объем впечатлил. А вот содержание... давайте по-порядку.
Глобальные проблемы с которыми столкнулось человечество на текущий момент
Это то, чтоб было еще с ХХ века. И мало что поменялось. И проблема тут не в том, что кто-то ангажирован (в капиталистическом строе - это не решаемая в принципе проблема), а скорее в не корректной идентичности каждой приведенной. А последнее ведет к тому, что определяется не корректно основополагающая причина. А их, на самом деле, всегда две - предельно низкий уровень образования основной массы людей и ориентация капиталистической идеологии на индивидуальные достижения группы, а не общие достижения социума. При повышении уровня образования и привитии правильных ценностей - все перечисленные проблемы имеют достаточно тривиальные решения, кстати говоря.
Отказ от денежного обращения и внедрение нейросетей как попытка ослабить влияние глобальных проблем
Не решает ни одну проблему. Деньги как таковые - это универсальный инструмент определения ценности для последующего обмена. Таким образом мы определяем, что условные пять кило гречки равный условным 20 литрам воды. Деньги - это инструмент, а негативные его факторы - проблема людей, а не инструмента.
Особенно наивно думать, что отказ от денег может помочь в борьбе с неравенством или помочь с понижением уровня стресса.
К сожалению не вспомню кто проводил эксперимент (давно читал работу), но был ученый, который пытался сделать общество без денег на отдельно взятом острове. Итогом стало изобретение социумом аналога денег, т.к. нужен был универсальный инструмент для определения ценности при обмене. А проблемы которые были - они так и остались. Ведь они в природе человека, а не в бумажках.
Ну а использование нейросетей... ознакомьтесь с трудами Жана Фреско, у него были подобные суждения - он предлагал управления отдать компьютерам. Если коротко - не взлетело и не взлетит. Нейросети - это не интеллект, а его эмуляция. И серьезные решения отдавать им - это примерно как стрелять себе в ногу.
Перейдём к конкретике. Концепция Глобального Социального Контракта
А у вас тут еще больше воды, чем было до. Забавно то, что ваши "очки" - суть те же деньги. Просто вы их обозвали иначе, чтобы было не как у клятых капиталистов. А по факту - назовите хоть горшком, сути не меняет. В не ту проблему предлагаете решать.
На а улучшения жизни за счет ИИ... вот я могу сказать как специалист по анализу - если взять всю историю планеты, то мы придем к выводу, что человеческое общество создало куда больше проблем и наносило исключительно вред. Как вы будете защищать ИИ от мысли, что проблема планеты - это человечество?
Предполагаю - тут вы ничего нового не придумаете и предложите аналоги законов робототехники Азимова. Но есть одно "но" - нейросети не могут мыслить и предлагать то, чего не знают. Без человека вы не обойдетесь.
Переход к новой системе ценностей
Вот тут уже появляются светлые идеи, которые вы, правда, тоже переизобрели. Один из известнейших романов об этом - "Город" К. Саймака, который повествует как раз о необходимости человечеству новой философии, которая бы вывела цивилизацию из тупика. Очень рекомендую к прочтению - прекрасное произведение, которое наталкивает на мысли. Конечно, какой-то конкретики в нем вы не найдете (за ней лучше обратиться к философским течениям), но итог к которому придет цивилизация с современными ценностями и нормами - описаны вполне не плохо. Кстати, проблемы вы так же оттуда могли бы почерпать, там куда лучше детерменированны причины и следствия, чем у вас.
В тексте - опять просто вода. Как организовать процесс формирования ценностей? Какие критерии полезности они должны нести и какие методы оценок требуется использовать? Как они должны интегрироваться в новые поколения? А как в старые? Как мотивировать общества переходить на них? Какая система противовесов должна вводится для индивидов, которые не принимают эту систему?
В целом, по тексту - вы сделали плохую компиляцию идей утотопистов (вроде упомянутого Ж. Фреско), коммунистов (отказ от денег, равенство - можно взять любого философа этого направления, начиная с Маркса) и приправили чуть техношизой (ИИ, "компутеры" - правда тут вторите упомянтому Фреско часто). Плюс набрали ворох пугалок в качестве основания у фантастов-антиутопистов, причем так и не смогли определиться в итоговом влиянии проблемы на конкртеные показатели (их в принципе нет). И похоронили немногие светлые идеи просто океанами воды, сведя их к красивым лозунгам.
Для того, чтобы менять мир к лучшему - надо решать реальные проблемы. А это не лозунги "давайте жить правильно", а конкретные шаги по идентификации понятия "правильно", интеграции его во все системы жизни.
Если хотите менять мир - начинайте, у вас есть все для этого. Сформируйте лозунги в цели, цели разбейте на задачи. И с этим уже - показывать людям, чтобы вдохновить и найти единомышленников. Покажите окружающим пример - люди потянутся, если идеи на самом деле будут стоящие.
А пока... просто очень много наивного текста на Хабре, уровня канала РЕН-ТВ, где для полного комплекта не хватает только Рептилоидов.
Golang как замена Pure C и C++ не взлетел.
Для использования вместо Pure C - надо выкидывать GC и как-то давать интерфейс работы с памятью. Это сложно и противоречит изначальной цели Go - быть простым.
Для использования вместо С++ - не гибокий, мало возможностей (в том числе работы с памятью) и слабая реализация элементов ООП.
Плюс конского размера бинари и невозможность использовать через какой-нибудь FFI.
А вот как альтернатива Python и подобным языкам для того, чтобы плодить web - вполне себе альтернатива, если нужна асинхронщина а в NodeJS не хочется, а в Erlang не можется.
Очень интенсивно недавно развивался, потом как-то затухло.
Мало с ним поработал. Так, для пары простых микросервисов заюзал. Не могу ничего плохого сказать - это один из череды "простых и производительных" языков, вроде Julia, Crystal, Elixir и им подобных. Чаще всего видел их позиционирование как "работа над ошибками Python/Ruby/$LanguageName". Но тут, думаю, проблемой стало позиционирование - Crystal и Elixir взяли такой хороший курс на Web, Julia пытается прижиться в наших ML и числодробилок...
А вот куда Nim приложить предлагают, я так и не смог понять. Были, на сколько помню, потуги его затащить в gamedev, но вроде как не взлетело (хотя могу ошибаться).
Как альтернатива Python... а зачем, если есть Julia? Последнее время она и в web стала хорошо уметь (прекрасный фреймворк Genie уже до 5 версии обновили), имеет свои notebooks (Pluto.jl) для датасаентистов и т.п. Плюс из неё можно делать вызовы Python-кода.
Любой язык, чтобы стать успешным, должен быть инструментом конкретной ниши, для конкретной ЦА. Надеюсь Nim найдёт своих пользователей. Язык то очень даже не плохой.
Ничего не имею против Elixir. Более того могу сказать, он мне нравится.
Я имел ввиду то, что берётся для сравнения в статье изначально более требовательный к погружению стек. Всё же вхождение в Erlang-окружение (а у Elixir много инструментов и подходов от "родителя") сложнее, чем JVM или NodeJS. Но да, Elixir не корректно "выбрасывать" из сравнения. Это язык, который на порядок лучше Golang и он вполне себе хорошая альтернатива для миграции с Ruby/Python.
Про Rust... это специфичный инструмент. Я не могу сказать, что он плохой. Он как раз требовательный, сложный и функциональный. Кстати, уж если заговорили про него - его экосистема ничуть не хуже Golang, а местами даже куда лучше. И если уж сравнивать компилируемые языки между собой - то оставить без внимания его было бы не верно. Как не верно и "забыть" сравнивать Golang с Dlang, который умеет всё то же самое, что и первый и ещё сверху много приятного (нормальные ошибки, дженерики, шаблоны, etc.). Последний, кстати, не на много сложнее изучить, чем Golang. В том числе за счёт достаточно простого и понятного синтаксиса.
За ссылку на рейтинг спасибо, как раз хотел посмотреть каков тренд и менялся ли).
Про продакшен код за пару дней изучения - не удивительно. Именно такую задачу и ставил Google. Вернее, чтобы "даже питонисты могли быстро влиться и начать писать производительный код". Это делает Golang хорошим инструментом, но не хорошим языком.
Далее - Scala, Rust, Julia иди Crystal не эзотерические. Вполне себе инструменты. NodeJS тем более. Но сравнивают почему-то с Elixir. Niff said.
Про экосистему. Я уже писал, что она хороша там где была интересна Google. Найдите ODM для той же ArangoDB или Couchdb. А это вполне промышленный СУБД. И нет никакого в этом go way (в случае с Golang - это просто агитка, чтобы не писали сложного, инструмент не заточен), есть интерес основного инвестора. И именно поэтому почти всегда не портит - есть пакеты не интересные корпорации, а остальные - на свой страх и риск.
Про IDE, извините. Я настраивал 7 лет назад Emacs под Dlang, Python и NodeJS. Потом накрутил еще модули для Julia. Вопрос инструмента и рук.
Про init.py - скорее особенность и условие. Тут не хорошо и не плохо. Функция main у K&R тоже условность.
Про инструментарий вообще не в кассу. Julia - похоже. На Nodejs еще раньше сделали, чем Golang. Древний Common Lisp умеет очень многое (сложно найти чего нельзя сделать через снапшот). Дебаг легких потоков - Erlang. А так из промышленного удобный инструментарий и IDE - идеи Smalltalk никто не отменял. Другое дело, что порог входа инструментов - низкий. Правда их функциональность соответствует порогу входа.
Проблемы со сборками... Давайте не сравнивать Python , а возьмем Dlang или Rust. У них их тоже нет. И C они редко дергают. Иными словами - мало удивительного. Плюсы компилируемого языка. И минусы. Так как на С давно уже это написано, зачем велосипедить? Ну а так - если честно, я встречал проблемы с зависимостям. В Python только под Wondows. И были проблемы с установкой каких-то пакетов под форточкамит и в Golang. Хотя может за 4 года, что я не прикасался - что-то поменялось.
Ага. Видел я в продакшене обработку. Примерно на уровне Python'новского try/catch+pass. Если ошибка - упасть, если не ошибка - делать. Другая крайность if-hell с диким уровнем вложений. Без нормальной типизации и единой точки обработки. Ничем не лучше callback hell, лапша.
Линейный код никто не запрещает писать на Python, Erlang, JS (asunc/await, generators) и кучи других языков. Собственно не линейный код свойственный языкам где кроме вызова callbacks нет ничего. А таких уже почти нет. Про лямбды - for тоже лямбда). Ничего, живут с ней все.
Пункт 7 можно применить к любому языку. Вообще любому. Главное, чтобы команда применяла best practice и работала с code style. Говнокодить можно на любом языке. Что чаще всего и делают. А сказки переносимости опыта - идеальная ситуация, которой не будет скорее всего.
Универсальность сериализации есть в любом языке, который проповедует "код есть данные". На Lisp 1 еще. В ФП не сложнее, как и в ООП. Чуть побольше пары строк, но не rocket science . Smalltalk, Julia, Ruby...примеров можно найти при желании много. Даже древний TCL позволял (своими руками такое делал). Но может не понял задачу какую имеете ввиду.
Стабильность - Erlang, CL, Racket, Clojure, Scala, Haskell...да даже Nodejs (мой сервис работал один несколько лет без передёргивания), ну в самом деле. Тут ничего нового. Erlang тот же в целом идеал на счет стабильности - что-то стало работать не так, пристрели и заспавни. Ну а GC вполне себе защищает от утечек (тут опять Go ничего не привнес). И тут можно вспомнить еще и тот же D (все было еще в нем + гора сверху). Или даже Rust с его подходом из современных.
Установка... А тут что нового? Тонны языков с бородатых лет. С современных тоже хватает. Тоже ничего нового. Либо я не так вас понял. Но, банально - даже на Racket я могу всю VM упаковать, со всеми либами. У мейнстримных языков это тоже давно есть.
А недостатки...
Да, согласен - исключений нормальных нет. Видимо и не будет. В XXI веке смотреть на это больно.
Дженериков таких лучше бы не было (судя по спеке). Ситуация напоминает лямбды в Python.
Про фреймворки - лозунги рекламы, они нужны. В том числе и "жирные". То, что их нет скорее показатель ниши и сложности сделать из на Go.
Про ORM/ODM - мир СУБД не ограничен PGSQL и еще парой реляционных баз. И язык запросов - не только SQL. СУБД много. И ORM хорошо подходят под микросервисы, позволяют работать с высоким уровнем абстракций. Там где нужно лопатить терабайты данных Go мало что может предложить (Julia, R и Fortran он не замени ), нет нужных инструментов тоже. Вот и получается - как все на Golang. Примитивные решения для небольших вещей.
Итог - Golang стал популярным благодаря маркетингу. У него нет приемуществ кроме предельно низкого порога входа (правда в D он не выше в тех же границах использования) и заточенности под определенные задачи (gRPC , частично network).
З. Ы.: писал как на Python, так и на Golang. И даже в пьяном угаре не стал бы советовать последний.
Думаю, для Python-разработчика проще перейти на Julia (а она умеет ещё и Python код выполнять через биндинги). А если вы рубист - то Crystal.
А теперь по пунктам. Есть немного критики
Производительность: а чем это отличается от следующего пункта?
Скорость языка имеет значение: давайте разделять задачи. В рамках web (для которого Golang получил наибольшее распространение) - есть два основных узких места. Это - база данных (тут Golang ничего не сделает) и обработка JSON (и тут он медленный). Так, что "+/-" у этого аргумента. И как ни смешно, для микросервисов, которые часто работают с JSON прекрасным выбором является NodeJS. Не хуже Aio у Python. Прекрасно показыают себя Julia и Crystal. Ну а такие стеки как Erlang, Elixir, Java, Haskell, Racket... да масса на самом деле... работает с данными узкими местами не хуже. Если говорить об оптимизации на низком уровне - лучше Pure C я пока ничего не встречал. Даже Rust просто даёт не защищённый режим, где вы можете сделать "быстро". Но тут да, вопрос где именно надо сделать быстро. Вполне возможно, что Golang в этой задачи легко "сольёт".
Продуктивность разработчиков и ограничение креативности: Код, который вы показали - выглядит отвратительно, это ИМХО. Большая часть тех, кто работал на Python, думаю, так же скажут. Ранние выходы, куча странных нотаций, своеобразный и многословный синтаксис. Про ограничения... за ними скорее в Rust. Если нужна "золотая середина", то я сказал бы DLang. Ну а на Python настроенный линтер и аннотации типов в целом решают проблему без смены языка.
Параллелизм и каналы: ничего нового, на самом деле. "Новизна" - скорее маркетинг. Легкие потоки давно есть в Erlang, Racket, etc. Асинхронщина - Promise и разные его аналоги есть уже очень давно. В Python есть инструменты, чуть сложнее синтаксически (хотя не на много), слабый аргумент для смены "рабочей лошадки". Уж тогда смотреть в сторону Julia, которая по синтаксису ближе к Python, но умеет все перечисленное и много всего сверху.
Быстрая компиляция: сомнительный плюс, интересен больше в dev-режиме (на проде - не так принципиально, но бывают случаи). Скорее интереснее REPL и горячая замена кода. Erlang и Lisp тут никто не превзошёл. Разве что рядом Julia (которая по сути - DSL над Lisp).
Возможность собрать команду: смотря какого уровня нужна. У Golang часто та же проблема, что и у Python - средний по больнице уровень кандидатов достаточно низкий. Про API и возможности язка - Golang в целом не принёс ни одной новой идеи. Это хороший энтерпрайзный язык, который делался под конкретные цели и экосистемы. И там он хорош, но за рамками них...Мало чем лучше Python, если мы не говорим о синтетических тестах или очень узких кейсах.
Сильная экосистема: сильнее, чем на NodeJS я не видел экосистемы (без шуток). Если честно. И уж тем более на Golang менять ради экосистемы, отказываться от Python - это бред. Та же Julia выстреливает в том числе потому, что она совместима с экосистемой "ползучего". Golang... стандартно, где-то даже ощутимо хуже. Ощущение как от Dart - если Google хотели так применять, то всё в целом "ок". Если нет - то в лучшем случае никак. И в чём тут аргумент против Python?
Gofmt, принудительное форматирование кода: а в Python форматирование является частью синтаксиса. А ещё есть куча инструментов, которые делают это в других экосистемах. А ещё есть IDE, которые из коробки это умеют. В общем - ещё один недоаргумент, который ещё раз подтверждает - оснований переходить с Python на Golang просто нет.
gRPC и буферы протокола: вообще слабый аргумент. Ещё одна ниша, которая нужна конкретно Google и затачивалась под их конкретные задачи. Тем более - gRPC умеет куча экосистем и стеков. Шутка ли - даже в древний Common Lisp находил реализации. Python - уж тем более не исключение. Про "плюсы" и "минусы" самого gRPC можно спорить очень долго. Скажу лишь пару аргументов "против" - фронт и gRPC лучше не дружить (приходится проксировать через Gateway и делать что-то REST-подобное на фасаде), тотальный вендорлок гугла. Ну а автогенерённый код... он и в Африке автогенерённый. Хотя да, на Golang это всё наиболее прозрачно (кстати, в Dart было не хуже, пока Google не замкнули язык на Flutter). Но ниша слишком узкая. Да и на Python не на много хуже обстоят дела.
Итого: не убедили. Из 8 причин - ни одной существенной.
А вот недостатки... давайте отдельно, тоже.
Отсутствие фреймворков: вот тут то, что я писал. Если Golang интересен в этой нише Google - будет инструмент, нет - не будет. В Web ещё не так всё плохо (есть зайчатки), а вот в каком-нибудь вопросе ORM/ODM для разных СУБД будет примерно так же как в Raku - пишешь сам, поддерживаешь сам.
Обработка ошибок: да нет её толком. Это сложная и ресурсоёмкая тема. И как правило - она усложняет инструмент. Golang проектировался, чтобы быть простым. Поэтому... просто плодим if, улыбаемся и машем (и после этого кто-то сетует на JS с его Callback/Promise Hell).
Управление пакетами: А ведь это важно. Особенно для enterprise. А почему нет? Правильно, все интересные пакеты Google будут мейнтейниться Google. И будет всё хорошо. А остальной рынок мало интересен для создателей Golang.
Бонусом уж совсем понесло.
Сравнение Golang и Elixir: а почему именно Elixir? А не сравнить с изначально более выигрышной NodeJS, не сравнить с простой, быстрой и понятной Julia. Не сравнить с элегантным и не уступающим ни в чём Crystal. Вы бы ещё с LFE сравнили. Или со Scala. Да, они подходят под "асинхронщину" и "параллельщину". Но явно рассчитанные на уровень в среднем выше, чем у среднего python-разработчика (ему просто много из ФП не нужно).
Итого по статье - спасибо, было интересно. Но эффект обратный. Вы скорее доказали, что Golang не стоит внимания, а сообщество его сторонников - не может аргументировать выбор инструмента (мало чем подкрепленные аргументы).
З.Ы.: про ридер-макросы. Избегают в общелиспе их скорее потому, что мало кто умеет применять и это задача далеко не для junior'a. Да и сама библиотека макросов должна проектироваться, а не появляться стихийно. Но проблема есть, да. Убрать их с одной стороны - уберечь людей от некоего пула ошибок, который очень сложно дебажить потом. А с другой - убрать большую часть свободы, которая и есть основная фича лиспов (можно сказать, что код как данные - не полностью реализуется без этого). Поэтому что наличие фичи, что её отсутствие - спорные решения.
Приятно было отвечать, человеку интересующемуся лиспами. На самом деле в РФ это не такое частое явление. Почему-то у нас считают язык мёртвым (хотя по ощущениям в мире он переживёт многие хайповые ЯП, просто потому что даёт всё тоже самое уже давно).
Да, согласен. Clojure и выделяется часто как отдельное семейство в lisp-family (некоторые просто его выносят вообще из семейства и говорят, что это просто "лисп подобный язык"), который имеет свои особенности, семантику и возможности. Сравнение с общелиспом его... тут скорее а надо ли? Они решают разные задачи. Clojure скорее язык для систем с высокой нагрузкой, где надо работать с большим количеством подключений и операций (тут видимо его ближайшие конкуренты Scala, Erlang, Haskell). А Common Lisp все жё язык общего назначения, который в целом для написания любого софта подходит, но делает это хуже чем специализированные языки.
За библиотеку спасибо. Посмотрю, заинтриговали. Хотя использование Clojure для меня осложнено в pet projects в первую очередь скоростью работы. Банальная авторизация с выпуском JWT занимает ЕМНИП 500-700ms на локалхосте. Это не такая частая операция (да и может я криворук), но CL раза в полтора-два с половиной быстрее при том же кейсе.
Да, согласен с вами про clojure и CL они на самом деле эквивалентны по функциональности, но как раз отсутствие ридер-макросов очень сильно вносит корректировки в применение их (tagged тут не полная замена всё же). Ну и да, макросы в Clojure сразу принадлежат к какому-то неймспейсу (что скорее хорошо, но немного ограничивает).
Про MOP и ООП - я тут скорее имел ввиду, что в Clojure модель не уникальная для языков в целом (вполне дефолтно на самом деле для ФП языка), а вот для Lisp (который всё же не только Lisp-1) уже не такой стандартный вариант. На сколько помню в Scheme она вообще на основе hashtables сделана. И не могу сказать, что это хорошо. Но тема скорее холиварная и касается вкуса фломастеров.
Про типы данных - для примера pair (как в том же CL), boxed integers (нет полного набора числовых типов), нет сигнального протокола исключения (хоть это и не совсем к этому, но всё же).
Так же к отличием Clojure от CL, Scheme можно отнести: case-sensitive, множество специальных типов данных (литералы, вектора, отображения, регулярные выражения, анонимные функции и т.д.), множество добавочного синтаксиса и отличий в синтаксисе (банально в том же let), другой flow исполнения (насколько помню связывание в let работает так же как let* в Scheme), нет части стандартных функций (car, cdr, etc.), nil по другому себя ведёт, поддержаны ленивые вычисления... Отличий на самом деле от общелиспа и схемы - много. Я не говорю, что они плохие, но они есть. И существенные.
Clojure я бы назвал неким Lisp-1.5, который более production/enterprise ready. Но от этого всё вроде и похоже, но не так.
З.Ы.: против Clojure ничего не имею, писал на нём какое-то время свои pet projects. Но вернулся в итоге на CL из-за всех этих нюансов.
Спасибо за статью и в целом, что вспомнили про Lisp. Но хотелось бы внести ясность по тому, как сейчас обстоят дела.
Напрочь забыты реализации Common Lisp. Он жив, жил и будет жить. Это один из самых богатых представителей lisp-family как со стороны батареек (за исключением Clojure), так и по количеству реализацией. Есть и платные, есть и свободные. На любой вкус.
Если говорить о Scheme, то тут надо брать конкретную реализацию. Она не одна и есть нюансы (в отличии от CL по ощущениям их больше). А ведь ещё есть и экосистема Guix, которая построена на нём (ЕМНИП, кто пользуется - поправьте), и NixOS построенная на ней. Об этом как-то забыли.
Racket - изначально был диалектом Scheme, потом стал отдельным языком в lisp-family (он очень далеко уже ушёл от Scheme). От него был отпочковался такой диалект как Typed Racket и ещё несколько. Racket как и Scheme ближе к ФП, чем тот же Common Lisp, некоторые диалекты Racket являются в целом прямым конкурентом тому же Haskell, но с сохранением особенностей семейства. Одним из отличий является наличие гигиенических макросов и в целом направленность Racket на решение задач через разработку DSL. Ну и да, не только в Clojure все хорошо с асинхронностью и параллелизмом. В Racket как минимум не хуже.
Clojure - самый спорный представитель всего lisp-family. Многие считают, что он не относится к лиспам вообще, а лишь походит на них синтаксически. В частности, в Clojure сильно обрезана система макросов, немного по другому строится в работа самого языка (всё же на JVM). Объектная модель с мультиметодами - тоже уникальная особенность языка, она не использует мета-объектный протокол. Ну и для lisp-family в нём очень много синтаксиса, который не является частью экосистемы а просто есть как сахар. Нет и некоторых вполне дефолтных типов данных. Все лиспы можно описать как (a(b(c))). С Clojure этого не пройдёт.
Если говорить о JVM - ABCL и Kawa все же больше лиспы, чем Clojure. И заслуживают внимания не меньше, если не больше.
Напрочь забыт PicoLisp, который является языком и СУБД в одном, развивается небольшим, но очень уютным комьюнити. И как раз он сейчас, ИМХО, наиболее интересен как "язык = платформа".
Есть реализация Lisp для виртуальной машины Erlang, которая пока только в зайчаточном состоянии, но уже представляет интересный проект. И если сравнивать с Clojure имеет куда больше фишек по параллельным и асинхронным операциям, да ещё и может использовать OTP.
Если говорим об Emacs и EmacsLisp, то тут скорее правильно говорить как о платформе. Сам по себе Emacs ближе к ОС, язык которой и выступает EmacsLisp. Собственно, на Emacs можно реализовать хоть веб-сервер, хоть CRM, хоть игровой движок. Проблема основная в изначальной не общей направленности. Но всё же. Язык и платформа - живы и переживут всякие Eclipse или поделия JetBrains.
А еще есть далекие потомки, такие как OpenDylan (не взлетевший но развиваемый язык от огрызочной компании, лисп без скобок) или JS (внезапно, это переделанная сильно "схема" для браузера).
Ну и на последок, не раскрыта в статье самые главные особенности lisp-family, которые обеспечивает языку такой почтительный срок жизни - "код есть данные" и "кровавый патчинг". Любой настоящий lisp способен воспринимать изменения кодовой базы и обрабатывать код, мутировать его. Он является одним из лучших вариантов для построения систем, которые пишут другие системы. Динамически, прямо в рантайме. ЕМНИП, ближе всех к этому из академических языков подошёл РЕФАЛ, но он уже закопан очень глубоко. Более или менее то же самое предлагал TCL, но он давно не развивается.
Я ничего не буду шутить, просто оставлю тут немного наблюдений:
Дуров обещал, что реклама никогда не появится в Telegram. Она появилась.
Дуров говорил, что проект Telegram никогда не будет делать платную подписку для пользователей. Она появилась "по просьбе самих пользователей".
Дуров говорил, что не будет сливать информацию о своих пользователях, последнее время все чаще Telegram передаёт данные спецслужбам %country_name.
Дуров говорил, что уехал из страны чтобы не было давления на него из-за бизнеса. Оказалось совсем не по этой причине.
Дуров говорил, что сообщения Telegram хранятся в защищённом виде и даже команда разработчиков не сможет их прочитать. Оказалось хранятся в открытом виде.
Дуров говорил, что он не анализирует данные пользователя и переписки. Оказалось анализирует.
Дуров говорил, что Apple делает лучшие смартфоны и ПК. Стал говорить, что компания делает плохую технику после выброса Telegram из яблочного маркета...
Дуров говорил, что telegram стал лидером рынка. Оказалось только в РФ и ближнем СНГ...
И такой список при желании можно продолжать очень долго. Telegram - просто ещё одна социальная сеть, которая просто ориентированна на нативные клиенты и подачу контента через чаты. Ни более и не менее. Это не защищённый мессенджер. Это посмешище... Больше всего радует, что человек потом начинает "отвечать на критику" просто, по-русски, переводя стрелки. Telegram никак не защищает данные и хранит переписки в открытом виде? Так WhatsApp сотрудничает с ФБР. И шут с ним, что он делает (Дуров) так же. Если не будет нужен PR ход как было в РФ... В общем - Дуров остался верен себе. Никакой аргументации и пустые обещания
Так нет черенка, в том-то и дело. Я же писал выше - у любой большой компании много хейтеров. И они пишут. Но давайте так - на заборе тоже много пишут, но процент правдивости этого как правило ничтожный.
В своем комменте написал как обстоят дела в компании с позиции человека, который достаточно долго в ней работает и знает, как на самом деле обстоят дела.
А про "везде так" - имел ввиду, что у всех enterprise компаний есть свои минусы. К примеру, я не видел ни одного крупного игрока, кто согласиться использовать тот же Red или Io как основной стек. В стартапе - пожалуйста (им терять всё равно нечего), в Enterprise - нет (там ведь есть клиенты, которые платят за продукт).
Вот, что всегда не любил в современном ИТ - это мнение, что если компания не рассказывает на право и налево о гироскутерах, не внедряет хипсторские решения, которые появились вчера, то она обязательно - галера. Хотя последнее - скорее к стартаперам и прочим хипсторам. Но они кричат громче. Вот и мнение формируется.
Мой комент - реакция не статью. Обидно читать не правду про место, где ты уже почти 4 года и знаешь как на самом деле обстоят дела.
Я в компании почти 4 года. Ни разу такого не было. Да, когда подходит время к выпуску - публикуется новость, что надо посмотреть на участок ответственности команд, определиться с версиями решения проблем или сдвинуть сроки задач. Но такого, чтобы штрафовали за количество багов или "работаем пока не поправим" - не было ни разу.
Я больше 13 лет на рынке и могу сказать, что в целом ТЕНЗОР - лучше на рынке не нашёл за всё время. Раньше менял место работы каждый год, потому-то что-то не устраивает. Тут осел и не планирую покидать, ибо нет того, что не устраивало бы.