78.5
Karma
45
Rating
39
Subscribers
Андрей Лесников @ozkriff

Крабообразный / Системный программист

Выпуск Rust 1.32

Выпуск Rust 1.32

+1

Как минимум офигенная штука для отладки кода в плейпене. Я (как и многие растовики) часто там код пишу, а нормального отладчика там все равно нет и вряд ли имеет смысл заморачиваться с втаскиванием.

Выпуск Rust 1.32

+1

Но тогда будет костыль с тем, что в этом специальном случае вызова "dbg!" он внезапно будет возвращать или (), или втихоря паковать перменные в кортеж.
Если возможность прозрачной вставки в середину выражения не нужна, то, кмк, проще ак и раньше "eprintln!" использовать с какой угодно форматной строкой:


eprintln!("a={}, b={}, c={}", a, b, c);

Выпуск Rust 1.32

+3

Как-то слишком категорично, тем более что:
1) такое изменение можно внести потом, потому что оно обратно-совместимо;
2) ценой одной пары скобок это уже можно делать через кортеж:


fn main() {
    let a = 0_u8;
    let b = a + 1;
    let c = "no";
    dbg!((a, b, c));
}

   Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 0.63s
     Running `target/debug/playground`
[src/main.rs:5] (a, b, c) = (
    0,
    1,
    "no"
)

Playground

Выпуск Rust 1.32

+3

Конкретно в этой версии ничего особо связанного (и в ближайших следующих ничего не предвидется), но в новой редакции книги есть глава про этот вопрос: http://rustbook.ru/ch17-00-oop.html


А в целом ответ классический — ооп в мэйнстримовом понимании термина нет, задачи решаются другими приемами.

Пишем операционную систему на Rust. Страничная организация памяти

Rust новости #4 (декабрь 2018)

Rust новости #4 (декабрь 2018)

+1

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

Rust новости #4 (декабрь 2018)

+5

Извиняюсь, что выкладываю аж 10ого числа, из-за праздников съехало расписание.


Поскольку я пишу это уже задним числом, вот важная новость "из будущего": Стив Клабник уходит из Мозиллы.


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

Мысли о современном C++ и игровой разработке

+1

В этом месте обычно принято говорить про ECS (Entity Component System) и кидать ссылку на доклад Катерины, тем более что речь в статье о разработке игр, где этот подход последние годы получает все больше признания.

Мысли о современном C++ и игровой разработке

+2
стандартного графического фреймворка нет

Прям в std чего-то такого никогда не будет, конечно. А если в более широком смысле, то проект https://github.com/gfx-rs/gfx очень сильно на эту роль пытается претендовать, хотя недавний гигантский рефакторинг всего проекта сильно пошатнул его стабильность.


возможностей по-человечески создавать игры тоже

Не уверен что это значит, но есть надежда что амбициозный проект https://github.com/amethyst/amethyst постепенно таки родит неплохой модульный игровой движок. Работы там, правда, тоже море еще.


Еще для 2д игр есть намного менее амбициозный и простой https://github.com/ggez/ggez (вариация на тему love2d), на котором я свою хобби-игру потихоньку ковыряю.

Rust в 2019 году и далее: ограничения на рост

0

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

Rust в 2019 году и далее: ограничения на рост

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

"anymore" зря опустил, кмк. На всякий поясню, что автор оригинальной заметки — Грэйдон Хор (Graydon Hoare) — это изначальный автор Rust'а, который несколько лет назад отошел от активного участия в проекте, а не какой-то прям левый чувак.


Сам пост хороший и правильный и очень сильно пересекается с мнениями некоторых текущих активных участников проекта, например статьей от Лодочника про "организационный долг": https://boats.gitlab.io/blog/post/rust-2019

Изучаю Rust: Как я UDP чат сделал c Azul

Выпуск Rust 1.31 и Rust 2018

0

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

У Интернета могут быть серьёзные проблемы из-за языков, подобных C и C++, которые способствуют появлению уязвимостей

У Интернета могут быть серьёзные проблемы из-за языков, подобных C и C++, которые способствуют появлению уязвимостей

+4
Напишете 100% безопасно с «автоматикой» — будет x1, напишете грамотно с «ручным управлением» — будет x50 скорость.

Есть ссылка откуда такие числа, особенно в контексте Rust'а?

Вышел Rust 2018… но что это такое?

+2

Меня тоже, если честно, немного тревожит этот аспект NLL — что оно более хитрое теперь все. Но 1) не так и просто придумать более-менее реалистичный пример, когда реально из-за этого сильно наступить на грабли 2) очень много людей просто отказывались пользоваться языком с до-NLL проверками, считая язык просто недоработанным (даже на хабре к прошлым статьям десятки таких коментов были).

Вышел Rust 2018… но что это такое?

Выпуск Rust 1.31 и Rust 2018

+7

Всех поздравляю с самым важым после 1.0 выпуском Rust. Уже успел перетащить свою поделку на новую редакцию, это было не больно, так что всем советую. :)


Предвидя два популярных вопроса:


1) rustup немного косячит с компонентами при обноввлении до новой версии. Есл иу вас раньше столи rustfmt-preview и clippy-preview компоненты, то теперь новые clippy и rustfmt компоненты нельзя будет поставить без переустановки тулчейна (URLO тема):


rustup self update
rustup toolchain uninstall stable
rustup toolchain install stable

2) Новый дизайн https://www.rust-lang.org очень спорное явление, сразу могу сказать что вот текущая активная тема для его обсуждения, а старый сайт можно найти тут: https://prev.rust-lang.org

У Интернета могут быть серьёзные проблемы из-за языков, подобных C и C++, которые способствуют появлению уязвимостей

0

Это писал не член команды раста. Мозилла большая, в ней много людей с разными мнениями и умением дипломатично формулировать мысли.

Вышел Rust 2018… но что это такое?

0

На всякий оговорюсь, что не прям сильно в теме и для ржавой встройки я скорее просто сочувствующий, чем реально имеющий опыт.


… всё это оставляет ощущение глубокой альфы, на которую ещё несколько лет можно даже не смотреть.

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


И как, повысили? И про это можно прочитать где-то в объёме большем, нежели «наши доблестные разработчики всё исправили»?

Можно, но за подробностями это с уровня таких больших "корпоративных релизов" надо спускаться на уровень конкретных Embedded WG ежемесячников (например, вот) или даже конкретных задач на гитхабе (например вот или вот).

Вышел Rust 2018… но что это такое?

0
"Для встроенной разработки необходимо было повысить стабильность существующей функциональности."
Обожаю такие фразы. Звучит весомо, не значит ничего.

Почему ничего? Есть всякие нестабильные флаги и возможности компилятора, очень полезные для разработки под встройку, но еще не доступные в стабильном канале. Где-то в Embedded WG ресурсах список был — потихоньку дело толкают к стабилизации всего этого хозяйства.


Для встраиваемой разработки необходимо было сделать так, чтобы без плясок с многочисленными бубнами бинарник занимал какое-то разумное место, сравнимое с написанным на C.

А no_std бинари много места занимают? Вроде не должны бы.

Зависимые типы — будущее языков программирования

0

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

Rust новости #3 (ноябрь 2018)

0

+1, это совсем другой уровень временных затрат.


Но тут даже скорее вопрос в просто другом фокусе. В "альфа версии" этих ежемесячников написано, какую примерно ЦА я себе представляю:


Я тут подумал, что на хабре довольно много сочувствующих ржавчине, но не прям сильно следящих за происходящим в экосистеме (не подписанных на TWIR?).

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


Ну и в целом, даже если и вопрос ЦА вынести за скобки, я сильно не уверен в жизнеспособности такого портала даже для основного раст сообщества, потому что практические потребности всех активных членов карго-культа покрываются или хорошо структурированным TWIR еженедельниками, или всезнающим /r/rust, оба которых уже всем знакомы и привычны.

Rust новости #3 (ноябрь 2018)

0

Шпаргалка и правда больше информации содержит, но не так что бы на порядок же.


просто ничего нет — кучка ключевых слов

Это звучит как Appendix A: Keywords, но есть же еще и Appendix B: Operators and Symbols, в котором как раз весь основной синтаксис разобран.

Rust новости #3 (ноябрь 2018)

10 неочевидных преимуществ использования Rust

0
В официальной группе по расту в телеграмме

Ни телеграмовское, ни rustycrate.ru/gitter сообщества не официальные.

10 неочевидных преимуществ использования Rust

+2

Пример показывает, что тесты писать просто — нашлепнул на функцию #[test] и готово, остальное встроено в стандартный cargo.

10 неочевидных преимуществ использования Rust

+3

Спокойно, просто вместо let a = 5; надо написать let mut a = 5; и она станет изменяемой.


Про идентификаторы — я подозреваю что в серьезных международных проектах просто будет включено предупреждение об использовании не-ascii идентификаторов (#![forbid(non_ascii_idents)]) и все.

10 неочевидных преимуществ использования Rust

10 неочевидных преимуществ использования Rust

+4

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


Обычно говорят что раст императивный, но с вывертом: чистые функциональные языки стараются не допускать общего изменяемого состояния (shared mutable state), запрещая изменения, а Ржавчина запрещает именно одновременность общего и изменяемого состояния. Т.е. в один момент времени состояние может быть или общим (много & указателей на переменную, например), или изменяемым, но с уникальным доступом (&mut указатель требует эксклюзивности доступа). Т.е. цель сходная с чистой функциональщиной, но путь к ней другой из-за необходимости быть более низкоуровневым.


P.S. недавняя статья на тему

10 неочевидных преимуществ использования Rust

10 неочевидных преимуществ использования Rust

+2

Для Си есть, как минимум, два более-менее живых:



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


Можно тут почитать отчет о недавней попытке использовать для портирования библиотеки: https://wiki.alopex.li/PortingCToRust

Губительная ошибка новичков в геймдеве

+2

Комментарии нарративщиков выше прям грусть навевают — вот жеж прям все прям игры делают исходя из сюжета или атмосферы, а игровые механики это, якобы, дело десятое уже :-\ .


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

10 неочевидных преимуществ использования Rust

Новости Rust #2 (октябрь 2018)

+3
мне кажется, что RFC в IETF, IAB и ISOC не пересекаются, и RFC однозначно можно было найти по номеру

Вполне может быть что так, это все ж таки связанные организации и их RFC находятся в одном "пространстве имен". Хотя я не то что бы прям сильно в теме как это все структурно устроено.


до тех пор, пока не появились ржавые RFC, которые уже пересекаются

Я не уверен что Rust это первый проект, который стал свои формализованные предложения обзывать "RFC": быстрый гуглеж показывается как формальные "MS RFC" еще аж в 2006ом году, так и просто неформальное использование аббревиатуры, например, на форумах D в 2011ом. А за последние годы так вообще распространенной практикой стало (хотя это уже, возможно, под влиянием ржавчины): emberjs/rfcs, yarnpkg/rfcs и еще десятки.


В общем, видимо, если контекст неоднозначен и есть шанс запутаться, то лучше сразу писать "<ИмяПректа> RFC <номер>".

Новости Rust #2 (октябрь 2018)

+2

А, извиняюсь, я чего-то подумал что вопрос значил "как в расте отличают RFC от членов команды разработки и RFC от внешних людей из интернета?".


Допустим, когда я вижу что-то типа RFC 5389 Section 15.2, я понимаю, что это ссылка на описание STUN, аттрибут XOR-MAPPED-ADDRESS.

По умолчанию "RFC" значит именно ржавые, а для IETF, IAB, ISOC или еще каких явно указывается префикс организации:


As stated in the User Datagram Protocol's specification in [IETF RFC 768], UDP is an unordered, unreliable protocol;

Новости Rust #2 (октябрь 2018)

+1

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

Изучаю Rust: Как я игру «Змейка» сделал

1 There