Я бы ещё добавил, наверное, сравнение с С++ными примитивами для управления памятью — unique_ptr, shared_ptr и прочее, и указанием, почему всё-таки они не панацея. Потому что это довольно справедливая претензия — в современном С++ код через сырые указатели стараются не писать.
Вы читали статью вообще? В Rust есть и куча, и сборщики мусора (ну сейчас там в стандартной библиотеке не полноценный GC, а подсчёт ссылок, но это дело желания и умения — написать нормальный GC). При этом все эти механизмы безопасны в принципе. А в C++ ничего не мешает вам, например, взять указатель во внутренности unique_ptr. Я уже не говорю про более сложные случаи, связанные с многопоточностью.
Очень странно, что вы увидели в Rust CoffeeScript'овый синтаксис. В Rust используются стандартные для C блоки для выделения кода, например. Да он вообще не похож на CoffeeScript!
А насчёт плюшек — тут можно спорить. Например, лично мне не нравятся строковые миксины, пусть они и офигенно мощные. А в Rust есть нормальные синтаксические гигиеничные макросы (и возможность создания полноценных процедурных макросов, как в Scala, например).
Если в D отключить сборщик мусора, то стандартная библиотека перестанет нормально функционировать. Кроме того, если вам стандартная библиотека и не нужна, то, отключая GC, вы возвращаетесь в мир проблем C++, так хорошо описанный автором статьи.
В Rust изначально заложена возможность писать безопасные программы без сборщиков мусора и других автоматических систем управления памятью.
Примесь это mixin. Это другого рода концепция. Например, в Scala примеси реализуются через трейты. В Rust такого понятия сейчас вообще не существует. Трейты — это, фактически, классы типов из Scala.
Я вам очень не советую переизобретать терминологию, вы сделаете только хуже для своих читателей. Если бы вы переводили художественный текст, то всё было бы в порядке. Если бы вы переводили тексты с совершенно новыми концепциями, которые до вас не переводил никто в принципе (включая сленг и жаргон), то это тоже бы прокатило. Но в технических/научных текстах с уже давно устоявшимся переводом терминов изобретать свой собственный перевод этих терминов нельзя. Это одно из основных правил переводчика профессионально-технической литературы.
Ну «сюръекция» — это «отображение на», т.е. отображение, у которого образ совпадает с областью значений. Если в вашей мапе из строк в Integer меньше 2^32 элементов, или если их 2^32, но хотя бы два значения совпадают, то это уже не сюръекция :)
Нет, не так. Map в этом случае в английском подразумевает именно отображение, потому что ассоциативный массив по сути и есть математическое отображение, которое в английском обозначается, в частности, словом «map» (или «mapping»).
Грубо говоря, в английском этой структуре данных соответствуют понятия {map, dictionary, associative array}. В русском же это будет {словарь, ассоциативный массив}. Это означает, что перевод «map» как «отображение» в контексте структур данных будет неверным, потому что это не устоявшийся термин. При этом «мапа» или «мап» будет сленговым/жаргонным переводом, который допустим в определённых условиях (например, в личной переписке или в разговоре), но недопустим в других условиях, например, в деловом/научном тексте. То же самое справедливо для трейтов.
Не могу с вами согласиться. Это не дело вкуса, это общепринятая терминология. Точно так же, как Map<K, V> в Java не переводят как «отображение» (хотя это и есть непосредственный перевод, в том числе и по смыслу) — обычно так и говорят, «мап» или «мапа», реже — «словарь» или «ассоциативный массив» (что очень длинно и неудобно, поэтому так говорят редко). Если не придерживаться общепринятой терминологии, то люди просто перестанут друг друга понимать.
Тем не менее, это термин. В сообществе Scala и, насколько я в курсе, PHP используется в подавляющем большинстве именно он. Multitran также символизирует.
«Тип реализует трейт» ничем не хуже чем, например, «тип реализует интерфейс». И если так подумать, то способности не реализуют, ими обладают, что в контексте языков программирования не используется почти никогда.
Никак — просто трейт. Например, такой термин используется в переводах книг по Scala. Ещё один возможный перевод — «типаж», но он, имхо, хуже, чем «трейт». См. здесь.
А сопоставление с образцом — это как раз самый распространённый и вменяемый перевод pattern matching'а, хотя в разговорной речи обычно всё-таки говорят «паттерн-матчинг» :)
В Rust Option — бесплатная штука. Компилятор оптимизирует использование памяти так, что, в частности, Option<&int> будет занимать ровно столько же памяти, сколько и &int. Это возможно за счёт отсутствия null-указателей. Более того, в планах схожая оптимизация для большего количества типов, помимо указателей.
Про динамическую память тут уже объясняли. Все операции с памятью в Rust детерминированы. Например, вышеупомянутый `Vec` выглядит примерно так:
Т.е. это длина, ёмкость и указатель на динамически выделенную память. При создании экземпляра этой структуры поля инициализируется, память выделяется. Когда экземпляр выходит из области видимости, вызывается деструктор, который уничтожит динамически выделенную память.
Примерно так же работает и std::vector в C++. Однако в C++ вы можете получить указатель на внутренности массива, и этот указатель сможет «пережить» сам массив — например, его можно вернуть из функции, где вектор является локальной переменной. В Rust это невозможно принципиально за счёт статического анализа. В этом, собственно, главное преимущество Rust — за счёт статического анализа полностью исключаются возможности обращения к невалидной памяти.
Если немного поразмышлять, можно увидеть, что типы, подобные Vec имеют семантику типов-значений, т.е. ведут себя точно так же, как типы-значения вроде int (за исключением автоматического копирования и вызова деструкторов; это различие также себя проявляет в системе типов Rust за счёт трейтов Copy, Clone и Drop), даже несмотря на то, что внутри у них динамически выделенная память. Такие структуры очень легко описывать в терминах владения данными и уникальных указателей. Однако, это не всегда удобно/возможно: например, с помощью уникальных указателей можно описать древовидные структуры данных, а вот двусвязный список, например, сделать уже нельзя. В таком случае используются другие типы умных указателей, например, Rc, который означает указатель с подсчётом ссылок, или Gc, который будет означать указатель со сборкой мусора. В C++ есть аналогичные типы, например, shared_ptr или unique_ptr, но в C++ ничего не мешает вам получить обычный сырой C-указатель на их внутренности и сохранить его после того, как указатель «умрёт». В Rust этого сделать нельзя в принципе.
В целом, я согласен, это тема достойная отдельной статьи.
Рабочая станция разработчика — это рабочая станция разработчика. Продакшен — это боевые сервера. Если вы считаете не так, то у вас, как мне кажется, странное восприятие термина «продакшен» :)
На сайте у авторов, имхо, и не должно быть ничего, кроме tar.gz. Пакеты для конкретных дистрибутивов должны делать мейнтейнеры. Когда Rust стабилизируется, я более чем уверен, что во всех популярных дистрибутивах появятся пакеты. Сейчас в этом нет особого смысла.
Пожалуйста, не называйте трейты способностями :) насколько я в курсе, такой перевод термина trait в контексте языков программирования вообще не используется и сильно режет глаз :)
Во-первых, когда Rust станет постабильнее, появятся и пакеты, поддерживаемые мейнтейнерами дистрибутивов. Сами разработчики и не должны этого делать никак. А для Ubuntu, например, уже сейчас есть PPA.
Во-вторых, зачем вам в продакшне компилятор Rust? В продакшне будет результат работы компилятора — бинарник, который скорее всего даже будет статически слинкован — аналогично Go. У него не будет зависимости на Rust.
Уже нельзя редактировать комментарий. Но то, что Go не может быть полноценным системным языком (как C/C++) — это вполне объективный факт. Вы не сможете его использовать везде, где вы можете использовать C. Go тянет за собой рантайм (не уверен, можно ли его отключить, но даже если и можно, то все ключевые возможности Go, включая горутины, потеряются), что совершенно неприемлемо в embedded. Про сборку мусора я уже писал. Добавлю ещё про невозможность нормального преобразования указателей, только через unsafe.Pointer с жутким синтаксисом. В области применения, на которую рассчитан Go, это совершенно не страшно; в области, где царствует C — это, наоборот, очень важно.
Ок, эту фразу я почему-то пропустил. Но, во-первых, больше там про это ничего нет, а во-вторых, даже если и так, и авторов Go на самом деле сподвигли на подвиги проблемы C/C++, то в любом случае Go не может быть полноценным системным языком, как C/C++.
Я бы ещё добавил, наверное, сравнение с С++ными примитивами для управления памятью — unique_ptr, shared_ptr и прочее, и указанием, почему всё-таки они не панацея. Потому что это довольно справедливая претензия — в современном С++ код через сырые указатели стараются не писать.
А насчёт плюшек — тут можно спорить. Например, лично мне не нравятся строковые миксины, пусть они и офигенно мощные. А в Rust есть нормальные синтаксические гигиеничные макросы (и возможность создания полноценных процедурных макросов, как в Scala, например).
В Rust изначально заложена возможность писать безопасные программы без сборщиков мусора и других автоматических систем управления памятью.
Mapв этом случае в английском подразумевает именно отображение, потому что ассоциативный массив по сути и есть математическое отображение, которое в английском обозначается, в частности, словом «map» (или «mapping»).Грубо говоря, в английском этой структуре данных соответствуют понятия {map, dictionary, associative array}. В русском же это будет {словарь, ассоциативный массив}. Это означает, что перевод «map» как «отображение» в контексте структур данных будет неверным, потому что это не устоявшийся термин. При этом «мапа» или «мап» будет сленговым/жаргонным переводом, который допустим в определённых условиях (например, в личной переписке или в разговоре), но недопустим в других условиях, например, в деловом/научном тексте. То же самое справедливо для трейтов.
Map<K, V>в Java не переводят как «отображение» (хотя это и есть непосредственный перевод, в том числе и по смыслу) — обычно так и говорят, «мап» или «мапа», реже — «словарь» или «ассоциативный массив» (что очень длинно и неудобно, поэтому так говорят редко). Если не придерживаться общепринятой терминологии, то люди просто перестанут друг друга понимать.«Тип реализует трейт» ничем не хуже чем, например, «тип реализует интерфейс». И если так подумать, то способности не реализуют, ими обладают, что в контексте языков программирования не используется почти никогда.
А сопоставление с образцом — это как раз самый распространённый и вменяемый перевод pattern matching'а, хотя в разговорной речи обычно всё-таки говорят «паттерн-матчинг» :)
Option— бесплатная штука. Компилятор оптимизирует использование памяти так, что, в частности,Option<&int>будет занимать ровно столько же памяти, сколько и&int. Это возможно за счёт отсутствия null-указателей. Более того, в планах схожая оптимизация для большего количества типов, помимо указателей.Про динамическую память тут уже объясняли. Все операции с памятью в Rust детерминированы. Например, вышеупомянутый `Vec` выглядит примерно так:
Т.е. это длина, ёмкость и указатель на динамически выделенную память. При создании экземпляра этой структуры поля инициализируется, память выделяется. Когда экземпляр выходит из области видимости, вызывается деструктор, который уничтожит динамически выделенную память.
Примерно так же работает и std::vector в C++. Однако в C++ вы можете получить указатель на внутренности массива, и этот указатель сможет «пережить» сам массив — например, его можно вернуть из функции, где вектор является локальной переменной. В Rust это невозможно принципиально за счёт статического анализа. В этом, собственно, главное преимущество Rust — за счёт статического анализа полностью исключаются возможности обращения к невалидной памяти.
Если немного поразмышлять, можно увидеть, что типы, подобные
Vecимеют семантику типов-значений, т.е. ведут себя точно так же, как типы-значения вроде int (за исключением автоматического копирования и вызова деструкторов; это различие также себя проявляет в системе типов Rust за счёт трейтов Copy, Clone и Drop), даже несмотря на то, что внутри у них динамически выделенная память. Такие структуры очень легко описывать в терминах владения данными и уникальных указателей. Однако, это не всегда удобно/возможно: например, с помощью уникальных указателей можно описать древовидные структуры данных, а вот двусвязный список, например, сделать уже нельзя. В таком случае используются другие типы умных указателей, например,Rc, который означает указатель с подсчётом ссылок, илиGc, который будет означать указатель со сборкой мусора. В C++ есть аналогичные типы, например, shared_ptr или unique_ptr, но в C++ ничего не мешает вам получить обычный сырой C-указатель на их внутренности и сохранить его после того, как указатель «умрёт». В Rust этого сделать нельзя в принципе.В целом, я согласен, это тема достойная отдельной статьи.
На сайте у авторов, имхо, и не должно быть ничего, кроме tar.gz. Пакеты для конкретных дистрибутивов должны делать мейнтейнеры. Когда Rust стабилизируется, я более чем уверен, что во всех популярных дистрибутивах появятся пакеты. Сейчас в этом нет особого смысла.
Во-вторых, зачем вам в продакшне компилятор Rust? В продакшне будет результат работы компилятора — бинарник, который скорее всего даже будет статически слинкован — аналогично Go. У него не будет зависимости на Rust.