• Прогулка по быстрому, безопасному и почти законченному веб-сервису на Rust
    +9
    В контексте оригинальной фразы: «It’s still a conceptually sound concurrent model with real parallelism…», слово sound следует переводить как корректный, надежный. К звуку оно не имеет никакого отношения.
  • «Без Meltdown и Spectre»: Intel перепроектирует свои процессоры
    0
    Я так и не понял, причем тут микрокод, если Meltdown на его уровне исправить невозможно.
  • Новая жизнь для XMPP. Делаем мессенджер, который не получится заблокировать
    +1
    Нет. Можете посмотреть недавнюю активность отдельно взятого разработчика и экстраполировать.

    Если коротко, то это имеет очень мало общего с тем болотом, что там было раньше. Надеюсь, скоро прочитаем подробности из первых рук.
  • Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    +1
    Как по заказу, специально для вас :) Анонс Embedded Devices Working Group.
  • Возможно, вам не нужен Rust, чтобы ускорить ваш JS
    +4
    Вы знаете, забавный момент: в мире Rust как-то не принято выпячивать себя и кричать о производительности или выразительности.

    Обычно стараются подчеркнуть не то, что Rust быстрее, а то, что он не медленнее. Не медленнее C/C++ при большей безопасности памяти и защите от состояния гонок; не медленнее JS, при большей прозрачности кода и т.д.

    Я просто настолько давно варюсь в этой экосистеме, что забыл уже, что бывает иначе. Меня вообще печалит такое однобокое восприятие, когда берут одну фичу языка и начинают меряться.
  • Возможно, вам не нужен Rust, чтобы ускорить ваш JS
    +4
    Еще раз: никто не говорит о превосходстве. Авторы хотели получить удобное и поддерживаемое решение. Они его получили. А то что оно оказалось еще и быстрым — приятный бонус.

    Никто вас не заставляет это использовать только потому, что «это круто и раст всех порвет». Статья вообще не про это.
  • Возможно, вам не нужен Rust, чтобы ускорить ваш JS
    +7
    Я бы процитировал эту часть:

    Most of the improvements that mraleph implemented are desirable regardless of the programming language that is our medium. Excessive allocation rates make any garbage collector (or malloc and free implementation) a bottleneck. Monomorphization and inlining are crucial to eking out performance in both Rust and JavaScript. Algorithm transcend programming languages.

    But a distinction between JavaScript and Rust+WebAssembly emerges when we consider the effort required to attain inlining and monomorphization, or to avoid allocations. Rust lets us explicitly state our desires to the compiler, we can rely on the optimizations occurring, and Rust’s natural idioms guide us towards fast code, so we don’t have to be performance wizards to get fast code. In JavaScript, on the other hand, we must communicate with oblique incantations to match each JavaScript engine’s JIT’s heuristics.

    We chose to rewrite a portion of our library in Rust and WebAssembly not just for the speed ups, although those are certainly nice, but also for maintainability and to get rid of the kludges added to gain JIT optimizations. We wanted to return to clean code and clearly expressed intent. It has been a great success.
  • Возможно, вам не нужен Rust, чтобы ускорить ваш JS
    0
    Ну и да, график тоже говорит сам за себя:

    Сравнение производительности
    image
  • Возможно, вам не нужен Rust, чтобы ускорить ваш JS
    +1
    Я на всякий случай напомню, что авторы библиотеки изначально так и делали. Но в некоторый момент времени они осознали, что код стал чрезвычайно сложно поддерживаемым и негибким. Почему, в общем-то, и было принято решение о выделении части функциональности в натив.

    Очень рекомендую прочитать статью-ответ, ссылку на которую уже дали выше. Там подробно разбираются сделанные изменения при взгляде с обеих сторон и взвешиваются все «за» и «против».
  • Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    +1
    Вот еще, могу посоветовать книгу с введением в микроконтроллеры с точки зрения Rust от все того же Japaric.
  • Система типов в математике
    +6
    Говорить о типах в математике и не упомянуть изоморфизм Карри-Говарда и тем паче гомотопическую теорию типов это как-то… странно.

    Тем более непонятен посыл статьи. Даже у меня, вроде бы знакомого с предметной областью, возникает только один вопрос: «и чо?».
  • Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    0
    Не путайте, пожалуйста, демократию и анархию. Если вам интересно, как все устроено, почитайте про процесс RFC и рабочие группы языка.
  • Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    0
    Но и потенциальных разработчиков на Rust не стоит лишать права голоса.

    Именно поэтому была выдвинута инициатива #Rust2018, в рамках которой сообщество писало посты со своим видением ориентиров развития на ближайший год со своими пожеланиями и обозначением собственных проблем.

    Было написано больше сотни постов, которые потом анализировались и упомянутый выше roadmap как раз был основан на компиляции озвученных идей.

    В противном случае, это как раз было бы решение вида «я так сказал», без учета мнения большинства.
  • Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    +3
    Если вы действительно хотите получить представление о положении дел в embedded, то могу посоветовать вот этот пост.

    Плюс блог небезызвестного japaric, который стоит на острие прогресса в этой области.

    И еще момент: не надо воспринимать авторов языка, как разработчиков проприетарного софта. Да, многие работают в Мозилле и получают за это деньги. Но развитие языка во многом определяется именно сообществом.

    В отличие от питона, перла или других языков где правит «тиран», решения по развитию Rust принимаются сообща и полностью в открытую.

    Таким образом, язык такой, каким его хочет видеть активная часть сообщества. И только.
  • Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    +2
    Вы не правы. Очень даже приоритет.
  • LL(*) парсер с использованием Rust макросов
    0
    Не знаю, надо проверять, но идея интересная. Но мне кажется, что это не соответствует правилам подстановки по образцу.
  • LL(*) парсер с использованием Rust макросов
    0

    К слову, в nightly версии компилятора, помимо существующих + и * добавили квантификатор ? для задания опционального шаблона.


    Теперь, например, можно финальную запятую обрабатывать как $(,)?

  • Rust: «Небезопасные абстракции»
    +6
    Тут сразу стоит сказать что сам по себе `unsafe` не делает ничего особенного и не увеличивает магическим образом производительность на 146% самим фактом своего использования. Он всего лишь позволяет программисту сказать компилятору «я знаю что делаю» и успокоить его анализатор, который в противном случае бы не дал написать потенциально небезопасную конструкцию.

    Поэтому в подавляющем большинстве случаев, прирост производительности происходит за счет опускания неких проверок, обязательных для обеспечения безопасности в общем случае.

    Например, если у вас есть вектор элементов то, как уже было сказано в статье, безопасная реализация обязана проверить, что переданный индекс не выходит за пределы массива. Даже если вы храните этот индекс в объекте и твердо уверены, что он верный, при каждом обращении все равно будет выполняться проверка.

    В этом случае вы можете использовать небезопасный вариант операции «получить значение по индексу», который не выполняет проверку условия. Тогда ответственность будет лежать на вас.

    Обычно такие приемы не делают в пользовательском коде, наоборот, необоснованное трюкачество считается признаком дурного тона. В то же время, в контролируемых условиях, например в стандартной библиотеке, такое может быть полезно, ибо позволяет сделать код более производительным.

    Один из примеров, где такое срезание углов имеет смысл — это реализация итератора по массиву. Доступный размер массива известен заранее, поэтому итератору достаточно хранить у себя текущий индекс. При создании итератора текущий индекс выставляется в 0 и увеличивается на единицу каждый раз, когда пользовательский код зовет `next` и если в массиве есть еще непосещенные элементы. Поскольку этот индекс по определению не может выйти за пределы массива, имеет смысл операцию обращения к элементу делать без проверки индекса (проверка заложена в саму логику итератора), тем самым, повышая производительность, путем убирания лишней проверки, а не всех проверок вообще. Код по-прежнему остается безопасным, просто обеспечение этой безопасности вынесено на другой уровень.

    По этой самой причине Rust рекомендует писать код именно с использованием итераторов и фильтров, так как они оказываются более эффективными, нежели традиционный императивный код с доступом по индексу.

    Конкретные цифры будут слишком малоинформативны, поскольку зависят от сотни факторов, включая конкретное место использования итератора, оценку компилятором весов при инлайнинге, архитектуру процессора и т.д.
  • Rust: «Небезопасные абстракции»
    +4
    Позволю себе добавить, что помимо сегфолтов, Rust позволяет статически (на этапе компиляции) доказать отсутствие в программе гонок по данным так же, как он предотвращает обращение к неинициализированной или уже освобожденной памяти без необходимости GC. Причем без каких-либо накладных расходов, то есть производительность от этого не страдает.
  • Rust vs. C++ на алгоритмических задачах
    +3
    Спасибо на добром слове :)
  • Ой, у меня задержка. Часть 2
    +1
    Да, разумеется.
  • Ой, у меня задержка. Часть 2
    +1
    Короче, PCR вообще нужен только при real-time вещании.
    Поправлю. Он нужен во всех случаях, когда у вас на руках в каждый момент времени есть только фрагмент стрима. Даже в случае HLS/DASH, хотя вроде бы «все должно быть нормально, ибо есть большой запас в несколько сегментов и ~30 секунд». Именно из-за clock drift-а, который упорно не хочет понимать топикстартер, декодоер рано или поздно упрется в одну из границ буфера и привет лаги/дропы. А потом начинают говорить, что стандарт говно. Именно поэтому, стандарт MP2 специфицирует допустимый дрифт PCR не более чем на 500 наносекунд.

    Резюмируя: когда вам весь TS доступен локально на диске, то PCR не нужен. Когда вы получаете его из кабеля (QAM) или скачиваете из сети по частям (стриминг, VOD и особенно realtime) — нужен. Во втором случае надо использовать PCR pacing в демультиплексоре.
  • Ой, у меня задержка. Часть 2
    0
    DASH — типичный пример академического дизайна. Он рассчитан на поток строго из SDI и строго с атомных часов. Т.е. уже банальный стрим с мобильного телефона, пропущенный через RTMP уже не укладывается в прокрустово ложе DASH и MSE.
    Вы сейчас говорите про сам стандарт или про его реализации? То что реализации оставляют желать лучшего, это и так понятно. Особенно опен-сорсные. Именно потому что, как правило, кладут на половину спецификации и «забивают на PCR». В итоге имеем, что имеем.

    Про PCR: многим клиентам вообще наплевать на PCR, они его не читают, потому что в аудио и видео потоках идут DTS. Но конечно для олдовых mpegts-пуристов это ересь требующая очистительного костра

    И это очень печально. Потому что PTS/DTS и PCR это фундаментально разные вещи. То что декодер можно завести только на PTS не означает, что PCR не нужен. Но вы, как специалист, это и так должны понимать.

    А потом возникает ситуация, что «у меня все сутками работало на тестах», а как только код попадает в поле, да еще на миллионы устройств — приехали. Особенно это критично для транскодеров, стоящих, как правило, в аппаратной кабельного оператора и работающих годами.
  • Ой, у меня задержка. Часть 2
    0
    Подробнее, пожалуйста.

    Я то же самое могу сказать и про HLS, особенно, если сценарии использования выходят за пределы «проиграть хоть как-то, в бытовых условиях».

    А если задавать разные неудобные вопросы, вроде синхронизации разных MPEG2-TS стримов через PCR и поведения, не определенного стандартом, то вообще мрак.
  • Ой, у меня задержка. Часть 2
    0
    Спасибо за статью, интересно посмотреть на проблемы коллег с другой стороны. По работе мне приходится сталкиваться с QAM/IP вещанием в сетях кабельного телевидения.

    Скажите, а DASH в вашей сфере насколько хорошо себя чувствует? С учетом того, что в плане полноты стандарта по сравнению с DASH, HLS выглядит как дешевая подтирка, очень странно, что все по-прежнему активно цепляются за HLS.

    И еще момент: существуют ли свои подходы к ABR? Я так понимаю, что для рилтайм стриминга критерии могут существенно отличаться от таковых для обычного вещания и тем более от VOD.
  • Rust vs. C++ на алгоритмических задачах
    +9
    Rust — уникальный проект. И как язык и как экосистема.

    Как язык он уникален тем, что ядро команды составляют великолепные специалисты по теории типов, которые, тем не менее, ориентируются на практичность, а не на академическую чистоту/новизну языка. В итоге получился язык с весьма мощной системой типов, который однако, можно успешно применять в повседневной разработке.

    Философия языка — это сплав современных представлений computer science и хиропрактик системного программирования, повернутых, однако, лицом к программисту-прикладнику.

    Ключевая, на мой взгляд, идея, идущая красной нитью через весь язык, — программист, как и любой другой человек не всесилен и склонен совершать ошибки. Соответственно, язык, который сваливает вину за промахи на программиста — плохой язык.

    Да, тут я говорю и про C++. Программирование на C++ — это сделка с дьяволом. Ты получаешь большие возможности в обмен на свою душу, когда самолет под управлением твоей программы грохнется в океан. C++ пестрит ситуациями, приводящими к неопределенному поведению, о которых программист обязан помнить.

    В технике давно пришли к выводу, что если в системе есть опасные агрегаты, то нужно исключить физическую возможность попадания человека в механизм, а не обучать обслуживающий персонал кунг-фу и умению танцевать с бритвами на скользком полу в трансформаторной будке.

    Rust пытается сделать то же самое на уровне системного программирования. Есть фундаментальная разница между утверждениями «корректность системы проверена тестами» и «корректность системы доказана математически». В первом случае, даже после десяти лет эксплуатации, мы все равно не можем быть уверены, что система надежна.

    Ключ к решению — формализация тех отношений в коде, которые в традиционных языках остаются на совести программиста. Например отношения владения памятью и поддержания ссылочной целостности на уровне указателей. Rust физически не допускает ситуаций, могущих привести к неопределенному поведению, нарушению алиасинга, состоянию гонок или обращению к уже освобожденной или еще не выделенной памяти.

    Все вместе позволяет без опаски реализовывать (а главное рефакторить!), сложные многопоточные программы. Здесь очень кстати будет классический уже пост Fearless Concurrency от одного из авторов языка, плюс великолепная серия статей Lin Clark про внутреннее устройство Firefox Quantum, который стал возможен исключительно благодаря возможностям Rust.

    Как экосистема Rust уникален тем, что ядру команды удалось сформировать удивительное сообщество, готовое к диалогу и дружелюбное к новичкам. Буквально каждый момент взаимодействия с этим сообществом вызывает чувство глубокой благодарности. Тем удивительнее это видеть в среде, близкой к системному программированию.
  • Rust vs. C++ на алгоритмических задачах
    +15
    За статью, безусловно, спасибо. Однако, подача материала, а главное, цель статьи меня смущают.

    Мне кажется, что плюсер, прочитавший статью и не знакомый с Rust, в лучшем случае «пожмет плечами» или пробурчит «как на Фортране можно писать на любом языке программирования».

    Сила Rust не только и не столько в итераторах, ссылках и семантике перемещения, сколько в иной философии и подходу к проектированию программ. Но из статьи этого понять не выйдет.

    У меня по крайней мере, сложилось бы впечатление, вроде: «Мда… ну и зачем весь этот бред? Учитесь писать на плюсах, а не выдумывайте очередного его “убийцу”».
  • Разработчики о самых грязных программных трюках в играх
    0
    А зачем было колхозить таймеры, если они и так поддерживались нативно в редакторе? Хоть на экран выводи.
  • Разработчики о самых грязных программных трюках в играх
    +3
    «Матерый хряк попался! Глаз подбил и кортик отобрал»
  • Опрос пользователей Хабра
    +1
    Было бы еще лучше, если бы в tmfeed/RSS сразу указывался бы автор публикации. Я к примеру, обожаю местные статьи по физике, но только определенных авторов.
  • Что каждый программист на C должен знать об Undefined Behavior. Часть 1/3
    +2
    Спасибо за перевод! Эту серию статей давно надо было перевести.
  • Почему LLVM может вызвать никогда не вызываемую функцию?
    +4
    Я не предлагаю отказываться полностью. Я предлагаю лишь не замалчивать потенциальные проблемы.

    Мир контроллеров это особый мир, со своими правилами и проблемами, и к нему уж точно не стоит апеллировать в статье на общую тему.

    Те, кому надо выжать из камня максимум, рано или поздно сами придут к битовым операциям, но уже с полным осознанием последствий.
  • Почему LLVM может вызвать никогда не вызываемую функцию?
    +6
    Я просто не пойму зачем провоцировать людей на подобное трюкачество? Вот такая функция точно так же будет преобразована в одну инструкцию fneg на тех компиляторах, которые это умеют:

    float negate(float num) {
        return num * -1;
    }

    Только, в отличие от примера в статье, данная функция:
    • Абсолютно понятна читающему
    • Ни при каких условиях не провоцирует неопределенное поведение
    • Не работает с указателями — больше простора для оптимизации
    • На кривых компиляторах все равно отработает как надо
  • Почему LLVM может вызвать никогда не вызываемую функцию?
    +6
    Причем здесь проявляется или не проявляется? Вам ли не понимать, к чему может привести UB в коде. Если флаг -strict-aliasing указан то все, приехали.
  • Почему LLVM может вызвать никогда не вызываемую функцию?
    +4
    Спасибо за статью. Вот только написать
    Пусть мы решили написать функцию, которая меняет знак у float, меняя 31-й бит бинарного представления float
    и не сказать о том, что так лучше не делать — может быть чревато.
  • Весь веб на 60+ FPS: как новый рендерер в Firefox избавился от рывков и подтормаживаний
    0
    Вопрос был про загрузку. Этот тест на загрузку. Тест на плавность анимации приведен в статье.
  • Весь веб на 60+ FPS: как новый рендерер в Firefox избавился от рывков и подтормаживаний
    +1
    Нет. Посмотрите видео. Например, вот это:
  • Весь веб на 60+ FPS: как новый рендерер в Firefox избавился от рывков и подтормаживаний
    0
    Edge так же как и Safari — платформозависимые броузеры, которые договорились с ОС. Хром и Лиса вынуждены играть по общим правилам.
  • 160-терабитный трансатлантический кабель Marea закончен
    +1
    Посмотрите на гугловский Loon. Они летают выше погоды.
  • Как может вызваться никогда не вызываемая функция?
    +2
    Нет, вроде бы там было честное условие.
    Не думаю, что можно сделать так, чтобы обе ветви if'а исполнялись — то что исполнится только одна ветвь определяется строением SSA-дерева.
    Не факт. Думаю, что при выполнении loop peeling-а и loop unrolling-а, могут появляться дублирования выражений, которые дальше могут поехать по-разному из-за UB.