В статье я не рассматриваю ReactPHP намеренно, поскольку не имел с ним дела, пишут про него неплохие вещи, но я не могу судить о том, с чем не сталкивался. Поэтому исходим из стандартного подхода к работе на PHP.
Миф 1
Язык GoLang не для всех
Может быть, что безусловно верно для любого языка программирования. Но благодаря тому что GoLang язык типизированный мы вынуждены более тщательно следить за своим кодом и большинство ошибок видим еще до того, как залили код на сервер при компиляции. Это не только сильно уменьшает массу неприятных вещей вроде ошибок на сервере, но и заставляет быть более организованными. Кроме того настроить домашнее окружения в GoLang гораздо проще чем в том же PHP. Достаточно установить только сам Go пакет и все готово к работе. Напомним что для установки и работы PHP нужно поставить: PHP, сервер типа Nginx или Apache. Настроить всю эту связку, правильно выстроить параметры запуска, проверить все ли нужные модули у нас подключены…
Получается что порог вхождения в язык GoLang если и выше то не намного, любой редактор IDE при работе с GoLang всячески будет подсказывать наличие большинства возможных проблем в коде прямо в процессе написания кода.
Миф 2
На GoLang трудно писать код
Отчасти с этим можно согласиться. Но писать код можно по разному. Можно писать микросервисы, можно писать целые сервера. Для начала возьмем код для написания программы Hello World. И написания сервера http который будет выводить эту надпись в проводнике.
PHP
<?php
print ("Hello World");
GoLang
package main
import (
"fmt"
)
func main() {
fmt.Println("Hello, world!")
}
Теперь сервер
PHP
<?php
print ("Hello World");
GoLang
package main
import (
"io"
"log"
"net/http"
)
// hello world, the web server
func HelloServer(w http.ResponseWriter, req *http.Request) {
io.WriteString(w, "hello, world!\n")
}
func main() {
http.HandleFunc("/hello", HelloServer)
log.Fatal(http.ListenAndServe(":12345", nil))
}
Я намеренно продублировал код на PHP в обеих случаях. На GoLang кода вроде больше, но в реальности мы пишем только одну строчку для простой программы и две функции для сервера. Все буквально в 3 строчки кода. Остальное заполняет IDE редактор, если вы им пользуетесь. PHP лидирует? Нет. Мы забыли что сервер на PHP можно запустить, но сами разработчики настоятельно рекомендуют его не задействовать из-за крайне нестабильной работы. А значит нам нужно проделать очень много шагов по запуску сервера, подключения к нему PHP расширения, настройки виртуального хоста, прописать все это в файле hosts. И так для каждого нового проекта. Для PHP есть еще сервер reactphp, работающий с помощью библиотеки «libev», но это уже не совсем классический PHP и нужно учитывать целый ряд минусов, таких как возможный долгие блокирующие вызовы
sleep
file_get_contents
file_put_contents
mkdir
fsockopen
PDO
mysql_*
etc.
могут вызвать проблемы если не выделять такие вызовы в отдельный процесс.
Плюс еще взаимодействие между процессами весьма спорное. Использовать для этого дополнительные библиотеки типа ключ-значение как-то странно.
А встроенный сервер и вовсе: php.ru
Внимание
Этот веб-сервер был разработан для помощи в разработке. Он также может быть полезным в тестовых целях или для демонстрации приложения, запускаемого в полностью контролируемом окружении. Он не выполняет функции полноценного веб-сервера и не должен использоваться в общедоступных сетях.
Конечно, есть проекты которые успешно работают со всем этим, но я бы не сказал что это проще чем в Go.
А GoLang позволяет запускать проекты из любой папки без дополнительных телодвижений.
Отдельно можно рассказать о расширениях в GoLang-e. Все расширения написаны на Go (конечно есть вставки на Assembler-е). И при разработке можно посмотреть как работает та или иная функция, написать у себя похожую и полноценно ее использовать.
GoLang
func ListenAndServe(addr string, handler Handler) error {
server := &Server{Addr: addr, Handler: handler}
return server.ListenAndServe()
}
Пример сервера приведен прямо из документации к функции ListenAndServe.
На PHP используются костыли. Для просмотра свойств функции используется специальный справочник, который описывает только принимаемые и возвращаемые параметры. Можно конечно посмотреть исходник PHP. Но тут небольшая заминка. Исходный код модулей написан на C++.
PHP_FUNCTION(foo) {
char* input;
int inputLength;
long multy;
char* result;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sl", &input, &inputLength, &multy)) {
return;
}
result = (char*) emalloc(strlen(input) + sizeof(long) + 3);
sprintf(result, "%s, %ld", input, multy);
RETURN_STRING(result, 1);
}
Пример взят из статьи.
Поэтому можно не только быстро освоить написание кода, но и быстро освоить правильное написание кода.
Миф 3
GoLang плохо подходит для написания сайтов
На вскидку вижу вместо одного мифа сразу несколько. Но посмотрим на код из первого мифа, написать на GoLang веб сервер с выводом любого контекста очень просто. Значит можно написать и целый сайт. Для этого можно самому написать обработчик, выводы, роутер и т.д. Но для начала можно использовать любой framework вроде Martini, BeeGo. Тот же BeeGo имеет встроенную систему кеширования, умеет работать с кукисами, имеет расширенные функции работы с шаблонизатором и поддержку мультиязычности. Кроме того имеет консольную утилиту bee, с помощью которой можно создать полноценное веб приложение используя только одну команду. Так же можно создавать контроллеры, модели, миграции, шаблоны. И сами команды и структура файлов и роуты сильно напоминают symfony в PHP. Причем судя по описанию на официальном сайте sympony PHP — это «High Performance PHP Framework for Web Development». С поледним утверждением о высокой производительности я бы сильно поспорил.
Как видим для написания сайтов GoLang так же имеет достаточное количество инструментов. К примеру мой сайт написан c использованием фреймфорка BeeGo. Так же можно посмотреть официальный сайт этого фреймворка. Скорость загрузки моего сайта очень высокая. не смотря на то что: на нем не задействована система кеширования, каждая ссылка проверяется на право доступа, каждая страница перед загрузкой проверяется на право доступа. Права доступа хранятся в базе данных (кроме основных). Все это работает на одном из самых дешевых серверов VPS.
Миф 4
Разработка сайта на GoLang очень затратна
И да и нет. Сайт визитку делать возможно слегка дороже, но тяжелый сайт или даже средний возможно и дешевле. А весь вопрос кроется в технологиях. Точнее в их количестве. Используя GoLang можно отказаться от сопутствующих вещей. К примеру memcache, redis, nodejs, nginx и прочих без потери в скорости или функционале. Все это прекрасно можно организовать средствами GoLang. Причем некоторые вещи даже проще. На моем сайте я добавил в меню лампочку которая может быть зеленой или красной. Она сигнализирует о том, есть ли связь сайта с сервером. Таким образом мой сайт является сайтом-чатом. Любое изменение на сервере можно мгновенно показать на клиенте. К примеру коментарии или количество пользователей на сайте показывает реальное а не виртуальное как обычно организуют в PHP.
Веб сокет можно организовать на том же порту что и основной сервер. Причем на разработку сайта из примера у меня ушло примерно 80 часов с учетом полного отсутствия опыта в данном фреймворке (BeeGo).
Получается что за счет более строгой типизации и сужения стека используемых технологий стоимость разработки сайта может быть даже ниже чем на PHP, а взамен мы получаем более быструю систему в целом.
Миф 5
На GoLang нет ООП
Это наверное самый острый вопрос, который волнует всех. Вспомним слова Алана Кэй который и придумал ООП:
Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++
Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениямиА вот с этим в GoLang все впорядке. Более того, ООП в PHP по сравнению с ООП в GoLang кажется ущербным (лично мое мнение). Все эти NameSpace как затычки и невозможность множественного наследия, награмождение всевозможных паттернов как результат усложняют работу (тот же fabric паттерн). В GoLang и с объектами и с наследием любой вложенности все более чем удобно. Тут многие могут поспорить, поэтому допишу — сугубо мое мнение.
Эти цитаты я взял с данной статьи, где вы можете более подробно прочитать на эту тему.
Миф 6
Компиляция — это очень сложно
Можно согласиться частично. Компиляция заставляет делать лишние телодвижения. Но вот скорость — это один из самых больших плюсов в GoLang. А если используете BeeGo, то можно вообще компилировать бинарный файл динамически. Но на выходе мы гарантированно проверяем наличие по крайней мере синтаксических ошибок.
К примеру мой сайт компилируется менее 5 секунд.
Миф 7
GoLang сложно запускать под разные платформы.
Мы знаем что PHP благодаря тому что является скриптовым языком можно запускать на любой платформе. А GoLang с его компиляциями делать это сложнее.
Опять и да и нет. Запустить вы сможете на любой платформе где стоит Go. Так же вы сможете запустить программу к примеру на телефоне, на маршрутизаторе, на windows, и еще много других платформах. И все это без изменения кода. Достаточно указать нужные флаги компилирования.
GOOS=windows GOARCH=386 go build
GOOS=linux GOARCH=amd64 go build
GOOS=windows GOARCH=amd64 go build
Миф 8
GoRoutines или потоки это очень сложно
В GoLang для работы с потоками есть основная команда «go». Все что нам нужно — это запустить функцию в потоке (именованную или анонимную). И все. А для синхронизации данных можно использовать либо общую переменную (срез или карту), либо каналы. Только если мы работаем с переменными не забывать перед считыванием-записью данную переменную лочить и разлачивать. Это все что нужно знать. Другими словами использование потоков в GoLang настолько простое, что через некоторое время забываешь о том что это поток отдельный. Иногда это даже приводит к ошибкам (к примеру забываем лочить общие переменные).
Далее примеры использования потоков
// A _goroutine_ is a lightweight thread of execution.
package main
import "fmt"
func f(from string) {
for i := 0; i < 3; i++ {
fmt.Println(from, ":", i)
}
}
func main() {
// Suppose we have a function call `f(s)`. Here's how
// we'd call that in the usual way, running it
// synchronously.
f("direct")
// To invoke this function in a goroutine, use
// `go f(s)`. This new goroutine will execute
// concurrently with the calling one.
go f("goroutine")
// You can also start a goroutine for an anonymous
// function call.
go func(msg string) {
fmt.Println(msg)
}("going")
// Our two function calls are running asynchronously in
// separate goroutines now, so execution falls through
// to here. This `Scanln` requires we press a key
// before the program exits.
fmt.Scanln()
fmt.Println("done")
}
Миф 9
GoLang сложно запустить на сервере
Подсознательно многие думают что для запуска GoLang нужно что-то шаманить, настраивать, проверять совместимости и т.д.
На практике весь деплой намного проще чем на том же PHP. В большинстве случаев заканчивается просто копированием одного файла на сервер и его запуска. Если это сайт, то возможно нужно еще статические файлы перенести. Статические — это какие-то картинки, стили, шаблоны, прилагаемые документы, файлы настроек.
На практике деплоить GoLang гораздо проще чем PHP файлы. Вот тут уже не нужно будет vagrant запускать у программистов что бы соблюсти все настройки сервера, не нужно виртуальной машины что бы к примеру с windows запускать unux консоль. Таких нюансов очень много и описывать их можно долго.
Надеюсь, данная статья поможет кому-то с ответами на вопросы, описанные выше. Если есть другие вопросы, пишите в комментариях. Сразу напишу, что всех ответов я не знаю, но если сталкивался с чем-то похожим, то обязательно напишу.
Комментарии (119)
JimmDiGreez
02.05.2018 15:48+1«Ущербными» нейпспейсами и подобным страдает не один только плохой пхп, но и большинство других языков. Ближайшая цель проста и ясна, как день — избежание конфликта имен. Их, конечно, и без специальной языковой конструкции можно накостылять при острой нужде, но зачем? Про множественное наследование ничего не буду говорить, видел много споров, которые в этой стезе заходили в тупик всегда.
Nginx и прочие плохие технологие и перед go, я уверен, будут поставлены. Врядли даже при всей мощи и скорости go мало кто захочет действительно повторять опыт таких развитых решений на боевом проекте и тратить на это время. Аналогично из Вашего примера в статье — redis. Может и хочется очень сильно написать in-memory key-value хранилище, с поддержкой кластеризации, регулярных и аварийных дампов содержимого на физические носители, pub/sub механизмом и прочего — но это как вообще понимать? Я пока эти лишь некоторые функции перечислял — уже мог бы редис в проект воткнуть и не париться. Предлагаю обратиться к разработчикам этих технологий с Вашим тезисом «я легко это напишу на go под задачу и не потеряю в скорости и функциональности».
Брать примеры из статьи 2009го года, как минимум, невежливо. При желании сейчас на любом языке, включая пхп, есть уйма event-loop технологий, которые так же в состоянии запустить сервер одной командой с консоли. Плюс докер/вагрант с настраиваемым окружением из конфига, пробросом портов на локалку и так далее. (еще и деплой можно с них прямо сделать).
Про скорость, конечно же, спорить не буду. Но если на go преобладают такие настроения сейчас — это сильное отставание в веб разработке породит.Ihariv Автор
02.05.2018 15:56-3PHP был взят как пример и как язык, о котором я имею полное право судить, имея за плечами >12 лет разработки на нем. Сервер на PHP запускать нельзя — это написано в официальной документации. Неймспейсы — сами по себе не такие и ущербные, просто их использование в PHP — костыль, рожденный из-за необходимости. Насколько я помню, все скрипты, заинклюженные через php считаются практически одним файлом. И уникальность имен нигде не проверяется. В принципе все верно, по другому и нельзя…
Grebenshikov
02.05.2018 16:29При всем уважении, но в какой момент времени закончились эти 12 лет?
Если вы всерьез сравниваете built in сервер в php который изначально был создан исключительно для запуска разработчиком на локалхосте (по моему, он даже синхронный и однопоточный) с сервером реализованным средствами самого языка (при том, это можно сделать и на php (reactphp/react)) то у есть некоторые сомнения в вашей компетентности.
И да, что бы запустить такой сервер, действительно не надо ничего кроме php-cli. И вы можете точно так же запустить http и websocket сервер в одном приложении, на одном порту.Ihariv Автор
02.05.2018 16:57-2При всем уважении, но в какой момент времени закончились эти 12 лет
Давайте не переходить на личности. Где было хоть слово про reactphp? К тому же reactphp — это отдельная библиотека, которую так же надо готовить. И не говорите что писать http сервер на нем так же просто и тривиально как на go. Тем более статья то не о PHP.
Ihariv Автор
02.05.2018 17:01Возможно я ошибаюсь, но в примерах reactPHP
$wsSocket->listen(4444, '0.0.0.0');
вроде как порт блокируется при создании вебсокета
Ihariv Автор
02.05.2018 16:03-3Nginx и прочие плохие технологие и перед go, я уверен, будут поставлены. Врядли даже при всей мощи и скорости go мало кто захочет действительно повторять опыт таких развитых решений на боевом проекте и тратить на это время.
На моем сайте нет nginx. Именно благодаря этому я на 80 порт подвесил еще и вебсокет. И могу еще много чего навесить. Просто зачем там Nginx?
Про 2009 год можно поновее пример привести? что бы отразился на сути самой статьи?
Но если на go преобладают такие настроения сейчас — это сильное отставание в веб разработке породит.
можно поподробнее? какие отставания? если я могу сейчас на своем сайте показывать информацию как на десктопном приложении? Количество пользователей реально в онлайне, а не обновлял страницу 5 минут назад? На php без всяких доп приложений так сделаете без постоянных пингов?Crysdd
02.05.2018 17:12Запустить вы сможете на любой платформе где стоит Go
Это не верно. GO не нужно устанавливать, достаточно бинарника программы.
Просто зачем там Nginx?
А если надо на одном сервере запустить 2 и более сайтов?
JimmDiGreez
02.05.2018 17:22Сервер на PHP запускать нельзя — это написано в официальной документации.
Есть веб-сервер, который можно использовать в тестовых целях, но крайне не рекомендуется использовать в бою. Это написано в официальной документации, и это не тоже самое что «запускать нельзя». Захочу и запущу, меня никто убивать за это не придет. А так я могу и про go сказать, что «запускать нельзя», ибо на мой взгляд это не полнцоенная замена тому же nginx на проектах от среднего и выше масштабов. Однако не вижу в этом проблем, т.к. язык не обязан быть по совместительству веб-сервером.
Если не устраивают все достижения сообщества в виде сторонних технологий (event-loop реализации те же) — то ок, будем считать, что богатая экосистема пхп как аргумент не принимается. Только тогда и фреймворк BeeGo незачем было упоминать в контексте статьи, а то двойные стандарты.
На php без всяких доп приложений так сделаете без постоянных пингов?
Вот честно, из всех проектов, с которыми довелось поработать, только 1 был с «пингом» под капотом. Но там и проекту то было лет больше, чем Вы указали в опыте своей работы. Может Вы даже с ним сталкивались в свое время и «осадочек» остался, как и у многих. Если найдете из современного что-то подобное, то у меня будут плохие новости для автора. А пока что Вы показываете, что ваши знания о разработке на php серьезно устарели.
На моем сайте нет nginx. Именно благодаря этому я на 80 порт подвесил еще и вебсокет. И могу еще много чего навесить.
Не буду вспоминать и врать, поднимал ли вебсокеты именно на 80 порту, но не вижу причин, по которым нельзя это сделать на том же nginx. Да и стандартом рекомендуется 80 и 443 порт, как и для http(s).
В том же Nginx на один и тот же порт можно множество разных правил задать, никто не мешает по одному правилу отдавать статику, по другому отправлять на http бекенд, по еще одному на websocket и все не слезая со стандартных 80/443. Думаю те, кто прямо сейчас имеют под руками конфиги nginx с реализацией подобного могут Вам показать пример, я только позже смогу в своем покопаться, придется подождать.
Просто зачем там Nginx?
У Вас все требования на данный момент укладываются в «удобно навесить все сразу на один порт», а вещи вроде отдачи статики, балансировок нагрузки, проксирования и прочего раз Вам конкретно сейчас не понадобились, то и не нужны получается. Ну с этим я поспорить не могу, судя по сайту, вполне может так и окажется, он небольшой.
Неймспейсы — сами по себе не такие и ущербные, просто их использование в PHP — костыль, рожденный из-за необходимости.
Я понимаю, что вспоминая историю php легко сказать, что там все хорошее впихивалось только как «костыль».
Современный php — это строгое следование стандартам разработки, за плохой код и решения без вопросов устраивают разбор полетов, обмениваются опытом и лучшими практиками, а не «и так сойдет». Те времена уже в лету канули.
Автозагрузка вместе с неймспейсами, кстати, решает задачу конфликта имен, если специально не вмешаться в этот уже стандартизированный процесс навешиванием автозагрузчиков, не следующих стандарту. Думаю очевидно, что такое уже не приветствуется.Ihariv Автор
02.05.2018 17:36Вот честно, из всех проектов, с которыми довелось поработать, только 1 был с «пингом» под капотом.
Придираюсь к словам, но к примеру на gmail.com я вижу пинги. По мне вполне современный проект. Возможно пинги не такие как когда-то раз в секунду, а по событию активности, или раз в 30 секунд, но суть не поменялась. Недавно ставил на проект сервис нотификации с использованием редиса и socket.io так там даже в настройках нужно указывать интервал пингов. Тоже вроде современная технология. На facebook тоже вижу явные пинги периодические. А чат так вообще только на пингах.JimmDiGreez
02.05.2018 17:48Хм, если Вы об этом, то в протоколе websocket есть опция ping/pong, описывающая фреймы для опроса сторонами жив там партнер или нет. Настраивается под ситуацию. Смотря как нужно соединение держать.
gmail и facebook, не спорю, возможно и пингуют по http еще, опять же штуки писавшиеся в давние времена, как мы все знаем, легаси проекты сложно мигрировать. Утверждать не буду на их счет ничего. Может там и long-polling какой-нибудь.
Я работал с одной cms в начале своего пути, вот там эти http пинги завалилвали лог запросов посекундно, аж смотреть было больно. В последующих проектах не встречал подобного.Ihariv Автор
02.05.2018 18:02-1у меня так socket.io заваливал логи. Для вебсокета вообще пинг-понг это не об этом я пишу. идет пинг-понг по http запросу. его можно ставить меньше или больше. Но мы отказались от использования данной технологии вовсе. Сейчас все работает и без пингов и без socket.io. Возможно проблема в малом опыте данного разработчика.
kahi4
02.05.2018 21:10+1Вы удивитесь, но что Гугл, что фейсбук не используют сокеты не потому что не могут, а потому что не хотят, это их осмысленный выбор. ответ гугла
От себя добавлю, что сокеты зачастую создают больше боли, чем решают задач, имею свойство отваливаться и вообще вести себя сомнительно на больших проектах с большой нагрузкой в реалтайме. Проще и эффективнее «пинговать».
Ihariv Автор
02.05.2018 17:16Это не верно. GO не нужно устанавливать, достаточно бинарника программы.
там ниже по тексту есть продолжение
Так же вы сможете запустить программу к примеру на телефоне, на маршрутизаторе, на windows, и еще много других платформах
для многосайтовасти — возможно да. но тогда сами себя лишаем интерактивности и добавляем лишние сложности. Для дев и тестовой машины достаточно запустить на разных портах. Для прода — я бы подумал о технологиях.
DorianPeregrim
02.05.2018 17:30+2Автор мифы сам придумывал?
Ihariv Автор
02.05.2018 17:39-2Хотел пару источников вопросов привести, но подумал, что и так топик загруженный получается. Но вопросы типа, смогу ли я писать на go достаточно частые. можете сами поискать.
rbobot
02.05.2018 18:48-2Разработчики похапе узнают о том, что есть и нормальные языки.
Ihariv Автор
02.05.2018 18:58-1есть и нормальные языки.
Зачем вы так. PHP отличный скриптовый язык. Однако порой из-за очень низкого старта встречаются не совсем адекватные разработчики, которых кидает то в одну сторону то в другую. В принципе такое может быть абсолютно в любой сфере. На GoLang такое может быть то же, но из-за общего количества программистов чисто статически такое встречается реже.anjensan
04.05.2018 13:15Однако порой из-за очень низкого старта встречаются не совсем адекватные разработчики, которых кидает то в одну сторону то в другую
Одной из фич Go заявляется «низкий старт» (и отчасти это так). Go-евангелисты постоянно об этом твердят. Так что сравнение с PHP в этом ключе весьма спорно.
Shtsh
02.05.2018 20:25+2Честно говоря, странная статья. Автор, судя по всему, совсем без опыта разработки сложных систем, борется с мифами, которые сам придумал.
Претензии, которые я слышал к Go где-то пару лет назад были такие:
- ручной разбор ошибок — боль
- нет дженериков
- жуткая работа с зависимостями
- нету удобного дебага
rbobot
02.05.2018 20:47-2Ручной разбор ошибок, боль лишь первый месяц, когда понимаешь, что теперь тебе сразу и на месте нужно решать что делать, если что-то пойдет не так, а не откладывать этот вопрос на потом.
На практике оказалось, что дженерики не особо и нужны, главное, что интерфейсы есть иинастоящая утиная типизация, без явного указания того, что класс (на деле структура с функциями) реализует интерфейс. Очень круто получилось на деле.
С зависимостями не супер удобно, но вполне работоспособно. Сейчас этот вопрос решается с новыми силами и целенапоавленно, а пока следует хранить свои проекты в папке в GOPATH и не париться. Ну действительно так-себе наезд.
Дебаггеры уже везде почти ок, бывает ломаются в горутинах, но по ощущениям нужны они сильно реже чем в других языках банально из-за навязанной простоты концепций и абстракций.
А вообще не стоит по этому поводу кого-то слушать, а стоит потратить неделю и попробовать самому. Там действительно низкий порог вхождения и лояльность к новичкам в виде сугубо структурной, не высоколобой ооп, парадигмы.SirEdvin
02.05.2018 21:00+2Ручной разбор ошибок, боль лишь первый месяц, когда понимаешь, что теперь тебе сразу и на месте нужно решать что делать, если что-то пойдет не так, а не откладывать этот вопрос на потом.
Это самообман. Что-то все популярные проекты на go с открытым исходным кодом, которые я смотрел (consul, docker, kubernetes) занимаются пробросом ошибок хотя бы на один-два уровня.
На практике оказалось, что дженерики не особо и нужны, главное, что интерфейсы есть иинастоящая утиная типизация, без явного указания того, что класс (на деле структура с функциями) реализует интерфейс. Очень круто получилось на деле.
Это тоже самообман. То, что вы можете решить проблему без дженериков не знает, что проблемы отсутствия дженериков нет. Вместо дженериков используется слишком много кодогенерации и куча приведений в духе
x = Float64(round(Float32(x))). Я тоже могу заявить, что локальные переменные не нужны и все можно написать на brainfuck, а потом использовать генератор кода из python в brainfuck. Делает ли это brainfuck применимым?
С зависимостями не супер удобно, но вполне работоспособно. Сейчас этот вопрос решается с новыми силами и целенапоавленно, а пока следует хранить свои проекты в папке в GOPATH и не париться. Ну действительно так-себе наезд.
Нет. В go просто нет управления зависимостями, вам просто предлагают хранить весь код в одной папке и не дают встроенных инструментов для нормального управления зависимостями и версионированния. Более того, из-за того, что в языке этого не было, большое количество проектов так и не выпустило релизы и предлагает вам брать какие-то коммиты из их репы и использовать.
Да, вы можете прикрутить dep или еще что-то, но вот какой смысл, если половина нужных вам библиотек вполне может это все не поддерживать?
rbobot
03.05.2018 09:15Это самообман. Что-то все популярные проекты на go с открытым исходным кодом, которые я смотрел (consul, docker, kubernetes) занимаются пробросом ошибок хотя бы на один-два уровня.
Это не противоречит, мой поинт был в том, что подход go дает повод задуматься о том, что делать в случае ошибки, а не в том, что её нельзя пробрасывать выше.
Это тоже самообман. То, что вы можете решить проблему без дженериков не знает, что проблемы отсутствия дженериков нет.
То, что я могу решить проблему без дженериков — именно и значит, что проблемы нет. Вероятно в некоторых случаях без дженериков хуже чем с дженериками, вероятно интерфейсы и кодогенерация — не всегда лучший выбор, но пока я до таких случаев не дорос и «обманываться рад».
Да, вы можете прикрутить dep или еще что-то, но вот какой смысл, если половина нужных вам библиотек вполне может это все не поддерживать?
Да, именно dep сейчас решает все мои проблемы, может быть есть библиотеки, которые его не поддерживают, но у меня такого опыта нет.
Мой поинт был в том, что следуют попробовать язык самому и самому сделать вывод о том на сколько все описаные проблемы — проблемы. Все описаные претензии решаемы и на практике они доставляют неудобство только первые пару дней, вместе с тем отнюдь не мешают получать удовольствие от языка.
Возможно у меня еще не прошел период «романтической влюбленности», но это мой опыт и он не претендует на звание абсолютной истины.
VolCh
03.05.2018 09:43+3> То, что я могу решить проблему без дженериков — именно и значит, что проблемы нет.
Вы можете решить любую (почти) проблему разработки путём кодирования в машинных кодах. Это не значит, что в языках, платформах и т. п. нет разнообразных проблем, которые их разработчики пытаются решить тем или иным способом, или просто перекладывают их решение на пользователей.
SirEdvin
03.05.2018 09:52+1Это не противоречит, мой поинт был в том, что подход go дает повод задуматься о том, что делать в случае ошибки, а не в том, что её нельзя пробрасывать выше.
Я уже не первый раз встречаю этот аргумент и совсем не понимаю почему? Возможно, первые 10-15 раз я задумаюсь, но потом я просто буду шаблонно копипастить стандартный
if err != nilи даже не думать о том "а что мне тут сделать с ошибкой".
А даже если бы думал, то почему из-за 1 случая из 100 мне нужно в остальных 99 заниматься копипастой?
То, что я могу решить проблему без дженериков — именно и значит, что проблемы нет. Вероятно в некоторых случаях без дженериков хуже чем с дженериками, вероятно интерфейсы и кодогенерация — не всегда лучший выбор, но пока я до таких случаев не дорос и «обманываться рад».
Я могу писать все на brainfuck, используя, например транcлятор из python в brainfuck, потому что любую проблему можно свести к операциям, которые нужны для тюринг-полноты языка. Но это не доказывает, что так делать правильно.
В том то и соль, что дженерики — это кусок кодогенерации, который делает за вас компилятор, с нужными проверками и прочим. Вы может сделать его сами, но это не делает язык лучше.
Edison
05.05.2018 16:47жуткая работа с зависимостями
dep, vgo — все довольно неплохо
нету удобного дебага
delve (есть интеграции с vim, vscode), Goland тоже умеет деббагер.
На счет ошибок и дженериков уже нахоливарено.
Лично мое мнение — ошибки не так уж и плохо, а еще есть либы типа pkg/errors, добавление своих типов ошибок и тд. Скорее всего меня начнут минусовать, но ошибки удобнее исключений (сначала я так не считал, но со временем я не мог без боли работать с исключениями).
Evengining
02.05.2018 23:37Затычки “NameSpace“, невозможность работы PHP без веб-серверов, иногда ужасное поставленнение предложений(например «На го нет ООП», складывается ощущения что это копипаста с прошлых пунктов).
Мне кажется что автору нужно 1) лучше проверять что он собираться выкладывать. 2) лучше анализировать саму идею. 3) проверять некоторые моменты перед тем как писать их. В остальном такие статьи только отпугивают от Go, если честно.
Ihariv Автор
03.05.2018 00:11Затычки “NameSpace“, невозможность работы PHP без веб-серверов
По сути в PHP это так и есть. Когда вводили namespace так и писали, наконец у нас не будет конфликтов с именами. По поводу веб серверов, да php нельзя юзать без них. Можно использовать низкоуровневый reactPHP, но я не уверен что внутри его не лежит библиотека бинарная, которая и работает как сервер (libev к примеру точно стоит). Встроенный сервер вообще не для того. По поводу на Go нет PHP — многие конференции по Go содержат данную фразу.
index0h
03.05.2018 02:08+1Печально читать вашу статью, правда.
Мне действительно нравится go, как инструмент. Но срывания покровов, вроде вашего оставляет очень нехорошее впечатление как о вас, так и о экосистеме в целом.
PHP лидирует? Нет.
Когда вы так говорите — где-то в мире грустят сотрудники Facebook и Vk, а так же большая часть сайтов в этих наших интернетах.
А значит нам нужно проделать очень много шагов по запуску сервера, подключения к нему PHP расширения, настройки виртуального хоста, прописать все это в файле hosts.
Это надо прописать и для go и для java и для всего остального (если не настраивать DNS сервер).
Слушайте хоть до посинения my-very-perfect.localhost на 80-м порту, но без знания этого хоста ваша ОС к нему все равно не направит.
Плюс еще взаимодействие между процессами весьма спорное. Использовать для этого дополнительные библиотеки типа ключ-значение как-то странно.
Как только вы не влезаете в одну железяку — такие вопросы сразу же возникнут, вне зависимости от того на чем вы написали приложение.
Отдельно можно рассказать о расширениях в GoLang-e. Все расширения написаны на Go (конечно есть вставки на Assembler-е).
Да как бы нет, есть куча примеров как вызвать go из крестов например и наоборот.
Как видим для написания сайтов GoLang так же имеет достаточное количество инструментов.
Вы перечислили достоинства BeeGo, это видно. Но для сайтов с большой долей вероятность я бы go не использовал. Go хорош для сетевы приложений и распределенных web систем, но сайты… В большинстве случае дешевле, быстрее, проще и надежней будет таки на php.
Используя GoLang можно отказаться от сопутствующих вещей. К примеру memcache, redis, nodejs, nginx и прочих без потери в скорости или функционале.
Смею предположить, что вы не учавствовали в крупных проектах.
Как только ваше детище не помещается на одну железяку, вот эти средства что вы перечислили (memcache, redis) — приходят к вам на выручку.
Что касается nodejs — я сам разочаровался в этой технологии, но для большого количества задач вы не найдете технологии лучше, например сборка SPA.
Про nginx — вы капец как зря. Интересно, сколько вам времени потребуется что бы написать балансер запросов, по сравнению с настройкой nginx.
Все эти NameSpace как затычки и невозможность множественного наследия, награмождение всевозможных паттернов как результат усложняют работу
Шта?? Namespace — это одна из самых лучших вещей, которые происходили c php. На счет множественного "наследия" — почитайте на досуге про SOLID и попытайтесь его придерживаться. Это не стеб, а просто совет.
А для синхронизации данных можно использовать либо общую переменную (срез или карту), либо каналы.
Вы хоть понимаете, что срезы и карты для синхронизации потоков стоит использовать только когда это требует маньяк с топором сидящий рядом с вами?
VolCh
03.05.2018 06:19+1Namespace — это одна из самых лучших вещей, которые происходили c php.
Спорно. По сути это просто сахар к префиксам имён классов, функций и т. п., позволяющие сократить их имена при использовании, не особо экономить на символах, ну плюс пару хаков, позволящих как бы переопределять глобальные функции. Увы, но это не полноценные модули, своей изолированной области видимости они не создают.
index0h
03.05.2018 10:44По сути это просто сахар к префиксам имён классов, функций и т. п.
Ложка — по сути это просто сахар к вилке, что бы борщ хлебать.
Namespaces решают проблемы:
- конфликты имет
- целый зоопарк автозагрузчиков и стандартов именования
Увы, но это не полноценные модули, своей изолированной области видимости они не создают.
Верно, вопрос изоляции решается за счет соглашений. В go вообще говоря тоже. Мне никто не запретит написать отсебятины ни в $GOPATH/src/anotherVendor ни в vendor.
VolCh
03.05.2018 11:41Namespaces решают проблемы конфликтов и автозагрузчиков ровно так же, как и префиксы, только имеет сахар для возможности не писать каждый раз полный путь.
Написать — полбеды. Проблема в том, что как автор какого-то модуля вы не можете разделить интерфейсы своего модуля на публичные и внутренние, только для классов и других элементов модуля.index0h
03.05.2018 12:18Они не просто решают, а задают стандарт решения этой задачи.
не можете разделить интерфейсы своего модуля на публичные и внутренние
И причем тут неймспейсы?)))
Вообще говоря могу, эта задача решается за счет соглашений.
VolCh
03.05.2018 13:29Неймспейсы не задают стандартов автозагрузки. Загрузчики просто получает полное имя класса. Как загрузчик будет отображать имя на ФС его личное дело. Может вообще ФС не использовать для этого, вызвав какой-нибудь eval(). А для уникальности имён неймспейсы лишь чуть более удобный инструмент чем префиксы, причём со своими недостатками.
Неймспейсы часто подаются как способ разбивать код приложения на отдельные модули. Но они модулями не являются, никаких средств изоляции между модулями не предоставляют.
index0h
03.05.2018 13:43А для уникальности имён неймспейсы лишь чуть более удобный инструмент чем префиксы, причём со своими недостатками.
И какими же недостатками?
Неймспейсы часто подаются как способ разбивать код приложения на отдельные модули.
Вы считаете, что неймспейсы должны решать задачу модульности вашего приложения, забудем на момент, что их целевое использование никак с этим не связано. А далее на основании своего ложного утверждения делаете выводы.
Это тоже самое, что упрекать микроскопы в неудобстве забивания гвоздей.
VolCh
03.05.2018 14:58Возможность переопределения некоторых глобальных имён локально. Результат разрешения какого-нибудь json_decode или Exception неоднозначен, зависит от наличия или отсуствия соотвествующих use
С php.net: «Что такое пространства имен? В широком смысле — это один из способов инкапсуляции элементов.» Но по факту они лишь групируются, но никакой инкапсуляции.index0h
03.05.2018 15:27Возможность переопределения некоторых глобальных имён локально.
Вообще говоря переопределить что-то глобальное у вас получится разве что через runkit. А в своем namespace вы сами себе хозяин.
зависит от наличия или отсуствия соотвествующих use
И в чем недостаток? То, что можно написать что-то неправильно? Ни один язык вас от этого в полной мере не защитит.
VolCh
04.05.2018 07:37Не сам себе хозяин. Любой может переопределить глобальную функцию или класс, которая используется у тебя в коде, если ты не предпринял защитных мер.
Неоднозначность, разрешаемая в рантайме. Дело не в «написать неправильно», дело в том, что когда читаешь код ты не знаешь как интерпретатор поймёт какой-нибудь fopen или array_map. Он сначала будет искать в текущем неймспейсе, который не контролируется никак, ведь любой может добавить в него что-то, а потом, если не найдёт, в глобальном попробует найти.index0h
05.05.2018 02:43Любой может переопределить глобальную функцию или класс
Приведите пример переопределения глобальной функции, или класса.
ты не знаешь как интерпретатор поймёт какой-нибудь fopen или array_map
В чем проблема? Хотите гарантий — пишите \fopen и \array_map. Проблема очень надуманная.
Ihariv Автор
03.05.2018 23:30Да как бы нет, есть куча примеров как вызвать go из крестов например и наоборот.
Не путайте расширения и вызовы.
Namespace — это одна из самых лучших вещей, которые происходили c php.
Очень печально что вы так думаете. Это вынужденная мера было, есть куча гораздо более интересных вещей. К примеру ob_get_contents.
Вы хоть понимаете, что срезы и карты для синхронизации потоков стоит использовать только когда это требует маньяк с топором сидящий рядом с вами?
Намеренно путаете синхронизацию данных и потоков?index0h
05.05.2018 14:19Не путайте расширения и вызовы.
Я и не путаю, когда прослойка на крестах (или другом языке) — это часть расширения, то изначальное утверждение, что все расширения написаны на go/asm — не верно.
К примеру ob_get_contents.
Я эту функцию использовал раза 4 всего, а с неймсейсами, тайпхинтингами и т.д. я встречаюсь каждый день.
Намеренно путаете синхронизацию данных и потоков?
Слайсы/карты не безопасны для конкурентного доступа, так что мое утверждение верно и для данных и для потоков
imgen
03.05.2018 02:27Так же добавлю от себя пару слов.
С какими трудностями я столкнулся при разработке на GO. С теми же, с которыми столкнулся node в свои первые годы.
- Очень плохие инструменты тестирования
- Отсутствие вменяемых менеджеров зависимостей
- Некоторые библиотеки пишутся с нарушением всех мыслимых и немыслимых принципов разработки, тому пример библиотека работы с AMQP/Rabbit MQ
- Отсутствие горячей замены кода как в том же пхп, где достаточно спулиться и всё уже поедет само
- Иногда трейсы вгоняют в депрессию
- Вся эта движуха с папками вместо неймспейсов доставляет ужасную боль, если проект фактически находится в другой папке через симлинк
- Отсутствие вменяемых редакторов, есть новая студия от Jetbrains, но оно тормозит, что даже Visual Studio Code кажется бодрее, а он вообще на node пишется
- Горутины не прозрачные и доставляют много проблем. После Erlang с их OTP, горутины это какой-то кошмар честно говоря
- Написание решений, без использования сомнительных библиотек и пакетов — будет очень и очень сложно. А в проектах, работающих с деньгами, Вам такие пакеты тащить в прод и не дадут.
Да и в целом статья, смотрите Go это хорошо, а PHP плохо моветон. Да PHP может и язык с плохим дизайном, но задачи, поставленные перед ним он решает и решает не хуже других ЯП, раз многие высоконагруженные проекты продолжают отдавать ему предпочтение. На Go пока еще ничего крупного не взлетело, быть может Dropbox станет первой такой компанией, будем следить за их деятельностью.
ZurgInq
03.05.2018 07:19+2Новички нахваливающие Go как будто специально делают печальную антирекламу данному языку. Вот уж действительно, Go — это новый php в мире веб разработки.
KirEv
03.05.2018 10:38+1какие-то надуманные мифы… когда начинал знакомится с go, года полтора назад, 99% из перечисленного тупо не встречал,
и ни слова про на самом деле острые вещи:
— garbage collector
— interface (можно подумать в Миф5 это должно быть упомянуто, но нифига), совмещение интерфейсов,
— reflection
— закрытие используемых ресурсов, зачем это нужно и чем игнор этого грозит, хотя бы defer упомянуть
— обработка ошибок, паники и выход из паники
— горутины и общение через каналы
— мапы и слайсы…
И почему в сравнение go ставится php? это совсем разные вещи.
И таки да, в go нет ооп, он не был ооп-ориентированным, для других вещей он был создан, но с помощью несложных махинаций можно сделать чтото похожее на ооп, но если вы ходите писать с помощью объектно-ориентированного подхода — зачем вам go и извращаться пытаясь следовать концепциям ооп, возьмите ооп-ориентированный язык который нативно поддерживает концепции ооп.
И самое интересное — в статье вспоминается мельком о какой-то стандартизации, но ни слова про утилитку fmt, которая приводит код к единому виду…
Про синтаксис ничего не сказано…
Эта статья, если выбросить «go» и «golang», подойдет для почти любого современного языка в сравнение с рнр.
FSA
03.05.2018 16:55Я конечно любитель, но я не знаю, что там сложного запустить связку nginx+php-fpm и включить xdebug если ты постоянно занимаешься разработкой. Эта же связка, но без xdebug прекрасно себя чувствует на любом дешёвом VPS.
Я думаю, для разработчика основной вопрос — не мифы о языке, а понять что даст ему переход с того же PHP на Go. Я лично для себя не вижу никакой выгоды при использовании в вебе, а вот время на изучение Go потратить придётся.
oxidmod
Достаточно установить PHP.
Пока не встретил ни одной проблемы связанной с встроенным сервером.
Но докер\вагрант спасут вас. Особенно докер =)
Ihariv Автор
только если вы собираетесь использовать его из консоли. На вскидку я не помню проектов, где полноценно используется только консольный клиент PHP. Для консоли есть более удобный bash (и наверное более быстрый). Возможно вы можете привести больше примеров. С удовольствием добавлю их в статью.
Ihariv Автор
цитата из php.ru
Так что ваш пример скорее всего исключение.
Опять говорим про докер, вагрант. О чем я и писал. У меня с вагрантом были серьезные проблемы в плане линковки файлов из-под windows на более-менее большом проекте.
oxidmod
Встроенные сервер идеально подходит для разработки. Что еще нужно для быстрого входа в язык?
Докер нужен для CI\CD. Благодаря докеру вы получаете единое окружение на всех этапах (тест\стейдж\прод) и очень легкий деплой приложения. И если вашему проекту кроме собственно пхп нужна еще куча сервисов (кеши, очереди, бд и т.д) на этапе разработки, то благодаря докеру поднимается это в одну команду:
Серьезные сервисы под виндой (если это не .net) — какой смысл? Небось еще и пыху на IIS крутить?
Ihariv Автор
У всех свои предпочтения. На моем последнем офисе у 70% стоит windows. Не всем же бекендом заниматься. Что может быть проще go get? а докер — это виртуальная машина. Не будем вдаваться, что виртуальная машина имеет свойство есть процессор. Хорошая IDE под тем же laravel тоже хочет кушать процессор и память. Порой нужно иметь почти игровой компьютер что бы просто писать скрипты. Мне как-то такая идея не нравится.
GennPen
Ihariv Автор
Ключевое слово «практически». Вносит, и не мало. Просто оно виртуализируется не так как лет 10 назад. сейчас просто запускаются процессы не эмулируя, а забирая часть ресурсов. А запускать нужно много. Посмотрите top на виртуальной машине. Это все то, что как правило уже запущено на основной машине, т.е. гоняет вхолостую.
Ihariv Автор
К стати, если мне память не изменяет, докер тоже написан на go
GennPen
И что это меняет? Язык — это всего лишь инструмент.
Ihariv Автор
стек технологий
Shtsh
Причем тут golang к линуксовским namespaces & cgroups? Реализация демона, который помещает обычные процессы куда надо не влияет на производительность.
Shtsh
какая разница, что стоит у пользователей, если это будет крутиться на сервере?
> докер — это виртуальная машина
это сильный довод
Ihariv Автор
Вы правы, докер не виртуальная машина, а система, запускающая приложения в среде виртуализации.
VolCh
Докер — не виртуальная машина, это интерфейс к штатным средствам изоляции процессов ОС.
Ihariv Автор
Ну все современные машины виртуализации так работают.
Изучайте более досканально матчасть пожалуйста. посмотрите как докер ставится, что он разворачивает и задайте вопрос, зачем, если не для того что бы запускать. А реализацию можно делать по разному, но от этого машина не перестает быть виртуальной.
kahi4
Виртуализация — абстрагирование выполнения программного обеспечения от аппаратной части, докер ничего ни от кого не абстрагирует. Докер как таковой — это вообще пара скриптов поверх линукс ядра, точнее cgroups, позволяющие подменить файловую систему и системные вызовы для контейнера.
Справедливости ради, это действительно называется «виртуализация на уровне ОС», но никаких виртуальных машин он не ставит и накладные расходы практически отсутствуют. Да фактически в контейнере запускаются обычные приложения только с более продвинутыми настройками привилегий. «Кольца защиты 2.0» так сказать.
oxidmod
Я думаю, что человек докер на Винду ставил.
Ihariv Автор
Хорошо, вы согласны что виртуализация есть, докер запускает ядро, unix скрипты, создает слепок, в котором все это сохраняет. Так что это если не виртуальная машина. Возможно запускать программы в том случае если эмулируемый инвайремент точно совпадает с локальным. Кроме того в руководстве докера четко написано что для мак и виндовс машин запускаются полностью виртуальные машины. Смысл докера, сэмитировать окружение сервера. Без отдельного контейнера со всем причитающимся имитация будет не полной и теряет свой смысл. А потери — это имеется ввиду накладные потери на поддержание самого виртуального пространства.
Shtsh
> докер запускает ядро, unix скрипты
Это не так
> Смысл докера, сэмитировать окружение сервера
Это не так
> Возможно запускать программы в том случае если эмулируемый инвайремент точно совпадает с локальным
Это не так
> для мак и виндовс машин запускаются полностью виртуальные машины
Какая разница, как сделано под мак и вин? Это сделано для разработчиков. Вы бы еще написали, что у вас в ide на локальной машине по другому работает. Имеет значение только какая производительность и принцип работы в реальном окружении.
Ihariv Автор
Ну посмотрите руководство. Докер может хоть ядро запустить другое, хоть только пару программ. Но он запускает. Так что вы не правы
В описываемом ракурсе именно так. Иначе зачем он вообще? если все программы и без него как правило стоят и настроены. Конечно, в общем смысле его можно использовать и с другой целью.
По вашему те кто работает на маке или на винде — не разработчики? Пример приведен для того что бы показать, что работает с виртуализацией, и на оф сайте почитайте, и на википедии именно так написано. Не важно запущено ядро или пара программ, для этих программ они в виртуальной среде.
michael_vostrikov
Вас не смутило, что в Википедии стоит ссылка на все выражение «виртуализации на уровне операционной системы»? Зачем вы выдергиваете слова из контекста?
Вы путаете виртуализацию железа, когда эмулируется выполнение инструкций процессора и ввод-вывод, и виртуализацию вызовов API операционной системы. Поэтому VirtualBox и Docker работают по-разному.
Ihariv Автор
michael_vostrikov
Я опровергаю не то, что я придумал, а ваши утверждения. Я же привел цитату. «Ну все современные машины виртуализации так работают». Не все и не так. Принцип работы виртуальной машины в VirtualBox отличается от принципа работы контейнера в Docker.
Вот здесь вроде неплохо описано.
VolCh
Докер не запускает ядро. Все процессы под докером разделяют одно ядро вместе со всеми остальными процессами, вообще к докеру отношения не имеющими, начиная с pid 1 хост-системы, какого-нибудь init. Если вы умудритесь вызвать kernel panic из контейнера, то это затронет все процессы на машине. Докер, грубо говоря, лишь изолирует процессы в юзерспейсе друг от друга так, чтобы они "думали", что являются единственным процессом ОС.
Докер не эмулирует аппаратные ресурсы, только часть из них прячет, а часть проецирует, монтирует для процесса. По сути chroot + mount на стероидах cgroups. И даже программные не эмулирует: запустите uname -a в контейнере FROM Ubuntu:16.04 на хосте с последней Gentoo и вы удивитесь.
Они запускаются не для контейнеров а для linux-версии докера. Windows-версия докера виртуалки не требует, чтобы запускать контейнеры FROM Windows
Смысл докера — удобный интерфейс к средствам изоляции процессов ядра Linux, позволяющий оперировать процессами и их программным окружением как одним целым — контейнером. Докер не виртуализирует ничего, просто делает удобным что и без него можно было делать в Linux.
Ihariv Автор
Почему вы все время врете? (с)
я не писал что докер эмулирует аппаратные ресурсы. Достаточно используя возможности процессора с помощью ядра виртуализировать сам процесс. Да и докер не chroot, от слова совсем. chroot только прячет файлы и подсовывает свои, а докер же юзает средства виртуализации если верить тому же вики. Но вы больше перевирать любите чем углубляться.
VolCh
Докер не виртуализирует процессы и никакие особые возможности процессора для виртуализации не использует. Если уж хочется считать, что при запуске докер-контейнера что-то виртуализуется, то этой виртуализацией занимается ядро ОС, это его штатные возможности. Ну и в целом это именно прятание одних ресурсов и подсовывание других, продвинутый chroot — об этом та же вики пишет.
Ihariv Автор
Найдите там слово chroot.
VolCh
Вы будете удивлены, но редакторы отвечают за предоставление пользовательского интерфейса к функциям ОС работы с файлами, а докер отвечает за предоставление пользовательского интерфейса к функциям ОС работы с процессами.
«Там» читаете первое предложение, видите что докер это не средство виртуализации, а средство развертывания в уже имеющейся среде виртуализации на уровне ОС, переходите по ссылке, чтобы узнать что это за среда такая, в которой докер развертывает приложения и внезапно увидите там слово chroot как самое старое средство виртуализации на уровне ОС.
Ihariv Автор
Хоть кол чеши. Опять перевираете. chroot ничего не изолирует. По сути это утилита больше относящаяся к файловой системе (условно). На странице про докер chroot нету. А на странице, о которой вы упоминаете простая оговорка, что бы вам было проще объяснить. Но вы видимо ни разу chroot не использовали, а все туда же. Давайте уже оговорки принимать как аргумент.
VolCh
chroot именно что изолирует основную файловую систему от процесса.
Ihariv Автор
Вы либо никогда им не пользовались либо. chroot меняет корень файловой системы. и все. Остальное — побочный эффект, файловую систему он не изолирует, делает только видимость этого, от процессов не ограждает. Но благодаря тому что в линуксе все процессы по сути файлы, это создает ощущение изолированности. но мне просто интересно, как вы изолируете процесс от файловой системы с помощью chroot? Более того из-под «изолированной» по вашему системы я много раз монтировал основную
VolCh
Так он меняет так, чтобы доступа у процесса к остальной части файловой системы не было, нельзя в изолированном процессе сделать что-то вроде chroot /new_root cat /../etc/passwd
Не процесс изолируется от ФС, а вся ФС кроме явно заданных точек изолируется от процесса. делаем chroot для разных процессов на два разных каталоги и ФС этих процессов изолируются друг от друга.
Ihariv Автор
точно не пользовались. Ничто не мешает сделать mount /dev/sda3 /mnt/root && cat /mnt/root/passwd
Какая же это изоляция?
VolCh
Где вы будете делать? Из процесса под chroot? Так в нём нет /dev если снаружи специально не смонтируете предварительно.
В докере вы тоже может корень ФС примонтировать как том и делать всё, что хотите.
Ihariv Автор
Блин, опять вас кидает со стороны в сторону. Я написал что можно, привел пример самый простой, вы пытаетесь какие-то условия писать. Уже и забыли, что докер не chroot, перескакиваете на вещи, которые могут отвлечь от основной линии обсуждения. Ну, как говориться, удачи.
Ihariv Автор
к тому же делаете mount -t proc proc /proc из под chroot и все, делайте с процессами родителя что хотите (как минимум под правами юзера, запустившего chroot)
VolCh
Причём тут процессы родителя? chroot изолирует ФС от процесса, как вариант ФС двух процессов друг от друга. Она не изолирует процессы друг от друга.
michael_vostrikov
Из-под виртуальной машины тоже можно примонтировать папку из хоста. Она тоже ничего не изолирует?
Ihariv Автор
Поподробнее, вы это вообще к чему сказали? Как вы это делаете, в какой виртуальной/изолированной системе? Посмотрел бы я как вы из машины эмулируемой с помощью VirtualBox-а что-то примантировали. а вот в этом списке
виртуальных систем если вы включили изоляцию, то не примонтируете.
michael_vostrikov
Shared folders — Manual mounting
Ihariv Автор
т.е. вы намеренно расшариваете папку из хоста, а потом ее монтируете. Вы бы еще smbmount привели как пример. Монтируется же. Речь о монтировании не прибегая к помощи хоста (без разрешения). Хоть бы посты почитали, о чем речь.
michael_vostrikov
А предварительное монтирование
/devот суперпользователя это типа не намеренное разрешение?)Речь была о том, какой метод виртуализации использует Docker, и что в описании этого метода сказано, что он похож на улучшенный
chroot. Нигде не сказано, что Docker работает аналогично VirtualBox, зато есть куча статей на тему «docker is not a virtual machine».Ihariv Автор
типа нет. dev — это любые устройства ввода вывода. Без него вы не можете к примеру форматировать отдельный диск, не можете флешку подключать, всякие принтера… Не показывайте больше своих поверхностных знаний в этой облости
michael_vostrikov
Как из этого следует, что монтирование его перед запуском chroot это не намеренное действие или не предоставление разрешения его использовать?
Ihariv Автор
Вы буквально недавно писали что это и есть chroot только продвинутый
michael_vostrikov
Это не я писал.
Ihariv Автор
Это вы будете удивлены, редакторы отвечают за редактирование. Название как бы намекает. Вы еще пишите такого-же и побольше
Ihariv Автор
Да, для понимания сути. Возможно в ряде случаев докер использует
Но в таких случаях, как я и писал ранее, расходы — это не расходы на окружение а только на гипервизор. Все остальные расходы остаются.
Ihariv Автор
точнее аналогично изолирует процессы.
Shtsh
Докер не использует chroot. Там mount namespace
VolCh
Вот докер это продвинутый chroot, у него нет расходов на гипервизор, это легковесная альтернатива виртуализации.
Sovigod
ни покажите как быстро и легко запустить окружение для актуальной симфони на php7.2 и pecl-mongodb и xdebug?
Сейчас используем кастомный Dockerfile для сборки такого окружения. Но «go get -u» намного проще и быстрей.
oxidmod
В это и смысл докера. Вы напишете один раз докер-файл (или найдете готовый на докер-хабе) и забудете о сетапе инфраструктуры. Право же, время затраченное на генерацию одного докер файла несравнимо с временем на разработку проекта.
Ihariv Автор
Вы лукавите, не все так просто и с докером. речь как раз о том, что не надо один раз писать. Все уже работает. Причем стабильно и на всех платформах, хоть на андроид.
Sovigod
Ну сами конечно считайте что сложней для среднего разработчика — использовать стороннюю тулзу(docker|docker-compose) со своим синтаксисом и конфигами. Или встроенный в язык механизм работы с зависимостями.
А для повседневной работы — go get на прядки быстрей composer на больших проектах.(Очистить кеш, пересобрать конфиги или обновить зависимости после git pull — бывает нужно каждый день)
Caravus
Справедливости ради: go get удобней ровно до тех пор пока вы не хотите от него чего-нибудь нестандартного. Например забрать код из закрытого репозитория или из репозитория с группами/подгруппами (см gitlab). И тут начинается шаманство с баш-скриптами и/или докерфайлами…
Ihariv Автор
тогда git pull спасет. Все равно проще выходит
Shtsh
Вот так представляю, захожу на билд сервер руками делать git pull. Или вы хотите сами костылить систему зависимостей хотя бы с возоможностью фиксации версий?
Правда же вы не подразумевает, что бинарник должен собирать и пушить в какую-нибудь хранилку человек?
oxidmod
Ihariv, Sovigod
Для go точно также нужно сетапать бд, еластик и кролика. Точно так же нужно будет насетапать балансировщик рано или поздно. Разве не так? Тогда что вы выигрываете?
Для разработки на пыхе достаточно самой пыхи. Это из личной практики. Причем я даже не запускаю встроенный сервер и обхожусь прогоном юнит тестов локально. Дальше на CI-сервере гонятся кроме юнитов еще интеграционные и функциональные тесты и код готов к выкатке на продакшен.
Ihariv Автор
Ну, допустим, базу надо, еластик и кролика — пока то же надо. А с балансировщиками никаких проблем и на go. Как пример статья за 2013 год. Конечно, зачем самому заново придумывать. Можно в нете поискать готовый балансировщик. Или написать свой, совсем уникальный.
Ihariv Автор
Людям не нравится балансировщик на go в 200 строк, можно юзать готовый на том же go. Балансировщик вполне современный и работает под очень большой нагрузкой.
oxidmod
Но весь консул не балансировщик. Зачем вы привели ссылку на него?
Ihariv Автор
Консул — это большая программа, которая работает в том числе как балансировщик. Причем на очень больших проектах. На что еще вам ссылку дать? Вам не угодить. То слишком старое, то слишком функциональное. Можете сами поискать в таком случае то что лично вам придется по вкусу.
oxidmod
Ну я глянул главную страницу. Глянул раздел с гайдами и раздел с описанием API консула и нигде не увидел ни слова о его использовании в качестве load balancer-a.
Ihariv Автор
Более подробно на эту тему. Что бы не отдаляться от темы топика
oxidmod
А вы внимательно смотрели видео?
Или консул написан на go + go grpc умеет в балансировку = консул — балансер?
Там консул лишь отдает список адресов, выполняя роль сервис-дискавери.
Ihariv Автор
Shtsh
Очень мощная. Но при этом не балансировщик.
Sovigod
да сетапить бд и прочее нужно. У нас также отдельный dockerfile для сборки монги сразу в кластере. От этого не избавиться. кролик вообще stateless (идеально для докера). Но вот его сетапить редко. А править в нем что-то еще реже.
А работать со сменой версий в pecl|composer приходится очень часто.
oxidmod
Вот для прода на пыхе нужно всего лишь добавить слой с самой пыхой и веб сервером. Если вы все равно используете докер, то какая разница?
Для разработки пыха даже проще, а для продакшена без разницы