В разделе про публикацию PHP приложений последним пунктом идёт "Перезапустить PHP-FPM" — зачем? Выкладываем новые исходники и они просто работают! Причём текущие запросы не будут сброшены. А с go приложением, получается, при перезапуске процесса мы можем потерять запросы которые были где-то в середине процесса обработки! Или есть способ zero-downtime перезапуска go приложения?
«Перевод введения» из нескольких абзацев — это, наверное, тоже кому-то полезно, но раз уж взялись писать статью, сделайте перевод всего курса!
Кстати, для тех кто не смотрел, там в оригинале достаточно простой и понятный английский с чётким произношением — и без перевода всё понятно, посмотрите.
Каким будет PHP через 5 лет? Явный тренд развития в сторону конкурентного и многопоточного программирования: из коробки появятся не блокирующий ввод-вывод и асинхронность (аля nodejs или reactphp — об этом ещё Дмитрий Стогов на DevConf упоминал), синтаксис asycn/await, возможно PHProutine (наш ответ на горутины!) или хотя бы примитивы вроде parallel foreach, и какой-то «стандартный» сервер приложений.
В синтаксисе появится больше сахара: стрелочные функции, destructuring ассоциативных массивов и объектов, pattern matching, использование имён функций как ссылки на сами функции, чтобы можно было передавать без заключения в кавычки: array_map(strlen, ...) (для совместимости со старым кодом, возможно, будет синтаксис strlen::function, по аналогии как было сделано с MyClass::class)
Выгода для хостингов есть в уменьшении нагрузки на сервере при переходе на PHP 7. Но, конечно, хостер никогда не может заранее знать, не отвалится ли у какого-нибудь клиента старый проект, поэтому просто так взять и перевести всех на PHP 7 не получится. Многие хостеры уже давно предлагали в панели переключатель версий PHP, надеюсь и PHP 7 туда подтянут, благо этот релиз хорошо распиарен, запрос в массах есть, даже среди wp разработчиков.
Статья хорошая, всё по полочкам, но аргументы не показались мне достаточными, чтобы сменить .NET/Mono на Node.js. Вы жаловались на баги и «чёрный ящик» платформы, но Node.js тоже не идеален — это такой же «чёрный ящик» со своими утечками, багами и однопоточностью.
Плюс вы потеряли статическую типизацию и богатую и удобную библиотеку .NET (о чём сами и написали). Знаю, что статическую типизацию в какой-то степени можно вернуть с помощью TypeScript, а .NET библиотеку заменить отдельными npm пакетами, но используете ли вы TypeScript? И, опять же, на сколько используемые npm пакеты хороши и содержат меньше багов по сравнению с .NET/Mono?
Как отметил Envy в первом комментарии, складывается впечатление о погоне за модой, а не о хладнокровном расчёте.
Из оставшихся упомянутых вариантов:
Ruby — медленно и динамически типизированно;
Java — те же яйца, что и .NET/Mono, только в профиль, хотя, может меньше багов чем в Mono?
Python — медленно и динамически типизированно;
Можно было бы расширить список кросплатформенных языков, которые на слуху:
Go — быстро, статически типизированно, но сыро на мобильных
Rust — быстро, статически типизированно, но сложно и не знаю, работает ли оно на мобильных вообще?
C++ — быстро, статически типизированно, работает везде, но сложно++
На мой вкус, выходит либо Java/Go — если хочется попроще, либо Rust/C++ если команда готова на это.
Ваши конкуренты из Мой Офис потянули и сделали всё кросплатформенно на C++/Qt habrahabr.ru/company/ncloudtech/blog/263719
Интересно было бы обсудить эти или другие варианты — комментируйте!
ООП уже не модно.
Расскажите, лучше, как применить функциональное программирование в 1С.
Хочу, как минимум, filter.map.reduce для моих документов и неизменяемые типы данных!
Вполне подойдёт вариант с трансляцией из другого языка, например Clojure1C — кто займётся?
Компиляции как таковой нет, но есть статические анализаторы, которые вы можете запустить, например, перед коммитом в репозиторий — это и будет аналог проверки типов «при компиляции». В рантайме проверка тоже будет происходить, если указаны интерфейсы и, начиная с PHP 7, скалярные типы.
Не форк, но язык очень похожий на PHP и при этом без костылей: Hack — уже production ready.
Есть ещё JPHP — PHP под JVM, но не уверен насчёт production.
А в целом чем вам мешают «костыли древности»? Просто не пользуйтесь «плохими» частями языка.
Ничего против ноды не имею, но эта статья типичное бла-бла-бла в стиле продажника или «консультанта» с абстрактными картинками раскиданными по тексту.
… и с развитием экосистемы Node только ускоряется. Это тот случай, когда стоит потратить время на поиск того, что уже есть в сообществе Node, и выяснить, можно ли переиспользовать какие-то из общих модулей.
выбрать подходящий npm пакет из сотни одинаково недоделанных — та ещё задачка
Сплочённость разработчиков и их моральный дух поднимаются, если в IT-структуре организации есть команда, работающая с Node.js.
это вообще о чём и зачем это здесь?
благодаря низкому потреблению ресурсов процессора, своей вычислительной мощности и эффективному использованию ОЗУ
с чем сравнивали? Особенно про низкое потребление памяти интересует…
Автору перевода, конечно, спасибо, но статья ни о чём.
Кстати, для тех кто не смотрел, там в оригинале достаточно простой и понятный английский с чётким произношением — и без перевода всё понятно, посмотрите.
В синтаксисе появится больше сахара: стрелочные функции, destructuring ассоциативных массивов и объектов, pattern matching, использование имён функций как ссылки на сами функции, чтобы можно было передавать без заключения в кавычки: array_map(strlen, ...) (для совместимости со старым кодом, возможно, будет синтаксис strlen::function, по аналогии как было сделано с MyClass::class)
Плюс вы потеряли статическую типизацию и богатую и удобную библиотеку .NET (о чём сами и написали). Знаю, что статическую типизацию в какой-то степени можно вернуть с помощью TypeScript, а .NET библиотеку заменить отдельными npm пакетами, но используете ли вы TypeScript? И, опять же, на сколько используемые npm пакеты хороши и содержат меньше багов по сравнению с .NET/Mono?
Как отметил Envy в первом комментарии, складывается впечатление о погоне за модой, а не о хладнокровном расчёте.
Из оставшихся упомянутых вариантов:
Ruby — медленно и динамически типизированно;
Java — те же яйца, что и .NET/Mono, только в профиль, хотя, может меньше багов чем в Mono?
Python — медленно и динамически типизированно;
Можно было бы расширить список кросплатформенных языков, которые на слуху:
Go — быстро, статически типизированно, но сыро на мобильных
Rust — быстро, статически типизированно, но сложно и не знаю, работает ли оно на мобильных вообще?
C++ — быстро, статически типизированно, работает везде, но сложно++
На мой вкус, выходит либо Java/Go — если хочется попроще, либо Rust/C++ если команда готова на это.
Ваши конкуренты из Мой Офис потянули и сделали всё кросплатформенно на C++/Qt habrahabr.ru/company/ncloudtech/blog/263719
Интересно было бы обсудить эти или другие варианты — комментируйте!
Расскажите, лучше, как применить функциональное программирование в 1С.
Хочу, как минимум, filter.map.reduce для моих документов и неизменяемые типы данных!
Вполне подойдёт вариант с трансляцией из другого языка, например Clojure1C — кто займётся?
Есть ещё JPHP — PHP под JVM, но не уверен насчёт production.
А в целом чем вам мешают «костыли древности»? Просто не пользуйтесь «плохими» частями языка.
выбрать подходящий npm пакет из сотни одинаково недоделанных — та ещё задачка
это вообще о чём и зачем это здесь?
с чем сравнивали? Особенно про низкое потребление памяти интересует…
Автору перевода, конечно, спасибо, но статья ни о чём.