Как стать автором
Обновить

Комментарии 66

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

Потому что :

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

  2. Изза обилия дублирующих по функционалу языков и библиотек к ним, наблюдается сильный разброс требований

  3. Индустрия плавно загибается, новых специалистов все меньше, удав начал есть себя с хвоста

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

Сейчас просто все смешалось: тяжелое наследие прошлого, текущий мейнстрим и ростки будущего.

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

Мне недавно надо было написать генератор флуда в journald для оценки его производительности. Питон отвалился (кратно медленнее journald), писать на Си было многообещающе. Написал на Rust'е, пять строчек. 1:2 по нагрузке (50% моего приложения на 100% journald). Совершенно тривиально и просто. Для меня это такой добротный инструмент второго ряда, если медленные языки не справляются.

Вроде бы потенциальный сценарий для Go. Он не рассматривался?

Нет, потому что я его не знаю. Но, в целом, go менее предсказуемый из-за GC.

Пишу на расте за деньги и отлично себя чувствую. Количество растеров в команде выросло в 8 раз за полгода. Еще год назад вакансии на растовские проекты приходилось выискивать самому, сейчас и проектов предостаточно, и рекрутеры активно хантят так же как со всеми остальными языками. Язык растет и активно развивается, фичи вливаются, экосистема тоже крепнет. Интерес к расту со стороны фаангов присутствует и увеличивается.

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

С одного человека до восьми?

C 5 до 40 :)

Вы ещё скажите что не HFT и не блокчейн

Ну чо ты сразу с козырей-то заходишь

Именно так и скажу :)
Вот если бы всё в языке было бы действительно так просто — было бы конечно очень хорошо. Но увы, начинаешь погружаться, бьешься головой о borrowing, мозг медленно закипает с непривычки, потому что раньше с этой концепцией не работал:) Потом бьешься головой о встроенные типы, потом об ошибки, которые непонятно как дебажить, и вот уже и выходные прошли и опять надо идти в свои убогонькие недоязычки на работе :(
Я пробовал научиться играть на флейте — гораздо сложнее. Заставить мозг запомнить всю эту распальцовку для меня оказалось нереально сложно, сразу бросил это дело. А вот заимствования куда проще — пишешь код и уже сам примерно предвидишь: «вот тут, скорее всего ругнётся. Ну, тогда, сделаю вот так». А там уже он ругается и таки приходится делать как-нибудь «вот так».

Насчет borrowing Rust обычно прав. Поначалу бесит, но потом понимаешь, что компилятор нашел в коде неочевидную архитектурную ошибку, которую на C++ я бы прозевал.

Так и есть, в начале тяжело. Но через полгода-год практики уже перестаешь замечать, что пишешь на языке с BC, а не с GC.

Зато потом приходишь в другие языки, и такой: ааааа где проверка типов? ааааа здесь можно оставить висящую ссылку! аааа нуллпоинтер!

И так далее.

Кстати, после Rust'а я начал лучше писать на Питоне. Когда используешь модель Rust'а вне Rust'а, то часть бенифитов сохраняется. Тебя больше никто не поправляет на ошибках, но если их не допускать, получается хороший код.

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

Пишу на C++, пишу многочисленные std::move и постоянно ловлю себя на мысли, что проще было бы иметь move по дефолту, и писать clone в паре мест, где они нужны.


С другой стороны Rust никак не решает проблему целостности структур данных в хипе. RC запросто создает циклы и приводит к утечкам. Так что lifetimes/borrowing — полезный инструмент анализа, но не панацея.

Госпаде замени копи конструктор на мув и мув на копи будет у тебя дефолт… Копи конструктор с неконстантным входным значением компилируется

Замечательная идея: в итоге наши типы будут с одним умолчанием, все остальные — с другим. Читать такой код будет очень интересно.

#define true false какой-то…
Я лично не вижу проблемы писать просто move, но раз уж ему надо — есть решение и для таких

Боюсь, что с циклами это вообще фундаментальная проблема, да и утечки это не так уж смертельно, на самом деле.

Я бы добавил, что утечка утечке рознь.


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


Куда более распространенная в си ситуация связана с «беспорядочной половой жизнью» указателей и спонтанные, неформализованные и нигде не задокументированные контракты владения вида:


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

и т.д.


Притом что во всех случаях интерфейс, утрируя, может выглядеть как void foo(void* ptr).


При таком подходе утечь память, прозевав, кто же все-таки должен ее прибирать, — раз плюнуть.

это одна из болезненных особенностей поддержки плюсового легаси. Рефакторишь на ссылки/смартпоинтеры и сразу дышится легче.
А как насчет поддержки оконного интерфейса? Консольные программы это конечно хорошо, но в мире Windows как-то более привычны «форточки». Если уж рекламировать язык программирования, то, желательно, что-нибудь GUI-ёвое.
С текущей тенденцией ухода фронтендов на веб-стек, думаю это уже не так актуально
Кому не актуально, тот пусть на нем и работает. А нас вполне устраивает C++ / WTL

Нее, "нас" не устраивает не кроссплатформенное решение.

А «нас» устраивает! Тем более что проблема высосана из пальца. Не хотите C++ / WTL, используйте кроссплатформенный C++ / wxWidgets либо C++ / Qt. Какие проблемы? В любом случае, фундаментальный Си / С++ будет актуальным еще долго!

Вот здесь можно оценить состояние экосистемы https://www.areweguiyet.com/

Спасибо за дополнение

Оценил, разочарован!

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


Или может быть вы разочарованы в том что Microsoft официально поддерживает WinAPI для Rust?

Просто мне нужно то, что вам не нужно и, скорее всего, наоборот. А нужен мне, для моего проекта, легкий интерфейс. WTL идеально подходит, С / С++ достаточно удобные, привычные и мощные. Что лично мне еще надо? Можно купить еще более удобным интерфейсом, например, как в опенсорсном Win32++ ( sourceforge.net/projects/win32-framework/files ). Но там все сделано в стиле MFC (от которого я уже отвык, кстати, и сам MFC M$ сделали уже опенсорсным, но, как для меня, слишком поздно), поэтому предпочитаю оставаться на WTL.

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

Вы забыли упомянуть самые главные особенности: то как раст работает с памятью и какие проблемы этим самым решает.

В целом неплохо. Но есть некоторые неудобные концепции.
Зачем нужен let, при этом контстанты декларируются явно const. Всё что не константы, должно быть mutable, но для раста это не так. Так что кодеру приходится думать о том, что и где у нас мутирует и почему. Подозреваю, правила видимости переменных в расте слишком либеральны.
Работа со строками как с массивами байтов мягко говоря уже как-то старомодно. Должна быть поддержка utf8/utf16 с определением длины таких строк в символах. Так что в целом довольно коряво, но для написания кода оно несколько лучше с.
Зачем нужен let, при этом контстанты декларируются явно const. Всё что не константы, должно быть mutable, но для раста это не так.

Сюрприз: ещё и static есть. Язык всё-таки системный и это различие бывает важно. Ну а то, что "переменные" не изменяемые по умолчанию на мой взгляд очень удобно.


Должна быть поддержка utf8/utf16 с определением длины таких строк в символах.

Поддержка utf8 есть, а вот utf16 — это как раз и есть "старомодно".


Подозреваю, правила видимости переменных в расте слишком либеральны.

Это как?

Есть ещё static mut для совсем ценителей.

Константы ≠ иммутабельные переменные. Константное значение может быть (и будет) вычислено в compile-time и жёстко зашито в бинарник. Если мы спрашиваем число у пользователя и кладём в переменную, то она не может быть const. Даже если никогда не собираемся её обновлять. Невозможно захардкодить значение, которого мы не знаем.

Так что кодеру приходится думать о том, что и где у нас мутирует и почему

Весь язык построен на borrowing rules, которые требуют, чтобы на один объект не было больше одной мутабельной ссылки в каждый момент времени. Это довольно строгое ограничение, которое компилятор должен суметь доказать в compile-time. Соответственно думать и помнить об этом приходится, таков язык. Он вообще не позиционируется как простой.

Должна быть поддержка utf8/utf16 с определением длины таких строк в символах.

Обычный вопрос для юникода — а что именно считать одним символом? Не все знакомы с особенностями юникода, поэтому в corner-cases ожидания людей частенько не совпадают с реальным поведением. Соответственно вылезают неожиданные баги, которые язык стремится предотвратить. Явное лучше неявного и всё такое. Однако для простых случев в стандартной библиотеки есть s.chars(), но у него в документации явно сказано, что он может возвращать не совсем что хотелось. Плюс в Книге целая глава посвящена аккуратной работе со строками.

Следующий момент — Rust позиционируется как производительный язык с zero-cost абстракциями. Вычислить длину UTF8 строки невозможно за O(1). Это совсем не совпадает с ожиданием, что длина любой коллекции вычисляется быстро. Поэтому предлагается писать s.chars().count() — явно создать итератор по символам, полностью его перебрать и вычислить длину.

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

Не понял аналогии, возможно вы что-то путаете. В языке есть let mut/let и есть &mut/ & (ссылки). Если планируется менять переменную, то let mut нужно обязательно указывать, хотя компилятор и так мог бы разобраться. Эта пометка лишь помогает понять человеку, меняется ли значение. При желании, можно всем переменным ставить mut и ничего не сломается. С ссылками дела обстоят немного интереснее, потому что язык требуют от программиста соблюдать некоторые правила.

Они формулируются как-то так: на каждый объект может существовать либо единственная &mut ссылка, либо сколько угодно не-mut. Либо то, либо другое — одновременно нельзя.

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

Эти ограничения могут казаться излишне жёсткими, но на самом деле всё не так плохо. Во-первых, очень часто не нужно менять существующие объекты, достаточно их только читать. Во-вторых, некоторые вещи, например подкючение к БД, можно использовать и по обычной ссылке, несмотря что происходят всякие INSERT INTO и состояние "меняется" — базы данных сами умеют разруливать гонки и им не нужна помощь от компилятора. В-третьих, всегда можно перенести проверки в runtime, используя Arc+Mutex. Они не позволят нарушить правила и сделать гонку данных, но при этом позволяют (плохо) писать практически как на обычных языках.

Простой пример без многопоточности: человек начал итерировать по стандартному списку (vector), для чего взял на него не-mut ссылку. В большинстве других языков, если вдруг кто-то добавит элемент в список, то произойдет либо UB, либо исключение, либо какая-то другая неожиданность. Но чтобы добавлять элементы в список необходимо иметь &mut ссылку на вектор, а компилятор этого не позволит, совсем. Вот таким нехитрым образом потенциальная ошибка нашлась сразу же.

1. Я имел в виду только то, что вы и сами написали
> то let mut нужно обязательно указывать, хотя компилятор и так мог бы разобраться.
Идея заставить программиста соблюдать ограничения путём написания необязательных для работы компилятора синтаксических конструкций
выглядит очень неоднозначно. Очень многое в Rust сделано необычным образом. Но тут практика покажет насколько это жизнеспособно…
2. Моё знакомство с Rust, скажу честно, где-то в общей сложности составляет… гм… пару часов просмотра примеров из учебника...:)))
3. Достоинства реализации многопоточности в Rust после столь краткого знакомства мне трудно.
4. Использовать что-то вроде мьютекса для блокировки объектов однопоточного приложения- довольно экзотическая идея.

Ну, а что касается хорошей реализации unicode, в качестве стандартной библиотеки, то, надеюсь, это со временем и Rust получит.

В Rust Utf-8 строки, просто вы на них смотрите по-умолчанию как на байтовый массив.

Зачем нужен let

Потому что есть много сахара, основанного на паттерн матчинге, как пример: if-let, без let наверное можно было бы обойтись, но читаемость была бы сильно ниже.


Всё что не константы, должно быть mutable

Что, по-вашему должно происходить в выражении "x = y" и почему?


Подозреваю, правила видимости переменных в расте слишком либеральны.

Строго консервативны


Должна быть поддержка utf8/utf16 с определением длины таких строк в символах

Какая длина у составных эмодзи и почему вы думаете, что ваш вариант устроит всех?

Какая классная штука на последней гифке — выделение участка кода рамкой. А есть такое для плюсов в vscode?

Да, действительно. Vscode'ом не пользовался, но, держу пари, что-то похожее должно быть

Не знаю про vscode, но в большой студии (visual studio) я нажимал ctr и у меня выделялся кусок кода.

Спасибо за обзор. Мне тоже нравится Rust, полезно знать эту технологию, как инструмент для решения тех задач, где скриптовый язык (Ruby) будет нецелесообразен) Например, делал небольшой проект по парсингу больших файлов (десяток Гб), вполне понравился результат. Думаю Rust медленно, но верно набирает свой рынок. И лет через 5 все будут удивляться, как мы жили раньше без него)

Согласен, надеюсь, так и будет

Про необязательную точку с запятой что-то "резануло глаз".

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

На Unix-подобных ОС сделать это можно одной командой:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Упорно не могу понять, почему в куче руководств по разным софтам предлагается установка в обход пакетного менеджера. Когда я ставлю ПО через пакетный менеджер, я знаю, что произойдёт дальше. А когда ставлю через подобный скрипт, то появляется куча вопросов без ответа — куда произойдёт установка? будет ли возможность указать каталог для установки или оно молча улетит куда-нибудь в /usr/local? будет ли оно использовать системные библиотеки в зависимостях или потащит свои бинарники?..


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

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

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

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

В Gentoo, к примеру, у меня 4 разных питона — пакетный менеджер умеет такое делать. Когда для разных проектов нужен определённый питон, то настраивается виртуальное окружение, которое делает симлинк на требуемый системный питон. Не говорю, что для раста надо делать также. Просто один из возможных способов.

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


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


Ну и наконец "найтли" версии языка собираются каждые сутки и опакечивать их нет никакого смысла. При этом "нестабильные" фичи доступны именно в найтли версиях. Про кросскомпиляцию уже сказали рядом — тоже аргумент.


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

Можно установить и в систему через пакет — удобно для контейнеров.
А для локальной разработки удобнее в домашнее окружение — несколько редакций, типов сборки и кэш пакетов — переключается и обновляется на лету, не надо глобально систему дёргать.

В Fedora, например, есть пакеты rust, cargo и ещё пара причастных, прям в основном репозитории. Но они заточены под ту архитектуру, для которой собраны, т.е. если вам по какой-то причине нужна кросс-компиляция — они не очень помогут.

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

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


Была ли в этом множестве Ада?

Rustlings - очень удобный способ выучить язык в самом начале. Я за 3-4 дня разобрался, взял еще разбор на egghead, то, что надо

А дальше OSS, пишем что-нибудь для своего проекта - профит

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