Я так и не понял, причем тут микросервисы. Вы не умеете писать на питоне, но приплели почему-то микросервисы
PS: Это прям эпично: Я PHP-разработчик с восьмилетним коммерческим опытом. А потом мы читаем статьи в которых авторы удивляются почему PHP во многих компаниях ред флаг и, что рынок труда полностью испорчен, и я не нужен со своим опытом 8 лет
Плюсую. Я года 3 назад устроился в IT в 40 с лишним лет. Но до этого несколько лет пилил петпроеты, которые мне реально были интересны и имели прикладное значение, а не абстрактное чтение из Кафки, чтобы просто прочитать, как у автора поста. Некоторым людям проекты оказались интересны, в результате получил несколько десятков звездочек на гитхабе. Один из них разросся до 10к строк. В итоге устроился я без проблем
Потому что они в среднем (не все) не работают в команде, не работают долго над одним продуктом с его поддержкой, а поэтому склонны гавнокодить, работают над относительно примитивными задачами. И даже если кто-то из фрилансеров не такой, его сложно отличить в общей их массе
php вполне вариант, и команда важна. Но есть много случае, когда команды просто нет - нужно выбрать стек и команду, и тут часто выбор клонится в сторону языков вроде руби, пыхи и питона
Он не все ломает. Вся нагрузка ложится на разработчиков языка и библиотек, которые сишный апи используют. Нормально продуктовый код на чистом Питоне не затрагивается
Если это opt in решение будет, то конечно возможно. Но видимо этого все-таки не будет. Я только что слушал Соболева. Как я его понял, многим кор разработчикам не очень нравится сама концепция asyncio. И скорее не многопоточность будут тащить туда, а сделают чего-то green threads с отдельным api
Так сейчас asyncio исполняется в одном потоке, и все это понимают и пишут в основном потоко не безопасно, но без лишних локов, где это можно. В описанном вами варианте изменения из другого потока, наверняка или не нужна атомарность, или лок повесят. А вот если вдруг внезапно asyncio полетит во множестве потоков, то куча существующего кода разнесет
Практически везде в существующем коде есть такие куски
Ну, не так это. Если у вас есть некая переменная, к которой вы доступаетесь из разных корутин, то сейчас у вас есть гарантия, что ее никто не прочитает/поменяет между двумя async вызовами внутри одной корутины. И сейчас куча мест в коде, которые полагаются на это и не берут локи. В вашей реализации или в более полноценной эта гарантия ломается
Текущую реализацию очень сложно перевести в многопоточную - крайне мало вероятно, что это случится. Там слишком много завязано на то, что переключение может произойти только в очень определенных местах кода
Вы на старте не знаете нужна ли вам производительность - может через пол года ваш маленький проект умрет или всегда останется маленьким. При этом есть поверье, что на языках вроде Python, Ruby легче писать код с нуля за счет гибкости языка и библиотечек вроде рельсы или Джанго. Когда вы упретесь в производительность скорее всего будут ресурсы, как-то решить эту проблему
Начинаете вы когда производительность не важна, а со временем она может стать важной. И перед вами выбор - переписать все на более быстрый язык, или добавить костылики внутри языка и увеличить скорость не переписывая. Для многих переписать все не вариант
Никто никому не обязан. Не претендуя на общность, в моем окружении не нанимают фулстек разработчиков, а если спрашивают о Кафке, то нанимают бекэнд разработчика. Если бекэнд разработчик 10 лет перекладывал круды и не знает используемые им технологии достаточно глубоко и их сравнение с близкими по типу технологиями, не умеет делать между ними осмысленный выбор, то это не очень высокого уровня специалист, мало чем отличающийся от хорошего джуна по существу. При этом обычно он хочет достаточно серьезные деньги за свой 10-ний опыт. В большинстве случаев лучше взять амбициозного джуна с горящими глазами за меньшие деньги и растить его
А вы пытались смотреть какие-то видео про прохождение тех собесов? Обычный посыл, что новичкам и сеньорам в принципе задают одни и те же вопросы, но требуется разный ответ. Если вам задали вопрос про Кафку и вы ответили "Посылаешь принимаешь, можно делать реплей, очередь сохраняется", то это уровень джуна, и при 10 годах опыта очень жирный красный флаг. От человека с 10 годами опыта требуется показать глубину (внутреннее устройство Кафки, причины ее быстродействия, характерный кейс применения и т.д.) и широту (сравнение с кроликом, NATS и т.д.) знаний. Понятно, что все это не рассказать в формате интервью. Обычно вас останавливают через 30 секунд и могут погрузиться в какую-то тему, которую вы успели затронуть
SOLID - это не база, а достаточно спорный набор принципов из одной хайповой книжки, от многих от которых сам автор уже отказался. Нельзя как-то стандартно про него ответить. Про SOLID можно по рассуждать со знающим человеком с опытом на тему не все так однозначно. Если такие вопросы задает HR, то это реально дичь
У меня есть примеры про Яндекс, ВК и Озон. Это грязными, но обычно есть еще премия от оклада раз в пол года, а кое-где больше, так что на круг можно сказать чистыми
Я так и не понял, причем тут микросервисы. Вы не умеете писать на питоне, но приплели почему-то микросервисы
PS: Это прям эпично: Я PHP-разработчик с восьмилетним коммерческим опытом. А потом мы читаем статьи в которых авторы удивляются почему PHP во многих компаниях ред флаг и, что рынок труда полностью испорчен, и я не нужен со своим опытом 8 лет
Плюсую. Я года 3 назад устроился в IT в 40 с лишним лет. Но до этого несколько лет пилил петпроеты, которые мне реально были интересны и имели прикладное значение, а не абстрактное чтение из Кафки, чтобы просто прочитать, как у автора поста. Некоторым людям проекты оказались интересны, в результате получил несколько десятков звездочек на гитхабе. Один из них разросся до 10к строк. В итоге устроился я без проблем
Потому что они в среднем (не все) не работают в команде, не работают долго над одним продуктом с его поддержкой, а поэтому склонны гавнокодить, работают над относительно примитивными задачами. И даже если кто-то из фрилансеров не такой, его сложно отличить в общей их массе
php вполне вариант, и команда важна. Но есть много случае, когда команды просто нет - нужно выбрать стек и команду, и тут часто выбор клонится в сторону языков вроде руби, пыхи и питона
Он не все ломает. Вся нагрузка ложится на разработчиков языка и библиотек, которые сишный апи используют. Нормально продуктовый код на чистом Питоне не затрагивается
Если это opt in решение будет, то конечно возможно. Но видимо этого все-таки не будет. Я только что слушал Соболева. Как я его понял, многим кор разработчикам не очень нравится сама концепция asyncio. И скорее не многопоточность будут тащить туда, а сделают чего-то green threads с отдельным api
Кажется с python 3 наелись и больше такого не хоят
Модель dotnet практически невозможно затащить в Питон - сломается весь существующий асинхронный код
Так сейчас asyncio исполняется в одном потоке, и все это понимают и пишут в основном потоко не безопасно, но без лишних локов, где это можно. В описанном вами варианте изменения из другого потока, наверняка или не нужна атомарность, или лок повесят. А вот если вдруг внезапно asyncio полетит во множестве потоков, то куча существующего кода разнесет
Практически везде в существующем коде есть такие куски
И сейчас есть гарантия, что чтение атрибута и его обновление происходит атомарно, если специально не подпрыгивать с изменением его в другом потоке
Ну, не так это. Если у вас есть некая переменная, к которой вы доступаетесь из разных корутин, то сейчас у вас есть гарантия, что ее никто не прочитает/поменяет между двумя async вызовами внутри одной корутины. И сейчас куча мест в коде, которые полагаются на это и не берут локи. В вашей реализации или в более полноценной эта гарантия ломается
Текущую реализацию очень сложно перевести в многопоточную - крайне мало вероятно, что это случится. Там слишком много завязано на то, что переключение может произойти только в очень определенных местах кода
Вы на старте не знаете нужна ли вам производительность - может через пол года ваш маленький проект умрет или всегда останется маленьким. При этом есть поверье, что на языках вроде Python, Ruby легче писать код с нуля за счет гибкости языка и библиотечек вроде рельсы или Джанго. Когда вы упретесь в производительность скорее всего будут ресурсы, как-то решить эту проблему
Начинаете вы когда производительность не важна, а со временем она может стать важной. И перед вами выбор - переписать все на более быстрый язык, или добавить костылики внутри языка и увеличить скорость не переписывая. Для многих переписать все не вариант
Никто никому не обязан. Не претендуя на общность, в моем окружении не нанимают фулстек разработчиков, а если спрашивают о Кафке, то нанимают бекэнд разработчика. Если бекэнд разработчик 10 лет перекладывал круды и не знает используемые им технологии достаточно глубоко и их сравнение с близкими по типу технологиями, не умеет делать между ними осмысленный выбор, то это не очень высокого уровня специалист, мало чем отличающийся от хорошего джуна по существу. При этом обычно он хочет достаточно серьезные деньги за свой 10-ний опыт. В большинстве случаев лучше взять амбициозного джуна с горящими глазами за меньшие деньги и растить его
А вы пытались смотреть какие-то видео про прохождение тех собесов? Обычный посыл, что новичкам и сеньорам в принципе задают одни и те же вопросы, но требуется разный ответ. Если вам задали вопрос про Кафку и вы ответили "Посылаешь принимаешь, можно делать реплей, очередь сохраняется", то это уровень джуна, и при 10 годах опыта очень жирный красный флаг. От человека с 10 годами опыта требуется показать глубину (внутреннее устройство Кафки, причины ее быстродействия, характерный кейс применения и т.д.) и широту (сравнение с кроликом, NATS и т.д.) знаний. Понятно, что все это не рассказать в формате интервью. Обычно вас останавливают через 30 секунд и могут погрузиться в какую-то тему, которую вы успели затронуть
SOLID - это не база, а достаточно спорный набор принципов из одной хайповой книжки, от многих от которых сам автор уже отказался. Нельзя как-то стандартно про него ответить. Про SOLID можно по рассуждать со знающим человеком с опытом на тему не все так однозначно. Если такие вопросы задает HR, то это реально дичь
Объяснение простое. Раньше развитие шло за счет найма людей людей, а сейчас за счет покупки GPU
Ну не каждая, а пару стран, а у остальных силенок не хватит
У меня есть примеры про Яндекс, ВК и Озон. Это грязными, но обычно есть еще премия от оклада раз в пол года, а кое-где больше, так что на круг можно сказать чистыми
В российском биг Техе 200к стартовая зп после стажировки