Компания Facebook вошла в число платиновых участников организации Rust Foundation, которая курирует связанную с языком Rust экосистему, поддерживает основных мэйнтейтнеров, занимающихся разработкой и принятием решений, а также отвечает за организацию финансирования проекта. Платиновые участники получают право вхождения представителя компании в совет директоров. Представителем Facebook стал Джоэл Марси (Joel Marcey), который присоединился в совете директоров к представителям AWS, Huawei, Google, Microsoft и Mozilla, а также пяти участникам, выбранным из Core Team и групп, отвечающих за надёжность, качество и взаимодействие с сообществом...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55049
Щас что-нить про макак начнут ныть, вангую.
макаки ноют
Ну да, ну да, ведь манагеры пейсбука, ответственные за подобные решения имеют, как минимум, лет сто опыта работы с С/С++ и нахлебались с этими наколенными поделками горя, так что точно знают, что делают. Только идиот может подумать, что такое прорывное решение может быть как-то связано с пиаром.
Ну и да, они заслали в РастФандэйшн своего главного ПХПшника. Но вам всё божья роса, прогрессивные вы ниши.
Манагеры не продумывают технические решения. Они максимум могут их одобрить, когда инженеры объяснят зачем это нужно.
Макака82 начала ныть :)
Что на этот раз будет сливать?
Ржавую воду
как обычно ВСЁ
GTK создали для гимпа, но в итоге это гноме тулкит. Раст создали для фаерфокса - оранжевого, но в итоге хз что будет.
> в итоге это гноме тулкитГимп они тоже забрали
> Раст создали для фаерфокса - оранжевого, но в итоге хз что будет.Цвета радуги будут
> Раст создали для фаерфоксаНеа. раст к тому моменту уже разрабатывался несколько лет.
Наверно мозиловцы увидели что-то перспективное
Не разрабатывался, а только проектировался.
Разрабатываться-таки он как раз с поддержкой Mozilla начал. И то - до сих пор родного компилятора нет, только LLVM-ный костыль, что отпугивает большинство знакомящихся конечным результатом компилируемого.
>например, на Rust написаны применяемые в Facebook Mercurial-сервер MononokeНовость о том, что существует такой сервер, поважнее будет.
ну может где-то внутри пейсбука и существует, тебе-то что с того?https://github.com/facebookarchive/mononoke - упс, пустое место.
Пейсбук не собирается делиться с тобой технологиями, пригодными к использованию (ссылка на бесполезного несовместимого недоделка в вечном процессе "переписывания" - это ни разу не пригодное к использованию)
Это у них теперь часть EdenSCM:
https://github.com/facebookexperimental/eden/tree/master/ede...
Имянно - то есть доделано не было и не будет никогда (а совместимости с настоящим hg уже нет).А то что за закрытыми дверями использует сам пейсбук- вам не дадут.
Доделано .было и опубликовано было. Но в другом репозитории.
За закрытыми дверями Facebook использует Eden, собственно. Вы просто лжёте.
О, классическойи пох. пожаловал, не прошло и 12 часов с новости)
Теперь ясно, Rust - очередная диверсия корпорастов в опенсорсе.
опенсорс это диверсия корпорастов по определению
Диверсификация рисков
1) .. по определению анонима из его головы, а там может быть всякое и даже больше.
2) Назови пострадавших от диверсии.
Кстати, что интересно, сделать в Расте проприетарную либу - не самая тривиальная задача
> сделать в Расте проприетарную либу - не самая тривиальная задачасделать в расте хоть что-то работающее - уже нетривиальная задача.
Эээ, почему это?
не более, чем на C или C++
Если не знаешь языка - конечно. Но так про любой язык можно сказать
Клятые корпорасты лишают бедных бородачей возможности бесконечно латать сишные дыры. Не забудем, не простим!!!!
Взамен сишных дыр придут дыры ржавые
Побойтися бога, в расте дыры ещё найти надо, а крэш словить без ffi вообще маловероятно
Ну всё. Теперь чтоб юзать раст придётся предоставлять удостоверение личности 🤣🤣🤣
Достаточно надеть платье.
Что ж, Раст не зря отправился в свободное плавание, стены Мозиллы он давно перерос
Следим дальше
Выпал из гнезда и такой «надо в дорогу-дорогу-дорогу мне торопиться!..».
Это была его лебединая песня.Под деревом, с которого выпал, вот такое: https://d.radikal.ru/d22/2002/ca/d5f430c08f46.jpg
Хлоп, и уже переваривается. Пейсбуком, с очень плохой дорогой пополам.
"Компания Facebook вошла в число партийных участников ..."Исправлено и дополнено. Исправленому верить.
"мэйнтейтнеров"
Так, и только так надо писать это слово.
Кто видел фабрикатор - тот понимает что новость печальная для раста :)
Что тебе не так с фабрикатором? Недостаточно эмодзишечек?
С ним не так всё, когда вы начинаете в нём работать это становится очевидно.
Я видел фабрикатор и не понимаю. Более того, я вообще не вижу связи.
А вы не смотрите, а попробуйте там что то сделать.Это чудоподелие МЕСЯЦ всасывало репозиторий фри и портов фри, те всосало то оно быстро, потом жевало месяц. Тазик там не супермощный был, но всё же. Нажевало в итоге базу до 30Гб.
Там нет пулрегвестов, есть поделие под это, где дифф надо или руками загружать или как то дурацкой утилитой написанной на пхп.
Зато там есть куча всего не нужного.
Файбрикатор - это сугубо внутренний продукт для мордоркниги для своих же ПХПеров, за пределами - он бесполезен и приносит больше вреда.
Во-первых сегодня много пользовался фабрикатором и просто недоумеваю о чём вы. Может так было когда-то давно?Во-вторых какая связь с Rust-то?
Означает ли это, что из фейсбука перестанут литься данные пользователей всем кому не лень ?
> Означает ли это, что из фейсбука перестанут литься данные пользователей всем кому
> не лень ?Прекратятся утечки про утечки данных.
Где скачать? Мне нужно для одного пет-проджекта...
Найдите серьезный софт на расте
проприетарно же спрятан :)
https://github.com/topics/rust
ну очень серьёзный софт :)
Отвечали на этот вопрос уже тонну раз. Хоть бы сами поискали на GitHub и в Google, прежде чем писать этот комментарий.
Так мусор один находит
Ваши комментарии не считаются
> поискали наНеуловимого Джона тоже ищут...
Rust очень удобен как система сборки для libcurl, я могу в Cargo.toml сказать "скачай, собери и прилинкуй libcurl статически", и это будет работать. Никаких дополнительних динамических линков, описанная система работает даже с кросс-компиляцией. Скажите, можно ли как-то удобно сделать это на Си или как-то еще? Я бы очень хотел найти более удобное решение, сам не очень люблю Rust
То-то Линус ругал раст за отсутствие модульности.
> То-то Линус ругал раст за отсутствие модульности.Только слушал эту ругань аноним как обычно принято на опеннете - жопой.
> Rust очень удобен как система сборки для libcurl, я могу в Cargo.toml сказать "скачай, собери и прилинкуй libcurl статически", и это будет работать. Никаких дополнительних динамических линков, описанная система работает даже с кросс-компиляцией.В итоге бинари получаются очень жирными.
> Скажите, можно ли как-то удобно сделать это на Си
Meson или Makefile для труЪ
CMake и Ninja
> CMake и NinjaCmake на С++
Meson вообще на питоне. И что?
>"скачай, собери и прилинкуй libcurl статически"А чем динамический не угодил? Libcurl гарантированно есть даже на ведроиде. Разве-что в openwrt его нет, но там статику ссаными тряпками гонят, ибо места мало.
>Никаких дополнительних динамических линков
Будет 30 файлов по 30 метров(900 всего) вместо 50 файлов по одному метру(50 всего)
Такое есть смысл использовать в закрытых проектах. Ну ещё иногда для микроконтроллеров, но пихать туда libcurl изначально гиблая идея.
https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_W.../Динамическая линковка внезапно добавляет рантайм косты, накидывает ряд других проблем, взамен чего она позволяет иногда экономить память. За пределами glibc не нужно.
Не совсем понятно, чё все линуксодистры так озабочены динамической линковкой. Я тоже был озабочен, но вот сейчас мне не вспомнить почему, по-моему, лишь по той причине, что оверлеи в досе были продвинутой техникой, и уметь их делать было почётно. И как-то эта почётность в моей голове перепрыгнула на динамическую линковку.
Но реально, это ж убожество. Ну ты сам прикинь: на каждую динамическую библиотеку при старте приложения надо сделать mmap, потом пройтись по табличке релоков/фиксапов, чтобы адреса в своём коде все поправить, но ведь всё это можно было сделать статически, причём даже лучше сделать: lto, pgo, заинлайнить функций, выкинуть неиспользуемое из библиотеки, а оставшееся рпзместить компактнее и более кеш-френдли. Можно сделать офигенно, и один раз на все запуски приложения, но вместо этого почемуто предпочитают делать кое-как, наспех, и при каждом старте. Ппц какой-то. Очередное наследие старпёров, протухший юниксвей, феласофея, скрепы, духовность... а инженерная сторона вопроса никому не интересна.
> Динамическая линковка внезапно добавляет рантайм косты, накидывает ряд других проблемКак бы это странно не звучало, но статика тоже может. Кеш-то не резиновый. Как процессорный, так и io. Да и так получается быстрее грузить систему с хардов или ещё чего с медленной скоростью чтения или случайного доступа.
>За пределами glibc не нужно.Ну и перекомпилирую систему после обновления, например, libcurl.
> Не совсем понятно, чё все линуксодистры так озабочены динамической линковкой.
Драсты и правда озабочены. А лигуксоиды не все. Я знаю как минимум двух людей, которым всё равно.
> Но реально, это ж убожество. Ну ты сам прикинь: на каждую динамическую библиотеку при старте приложения надо сделать mmap
Дисковый кеш может спать спокойно
> потом пройтись по табличке релоков/фиксапов, чтобы адреса в своём коде все поправитьОтносительная адресация
> это можно было сделать статически, причём даже лучше сделать: lto, pgo,Это про оптимизацию. Зубилом хлеб не режут, ножём не делают статуи.
Ну и напоследок
>https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_W...Тут немного про другое. Тут про черезмерное использование динамичечкой линковки. И да, со статикой модет работать быстрее. Но это не повод запрещать динамику.
>> потом пройтись по табличке релоков/фиксапов, чтобы адреса в своём коде все поправить
> Относительная адресацияЧто относительная адресация? Вот написал ты в своей программе:
printf("Hello, world\n");
Это сведётся к:
call printf
какой адрес у printf? Этот адрес станет известным только в процессе работы динамического линкера. И никакая относительная адресация тебе не поможет.
pic код, как я понимаю, использует глобальную табличку оффсетов, и этот call становится косвенным вызовом, и требует дополнительного обращения к памяти. То есть, во-первых, ту табличку надо заполнить на этапе динамической линковки. Во-вторых, при _каждом_ вызове printf будет дополнительная стоимость для процессора -- обращение к глобальной табличке оффсетов, таким образом процессорный кеш, внезапно, вынужден постоянно эту табличку хранить.
> Как бы это странно не звучало, но статика тоже может. Кеш-то не резиновый. Как процессорный, так и io. Да и так получается быстрее грузить систему с хардов или ещё чего с медленной скоростью чтения или случайного доступа.
Ты замерял этот эффект? Я как-то очень сомневаюсь, что будет быстрее. Во-первых, процессорный кеш инструкций вылетает от любого чиха, и надеятся на то, что переключение процессов его сохранит... Лучше бы не сохраняло, потому как мы знаем о том к каким дырам в процессорах оно приводит. А значит возможность шарить код между процессами -- это антифича.
Во-вторых, дисковый кеш, по-моим наблюдениям, вылетает не из-за кода, а из-за данных. Данных на порядки больше кода, и тормоза там лезут именно из-за данных, которые надо читать с диска. Мне приходилось неоднократно сталкиваться с исследованиями о том, как необходимость взаимодействия с жёстким диском для чтения данных приводит к тормозам. Разного уровня исследованиями, начиная от "гляньте чуваки, у меня программа тормозила, но я тут алгоритм поменял, чтобы он читал в другом порядке, и хоп, она стала тормозить в разы меньше", и заканчивая почти уровнем научной статьи, где использовались различные способы измерений (один подтверждает/опровергает другой), проверялись альтернативные гипотезы, где человек шёл на очень серьёзные меры, чтобы показать, что тормоза возникают именно таким образом, каким он говорит. Мне попадались такие исследования про данные, но я не видел ни одного исследования, которое показывало бы превосходство динамической линковки над статической по скорости выполнения.
Я отмечу, что я не искал специально, может они и есть такие? Но вот тут как раз у меня и возникает вопрос: что ты знаешь, и почему ты думаешь, что ты это знаешь? Тебе известны такие исследования? Сейчас будет очень кстати поделиться ссылками на них. Потому как я в этом месте склонен делать вывод, что отсутствие свидетельств -- это свидетельство отсутствия: если проблему никто не подтвердил измерениями, значит проблемы нет.
>> это можно было сделать статически, причём даже лучше сделать: lto, pgo,
> Это про оптимизацию. Зубилом хлеб не режут, ножём не делают статуи.Да, это про оптимизацию. Статический линкер может её выполнять, динамический -- нет. Я не знаю, называешь ли ты его зубилом здесь или ножом, и я не очень понимаю, что ты хочешь сказать этой метафорой, но факт в том, что динамический линкер не может в оптимизации.
> Тут немного про другое. Тут про черезмерное использование динамичечкой линковки. И да, со статикой модет работать быстрее. Но это не повод запрещать динамику.
А раст не запрещает динамику. Тебе никто не мешает объявлять extern-символы. Единственное что, есть ограничения на то, что может быть extern. Параметризованную функцию, например, ты не сделаешь extern. В целом, в rust'е, ты можешь создавать API для динамических библиотек, и использовать эти API, но эти API будут выглядеть так, как выглядят API C.
> pic код, как я понимаю, использует глобальную табличку оффсетов, и этот call
> становится косвенным вызовом, и требует дополнительного обращения к памяти. То есть,
> во-первых, ту табличку надо заполнить на этапе динамической линковки. Во-вторых, при
> _каждом_ вызове printf будет дополнительная стоимость для процессора -- обращение к
> глобальной табличке оффсетов, таким образом процессорный кеш, внезапно, вынужден постоянно
> эту табличку хранить.Если надо несколько раз вызвать одну и ту же функцию, то можно хранить её адрес в регистре. +PIC - это ASLR.
> Ты замерял этот эффект? Я как-то очень сомневаюсь, что будет быстрее. Во-первых,
> процессорный кеш инструкций вылетает от любого чиха, и надеятся на то,
> что переключение процессов его сохранит... Лучше бы не сохраняло, потому как
> мы знаем о том к каким дырам в процессорах оно приводит.
> А значит возможность шарить код между процессами -- это антифича.Это делают разные кеши. Кэш инструкций реализован аппаратно, а кеш страниц ВНЕЗАПНО через MMU. Ну и без него придётся для каждого процесса выделять кучу реального пространства.
> но я не видел ни одного исследования, которое показывало
> бы превосходство динамической линковки над статической по скорости выполнения.Я такого не заявлял. Я наоборот, говорил, что статика быстрее.
>И да, со статикой модет работать быстрее.
Зачем его искать?
Фейсбук такой большой, что ему можно всё.
У пёсбука скажем так нетрадиционный подход ко всему, притом я бы сказал в негативном смысле.
Примерно как у телевизионщиков или телефонистов - они просто невыносимы :)
Все невыносимы, кроме админов.
Забавен факт, что даже самый задрипанный проект на ржавом обязательно пытается о сим факте упомянуть. Какой-то комплекс неполноценности.
Занятно, что обычно он проявляется у пихтонщиков, жсников, жошников и собсна ржашников. pysmth, smth.js/smth.io, gosmth и smth-rust соответственно.
Так что это получается?!.. Важно не компетентное мнение комментаторов Opennet, а шкурный интерес каких-то состоятельных проходимцев?
Да в фейсбуке лошьё сплошное, наслушались растового маркетинга. И поверили, всем же известно, что маркетинг -- это сплошное враньё.
Ох, вот теперь точно расхотелось в раст учиться... :-|
А во что захотелось? Во что удалось научиться?
Немедленно перестань дышать, пить и есть, а то в тебя попадут молекулы, побывавшие в организме Гитлера.
