Во-первых, там используется save-analysis, т.е. сначала проект компилится полностью, часть внутренних структур данных компилятора дампается, и по ним уже RLS лазит. Что тут плохого - проект нужно полностью перекомпилировать при любом изменении, чтоб RLS'ом получить актуальные данные, и это охренеть как долго. Мб инкрементальная компиляция поможет, но это и есть одно из тех самых "изменений архитектуры", что необходимы RLS. И пилят это довольно долго. И все равно это будет медленно, пока save-analysis не отпилят полностью. Во-вторых, компилятор очень плохо работает с кодом, который не компилится. Если поломан синтакисис - то вообще giving up. Это причина, почему в RLS комплишен до сих пор через racer, ибо комплишн - это почти всегда "поломанный синтаксис". У нас с самого начала все пилится с учетом IDE'шных требований. Парсер умеет восстанавливаться на поломанном синтаксисе, типы нормально выводятся на незавершенных выражениях, и т.п. Ну и перфоманс - компилится только открытая в IDE вкладка. Зачем весь проект компилить? Ну и подобным подходам уже с десяток лет, в остальных JetBrains IDE примерно так же все работает. И практически для всех языков мы заново компилятор писали. Исключения я пока 2 знаю - это, во-первых, kotlin (для которого мы сами компилятор и писали, лол), во-вторых C#. С C# близко не знаком, хз как так вышло

Кстати, сам я точно не знаю, но по слухам комплишн у нас уже гораздо лучше, чем в RLS

@vlad20012 затри ему за идею чо ты

Clion, Idea очень хорошие IDE. Особенно после Qt Creator, Clion очень меня впечатлил. Но как-то не фешуйно писать свои велосипеды вместо того, чтобы развивать существующие решения.

Clion, Idea очень хорошие IDE. Особенно после Qt Creator, Clion очень меня впечатлил. Но как-то не фешуйно писать свои велосипеды вместо того, чтобы развивать существующие решения.

Существующие решения пытаются костылить поверх решений которые под другие задачи создавались

Вообще я допускаю, что как long-term solution идея RLS очень хороша. Просто я не верю, что они ее допилят раньше, чем года через 3

Т.е. ну это нужно переписать весь компилятор. Начиная с libsyntax, если что

А нам как-то проще свою инфраструктуру использовать для создания компилятора для IDE. Тот же Grammar Kit

конкуренция это обычно хорошо для прогресса :)

конкуренция это обычно хорошо для прогресса :)

О, какие люди! :)

и тебе привет :) я хоть и болею за RLS, но слежу что крутого мелькает в https://intellij-rust.github.io/thisweek :)

Автодополнение Cargo.toml выглядит удобно, блин: https://i.imgur.com/D7CYVsa.png

FPConf 2017. Интервью с Денисом Шевченко https://habrahabr.ru/post/342470/

Автодополнение Cargo.toml выглядит удобно, блин: https://i.imgur.com/D7CYVsa.png

Там в последнем ченжлоге продолбали главную фичу - фот это заехало https://github.com/intellij-rust/intellij-rust/pull/1773

let a: String = Default::default(); Резолвится default на конкретный импл теперь

👍 и правда солидная штука

Fearless concurrency in Firefox Quantum https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html

Это единственный развивающийся плагин для раста

Тогда понятно чё у тебя не падал

Rust & socks5. Кто нибудь сталкивался?

https://github.com/tokio-rs/tokio-socks5

https://github.com/tokio-rs/tokio-socks5

Мне нужно подключиться к фтп серверу через socks5, эта библиотека поможет?

И спасибо

Ну уточняй что недо :)

https://docs.rs/socks/0.2.3/socks/struct.Socks5Stream.html

Если найдешь реализацию ftp клиента, который принимает Read+Write в качестве стрима

То можно пользоваться

Ан, нет

Есть into_inner() -> TcpStream

Так что можно юзать с любым ftp-клиентом по идее

Который принимает TcpSocket

тцп сокет из токио

Спасибо, покурю

тцп сокет из токио

Клиента можно и без токио, асинхронные клиенты в целом почти не упёрлись

Всмысле не уперлось?

В прямом.

Что такое прямой смысл в твоей фразе

Слишком старый сленг, понял

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

На клиенте подключений обычно не много

И трахаться с токио когда нужно просто скачать файлик с фтп — чутка не целесообразно

Другое дело если ты пишешь фтп-сервер

Я вообще думал что там просто тцп стрим из Токио, который по дефолту немного другой. А теперь увидел что они как-то возвращают обычный

Во втором крейте вообще нет токио

А тю, это разные крейты

Ты меня обманул короче

Я думал то дока из первого

Кстати, недавно видел классный подход: либа-сервер принимает в конвтруктор структуры Server обычные stdlib'овские TcpStream и UdpSocket и сама оборачивает их в токиевкие + свой же ивентлуп

В плане API копец удобно

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

(

Прости

Кстати, недавно видел классный подход: либа-сервер принимает в конвтруктор структуры Server обычные stdlib'овские TcpStream и UdpSocket и сама оборачивает их в токиевкие + свой же ивентлуп

К этому еще добавить возможность констрактить со своим ивентлупом и токиостримами и это был бы идеальный API

Да, только вопрос, можно ли клонить тцп стрим?

Нельзя

Только через ансейф

Теоретически))

Ну виндусы не нужны

По этому всё ок

Для винды тож есть вариант

ПРосто трейт другой

Вообще при !Sync почемуб и не дать возможность клонить

Не понятно

https://doc.rust-lang.org/std/net/struct.TcpStream.html#method.try_clone

Отлично

Ток в найтли пока

Или...

Стоп

Че за костыль

Это ж метод

А, да, я с TryFrom путаю

Ну типа пока нет трай клона, нужно как-то жить

TryClone вообще есть разве как трейт?

Вообще если есть клон, то кидать в токиевский не сильно безопасно

Нету

Rfc был

Вообще если есть клон, то кидать в токиевский не сильно безопасно

Почему?

Ну ты будешь делать врайты, а тебе непонятные "вудблоки"

Потому что может быть гонка на сокете, сам спросил — сам ответил

Ну это понятно

Ну ты будешь делать врайты, а тебе непонятные "вудблоки"

Ну да, это тоже

Но это не большая проблема — это сразу будет видно