Спасибо за статью, в любом случае. Объем впечатлил. А вот содержание... давайте по-порядку.
Глобальные проблемы с которыми столкнулось человечество на текущий момент
Это то, чтоб было еще с ХХ века. И мало что поменялось. И проблема тут не в том, что кто-то ангажирован (в капиталистическом строе - это не решаемая в принципе проблема), а скорее в не корректной идентичности каждой приведенной. А последнее ведет к тому, что определяется не корректно основополагающая причина. А их, на самом деле, всегда две - предельно низкий уровень образования основной массы людей и ориентация капиталистической идеологии на индивидуальные достижения группы, а не общие достижения социума. При повышении уровня образования и привитии правильных ценностей - все перечисленные проблемы имеют достаточно тривиальные решения, кстати говоря.
Отказ от денежного обращения и внедрение нейросетей как попытка ослабить влияние глобальных проблем
Не решает ни одну проблему. Деньги как таковые - это универсальный инструмент определения ценности для последующего обмена. Таким образом мы определяем, что условные пять кило гречки равный условным 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 лет на рынке и могу сказать, что в целом ТЕНЗОР - лучше на рынке не нашёл за всё время. Раньше менял место работы каждый год, потому-то что-то не устраивает. Тут осел и не планирую покидать, ибо нет того, что не устраивало бы.
Работаю в ТЕНЗОР почти 4 года и за всё время описанных проблем - не встретил ни разу, какая-то дезинформация, скорее всего взятая от хейтеров (а у сильных игроков рынка таких всегда хватает).
Не понимаю, откуда вы вообще про график и штраф за опоздания взяли информацию? Никакого жесткого контря графика нет - рабочий день гибкий, можно подстроить график под себя (начало и конец рабочего дня), работать удалённо. Никаких штрафов за опоздания нет, нужно задержаться - сообщаешь об этом и всё. Про тотальную слежку - опять же, не правда. Да, система СБИС интегрирована с электронными турникетами и ты можешь посмотреть, в офисе ли человек, но это никак не проверяется. Да и зачем?
Про климат - тут тоже совсем не так. Все готовы помочь, всегда выслушают проблему и постараются найти решение, это часть корпоративной культуры и такой подход культивируется. Иначе такой большой продукт как СБИС просто физически было бы не реально выпускать.
Про авторитарный стиль управления - а что под ним понимается? Скажем, да, ведущий специалист по конкретному сегменту/технологии может сказать "так правильно, а вот это не правильно" - это нормальный рабочий процесс. Если говорить о формировании проектов, то да - заказчик в компании по-факту один (ему сдаются работы), но они формируются же проектными менеджерами и аналитиками, которые опираются на потребности клиентов. Да, у компании есть конкретный и понятный вектор развития, который определяется руководителями - но где в enterprise по-другому? И в то же время - любой программист может предложить проект и если это нужно клиентам или улучшит продукт, то он пойдёт в работу.
Про дедлайны - а где нет deadline'ов? Давайте сравним с другими крупными компаниями с продаваемым продуктом или gamedev. Увидим, что на самом деле картина в ТЕНЗОР даже мягче, чем у большинства игроков (всё же СБИС - облачный продукт, для каждой версии могут выходить миноры через которые доставляются фиксы или фичи). Про объемы работ - а где в enterprise их нет? Другая картина разве, что у стартаперов или компаний для которых разработка - побочный продукт (первые - только делают прототип, а для вторых сроки в принципе не критичны).
Говоря о переработках - они носят исключительно добровольный характер (и они оплачиваются отдельно), когда конкретная команда хочет поскорее что-то внедрить (и им ещё надо доказать, что ускорение внедрения необходимо). Руководство хорошо понимает, что переработки ведут к выгоранию и помогают построить рабочий процесс, чтобы этого не было. Если и бывают моменты - это скорее исключительная ситуация.
В целом - могу сказать, что такое ТЕНЗОР - это дружный коллектив, интересные эвенты, конкурентная зарплата (и её уровень поддерживается, за текущий год уже 4 раза индексировали), понятная кривая развития и сложные/интересные задачи. Кстати, да. По данным моего опыта - текучка минимальна. Минусы - они есть у всех, но общие для всех крупных компаний и не имеют ничего общего с описанным.
Так всегда в его случае. Красивые обещания без подтверждения делом. Скоро реклама будет введена и в обычные, личные чаты). С возможностью отключить за плату по подпичке. Оправдание найдется.
О, подвезли рекламу. Там, где ее обещали ни в коем случае не делать. Ведь все далется для блага обычного пользователя.
Так же сделали платную подписку. Там где обещали ее не делать. Ведь цель telegram дать "свободный" интернет, а не заработать.
Меня поражает, что люди продолжают верить Дурову и в Дурова. "Безопасный" мессенджер использует телефон для авторизации и хранит на серверах море инфы о пользователе, в группах продвигается pron (разной степени треша, от лёгкого до снафа и лоли), куча спамеров и нелегальщины. А проекты ton и gram имеют явную ориентацию на даркнет, а не на благо обычных пользователей.
Кто ещё не врубился - telegram является клоном ВК (который - просто клон Facebook) с нативным клиентом и фокусом на чате. Тот же стиль, цвета. Монетизация +/- похожа. Только с возможностью размещения контента, который официально запрещен в РФ, поэтому и сервера "забугром".
И вроде бы, можно сказать, что проект удался. Большая часть СНГ стоит на нем. Но...мерзко. Продукт созданный для того, чтобы можно было впихнуть в инфосферу то, от чего нормальные сервисы отказываются. С агрессивным маркетингом, за которым не так и много реальных фактов. И с лидером, который косплоет Джобса, не имея даже крупицы того гения.
Итог - шлакопродукт, который будет выкинут на обочину истории. С откровенно слабым идеологом (но прекрасным коммерсантом, в этом отношении - все прекрасно) и отсутствием пруфов на маркетинговые кричалки.
Спасибо за статью, в любом случае. Объем впечатлил. А вот содержание... давайте по-порядку.
Глобальные проблемы с которыми столкнулось человечество на текущий момент
Это то, чтоб было еще с ХХ века. И мало что поменялось. И проблема тут не в том, что кто-то ангажирован (в капиталистическом строе - это не решаемая в принципе проблема), а скорее в не корректной идентичности каждой приведенной. А последнее ведет к тому, что определяется не корректно основополагающая причина. А их, на самом деле, всегда две - предельно низкий уровень образования основной массы людей и ориентация капиталистической идеологии на индивидуальные достижения группы, а не общие достижения социума. При повышении уровня образования и привитии правильных ценностей - все перечисленные проблемы имеют достаточно тривиальные решения, кстати говоря.
Отказ от денежного обращения и внедрение нейросетей как попытка ослабить влияние глобальных проблем
Не решает ни одну проблему. Деньги как таковые - это универсальный инструмент определения ценности для последующего обмена. Таким образом мы определяем, что условные пять кило гречки равный условным 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 лет на рынке и могу сказать, что в целом ТЕНЗОР - лучше на рынке не нашёл за всё время. Раньше менял место работы каждый год, потому-то что-то не устраивает. Тут осел и не планирую покидать, ибо нет того, что не устраивало бы.
Работаю в ТЕНЗОР почти 4 года и за всё время описанных проблем - не встретил ни разу, какая-то дезинформация, скорее всего взятая от хейтеров (а у сильных игроков рынка таких всегда хватает).
Не понимаю, откуда вы вообще про график и штраф за опоздания взяли информацию? Никакого жесткого контря графика нет - рабочий день гибкий, можно подстроить график под себя (начало и конец рабочего дня), работать удалённо. Никаких штрафов за опоздания нет, нужно задержаться - сообщаешь об этом и всё. Про тотальную слежку - опять же, не правда. Да, система СБИС интегрирована с электронными турникетами и ты можешь посмотреть, в офисе ли человек, но это никак не проверяется. Да и зачем?
Про климат - тут тоже совсем не так. Все готовы помочь, всегда выслушают проблему и постараются найти решение, это часть корпоративной культуры и такой подход культивируется. Иначе такой большой продукт как СБИС просто физически было бы не реально выпускать.
Про авторитарный стиль управления - а что под ним понимается? Скажем, да, ведущий специалист по конкретному сегменту/технологии может сказать "так правильно, а вот это не правильно" - это нормальный рабочий процесс. Если говорить о формировании проектов, то да - заказчик в компании по-факту один (ему сдаются работы), но они формируются же проектными менеджерами и аналитиками, которые опираются на потребности клиентов. Да, у компании есть конкретный и понятный вектор развития, который определяется руководителями - но где в enterprise по-другому? И в то же время - любой программист может предложить проект и если это нужно клиентам или улучшит продукт, то он пойдёт в работу.
Про дедлайны - а где нет deadline'ов? Давайте сравним с другими крупными компаниями с продаваемым продуктом или gamedev. Увидим, что на самом деле картина в ТЕНЗОР даже мягче, чем у большинства игроков (всё же СБИС - облачный продукт, для каждой версии могут выходить миноры через которые доставляются фиксы или фичи). Про объемы работ - а где в enterprise их нет? Другая картина разве, что у стартаперов или компаний для которых разработка - побочный продукт (первые - только делают прототип, а для вторых сроки в принципе не критичны).
Говоря о переработках - они носят исключительно добровольный характер (и они оплачиваются отдельно), когда конкретная команда хочет поскорее что-то внедрить (и им ещё надо доказать, что ускорение внедрения необходимо). Руководство хорошо понимает, что переработки ведут к выгоранию и помогают построить рабочий процесс, чтобы этого не было. Если и бывают моменты - это скорее исключительная ситуация.
В целом - могу сказать, что такое ТЕНЗОР - это дружный коллектив, интересные эвенты, конкурентная зарплата (и её уровень поддерживается, за текущий год уже 4 раза индексировали), понятная кривая развития и сложные/интересные задачи. Кстати, да. По данным моего опыта - текучка минимальна. Минусы - они есть у всех, но общие для всех крупных компаний и не имеют ничего общего с описанным.
Так всегда в его случае. Красивые обещания без подтверждения делом. Скоро реклама будет введена и в обычные, личные чаты). С возможностью отключить за плату по подпичке. Оправдание найдется.
Да вы что? Такое не возможно в безопасном мессенджере. Он же безопасный)
О, подвезли рекламу. Там, где ее обещали ни в коем случае не делать. Ведь все далется для блага обычного пользователя.
Так же сделали платную подписку. Там где обещали ее не делать. Ведь цель telegram дать "свободный" интернет, а не заработать.
Меня поражает, что люди продолжают верить Дурову и в Дурова. "Безопасный" мессенджер использует телефон для авторизации и хранит на серверах море инфы о пользователе, в группах продвигается pron (разной степени треша, от лёгкого до снафа и лоли), куча спамеров и нелегальщины. А проекты ton и gram имеют явную ориентацию на даркнет, а не на благо обычных пользователей.
Кто ещё не врубился - telegram является клоном ВК (который - просто клон Facebook) с нативным клиентом и фокусом на чате. Тот же стиль, цвета. Монетизация +/- похожа. Только с возможностью размещения контента, который официально запрещен в РФ, поэтому и сервера "забугром".
И вроде бы, можно сказать, что проект удался. Большая часть СНГ стоит на нем. Но...мерзко. Продукт созданный для того, чтобы можно было впихнуть в инфосферу то, от чего нормальные сервисы отказываются. С агрессивным маркетингом, за которым не так и много реальных фактов. И с лидером, который косплоет Джобса, не имея даже крупицы того гения.
Итог - шлакопродукт, который будет выкинут на обочину истории. С откровенно слабым идеологом (но прекрасным коммерсантом, в этом отношении - все прекрасно) и отсутствием пруфов на маркетинговые кричалки.
Но telegram станет лучше. Вы главное заносите.
linux.org.ru
Это какой-то позор. Я бы понял увидеть статью с таким заголовком на "лента.ру" или другом жёлтом ресурсе. Но Хабр?!
Плюс, если брать по тегам суть статьи - Дуров не гик, а обычный (пусть и хороший) успешный маркетолог.