LINUX.ORG.RU

Rust 1.31.0 (2018)

 ,


5

10

Команда Rust объявила о выходе новой стабильной версии Rust 1.31.0, который ознаменует собой также выход новой редакции «Rust 2018». Rust — это язык программирования, который позволяет каждому создавать надежное и эффективное программное обеспечение.

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

rustup update stable

Если у вас ещё не установлен Rust, то это можно сделать, загрузив с сайта утилиту rustup.

Что нового в Rust 1.31.0

Rust 2018

Данный релиз ознаменует собой выпуск редакции Rust 2018. Впервые Rust 2018 был упомянут в марте, затем в июле: прочтите их, чтобы понимать для чего нужен Rust 2018. Также, есть статья на сайте Mozilla Hacks.

Вкратце, Rust 2018 это возможность представить всю работу за последние три года в виде цельного пакета. Кроме возможностей языка, сюда входят:

  • Инструментарий (поддержка IDE, rustfmt, Clippy)
  • Документация
  • Работа различных рабочих групп
  • Новый веб-сайт

Для обозначения редакций Rust был представлен ключ edition в Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
authors = ["Your Name <you@example.com>"]
edition = "2018"

[dependencies]

Значение 2018 означает, что используется редакция Rust 2018; отсутствие ключа или значение 2015 означает использование редакции Rust 2015.

Важно отметить, что каждый пакет может быть в редакциях 2015 или 2018, и они без проблем могут работать вместе. Проект под редакцией 2018 может использовать зависимости 2015, а проект 2015 использовать зависимости 2018. Это гарантирует целостность экосистемы, сохраняя совместимость существующего кода. Кроме того, существует возможность автоматической миграции кода с редакции Rust 2015 на Rust 2018 при помощи cargo fix.

Non-lexical lifetimes (NLL; Нелексические времена жизни)

В 2018 появились нелексические времена жизни, что на простом языке означает, что проверщик заимствований (borrow checker) стал умнее и теперь не отклоняет правильный код. Например:

fn main() {
    let mut x = 5;

    let y = &x;

    let z = &mut x;
}

В старых версиях этот код выдаст ошибку компиляции:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
6 | }
  | - immutable borrow ends here

из-за того, что время жизни действует внутри лексического блока; то есть, заимствование будет удерживаться за y, пока y не покинет пределы main, несмотря на то, что y больше не используется. Сегодня этот код скомпилируется правильно.

Другой пример:

fn main() {
    let mut x = 5;
    let y = &x;
    let z = &mut x;
    
    println!("y: {}", y);
}

Старый Rust выдаст следующую ошибку:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
...
8 | }
  | - immutable borrow ends here

В Rust 2018 вывод ошибки стал лучше:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:13
  |
4 |     let y = &x;
  |             -- immutable borrow occurs here
5 |     let z = &mut x;
  |             ^^^^^^ mutable borrow occurs here
6 |     
7 |     println!("y: {}", y);
  |                       - borrow later used here

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

Пока эти возможности доступны в Rust 2018, но в будущем планируется портировать их на Rust 2015.

Изменения в системе модулей

Редакция Rust 2018 привносит некоторые изменения в работу с путями, что в конечном итоге привело к упрощению системы модулей.

Вкратце:

  • extern crate больше не требуется практически во всех случаях.
  • Макросы теперь можно импортировать при помощи use вместо атрибута #[macro_use].
  • Абсолютные пути начинаются с названия пакета, где ключевое слово crate ссылается на текущий пакет.
  • foo.rs и поддиректория foo/ могут сосуществовать вместе; mod.rs больше не нужен при размещении подмодулей в поддиректории.

Полную информацию можно прочесть в руководстве.

Упрощенные правила синтаксиса времени жизни

В обеих редакциях представлены новые правила синтаксиса времени жизни для блоков impl и определениях функций. Следующий код:

impl<'a> Reader for BufReader<'a> {
    // methods go here
}
теперь может быть написан таким образом:
impl Reader for BufReader<'_> {
    // methods go here
}

'_ подсказывает, что BufReader берёт параметр, но больше нет необходимости именовать его.

В структурах времена жизни всё ещё должны быть определены, но теперь без лишнего кода:

// Rust 2015
struct Ref<'a, T: 'a> {
    field: &'a T
}

// Rust 2018
struct Ref<'a, T> {
    field: &'a T
}
: 'a добавляется автоматически. При желании, можно продолжать использовать явное определение.

const fn

Существует несколько способов определения функций в Rust: регулярная функция с fn, небезопасная функция с unsafe fn, внешняя функция с extern fn. В этом релизе появился ещё один способ: const fn, который выглядит следующим образом:

const fn foo(x: i32) -> i32 {
    x + 1
}
Функции const fn могут вызываться как регулярные функции, но вычисляются во время компиляции, а не во время выполнения. Для стабильной работы, они должны иметь детерминированный результат и в настоящее время ограничены следующим минимальным набором операций:

  • Арифметические операторы и операторы сравнения с целыми числами
  • Все логические операторы, кроме && и ||
  • Построение массивов, структур, перечислений и кортежей
  • Вызов других функций const fn
  • Задание индекса массивам и срезам
  • Доступ к полям структур и кортежей
  • Чтение из констант
  • & и * на ссылках
  • Приведение типов, за исключением необработанных указателей на целые числа

В будущем данный набор будет расширяться, подробную информацию можно посмотреть здесь.

Новые инструменты

Наряду с Cargo, Rustdoc, и Rustup, которые являются ключевыми инструментами с версии 1.0, редакция 2018 представляет новое поколение инструментов: Clippy, Rustfmt, и поддержку IDE.

Clippy является статическим анализатором кода в Rust, достиг версии 1.0 и теперь доступен в стабильной версии Rust. Установку можно произвести следующим образом: rustup component add clippy, запуск: cargo clippy.

Rustfmt является инструментом для автоматического форматирования кода Rust в соответствии с официальной стилистикой Rust. В этом релизе он достиг версии 1.0 и, начиная с этой версии, гарантируется обратная совместимость для Rustfmt: отформатированный сегодня код останется неизменным в будущем (только с опциями использованными по-умолчанию), и несёт практическую ценность при использовании с системами непрерывной интеграции (CI; cargo fmt --check). Установить Rustfmt можно следующим образом: rustup component add rustfmt, использовать: cargo fmt.

Поддержка IDE - одна из наиболее востребованных возможностей в Rust. Работы над поддержкой IDE ещё не закончены, но на данный момент уже существуют несколько высококачественных опций:

Tool lints

В Rust 1.30 были стабилизированы атрибуты инструментов, такие как #[rustfmt::skip]. В Rust 1.31 стабилизированы «анализаторы инструментов» («tool lints») наподобие #[allow(clippy::bool_comparison)], у них появилось своё пространство имён и теперь ясно к какому инструменту они относятся. Старые проверки Clippy теперь можно писать следующим образом, вам больше не нужен атрибут cfg_attr:

// old
#![cfg_attr(clippy, bool_comparison)]

// new
#![allow(clippy::bool_comparison)]

Документация

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

Рабочие группы

В этом году было объявлено о создании четырёх рабочих групп в следующих областях:

  • Сетевые сервисы
  • Приложения командной строки
  • WebAssembly
  • Встраиваемые устройства

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

  • Группа сетевых сервисов работает над интерфейсом Futures и async/await, который уже будет доступен в скором времени.
  • Группа командной строки работает над библиотеками и документацией для создания ещё лучших приложений для командной строки.
  • Группа WebAssembly выпустила огромное количество инструментария для использования Rust с wasm.
  • Группа встраиваемых устройств добилась поддержки разработки ARM на стабильной версии Rust.

Новый сайт

Основной сайт получил новый дизайн.

Стабилизация библиотек

Добавлено множество реализаций From:

  • u8 теперь реализует From<NonZeroU8>, то же самое для других числовых типов и их NonZero-эквивалентов
  • Option<&T> реализует From<&Option<T>>, аналогично для &mut

Были стабилизированы следующие функции:

  • slice::align_to и её изменяемый аналог
  • slice::chunks_exact и её изменяемый и r аналоги (такие как slice::rchunks_exact_mut) во всех комбинациях

Подробный список изменений можно посмотреть здесь.

Cargo

Cargo теперь загружает пакеты параллельно, используя HTTP/2. В связи с тем, что extern crate практически больше не требуется, было бы неудобно использовать пакет через extern crate foo as bar; Это можно сделать в Cargo.toml следующим образом:

[dependencies]
baz = { version = "0.1", package = "foo" }

или

[dependencies.baz]
version = "0.1"
package = "foo"

В примере выше, пакет foo теперь может быть использован через baz.

Подробный список изменений можно посмотреть здесь.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от WatchCat

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

h4tr3d ★★★★★ ()
Ответ на: комментарий от eao197

А настоящие программисты в этом не нуждаются, ага.

Нормальные программисты в состоянии это сами сделать.

Могут, конечно. Но не всегда. И им тоже приходится смотреть на выдачу valgrind.

Но это принципиально отличается от программистов, которые в принципе сами себе сопли утереть не могут.

Принципиально - не отличаются. Потому что «настоящие программисты» тоже делают use-after-free errors. Разница только количественная.

Ты хочешь с ними работать над общим кодом? Пусть даже в Rust-е?

Вряд ли, но я вообще мало с кем хочу работать над общим кодом. При работе над общим кодом на Rust я хотя бы буду меньше зависеть от их ошибок.

tailgunner ★★★★★ ()
Ответ на: комментарий от eao197

5-звезданутый ответ, который очень в тему. Товарищ еао, в последнее время ты сильно сдаешь свои позиции, особенно когда признался, что не рабираешься в теории акторов и ксп. Успехов тебе.

anonymous ()
Ответ на: комментарий от tailgunner

Могут, конечно. Но не всегда. И им тоже приходится смотреть на выдачу valgrind.

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

И да, на всякий случай, раз уж ты интерпретируешь слова по-своему: речь не про то, что «настоящие программисты» не делают ошибок или не используют valgrind.

Вряд ли

О том и речь.

При работе над общим кодом на Rust я хотя бы буду меньше зависеть от их ошибок.

О том и речь.

eao197 ★★★★★ ()
Ответ на: комментарий от anonymous

в последнее время ты сильно сдаешь свои позиции

Пойду утоплюсь с горя.

когда признался, что не рабираешься в теории акторов и ксп.

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

PS. Царь, ты справку уже взял?

eao197 ★★★★★ ()
Ответ на: комментарий от dearAmomynous

Напоминает то время, когда появился С++. Все кричали: С плох и ненужен. Потом Джава - та самая история, только С++ добавили в список ненужных. Потом С# нарисовался. Ну вы поняли. Раст ещё не доказал своей проф пригодности, его даже в Мозилле не используют в чистом виде. Вам, может, уже ясно что он всех заменит, но большинству не ясно. Как он ведёт себя в крупных проектах с длительной поддержкой, только гадать. Касательно безопасности памяти, так любой язык с сборщиком мусора имеет такие же гарантии. Касательно быстродействия, раст уступает С и С++. Касательно простоты использования, поддержки concurrent программирования и развитости инфраструктуры он уступает Go. Вы агритесь, потому что думаете что другие считают раст калом. Хотя на деле другие люди вам говорят, что преимущество раста над любым другим языком не очевидно.

anonymous ()
Ответ на: комментарий от h4tr3d

1. даешь новичку книжку по с++

2. просишь его самостоятельно реализовать что-нибудь простенькое из stl.

3. удивляешься с выхлопа компилятора

уж не знаю, как там в «последних компиляторах», ии прикрутили?

MyTrooName ★★★★★ ()
Ответ на: комментарий от eao197

В свое оправдание скажу, что это была моя первая (и последняя) програмка на Си и я ее таки победил, но осадочек остался. Скорее даже не осадочек. Осадище

Я даже делился болью с реддитом. Советы были один охренительнее другого:

  • Сделай свою библиотеку для массивов с длиной
  • Сделай свою библиотеку-счетчик ссылок
  • Си не предназначен для работы с кучей. Получил 2 байта — сразу отправь (наверное в микровервис для хранения массивов)
  • Есть отличнный встраиваемый язык lua. Встрой и оперируй динамическими данными в нем
  • В начале работы програмы выдели большой кусок кучи и запили в нем собственный malloc на на int-ах вместо ссылок
  • Use Java
spoonbob ()
Ответ на: комментарий от MyTrooName

Всегда радует мнение «диванных экспертов», тех кто либо в глаза язык не видел, либо использовал его в универе, либо джуном на древнем проекте. Вы из них который?

anonymous ()
Ответ на: комментарий от anonymous

Касательно безопасности памяти, так любой язык с сборщиком мусора имеет такие же гарантии.

нет. языки со сборщиком мусора не гарантируют своевременного освобождения утекшего ресурса.

Касательно быстродействия, раст уступает С и С++.

не уступает. C будет быстрее только если вручную запиливать концепции, которые раст дает по-умолчанию, и адаптировать под них нужные тебе библиотеки. при этом размер кода вырастает в десятки раз, про поддерживаемость вообще умолчим

Касательно простоты использования, поддержки concurrent программирования и развитости инфраструктуры он уступает Go

не знаю про го.

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

MyTrooName ★★★★★ ()
Последнее исправление: MyTrooName (всего исправлений: 1)
Ответ на: комментарий от eao197

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

Ура! Наконец-то ответ на вопрос почему в офисах настоящих программистов не стоят таблички «Чтобы не свалиться/сгореть воспользуйтесь valgrind глазами», вместо перил, дверей в лифте, скрытой проводки и пожарной сигнализации.

red75prim ()
Ответ на: комментарий от eao197

И им тоже приходится смотреть на выдачу valgrind.

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

Я думаю, spoonbob тоже разобрался со своей проблемй, пусть и за два дня.

речь не про то, что «настоящие программисты» не делают ошибок или не используют valgrind.

Даже трижды настоящим программистам не мешало бы получше «подтирать за собой». Сейчас они используют для этого valgrind, но к этому в ближайшем будщем добавится borrow checker (неважно, в Rust-воплощении или Си++-воплощении).

При работе над общим кодом на Rust я хотя бы буду меньше зависеть от их ошибок.

О том и речь.

Так и они будут меньше зависеть от моих. Потому что Rust будет «подтирать» за нами всеми.

tailgunner ★★★★★ ()
Ответ на: комментарий от MyTrooName

Какого какого ресурса? Есть сайт, видимо, вам не известный: godbolt.org aka CompilerExplorer. Загоните в него код на расте и на С/С++, докажите своё утверждение о быстродействии. Вот я про это и говорил про «лучше». Языки выбирают под задачу, а не потому что лучше.

anonymous ()
Ответ на: комментарий от anonymous

Какого какого ресурса?

с терминологией проблемы?

Есть сайт, видимо, вам не известный: godbolt.org aka CompilerExplorer. Загоните в него код на расте и на С/С++, докажите своё утверждение о быстродействии

сначала ты

MyTrooName ★★★★★ ()
Ответ на: комментарий от red75prim

Ура, теперь у нас настоящими программистами будут считаться люди, которые не могут разобраться, как работать с динамической памятью в C:

«Мои мозги действительно не способны работать с кучей на Си.»

Двадцать лет назад таких выставляли на мороз из профессии.

Сейчас они будут делать софт.

Ну вот и хорошо, что они будут делать софт на Rust, а не на C.

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

Двадцать лет назад таких выставляли на мороз из профессии.

Ну вот, а не было бы перил, так бы осталось. Кто не способен заметить очевидные вещи в профессии бы не задержался.

red75prim ()
Последнее исправление: red75prim (всего исправлений: 1)
Ответ на: комментарий от mersinvald

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

anonymous ()
Ответ на: комментарий от eao197

Успехов тебе.

Пойду утоплюсь с горя.

Беру свои слова обратно. Не хочу, чтобы ты был успешен в этом виде деятельности.

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

Это ты так реламируешь свою реализацию акторов, показывая уровень знакомства с теорией?

PS. Царь, ты справку уже взял?

У нас разные понятия «царь». Наверно, это должно быть смешно. Осталось выяснить, кто -«шут», кто - «зритель».

anonymous ()
Ответ на: комментарий от anonymous

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

А методы программирования, конечно, не имеют к этому отношения.

tailgunner ★★★★★ ()
Ответ на: комментарий от red75prim

Я уже устал объяснять простую вещь, но попробую еще раз:

Еще не так давно человек, который не может разобраться с динамической памятью в C, был просто профнепригоден.

Сейчас таких людей полно и они массово пишут софт.

Я лично считаю, что в этом нет ничего хорошего. Но раз уж такое существует, то пусть лучше эти люди пишут на Go или Rust-е.

Ну и, поскольку и такого объяснения не поймут (что у растоманов, как видно, в порядке вещей), то другими словами:

Язык С выдвигает серьезные требования к уровню разработчика. Высокие, но не запредельные. Нормальный разработчик (пусть даже в вашей терминологии это будет «настоящий программист») сможет написать работающий код на C. Пусть даже это будет стоить дорого.

А вот язык Rust эти требования снижает. И на Rust-а программу сможет написать даже тот, кто еще недавно нормальным программистом считаться вряд ли смог бы.

eao197 ★★★★★ ()
Ответ на: комментарий от anonymous

Напоминает то время, когда появился С++. Все кричали: С плох и ненужен. Потом Джава - та самая история, только С++ добавили в список ненужных. Потом С# нарисовался. Ну вы поняли. Раст ещё не доказал своей проф пригодности, его даже в Мозилле не используют в чистом виде. Вам, может, уже ясно что он всех заменит, но большинству не ясно. Как он ведёт себя в крупных проектах с длительной поддержкой, только гадать.

Не нужно меня сгребать в кучу ко всем. Я не молюсь на джаву или раст, и не говорю что какой-то из языков нужно похоронить. Пусть он не идеален и у него мутное будущее (Как и у мозиллы), но он, ИМО, - первая удачная попытка найти компромисс между «На этом удобно писать» и «Программы на этом работают быстро».

Касательно безопасности памяти, так любой язык с сборщиком мусора имеет такие же гарантии.

Да, но они катастрофически тормозные и прожорливые. Это относительно, и железо помощнее спасает, но факт есть факт.

Касательно быстродействия, раст уступает С и С++.

Не удивительно, но он уступает далеко не так сильно как остальные. И у меня есть подозрения что после реализации некоторых RFC станет уступать ещё меньше.

Касательно простоты использования, поддержки concurrent программирования и развитости инфраструктуры он уступает Go.

Для меня он довольно прост в использовании, хотя могло быть (и будет) лучше. Правда интересующие меня фичи продвигаются крайне медленно. С Go не знаком.

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

Да, именно. Rust может быть не идеален, но уж точно не кал. Он занимает (лично мне) интересную нишу между безопасностью, удобством и производительностью. Он безопасен: если в черепной коробке есть хоть какой-то зачаток межушного ганглия, дабы можно было либо писать иногда корректный unsafe, либо не использовать его вовсе и не стрелять себе в ногу. Он удобен и «более корректен»: В частности, трейты, дженерики, вменяемые итераторы, utf8 из коробки, match, while/if let с прочими деструктуризациями, enum со значениями заместо boost::variant (В частности Result и Option, включая Box внутри них, заместо проверки на nullptr), слайсы, нормальные макросы, аттрибуты, с сахарной пудрой из проверок корректности компилятором и адекватных сообщений об ошибках, etc. - это всё то, чего в C/C++ мне не хватало. Он быстрый: это конечно не код на C, написанный гуру своего дела, но и не Java, на которой IDEA делает индексацию и подсветку по пол минуты (В этом я не одинок, у них полно тикетов в багтрекере). Иными словами - мне очень даже хватает, даже если он уступает C/C++.

dearAmomynous ()
Ответ на: комментарий от eao197

Да я вроде бы и не противоречу. Нормальный программист сможет работать и в офисе без перил, если он ему в наследство достался. Почему ему это может нравится - другой вопрос.

red75prim ()
Ответ на: комментарий от eao197

Язык С выдвигает серьезные требования к уровню разработчика. Высокие, но не запредельные.

Проблема в том, что несоответствие этим требованиям проявляется тогда, когда программа уже написана и сдана заказчику.

А вот язык Rust эти требования снижает.

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

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

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

А методы программирования, конечно, не имеют к этому отношения.

О, и вы туда же. Какие такие методы?

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от eao197

Еще не так давно человек, который не может разобраться с динамической памятью в C, был просто профнепригоден.

Еще недавно человек, который не разбирается в характерах лошадей, был просто непригоден к управлению дилижансом.

freecoder ()
Ответ на: комментарий от h4tr3d

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

Самым странным, что я видел, было что-то вроде `error expected &std::unique_ptr<T>, got &std::unique_ptr<T>` или вроде того, сейчас уже не воспроизведу.

Freyr69 ★★★ ()
Ответ на: комментарий от freecoder

Еще не так давно человек, который не может разобраться с динамической памятью в C, был просто профнепригоден.

Еще недавно человек, который не разбирается в характерах лошадей, был просто непригоден к управлению дилижансом.

Он и сегодня непригоден, просто управлять дилижансом уже не надо. А программировать еще надо.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Ну конечно. Можно я вас исправлю s/методы/методологии/g, лады?

Как простейший пример - обращения к глобальным переменным должны защищаться мютексами.

^-- это и это --v

той моделью памяти, которая определяется аппаратной архитектурой

А ну-ка просветите, это вы о какой аппаратной архитектуре речь ведете? А главное, о какой аппаратной команде речь? Достаточно мнемокода.

anonymous ()
Ответ на: комментарий от anonymous

Да, посмотри на этот языковой шовинизм вокруг. Толпа полуграмотных защищает свое из-за эмоциональных мотивов, а не технических. Нужно играть на том же поле.

vlad9486 ()
Ответ на: комментарий от tailgunner

просто управлять дилижансом уже не надо. А программировать еще надо

Так я об этом и говорю. Просто у некоторых не укладывается в голове, что в один прекрасный день программисту знать Си будет уже не надо, чтобы выполнять те же задачи.

freecoder ()
Ответ на: комментарий от tailgunner

Сейчас они используют для этого valgrind

Как вообще люди используют valgrind? Он же делает программу в 40 раз медленней, ничего серьезного под ним не запустишь. Создают тестовую прграмму на каждый чих? Если у меня 666 объектов и где-то утечка, я все разом целиком валграйнду не смогу скормить.

Freyr69 ★★★ ()