Вы неправильно поняли посыл статьи. Не надо всё делать объектами… Это ошибка проектирования. На нижнем уровне объекты только мешают, там гораздо удобнее работать с примитивными типами данных и структурами. В мейнстрим реализациях ООП начинается с идеи переноса объектов реального в программирование, а в итоге сводится к имитации, что строка общается с числами и т.п.
По поводу состояния, в Elixir оно надёжно спрятано в процессе, никакой рефлексией и уж тем более прямыми присваиваниями до него не достать. Только отправкой сообщений можно опосредованно влиять на состояние. Ну и как в любом функциональном языке все данные неизменяемы. Т.о. ситуация, когда вы получили часть состояния объекта по ссылке, передали в другой метод, а он взял его и изменил, тоже невозможны by design.
Процесс с этим pid упадёт с ошибкой типа (FunctionClauseError) no function clause matching in Airplane.handle_cast/2
airplane.ex:38: Airplane.handle_cast({:add, "Aimee", 2}, %{})
Вообще Erlang и Elixir стимулирует разработку по принципу «Let it crash». Поэтому чуть что не так — процесс падает и перезапускается с чистого листа одним из супервизоров.
Вы почему-то исходите из того, что текущий уровень языков программирования очень низок. Но по факту нам и правда надо хорошенько осмыслить то, что придумали за предыдущие 60 лет. На тех компьютерах, которые у нас сейчас есть, крайне сложно придумать что-то новое в области программирования. Более того CPU уже упёрлись в физические пределы производства. И даже на случай, если дальнейший рост пойдёт через увеличение кол-ва ядер на порядки, уже всё придумано.
застрявшими в цифровой эпохе электрических компьютеров на 1000 лет.
В том то и дело, что придумывать новые компьютеры в компетенции программистов не входит, это будут делать физики.
А если Вы реально хотите придумать что-то новое в плане программирования, смотрите в сторону появляющихся вариантов, типа квантовых компьютеров. Там прогресс будет, но это уже совсем другая история. Не имеющая отношения к написанию 100500 примерно одинаковых фреймворков/библиотек для одной и той же задачи.
Ну, если верить indeed.com, то разница на уровне Senior всего 6-7% в пользу Node.js. Т.е. по факту всё будет зависеть от выбора компании и проекта, а не от выбора между этими двумя вариантами.
Так речь то не о том, чтобы запрещать что-то придумывать, речь о том, что за предыдущие, допустим, 10 лет практически ничего нового не придумали. На первый взгляд кажется, что это бред, вон же каждую неделю что-то новое появляется. Но если задуматься, то по сути то реально ничего нового, просто небольшие плюшки, аля синтаксический сахар.
Если Вы JavaScript для client-side используете, а Java — для backend, то это всё-таки 1 поезд, просто с двумя вагонами, можно ещё 3-й вагон SQL прицепить )
А вот если и то и то для backend, то интересно было бы послушать каким образом Вы это совмещаете.
До Rust и Go уже был написан D. Если с C++ понятно, что ломать обратную совместимость никто не хочет, то вот почему не захотели вкладываться в D непонятно…
Спасибо за подробный рассказ. По-моему у Вас вполне здравая позиция и выбор технологий по конкретным критериям. Только к чему переживать об упущенных поездах, на двух одновременно ехать всё равно не удобно. По-любому какой-то один будет основным.
Из трёх перечисленных я хорошо знаком только с Go. Но в Go скорее идёт компоновка старых и очень старых идей, чего-то реально нового там не видно.
Есть даже книжка «Communicating Sequential Processes. The First 25 Years» с материалами симпозиума от 2004 года.
В Rust, насколько я понимаю, из коробки реализована модель умных указателей. Но самим умным указателям тоже сто лет в обед.
По поводу зависимых типов, Idris — далеко не первый ЯП, в котором они используются. А тому же Coq уже больше 30 лет.
P.S. С другой стороны, если рассматривать отдельно взятого программиста, то Вы правы, тут идёт прогресс в мышлении по мере ознакомления с разными парадигмами и подходами. Но в рамках индустрии новых идей очень мало.
По поводу состояния, в Elixir оно надёжно спрятано в процессе, никакой рефлексией и уж тем более прямыми присваиваниями до него не достать. Только отправкой сообщений можно опосредованно влиять на состояние. Ну и как в любом функциональном языке все данные неизменяемы. Т.о. ситуация, когда вы получили часть состояния объекта по ссылке, передали в другой метод, а он взял его и изменил, тоже невозможны by design.
(FunctionClauseError) no function clause matching in Airplane.handle_cast/2
airplane.ex:38: Airplane.handle_cast({:add, "Aimee", 2}, %{})
Вообще Erlang и Elixir стимулирует разработку по принципу «Let it crash». Поэтому чуть что не так — процесс падает и перезапускается с чистого листа одним из супервизоров.
Полный текст интереснее.
В том то и дело, что придумывать новые компьютеры в компетенции программистов не входит, это будут делать физики.
А если Вы реально хотите придумать что-то новое в плане программирования, смотрите в сторону появляющихся вариантов, типа квантовых компьютеров. Там прогресс будет, но это уже совсем другая история. Не имеющая отношения к написанию 100500 примерно одинаковых фреймворков/библиотек для одной и той же задачи.
А вот если и то и то для backend, то интересно было бы послушать каким образом Вы это совмещаете.
Есть даже книжка «Communicating Sequential Processes. The First 25 Years» с материалами симпозиума от 2004 года.
В Rust, насколько я понимаю, из коробки реализована модель умных указателей. Но самим умным указателям тоже сто лет в обед.
По поводу зависимых типов, Idris — далеко не первый ЯП, в котором они используются. А тому же Coq уже больше 30 лет.
P.S. С другой стороны, если рассматривать отдельно взятого программиста, то Вы правы, тут идёт прогресс в мышлении по мере ознакомления с разными парадигмами и подходами. Но в рамках индустрии новых идей очень мало.