@@alexnov4367 раньше был на Битриксе. Symfony конечно круче. Хоть и сложно, но для работы много знать необязательно. Ко всему можно подлезть и все можно настроить. В основном сейчас меняю пару строчек кода и все работает. На Битриксе по любому поводу надо было писать километры кода.
До тех поп пока проект не требует больших спу, го можно и не рассматривать. Го отличные, но как студия я думаю они не делали какие супер сложные проекты которые требуют использования го.
Сложно слушать - как с пулемёта слова летят, а когда язык не поспевает и получаются плевки , причмокивания и тп - вообще ужасно... Как истинный руководитель мог бы и делегировать выступление...
В первые же 10 минут стало понятно что ребята не go учили, а в принципе учились программировать. И в целом доклад про это. Увы на рынке php если не изучать параллельно другие, в том числе системные языки, по-настоящему программировать не научиться. Попробуйте сходу освоить C и Rust, тогда ваш код на go точно станет ещё лучше. Молодцы что расширили свой кругозор, но доклад, увы скучный. Я ожидал услышать не как ребята учили очевидные вещи, а о том как это было с точки зрения бизнеса, как быстро училась команда. Какие были издержки с этим связанные. Как скоро начало получаться писать качественный код. В общем промазал с выбором видео. Видимо я не аудитория доклада.
Про срезы повеселил. Человек не привык работать на системном уровне. Go - это улучшенный Си, со всеми вытекающими. И работать с ним нужно как если бы вы писали качественный код на Си. Что в Си делать совсем не просто и требует огромного труда и терпения. Go - это таблетка от головной боли системщика - Си-шника - работа с массивами, строками, памятью, многозадачностью, модульностью из коробки. И ничего лишнего, неконтролируемого, неоднозначного Срез, скорее всего, делает realloc и разумеется возвращает указатель на новую область памяти. Это на столько очевидно, что не задумываясь возвращаешь новое значение указателя и живешь с ним дальше. Goрутина - Обычный fork+exec+pipe+signal handler
1. Гоу может быть непредсказуем по потреблению памяти 2. Горутина не имеет отношения к лежащему внизу поста, горутина даже потоком не является, не то что процессом
@@EdwVee ничто не ново под луной. Горутина - это обычная функция, запущенная в отдельном процессе(в терминах го это M-machine). Общается горутина через каналы. И чем это принципиально отличается от классического fork() + pipe() ? А copy-on-write гарантирует малое потребление памяти как и при обычном fork-e. Просто всю грязную работу делает шедулер. Но если вы привыкли работать с тредами, то действительно - это другое. Треды на винде более легковесны, но тянут за собой кучу проблем разделения данных.
@@kshetragia тем, что можно 100500 горутин создать даже в отличие от потоков, и я не говорю про процессы, тем что есть разделяемая память. Вроде и то, и то обёртка для исполняемого кода, но называть их равнозначными нельзя
Проблема была в Фреймворк, был бы голый php таких бы проблем было бы меньше. Докер, это еще один бред замедляющий работу. Не удивительно что всё полетело
Неправильно ООП используете. Согласно правилам солид нельзя перезаписывать методы из наследуемого класса, в новые класс нужно только добавлять функционал, учите матчасть, и кстати golang поддерживает парадигму ООП.
Отличный доклад, спасибо. Жаль, что было так мало времени. Скорость речи классная, поток информации залетает плотный)
Я так и не понял как GO решил проблемы проекта. Он вообще их решил?
"При передаче среза в метод, передается копия среза, но со ссылкой на старый массив".... это как?? и для чего такой огород?!?!? 🧐
Go заставляет писать правильно. Горутины выводят неправильное значение, потому-что в функцию I нужно передавать аргументом, а не переменную из scope.
Ищем бекэнд разработчика на golang в международный проект. Пишите на почту globint@mail.ru
Ну судя по всему заставить не получилось 😂
охуеть открытие, компилируемый язык быстрее интерпретируемого
Swoole + swoft
На 29:25 докладчик немного ошибся, в php есть множественное наследование через traits.
Это да. Только если не учитывать, что trait к наследованию отношения не имеет
Хочу перейти с PHP (Битрикс) на Go. Ищу стажировку, готов изучать с уклоном под ваш конкретный проект
Ухх....битрикс. Сочувствую.
Прешли в итоге. Если да то сложно ли было? Заранее спасибо!
@@GermanBoldyrev нет. Но перешел на Symfony
@@Wivern11 А на чем раньше работали и как вам Symfony? Поделитесь, пожалуйста, впечатлениями. Плюсы, минусы, выбрали бы сейчас его или нет?
@@alexnov4367 раньше был на Битриксе. Symfony конечно круче. Хоть и сложно, но для работы много знать необязательно. Ко всему можно подлезть и все можно настроить. В основном сейчас меняю пару строчек кода и все работает. На Битриксе по любому поводу надо было писать километры кода.
До тех поп пока проект не требует больших спу, го можно и не рассматривать.
Го отличные, но как студия я думаю они не делали какие супер сложные проекты которые требуют использования го.
Сложно слушать - как с пулемёта слова летят, а когда язык не поспевает и получаются плевки , причмокивания и тп - вообще ужасно... Как истинный руководитель мог бы и делегировать выступление...
чтобы gearman отвалился из-за нехватки памяти, нужно запустить 10 тысяч воркеров. Похоже просто в нем делали какую-то херню
Ну мы именно ее и делали:) приготовили php+gearman неправильно)
В первые же 10 минут стало понятно что ребята не go учили, а в принципе учились программировать. И в целом доклад про это. Увы на рынке php если не изучать параллельно другие, в том числе системные языки, по-настоящему программировать не научиться.
Попробуйте сходу освоить C и Rust, тогда ваш код на go точно станет ещё лучше.
Молодцы что расширили свой кругозор, но доклад, увы скучный. Я ожидал услышать не как ребята учили очевидные вещи, а о том как это было с точки зрения бизнеса, как быстро училась команда. Какие были издержки с этим связанные. Как скоро начало получаться писать качественный код. В общем промазал с выбором видео. Видимо я не аудитория доклада.
Забавно, да. Информации ноль. Перетирание избитой темы про слайсы, но люди и с таким подходом зарабатывают деньги, что не менее интересно
Про срезы повеселил. Человек не привык работать на системном уровне. Go - это улучшенный Си, со всеми вытекающими. И работать с ним нужно как если бы вы писали качественный код на Си. Что в Си делать совсем не просто и требует огромного труда и терпения.
Go - это таблетка от головной боли системщика - Си-шника - работа с массивами, строками, памятью, многозадачностью, модульностью из коробки. И ничего лишнего, неконтролируемого, неоднозначного
Срез, скорее всего, делает realloc и разумеется возвращает указатель на новую область памяти. Это на столько очевидно, что не задумываясь возвращаешь новое значение указателя и живешь с ним дальше.
Goрутина - Обычный fork+exec+pipe+signal handler
1. Гоу может быть непредсказуем по потреблению памяти
2. Горутина не имеет отношения к лежащему внизу поста, горутина даже потоком не является, не то что процессом
@@EdwVee ничто не ново под луной. Горутина - это обычная функция, запущенная в отдельном процессе(в терминах го это M-machine). Общается горутина через каналы.
И чем это принципиально отличается от классического fork() + pipe() ? А copy-on-write гарантирует малое потребление памяти как и при обычном fork-e.
Просто всю грязную работу делает шедулер. Но если вы привыкли работать с тредами, то действительно - это другое. Треды на винде более легковесны, но тянут за собой кучу проблем разделения данных.
@@kshetragia тем, что можно 100500 горутин создать даже в отличие от потоков, и я не говорю про процессы, тем что есть разделяемая память. Вроде и то, и то обёртка для исполняемого кода, но называть их равнозначными нельзя
@@EdwVee все вполне предсказуемо если знать как все работает
@@kshetragia Горутина работает без свитч контекста, в юзерспейсе есть свой скедулер. Это не классический поток.
Не крайній, а останній
Ужас, стыдно должно быть с таким докладом выходить, когда ты не разбираешься в том, о чем рассказываешь
Что за фигня со звуком??????
Слушать невозможно
Проблема была в Фреймворк, был бы голый php таких бы проблем было бы меньше. Докер, это еще один бред замедляющий работу. Не удивительно что всё полетело
Всё-таки проблема у авторов лежала в архитектуре: плодить целые процессы чтобы делать хттп запросы. Тут даже ассемблер с таким подходом не поможет.
Неправильно ООП используете. Согласно правилам солид нельзя перезаписывать методы из наследуемого класса, в новые класс нужно только добавлять функционал, учите матчасть, и кстати golang поддерживает парадигму ООП.
Какое правило solid запрещает переопределение методов?