Но я во даже не могу представить реальную нужность и полезность переписывать на раст.

Так вы и не программист. Вырастишь - поймёшь. (с)

Но я во даже не могу представить реальную нужность и полезность переписывать на раст.

Я соглашусь с переписыванием. Надо делать по новому, лучше, идиоматично

Пока стабильного ABI не завезли, большого смысла переписывать готовые системные либы нет. А вот когда завезут, тогда определенно будет. Папралельно с сишными символами экспортировать из dll-ки бохатые растоабстракции

В Расте все вкомпиливают в бинарь. Как-то это сходило с рук пока-что, даже со всякими большими вещами вроде Tokio. Надо бы исследовать, стоит ли игра свеч с этими shared библиотеками, или проблем можно решить по другому. Вполне может оказаться что все это пришло с эпохи флоппи дисков. Для остального хватит dbus и opengl

Для системщины есть C-API. См. librsvg.

Я хз как дин. линковка работает с lto и подобным. Поэтому лучше статика.

Автор xi недавно плакался, что у него по 15 минут компилится. Распиливание на шаред либы думаю спасло бы положение

Пора бы уже применять какие-то меры за неуважение к Ъ.

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

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

А если это прямо мажорные версии, так и с shared библиотеками они не совместимы.

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

Для системщины есть C-API

Архаика. Давно пора научиться экспортировать что-то сложнее функций с неизвестными аргументами

Или можно просто пофиксить компиляцию. В идеале при изменении одного файла должна быть минимальная пересборка и линковка. Не может это быть 15 мин

COM? :)

Между процессами уже давно есть DBus. Плюс интересно как вот это взлетит

https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md

Если взлетит, будем Python+C+Rust+JS клеить не глядя

Кстати, слака, Flatpack, AppImage, snapd, docker, Go - все гоняют жирноблобы со всем что нужно и ничего, все живы. Максимум там во Flatpack что-то дергаются по поводу Platform. Вот такой тренд. Никто не хочет ввязываться в это дерьмо с so

https://github.com/WebAssembly/interface-types/blob/master/proposals/interfac...

Как-раз вот эту штуку хотел привести на последующие аргументы :)

Я бы вот совсем не против Васи на десктопе. При установке пусть верифицируется, собирается в натив под конкретный проц и гоняется в нативном сендбоксе. На андроиде уже много лет так, только с джавой.

Никто не хочет ввязываться в это дерьмо с so

В основном из-за того, что реализация дерьмовая. Замучаешься биндиться на эти сишные кишки

Мигелюшка

Он ещё жив?

Так вы и не программист. Вырастишь - поймёшь. (с)

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

flatpack уже научился в системную тему? Дин. линковка ему не помогла.

Тем более во времена, когда каждый тащит свой электрон.

Не, wasm/wasi узкоограниченное говно. Я про сам формат interface types. Ничто же не мешает реализовать его в одной из секций ELF?

К чему аргумент? Системную тему вполне можно поддерживать при полной статической линковке. По моему это просто банальный баг

:D

Кстати, осталось 9 дней до async/await в стейбле, покайтесь.

I am going to embrace this new world with open arms!

У кого есть акк в твиттере - переспросите его, а с какими руками он его планирует расширить и изничтожить?

Пора начать читать Rust Book. А то сложно изображать иксперта вообще не разбираясь в вопросе )

Да вот затаились ждем, не портим себе аппетит всякими beta/nightly.

Вообще после async/await клянусь никогда не ставить nightly

В стабильном еще доолго async-методы в трейтах не сможешь писать

http://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-ar...

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

То есть, алокаторы в расте вшиваются в либу и приложение отдельно. В си и плюсах было бы по-другому.

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

То есть, алокаторы в расте вшиваются в либу и приложение

Странная фигня для системного языка

Там выше написал. Если соблюдается сишное API, то глубоко без разницы.

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

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

Это да.
К примеру в Visual Studio использование одних и тех же библиотек, но из разных версий «чревато».
В т.ч. из-за аллокаторов.

Немного наврал. Для сишного API тоже важно, чтобы объект удалили из того модуля, откуда вызвали. Ох, уж эта системщина...

К примеру в Visual Studio использование одних и тех же библиотек, но из разных версий «чревато».

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

Java

Из-за этого у меня в «Установке и удалении програм» штук 10 версий vc runtime?

Для сишного API тоже важно, чтобы объект удалили из того модуля, откуда вызвали.

Да.
Впрочем много нюансов ...

Из-за этого у меня в «Установке и удалении програм» штук 10 версий vc runtime?

Ну да.
Если программа собрана с использование Visual Studio 6, то ей нужно «скормить», соответствующий run-time.

Владимир

У меня всегда все run-time установлены /архивов с набором run-time в inet полно/.

А вот разработку веду кроссплатформенную /нет ни каких зависимостей от Windows/.

Или не искать ничьи сборки, а просто пользоваться менеджером пакетов:

choco install vcredist-all

https://chocolatey.org/packages/vcredist-all

Не использую /просто необходимости нет/.
C++ использую только в то случае если мне нужен какой-то, отсутствующий где либо API + свои велосипеды.
К примеру для работы с mxl 1С пришлось разработать API, ...

всеобщая вера в то, что shared библиотеки решают проблему потребления памяти и диска

Так ведь действительно решает. Можно между процессами шарить страницы одинакового кода.

Visual Studio 6

Вот как раз таки для VC6 никакой рантайм не нужен. Он есть в составе самого оффтопика.

И я очень жалею, что штудии свежее так не могут.

Никто не хочет ввязываться в это дерьмо с so

диды ушли на пенсию, а молодёжь (лет до 40 включительно) в со уже и не умеет

Вот как раз таки для VC6 никакой рантайм не нужен. Он есть в составе самого оффтопика.

Да может быть и так.
Использовал все версии Visual Studio.
Остановился на 13-й.
Хватает на все 100%, а гонку за стандартами пусть используют «теоретики».

Кстати, слака, Flatpack, AppImage, snapd, docker, Go - все гоняют жирноблобы со всем что нужно

Зачем ты все это в кучу свалил? Релевантно здесь только го, но на нем пишут микросервисы, там разумно иметь самодостаточный микроблоб. На расте пишут пока хелловорлды, и то уже огребают проблемы с долгой компиляцией. Как вы собираетесь делать системные либы без so неясно. Хотя ясно, что вы не собираетесь. Это очередной говноклей.

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

Системную тему вполне можно поддерживать при полной статической линковке.

Нельзя. Ибо нужно линковаться с либами. Как минимум в KDE.