Комментарии 122
НЛО прилетело и опубликовало эту надпись здесь
Go — это язык в котором простоту довели до примитивизма. В итоге решения часто начинают распухать на пустом месте т.к. средств языка просто не хватает, на то чтобы все это завернуть красиво.
В этом отношении даже http://nim-lang.org/ куда более удобный, правда когда пишешь на Nim не покидает чувство, что они дергали разные концепции не имея чуткого понимания того, что хотят получить, но когда пытаешься писать на Go создается впечатление, что целью было создать не простой, а именно обрезанный язык.
В этом отношении даже http://nim-lang.org/ куда более удобный, правда когда пишешь на Nim не покидает чувство, что они дергали разные концепции не имея чуткого понимания того, что хотят получить, но когда пытаешься писать на Go создается впечатление, что целью было создать не простой, а именно обрезанный язык.
целью было создать не простой, а именно обрезанный язык.
Благо это быстро проходит. Писать серверный код на Go одно удовольствие
Я видимо что-то делаю не так, ибо ничего не распухает. Но если бы пытался все делать, как привык в php или C++, то наверное так и выходило бы.
Зато если удалось "все это завернуть красиво" можно рассчитывать что и работать будет быстрее. Напротив в Haskell, Skala можно быть почти уверенным — чем элегантней код, тем он медленней.
Да, в статье чего то не хватает… Кати?
Промт
Согласен с выводами, но мне кажется тема "с точки зрения PHP программиста" не совсем раскрыта.
Когда садишься писать на Go после PHP, а особенно Symfony, думаешь о Layers, Abstractions, Interfaces, продумываешь архитектуру и заботишься о том, как этот код будет поддерживаться в дальнейшем, и в большинстве случаев… упираешься в простоту Go и приходиться опять искать другую реализацию архитектуры. В итоге главное принять и поверить — что очевидное и самое простое решение — в Go будет самым правильным, и не надо пытаться вот тут вот сделать интерфейс, а вот тут вот убрать повторение кода, чтобы следовать DRY. Мне показалось что Go диктует простую архитектуру, проблемы поддержки которой решаются именно немонолитностью кода, и после возможностей PHP в плане ООП как решения проблем монолита в это трудно поверить :)
И я бы не сказал что это минус, в выводах очень правильная мысль — PHP вначале, и когда дозрели — выносить в Go.
PS. Насчет времени инициализации и т.п., http://symfony.com/blog/new-in-symfony-2-8-symfony-as-a-microframework
Когда садишься писать на Go после PHP, а особенно Symfony, думаешь о Layers, Abstractions, Interfaces, продумываешь архитектуру и заботишься о том, как этот код будет поддерживаться в дальнейшем, и в большинстве случаев… упираешься в простоту Go и приходиться опять искать другую реализацию архитектуры. В итоге главное принять и поверить — что очевидное и самое простое решение — в Go будет самым правильным, и не надо пытаться вот тут вот сделать интерфейс, а вот тут вот убрать повторение кода, чтобы следовать DRY. Мне показалось что Go диктует простую архитектуру, проблемы поддержки которой решаются именно немонолитностью кода, и после возможностей PHP в плане ООП как решения проблем монолита в это трудно поверить :)
И я бы не сказал что это минус, в выводах очень правильная мысль — PHP вначале, и когда дозрели — выносить в Go.
PS. Насчет времени инициализации и т.п., http://symfony.com/blog/new-in-symfony-2-8-symfony-as-a-microframework
Насчет времени инициализации всё равно 11ms. Тут скорее надо давать ссылку на http://reactphp.org/.
Я бы не стал никому рекомендовать использовать ReactPHP в продакшн-системах. Удачный эксперимент, показывающий возможности PHP, не более.
А можете подробнее рассказать о причинах? Есть опыт успешного внедрения у нас в компании, у других пользователей( Fesor точно)
Разрабатываем backend'ы для мобильных приложений\игр, относительный highload, rpm 200k-500k.
Помимо ReaсtPHP — есть Icicle, c "coroutines" на генераторах.
Также есть проект http://amphp.org/ ориентированный на PHP7. Много интересного "из коробки".
И старый добрый, правда очень монолитный phpDaemon
Разрабатываем backend'ы для мобильных приложений\игр, относительный highload, rpm 200k-500k.
Помимо ReaсtPHP — есть Icicle, c "coroutines" на генераторах.
Также есть проект http://amphp.org/ ориентированный на PHP7. Много интересного "из коробки".
И старый добрый, правда очень монолитный phpDaemon
На мой взгляд, ReactPHP — это не более, чем попытка доказать, что в PHP можно делать вещи в стиле JavaScript / Node.js. В то время, как 95% всех зависимостей из npm дополняют экосистему Node.js, в PHP это — в точности до наоборот. Редкие фреймворки и библиотеки для PHP спроектированы для асинхронного программирования.
В конце концов, почему бы просто не использовать Node.js для подобных задач? Взять хотя бы его поддержку сообществом https://github.com/nodejs/node по сравнению с https://github.com/reactphp/react.
В конце концов, почему бы просто не использовать Node.js для подобных задач? Взять хотя бы его поддержку сообществом https://github.com/nodejs/node по сравнению с https://github.com/reactphp/react.
У нас ReactPHP успешно работает в продакшене. Да и зачем использовать node.js, если есть %language%
На мой взгляд, ReactPHP — это не более, чем попытка доказать, что в PHP можно делать вещи в стиле JavaScript / Node.js.
А Node.js это попытка доказать, что Javascript подходит для создания сайтов в стиле PHP. На мой взгляд.
Нет, давайте без вентилятора.
Редкие фреймворки и библиотеки для PHP спроектированы для асинхронного программирования.
Любой фреймворк, который представляет абстракцию на Request\Response отлично работает, не знаю, чтобы кто-то щас делал новые фреймворки по-другому, PSR этому способствует.
Мы используем redis и cassandra — для всего есть async экстеншны. Драйвер для mysql с очень давних времен поддерживает async, лет 5
Еще можно такой список посмотреть https://github.com/elazar/asynchronous-php
ReactPHP это попытка реализации паттерна "реактор" на PHP, и более чем успешная. И распространения это не получает особо именно из-за консервативных взглядов в духе "php должен умирать".
У меня один из проектов крутится на reactphp уже больше года в продакшене, и небыло никаких проблем (а те что были не связаны именно с reactphp а больше с тем, как изначально разработчики использовали монгу и завязали все на синхронные API).
Основная проблема PHP — отсутствие вменяемой библиотеки асинхронных/неблокируемых функций. Благо проект amphp как раз таки эту проблему рашета, а за счет корутин можно не волноваться по поводу наступления callback hell. Неблокируемый код в синхронном стиле.
Однако я все же предпочитаю для подобных задач использовать node.js, просто потому что мне лень пилить велосипеды, а для PHP их надо написать еще много (неблокируемых). Есть еще надежда на то что в PHP8 появится async/await. А может и раньше.
У меня один из проектов крутится на reactphp уже больше года в продакшене, и небыло никаких проблем (а те что были не связаны именно с reactphp а больше с тем, как изначально разработчики использовали монгу и завязали все на синхронные API).
Основная проблема PHP — отсутствие вменяемой библиотеки асинхронных/неблокируемых функций. Благо проект amphp как раз таки эту проблему рашета, а за счет корутин можно не волноваться по поводу наступления callback hell. Неблокируемый код в синхронном стиле.
Однако я все же предпочитаю для подобных задач использовать node.js, просто потому что мне лень пилить велосипеды, а для PHP их надо написать еще много (неблокируемых). Есть еще надежда на то что в PHP8 появится async/await. А может и раньше.
думаешь о Layers, Abstractions, Interfaces, продумываешь архитектуру и заботишься о том, как этот код будет поддерживаться в дальнейшем, и в большинстве случаев… упираешься в простоту Go и приходиться опять искать другую реализацию архитектуры
Потому что layers, abstraction, interfaces — средства решения задачи, а нечто самое, сущее. Просто в ряде языков, том же Java это — необходимость. Если решать задачу изначально с оглядкой на язык, все получается так же удобно, красиво и поддерживаемо. Парадигма другая, задачи решаются те же.
и не надо пытаться вот тут вот сделать интерфейс, а вот тут вот убрать повторение кода, чтобы следовать DRY
Потому что иногда это (интерфейсы, ООПизация) становится просто процессом ради процесса.
Теперь давайте вспомним, как мы меняем значения двух переменных в PHP:
$a = 1;
$b = 2;
list($a, $b) = [$b, $a];Это был пример на множественное присваивание, если что. Понятно, что через передачу указателей в функцию можно хоть и десять значений свапнуть.
list в PHP это не функция, а языковая конструкция
Согласен, php уже давно не использовал, подзабыл. Но смысла это не отменяет. Автор хотел показать, что в go можно делать так:
или так:
Что подставить на второй половине, не имеет значения. Автор использовал для примера смену двух значений. И будь в php коде это list, пример был бы неочевиден.
var1, var2, var3 := true, "text", 10или так:
var1, var2, var3 := myFunc()Что подставить на второй половине, не имеет значения. Автор использовал для примера смену двух значений. И будь в php коде это list, пример был бы неочевиден.
Согласитесь, что это синтаксический сахар. Так же можно найти какой-нибудь сахар в PHP, которого нет в Go
Прозвучало так, как будто я восхвалял golang. А вы меня осадили.
Множественное присваивание, как и множественные возвращаемые значения из функций это особенность языка, которую стоило описать в статье. Если будет статья, php глазами гофера, то там стоит упомянуть, что в php такого присваивания нет. Но зато есть что-то другое.
Множественное присваивание, как и множественные возвращаемые значения из функций это особенность языка, которую стоило описать в статье. Если будет статья, php глазами гофера, то там стоит упомянуть, что в php такого присваивания нет. Но зато есть что-то другое.
Это сахар, т.к. по факту в PHP тоже можно вернуть несколько значений из функции объединив их в массив, а с помощью list их распаковать. Получается немного больше кода, но копирует 1 в 1 возможность go.
По сути все языки высокого уровня это сахар, все то же можно было написать и на асме.
Зато эффективность этого кода несравнимая. Не надо сравнивать совершенно разные вещи. Это не просто сахар, а конструкция языка, что позволяет не костыли городить, как вы предлагаете в php, а делать все эффективно и прозрачно.
Это всего лишь одна из возможностей языка, которая может показаться интересной PHP программисту.
Автор хотел показать, что это именно отличие Go от PHP. И в этом он ошибся. Если бы он хотел просто показать множественное присваивание в Go, то про PHP там бы ничего написано не было, так же как в разделах про переменные, циклы и структуры.
В PHP тоже можно делать так, как вы написали в обоих примерах. По факту отличие только в том, что в Go определена операция "запятая", которая создает… Хм, что же она создает, уж не список ли разнотипных значений, который в PHP называется массивом?
И что подставить на второй половине значение все-таки имеет. В Go нельзя слева написать 2 переменных, справа 3, в PHP можно.
В PHP тоже можно делать так, как вы написали в обоих примерах. По факту отличие только в том, что в Go определена операция "запятая", которая создает… Хм, что же она создает, уж не список ли разнотипных значений, который в PHP называется массивом?
И что подставить на второй половине значение все-таки имеет. В Go нельзя слева написать 2 переменных, справа 3, в PHP можно.
Вполне можно
И ничего запятая не создает, это просто разделитель между разными переменными.
a, _, b = b, c, aИ ничего запятая не создает, это просто разделитель между разными переменными.
Никаких операций и созданий чего-либо в Go не происходит. Это компилируемый строго типизированный язык. Компилятор знает всю информацию о том, что, какого типа и в каком количестве возвращает функция, что позволяет скомпилировать это без всяких вспомогательных конструкций. У нас уже и так есть стек для этого.
И таки это совсем не тоже самое, что массивы в PHP.
И таки это совсем не тоже самое, что массивы в PHP.
удалено
И вас не смущает идея создания массива ради экономии двух строк? К слову.
А вас не смущает, что несколько возвращаемых значений сами по себе создают такой массив?) Кстати, не подскажете аналогичную ссылку для Go, как это происходит на низком уровне и сколько памяти занимает?
Если честно то не очень. Никого же не смущает использование фреймворка с сотнями классов (десятки из которых инстанциируются во время запроса) для простого вывода HTML в браузер.
Кстати, чисто ради интереса проверил результат на PHP 5.6 и PHP 7.0:
5.6
7.0:
5.6
echo memory_get_usage() - $startMemory, ' bytes';
// 14649168 bytes7.0:
echo memory_get_usage() - $startMemory, ' bytes';
// 4198640 bytesЭто не сильно меняет суть проблемы.
Простите за иронию, но...
Вау, чуваки! Зацените! Тут есть крестообразная отвертка и крест для свершения публичной казни! И то, и другое — крестообразное, так что очень просто перейти от одного к другому!
Ну ведь правда же "похожий" синтаксис (похожий тем, что и там, и сям есть фигурные скобки и синтаксический сахар) — это мелкая деталь на фоне двух замечательных, но совсем-совсем-совсем разных языков программирования?
Вау, чуваки! Зацените! Тут есть крестообразная отвертка и крест для свершения публичной казни! И то, и другое — крестообразное, так что очень просто перейти от одного к другому!
Ну ведь правда же "похожий" синтаксис (похожий тем, что и там, и сям есть фигурные скобки и синтаксический сахар) — это мелкая деталь на фоне двух замечательных, но совсем-совсем-совсем разных языков программирования?
Как по мне после пхп проще и логичнее всего переходить на джаву, а не на го. Тем более на горизонте котлин.
Как по мне — не стоит переходить с РНР, а достаточно учить и осваивать новые языки и писать на них. Зачем с чего-то куда-то переходить?
У нас сейчас проект с миллионом строк кода на РНР, зачем мне переходить на что-то другое, тратить год всей команды, а то и больше, чтобы перейти на что-то другое, которое как-бы лучше? Да и наш шеф то не одобрит такое…
Я уже молчу о том, что при этом будет +N багов, к уже имеющимся…
О миграции уже работающих серверах я вообще молчу...
У нас сейчас проект с миллионом строк кода на РНР, зачем мне переходить на что-то другое, тратить год всей команды, а то и больше, чтобы перейти на что-то другое, которое как-бы лучше? Да и наш шеф то не одобрит такое…
Я уже молчу о том, что при этом будет +N багов, к уже имеющимся…
О миграции уже работающих серверах я вообще молчу...
Я лишь хотел обратить внимание что по синтаксису джава ближе всего к пхп чем к примеру го. Переходить не переходить это вопрос лично каждого. Я сам лично пишу на трех языках и ничего нормально.
На самом деле, большинство багов отсеется на этапе "оно не компилится, ошибка в строке N", так-как компилятор довольно строгий и вероятность скрытых багов гораздо меньше, чем в php или js. В go сами средства языка практически не дают возможности сделать шаг влево-вправо и, я бы сказал, навязывает единый стиль кода и программирования. Я конечно больше сравниваю с nodejs, с которой работаю последние несколько лет. Но и с php тоже знаком не по наслышке.
Я имел ввиду логические ошибки. Т.к. новы язык и идеально не знаешь, что именно получишь от какой-то конструкции, к примеру.
Я просто приведу маленький пример. Новичек в php экспериментирует, с таким выражением:
Как поведет себя блок, когда в переменной будет true, 1, "1", "", " ", "string", (10 > "11") и т.д?
Тот же новичек попробует все подобные варианты в go. Тут он быстро поймет, что скомпилится только первый. Все остальные выдадут ошибку на этапе компиляции. Потому-что go принимает все прямолинейно, только булевы значения. Вот пару примеров, можно нажать и посмотреть ошибки:
https://play.golang.org/p/t_MDQBvIj1
https://play.golang.org/p/SCumk_DuV9
https://play.golang.org/p/DuGHIcdmIq
Или такой вариант:
Gо же вообще не позволяет выполнять if, for и т.д. без фигурных скобочек.
И такой подход практически во всем. Не скажу, что там вообще нет подводных камней, на которые может напороться новичек. Но все гораздо лучше в плане надежности ПО, сужу по реальному опыту применения.
if ($my_var) { /* .... */ }Как поведет себя блок, когда в переменной будет true, 1, "1", "", " ", "string", (10 > "11") и т.д?
Тот же новичек попробует все подобные варианты в go. Тут он быстро поймет, что скомпилится только первый. Все остальные выдадут ошибку на этапе компиляции. Потому-что go принимает все прямолинейно, только булевы значения. Вот пару примеров, можно нажать и посмотреть ошибки:
https://play.golang.org/p/t_MDQBvIj1
https://play.golang.org/p/SCumk_DuV9
https://play.golang.org/p/DuGHIcdmIq
Или такой вариант:
if($test)
echo "Ok";
echo "Test passed!";Gо же вообще не позволяет выполнять if, for и т.д. без фигурных скобочек.
И такой подход практически во всем. Не скажу, что там вообще нет подводных камней, на которые может напороться новичек. Но все гораздо лучше в плане надежности ПО, сужу по реальному опыту применения.
А о том, что найти специалистов на РНР куда проще, чем на GO, ну в Одессе уж точно.
Хотя и по РНР сейчас найти опытных не удаётся...
Хотя и по РНР сейчас найти опытных не удаётся...
Думаю это ошибочная мысль, ибо количество носителей языка, не свидетельствует о их профессионализме, тем более если это касается таких языков с низким порогом вхождения как php.
Да, Вы можете так считать, но я не своё мнение высказал, о озвучил, как оно есть сейчас в Одессе.
Ну те кто минусуют, если вы из Одессы, рады будем вашему резюме, присылайте и приходите на собеседование.
Есть простой способ получить неплохого разработчика на Go — берем опытного человека на php и даем ему небольшой проект на Go. Делать он его будет раза в 3 дольше (в первый раз), но в конце уже будет неплохо знать Go.
Желательно, конечно, чтобы проект для Go подходит лучше, чем для php.
Учитывая возраст и распространенность языка, такой путь будет проще и быстрее, чем ждать у моря погоды, пока появятся люди, что уже его изучили и готовы менять работу.
Желательно, конечно, чтобы проект для Go подходит лучше, чем для php.
Учитывая возраст и распространенность языка, такой путь будет проще и быстрее, чем ждать у моря погоды, пока появятся люди, что уже его изучили и готовы менять работу.
Возможно, не стану отрицать, я его ещё не смотрел, но если у нас появился опытный разработчик на РНР, чем "перековывать" его в неплохого на GO, я лучше его отправлю в команду с проектом на РНР.
- опытный РНРшник получает тоже достаточно хорошо, и менять позицию, просто так, не думаю, что ему это будет сильно интересно. Или нужно предлагать гораздо лучшие условия.
НЛО прилетело и опубликовало эту надпись здесь
А с Java на PHP — как на это смотрите?
Да вы правы, в этом нет никакого смысла вообще. Все большие проекты с хорошими бюджетами в основном на пхп написаны. Да и по производительности ему нет равных в принципе. Очень много качественных библиотек написано студентами для пхп. А особенно радует адекватность и техничексий уровень специалистов, которые пишут на пхп — общаться с ними одно удовольствие. Это все подтверждается огромных количеством пхп вакансий на рынке Европы и Америки.
обожаю ничем необоснованные суждения
Вы ответили слишком категорично, я ответил в таком же духе. У пхп своя ниша — ненагруженные проекты и админки. Я до сих пор считаю симфони вторую одним из лучших фреймворков для быстрой разработки бекенд админок. Но если глянуть шире…
1) В хайлоаде пхп проигрывает… да уже почти всем. nodejs, java, erlang, даже питон со своим GIL и то выигрывает
2) Ентерпрайз — java, с#
3) Обработка больших данных — java (привет хадуп), R, python
4) Алгоритмы искусственного обучения — опять таки java, python, c++
5) Разработка мобильных приложений — java (андроид), objective-c, swift (ios), ну и с трудом С++ (привет QT)
6) Десктоп — ну там все понятно
7) Микросервисы — опять java, привет GO (о чем статья), node возможно еще что-то. Тут еще пхп может посоперничать (если нагрузка не велика)
1) В хайлоаде пхп проигрывает… да уже почти всем. nodejs, java, erlang, даже питон со своим GIL и то выигрывает
2) Ентерпрайз — java, с#
3) Обработка больших данных — java (привет хадуп), R, python
4) Алгоритмы искусственного обучения — опять таки java, python, c++
5) Разработка мобильных приложений — java (андроид), objective-c, swift (ios), ну и с трудом С++ (привет QT)
6) Десктоп — ну там все понятно
7) Микросервисы — опять java, привет GO (о чем статья), node возможно еще что-то. Тут еще пхп может посоперничать (если нагрузка не велика)
НЛО прилетело и опубликовало эту надпись здесь
Статья не так уж и плоха, но ...
А как же магия GOPATH? Даже тот же PHP скачал, поставил, запустил — работает. А в go нужно настраивать GOPATH :(
А теперь поговорим о процессе развертки Go приложения:
А как же магия GOPATH? Даже тот же PHP скачал, поставил, запустил — работает. А в go нужно настраивать GOPATH :(
Серьезно? Подход Go как раз в том, что на GOPATH все и ограничивается. Дальше все просто работает, одной командой в консоли. Редкий компилируемый язык так может.
Ничего себе, нужно иметь научную степень, наверное, чтобы прописать переменную окружения.
А как же локальный вэб-сервер поднимать, что бы заработал php? Я думаю это совокупно GOPATH.
Нубский вопрос про деплой Go веб-приложения на Windows. Начал изучать язык, собрал exe простейшего приложения на Gin, залил его на виндовс сервер, через рдп запустил, на IIS настроил reverse proxy на порт приложения. Все вроде бы хорошо, но хочу залить обновление, а процесс приложения не дает перезаписать exe через ftp. Есть ли какие-то общепринятые методы деплоя, желательно без ручного вмешательства в остановку-запуск приложения. И существует ли что-то вроде Node.js-ного Forever, рестартующего веб-апп в случае вылетания по эксепшну?
Каждый PHP разработчик знает, что, если ему удасться довести время инициализации большого монолитного приложения до 30мс, это отличный результат! Добавить к этому 50-100мс для обработки самого запроса, и перед нами поразительное общее время ответа.
Symfony2, nginx+php-fpm, простой запрос — время ответа 20-30мс. И это на тяжёлом фрэймворке с кучей зависимостей и библиотек.
Golang, библиотека gin, CRUD на БД, время ответа от без нагрузки на БД — 1-10мс. Разница существенна. Но не критична. Если на php убрать обвязку из Symfony, то разница ещё больше сократится.
Развертка приложения — необходимое действие и не зависит от языка программирования и того, что пишут с его помощью. Будучи PHP программистом, сколько Capistrano или Envoy конфигураций вы написали за свою профессиональную карьеру? Сколько файлов, измененных вручную, вам приходилось переносить на хостинг-провайдеры во времена FTP?
Далее приводиться огромный список шагов, который не отражает действительность. Первичная настройка капистрано — 5 минут. Деплой — одна консольная команда. Go тут не предоставляет ничего нового, процесс нисколько не отличается. Тот же самый перенос исполняемого файла и конфигов на сервер. И для этих целей я использую тот же самый капистрано. Только для Go появляется предварительный этап — компиляция с нужными флагами.
Складывается впечатление, что автор не знаком с php. Бесспорно, golang эффективнее чем php для написания микросервисов, но статья вводит в заблуждения относительно не эффективности php.
Сейчас в своей работе я использую связку ruby + golang. На обоих языках написано несколько "микросервисов". Основное выявленное преимущество Go — более низкое потребление памяти и боле эффективная работа с внешними асинхронными запросами.
В разделе про публикацию PHP приложений последним пунктом идёт "Перезапустить PHP-FPM" — зачем? Выкладываем новые исходники и они просто работают! Причём текущие запросы не будут сброшены. А с go приложением, получается, при перезапуске процесса мы можем потерять запросы которые были где-то в середине процесса обработки! Или есть способ zero-downtime перезапуска go приложения?
Можно же перезапуск устроить так, что он не будет отстреливать всё, а дожидаться завершения последнего запроса. Как nginx c reload
Graceful shutdown + load balancer + несколько инстансов приложения, обновляемых по очереди. Вот вам и zero downtime.
Это нормальная практика для всех приложений, будь то go, python, java и прочее, что висит как процесс
Это нормальная практика для всех приложений, будь то go, python, java и прочее, что висит как процесс
Руками придётся писать же, не?
Все зависит от того, что используете. В finagle на scala есть graceful shutdown из коробки. Наверняка есть готовые решения для множества платформ
Для Go не было.
Из коробки нет, но есть множество пакетов, типа https://github.com/facebookgo/grace
Рекомендуете именно этот?
Порекомендовать не могу, так-как сам не использую.
Вообще, есть еще варианты, например простой пакет https://github.com/tj/go-gracefully от авторов известного фреймворка express для nodejs
Вообще, есть еще варианты, например простой пакет https://github.com/tj/go-gracefully от авторов известного фреймворка express для nodejs
При наличии OPcache или APC, новые изменения не будут "просто работать".
Команда очистит кэш и принудит его пересоздание при первом обращении.
В случае Go приложения, если есть несколько образцов приложения, проблем возникнуть не должно (как пояснил ImLiar). С одним же образцом можно запустить новую версию на соседний порт, перенаправить запросы с веб-сервера на него, и отключить старый после короткого ожидания.
$ php5-fpm reloadКоманда очистит кэш и принудит его пересоздание при первом обращении.
В случае Go приложения, если есть несколько образцов приложения, проблем возникнуть не должно (как пояснил ImLiar). С одним же образцом можно запустить новую версию на соседний порт, перенаправить запросы с веб-сервера на него, и отключить старый после короткого ожидания.
Не могу согласиться, что только в памяти дело. У меня зачастую время ответа скрипта на golang — микросекунды, миллисекунды — при сколько-либо существенной нагрузке.
Синтетика конечно, но все же
Если время ответа CRUD сервиса на Go составляет 10мс, я бы занялся поиском причин.
А разве то, что делает эта консольная команда, — не тот же самый "огромный список шагов"?
Далее приводиться огромный список шагов, который не отражает действительность. Первичная настройка капистрано — 5 минут. Деплой — одна консольная команда.
А разве то, что делает эта консольная команда, — не тот же самый "огромный список шагов"?
Если время ответа CRUD сервиса на Go составляет 10мс, я бы занялся поиском причин.
Причина — время ответа от БД, и тут без разницы, golang, php, python, ruby. На php время ответа будет в пределах 50мс, что конкретно в моём случае не критично.
А разве то, что делает эта консольная команда, — не тот же самый «огромный список шагов»?
Тот же самый. Там может быть хоть 100 шагов. Можно и golang приложение каждый раз компилировать, переносить на сервер и вручную перезапускать. А можно воспользоваться готовыми инструментами, которые всё сделают сами. И под php\python\ruby эти инструменты сейчас заточены гораздо лучше.
В PHP (классическом с умиранием) соединение с БД делается каждый раз, если не используется persistent connect (в котором много подводных камней). В Go соединение делается один раз и далее повторно используется.
И при этом в Go значительно проще организовать кеширование, фильтр Блума, hyperLogLog и многие другие вещи, которые помогают вообще не делать запросы в базу при каждом обращении.
Факт. С другой стороны, при наличии нескольких инстансов фронта это всё усложняет приложение неимоверно, хоть и даёт отличную производительность.
Это тоже правда, все зависит от архитектуры конкретного приложения. Как пример, недавно была задача банального инкремента на нескольких инстансах, решение было тоже банально, инкремент на накопленное значение из каждого инстанса n раз в секунду. Если бы в том же случае осуществлялась прямая запись, нагрузка на базу была бы критичной на существующих мощностях, и думаю даже на значительно больших.
Даже все хитрее. В Go sql.DB это не соединение, а пул, который сам создает, переиспользует и убивает соединения до базы.
в котором много подводных камней
На самом деле эти "подводные камни" заключаются лишь в том, что бы люди убирали за собой, а не надеялись что PHP волшебным образом отменит незавершенные транзакции и т.д. Ну то есть та же проблема, по которой понадобились сборщики мусора, или та проблема, из-за которой среднему php-нику нельзя давать работать с тредами или "не умирающим пыхом". Возьмут ребята какой-нибудь react/amphp, впихнут туда доктрину синхронную, и потом кричат направа налево, что PHP не подходит для реализации эффективных решений.
Реализовать небольшую оберточку поверх PHP, которая по завершению запроса будет "невилировать" сайд эффекты текущего запроса, это как бы не сложно.
Многие компании, такие как Facebook, Yahoo!, Wikipedia, Wordpress, Tumblr, начинали свою историю с PHP
Yahoo! в этом списке вероятно по ошибке. Yahoo! на несколько лет старше, чем PHP.
«Многие компании, такие как Facebook, Yahoo!, Wikipedia, Wordpress, Tumblr, начинали свою историю с PHP»
Альтернатив просто не было. А те что были были еще хуже.
Альтернатив просто не было. А те что были были еще хуже.
замечательные черты, как легкий параллелизм…
…
вы должны знать две вещи о параллельности в Go — горутины и каналы.
…
Горутина имеет простую модель: это функция, выполняемая параллельно с другими горутинами в едином адресном пространстве.
Чувак ни фига не понял.
Честное замечание. Я пытался найти более подходящий перевод для "concurrency". Обновлю статью, если посоветуете.
Интересные и удобные конструкции, но новичкам лучше с него на начинать. Иначе новички не поймут, что собственно упрощалось и объединялось, и почему можно по другому.
Перевод нормальный ребята, прочитал понял суть вроде не Перельман :) Собит молодчик хорошая статья. Привет из 2шанбе :)
Друзья, поясните пожалуйста, а что произойдет, если someHeavyOperationToFindTheName не успеет заполнить "c" до момента ее использования? Как понять заполнила ли она "c" или нет? Есть событие?
Строчка
сначала будет вычислять аргументы в таком порядке:
чтобы не ждать, можно делать, например, так:
fmt.Printf("Employees: %s, %s", <-c, <-c)сначала будет вычислять аргументы в таком порядке:
"Employees: %s, %s", <-c, <-c. То есть для вывода на экран значений она сначала вытащит два значения из канала. Если в канале значений нет, то "<-" будет ждать их появления.чтобы не ждать, можно делать, например, так:
select {
case str := <-c:
// значение было в канале и мы его вытащили в str
default:
// канал еще пуст
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Go с точки зрения PHP программиста