Rust не имеет перегрузки функций: вы не можете определить две функции, которые имеют одно и то же имя. Компилятор выдаст сообщение, что у вас имеется двойное задание одного и того же определения, хотя бы они и содержали разные типы аргументов.
После нескольких попыток задача была успешно решена. Как — под катом.
Перформансные задачи от Контура уже были, настала и наша очередь: представляем хардкорные задачи с Java-конференции JBreak 2018, aka «ад от Excelsior».
Задачи даны в оригинальных формулировках, в каждой задаче может быть несколько правильных ответов, и к каждой задаче дано решение под спойлером.
Ваш коллега начитался Java Language Specification и написал следующее:
void playWithRef() {
Object obj = new Object();
WeakReference<Object> ref = new WeakReference<>(obj);
System.out.println(ref.get() != null);
System.gc();
System.out.println(ref.get() != null);
}А разгребать вам: какие результаты исполнения возможны?
Сериализация данных посредством serde. Недавно я писал Rust-код для работы со сторонним источником данных в TOML-формате. В других языках я бы подгрузил данные какой-либо TOML-библиотекой и прогнал бы по ним мою программу, однако я слышал про serde — библиотеку сериализации на Rust, так что я решил попробовать ее.
Подробности — под катом.
void forEach(List<Integer> values, PrintStream ps) {
values.forEach(ps::println);
}
void forEach(List<Integer> values, PrintStream ps) {
values.stream().forEach(ps::println);
}
void forEach(List<Integer> values, PrintStream ps) {
values.parallelStream().forEach(ps::println);
}
Как-то я сказал своему коллеге, что в Rust имеются макросы, ему показалось, что это плохо. Раньше у меня была такая же реакция, но Rust показал мне, что макросы не обязательно плохи.
Где и как их уместно применять? Смотрите под катом.
@media screen. Ибо кодbody{font-size: 1em;}
@media screen and (max-width: 1024px){
body{font-size: 0.8em;}
}Раньше в Rust были состояния типов, которые были удалены из языка еще до официального релиза первой версии. В этой статье я раскрою вам тайну: Rust поддерживает состояния типов.
Прошу под кат.
Давайте познакомимся с Rust, поработав над маленьким проектом! Мы покажем основные концепты Rust на реальном примере. Вы узнаете о let, match, методах, ассоциированных функциях, подключении сторонних библиотек и много о чем другом. Мы реализуем классическую задачу: игра “угадай-ка”.
Есть что-то прекрасное в программировании на ассемблере. Оно может быть очень медленным и полным ошибок, по сравнению с программированием на языке, таким как Go, но иногда — это хорошая идея или, по крайней мере, очень весёлое занятие.
Зачем тратить время на программирование на ассемблере, когда есть отличные языки программирования высокого уровня? Даже с сегодняшними компиляторами все ещё есть несколько случаев, когда захотите написать код на ассемблере. Таковыми являются криптография, оптимизация производительности или доступ к вещам, которые обычно недоступны в языке. Самое интересное, конечно же, оптимизация производительности.
Когда производительность какой-то части вашего кода действительно имеет значение для пользователя, а вы уже попробовали все более простые способы сделать его быстрее, написание кода на ассемблере может стать хорошим местом для оптимизации. Хотя компилятор может быть отлично оптимизирован для создания ассемблерного кода, вы можете знать больше о конкретном случае, чем может предположить компилятор.
Wow. Such Rust. Much macro. © картинка - Твиттер аккаунт Servo
Язык Rust стремительно набирает обороты. Кто-то пророчит ему стать заменой C/C++, кому-то он просто нравится. Я скорее принадлежу ко второй группе. Разработчики стараются сделать его удобным и безопасным. В нем есть конструкции и принципы, которые еще не скоро появятся в "плюсах", ввиду инерции комитета и множества других причин. Поэтому, для всех личных проектов я предпочитаю использовать именно Rust.
Так сложилось, что с переменным успехом я пишу компиляторы. Не успел правда написать ни одного, но мне более интересен сам процесс, чем результат.
Однажды, когда я в очередной раз застрял с синтаксическим анализатором (он же "парсер"), я подумал, что уж очень много я пишу однотипного кода. И этот однотипный код один в один ложится на грамматику в форме Бэкуса — Наура (БНФ).
Немного подумав, я решил, что мне надо написать генератор кода на основе грамматики. И для этой задачи как нельзя хорошо подходят макросы в Rust.
В статье описана реализация LL(*) парсера с использованием макросов. И реализован парсер простых математических выражений.
В итоге парсер для БНФ грамматики:
expr ::= sum
sum ::= mul "+" sum | mul "-" sum | mul
mul ::= atom "*" mul | atom "/" mul | atom
atom ::= "(" expr ")" | number | neg;
neg ::= "-" atomМожно сгенерировать с помощью серии макросов:
rule!(expr, sum);
rule!(sum, or![
and![(mul, token('+'), sum) => make_operator],
and![(mul, token('-'), sum) => make_operator],
mul
]);
rule!(mul, or![
and![(atom, token('*'), mul) => make_operator],
and![(atom, token('/'), mul) => make_operator],
atom
]);
rule!(atom, or![
and![(token('('), expr, token(')')) => |_lbrace, stat, _rbrace| Some(stat)],
num,
neg
]);
rule!(neg, and![(token('-'), atom) => |_, number| Some(Box::new(expression::Expression::Negate(number)))]);В последнее время я долго думал над персистентными коллекциями и в особенности над тем, как они относятся к Rust. Хочу поделиться с вами своими наблюдениями.
О том, как устроены персистентные векторы, быстрее ли они традиционных коллекций — смотрите под катом.
В мире существует множество клёвых маленьких библиотек, которые как бы и не знаменитые, но очень полезные. Идея в том, чтобы потихоньку знакомить Хабр с такими вещами. Сегодня расскажу о JavaParser.
JavaParser — это набор инструментов для парсинга, анализа, трансформации и генерации Java-кода. Иначе говоря, если нужно взять кусок джавакода и как-то его покорёжить подручными методами и без необходимости в особых знаниях, эта либа — самое то.
Где-то посреди статьи вы ВНЕЗАПНО можете осознать, какой кошмар и ужас можно сотворить этой либой, и никак не дождётесь дочитать текст и полить меня гневными комментариями. Не сдерживайтесь, не стоит — сразу скрольте до самого низу и изливайте душу :)
Часто, когда я обсуждаю дизайн Rust на RFCs или на internals-форуме с другими пользователями, я замечаю характерные высказывания насчет явности. Обычно что-то в духе:
Мне не нравится<дизайн возможности X>, потому что он менее явный. Всякая магия уместна в<другом языке Y>, а Rust — это явный язык, так что следует использовать<дизайн возможности Z>.
Подобные комментарии жутко меня раздражают, потому что дают очень мало полезной обратной связи. Они лишь утверждают, что "явное лучше неявного" (при этом предполагается, что это бесспорное утверждение), и что какой-то дизайн менее явный, чем альтернатива (хотя часто даже не приводится объяснений, почему именно критикуемый дизайн менее явный), из чего следует, что их подход предпочтительнее.
В своей опубликованной ранее в этом году заметке Аарон пытался докопаться до сути вопроса явности, обсуждая размер контекста (reasoning footprint). Он попытался разбить понятия "явность" и "неявность" на составные части, чтобы подготовить почву для суждения о явности дизайна той или иной возможности. Я же хочу изложить немного другой взгляд на проблему и попытаюсь очертить в общих словах, что мы подразумеваем под словом "явный".
Английский — довольно нечеткий язык, в котором прилагательные имеют множества контекстно-зависимых значений, например, как используется слово "нечеткий" (fuzzy) в предыдущем предложении. Слово "явный" тоже многозначно, так что я не могу утверждать наверняка, что кто-то неправильно использует это слово. Однако я предлагаю выражать свои мысли при обсуждении "явности" более четко, чтобы все лучше понимали, о чем именно идет речь.
Сообщество Rust в последнее время сконцентрировало много своих усилий на асинхронном вводе/выводе, реализованном в виде библиотеки Tokio. И это замечательно.
Многим из участников сообщества, тем, которые не работали с веб-серверами и связанными с этим вещами, не ясно, чего же мы хотим добиться. Когда эти вещи обсуждались во времена версии 1.0, я тоже имел смутное представление об этом, никогда прежде не работав с этим раньше.
Рассмотрим модели многопоточности на примере Rust и Go.
// func.cpp
void benchmark_func(int* a)
{
for (int i = 0; i < 32; ++i)
a[i] += 1;
}// func.cpp
void foo(int* a)
{
for (int i = 0; i < 32; ++i)
a[i] += 1;
}
void benchmark_func(int* a)
{
for (int i = 0; i < 32; ++i)
a[i] += 1;
}