Опрос о состоянии Rust 2020

Потом Карго и единый компилятор (в плюсах всё намешано-перемешано, приятно от этого уйти).

А можно более развёрнуто? От чего уйти хотели и что намешано?

Мой опыт с rust был противоположный: cargo для сборки проекта сам загружал откуда-то из интернет что-то и получалась мешанина из всяких маленьких зависимостей. Это сразу озадачило и напрягло. Ведь в C/C++ как раз есть компилятор, а я уж сам разберусь как и что мне в мой проект добавить и как собрать зависимости.

Вы не отличаете компилятор от системы сборки?

Ведь в C/C++ как раз есть компилятор

И в расте как раз есть компилятор. Называется rustc.

Вы не отличаете компилятор от системы сборки?

Я отличаю. А вы?

Это был ваш анонимный комментарий? Была же просьба развёрнутого ответа.

Но раз уж вы ответили, то расскажите, как вы собираете ваши проекты без cargo. С живыми примерами, пожалуйста.

Мы имеем четыре основных компилятора (да, мне нужны все эти ос):

• GCC (Линукс)
• MSVC (винда)
• Clang (Андроид)
• Apple Clang (iOS, Mac). Да-да, у него даже версии и список поддерживаемых функций отличаются

https://en.cppreference.com/w/cpp/compiler_support

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

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

Да, можно свести всё к Clang (msvc/clang, linux), но версия в ндк от этого быстрее не обновится, версия аппле на общую нумерацию не перейдет.

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

Пакетный менеджер? Зачем? Тру бородатый программист сам всё настроит, зачем какие-то менегеры выдумывать. Ну есть пара штук, но отсутствие там не делает твою либу несуществующей, а значит это необязательно и формально этого нет.

А что же Раст? Есть текущая стейбл версия, которую использует большинство. Ну или, возможно, чуть раньше, или ночнушка. В целом, небольшой +-, совершенно не критичный. Появилась новая фича? Доступна, можно активно использовать. На новый синтаксис async/await все переползли на удивление максимально быстро. Есть модули, активно используются, без них никак. Карго помогает подтянуть зависимости, без него сложно (но возможно). Можно завести либу разных версий в одном проекте без проблем. Это всё радует, поскольку не нужно тратить время на регулярную борьбу с зависимостями, а заниматься непосредственно бизнес-логикой. Но если вдруг встретится биндинг к сишной либе, то вновь привет, боль и страдания, особенно вне линукса. Растолибы собирать одно удовольствие, все мелкие зависимости без проблем подтягиваются, и резко не перестанут работать, поскольку подтягиваться будет нужная версия. Не говорю уже о самом языке и его удобствах (трейты, серде и т.п). И нет, дело не в безопасности, а в самом языке, его инфраструктуре, подходе.

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

Ручками, так же как и в Си. Или вы думаете cargo что-то магическое делает?

Ведь в C/C++ как раз есть компилятор, а я уж сам разберусь как и что мне в мой проект добавить и как собрать зависимости.

Можно еще и без VCS писать и делать ежедневные срезы кода в качестве бэкапов, а обмениваться кодом с помощью диффов по e-mail, но зачем? Уже есть Java с Maven и там решение зависимостей отлично работает. После этого подтянулся .Net. Свое костыльное решение предложил nodejs: его неприятно использовать (oneliner’ы в качестве «библиотек», куча ненужного хлама), и тем не менее, еле-еле, но работает.

И тут у нас есть C/C++ с его офигенной «экосистемой»… Вот честно, я так и не осилил сборку 64-битного wine. Даже в 32-битном у меня нет пары библиотек (FAudio, Vulkan и USB. Их нет в дистре и надо самому собирать из исходников), «разберусь как и что добавить сам» - ok, если вам не жалко своего времени (IIRC, у wine порядка 20 зависимостей). Использование cmake - боль, оно работает плохо, т.к. в разных дистрах dev-пакеты лежат в разных местах (и никто не обещает, что ваш дистр совпадет с дистром автора кода). И самое главное: нафига всё это? И с каждым новым пакетом нужно по-новой проходить этот ад… Почему нельзя ввести одну команду «build» и чтобы проект собрался?!

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

Или вы думаете cargo что-то магическое делает?

Магического конечно ничего он не делает, но он делает что-то, что нельзя легко и просто увидеть, понять и контролировать: лезет в интернет (куда-то) и загружает оттуда файлы (какие-то).

Сколько не задавался этот вопрос, ответ всегда ровно один и тот же. Да, ваш: «можно без cargo, но никто так никогда не лелал и не делает, ведь с ним удобней». Это не аргумент, а отмазка и просто брехня.

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

Вот честно, я так и не осилил сборку 64-битного wine

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

нельзя легко и просто увидеть, понять и контролировать

То есть make, cmake и co легко и понятно? Лул.

То есть make, cmake и co легко и понятно? Лул.

Имеено так.

Вы не устали демонстрировать глубины своей некомпетентности?

Про тред с бинарной арифметикой напомнить?

Имеено так.

Ну тогда откланиваюсь. Тут только в морг.

Про тред с бинарной арифметикой напомнить?

Не вижу ничего плохого в критике говнокода.

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

Всё это понятно и для этого всего делается много хороших и разных инструментов. Но разницу-то подходов вы улавливаете?

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

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

Ну тогда откланиваюсь.

Лоб не расшиби.

Не вижу ничего плохого в критике говнокода.

Вы уже в школе басню «мартышка и очки» проходили?

Магического конечно ничего он не делает, но он делает что-то, что нельзя легко и просто увидеть, понять и контролировать: лезет в интернет (куда-то) и загружает оттуда файлы (какие-то).

Было бы желание.

$ cargo --offline new --bin hello
$ cd hello
$ echo 'libc = "0.2.77"' >> Cargo.toml
$ cargo --offline generate-lockfile
$ grep -e name -e version -e source Cargo.lock
   name = "hello"
   version = "0.1.0"
   name = "libc"
   version = "0.2.77"
   source = "registry+https://github.com/rust-lang/crates.io-index"
$ wget 'https://github.com/rust-lang/crates.io-index/raw/master/config.json'
$ cat config.json 
   {
     "dl": "https://crates.io/api/v1/crates",
     "api": "https://crates.io"
   }
$ wget 'https://crates.io/api/v1/crates/libc/0.2.77/download' -O libc-0.2.77.crate
$ mv libc-0.2.77.crate ~/.cargo/registry/cache/github.com-1ecc6299db9ec823/
$ cargo --offline build -v

make, cmake и co легко и понятно? Лул.

Имеено так.

А ничего, что есть 100500 вариантов реализации make? Причём каждая со своими тараканами. Тот кто пробовал - знает, как «легко» сделать кроссплатформенную сборку на «чистом» make :))) Авторы того же cmake его запилили только потому, что «простой и понятный» make ниасилили. Штольман и Ко автотулсы свои также от нефиг делать написали.

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

а зачем без cargo?

Все они много хотяти атк бридж и карго без них работает на данный момент все

А ничего, что есть 100500 вариантов реализации make? Причём каждая со своими тараканами. Тот кто пробовал - знает, как «легко» сделать кроссплатформенную сборку на «чистом» make

Сразу видно, что ты не пробовал. Реализаций может быть сколько угодно, проблемы make с этим не связаны, ибо «кроссплатформенную сборку» ты даже в GNUMakefile не напишешь.

ибо «кроссплатформенную сборку» ты даже в GNUMakefile не напишешь.

Я писал GNUMakefile для Windows(msys и обычный cmd), Linux(Debian, Manjaro), FreeBSD, MacOS, OpenIndiana, OpenBSD, DragonFlyBSD, NetBSD, Haiku

Что там сложного?

ifeq ($(OS),Windows_NT)
    PLATFORM := $(shell uname 2>NUL; false)
    ifeq ($(findstring MINGW,$(PLATFORM)),MINGW)
        PLATFORM = "Mingw"
    else
        PLATFORM = "Windows"
    endif	
else
    PLATFORM = $(shell uname)
endif

Затем в зависимости от PLATFORM просто делаешь include где описан компилятор и все его флаги и все зависимости и как их находить(то есть обычный не кроссплатформенный makefile)

include mk/haiku_clang.mk

или 

include mk/dragonfly_gcc.mk

cargo все равно удобнее :D до карго даже конан не дотягивает пока.

cargo это вообще единственное, что есть годного в раст.

Что там сложного?

Ты сам же и показал, что сложно.

ifeq ($(OS),Windows_NT)

$(OS)

Код для дефайна OS ты не привёл. Нет, в GNU make нет такого.

PLATFORM := $(shell uname 2>NUL; false)

shell uname

Я писал GNUMakefile для Windows(msys и обычный cmd)

4.2

Уже плохо. Но для полноты картины можно ещё написать поиск библиотек, компилятора, получение версии компилятора, диспатч по флагам для release/debug сборок, подключение библиотеки к сборке, пересборку при передаче пользователем дополнительных флагов(и сам механизм передачи, кстати) и, конечно же, установку собранного на хост. Написать в принципе можно. Но не нужно.

Код для дефайна OS ты не привёл.

В Windows NT по-умолчанию такой дефайн есть. Так я нахожу Windows это или нет. В Debian и Haiku такого дефайна в env нет…

uname в msys есть, а в Windows cmd нет. Я перенаправил сообщение об ошибке в Windows /dev/null, чтобы при запуске make в cmd никаких ошибок не показывалось

https://imgur.com/a/62VGW2x

В Windows NT по-умолчанию такой дефайн есть

ok.

uname в msys есть, а в Windows cmd нет

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

Кстати, недавно увидел результаты какого-то опроса для С++ программистов.

«Какую систему сборки вы используете?»

https://i.imgur.com/gWLozRS.png

Многие названия прочитал в первый раз :)

и make довольно высоко держится :)

Исходники linker Microsoft имеются в сети?

и make довольно высоко держится

Это потому, что из CMake генерится makefile и потом собирается make-ом. Другой вариант, генерить build.ninja. Не думаю, что кто-то руками ninja файлы пишет. А если посмотреть на гистограмму, там make+ninja~=CMake.

Отвечу иначе: https://github.com/google/cargo-raze

И да, оно вызывает rustc напрямую: https://github.com/google/cargo-raze#why-not-build-directly-with-cargo--why-g...

оно кое-как, но будет работать. Но здесь слишком много телодвижений и сложность именно в этом

enjoy your C++. и си-подобные.

портировал намедни LambdaMOO под winsock. ну как бы есть старый WinMOO под 1.8.0, но тут уже 1.8.3+ в транке с уникодом.

а ещё winsock 2.0 с асинхронностями бывает.

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

в итоге код на Сишечке (без ++, емнип) – костыли вокруг #define-ов (если msys и mingw, тогда winsock, и т.п.). если win32 то … если win64 то … если msvc (ну тут вроде без особенностей обошлось, собирается обеими).

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

не, оно конечно всё допиливается. и даже работает, портированное-то. куда оно денется.

но как-то — неаккуратненько. только ткни – сразу сломается.

ради хохмы, наткнулся на какой-то инсталлятор на powershell, и увидет там вебсервер в три строчки вокруг HttpListener. наколбасил под кураж свой недоMOO на сисярпе вокруг TcpListener за пару часов (а тот порт дня три допиливал, на няшной сишечке).

теперь вот думаю переписать ещё раз – на аде и пони, а затем на расте. с task-ами, с акторами и с lend/borrow и lock-free телнет-сервером с асинхронщиной.

ради хохмы.

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

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

то зачем нужен первый хрупкий язык. и этот ваш С++ впридачу, ога.

ну это как в жабе есть ant (аналог make, ninja) а есть maven, gradle. где можно сказать mvn achetype create helloworld или как-то там. и он тебе сам болванку-макет наболванит и все зависимости выкачает. а потом одной командой можно обновить все зависимости, выкачав новые. автомагически, а не прописывать статически старые версии библиотек в своём дереве.