Микросервисная архитектура прежде всего предназначена для разделения работы на несколько команд разработчиков, когда вся система не может поместиться в головах одной команды на 10 человек. Есть и другие предпосылки типа горизонтального масштабирования отдельных частей, независимого деплоя частей... Но в одиночку пилить микросервисы - обычно немного смысла, и неудивительно, что получился монолит.
Может нейросеть больше обучена С-подобным языкам, а не Verilog? По идее, лечится специальным промптом, если хоть какие-то подходящие умения есть, но запрятаны.
Ожидание внешнего сигнала, без которого дальнейшая цепочка действий невозможна встречается повсеместно и относится именно к предметной области, а не к деталям реализации
Только вот await из языков программирования для этого почти всегда не применим.
Что будет, если наш процесс прервался на await taskC (например, сбой)? Он перезапустится сначала, причём вся цепочка - с taskA (и хорошо, если те сервисы идемпотентны). Если это плохо применимо (например, сервисы A, B работают неидемпонтентно, отвечают долго, или промежуточные расчёты долгие), то в таких случаях вы всё равно вынуждены делать стейт-машину наподобие следующей, хоть async/await, хоть синхронный код (шагов может быть больше, если отделять расчёты в отдельные состояния):
state, context = await read_state()
while state!=FINAL_STATE:
match state:
case 0:
await serviceA.taskA(x,y)
...do_something...
await save_state(state:=1,context)
case 1:
await serviceA.taskA(x,y)
...do_something...
await save_state(state:=2,context)
case 2:
await serviceA.taskA(x,y)
await save_state(state:=FINAL_STATE,context)
Здесь await вызывает внешний сервис, и заставляет поток ОС заняться другой задачей. Если этот поток ОС прерван (например, был сбой, и наш сервис перезапушен), то стейт-машина продолжит бизнес-процесс с точки сохранения, что была перед сбоем, но заслуги конструкции языка async/await в этом нет. С тем же успехом тут мог быть синхронный код, причём в обоих этих примерах.
async/await - это всего лишь конструкция языка, помогающая вручную компактно упаковать вычисления и ожидания IO в существующие потоки ОС, что даёт эффективность выполнения кода за счёт минимизации простоя процессора и минимизации создания/переключений потоков ОС. Для ожидания внешних систем, если вам нужна устойчивая работа кода, эта конструкция неприменима. Поэтому, на мой взгляд, она и не имеет отношения к предметной области.
async, await, override настолько далеки от пользователя, что в java обходятся без них - язык или инфраструктура берут это на себя, выбирая некий вариант автоматически. А в python, например, решили, что это должен контролировать программист. Я не представляю, где в предметной области может понадобиться await, который относится чисто к управлению потоками внутри процесса ОС в компьютере, а не к бизнес-процессам (отличие в том, что поток в компьютере может прерываться по техническим причинам, а соответствующий бизнес-процесс может в это время продолжаться - т.е. это разные понятия, лишь отдалённо схожие, и ожидание в бизнес-процессе - это совершенно не await).
(@override / @Override здесь плохой пример, т.к. и в java, и в python он "фиктивный" - язык его не требует, в отличие от каких-нибудь scala, где это зачем-то обязательно, или delphi, где override напрямую влияет на способ вызова функции - виртуальный или обычный)
На каком основании async/await в прикладных?? Там рядом такая несуществующая в реальной жизни муть с event loop, что не каждый программист сходу разберётся. То же и @override @staticmethod @abstract - это детали реализации ООП...
А в Rust прикладного, возможно, ничего и нет - там 90% кода "имеет в виду" управление памятью. Постоянно ссылки, Box<T>, разыменования, стек, крейты, делегирование (это ещё число лайфтаймов в коде по сравнению с первыми версиями снижено в 10 раз).
По-моему, Python взлетел из-за 1) простоты, причём явно и фанатично декларируемой, 2) гибкости, подобной Lisp (только вместо списков - в Python словари как базовый контейнер для всего, в т.ч. и кода). Из этого всего смогли соорудить Tensorflow в виде, пригодном для запуска учёными, и пошло-поехало. С++ тоже подходит для таких вещей, но меньше подходит для непрограммистов. Ну и, возможно, ещё п. 3) легкая интеграция с C/С++.
А так сравнение забавное, заставляет задуматься, спасибо.
про замену целой команды все-таки сильное преувеличение
Не сказал бы. Недавно обнаружил, что claude неплохо оптимизирует код, на уровне повыше сеньора (если так можно назвать человека, кто 15+ лет оптимизацией занимается). Определённо, всю команду пока не заменяет, но отдельные скилы - да.
промпт-инжиниринг с каждым днем все больше напоминает синтаксис плюсов
Не сказал бы. Удивительно, но llm-агенты в последнее время понимают чуть ли не с полуслова, даже если писать обычный текст, без промптовых вывертов. Кажется, ещё год назад было хуже.
если у человека будут деньги на российский аналог Теслы или Лифа, то он купит последние, а не российский аналог
А это уже проблема восприятия брендов "наше или заморское". Решается тотальными запретами. Очень часто своё воспринимается негативно, не только у нас. И вряд ли низкие цены тут помогут - за ними рано или поздно следует ужасное качество. Нужно что-то, что может завоевать доверие, причём в условиях жёсткой конкуренции и медийных войн.
Так-то да, но это имеет смысл в неблагополучных районах. И в настройках обычно есть опция - разблокировка автоматически/кнопкой на двери/кнопкой на брелке, так что это не проблема.
Ока никому сейчас не нужна - очень маленькая по сравнению с китайцами. Есть всякие рено твизи, smart - очень редкие.
Так что единственный жизнеспособный план делать экономически окупаемые электрички - это условная Ока, едущая 200-300 км. Еще желательно и с модульной в несколько частей батареей, в которой можно относительно легко менять сдохшие/поврежденные в аварии сегменты. И никакого выпендрежа с футуризмом, что-то уровня ВАЗ-1111Э .
Имхо, то, что вы предлагаете, во-первых, никому не нужно по причине убогости, во-вторых, невозможно разработать по причине подразумеваемой низкой цены. Большую дорогую машину делать просто и приятно, маленькую и дешёвую - сложно и экономически невыгодно.
Даже при маневрировании во дворе можно не перехватывать руль — поворота руля на 270° обычно хватает, при этом достаточно отпускать одну руку, сохраняя контакт с рулём второй рукой. А вот при парковке перехваты требуются почти всегда.
У меня яндекс-такси долгое время, если указывать адрес, вызывалось не к главному входу предприятия, а к черному, который почти всегда закрыт, и к которому таксисту ехать плюс пять минут дворами, да еще и мне идти плюс пару минут.
Но переплюнул Яндекс таксист, который, игнорировав навигатор, зарулил под знак и зачем-то проехал под окнами администрации.
Какой ужас. Та дорога, что вы предлагаете, - по виду с панорам жилая зона, поэтому вероятно навигатор не ведёт по ней (хотя у меня бывало, что навигатор начинал вести дворами там, где есть улица). Та дорога, что предлагает навигатор - фактически убитая грунтовка. И эти дороги очень узкие.
Здесь, возможно, через "Народные карты" нужно поменять класс дороги на нечто вроде "убитые ебеня" на что-то малозначимое, чтобы навигатор не давал приоритет плохому пути. Ну или ремонт затеять.
Микросервисная архитектура прежде всего предназначена для разделения работы на несколько команд разработчиков, когда вся система не может поместиться в головах одной команды на 10 человек. Есть и другие предпосылки типа горизонтального масштабирования отдельных частей, независимого деплоя частей... Но в одиночку пилить микросервисы - обычно немного смысла, и неудивительно, что получился монолит.
"Автор в детстве не просто потерялся в лесу, а был спасён и воспитан большими языковыми моделями".
Может нейросеть больше обучена С-подобным языкам, а не Verilog? По идее, лечится специальным промптом, если хоть какие-то подходящие умения есть, но запрятаны.
Только вот await из языков программирования для этого почти всегда не применим.
Допустим, у нас есть несколько ожиданий:
await serviceA.taskA(x,y)...do something...
await serviceB.taskB(a,b,c)
...do something...
await serviceC.taskC(c,d,a)
Что будет, если наш процесс прервался на await taskC (например, сбой)? Он перезапустится сначала, причём вся цепочка - с taskA (и хорошо, если те сервисы идемпотентны). Если это плохо применимо (например, сервисы A, B работают неидемпонтентно, отвечают долго, или промежуточные расчёты долгие), то в таких случаях вы всё равно вынуждены делать стейт-машину наподобие следующей, хоть async/await, хоть синхронный код (шагов может быть больше, если отделять расчёты в отдельные состояния):
state, context = await read_state() while state!=FINAL_STATE: match state: case 0: await serviceA.taskA(x,y) ...do_something... await save_state(state:=1,context) case 1: await serviceA.taskA(x,y) ...do_something... await save_state(state:=2,context) case 2: await serviceA.taskA(x,y) await save_state(state:=FINAL_STATE,context)Здесь await вызывает внешний сервис, и заставляет поток ОС заняться другой задачей. Если этот поток ОС прерван (например, был сбой, и наш сервис перезапушен), то стейт-машина продолжит бизнес-процесс с точки сохранения, что была перед сбоем, но заслуги конструкции языка async/await в этом нет. С тем же успехом тут мог быть синхронный код, причём в обоих этих примерах.
async/await - это всего лишь конструкция языка, помогающая вручную компактно упаковать вычисления и ожидания IO в существующие потоки ОС, что даёт эффективность выполнения кода за счёт минимизации простоя процессора и минимизации создания/переключений потоков ОС. Для ожидания внешних систем, если вам нужна устойчивая работа кода, эта конструкция неприменима. Поэтому, на мой взгляд, она и не имеет отношения к предметной области.
async, await, override настолько далеки от пользователя, что в java обходятся без них - язык или инфраструктура берут это на себя, выбирая некий вариант автоматически. А в python, например, решили, что это должен контролировать программист. Я не представляю, где в предметной области может понадобиться await, который относится чисто к управлению потоками внутри процесса ОС в компьютере, а не к бизнес-процессам (отличие в том, что поток в компьютере может прерываться по техническим причинам, а соответствующий бизнес-процесс может в это время продолжаться - т.е. это разные понятия, лишь отдалённо схожие, и ожидание в бизнес-процессе - это совершенно не await).
(
@override/@Overrideздесь плохой пример, т.к. и в java, и в python он "фиктивный" - язык его не требует, в отличие от каких-нибудь scala, где это зачем-то обязательно, или delphi, где override напрямую влияет на способ вызова функции - виртуальный или обычный)На каком основании async/await в прикладных?? Там рядом такая несуществующая в реальной жизни муть с event loop, что не каждый программист сходу разберётся. То же и
@override @staticmethod @abstract- это детали реализации ООП...А в Rust прикладного, возможно, ничего и нет - там 90% кода "имеет в виду" управление памятью. Постоянно ссылки, Box<T>, разыменования, стек, крейты, делегирование (это ещё число лайфтаймов в коде по сравнению с первыми версиями снижено
в 10 раз).По-моему, Python взлетел из-за 1) простоты, причём явно и фанатично декларируемой, 2) гибкости, подобной Lisp (только вместо списков - в Python словари как базовый контейнер для всего, в т.ч. и кода). Из этого всего смогли соорудить Tensorflow в виде, пригодном для запуска учёными, и пошло-поехало. С++ тоже подходит для таких вещей, но меньше подходит для непрограммистов. Ну и, возможно, ещё п. 3) легкая интеграция с C/С++.
А так сравнение забавное, заставляет задуматься, спасибо.
Было бы интересно увидеть и opencode в сравнении... Имхо, перспективная штука.
Не сказал бы. Недавно обнаружил, что claude неплохо оптимизирует код, на уровне повыше сеньора (если так можно назвать человека, кто 15+ лет оптимизацией занимается). Определённо, всю команду пока не заменяет, но отдельные скилы - да.
Не сказал бы. Удивительно, но llm-агенты в последнее время понимают чуть ли не с полуслова, даже если писать обычный текст, без промптовых вывертов. Кажется, ещё год назад было хуже.
А это уже проблема восприятия брендов "наше или заморское".
Решается тотальными запретами.Очень часто своё воспринимается негативно, не только у нас. И вряд ли низкие цены тут помогут - за ними рано или поздно следует ужасное качество. Нужно что-то, что может завоевать доверие, причём в условиях жёсткой конкуренции и медийных войн.Так-то да, но это имеет смысл в неблагополучных районах. И в настройках обычно есть опция - разблокировка автоматически/кнопкой на двери/кнопкой на брелке, так что это не проблема.
Чтобы не отпускать полностью руль. Так меньше действий делается, и повороты получаются проще и быстрее.
Обычное расположение рук "на 9-3", никакой акробатики.
Ока никому сейчас не нужна - очень маленькая по сравнению с китайцами. Есть всякие рено твизи, smart - очень редкие.
Имхо, то, что вы предлагаете, во-первых, никому не нужно по причине убогости, во-вторых, невозможно разработать по причине подразумеваемой низкой цены. Большую дорогую машину делать просто и приятно, маленькую и дешёвую - сложно и экономически невыгодно.
Наверняка пока что если результаты краш-тестов и есть, то только от производителя. Модель только выпустили.
А так, тот же вопрос и у меня.
Даже при маневрировании во дворе можно не перехватывать руль — поворота руля на 270° обычно хватает, при этом достаточно отпускать одну руку, сохраняя контакт с рулём второй рукой. А вот при парковке перехваты требуются почти всегда.
Телепортацию запретят, как сейчас отказываются от удалёнки :)
В том здании отмечен только 1 главный вход. Полагаю, сбой был из-за того, что на карте к центру здания была ближе дворовая дорога, а не улица.
Есть такое.
У меня яндекс-такси долгое время, если указывать адрес, вызывалось не к главному входу предприятия, а к черному, который почти всегда закрыт, и к которому таксисту ехать плюс пять минут дворами, да еще и мне идти плюс пару минут.
Но переплюнул Яндекс таксист, который, игнорировав навигатор, зарулил под знак и зачем-то проехал под окнами администрации.
Какой ужас. Та дорога, что вы предлагаете, - по виду с панорам жилая зона, поэтому вероятно навигатор не ведёт по ней (хотя у меня бывало, что навигатор начинал вести дворами там, где есть улица). Та дорога, что предлагает навигатор - фактически убитая грунтовка. И эти дороги очень узкие.
Здесь, возможно, через "Народные карты" нужно поменять класс дороги
на нечто вроде "убитые ебеня"на что-то малозначимое, чтобы навигатор не давал приоритет плохому пути. Ну или ремонт затеять.