resvg 0.7 — библиотека отрисовки SVG

Сравнение с Си некорректно. Нужно сравнивать с C++.

Оценивать весь язык по одной либе - как минимум глупо.

Почему? Либа - это тебе не академический, спецом подогнанный под тесты и метрики проект. Тут показывается реальное использование языка, а не хеллуворлды.

Советую ознакомиться с основами статистики.

Василий Иванович ест мясо, Анка ест рис, Петька ест капусту - по статистике все трое едят голубцы. Лучше поясни, почему по реальному проекту НЕЛЬЗЯ говорить об используем там языке (щито? Как это?) и причем тут статистика? Не, я понимаю, как разраб, что после мучительных написания и отладки кода, будешь как утёнок, чем угодно аргументировать свой выбор стека, но всё-таки?

Извращение в стиле C->Rust->C. Не надо.

Предоставь статистику использования Rust в мире по всем областям IT.

У меня приложение на Qt. Зачем мне вызывать твою библиотеку, которая будет использовать backend-qt чтобы отобразить, если я могу сразу вызвать QtSVG без плясок с конвертацией между языками?!

Пока не будет переписаны на раст хотя бы 51% всего софта созданного за 30 лет на С/C++, особенно базового, Rust можно закапывать, да хоть уже сейчас.

Для тебя это религия, для меня это просто еще один язык с которым можно немного мозги свои проветрить воскресным утром.

Если закрыть глаза на то, что QtSvg чуть менее чем полностью уныл - то да, смысла нет.

Не стоит навешивать на меня ярлыки, прикрывая этим свой унылый троллинг.

Ошибку в новости лучше поправь, вместо того, чтобы уныло сраться про rust vs. Not rust

При чём тут моя либа? Речь шла про librsvg. Если автор решил набрать 100500 зависимостей, которые раздули сборку, то это проблема автора, а не языка.

Очередной виртуал будет мне рассказывать что делать.

Не при чем. Просто дана сравнительная таблица ресурсов при компиляции для разных версий - на си и на расте. Разница в 11 минут времени и более 1.2 гига по кэшу...впечатляет.

Если автор решил набрать 100500 зависимостей

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

Очередной виртуал будет мне рассказывать что делать.

Бедный Пьер, как только его не называли. Жаль, что из-за неграмотных НЕвиртуалов, у которых все враги, особенно те, кто не прыгает с щенячьми восторгом, он в гробу вертится - таки заслужил человек покоя, полноценную предметную область построения кривых все-таки разработал.

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

А зачем в каждой второй строчке упоминать, что написано на Rust? Я вот уже который тред никак не могу понять, зачем так пишут.

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

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

Я даже не знаю, тонко это или толсто.

Мне казалось, что там будет тот же результат что и в хроме. Нет?

Ну это только при двух условиях: 1) набор поддерживаемых фич в движках совпадает (ну там всякие новомодные SVG2) и 2) в моем коде отрисовки нет багов (один ты мне уже репортил, я его кстати починил)

Кому надо - соберёт сам.

Тоже верно. Но пихать resvg даже в «условные» зависимости становится резко неинтересно.

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

Да мне плевать, на чём оно написано и как, если оно, исходя из новости (ибо я не полезу в код на расте, так как не умею в него), по фичам лучше конкурентной библиотеки. А учитывая, как криво рендерит гномовская rsvg, я готов сменить её на что угодно, так как улучшений там и не предвидится.

Меняет и очень многое. И не вижу проблемы в использовании unsafe.

Предположим, есть заковыристая либа на расте без unsafe. Затем создаю небольшую производную либу тоже на расте, но с сишными хедерами для интеграции с языком си, например, чтобы из питона вызывать раст и вызывать сам питоний код из раста. Что плохого в том, что в промежуточной растовской либе будет много unsafe, если весь основной код работает и написан на «безопасном» расте?

Или если ты захотел использовать MPI из раста. Тебе нужна все равно прослойка с unsafe, хотя сам основной код тоже может быть на безопасном расте.

Могут быть и другие примеры.

Тогда зачем нужен этот язык?

Чтобы уменьшить объём потенциальных ошибок работы с памятью?

Чтобы дать реализацию современных практик C++ без оглядки на legacy?

Как связаны libc и lazy_static, bitflags?

Это связка означает что ты пишешь на старом Си, а раст тут чисто название...

Я имел в виду, как lazy_static и bitflags связаны с Си?

Можно, но программистам лень

Вот как раз не совсем и лень. Постоянно появляются все новые и новые 100%-растовые клоны сишных либ. Другое дело, что функционалом они зачастую не блещут и бедным узерам приходится от них отказыватся в пользу старых добрых биндингов.

Тут показывается реальное использование языка, а не хеллуворлды.

Например для С++ по коду boost будем оценивать типичный прикладной код :)

без плясок с конвертацией между языками

Все пляски с конвертацией остаются в исходном коде. В машинном коде библиотеки никаких конвертаций нет и этот код мало отличается от кода скомпилированного тем же с++.

Можно будет потыкать на досуге.

в моем коде отрисовки нет багов

А в хроме есть?

Только если мы говорим про линукс. Вон openshot использует и не парится.

4.2

Обычно в подобные проекты зависимости просто так не добавляют

Святая наивность. Конечно же, сишники все примерные мальчики.

А в хроме есть?

Теоретически тоже могут быть

Пока не будет переписаны на раст хотя бы 51% всего софта созданного за 30 лет на С/C++, особенно базового, Rust можно закапывать,

Пока на лор не перейдут хотя бы 51% всех пользователей хабра/опеннет особенно анонимусы, лор можно закапывать,

Исправил.

Артефактов и падений ни разу не видел. Ни у хрома, ни у лисы. Там с этим серьезно всё. С поддержкой стандарта же - так себе.

А у тебя авторский набор тестов, да? Я пожалуй к себе заимпорчу, отдельный тест на каждую фичу и корнер-кейсы - это хорошо

В смысле авторский? Самописный? Тогда да. Test suite весь под MIT, поэтому можно делать что угодно.

...если я могу сразу вызвать QtSVG

...и получить кривой и неполный рендеринг.

rust и есть по большому счету С с альтернативным синтаксисом и синтаксическим транслятором фронтэндом к llvm. Исторически так сложилось что $defaultname язык это С. Было бы глупо переписывать библиотеки на rust тратя на это время если вы можете легко их использовать оборачивая в свой rust-безопасный мирок. Подумайте над тем что вы написали, если бы с выходом каждого языка мы бы все переписывали на новый язык это было бы полным фиаско учитывая что в итоге вы бы получали такие же статически или динамически связываемые библиотеки, смысл?

Это как это ты обернешь сишный код в расте? Через unsafe, что ли? Так что либо переписывать на расте, либо пользоваться небезопасными библиотеками. По другому никак.

Это как это ты обернешь сишный код в расте? Через unsafe, что ли?

Rust не ява с шарпом unsafe для околосиситемного языка это нормально.

Я понимаю к чему вы клоните, к тому что народ продолжает юзать функционал С, ну так и С++($аny_language_name) продолжает так что туше.

Свой код ты пишешь на обычном rust, любой код который вы получаете в виде библиотеки для связывания можно считать «небезопасным», какая мне разница был он собран из rust исходников или из C исходников. Зачем мне переписывать libc на rust чтобы получить то же по сути? На любом языке используя связываемый нативный код вы соглашаетесь с тем, что это небезопасно, но почему-то судя с ваших слов для rust это крах, а для того же с++ когда, он берет libc нет, или например для js когда оно работает в связке с node.js которое по сути v8 + libevent, может быть это крах js? Может со временем стандартная библиотека rust станет богаче и люди откажутся от libс и что вы там еще перечисляли, опять же банально многим проще брать биндинги из-за предыдущего опыта, как например с тем же libcurl типичная «народная» библиотека и это совершенно не говорит о том что это крах rust.

rust это не какая-то волшебная хрень которая делает любую программу или библиотеку написанную на нем безопасной, он просто ставит вам палки в колеса, когда вы пишите нативный код плохо и опасно, что делает его более-менее рабочим без необходимости потом еще его гонять через статические анализаторы, санитайзеры, отладчики чтобы убедиться в том, что вы себе не отстреливаете ногу каждый день по чуть-чуть (хотя даже в нем я более чем уверен, что можно обмануть компилятор и написать опасный код), а так же без необходимости держать в голове 1000 и 1 особенность работы языка и компилятора (потому что вы сами декларативно описываете поведение ваших типов и их времени жизни если речь идет о ссылках + управление мутабельностью, передачей и владением (все выдуманные категории за которыми в других языках следит компилятор, а вам приходится помнить правила того, как он на этими категориями следит)) как это например происходит в С. Так что по большей степени rust это и есть С, но вывернутый наизнанку и с альтернативным синтаксисом. Rust это С для ленивых c маленькой оперативкой мозга :3 (никого не хочу обидеть имел в виду только себя)

lazy_static - попытка создать глобальные переменные с вызовом процедур до main. bitflags - for sets of C-style bitmask flags. It can be used for creating typesafe wrappers around C APIs.

«Нас не устраивает раст, давайте расширим синтаксис до знакомых вещей»

Спасибо, капитан очевидность. По твоей логике и связка PHP + Haskell тоже будет смотреться очень хорошо.

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

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

Спасибо, капитан очевидность. По твоей логике и связка PHP + Haskell тоже будет смотреться очень хорошо.

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

смысле есть, писать проще, изучать проще, а значит быстрее, его по сути только для этого и придумывали потому что «нажрались» сишечки (люблю особо теплой любовью сишечку, но понимаю тех кто делал rust)

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

С си переходить смысл вполне есть, если не в ядре или эмдебеде сидишь, раст как язык более выразителен и во многом как ни парадоксально ближе к си чем с++ (в раст нет исключений, рантайм легче чем у с++, очень легкий ооп). Вот с современного С++ смысла уже меньше, тут только из-за безопасности можно переходить.

Ты сам не понял что я имел ввиду. Чем сильно отличаются языки тем больше надо выполнять преобразований между ними. Как ты собрался из раста вызывать виртуальные методы C++? Писать кучу хаков и костылей? А потом в раст обратно передавать объект std::string?

Ты понимаешь что в языках разное представление данных и что передать по указателю не получится просто так если ты не знаешь как выравниваются и алоцируются данные?!

У раста есть полноценный 100% ABI везде и всюду чтоль?

lazy_static - попытка создать глобальные переменные с вызовом процедур до main.

lazy_static - это просто сахар. rust поддерживает глобальные переменные.

bitflags

Опять сахар.

Нас не устраивает раст, давайте расширим синтаксис до знакомых вещей

Это не делает его сишкой.

Ты сам не понял что я имел ввиду. Чем сильно отличаются языки тем больше надо выполнять преобразований между ними. Как ты собрался из раста вызывать виртуальные методы C++? Писать кучу хаков и костылей? А потом в раст обратно передавать объект std::string?

Речь же шла о динамической библиотеке с сишным итерефейсом, такие на и на расте и на с++ удобно как делать так и вызывать без проблем. А про вызов С++ из динамических библиотек не нужно, С++ не может и С++ вызывать в общем случае, ABI нет стандартизированного.

У раста есть полноценный 100% ABI везде и всюду чтоль?

В расте легко пользоваться сишным ABI.

Ты сам себе противоречишь. По твоей логике зачем писать велосипеды на расте тогда, если есть готовое на C/C++ с иcпользованием других библиотек на C/C++?! Это все равно превратиться в бинарный код в итоге. Смысл???

С си переходить смысл вполне есть

Так никто не хочет переходить с безопасного C#(с тем же unsafe) в том то и дело.

если не в ядре или эмдебеде сидишь

а где ниша тогда?