man!(D => Rust).basics

Пойдет?

struct Man {
    basics: &'static str,
}

macro_rules! man {
    ( $x:expr => $y:expr ) => {
        Man{basics: "https://habrahabr.ru/post/280642"}
    }
}

fn main() {
    println!("{}", man!(D => Rust).basics);
}

https://play.rust-lang.org/?gist=1df33e28a746408d0905c9c71a74a5fe

Кортежи в языках программирования. Часть 2

В… Rust предусмотрена специальная метапеременная "_" ...

Я бы не назвал это метапеременной, это просто часть синтаксиса сопоставления с образцом.
_ (как и .., ref, mut и т.д.) работает только в контексте образца, иначе:

fn main() {
    fn f_ab() -> (u8, u8) { (1, 2) }
    let mut a;
    (a, _) = f_ab();
    println!("{}", a);
}

руганется:

<anon>:6:9: 6:10 error: unexpected token: `_`
<anon>:6     (a, _) = f_ab();
                 ^

Советы по написанию библиотек на Rust

единственный заслуживающий внимания «пакетный менеджер» для плюсов — это Find-модули CMake

Склонен согласиться, к сожалению

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

Смотря какие требования. Возможности далеко не всех системных ПМ удобны для разработки, они все-таки на администраторов/пользователей заточены.

лично мне непонятно, какие именно задачи должен решать системный ПМ, а какие — ПМ для языка и его экосистемы

Я для себя разделение довольно четко вижу: системный ПМ — установка уже готовых программ (ИМХО, в системном ПМ вообще не должно быть команды "поставить библиотеку", только "поставить программу"), языкоспецифичный ПМ — установка всяких зависимостей для разработки чего-то там.

Советы по написанию библиотек на Rust

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

Повесть о создании классической RTS в домашних условиях с нуля + разбор основных этапов разработки (AI, сеть и т.д.)

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

Но я про сеть чего-то не вижу ничего. А там, мне кажется, куча интересных подробностей должна же быть, очень хочется почитать :) .

Советы по написанию библиотек на Rust

Да их для плюсов, как и систем сборки (хотя тут, вроде, cmake доминирует), много. В этом и проблема :(

Советы по написанию библиотек на Rust

Я бы сказал что в целом да, хотя надо немного больше усилий потратить.
Инструменты типа Homu, Clog и подобное вообще от языка не зависят. Readme.md и лицензия тоже. Travis почти так же прикручивается.
Статических анализаторов для плюсов много (сравнение эффективности этих анализаторов с встроенными и внешними проверками ржавчины, это немного другой вопрос).
Автогенерация и автозагрузка куда-то там документации, при желании, тоже делается в том же трэвисе.
Для автоформатирования есть clang-format и еще много всякого.
Тесты, хоть и не вшиты в язык, тоже никто не запрещает делать. Какие-то инструменты для сбора информации о тестовом покрытии тоже есть.
Так что из существенного остается, как мне кажется, только Cargo и его метаданные — у плюсов нет стандартного менеджера пакетов и центрального хранилища.

Rust и Swift (вступление, первая и вторая части)

> К сожалению, альтернативные варианты предполагают наличие типов высшего порядка (HKT), которых в Rust пока нет.

Да и авторы языка вообще не хотят завязываться сильно на монады и do-нотацию, это, по их мнению, слишком сильно сдвинет язык в сторону функциональщины — всякие там императивные break/continue плохо с этим сочетаются.

C++17, который мы потеряли

Т.е. вопрос в библиотеках, а не самом языке.

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

C++17, который мы потеряли

uninstall уже есть. Реп пока нет, но чего-то с зеркалами crates.io потихоньку делают — думаю, в репы в итоге выльется.

Лично мне бинарных зависимостей недостает :(.

> можно сделать его и не языкоспецифичным.

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

C++17, который мы потеряли

> Rust — это, скорее, замена С, а не С++

А можно раскрыть мысль? Несколько раз там и сям видел это мнение и не очень его понимаю. Может я слово «замена» в таком контексте как-то не так понимаю, может дело в предметной области, где человек работает, хз.

Работа с С-объединениями (union) в Rust FFI

Если что, вот нагуглилось RFC об `unsafe enum` — https://github.com/retep998/rfcs/blob/master/text/0000-unsafe-enums.md. Его даже обсуждали активно, так что, наверное, когда-нибудь сделают какое-то человеколюбивое решение.

Один разработчик чуть не «сломал» пакетный менеджер NPM

«Юристы», как мне кажется, Апач предпочитают.

C++17, который мы потеряли

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

Один разработчик чуть не «сломал» пакетный менеджер NPM

Теперь я точно не сомневаюсь, что невозможность удалить однажды опубликованный пакет в rust`овском crates.io это отличная идея — http://doc.crates.io/crates-io.html#cargo-yank.

Один разработчик чуть не «сломал» пакетный менеджер NPM

https://github.com/starters/kik/blob/4dbb5c/package.json#L23

Модули расширения Python на Rust

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

Модули расширения Python на Rust

В ffi, наверное, лучше `*const i8`/`isize`/`usize` заменить на сишные аналоги из https://doc.rust-lang.org/std/os/raw/index.html. А то мало ли что там на других платформах будет.

Модули расширения Python на Rust

> `let a = a_obj.extract::(py).unwrap();`

Мне кажется, обычно этим стремным синтаксисом стараются не пользоваться и пишут

`let a: i32 = a_obj.extract(py).unwrap();`

С виду, так тип выражения должен нормально вывестись тоже.

Что читать о перспективных языках программирования

> и потенциальное место для ошибок

Кстати, хотя целые числа в 5.3 добавили, приведение одного к другому неявное, так что от ошибок это, вроде как, должно спасать ровно на столько же, насколько и просто использование целого подмножества float`ов.