Ü (Programmiersprache) (75 стр)

1 frag / 2 deaths
> Кора 3500. 4 гига оперативы
Жесть, а нафига ты с этим компом вообще сидишь щас? Щас с 4 ГБ вообще мука же полная...

Vlad2001_MFS
А что не так с 4 гигами? Я даже Етернал Дум прошёл спокойно. Браузер не закрываю даже.
Прям щас загрузка памяти 45%, это с открытым ВСКодом. Могу ещё Старкрафт-2 в альт-табе держать.
Нахрена мне больше?

1 frag / 2 deaths
А у тебя SSD или нет?
Честно говоря, не думал, что щас с 4 ГБ можно быть более-менее адекватная жизнь.

Vlad2001_MFS
HDD на 460 гигов (не хватает). Ещё лиса капец долго прогружается
Стоп, я нагнал, у меня 8 гигов

Panzerschrek[CN]
> Свой то код каждая система соберёт.
Но ведь это и есть основная задача системы сборки, покрывающая абсолютное большинство кейсов. Пользователи языка в основной массе собирают код именно на этом языке, а не прикручивают другие языки биндинг соплями. Под этот основной сценарий системы сборки и заточены. Мой пойнт в том, что тот же Cargo спроектирован и реализован достаточно годно, поэтому его можно использовать как пример для Ü. А вот зоопарк разношерстных костылей в С/С++ - это наоборот отличный пример, как делать не надо. Чего стоит только анальное шапито с автотулзами под виндой, таскание многогигабайтных скомпиленных бинарей прямо в гит репозиториях, говноскриптинг на процедурном высере CMake и прочие прелести.

> А вот что-то окромя прикручиваться будет со скрипом.
Падажжи, это уже проблемы конкретных реализаций FFI в конкретных языках. Причем тут системы сборки? За го и раст не скажу, но к джаве и питону биндинги писать приходилось. Все как и везде - C ABI как наименьший общий знаменатель, ручное написание сишных оберток или генерация оных через какой-нибудь SWIG. Не фонтан конечно, но со скрипом сделать можно.

Ну хорошо, а что ты предлагаешь вместо этого? Если Go или Rust в этой системе заменить на Ü, станет ли сборка проще? Можно ли собрать произвольную С++ библиотеку и использовать ее в Ü без написания оберток или использования генераторов биндингов? Какие С++ компиляторы поддерживаются? Как обстоят дела с биндингом шаблонных классов, ну хотя бы базовых std::vector, std::map, std::unique_ptr, std::shared_ptr?

1 frag / 2 deaths
> Кора 3500. 4 гига оперативы
> Стоп, я нагнал, у меня 8 гигов
Хм, у меня когда-то был похожий сетап (i5 3550, 16 Гб), но прямо жестких фризов в вскоде никогда не замечал. Сейчас по работе пользуюсь пачкой электрон приложений вроде Teams, но и с ними нет особых проблем, не считая традиционной для электрона неотзывчивости UI и отсутствия 60 фпс рендеринга. Кулстори про жуткие лаги и фризы GC слышу в основном от С/C++ разработчиков, которые этот самый GC видели разве что на картинках.

Но ты уже конечно все отпрофилировал и однозначно установил виновника трагедии, ведь так? Это именно GC. Не свапы на сыпящийся HDD. Не проблемы рендеринга сложнейшего браузерного движка. Это именно говносборщик и только он.

std::noob
> тот же Cargo спроектирован и реализован достаточно годно,
Нет.
Для простеньких проектов он подходит, а если нужно что-то сложное городить, выясняется, что он не гибок и местами туп.
CMake в этом плане гораздо лучше. Он вообще, тьюринг-полный и в нём есть возможность легко запускать произвольные команды.

> Чего стоит только анальное шапито с автотулзами под виндой
Да, autotools - адовы костыль. Но есть же CMake.

> многогигабайтных скомпиленных бинарей прямо в гит репозиториях
А это тут вообще при чём? Не клади бинари под систему контроля версий.

> Падажжи, это уже проблемы конкретных реализаций FFI в конкретных языках. Причем тут системы сборки?
Сложно компилятор альтернативного языка во всех этих системах сборки запускать.
Конкретно в cargo вообще весело с цеплянием статических крестобиблиотек. Возможность указывать нужные флаги компоновки не завезли. Вместо этого Cargo пытается угадать нужные флаги и зависимости от стандартной библиотеки C++.

> Все как и везде - C ABI как наименьший общий знаменатель, ручное написание сишных оберток или генерация оных
Ну как раз в этом проблем нету.

> Можно ли собрать произвольную С++ библиотеку и использовать ее в Ü без написания оберток или использования генераторов биндингов?
Нет конечно. Биндинги написать придётся.

> Как обстоят дела с биндингом шаблонных классов, ну хотя бы базовых std::vector
Какие ещё шаблонные классы? В межъязыковом взаимодействии только голый Си может быть или что-то ему подобное.

Panzerschrek[CN]
> CMake в этом плане гораздо лучше. Он вообще, тьюринг-полный и в нём есть
> возможность легко запускать произвольные команды.
CMake - лютое дерьмище, недалеко ушедшее от автотулзов. Навскидку опыт использования CMake в больших проектах:
- Примитивный процедурный язык без ООП в худших традициях юникс шелл скриптов.
- Большинство разработчиков на С/C++ прекрасно понимают бесполезность и бесперспективность глубокого изучения этого языка, т.к. вне скриптов сборки он больше нигде не нужен. Поэтому изучают его по минимуму, выдавая уродливые высеры ужасающего качества, намного хуже основного С++ кода.
- CMake где-то после версии 3.0 распался на две части - устаревший диалект и так называемый Modern CMake. При этом интернет и SO по прежнему заполнены советами и туториалами по устаревшему хламу, разработчики беспорядочно тащат оттуда куски устаревшего и современного кода вперемешку, превращая скрипты сборки в еще большую кашу.
- Нет встроенного пакетного менеджера, в результате чего скачивание и компиляция зависимостей превращается в боль и страдания. Cargo с репозиторием крейтов просто на световые годы впереди. Впрочем это проблема С++ вообще, а не только CMake.
- Тьюринг-полный язык это скорее недостаток, чем преимущество. Нужен он в основном как костыль в отсутствие пакетного менеджера, чтобы скриптовать поиск и подключение сторонних библиотек. При наличии вменяемого менеджмента пакетов необходимость в тьюринг-полном языке резко уменьшается, становится достаточно декларативного манифеста + билд скриптов на том же самом языке для особых случаев. В Cargo эти билд скрипты пишут на самом расте, а не на левом велосипедном говноязыке типа CMake. Тоже плюсик в карму Cargo.
- Применение тьюринг-полного языка вместо фиксированных форматов проекта типа JSON/XML/TOML сильно ограничивает возможность создания нормальной гуйни для настроек сборки в IDE. Уже нельзя просто так открыть гуи окошко в IDE, натыкать там настройки компилятора/линкера и сохранить в XML, как это делает студия для обычных non-CMake проектов.

CMake стал более-менее популярен только потому, что крестокомьюнити за все эти годы так и не смогло выпердеть хоть сколько нибудь вменяемую систему сборки. dds и build2 сильно далеки от практического применения. Намного лучше ориентироваться на современные системы сборки типа Cargo, а не копировать худшие практики из С++. Ну мое дело предложить в общем :)

> А это тут вообще при чём? Не клади бинари под систему контроля версий.
Это я про отсутствие пакетного менеджера, в результате чего большинство крестовиков по статистике заталкивают сорцы сторонних библиотек или скомпиленные бинари себе в исходники. Советую не делать так в Ü, это очень-очень плохо. Лучше сделай пакетный менеджер.

> Сложно компилятор альтернативного языка во всех этих системах сборки запускать.
А, понял. Т.е. основные претензии заключаются в том, что в Cargo недоработано подключение крестобиблиотек. А если бы в Cargo.toml были бы припасены готовые опции для безгеморройного подключения крестобиблиотек на все случаи жизни, то претензий бы не было?)

std::noob
> Не проблемы рендеринга сложнейшего браузерного движка.
Это шутка?

std::noob
> Не свапы на сыпящийся HDD.
Которые так лагают только на ВСКоде. Совпадение? Не думаю.

std::noob
> Примитивный процедурный язык без ООП в худших традициях юникс шелл скриптов
В этом и фишка. Тупой скриптовый язык. Выучить его можно за 10 минут.

> Нет встроенного пакетного менеджера
И это хорошо. Пакетный менеджер и сборщик это разные сущности, не надо всё в одну кучу тащить.

> Тьюринг-полный язык это скорее недостаток, чем преимущество
Это больше возможностей.
В тупом декларативном Cargo.toml я не могу сделать банальщины, вроде вычитывания каких-то параметров из переменных окружения.

> сильно ограничивает возможность создания нормальной гуйни для настроек сборки в IDE
Да и не нужна ваша гуйня для настройки проектов. Файлы проекта должны быть написаны человеком, чтобы можно было нормальный review делать.

> это очень-очень плохо
Это нормальный подход, когда нужна стабильность окружения. У тебя не отвалится сборка, если кто-то отзовёт пакет в репозитории или сломает его. У тебя не отвалится подтягивание зависимостей, если завтра какой-нибудь РосКомНадзор заблокирует адрес центрального репозитория.

В целом я не против централизированных репозиториев для библиотек. Но использовать их надо более аккуратно.

> А если бы в Cargo.toml были бы припасены готовые опции для безгеморройного подключения крестобиблиотек на все случаи жизни, то претензий бы не было?
Это лишь одна проблема, с которой я столкнулся. Проблем бы не было, если был бы удобный механизм для расширения системы сборки. в Cmake для этого есть add_custom_command, например.

std::noob
> Нет встроенного пакетного менеджера, в результате чего скачивание и компиляция
> зависимостей превращается в боль и страдания.
Все зависимости надо пихать в один проект, чтоб у пользователей не было боли от их скачивания и подключения.
А то есть проекты, которые надо несколько дней настраивать чтоб скомпилировать.
К тому же не везде указаны версии и приходится использовать бинарный поиск по комитам, чтоб найти рабочую версию для каждой из зависимостей.

Кстати, универсальная система сборки - это, на самом деле, уже решённая проблема. Потому что есть Nix.

Имбирная Ведьмочка
> Кстати, универсальная система сборки - это, на самом деле, уже решённая
> проблема. Потому что есть Nix.
https://nixos.org/manual/nix/stable/#portability

Фатальный недостаток.

Инкрементальная сборка? Не, не слышали, пересобирай всё целиком.

Имбирная Ведьмочка
Если есть желание, заведи отдельную тему, там эту штуку обсудим.

1 frag / 2 deaths
> > Не проблемы рендеринга сложнейшего браузерного движка.
> Это шутка?
Ни разу. Перебираю варианты проблем для твоего патологического случая. Возможных причин зависаний на самом деле может быть много. Но у тебя уже заранее назначен виновный - GC. Кошка бросила котят - говносборщик виноват.

> Которые так лагают только на ВСКоде. Совпадение? Не думаю.
Ну бида-бида, что еще могу сказать. На твоем железе вскод в теории должен без проблем работать. Если есть желание, то надо разбираться в проблеме, удалив все расширения, вычистив конфиги и переустановив вскод с нуля. Ну или вообще забить.

Panzerschrek[CN]
> В этом и фишка. Тупой скриптовый язык. Выучить его можно за 10 минут.
И потом неделями ковыряться в уродских командах с 100500 параметрами. Очень удобно, угу. Семидесятыми так и пахнуло, ООП еще не изобрели, крестовики дружно ковыряются в процедурном высере.

> Это нормальный подход, когда нужна стабильность окружения. У тебя не отвалится сборка, если кто-то отзовёт пакет в репозитории или сломает его. У тебя не отвалится подтягивание зависимостей, если завтра какой-нибудь РосКомНадзор заблокирует адрес центрального репозитория.

Здесь да, согласен, может быть такая необходимость. Кому надо, те используют вендоринг зависимостей, пакетные менеджеры это позволяют. Ну а большинству в общем-то плевать. Сколько было крупных сбоев в репозиториях за последние 5-6 лет, со времен лефтпада?

> Проблем бы не было, если был бы удобный механизм для расширения системы сборки. в Cmake для этого есть add_custom_command, например.

Я конечно сварщик ненастоящий, но чем build.rs то не устраивает? Пересборка по умолчанию делается только при изменении файлов в каталоге пакета, наподобие DEPENDS в add_custom_command.

/A\
> Все зависимости надо пихать в один проект, чтоб у пользователей не было боли от
> их скачивания и подключения.
Да, это один из вариантов. Видел проекты, где создавали солюшены студии специально для зависимостей, качали в какую-нибудь папку, канпеляли, а потом подкладывали куда надо в основной солюшен. В других проектах скомпиленные бинари заталкивали прямо в гит репозиторий. Особенно забавно выглядели несколько копий культей под разные платформы весом в несколько гигов. Но все это разумеется дичайшие костыли из-за отсутствия пакетного менеджера в С++.

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

class A interface
{
  type I= i8;
}
class B interface
{
  type I= i16;
}
class C polymorph
{
  type I= i32;
}
class D : A, B, C {}
type I= D::I; // Какой "I" тут должен быть?

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