>>790450

Эти чуть пояснили чутка про техническую часть
>>794774
>>790486

А вот тебе ещё сверху чуть более философских субъективных мыслей, может, что-то покажется интересным.

— Небольшое число вакансий

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

На Rust вакансии приходится искать, почти все они в Америке и Европе (и то там сильно меньше по сравнению с Америкой), в остальных странах суммарно и полсотни не набиралось тогда, когда я занимался поисками.
И искать приходится не только на linkedin/hh, а в Twitter, /r/rust и через сарафанное радио.
Зачастую ещё и оказывается, что Rust там всего лишь часть системы, довольно обособленная, и в твои обязанности будет входить что-то ещё.

В России сейчас, наверное, и 15 компаний с чистой разработкой на Rust не наберётся включая все блокчейны.
То есть, если хочется увеличить шансы найти работу, в дополнение к Расту сразу нужен хороший иностранный язык.

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

А если учитывать, что наличие проектов на Rust не делает компании и работу автоматом хорошей и интересной (особенно в далёкой перспективе), то выбор сужается ещё больше.

- Серьёзные требования к соискателям

К счастью, не всем таким долбоёбам что-то светит; к несчастью, потому, что нужны специфические знания.

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

Обиднее ещё то, что эти знания плохо переносятся между областями: веб-макака на Rust с прекрасным знанием редисов, кафок и прочих кубернетесов почти бесполезна в каком-нибудь embedded на Rust, там совершенно другие задачи.
Так что количество доступных вакансий на Rust на самом деле ещё меньше: долбоёбов брать человека просто за знания языка и библиотек (которых всё равно особо нет) не так много. Тех, кто при этом будет платить нормально, ещё меньше.

- Много не-Rust "legacy"

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

Очень частый сценарий в вебе: копролит на php/python/java/younameit распиливают на микросервисы на Rust, чтобы вот в этот-то раз всё стало заебись.
Мало того, что тебе в этом цирке придётся учавствовать, да ещё и на Rust писать будешь половину времени, остальное время дебажа старый продукт в тщётных попытках понять, что этот индусокод делает, и что за хитровыебаную бизнес-логику от тебя хотят.

- Rust может быть очень разный

В том же вебе ты будешь шлёпать типичный крудоговногод уровня `if err != nil`, только на Rust, склеивая клеем логику и либы с crates.io
Про unsafe будешь в страшных сказках слушать и вряд ли сам будешь трогать (если не поехавший экспериментатор).

В wasm проектах тебе с порога в зубы прилетает `#![no_std]`, с которым не работает 95% всех крейтов, зато добавляется горсть новых типа web-sys со своей особой пизданутостью.
В embedded к этому бонусом будут ffi биндинги ко всяким либам на C и, если не повезёт, ещё и макросы с asm и, конечно же, unsafe через unsafe.

Конечно, часть опыта переносится, но далеко не всё, особенно если в проекте найдутся ебанутые любители использовать много nightly фич, которые могут и меняться со временем.

- Мало знаний о том, как правильно писать на Rust

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

Обычное большинство твоих коллег (как и ты) будет среднехуёво знать сам язык и кодить в меру своего разумения так, как им видится.
Если повезёт, дело ограничится какими-нибудь тихими особенностями (а не полным пиздецом) в уголках их проектов из-за того, что они не смогли (не подумали) договориться о том, как код писать.

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

- Плохой тулинг и сложности с поиском серьёзных ошибок

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

Дебаггеры как бы есть (как и полторы ide), но до уровня дебаггеров JS или Java ему как до луны: обычные структуры из stdlib типа `OsStr` сейчас отображаются как набор байт, а не строки, лол.
Максимум, что ты с ними сможешь сделать (и то не всегда): запустить локально приложение и походить в нём по брейкпоинтам, проваливаясь в декомпилированный asm.
Возможно, ты даже сможешь понять, что записано почти во всех переменных на стеке (ну или будешь писать и учиться грузить pretty printer'ы на Python для дебаггера, если совсем заебёт).

- Нужно следить за всем, что происходит вокруг Раста и что-то изучать по мере сил

Тут примерно как в JS, доки по языку и либам очень редко бывают актуальными (если вообще есть, лол), всё бурлит, меняется и куда-то несётся, друг от друга зависит и тянет всякие аналоги leftpad.
Чтобы понять, как пользоваться нужными библиотеками, придётся зачастую читать их код (и хорошо если тесты или examples будут).
Поскольку большинство крейтов имеют версию `0.*`, компиляция может сломаться из-за простого апдейта какого-нибудь крейта (к счастью, не очень часто с таким сталкивался), за всем этим говном нужно следить и обновлять, чтобы не оказаться в дремучей жопе спустя пару лет, что тоже добавляет головняка.
Иногда проекты забрасываются, искать альтернативы и всё опять переписывать тоже удовольствие ниже среднего.

Будешь что-то гуглить нестандартное в узкой предметной области — рискуешь нарваться на пару полумёртвых крейтов и всё.
Если ты до сих пор впадаешь в ступор от ошибок компиляции, то тебе пизда, загуглить точный набор твоих закорючек зачастую невозможно а то, что гуглится, может и не подойти, потому что даже мелкое отличие может влёгкую агрить borrow checker.

Если полезешь в async, ещё и отличный от tokio, то придётся держать в голове зависимость крейтов от рантайма, что к чему подходит и как это заводить вместе, если не подойдёт (опять читать код, да).
Бонусом идёт повышенное веселье с компилятором и всякими `Pin`, хотя раньше, до async/await, когда были комбинаторы было ещё хуже, сейчас норм, можно наколбасить много кода до того, как нарвёшься на проблемы.

Описание новинок в самом языке появляется только в release notes, в Rust Book это оседает непонятно когда, обычно силами энтузиастов, почти всю команду документаторов Mozilla прибила своими увольнениями.
Если совсем на это положить хуй, спустя пару лет можно обнаружить себя довольно в стороне от современных фич языка.

>>798230

И ещё немного совсем субъективного:

- Местами странное развитие языка

Развитие самого языка иногда тоже вызывает вопросы: ключевые люди, сидящие на зарплате у Mozilla, уходят в другие компании со временем, совсем недавно ещё один ушёл.
Как ни удивительно, некоторые из них продолжают помогать с развитием языка и в других компаниях, но это не то, чтобы очень надёжная стратегия, как по мне: компилятор это не хуй собачий, даже люди на зарплатах пилят фичи долго и сложно.
Mozilla тоже не даёт скучать, в недавних увольнениях выпизднули много важных разрабов из wasmtime, servo.
Сам язык сидит частично на донатах: Microsoft дал им железо для сборки и прогона CI, что-то пилят в языке на голом энтузиазме мимокрокодилы.
Учитывая, что с баблом у Mozilla туго, быстрого развития языка можно не ждать, да и будущее тоже немного туманно: уже пошли разговоры о полном выделении Rust в отдельную организацию (сейчас как минимум бабло идёт через Mozilla).

Остатки кор тимы тоже не выглядят до хуя уверенными в своих действиях, вспомнить хотя бы выстраданный async/await с его костылями (`Pin` & `Unpin` с его unsoundness), который так и не доделали (async traits), хотя мудохались несколько лет.
Те же функциональщики смотрят на все эти заморочки с async блоками и иногда обсуждаемыми try блоками с удивлением, есть вполне себе рабочие подходы к дизайну языка, которые позволяют этого всего зоопарка избежать, унифицировав.

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

— Много бестолкового хайпа вокруг

Грустно наблюдать все эти ебанутые разборки фанатов async-std и tokio, шумиху вокруг unsafe в actix-web и прочую странную активность: вместо того, чтобы помогать пилить крейты, ебучие белки-истерички разводят шум и драму из года в год.

Доходит до странностей: сейчас на crates.io есть всего один НЕ асинхронный production-ready веб фреймворк, и тот в следующей версии тоже станет асинхронным.
Получается, просто потому, что это стильно и модно, любой веб-сервер на Rust вынужден тащить один из рантаймов с десятками лишних зависимостей, ебаться с async/await и ограничивать себя в выборе крейтов, либо сидеть на древних, не обновляемых библиотеках.
(не говоря уже о том, что есть вполне себе реальные real-time приложения с жёсткими требованиями к latency, которые асинхронные рантаймы в принципе не способны гарантировать)

- Сложно уходить обратно на другие языки

После того, как привыкаешь к Расту, пилишь на нём несколько лет и потом берёшь типичный ебаный проект на каком-нибудь Python/JS, то поначалу просто оторопь берёт, чувствуешь себя как без рук: как можно писать без нормальных типов, без cargo check, с пониманием, что любая строчка может бросить exception и это считается нормальным?
В паре проектов без тестов я просто не мог ни строчки написать несколько дней, пока привыкал.

>>804749

> указывай типы переменных в замыканиях и будет счастье?

Нет. Эта ошибка немного другого толка, и скорее всего её быстро исправят.

> Как в Rust с асинхронностью?

Средне. Асинхронные функции возвращают уникальный объект, который имплементирует специальный трейт future. Внутри асинхронной функции с этим трейтом можно использовать оператор await (т.е. с точки зрения await нет разницы является ли функция асинхронной или синхронной, но возвращающей Future-подобный объект).

В итоге самая первая асинхронная функция возвращает future-подобный объект, который ты передаёшь рантайму (а встроенного рантайма в стандартной библиотеке нет) и он запускает весь этот набор функций.

В расте у асинхронных функций есть огромный плюс - по умолчанию они возвращают impl Future<Output = ?>, а значит для использования асинхронщиный не нужно выделение памяти, как-как всё будет умещаться на стеке (что впрочем не мешает тебе вызов асинхронной функции отправить в кучу, чтобы например уменьшить размер future-объекта твоей функции, так-как иначе он будет разрастаться, что иногда нежелательно [1]).

Самый большой недостаток вытекает из этого самого преимущества - асинхронные функции нельзя определять в трейтах. Тут [2] написано об этом очень подробно. Там как раз и требуются аналоги "типов высших порядков" именуемые GAT. Недостаток можно обойти ценой аллокации при каждом вызове функции (т.е. будет возвращаться Pin<Box<dyn Future<Output = ?>>>), что и делают макросы async_trait (как я сказал выше разницы нет между асинхронной функцией и синхронной с future-подобным объектом, что эти макросы и используют).

Второй по величине недостаток (хотя с точки зрения юзабилити скорее первый) - это то, что стандартизирован только сам трейт Future, и помощники по работе с ним для создания рантайма. И больше ничего. То есть даже чтобы в асинхронной функции сделать таймер, нужно будет использовать специальную функцию рантайма, которая у каждого рантайма будет разной. В итоге на расте есть куча библиотек, который работают только на одном рантайме, а на любом другом не запустятся. А написать универсальную для любого рантайма библиотеку зачастую попросту невозможно и максимум что делают поддерживают два самых популярных рантайма (async-std и tokio),а всё остальное идёт лесом.

[1]: https://without.boats/blog/futures-and-segmented-stacks/
[2]: https://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-are-hard/

>>837580

> просто адрес на начало куска памяти

Уважаемый господин программист, давай не будем языковую семантику приплетать к работе железа, в каком нибудь эльбрусе например указатели представлены отдельным типом от данных, и передавая void^x ты передаешь не адрес на начало где то в памяти а полноценную информацию о куске памяти с данными или процедурой, просто потому что железо так устроено а высокоуровневый язык позволяет абстрагироваться от всей вот этой хуйни.

Так что давай говорить о конкретных вещах - например об объектах (экземплярах класса) со своими типизированными полями и виртуальными функциями, как в плюсах например запихать разные объекты в массив или передавать их функциям? - или превратить в указатель на непонятное нечто (void^x) или наследовать от некоего общего ( возможно абстрактного) класса:

class Any
{
private:
uint8_t type;
public:
Any(t) { type = t; };
~Any() {};
}

class MyObject : public Any
{
private:
int a, b;
public:
MyObject(int arg1, int arg2) : Any(0)
{
a = arg1; b = arg2;
};
~MyObject() {};
}

int myFoo(Any^x obj) {
switch(obj->type) {
case 0:
return (MyObject ^x)(obj)->a + (MyObjec t^x)(obj)->b;
// ...
}
}

Вот и вся твоя мета информация, в случае просто передачи void^x компилятор не может сразу назначить грузить определенные поля типа type, как в моем примере. А идея таких языков как раст или го (свиф вроде как jvm язык), в том чтобы избавится от malloc() и free() / destroy(), и оверхэд там связан только с рантайм библиотекой которая контролирует это дело, а не какими не метатипами. Нахрена тогда вообще язык типизированный, в том же джаваскрипте джит компилятор во время исполнения по входным аргументам определяет для каких типов функции / инструкции подставлять, но на то он и динамический язык.

>>837644

>в каком нибудь эльбрусе например указатели представлены отдельным типом от данных

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

>return (MyObject x)(obj)->a + (MyObjec tx)(obj)->b;

Поздравляю, ты только наговнокодил так, что:
а) это нереально расширять и поддерживать, а искать креши и битые данные после даже минимального рефакторинга будешь месяцами;
б) вырубил все возможные оптимизации компилятра;
в) а ввиду отсутствия прошлого пункта, без жирного гц в стиле жавы/дотнета, который бы дефрагментировал кучу и собирал такое поплотнее — максимально не cache-friendly код, который оказавшись в горячей точке будет дрочить память а не работать.
г) хоть это и пример, но даже в нём деструктор MyObject в 2/3 случаев тупо не будет вызываться и ты получишь 30 гб хипа ой)0

>Вот и вся твоя мета информация

Дружочек, ты обосрался. Раз уж тебе так нравится аппелировать к свифту, то давай посмотрим, как же вся метаинформация вмещается в 1 байт (у тебя в программе как полагается настоящему хэловорду же не может быть больше 255 типов, кекус):
https://ideone.com/7IoQmE

>T size: 4

>Any size: 32

https://godbolt.org/z/8Keoaz
Внезапна-внезапна, вытерев ноги об систему типов ты заставил компилятор забоксить значение (выделив память в куче, получив x2 размер объекта и как минимум ещё место под счетчик ссылок, которого нет в сырой структуре), а так же получил оверхед по памяти аж целых 3 указателя — на а) таблицу с конструкторами/деструкторами, б) виртуальную таблицу, в) таблицу типов (в которой хранятся: имена всех переменных и самого типа, как и в любом языке с рефлексией, а не 1 ебучий байт). Короче, получил полноценный жопаскрипт, всё как ты хотел.

>и оверхэд там связан только с рантайм библиотекой которая контролирует это дело, а не какими не метатипами

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

>Нахрена тогда вообще язык типизированный

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

> в том же джаваскрипте джит компилятор во время исполнения

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