Ну я условно сказал, да. Та же Jita перманентно висит на выделенной ноде, например. Плюс у них есть некоторое количество резервных нод, которые они присовывают заранее куда надо, если знают о предстоящем сражении. Там же есть на сайте кнопочка "рассказать разрабам, что мы хотим крупно подраться". Специально, чтобы они заранее подсуетились и туда нод подкинули
А лагает-то из-за чего по-вашему? TD вводится на всей ноде, поэтому зачастую можно влететь в такой кисель за 3-4 системы от самого сражения. Потому что лагает сама нода, и таким образом пытается это компенсировать. И именно поэтому при подключении резервных нод TD отключается или сводится к минимуму. Потому что он рассчитывается от нагрузки сервера, а не клиентов
Ева уже вешается там из-за этого питона. Они сидят на нестандартном несовместимом компиляторе (чтобы избавиться от GIL, который авторы стандартного питона фиксить не собираются видимо), половину бэка утащили на Азуры, мигрировали полностью на gRPC, каждую парочку звездных систем обслуживает отдельный сервер (просто этого глазами не видно), и все равно лагает)
Собственно поэтому им и пришлось много лет назад добавить TiDi, оно же космокисель. Это когда при увеличении нагрузки на сервер (большое сражение) сервер начинает замедлять тики, чтобы успевать все обрабатывать. В итоге абсолютно все процессы в игре происходят дольше (коэффициент замедления), при максимуме "кисельности" битва 6к игроков идет 27 часов)
А съехать с питона они не могут. Другого не умеют, плюс там лютый лапшекод, настаивавшийся с 2003 года. Вот и страдают все. Пять лет уже плотно переписывают все, и лет 15 просто пытаются как-то решить лаги. Но воз и ныне там
Мне даже интересно стало. Почему вы в один ряд с сями ставите голенг (!) как пример быстрого масштабируемого языка (!!), но даже не упоминаете Rust, который в 8 раз быстрее голенга, на уровне жавы по сложности и гораздо проще и удобнее сей?
Ну удобство - оно субъективно. Я, например, Go не рассматриваю именно из-за неудобства синтаксиса во многих моментах и безальтернативности правил написания кода в языке. Так еще и позиция его создателей играет роль, которые сознательно ухудшают скорость работы программ ради скорости сборки и не дают это отключить
Лично мне Rust удобнее, поскольку спасает от гораздо большего количества ошибок и многое позволяет, гораздо больше Go. При том же объеме кода микросервисы на Rust (выглядят 1 в 1 как ExpressJs с тайпскриптом) работают в 8 раз быстрее Go, в 10 раз быстрее ExpressJs и в 30 раз быстрее Spring. Сам язык я считаю по уровню сложности наравне с Java/C#, так что проблема лишь в его молодости, из-за которой специалистов мало (но в него вцепились крупные корпорации намертво, так что вопрос времени)
В таком случае, зачем он скачивает Mono и Mac Catalyst для билда проекта? И почему в официальной документации MAUI на сайте Майкрософта куча упоминаний работы через эмулятор и Mono, которую я выше описал? Тут одно из двух: или оно действительно так работает (что как бы мдэ), или документация нагло врет, еще и в куче мест сразу (что еще хуже)
Для мимокрокодила, который далек от DS сферы и работает на Java и Typescript, это выглядит примерно на уровне ассемблера в смысле Quality of Life. Про Rust и заикаться больно, сравнение с его дружелюбными сообщениями об ошибках вообще будет избиением младенца
Очень странная подсветка в блоках кода на Rust. Буквально 2-3 слова подсвечивает, остальное серое. Это у меня баг или автор выставил не Rust в качестве языка для них?
Ну я не спорю, что нормальная возможность. Но имхо на том же Rust это будет не сложнее, а профита и возможностей больше (а может просто у меня уже профдеформация из-за того, что пишу на нескольких языках)
К слову, код Rust тоже кроссплатформерный. В смысле один компилятор, есть кросс-компиляция и нет undefined behavior, т.е. можно гарантировать переносимость кода (если он конечно не использует системные апи или конкретное железо, но это и так очевидно)
Ну тогда согласен, что это достойное решение для фанатов C#. По сути из реальных минусов только GC, наличие которого ставит крест на RT-окружении. Ну и работа поверх ОС тоже урезает доступные ресурсы и прочее. На той же STM32 Rust работает bare metal, как и на других embedded платформах (но при желании никто не мешает и поверх ОС запустить, тогда даже std будет)
Но я в целом шарп не люблю, как и Майкрософт, поэтому не для меня)
Не нужно путать теплое с мягким. Как я понял, дотнету обязательно нужна операционка для работы. Но если у нас есть операционка, то можно писать и на обычном полноценном Rust. А Embedded нужен для bare metal сред, когда мы пишем напрямую под железо, без какой-либо операционки или среды исполнения, только прошивка и программатор
UPD: погуглил, похоже дотнет тоже может на bare metal работать, но поддерживает меньше платформ, чем Rust (например FPGA от Xilinx). Просто по вашей статье сложилось впечатление, что он без позикса не живет. Ну в таком случае сравнение корректно, но я все равно считаю, что и сам язык удобнее и безопаснее, и отсутствие GC много где критично (= любое реальное время)
Торвальдс критикует всё, что не чистый Си. И то, разговоры о добавлении Rust в линь увенчались далеко не громким отказом (в отличие от того же С++)
Если Rust наберет популярность для embedded устройств, то это будет замечательно, все будут только в плюсе.
Так вроде уже. Не Си конечно по популярности, но никто и не претендовал. Библиотеки под всё самое используемое есть давно, статьи, на конференциях эмбеддщиков на нём кодят и тд
Применительно Rust к .NET nanoFramework, на Rust для .NET можно писать низкоуровневый неуправляемый код, т.е. нижний слой
Я не знаю, зачем такого монстра создавать. Почему бы просто не писать на Rust под голое железо? Pico же просто Cortex M, Rust в него давно уже умеет
Ну и у Rust есть имхо киллер-фича, которая ставит его на голову выше конкурентов в первую очередь в embedded мире. Паники, они же фатальные ошибки. А точнее то, как они реализованы. Rust в рантайме отслеживает все возможные критические ситуации. Паники срабатывают до критической ошибки, вызывая раскрутку стэка и прочее. Т.е., например, при вылете за границы массива, на Rust мы поймаем панику, но память не будет повреждена, т.к. он её выбросил до того, как ушел реальный вызов. А в embedded Rust мы при этом пишем глобальный обработчик паник (или пользуемся готовым, коих полно) и всё. Или уходим в бесконечный цикл, или логгируем падение, или еще что. Но самое главное, что наша ошибка не повлияла ни на что, кроме хода выполнения программы (включая память). А ведь есть среды, где менеджера памяти, а значит и защит, просто нет. И там только Rust сможет вам дать по рукам и спасти от ее порчи
Да. Причем не только в полноценных функциях, можно даже делать async лямбды
И полноценные потоки тоже никто не отбирает. При этом есть много проверок на отсутствие гонок и прочего, что делает многопоток сильно менее болезненным
Есть ли generic типы?
Тоже да. Причем, в отличие от темплейтов С++, компилятор не верит на слово и требует гарантий наличия нужных методов в дженерик типе.
Отдельно стоит упомянуть тот факт, что Rust построен на платформе LLVM, а значит совместим с С++. Т.е. Rust можно вызывать из C++ и наоборот.
Кроме того, многое, ради чего в других языках нужно искать библиотеки, тут есть из коробки. Например, условное добавление кода на этапе компиляции, генерация тестов по документации, просмотр документации по всем зависимостям проекта локально в браузере с навигацией и поиском, и тд
Многие корпорации (Amazon, Discord, Dropbox, Jetbrains, Microsoft, Mozilla) начали переписывать старые или разрабатывать новые проекты на этом языке, что меня очень радует. Хорошие инструменты должны популяризироваться.
Вообще на всяких конференциях, посвященным микроконтроллерам и разработке под них, Rust уже тоже частый гость. Там на нем пишут под всё на свете, от STM32 до всякой экзотики
Я формально работаю на Java, но фактически использую Java, Typescript, Kotlin. Ранее писал на С++. Сам на Rust наткнулся не так давно и просто влюбился в язык. Уже один пет на нём начал и один планирую. Первый на моей памяти такой, соединил всё лучшее из С++, Java и Python. Удобен, быстр, безопасен, позволяет писать как на высоком, так и на низком уровне. Как прикладные программы, так и системщину. И ни в одном из перечисленных применений нет ощущений, что натягиваешь сову на глобус
Это принципиальная позиция, композиция вместо наследования, т.к. оно нередко приводит к ошибкам. При необходимости это наследование эмулируется с помощью дженериков и трейтов
Про низкоуровневость не согласен. Если не хочется, то и не надо на низкий уровень опускаться. Посмотрите бэкенд на том же Actix и найдите 10 отличий от Express (кроме того, что Actix быстрее примерно в 10 раз). Это универсальный язык
Про порог входа тоже не согласен. Язык гораздо чаще не дает совершать ошибок, куча сахара и тд. Если специально на низкий уровень не опускаться и в unsafe не лазать, то почти всё привычно. Только привыкнуть к системе владения и ссылкам (и то, владение есть в Свифте, а ссылки в неявном виде есть много где, взять ту же Джаву).
Зато в награду паранойидальный, но очень умный и приятный компилятор, гарантирующий отсутствие утечек памяти, рейс кондишенов и тд без продажи души демонам
А в шарпе я навскидку вот вспомню супернеочевидный как для новичка, так и для свитчера кейс, когда перестановка 2 множителей в выражении роняет перфоманс в 20 раз (что вообще противоречит математике и логике)
Иметь возможность комфортно писать на строготипизированном языке для микроконтроллеров - это очень круто.
Предлагаю ознакомиться с Rust. Очень строгая система типов и проверок, работа на куче платформ (от WASM до микроконтроллеров), отсутствие как GC (что позволяет писать среды реального времени), так и необходимости вручную освобождать память (что нередко вызывает ошибки)
И просто огромное количество опционального сахара и zero-cost abstractions, благодаря чему писать приятно, а на выходе получается производительность на уровне С++
Ну я условно сказал, да. Та же Jita перманентно висит на выделенной ноде, например. Плюс у них есть некоторое количество резервных нод, которые они присовывают заранее куда надо, если знают о предстоящем сражении. Там же есть на сайте кнопочка "рассказать разрабам, что мы хотим крупно подраться". Специально, чтобы они заранее подсуетились и туда нод подкинули
А лагает-то из-за чего по-вашему? TD вводится на всей ноде, поэтому зачастую можно влететь в такой кисель за 3-4 системы от самого сражения. Потому что лагает сама нода, и таким образом пытается это компенсировать. И именно поэтому при подключении резервных нод TD отключается или сводится к минимуму. Потому что он рассчитывается от нагрузки сервера, а не клиентов
Ева уже вешается там из-за этого питона. Они сидят на нестандартном несовместимом компиляторе (чтобы избавиться от GIL, который авторы стандартного питона фиксить не собираются видимо), половину бэка утащили на Азуры, мигрировали полностью на gRPC, каждую парочку звездных систем обслуживает отдельный сервер (просто этого глазами не видно), и все равно лагает)
Собственно поэтому им и пришлось много лет назад добавить TiDi, оно же космокисель. Это когда при увеличении нагрузки на сервер (большое сражение) сервер начинает замедлять тики, чтобы успевать все обрабатывать. В итоге абсолютно все процессы в игре происходят дольше (коэффициент замедления), при максимуме "кисельности" битва 6к игроков идет 27 часов)
А съехать с питона они не могут. Другого не умеют, плюс там лютый лапшекод, настаивавшийся с 2003 года. Вот и страдают все. Пять лет уже плотно переписывают все, и лет 15 просто пытаются как-то решить лаги. Но воз и ныне там
Главный вопрос не "как?", а "зачем?". Этот вопрос был бы актуален и до выхода UE5, а после уже просто смешно
Да и качество статьи оставляет желать лучшего. Нет примера проекта, налицо явное незнание Анриала в целом и плюсов в частности, и тд
Мне даже интересно стало. Почему вы в один ряд с сями ставите голенг (!) как пример быстрого масштабируемого языка (!!), но даже не упоминаете Rust, который в 8 раз быстрее голенга, на уровне жавы по сложности и гораздо проще и удобнее сей?
Ну удобство - оно субъективно. Я, например, Go не рассматриваю именно из-за неудобства синтаксиса во многих моментах и безальтернативности правил написания кода в языке. Так еще и позиция его создателей играет роль, которые сознательно ухудшают скорость работы программ ради скорости сборки и не дают это отключить
Лично мне Rust удобнее, поскольку спасает от гораздо большего количества ошибок и многое позволяет, гораздо больше Go. При том же объеме кода микросервисы на Rust (выглядят 1 в 1 как ExpressJs с тайпскриптом) работают в 8 раз быстрее Go, в 10 раз быстрее ExpressJs и в 30 раз быстрее Spring. Сам язык я считаю по уровню сложности наравне с Java/C#, так что проблема лишь в его молодости, из-за которой специалистов мало (но в него вцепились крупные корпорации намертво, так что вопрос времени)
В таком случае, зачем он скачивает Mono и Mac Catalyst для билда проекта? И почему в официальной документации MAUI на сайте Майкрософта куча упоминаний работы через эмулятор и Mono, которую я выше описал? Тут одно из двух: или оно действительно так работает (что как бы мдэ), или документация нагло врет, еще и в куче мест сразу (что еще хуже)
Можно пожалуйста раскрыть тезис про экосистему?
Для мимокрокодила, который далек от DS сферы и работает на Java и Typescript, это выглядит примерно на уровне ассемблера в смысле Quality of Life. Про Rust и заикаться больно, сравнение с его дружелюбными сообщениями об ошибках вообще будет избиением младенца
Я слишком редко вижу питон, чтобы это распознать с первого взгляда)
Ну тогда это просто лень/невнимательность/пофигизм автора
Очень странная подсветка в блоках кода на Rust. Буквально 2-3 слова подсвечивает, остальное серое. Это у меня баг или автор выставил не Rust в качестве языка для них?
Вот целый блог по созданию ОС на Rust: https://os.phil-opp.com/
С прерываниями, планировщиком с поддержкой асинхронности, vga text mode, обработкой ошибок, загрузчиком, пагинацией памяти и тд
Ну я не спорю, что нормальная возможность. Но имхо на том же Rust это будет не сложнее, а профита и возможностей больше (а может просто у меня уже профдеформация из-за того, что пишу на нескольких языках)
К слову, код Rust тоже кроссплатформерный. В смысле один компилятор, есть кросс-компиляция и нет undefined behavior, т.е. можно гарантировать переносимость кода (если он конечно не использует системные апи или конкретное железо, но это и так очевидно)
Ну тогда согласен, что это достойное решение для фанатов C#. По сути из реальных минусов только GC, наличие которого ставит крест на RT-окружении. Ну и работа поверх ОС тоже урезает доступные ресурсы и прочее. На той же STM32 Rust работает bare metal, как и на других embedded платформах (но при желании никто не мешает и поверх ОС запустить, тогда даже std будет)
Но я в целом шарп не люблю, как и Майкрософт, поэтому не для меня)
Так это только два примера статей. Я ж не буду весь хабр перекапывать, плюс есть сторонние источники
Присутствует, и даже несколькими способами. Просмотр стека, кучи, регистров, бэктрейса во время отладки. И тд
https://docs.rust-embedded.org/debugonomicon/
Не нужно путать теплое с мягким. Как я понял, дотнету обязательно нужна операционка для работы. Но если у нас есть операционка, то можно писать и на обычном полноценном Rust. А Embedded нужен для bare metal сред, когда мы пишем напрямую под железо, без какой-либо операционки или среды исполнения, только прошивка и программатор
UPD: погуглил, похоже дотнет тоже может на bare metal работать, но поддерживает меньше платформ, чем Rust (например FPGA от Xilinx). Просто по вашей статье сложилось впечатление, что он без позикса не живет. Ну в таком случае сравнение корректно, но я все равно считаю, что и сам язык удобнее и безопаснее, и отсутствие GC много где критично (= любое реальное время)
Да вроде уже, пусть и корявенькие)
https://habr.com/ru/company/ruvds/blog/645253/
https://habr.com/ru/post/495948/
Торвальдс критикует всё, что не чистый Си. И то, разговоры о добавлении Rust в линь увенчались далеко не громким отказом (в отличие от того же С++)
Так вроде уже. Не Си конечно по популярности, но никто и не претендовал. Библиотеки под всё самое используемое есть давно, статьи, на конференциях эмбеддщиков на нём кодят и тд
Я не знаю, зачем такого монстра создавать. Почему бы просто не писать на Rust под голое железо? Pico же просто Cortex M, Rust в него давно уже умеет
Ну и у Rust есть имхо киллер-фича, которая ставит его на голову выше конкурентов в первую очередь в embedded мире. Паники, они же фатальные ошибки. А точнее то, как они реализованы. Rust в рантайме отслеживает все возможные критические ситуации. Паники срабатывают до критической ошибки, вызывая раскрутку стэка и прочее. Т.е., например, при вылете за границы массива, на Rust мы поймаем панику, но память не будет повреждена, т.к. он её выбросил до того, как ушел реальный вызов. А в embedded Rust мы при этом пишем глобальный обработчик паник (или пользуемся готовым, коих полно) и всё. Или уходим в бесконечный цикл, или логгируем падение, или еще что. Но самое главное, что наша ошибка не повлияла ни на что, кроме хода выполнения программы (включая память). А ведь есть среды, где менеджера памяти, а значит и защит, просто нет. И там только Rust сможет вам дать по рукам и спасти от ее порчи
Вот целый блог по созданию ОС на Rust: https://os.phil-opp.com/
Вот статья про прерывания в части официальной документации языка, посвященной embedded разработке: https://docs.rust-embedded.org/book/start/interrupts.html
Да. Причем не только в полноценных функциях, можно даже делать async лямбды
И полноценные потоки тоже никто не отбирает. При этом есть много проверок на отсутствие гонок и прочего, что делает многопоток сильно менее болезненным
Тоже да. Причем, в отличие от темплейтов С++, компилятор не верит на слово и требует гарантий наличия нужных методов в дженерик типе.
Подробнее можно посмотреть в официальной документации: https://doc.rust-lang.org/book/ch10-01-syntax.html
Отдельно стоит упомянуть тот факт, что Rust построен на платформе LLVM, а значит совместим с С++. Т.е. Rust можно вызывать из C++ и наоборот.
Кроме того, многое, ради чего в других языках нужно искать библиотеки, тут есть из коробки. Например, условное добавление кода на этапе компиляции, генерация тестов по документации, просмотр документации по всем зависимостям проекта локально в браузере с навигацией и поиском, и тд
Многие корпорации (Amazon, Discord, Dropbox, Jetbrains, Microsoft, Mozilla) начали переписывать старые или разрабатывать новые проекты на этом языке, что меня очень радует. Хорошие инструменты должны популяризироваться.
Вообще на всяких конференциях, посвященным микроконтроллерам и разработке под них, Rust уже тоже частый гость. Там на нем пишут под всё на свете, от STM32 до всякой экзотики
Я формально работаю на Java, но фактически использую Java, Typescript, Kotlin. Ранее писал на С++. Сам на Rust наткнулся не так давно и просто влюбился в язык. Уже один пет на нём начал и один планирую. Первый на моей памяти такой, соединил всё лучшее из С++, Java и Python. Удобен, быстр, безопасен, позволяет писать как на высоком, так и на низком уровне. Как прикладные программы, так и системщину. И ни в одном из перечисленных применений нет ощущений, что натягиваешь сову на глобус
Это принципиальная позиция, композиция вместо наследования, т.к. оно нередко приводит к ошибкам. При необходимости это наследование эмулируется с помощью дженериков и трейтов
Про низкоуровневость не согласен. Если не хочется, то и не надо на низкий уровень опускаться. Посмотрите бэкенд на том же Actix и найдите 10 отличий от Express (кроме того, что Actix быстрее примерно в 10 раз). Это универсальный язык
Про порог входа тоже не согласен. Язык гораздо чаще не дает совершать ошибок, куча сахара и тд. Если специально на низкий уровень не опускаться и в unsafe не лазать, то почти всё привычно. Только привыкнуть к системе владения и ссылкам (и то, владение есть в Свифте, а ссылки в неявном виде есть много где, взять ту же Джаву).
Зато в награду паранойидальный, но очень умный и приятный компилятор, гарантирующий отсутствие утечек памяти, рейс кондишенов и тд без продажи души демонам
А в шарпе я навскидку вот вспомню супернеочевидный как для новичка, так и для свитчера кейс, когда перестановка 2 множителей в выражении роняет перфоманс в 20 раз (что вообще противоречит математике и логике)
Предлагаю ознакомиться с Rust. Очень строгая система типов и проверок, работа на куче платформ (от WASM до микроконтроллеров), отсутствие как GC (что позволяет писать среды реального времени), так и необходимости вручную освобождать память (что нередко вызывает ошибки)
И просто огромное количество опционального сахара и zero-cost abstractions, благодаря чему писать приятно, а на выходе получается производительность на уровне С++