Судя по скриншотам, пытаются смотреть через Германию. Вопрос - это не региональные ли блокировки? Просто в Германии и так целая куча видео недоступна, и они продолжают добавлять новые (у них там драконовское законодательство для контента). Я не к тому что ютуб не начал что-то ещё блокировать, но если из Германии что-то не работает, полезно на всякий случай проверить из другой страны, у них там и в мирное время контент блокируют.
Может описывать эксперимент и разбивать на шаги, чтобы его отростки-лаборанты его выполняли и передавали результат эксперимента обратно в LLM? Эта-то часть вопросов не вызывает.
Если стоимость простоя низкая, то вы начинаете с того что есть и улучшаете процессы пока у вас не получается удовлетворительный контроль качества. Если же стоимость простоя настолько высока что несколько таких простоев потопят вашу компанию то, простите, фокусируетесь вы уже далеко не только на выборе языка.
Да, root cause у CrowdStrike был с буферами памяти. Но это несущественно, потому что, если ваш продукт способен положить половину крупного бизнеса, то вы фокусируетесь не на паническом переписывании всего на Rust, а на процессах тестирования и внедрении phased rollouts, что вы так или иначе должны были сделать давным-давно потому что существует масса возможных проблем которые Rust просто не покрывает. Логические ошибки, ошибки конфигурации, недостаточный контроль входных данных, сетевые ошибки, аппаратные, человеческие ошибки на каждом этапе... Если у вас есть риски, то вы их оцениваете, и амортизируете их наиболее эффективными методами вместо того чтобы "а вот давайте всё перепишем на X и все проблемы исчезнут". Не исчезнут.
Точную оценку - нет, приблизительную, достаточную для оценки рисков - почему бы нет. Реальный вопрос в вашем случае, конечно, какая была стоимость простоя и окупилось ли бы внедрение Typescript. Это всё вполне себе оценивается, особенно если проект существует уже давно и есть статистика. Конечно же стоимости простоев надо считать, тем более что для разных проектов (как раз то о чём я и говорил) они могут быть от незначительных (ну упадёт у кого-то игра время от времени, зато выкатили вовремя и получили продажи) до настолько критичных что они стоят крупных инвестиций (mission critical / safety critical например).
Небольшим количеством времени - это каким, мне любопытно? :) Вы, к примеру, готовы оценить, для конкретного проекта, в монетарном эквиваленте, затраты времени и ресурсов на внедрение, переобучение, разработку тулинга, адаптацию инфраструктуры, недополученную прибыль из-за приостановки внедрения новых фич - и так далее, список длинный, вы и так понимаете - и взвесить эту оценку против, скажем, поддержки (уже существующей) пачки тестов для C++ проекта, статического анализа в пайплайне и (что в любом случае должно быть) peer review перед интеграцией где люди не будут давать друг другу коммитить код не соответствующий (в принципе уже достаточно безопасным) практикам последних стандартов, плюс покрытие некоторых (поддающихся оценке) убытков от того что в конкретном проекта продакшн упадёт и будет чиниться в среднем полтора часа в год?
Не поймите меня неправильно, я не против Раста, и не против того чтобы действительно провести такую оценку. Я лишь говорю о том, что такая оценка должна быть проведена, не все могут позволить себе выбрасывать деньги на ветер, и если конечный счёт оказывается не в пользу Rust, то в этом конкретном проекте Rust хуже чем C++. Не "хуже для горстки старпёров", а объективно хуже, потому что из-за него пользователь получает меньше и платит больше. Sad but true. Серебряных пуль нет, не существует one size fits all, существуют конкретные проекты с конкретными условиями. Плюсы должны перевешивать минусы. "Несоизмеримо большее время" и "небольшое количество времени" - я вот не готов такое отнести к людям, котрым по должности положено беспокоиться о том что, если они сделают неверный выбор, то через год паре тысяч их сотрудников придётся искать новую работу а им самим останется оформлять банкротство и идти в управдомы.
Ну, у меня есть определённые сомнения. Монополии вроде MS как раз дошли до такой точки когда они могут себе позволить дорогостоящие эксперименты с неясным return on investment, это как бы не первое для них родео. Если получится хорошо, то и богу слава. Если Rust к стене не прилипнет - спишут убытки а тех кого нанимали, так и сократят заодно ещё с десятком тысяч человек. Если компании надо действительно считать деньги чтобы остаться на плаву - там другая история.
Ну, если столько всего написано но ничего из этого ещё не мэйнстрим, то, может быть, есть ещё что доказывать. :) Пригодность языка, в широком понимании (да и любой технологии) - это способность принести business value если его внедрить.С точки зрения конечного пользователя, если он платит N дополнительных денег на внедрение но его жизнь не становится пропорционально лучше / прибыль не растёт на сумму, большую чем потратили на внедрение, то технология не нужна.
Вот поэтому мне печально видеть апологетов Раста кривящих нос на "нетехническую ерунду". Потому что Rust сейчас в той стадии, где на эту ерунду как раз и надо обращать внимание. Все уже поняли что такое borrow checker, горшочек не вари, теперь надо наконец повзрослеть и определить как прелести языка трансформируются в добавленную прибыль после внедрения и донести это знание в массы. Если Rust не способен просто существованием ядер и гипервизоров доказать что он сделает жизнь конечных пользователей лучше (или их карман - толще), то надо отправлять внедренцев к менеджменту а не ещё больше евангелистов на форумы.
Кстати, не знаю откуда выше 7.5 евро, но я плачу в районе 0.1 евро за кВтч (ночью меньше), так что на сто километров получается в районе полутора евро если заряжать в гараже. На заправке больше, конечно, но не радикально.
Ну, тут с какой стороны посмотреть. Тормоза ДВС обратно бензин в баки могут закачивать? И да, тот факт что в большинстве случаев достаточно рекуперативного торможения, означает что тормозные колодки не так быстро изнашиваются.
У многих электромобилей (у меня самого пример перед глазами, BMW i3) к тому же есть "однопедальный" режим где при отпускании педали включается рекуперативное торможение. Ужасно удобно.
Колодки - да (хотя вроде бы полуметаллические самые популярные пока?), а менее пылящими - цифры выше, тормоза похоже больше пылят по весу пыли чем шины, и (это к @vadimir) пыль от тормозов более мелкидисперсная.
С другой стороны, металлическая пыль считается более токсичной, нет? Кроме того, я вот запросил, и похоже что колодки дают больше выхода частиц по массе (шины 2.5-3.2mg/mile, тормоза 3.3-13.6mg/mile), так что эффект от рекуперативного торможения вполне может перевешивать повышенный выход частиц с шин.
В целом всё так, сгенерированное формально хранить не надо. Но если его много и меняется оно не часто (много-много редко меняющихся RPC), то можно и хранить, чтобы сберечь время разработчикам и сократить время сборок в CI/CD, плюс это сглаживает проблему зоопарка версий генераторов у разработчиков. До объектных файлов в репозитории пока не дошли, но кэш компиляции подключаемый при сборке к контейнеру на гитлабе - это уже вполне себе практика. Всё ради скорости. :)
(Спасибо за молчаливый минус, кем бы вы ни были, в следующий раз может быть наберётесь храбрости даже сказать с чем именно несогласны. ^^)
Номер версии при генерации, конечно, надоедает, но есть целая куча аргументов за то чтобы он там был, особенно если в команде люди используют разные версии генераторов. Но если совсем уже достало, то в принципе можно чуть-чуть постоять на голове и вычистить из сгенерированного версию тем же sed (хотя в идеале лучше удостовериться что у всех одна и та же версия генератора).
Ну, если уж такой разговор зашёл, то в любых более или менее сложных проектах на C++ есть и code style conventions, и проверки формата которые не дадут ничего смёржить пока clang-tidy чем-то недоволен, и документация по проекту где есть соглашения о том в какие дебри забредать не надо, и ревьюверы которые не дадут увлечься шаблонной уличной магией. :)
Меня персонально всегда смущал путь Rust на концептуальном уровне. Большинство современных языков стремится сделать написание корректного кода проще. Rust стремится сделать написание некорректного кода сложнее - казалось бы похоже но, как говорят в Одессе, две большие разницы.
А зачем ему этим заниматься, по здравому размышлению? Ему за паттерны и пул реквесты денег не платят, он выбирает инструменты для достижения практических целей. Вот он и пишет статью про то, что вот мол он попробовал инструмент, как молоток не работает. А переделывать его в молоток вместо того чтобы взять молоток и гвозди начать забивать - это не его дело.
Просто разработчики/фанаты отвёрток любят всем говорить что их отвёртки созданы как убийцы молотков, вот люди и проверяют их на гвоздях. :)
Ну-у-у... "проще" - это слово открытое к интерпретации и зависит от того что считать конечной целью. Если допиливать до вылизанного и свободного от багов состояния - да. Если допиливать до состояния где оно не падает уж очень часто и не лишает игру играбельности - то это уже совсем другой коленкор, там надо чтобы компилятор с пониманием относился к срокам релиза и тому что капельницы с кофе уже на исходе. :) Игровая индустрия обычно предпочитает второе.
Тут в игру (pun intended!) вступает такой момент что движков вокруг уже полно и движок - это обычно штука которая не страдает от чрезмерного обилия багов после начального периода развития, так что сложно придумать вразумительную причину по которой нам очень-очень нужен движок именно на Rust. И наоборот, если какая-то компания берёт движок и допиливает его для нужд крупного AAA-проекта (как делали с Lumberyard например), им уже начнёт вставлять палки в колёса тот факт что быстро допиливать будет не так-то просто потому что Rust их бьёт по рукам а сроки горят и надо выкатывать игру уже вот-вот, а бизнес модель "пипл схавает, а краши поправим первым хотфиксом после релиза" реально работает и приносит деньги.
Я в своё время сбросил около 20 килограмм, в районе 1.5-2 кг в месяц. Low carb диета и кардио каждый день - между 40 минутами и часом на беговой дорожке. И да, я принимал л-карнитин, но без интенсивного кардио он просто не будет работать (те кто с биохимией знаком лучше меня объяснят, но если очень просто и не совсем правильно - он не нужен пока имеющийся не истощится, а истощается он активным расщеплением жиров, сам по себе он ничего не расщепляет, у него транспортная функция). Но что правда то правда, побочные эффекты неприятные - энергии, особенно с утра, нет, ходишь злой и раздражительный.
Как по мне, удержать вес сложнее чем сбросить. Найти мотивацию придерживаться диеты и спортивного режима пока худеешь - это сложно. Найти мотивацию так и дальше всю жизнь продолжать - ещё сложнее. :) Я большую часть этого веса обратно набрал, и теберь вот начинаю худеть снова.
Судя по скриншотам, пытаются смотреть через Германию. Вопрос - это не региональные ли блокировки? Просто в Германии и так целая куча видео недоступна, и они продолжают добавлять новые (у них там драконовское законодательство для контента). Я не к тому что ютуб не начал что-то ещё блокировать, но если из Германии что-то не работает, полезно на всякий случай проверить из другой страны, у них там и в мирное время контент блокируют.
Может описывать эксперимент и разбивать на шаги, чтобы его отростки-лаборанты его выполняли и передавали результат эксперимента обратно в LLM? Эта-то часть вопросов не вызывает.
Если стоимость простоя низкая, то вы начинаете с того что есть и улучшаете процессы пока у вас не получается удовлетворительный контроль качества. Если же стоимость простоя настолько высока что несколько таких простоев потопят вашу компанию то, простите, фокусируетесь вы уже далеко не только на выборе языка.
Да, root cause у CrowdStrike был с буферами памяти. Но это несущественно, потому что, если ваш продукт способен положить половину крупного бизнеса, то вы фокусируетесь не на паническом переписывании всего на Rust, а на процессах тестирования и внедрении phased rollouts, что вы так или иначе должны были сделать давным-давно потому что существует масса возможных проблем которые Rust просто не покрывает. Логические ошибки, ошибки конфигурации, недостаточный контроль входных данных, сетевые ошибки, аппаратные, человеческие ошибки на каждом этапе... Если у вас есть риски, то вы их оцениваете, и амортизируете их наиболее эффективными методами вместо того чтобы "а вот давайте всё перепишем на X и все проблемы исчезнут". Не исчезнут.
Точную оценку - нет, приблизительную, достаточную для оценки рисков - почему бы нет. Реальный вопрос в вашем случае, конечно, какая была стоимость простоя и окупилось ли бы внедрение Typescript. Это всё вполне себе оценивается, особенно если проект существует уже давно и есть статистика. Конечно же стоимости простоев надо считать, тем более что для разных проектов (как раз то о чём я и говорил) они могут быть от незначительных (ну упадёт у кого-то игра время от времени, зато выкатили вовремя и получили продажи) до настолько критичных что они стоят крупных инвестиций (mission critical / safety critical например).
Небольшим количеством времени - это каким, мне любопытно? :) Вы, к примеру, готовы оценить, для конкретного проекта, в монетарном эквиваленте, затраты времени и ресурсов на внедрение, переобучение, разработку тулинга, адаптацию инфраструктуры, недополученную прибыль из-за приостановки внедрения новых фич - и так далее, список длинный, вы и так понимаете - и взвесить эту оценку против, скажем, поддержки (уже существующей) пачки тестов для C++ проекта, статического анализа в пайплайне и (что в любом случае должно быть) peer review перед интеграцией где люди не будут давать друг другу коммитить код не соответствующий (в принципе уже достаточно безопасным) практикам последних стандартов, плюс покрытие некоторых (поддающихся оценке) убытков от того что в конкретном проекта продакшн упадёт и будет чиниться в среднем полтора часа в год?
Не поймите меня неправильно, я не против Раста, и не против того чтобы действительно провести такую оценку. Я лишь говорю о том, что такая оценка должна быть проведена, не все могут позволить себе выбрасывать деньги на ветер, и если конечный счёт оказывается не в пользу Rust, то в этом конкретном проекте Rust хуже чем C++. Не "хуже для горстки старпёров", а объективно хуже, потому что из-за него пользователь получает меньше и платит больше. Sad but true. Серебряных пуль нет, не существует one size fits all, существуют конкретные проекты с конкретными условиями. Плюсы должны перевешивать минусы. "Несоизмеримо большее время" и "небольшое количество времени" - я вот не готов такое отнести к людям, котрым по должности положено беспокоиться о том что, если они сделают неверный выбор, то через год паре тысяч их сотрудников придётся искать новую работу а им самим останется оформлять банкротство и идти в управдомы.
Ну, у меня есть определённые сомнения. Монополии вроде MS как раз дошли до такой точки когда они могут себе позволить дорогостоящие эксперименты с неясным return on investment, это как бы не первое для них родео. Если получится хорошо, то и богу слава. Если Rust к стене не прилипнет - спишут убытки а тех кого нанимали, так и сократят заодно ещё с десятком тысяч человек. Если компании надо действительно считать деньги чтобы остаться на плаву - там другая история.
Ну, если столько всего написано но ничего из этого ещё не мэйнстрим, то, может быть, есть ещё что доказывать. :) Пригодность языка, в широком понимании (да и любой технологии) - это способность принести business value если его внедрить.С точки зрения конечного пользователя, если он платит N дополнительных денег на внедрение но его жизнь не становится пропорционально лучше / прибыль не растёт на сумму, большую чем потратили на внедрение, то технология не нужна.
Вот поэтому мне печально видеть апологетов Раста кривящих нос на "нетехническую ерунду". Потому что Rust сейчас в той стадии, где на эту ерунду как раз и надо обращать внимание. Все уже поняли что такое borrow checker, горшочек не вари, теперь надо наконец повзрослеть и определить как прелести языка трансформируются в добавленную прибыль после внедрения и донести это знание в массы. Если Rust не способен просто существованием ядер и гипервизоров доказать что он сделает жизнь конечных пользователей лучше (или их карман - толще), то надо отправлять внедренцев к менеджменту а не ещё больше евангелистов на форумы.
У меня на i3 примерно так и получается.
Кстати, не знаю откуда выше 7.5 евро, но я плачу в районе 0.1 евро за кВтч (ночью меньше), так что на сто километров получается в районе полутора евро если заряжать в гараже. На заправке больше, конечно, но не радикально.
Ну, тут с какой стороны посмотреть. Тормоза ДВС обратно бензин в баки могут закачивать? И да, тот факт что в большинстве случаев достаточно рекуперативного торможения, означает что тормозные колодки не так быстро изнашиваются.
Вы, это, почаще всем напоминайте что они тут не нужны и могут валить на все четыре стороны, может им от этого внезапно расхочется валить. :)
У многих электромобилей (у меня самого пример перед глазами, BMW i3) к тому же есть "однопедальный" режим где при отпускании педали включается рекуперативное торможение. Ужасно удобно.
Колодки - да (хотя вроде бы полуметаллические самые популярные пока?), а менее пылящими - цифры выше, тормоза похоже больше пылят по весу пыли чем шины, и (это к @vadimir) пыль от тормозов более мелкидисперсная.
С другой стороны, металлическая пыль считается более токсичной, нет? Кроме того, я вот запросил, и похоже что колодки дают больше выхода частиц по массе (шины 2.5-3.2mg/mile, тормоза 3.3-13.6mg/mile), так что эффект от рекуперативного торможения вполне может перевешивать повышенный выход частиц с шин.
В целом всё так, сгенерированное формально хранить не надо. Но если его много и меняется оно не часто (много-много редко меняющихся RPC), то можно и хранить, чтобы сберечь время разработчикам и сократить время сборок в CI/CD, плюс это сглаживает проблему зоопарка версий генераторов у разработчиков. До объектных файлов в репозитории пока не дошли, но кэш компиляции подключаемый при сборке к контейнеру на гитлабе - это уже вполне себе практика. Всё ради скорости. :)
(Спасибо за молчаливый минус, кем бы вы ни были, в следующий раз может быть наберётесь храбрости даже сказать с чем именно несогласны. ^^)
Номер версии при генерации, конечно, надоедает, но есть целая куча аргументов за то чтобы он там был, особенно если в команде люди используют разные версии генераторов. Но если совсем уже достало, то в принципе можно чуть-чуть постоять на голове и вычистить из сгенерированного версию тем же sed (хотя в идеале лучше удостовериться что у всех одна и та же версия генератора).
Ну, если уж такой разговор зашёл, то в любых более или менее сложных проектах на C++ есть и code style conventions, и проверки формата которые не дадут ничего смёржить пока clang-tidy чем-то недоволен, и документация по проекту где есть соглашения о том в какие дебри забредать не надо, и ревьюверы которые не дадут увлечься шаблонной уличной магией. :)
Меня персонально всегда смущал путь Rust на концептуальном уровне. Большинство современных языков стремится сделать написание корректного кода проще. Rust стремится сделать написание некорректного кода сложнее - казалось бы похоже но, как говорят в Одессе, две большие разницы.
А зачем ему этим заниматься, по здравому размышлению? Ему за паттерны и пул реквесты денег не платят, он выбирает инструменты для достижения практических целей. Вот он и пишет статью про то, что вот мол он попробовал инструмент, как молоток не работает. А переделывать его в молоток вместо того чтобы взять молоток и гвозди начать забивать - это не его дело.
Просто разработчики/фанаты отвёрток любят всем говорить что их отвёртки созданы как убийцы молотков, вот люди и проверяют их на гвоздях. :)
Ну-у-у... "проще" - это слово открытое к интерпретации и зависит от того что считать конечной целью. Если допиливать до вылизанного и свободного от багов состояния - да. Если допиливать до состояния где оно не падает уж очень часто и не лишает игру играбельности - то это уже совсем другой коленкор, там надо чтобы компилятор с пониманием относился к срокам релиза и тому что капельницы с кофе уже на исходе. :) Игровая индустрия обычно предпочитает второе.
Тут в игру (pun intended!) вступает такой момент что движков вокруг уже полно и движок - это обычно штука которая не страдает от чрезмерного обилия багов после начального периода развития, так что сложно придумать вразумительную причину по которой нам очень-очень нужен движок именно на Rust. И наоборот, если какая-то компания берёт движок и допиливает его для нужд крупного AAA-проекта (как делали с Lumberyard например), им уже начнёт вставлять палки в колёса тот факт что быстро допиливать будет не так-то просто потому что Rust их бьёт по рукам а сроки горят и надо выкатывать игру уже вот-вот, а бизнес модель "пипл схавает, а краши поправим первым хотфиксом после релиза" реально работает и приносит деньги.
Я в своё время сбросил около 20 килограмм, в районе 1.5-2 кг в месяц. Low carb диета и кардио каждый день - между 40 минутами и часом на беговой дорожке. И да, я принимал л-карнитин, но без интенсивного кардио он просто не будет работать (те кто с биохимией знаком лучше меня объяснят, но если очень просто и не совсем правильно - он не нужен пока имеющийся не истощится, а истощается он активным расщеплением жиров, сам по себе он ничего не расщепляет, у него транспортная функция). Но что правда то правда, побочные эффекты неприятные - энергии, особенно с утра, нет, ходишь злой и раздражительный.
Как по мне, удержать вес сложнее чем сбросить. Найти мотивацию придерживаться диеты и спортивного режима пока худеешь - это сложно. Найти мотивацию так и дальше всю жизнь продолжать - ещё сложнее. :) Я большую часть этого веса обратно набрал, и теберь вот начинаю худеть снова.