Можно еще вспомнить https://github.com/thepowersgang/mrustc как замену блобу компилятора для раскрутки, правда mrustc в последние версии ржавчины (пока?) не умеет, надо через много промежуточных версий будет пробутстрапиться.
Разработка Quantum CSS началась, чтобы повысить производительность. Улучшение безопасности — просто удачный побочный эффект.
Оно все и затевалось в первую очередь для улучшения производительности. Конкретнее об этом аспекте можно почитать в прошлых статьях цикла, на которые есть ссылки в начале статьи.
Я так понимаю, что в текущем виде это просто технодемка/тест, но общая задумка в создании обычного тайкуна на тему тенниса:
сочетаются Cities Skylines, Zoo Tycoon, Prison Architect и собственно теннис
игра об академии тенниса, куда люди приходят для игры
Обычно, игровой процесс состоит из выбора помещений для аренды, покупки и расстановке/монтаже инвентаря, найма-тренировки сотрудников, регулировании ценовой политики, конкурентной борьбе на рынке и т.п. Сами клиенты всегда автономные NPC, в этом же суть, вручную их перетаскивать вряд ли кто даст.
В принципе, парочку повторений в русском варианте можно бы и убрать без потери смысла, но на весь текст новости "Rust" всего восемь раз используется, я бы не сказал что это как-то очень много.
А работы по проталкиванию раста в пакетные менеджеры популярных осей вполне себе ведутся (под федору с дебианом, как минимум), но возня с заморочками и политиками каждого пакетного менеджера и его экосистемы это на порядок более сложный и долгий процесс, чем сделать самим хорошее частное решение для конкретных проблем.
Как минимум офигенная штука для отладки кода в плейпене. Я (как и многие растовики) часто там код пишу, а нормального отладчика там все равно нет и вряд ли имеет смысл заморачиваться с втаскиванием.
Но тогда будет костыль с тем, что в этом специальном случае вызова "dbg!" он внезапно будет возвращать или (), или втихоря паковать перменные в кортеж.
Если возможность прозрачной вставки в середину выражения не нужна, то, кмк, проще ак и раньше "eprintln!" использовать с какой угодно форматной строкой:
Как-то слишком категорично, тем более что:
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"
)
Конкретно в этой версии ничего особо связанного (и в ближайших следующих ничего не предвидется), но в новой редакции книги есть глава про этот вопрос: http://rustbook.ru/ch17-00-oop.html
А в целом ответ классический — ооп в мэйнстримовом понимании термина нет, задачи решаются другими приемами.
Может и значит, а может и нет, время покажет. Быть в команде ядра, не работая в мозилле, сложнее все-таки. В любом случае его степень влияния на проект сильно упадет.
Грустно, я очень привык за эти годы что он является главным из официальных "лиц раста", но в целом это не критично, потому у раста еще куча толковых людей в "правительстве".
В этом месте обычно принято говорить про ECS (Entity Component System) и кидать ссылку на доклад Катерины, тем более что речь в статье о разработке игр, где этот подход последние годы получает все больше признания.
Прям в std чего-то такого никогда не будет, конечно. А если в более широком смысле, то проект https://github.com/gfx-rs/gfx очень сильно на эту роль пытается претендовать, хотя недавний гигантский рефакторинг всего проекта сильно пошатнул его стабильность.
возможностей по-человечески создавать игры тоже
Не уверен что это значит, но есть надежда что амбициозный проект https://github.com/amethyst/amethyst постепенно таки родит неплохой модульный игровой движок. Работы там, правда, тоже море еще.
Еще для 2д игр есть намного менее амбициозный и простой https://github.com/ggez/ggez (вариация на тему love2d), на котором я свою хобби-игру потихоньку ковыряю.
Выгорел за семь лет, особенно когда проект разросся и понадобилось больше заниматься управленческими задачами + развод и что-то там с операцией было. Вот тут, например, подробнее от него же можно почитать.
Должен отметить, что говорю только за себя, а я даже не очень активный участник проекта.
"anymore" зря опустил, кмк. На всякий поясню, что автор оригинальной заметки — Грэйдон Хор (Graydon Hoare) — это изначальный автор Rust'а, который несколько лет назад отошел от активного участия в проекте, а не какой-то прям левый чувак.
Сам пост хороший и правильный и очень сильно пересекается с мнениями некоторых текущих активных участников проекта, например статьей от Лодочника про "организационный долг": https://boats.gitlab.io/blog/post/rust-2019
Можно еще вспомнить https://github.com/thepowersgang/mrustc как замену блобу компилятора для раскрутки, правда mrustc в последние версии ржавчины (пока?) не умеет, надо через много промежуточных версий будет пробутстрапиться.
Оно все и затевалось в первую очередь для улучшения производительности. Конкретнее об этом аспекте можно почитать в прошлых статьях цикла, на которые есть ссылки в начале статьи.
Я так понимаю, что в текущем виде это просто технодемка/тест, но общая задумка в создании обычного тайкуна на тему тенниса:
Обычно, игровой процесс состоит из выбора помещений для аренды, покупки и расстановке/монтаже инвентаря, найма-тренировки сотрудников, регулировании ценовой политики, конкурентной борьбе на рынке и т.п. Сами клиенты всегда автономные NPC, в этом же суть, вручную их перетаскивать вряд ли кто даст.
Конкретно этого проекта на гитхабе автора в публичных Rust репах не видно.
В принципе, парочку повторений в русском варианте можно бы и убрать без потери смысла, но на весь текст новости "Rust" всего восемь раз используется, я бы не сказал что это как-то очень много.
А работы по проталкиванию раста в пакетные менеджеры популярных осей вполне себе ведутся (под федору с дебианом, как минимум), но возня с заморочками и политиками каждого пакетного менеджера и его экосистемы это на порядок более сложный и долгий процесс, чем сделать самим хорошее частное решение для конкретных проблем.
Хм, а почему не про Cargo вопрос? Системные пакетные менеджеры библиотеки ставить умеют же.
RFC приняли, теперь вот тут — https://github.com/rust-lang/rust/issues/55467 — можно подписаться следить за статусом реализации.
Как минимум офигенная штука для отладки кода в плейпене. Я (как и многие растовики) часто там код пишу, а нормального отладчика там все равно нет и вряд ли имеет смысл заморачиваться с втаскиванием.
Но тогда будет костыль с тем, что в этом специальном случае вызова "dbg!" он внезапно будет возвращать или
(), или втихоря паковать перменные в кортеж.Если возможность прозрачной вставки в середину выражения не нужна, то, кмк, проще ак и раньше "eprintln!" использовать с какой угодно форматной строкой:
eprintln!("a={}, b={}, c={}", a, b, c);Как-то слишком категорично, тем более что:
1) такое изменение можно внести потом, потому что оно обратно-совместимо;
2) ценой одной пары скобок это уже можно делать через кортеж:
Playground
Конкретно в этой версии ничего особо связанного (и в ближайших следующих ничего не предвидется), но в новой редакции книги есть глава про этот вопрос: http://rustbook.ru/ch17-00-oop.html
А в целом ответ классический — ооп в мэйнстримовом понимании термина нет, задачи решаются другими приемами.
https://habr.com/ru/users/lain8dono/posts/
Да, именно так и думаю. Но мне все равно грустно. :)
Может и значит, а может и нет, время покажет. Быть в команде ядра, не работая в мозилле, сложнее все-таки. В любом случае его степень влияния на проект сильно упадет.
Извиняюсь, что выкладываю аж 10ого числа, из-за праздников съехало расписание.
Поскольку я пишу это уже задним числом, вот важная новость "из будущего": Стив Клабник уходит из Мозиллы.
Грустно, я очень привык за эти годы что он является главным из официальных "лиц раста", но в целом это не критично, потому у раста еще куча толковых людей в "правительстве".
В этом месте обычно принято говорить про ECS (Entity Component System) и кидать ссылку на доклад Катерины, тем более что речь в статье о разработке игр, где этот подход последние годы получает все больше признания.
Прям в std чего-то такого никогда не будет, конечно. А если в более широком смысле, то проект https://github.com/gfx-rs/gfx очень сильно на эту роль пытается претендовать, хотя недавний гигантский рефакторинг всего проекта сильно пошатнул его стабильность.
Не уверен что это значит, но есть надежда что амбициозный проект https://github.com/amethyst/amethyst постепенно таки родит неплохой модульный игровой движок. Работы там, правда, тоже море еще.
Еще для 2д игр есть намного менее амбициозный и простой https://github.com/ggez/ggez (вариация на тему love2d), на котором я свою хобби-игру потихоньку ковыряю.
Выгорел за семь лет, особенно когда проект разросся и понадобилось больше заниматься управленческими задачами + развод и что-то там с операцией было. Вот тут, например, подробнее от него же можно почитать.
"anymore" зря опустил, кмк. На всякий поясню, что автор оригинальной заметки — Грэйдон Хор (Graydon Hoare) — это изначальный автор Rust'а, который несколько лет назад отошел от активного участия в проекте, а не какой-то прям левый чувак.
Сам пост хороший и правильный и очень сильно пересекается с мнениями некоторых текущих активных участников проекта, например статьей от Лодочника про "организационный долг": https://boats.gitlab.io/blog/post/rust-2019