Несмотря на мой статус и очевидную предвзятость как одного из создателей D, я постараюсь отвечать откровенно; Я следовал путям Go и Rust, и я абсолютно точно знаю, где стирают грязное белье в D. Я поощряю людей на аналогичных позициях в сообществах Rust и Go чтобы и они делились своим мнением. Так вот.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Pointers Are Complicated, or: What's in a Byte?" авторства Ralf Jung.

Этим летом я снова работаю над Rust фуллтайм, и я снова буду работать (помимо прочих вещей) над "моделью памяти" для Rust/MIR. Однако, прежде чем я заговорю о своих идеях, я наконец должен развеять миф, что "указатели просты: они являются просто числами". Обе части этого утверждения ошибочны, по крайней мере в языках с небезопасными фичами, таких как Rust или C: указатели нельзя назвать ни простыми, ни (обычными) числами.

Я бы также хотел обсудить часть модели памяти, которую необходимо затронуть, прежде чем мы можем говорить о более сложных частях: в какой форме данные хранятся в памяти? Память состоит из байтов, минимальных адресуемых единиц и наименьших элементов, к которым можно получить доступ (по крайней мере на большинстве платформ), но каковы возможные значения байта? Опять же, оказывается, что "это просто 8-битное число" не подходит в качестве ответа.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Perils of Constructors" автора Aleksey Kladov.

Один из моих любимых постов из блогов о Rust — Things Rust Shipped Without авторства Graydon Hoare. Для меня отсутствие в языке любой фичи, способной выстрелить в ногу, обычно важнее выразительности. В этом слегка философском эссе я хочу поговорить о моей особенно любимой фиче, отсутствующей в Rust — о конструкторах.

Что такое конструктор?

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

1. Вы устанавливаете инварианты в конструкторе.
2. Каждый метод заботится о сохранении инвариантов.
3. Вместе эти два свойства значат, что можно думать об объектах как об инвариантах, а не как о конкретных внутренних состояниях.

Конструктор здесь играет роль индукционной базы, будучи единственным способом создать новый объект.

К сожалению, в этих рассуждениях есть дыра: сам конструктор наблюдает объект в незаконченном состоянии, что и создает множество проблем.

Привет, Хабр! Представляю вашему вниманию перевод статьи "What Is Rust's unsafe?" автора Nora Codes.

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

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

В последнем семестре университета я выбрал курс компиляторов CS444. Там каждая группа из 1-3 человек должна была написать компилятор из существенного подмножества Java в x86. Язык на выбор группы. Это была редкая возможность сравнить реализации больших программ одинаковой функциональности, написанных очень компетентными программистами на разных языках, и сравнить разницу в дизайне и выборе языка. Такое сравнение породило массу интересных мыслей. Редко можно встретить такое контролируемое сравнение языков. Оно не идеально, но намного лучше, чем большинство субъективных историй, на которых основано мнение людей о языках программирования.

Мы сделали наш компилятор на Rust, и сначала я сравнил его с проектом команды на Haskell. Я ожидал, что их программа будет намного короче, но она оказалась того же размера или больше. То же самое для OCaml. Затем сравнил с компилятором на C++, и там вполне ожидаемо компилятор был примерно на 30% больше, в основном, из-за заголовков, отсутствия типов sum и сопоставлений с образцом. Следующее сравнение было с моей подругой, которая сделала компилятор самостоятельно на Python и использовала менее половины кода, по сравнению с нами, из-за мощности метапрограммирования и динамических типов. У другого товарища программа на Scala тоже была меньше нашей. Больше всего меня удивило сравнение с другой командой, которая тоже использовала Rust, но у них оказалось в три раза больше кода из-за разных дизайнерских решений. В конце концов, самая большая разница в количестве кода оказалась в пределах одного языка!

Привет, Хабр!

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

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

В этой заметке мы запилим Rust-прототип недавнего предложения от соавтора Lightning Network Paper, Thaddeus Dryja — Utreexo: a dynamic hash-based accumulator optimized for the Bitcoin UTXO set, позволяющего уменьшить требования к дисковому пространству для узлов-валидаторов.

Всем привет! Недавно открыл для себя язык Rust. О своих первых впечатлениях поделился в предыдущей статье. Теперь решил копнуть немного глубже, для этого необходимо что-то посерьёзнее списка. Выбор мой пал на дерево Меркла. В этой статье я хочу:

• рассказать про эту структуру данных
• посмотреть на то, что уже есть в Rust
• предложить свою реализацию
• сравнить производительность

Как сделать решатель (солвер) нонограмм на Python, переписать его на Rust, чтобы запускать прямо в браузере через WebAssembly.

TL;DR

В этой короткой статье я расскажу о паттерне в Rust, который позволяет "сохранять" для последующего использования тип, переданный через обобщенный метод. Этот паттерн встречается в исходниках Rust-библиотек и я тоже иногда его использую в своих проектах. Мне не удалось найти в сети публикаций о нем, поэтому я дал ему свое название: "Замыкание обобщенного типа", и в этой статье хочу рассказать, что он из себя представляет, зачем и как его можно использовать.

Хочу рассказать о статье "I/O Is Faster Than the CPU – Let’s Partition Resources
and Eliminate (Most) OS Abstractions", опубликованной на личной странице одного из разработчиков ScyllaDB, Pekka Enberg. О ней узнал из видео.

С докладом по этой статье авторы должны были выступать на HOTOS17 (Hot Topics in Operating Systems) воркшопе 12 -15 мая 2019. Насколько понял там обсуждают наработки на ранних этапах их жизни.

Моя статья носит новостной характер с целью возбудить пытливые умы на обдумывание этой темы и размышления в комментариях.

Привет, Хабр! В общем как я обещал вот рассказ о том как CLion в качестве IDE для Rust на MacOS использовать. Почему не IntelliJ IDEA? Потому что CLion может дебажить. Почему LLDB, а не GDB? Потому что LLDB у меня вместе с XCode был установлен. Мне нравится эта IDE, и поэтому я решил рассказать про нее вам. Если вам стало интересно, то добро пожаловать под кат.

В этой статье описывается библиотека optlib, предназначенная для решения задач глобальной оптимизации на языке Rust. На момент написания этой статьи в этой библиотеке реализован генетический алгоритм нахождения глобального минимума функции. Библиотека optlib не привязана к конкретному типу входных данных для оптимизируемой функции. Также библиотека построена таким образом, что при использовании генетического алгоритма можно легко менять алгоритмы скрещивания, мутации, отбора и другие этапы работы генетического алгоритма. По сути генетический алгоритм собирается как бы из кубиков.

Привет, Хабр! Представляю вашему вниманию перевод статьи "The Rust Release Team "Announcing Rust 1.34.0".

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust, 1.34.0. Rust — это язык программирования, который даёт возможность каждому создавать надёжное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.34.0 вам достаточно выполнить:

$ rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта.

Что вошло в стабильную версию 1.34.0

Основное улучшение этого выпуска это поддержка альтернативных cargo-реестров. Релиз также включает поддержку ? в документационных тестах, некоторые улучшения в #[attribute(...)] и стабилизацию TryFrom. Читайте далее о ключевых вещах или можете посмотреть подробные примечания к выпуску для дополнительной информации.

Всем привет!

В данном руководстве хочу рассказать как подружить CUDA C/С++ и Rust. И в качестве примера напишем небольшую программу на Rust для вычисления скалярного произведения векторов, вычисление скалярного произведения будет производиться на GPU с использованием CUDA C.

Кому интересно под кат!

Многие компании ненавидят движение OpenSource особенно утилиты GNU и ядро Linux. Коммерческие компании выкупают OpenSource сервисы и компании. В 2018 году был получен контроль над OpenSource-компаниями GitHub, RedHat.

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

Первая часть
Вторая часть

Тема сегодняшнего разговора — работа с памятью. Я расскажу про инициализацию директории страниц, маппинг физической памяти, управление виртуальной и мою организацию кучи для аллокатора.

Как я уже говорил в первой статье, я решил использовать страницы размером 4 МБ, чтобы упростить себе жизнь и не иметь дела с иерархическими таблицами. В дальнейшем я надеюсь перейти на страницы размером 4 КБ, как большинство современных систем. Я мог бы использовать готовый (например, такой блочный аллокатор), но написать свой было чуть интереснее и хотелось чуть больше понять, как живет память, так что мне есть, что вам рассказать.

В прошлых статьях цикла мы обсудили безопасность памяти и безопасность потоков в Rust. В этой последней статье посмотрим на последствия реального применения Rust на примере проекта Quantum CSS.

Движок CSS применяет правила CSS на странице. Это нисходящий процесс, который спускается по дереву DOM, после расчёта родительского CSS дочерние стили можно вычислять независимо: идеальный вариант для параллельных вычислений. К 2017 году Mozilla предприняла две попытки распараллелить систему стилей с помощью C++. Обе провалились.

Разработка Quantum CSS началась, чтобы повысить производительность. Улучшение безопасности — просто удачный побочный эффект.

Первая часть

Первая статья еще не успела остыть, а я решил не держать вас в интриге и написать продолжение.

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

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

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

Этот цикл статей опубликован выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий тикет. Все исходники для статьи лежат в этой ветке.

Ещё одна статья о страничной организации памяти?
Если вы следите за этим циклом, то видели статью «Страничная память: продвинутый уровень» в конце января. Но меня раскритиковали за рекурсивные таблицы страниц. Поэтому решил переписать статью, применив иной подход для доступа к фреймам.

Я решил написать статью, а если получится — то и серию статей, чтобы поделиться своим опытом самостоятельного исследования как устройства Bare Bone x86, так и организации операционных систем. На данный момент мою поделку нельзя назвать даже операционной системой — это небольшое ядро, которое умеет загружаться из Multiboot (GRUB), управлять памятью реальной и виртуальной, а также выполнять несколько бесполезных функций в режиме многозадачности на одном процессоре.

При разработке я не ставил себе целей написать новый Linux (хотя, признаюсь, лет 5 назад мечтал об этом) или впечатлить кого-либо, поэтому особо впечатлительных прошу дальше не смотреть. Что мне на самом деле захотелось сделать — разобраться, как устроена архитектура i386 на самом базовом уровне, и как именно операционные системы делают свою магию, ну и покопать хайповый Rust.

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

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