Переосмысление Zephir

Original author: Phalcon
  • Translation
После нескольких месяцев работы над Zephir мы очень довольны прогрессом. В течение нескольких месяцев мы выпустим бета-версию и сможем использовать все ее возможности. Проект собрал более 1000 коммитов и все еще многое нужно сделать. Проект позволил нам провести больше исследований в области computer science и это было очень интересно для нас.
Кроме того, хоть мы и не уверенны, на счет того, что произойдет с PHP в будущем, так или иначе — мы создаем инструмент, который позволяет использовать еще одну возможность PHP (расширения на C), которая раньше была доступна только опытным C программистам.
Также в Zephir мы реализовали фичи, о которых многие мечтали, но по тем или иным причинам их нет в PHP сейчас:



Мы верим, что все это поможет нам улучшить фреймворк и может помочь вам в создании собственных инструментов новым способом. Не всем нужны эти фичи и не все с ними согласны, но так или иначе мы надеемся, что однажды они таки окажутся в PHP. Что бы не произошло, мы надеемся что PHP продолжит развиваться несмотря на пройденный путь.
Zephir изначально задуман, как высокоуровневый язык, создающий абстракцию над низкоуровневыми деталями ядра PHP. Он генерирует код на C, который в последствии может быть скомпилирован популярными компиляторами такими как gcc/clang/vc.
Так как Zephir высокоуровневый язык, он может работать, как мета-язык, а не просто DSL.
После некоторого обдумывания, я создал этот топик, чтобы обсудить с вами новую идею.
Если мы переделаем Zephir так, чтобы он мог генерировать и PHP и C код, тогда Zephir станет более мощным и гибким.

Генерация C:

  • Код может быть скомпилирован, повысится производительность и уменьшится расход памяти.
  • Появляется некоторый важный уровень защиты
  • Код экспортируется как C расширение


Генерация PHP:

  • PHP запустится везде, где сам php доступен (шаред-хостинги, серверы с ограничениями, другие реализации PHP)
  • Код экспортируется как библиотека на PHP


Использование расширений на C:
  • На продакшене, когда производительность необходима и установка расширения осуществима


Использование PHP:

  • Разработка/Тестирование, другие реализации PHP


Возможные минусы

  • С-код-блоки не могут быть перенесены в PHP
  • Интеграция с C-библиотеками не может быть экспортирована в PHP
  • Возможные несовместимости, из-за разных сред выполнения (может быть решено с помощью тестов)


С нетерпением ждем ваших комментариев

Only registered users can participate in poll. Log in, please.

Проведем хабра-голосование!

  • +28
  • 8.1k
  • 9
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 9

    +1
    Оперативно вы! Супер. Я отписался по ссылке…

    Словом, то что творят ребята из Phalcon невероятно. И да, мне нравится возможность на выбор упаковывать библиотеки в extension или подключать их как PHP классы
      0
      Ну вот я не совсем согласен, что это нужно.
      С одной стороны таким образом zephir получит огромную популярность, особенно если ребята из jetbrains помогут. Мы действительно получим любую фичу, которой не достает в php и не будем задумываться о совместимости между версиями.
      С другой стороны сейчас не совсем подходящее время и некоторая часть зефира остается за кадром. Например мысль о том, что теперь-то мы сможем запустить phalcon на своем шаред хостинге за 100 рублей — не верна. Есть некоторые вещи, которые как писались — так и продолжают писаться пол phalcon на Си. Например volt.
      Так что на мой взгляд фича нужная, понятно что к этому когда-то бы пришли, но сейчас есть более важные штуки)
        +2
        Да, согласен, разработчикм Zephir стоит самим оценивать силы и приориеты. Мы конечно можем хотеть всего и сразу, но сколько всё это займет времени и сил.

        Я лично за вариант с мета-языком, так как до выхода Zephir уже можно начать формировать его экосистему — писать либы и фреймворки. При этом эти фреймворки и библиотеки будут такой же частью достоянием всего PHP сообщества.
        –1
        Не понятна целевая группа. Те кому нужны миллисекунды перепишут код на си, сэкономив ещё больше. Те кто не силён в си, вряд ли будет лезть в код, а чужие экстеншины его будут пугать из-за проблем с поддержкой, багами и совместимостью с новыми версиями самого php. Ну и как бы уже есть pecl, которым почти никто не пользуется, а кто пользуется — форкает и патчит под себя.
        Генерация php — очень сомнительное удовольствие.
        0
        Уже есть один отличный, проверенный временем, очень быстрый статически типизированный язык. На нём пишут как софт для корпораций и банков (высокочастотный трейдинг, где важны наносекунды), так и распределённые базы данных, пример — cassandra. Ну зачем ещё увеличивать энтропию и делать из php, который задумывался для совсем других целей, вот такого франкенштейна?
          +2
          С чисто практической точки зрения я скорее согласен с этим утверждением.
          Но с методологической, или, даже — философской…
          — Уже есть один отличный, проверенный временем тип орудий. Им разделывают шкуры мамонтов, рубят деревья, убивают зверей на охоте. Ну зачем ещё увеличивать энтропию и делать из блестящего, но бесполезного металла, который задумывался исключительно для украшений, вот такого франкенштейна?

          На самом деле пути эволюции неисповедимы. В мире разработаки она, собственно, только и держится на энтузиазме. И это прекрасно. Без проб и ошибок нет и развития. При этом никто не может предсказать, что получится в итоге. Никто. В этом-то и прелесть. Поэтому обязательно надо пробовать новое. Разумеется, некоторые ростки обязательно окажутся тупиковыми. Ничего страшного — это так и задумано. Важно понимать, что без тупиковых ветвей не бывает прорывов. Так что безумству храбрых стоит петь песню, а не держать их за штаны и не пущать.

          PS. Ну зачем ещё увеличивать энтропию и делать из Perl, который задумывался для совсем других целей, вот такого франкенштейна — набор утилит Pretty Home Page / Form Interpreter? ;)
          0
          Писать код с использованием всех этих вкусностей (статическая типизация, именованные параметры и проч.) и получать на выходе «чистый» PHP — идея заманчивая. Но возникает вопрос — а какой ценой? Боюсь, выходной код не всегда будет оптимальным. Но при компиляции C-библиотек это с лихвой перекрывается тем, что сам код на C выполняется в разы быстрее.

          А вот при трансляции мета-кода в PHP есть опасения, что производительность будет ниже, чем если то же самое писать сразу на PHP.
            0
            Не думаю, что если это таки реализуют — производительность php кода упадет.
            Например можно включить разные степени проверок и код будет компилироваться по разному:
            // zephir
            public function a(string b) {}
            // php:
            public function a($b) {}
            public function a($b) {
            if (gettype($b)!== 'string'){...}
            }
            

            В первом случае проверки будут только на этапе компиляции
            И я с вами не согласен, посмотрите на код, генерируемый зефиром — там все оптимизированно, и будет продолжать оптимизироваться
              0
              Я же не утверждаю, я лишь высказываю опасения. С Зефиром пока не работал, основываюсь исключительно на том, что, как правило, выигрыш в одном почти неизбежно влечет за собой проигрыш в другом. Но если разработчики смогут реализовать идею, и при этом не потерять в производительности при трансляции в PHP — то это будет реально крутая вещь. И убежден — это может оказать сильнейшее влияние на среду веб разработки

          Only users with full accounts can post comments. Log in, please.