Представлен первый бета выпуск P2P-платформы Radicle и связанного с ней десктоп-клиента Radicle Upstream. Проект нацелен на создание децентрализованного сервиса совместной разработки и хранения кода, похожего на GitHub и GitLab, но не привязанного к конкретным серверам, не подверженного цензуре и работающего с использование ресурсов участников P2P-сети. Код проекта написан на Rust (клиент на TypeScript, Svelte и Electron) и распространяется под лицензией GPLv3. Сборки подготовлены для Linux (AppImage) и macOS...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54207
Кто уже успел использоваться, напишите пожалуйста про быстродействие.
> Кто уже успел использоваться, напишите пожалуйста про быстродействие.инструменты: TypeScript, Svelte и Electron
Быстродействие зависит от того, на сколько больше чем 8 Гб. у тебя оперативки....
>инструменты: TypeScript, Svelte и ElectronА что ты против них имеешь? Вообще-то это уже софт космического уровня надежности - управление на Масковском Dragon, который, вообще-то, людей на МКС возит, на нем сделан.
Почитай для общего развития: https://habr.com/ru/company/dcmiran/blog/530446/
Electron и JS - это давно уже mission-critical вещи. В том числе там где от этого зависят жизни.
дебилизм американских технологий известен давно, так что можете лишний раз не рекламировать (дело в том что им приходится использовать то что получило развитие благодаря свободному рынку, т.е. толпе, а толпа не очень хорошо разбирается в технологиях и проектрировании)
Чувак. Ты сидишь в американской сети, твой комп разработан американскими фирмами полностью и твоя ОС написана американскими фирмами. И при этом ты рассказываешь о тупости американцев и своем вяличае. Тебе не смешно самому?
Сеть проcрали стандартами, все ОС в гyмно скатываются. А сами компы ты это не бзды - это всё Китай.
> Сеть проcрали стандартами, все ОС в гyмно скатываются. А сами компы ты
> это не бзды - это всё Китай.Все железо разработано американскими фирмами, а где произведено не важно. Инженеры-то американские были.
Справедливости ради, про вяличае он ни слова не сказал. Но вашу точку зрения поддерживаю.
И как то ты всё мимо попал
чел. сеть, ос, компы и вот это всё придумывалось одними людьми, а тайпскрипты, электроные и прочее - другими. Улавливаешь?
Ты ненавидишь все американское. Да и люди зачастую там те же. Это как с ненавистниками Wayland'а которые не знают, что его пилят те же, кто раньше пилили Xorg :-D
>>инструменты: TypeScript, Svelte и Electron
> А что ты против них имеешь? Вообще-то это уже софт космического уровня
> надежности - управление на Масковском Dragon, который, вообще-то, людей на МКС
> возит, на нем сделан.
> Почитай для общего развития: https://habr.com/ru/company/dcmiran/blog/530446/
> Electron и JS - это давно уже mission-critical вещи. В том числе там где от этого зависят жизни.А если читать чуть дальше заголовка?
> Всё это не значит, что космический корабль летает на JavaScript. Chromium на корабле используется только как средство отрисовки элементов пользовательского интерфейса.
>Слой взаимодействия с полётным программным обеспечением имеет все необходимые меры резервирования и находится за пределами дисплеев, говорят сотрудники SpaceX.
>Бэкенд написан на C/C++.
>На всякий случай под тач-дисплеями расположены физические клавиши. Они предназначены для критических ситуаций, к примеру, пожара в кабине корабля. Также есть физические кнопки «начать» и «прервать» для большинства операций, которые можно вызвать с дисплеев. НАСА разработало специальные требования к самим экранам, и решение SpaceX им соответствует.
>
Понятное дело, что ПО контролирующее полёт ракеты не пишут на джаваскрипте и хроме. Хромого невозможно отдебажить чтобы иметь хоть какие-то существенные гарантии что ничто не навернётся.
И физические кнопки это вполне нормальное явление. Это даже не вопрос надёжности джаваскрипта или чего-то ещё, это вопрос дубликации всего чего только можно. С учетом цены ракеты и космонавтов, я бы мозаиками из этих кнопок стены бы обклеивал.
Тем не менее, не смотря на то, что я электрон на дух не переношу и мне сложно это признавать, но это круто.
> Вообще-то это уже софт космического уровня надежности - управление на Масковском DragonТо-то они 3 компа параллельно запускают с этим софтом...
>>инструменты: TypeScript, Svelte и Electron
> А что ты против них имеешь?ничего. просто тормозной хлам и все. выкинул и забыл.
Электрон - говно из жопы собаки, жрущее кучу памяти, и созданное чобы удешевить разработку, так как js-разработчики меньше стоят, чем другие. А теперь рви жопу и доказывай обратное.
Интересненько... Пользовался кто-нибудь?
Звучит излишне сложно, не взлетит. Но, в принципе, исключительно для _совместной разработки_ двух или около того кодеров было бы интересно попробовать. Сайт клепали какие-то содомиты.
>Код прокси для работы узла написан на языке Rust, в графический клиент на TypeScript, Svelte и ElectronТеперь будет истерика
На сях надо было им писать.
Только после обкатки технологии. Пока рано.Пусть накопятся всее косяки в архитектуре и со знанием их уже и будет нормальная реализация, не тянущая гигабайты, сама не занимающая столько и работающая быстро.
Или что-то типа плагина для git'а.
> На сях надо было им писатьОдин товарищ здесь с Вами не согласится вот прям 100%
Лучшие си это плюсы.
не соглашусь
Хуже си только плюсы.
Соглашусь.
Код изначально "на выброс" пофиг на чём писать.
Новый проект нет смысла начинать писать на сях.
Подожду, пока подобную технологию добаваят в GNUnet. Тогда будет норм, без Растов и Электронов.
> Подожду, пока подобную технологию добаваят в GNUnet. Тогда будет норм, без Растов
> и Электронов.…на Guile.
Почему бы и нет? Одобренный мэтром СПО язык.
Электрон ладно, то еще гуано. Но Раст-то чем не угодил? Он по скорости на уровне C или C++.
Во-первых - медленнее, уже на что пыжились разоблачая zero-overhead в плюсах, но по сравнению с рустом это кажется мелочными придирками.
Во-вторых - одной "сравнимой скорости" мало. Пока в сообществе преобладают ведущиеся на хайп кодомакаки, которые думают, что использование "правильного" языка им автоматически пересадит руки из жопы на плечи - трижды подумаешь прежде чем связываться.
В-третьих, учитывая то, что основную команду разработчиков выперли на мороз, после того как они за десять(!) лет не смогли родить ничего практически полезного в плане решения поставленной задачи - вызывает сомнения в перспективах руста как языка.
Как же не смогли?
Часть firefox работает на rust.
А выкинули на мороз потому что из-за доходов нехватило на зарплату менеджерам https://pbs.twimg.com/media/EOWjE6PU0AAddTu?format=jpg&name=...
Надо же было на чем-то экономить.
> Часть firefox работает на rust.Говорят, в одном из офисов гугла есть веб-страничка на похапэ, через которую они пиццу заказывают. Значит ли это что в гугле всерьёз полагаются на похапе в своей работе?
Некорректное сравнение, там много важных частей на Расте. Например, движок CSS и WebRender
Ну да, ну да, как же, quantum. Ради него просpали наработанный массив дополнений, кастомизацию браузера как такового и лояльность пользователей. В результате поменяли один css-движок на другой, и выперли команду разработчиков, которая теоретически может его поддерживать в будущем. Quantum сейчас - это чемодан без ручки: выкинуть жалко, ибо столько ресурсов в него закопано, тянуть - тяжело. А тем временем, в процессе переписывания, за пять лет браузер потерял в распространённости втрое: с 22% до 7%.Что самое смешное, несмотря на всё перечисленные "непопулярные меры", падение доли рынка это не остановило, и firefox продолжает уверенно и не снижая темпов просиpать её в пользу гуглохрома, который ...написан на c++. Пора открывать школу эффективного менеджмента от мозиллы.
> Ради него просpалиНе ради него. У них был явный выбор: или жесткие тормоза, уязвимые небезопасные, но хорошо кастомизируемые дополнения или избавиться от легаси и начать жить. Выбор очевиден.
Да, я тоже скучаю по некоторым дополнениям, люблю Firefox, но вряд ли бы продолжал терпеть его даже ради кастомизации. А вот после перехода на Квантум он по скорости стал на уровне Хрома.> за пять лет браузер потерял в распространённости втрое
Это связано не с самим Firefox, а с назойливостью Гугла.
Впрочем, именно с этими изменениями он смог стать сильным конкурентом по _скорости_, так бы наверняка потерял еще больше.> который ...написан на c++
Ты всерьез заявляешь, что язык хоть как-то влияет на популярность массового продукта? Реально? Большинство пользователей даже не знает, что такое Rust или C++. Хотя нет, Rust они знают. Игра такая есть.
с xul нельзя было сделать много процессовую архитектуру. От него пришлось отказаться
впараше и говнокнига написаны на php.
> впараше и говнокнига написаны на php.не, у них не чистый пхп, а альтернативная реализация
> впараше и говнокнига написаны на php.Нет. Но даже это их не спасает конечно же
> Во-первых - медленнее, уже на что пыжились разоблачая zero-overhead в плюсахОй, все эти оптимизации - вилами по воде.
Например, у меня были случаи, когда один и тот же код g++ оптимизировал лучше gcc (значительно), когда rust быстрее gcc и/или g++, когда gcc и/или g++ быстрее rust.
Так что в целом можно сказать, что они примерно в одинаковой весовой категории zero cost abstraction языков, где всё уже скорее зависит от реализации, нежели самого языка.
Понимаю, что это ничего не значит, но просто оставлю здесь: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...> Пока в сообществе преобладают ведущиеся на хайп кодомакаки, которые думают, что использование "правильного" языка им автоматически пересадит руки из жопы на плечи
???
Например? Пока я скорее видел тех, кто раньше занимался C/C++, потом решив использовать еще и Rust. И выходцев из других языков, но там обычно из лучших. Абы кто не стремится в язык с относительно высоким порогом входа.
Лично я в проектах до Раста использовал C++ (и продолжаю), иногда JavaScript, и не совсем понимаю описанную ситуацию, можно подробнее?> после того как они за десять(!) лет не смогли родить ничего практически
? Это всё внутренние дела Мозиллы, которой самой, к сожалению, не сладко.
Но это не мешает тому, что все новые хорошие модули в Firefox пишутся на Расте (естественно, сам Firefox целиком переписывать было бы очень глупо), а сам Раст давно вырос из Мозиллы, и им интересуются народ из более крупных компаний.
Создание фонда Раста вызывает больше положительных эмоций, нежели прибывание его в Мозилле.
Не теперь, а через пару месяцев ...у разработчиков. Когда они обнаружат, что их велосипед нах никому не нужен, несмотря на то что он на русте.
P2P git... Хорошая, годная идея. Гит на торентах)))
Анархическая платформа?
Намного проще: куда девать энергию rast'аманам, чьи поделия никому не нужны? А давайте запилим очередное "ненужно" на каком-нибудь "ненужно"!
Самп понял, что за чушь ты сейчас написал?
Чем бы дитя не тешилось, лишь бы не руками и в публичном месте.
Судя по описанию, оно через p2p всего лишь шарит git. Интереснее было бы, если бы прям в p2p storage хранились коммиты. Например во freenet или в gnunet. freenet с его доступом по ключу на первый взгляд кажется весьма подходящим инструментом.
Гит сам и есть распределённое хранилище. Ты предлагаешь на ровном месте получить проблемы при интеграции с инструментами для гита без какой-либо выгоды от использования IPFS вместо гита.
А зачем? Гит и так самодостаточный. Ему только ремоут сделать через p2p
> А зачем? Гит и так самодостаточный. Ему только ремоут сделать через p2pВыключится компьютер разработчика, его ветка станет недоступной.
Это и есть p2p storage с git-бэкендом.
>Код прокси для работы узла написан на языке Rust, в графический клиент на TypeScript, Svelte и Electron.это плохо
Это просто такой стёб, наверное. Первоапрельский проект.
> на языке Rust, в графический клиент на TypeScript, Svelte и Electronпошёл мыть глаза с мылом. где тег "жесть"?
Вот вот. Вместо того чтобы написать на нормальном языке программирования таком как Си, со слабой типизацией, без строк, без автоматического управления памятью, они пишут на смузихлебном rust
Что еще взять от необразованных недопрограммистов?
git написан на том самом си: "со слабой типизацией, без строк, без автоматического управления памятью", что не помешало ему закопать всех остальных конкурентов в своей нише, в том числе тех, которые были написаны на языках, где всё перечисленное было: hg, bzr.Люди способные придумать действительно революционный в своём классе софт, как правило владеют сишечкой и/или плюсами. А вот смузихлёбы в силу умственных способностей не могут ни того ни другого, поэтому хотя бы свою криворукость и пытаются компенсировать рустом.
Неудачный выбор языков прям так и говорит: можете выбросить ВООБЩЕ ВСЁ без сожаления!
Почему неудачный?
Вы всегда можете написать лучше
С чего вы взяли, что это вообще надо писать? В новости начисто отсутствует раздел "RATIONALE", в которой описана проблема, которую пытаются решить, обзор более ранних попыток её решения, и почему /именно их/ новый велосипед её успешно решает.
потому что это само собой очевидно.
чтобы не забанили за просто так по желанию левой пятки правообладателя на какую-то ерунду, о которой разработчик знать не знал и к которой разрабатываемая программа не имеет отношения.
Мне одному кажется, что "единая точка отказа, компания может закрыться или изменить условия работы" - вот это вот всё решается простым бэкапом всех реп на локальный диск??
Вас трое. Проект — это не только исходники, но и багтрекер, и вики, и вебсайт, так что бекапить нужно не только репу с кодом. И если в случае с гитлабом код сервера открыт и можно поднять свой сервер, то в случае с гитхабом ты в пролёте. (Хотя хз, возможно, в гитлабе есть средства миграции с гитхаба.)
багтрекер и пулреквесты заблокированного на гитхабе youtube-dl восстановили? или таки пришлось обнулить?
а если репа в закрытом корпоративном аккаунте?
гитхаб имеет право такое проверять и закрывать
Так здесь нет ни первого ни второго ни третьего.
Если посмотришь на скриншот в новости, увидишь таб "Issues", так что багтрекер там есть. Про остальное не знаю.
>в случае с гитхабом ты в пролётеЕсть куча инструментов для экспорта данных с гитхаба. Так что да, когда пилишь штуки типа youtube-dl, важно делать бэкапы.
Кстати, ровно в это же время программерская среда страдает от отсутствия нормальных, бесплатных средств совместной разработки - хранение кода, реестр ошибок, документация, сообщения и т.п. ГДЕ ЭТО ВСЁ? Доколе можно пилить все эти блокчейны, когда на носу висит конкретная проблема?
в зеронете есть аналог гитхаба http://127.0.0.1/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/
если зеронет не установлен, то можно глянуть через прокси https://zeronet.now.im/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/
>бесплатных средств совместной разработки - хранение кода, реестр ошибок, документация, сообщения и т.п. ГДЕ ЭТО ВСЁgithub и gitlab
Всё упирается в человеческий фактор, если разраб раздолбай - он точно так же /не будет/ всем этим пользоваться, если нет - найдёт способ относительно безгеморно обеспечить бэкап всего перечисленного с уже существующими средствам, благо их навалом.Это теоретически /может быть/ полезно в экзотическом случае вроде сильной текучки людей в проекте, но... я не знаю ни одного, который просуществовал бы достаточно долго. В этом случае инфраструктура и workflow "старожилов" проекта и становятся стандартом de-facto, а мимокрокодилы под них подстраиваются. Если ни одного "старожила" не осталось - проект умирает.
Что касается технической стороны, то если проект большой/серьёзный - можно потратить какое-то время на собственную инфраструктуру, хотя бы в виде домена с gitea, если маленький/бросовый - проще взять уже готовое. Идейным selfhosted-одиночкам проще взять какой-нибудь fossil, и гордо жить хоть на динамическом ip, по принципу "всё своё ношу с собой". И в том, и в другом и в третьем случае нет смысла заморачиваться с p2p, да ещё с такими всратыми зависимостями. Тут люди от редмайна отказываются, чтобы руби в систему не тащить (первому уже 15 лет, второму - 25, детские проблемы вылечены, шишки набиты, на stackoverflow все тонкости разжёваны в степени "для имбецилов"), а тут ещё какая-то неведома чебурашка, которую непонятно как поддерживать.
>Вместо привязки к внешнему эталонному репозиторию, в Radicle работа отталкивается от монорепозитория на локальной машине каждого разработчика, в который можно извлекать изменения из репозиториев отслеживаемых участников и передавать свои изменения в репозитории отслеживающих участников.Они переизобрели mercurial? Серьёзно?
Раз они используют раст, могли бы взять как раз тот же mercurial, который на раст тоже переходит.
Раз они используют раст, они могли бы взять pijul[1], но решили-таки взять git. Лошки.[1] https://pijul.org/
Вы-то сами свой пихуль используете? Без GUI-инструментов, интегрированных в файл-менеджер ни одна система контроля версий не нужна.Кстати, у них заявлена возможность подключить любую систему контроля версий, включая pijul (да, они о нём знают), просто они предпочитают сначала допилить и отладить бэкэнд для гита.
> Вы-то сами свой пихуль используете?Нет.
> Без GUI-инструментов, интегрированных в файл-менеджер ни одна система контроля версий не нужна.
Глупости. Зачем системе контроля версий gui инструменты? Я пользую magit с git, но magit сложно назвать "графическим". И то мне иногда проще в командной строке с git разобраться, чем через magit. Когда я начинал работать с git, я пользовался gitk, чтобы видеть, что я сделал, но gitk практически бесполезен для всего остального.
А файл-манагер? Зачем он нужен вообще при работе с версиями? В смысле, чтобы видеть файлики в виде иконок, а не имён? Или чтобы перетаскивать файлики из ветки в ветку? Всё ведь делается в командной строке или средствами IDE.
> Кстати, у них заявлена возможность подключить любую систему контроля версий, включая pijul
> (да, они о нём знают), просто они предпочитают сначала допилить и
> отладить бэкэнд для гита.Вот я и говорю -- лошки.
>Зачем системе контроля версий gui инструменты?Затем что без них придётся только и делать, что копипастить хеши. Кстати, без GUI-консоли вы их и копипастить не сможете, придётся ручками набивать.
> gitkТакое глючное говно, которое
1 постоянно падает на некоторых проектах;
2 не умеет в копирование. Первый раз копирование в буффер удаётся, последующие - нет;а пофиксить некому. И это один из лучщих GUI-клиентов для линукс. Дя винды TortoiseGit вне конкуренции, но на линукс её хрен портируешь, жаром что на Qt написана.
>А файл-манагер? Зачем он нужен вообще при работе с версиями? В смысле, чтобы видеть файлики в виде иконок, а не имён?
Чтобы наглядно видеть, какие файлы и папки изменились, и парой кликов вызывать дифф для них.
>>Зачем системе контроля версий gui инструменты?
> Затем что без них придётся только и делать, что копипастить хеши.Нет, я делаю много других вещей. Вообще хеши копипастить приходится, когда что-то пошло не так. А пока всё по плану, выручают stash'и и ветки.
> Кстати, без GUI-консоли вы их и копипастить не сможете, придётся ручками набивать.
Во-первых, с чего я вообще буду пользоваться не-GUI-консолью? Ядерная консоль тормозная донельзя, плюс я считаю небезопасным иметь код эмуляции терминала в ядре: они б ещё X'сервер в ядро засунули. Во-вторых, смогу. Ты про gpm слышал?
>> gitk
> Такое глючное говно, котороеДа мне пофигу. И ты мог бы догадаться, потому как я выше написал, что использовал его для визуализации.
>>А файл-манагер? Зачем он нужен вообще при работе с версиями? В смысле, чтобы видеть файлики в виде иконок, а не имён?
> Чтобы наглядно видеть, какие файлы и папки изменились, и парой кликов вызывать
> дифф для них.Но git же скажет, какие изменились, надо лишь спросить. И diff покажет. Совершенно бесполезная вещь, этот ваш гуй.
Идея гипертекстового векторного фидонета не дает людям покоя.
> Еще одной статьей его дохода стала сдача в аренду целого лабиринта старых сараев и подвалов за баром.
> Обычно их весьма ненадолго снимали полные энтузиазма производители всяких занятных штук, например такие, которые верили, что мир очень, очень нуждается в надувных досках для дартса. (ц)
Успех или неудача /любого/ проекта определяется тем, решает ли он какую-то насущную потребность или нет, а не тем, на правильном ли языке он написан. Уже потом идёт подбор инструмента под задачу, и остальные факторы. Рустоё6ы, как частный случай фанатиков любого ЕдинственноПравильногоЯзыка™ этого в упор не понимают.
И ты не видишь в своих словах противоречия? Вот кто истинный фанатик!
> Рустоё6ы этого в упор не понимаютА местные сиёбы это понимают, да?
Раст объективно уместен везде, где есть сеть и бэкенд, которому нужно действительно хорошо работать. Удобная асинхронность (async/await с участием Tokio) для сетевых проектов этому лишь способствует.
Естественно, его нет смысла пихать вообще везде (как и C или C++), но в данном проекте он уместен чуть более, чем полностью.
> Раст объективно уместен везде, где есть сеть и бэкендЭто типа за десять лет так и не придумали, в какую же нишу его нацелить? Теперь оказывается это язык для написания сетевых приложений. Ну удачи вам повоевать за сетевые сервисы, бгг. Мозилла вот чёт не шмогла за десять-то лет.
Hint: Сунетесь в телекомы - соснёте у ерланга, в ентерпрайз - у жабы, в бакенд вебсервисов - у го, в сетевой хайлоад, гейминг или hft - у плюсов с asio и сишечки с libev. Обложили со всех сторон, супостаты проклятые!
Ниша: системное программирование
Сабж: сетевое приложение. Говорим, именно в контексте этого.Да, бэкенды - одна из ниш Раста, где он хорошо себя раскрывает. Очень показательный пример развития языка: синтаксис async/await добавили в стейбл год назад, и сейчас практически все либы перешли на новый. А теперь смотрим на C++20, его состояние в компиляторах и плачем. Какие-то ещё вопросы?
Между делом, actix web, один из быстрейших веб-либ, написан на... Правильно :)
https://www.techempower.com/benchmarks/
Раст еще и из-за хорошего асинхронного драйвера postgres вывозит тест (да, в первую очередь важен не язык, а алгоритмы и реализация).
Drogon тоже неплох, но вроде бы гораздо менее известен (узнал о нем впервые из бенчмарка, более нигде не видел)
В том же бенче можно наблюдать поражение Жабы, Го и прочих.
Ещё поражение Го неплохо прослеживается в истории Дискорда, который заменил довольно быстрый оптимизированный сервис с Го (но тормозящий из-за gc) на сделанную на коленке версию на Расте и получили равную производительность (из-за отсутствия gc - без тормозов), оптимизировали раст-версию и получили существенное улучшение производительности и стабильную работу.
http://habr.com/ru/post/487116
> async/await добавили в стейбл год назадО, узнаю тяжёлый дух маразма привыкшего писать на языках "с батарейками в комплекте". Напомнить, откуда фичи для включения в очередной плюсовый стандарт черпаются и по сколько лет они там маринуются для допиливания? Что впрочем не мешает их использовать всем желающим сразу, благо язык позволяет себя расширять в полевых условиях, не дожидаясь высочайшего одобрения комитета.
Конкретно плюсовый asio почти вдвое старше руста как такового, впятеро - руста "стабильного". А есть ещё те, кто в стандарт и не стремился, и тем не менее свою работу выполнял, например poco.
> О, узнаю тяжёлый дух маразма привыкшего писать на языках "с батарейками в комплекте"Звучит так, будто это плохо. В языке должны быть Возможности, а не как C без толкового развития десятилетиями. C++ в этом плане неплох, я им пользуюсь в целом с удовольствием, в частности его воплощением в Qt-версии, но всё же он в целом несколько отстает от Rust по удобству экосистемы (один https://serde.rs/ чего стоит).
> Что впрочем не мешает их использовать всем желающим сразу
Можно модули и концепты во всех основных (gcc и оба clang) компиляторах? Это, пожалуй, одни из основных фич C++20. И да, мне реально нужен, как минимум, Clang, ибо все платформы, а на андроиде/маке/айоси он основной. При чем у Аппле свой Шланг, у которого фичи не всегда совпадают с мейнстримным.
https://en.cppreference.com/w/cpp/compiler_support
Раст радует тем, что основной компилятор у него один. Надеюсь, в связи с организацией фонда, так останется и впредь, и микрософт не будет плодить всякие вероны.> Конкретно плюсовый asio почти вдвое старше руста как такового, впятеро - руста "стабильного"
Тем временем, в стандарте C++ нетворка до сих пор нет, а в Rust есть :)
> Тем временем, в стандарте C++ нетворка до сих пор нет, а в Rust естьИронично, что это сообщение написано через браузер, написанный на c++, через сетевой стек операционки, написанной преимущественно на с++, с ядром, написанном на си. Давай, ебaнат, расскажи мне ещё этих прохладных историй.
Давай, eбанaт, расскажи, где в STL у C++ есть нетворк
> Тем временем, в стандарте C++ нетворка до сих пор нет, а в Rust есть :)Это убожество под названием Rust - лучше бы вообще не умело в нетворк чем вот так. Вообще странная или больная фигня, тут как-раз таки Си и даже с плюсами уделывает даже не приходя на тесты.
Вот вообще, без пруфов, чисто мысли вслух, основанные на собственных больных фантазиях? :)
Я хотя бы ссылку на бенчмарки веб бэкендов дал.
>А теперь смотрим на C++20, его состояние в компиляторах и плачем.А чего смотреть-то? Дело времени, стандарт только в этом году утверждён.
Ишь как свирепо минусуют, правда она такая - глаза колет, и в заднице жжет. Неприятно осознавать себя идиотом, правда? Вот вам мнение другого умного человека на ту же тему:---
Типичный астронавт архитектуры, размышляя над тем, что «Napster — Peer-To-Peer (P2P) сервис для обмена музыкой» проигнорировал все, кроме архитектуры, думая, что интересно только Peer-To-Peer, забыв о том, что ещё можно ввести название песни и мгновенно её прослушать.
Все размышляют о Peer-To-Peerએ, и об этом, и о том, внезапно обнаруживая Peer-To-Peer конференцию, Peer-To-Peer фонд венчурного капитала, и даже Peer-To-Peer рефлексию идиотствующих бизнес-журналистов, истекающих желчью, переписывая друг у друга: «Peer-To-Peer мертв!».
Астронавт архитектуры задается вопросом: «Можно ли представить себе такую программу, как Napster, но с возможностью обмениваться не только песнями?» И кинется создавать приложение, подобное Groove. Потому, что считает его более общим, чем Napster, но пренебрегает при этом незначительной, крошечной функцией — можно ввести название песни и немедленно её прослушать. Тем, что мы хотели получить изначально. Суть потеряна, всё. Если бы Napster был не Р2Р и позволял, напечатав название, немедленно прослушать песню, он все равно был бы популярен. (ц) Спольски
---
P.S. Вместо изучения очередного модного убогого недоязычка, чтобы не отстать от рынка™, займитесь лучше поиском действительно стоящих идей для своих проектов.
> несколько параллельных веток (upstream) со своими сопровождающими и участникамТак и представляю ветку форума поддержки:
- Памагити, софт не работает!
- Из чьей ветки тащил?
- Из ветки Васяна.
- Бери из ветки Вована, у Васяна глючная.
Стремясь избавиться от "единой точки отказа" авторы потеряли вершину цепочки ответственности. Должно быть ответственное лицо - либо личность (Торвальдс, Ван Раадт, Диллон и т.д.), либо коллекивный орган. А следовательно - должна быть одна ветка, за которую это ответственное лицо может поручиться.
Оно не о том. И так можно собрать из ветки любого разработчика. Речь о том, что если основного разраба или его сервер переехал трактор - все изменения оказались доступны, а для полноценного (PR, issues и прочего) участия в проекте не надо быть привязанным к конкретному инстансу. Тому же youtube-dl - в самый раз.А со сборкой - всё проще - "бери такой-то коммит, он релизный"
> А со сборкой - всё проще - "бери такой-то коммит, он релизный"В том-то и вопрос, от кого - релиз в ветке Васяна или в ветке Вована.
Ясно, понятно. Тебе к проприетарщикам, у них собор! А здесь базар.
> здесь базарОтучаемся говорить за всех.
А, лично у тебя с проприерастами собор.
Не пойму, о чём стоны. Ежу ясно, что для гита давно нужен удобный распределённый механизм пулл реквестов, issues и прочего - не прибитый гвоздями к гитхзабу или отдельным инстансам гитлаба, на которых надо регистрироваться для того, чтобы что-то сделать.Конечно, совсем уж p2p - это, может, и лишнее - полагаю, просто механизм для создания PR со стороннего инстанса git плюс хранение issues и прочего в параллельной клонируемой гит-репе и отображение всего этого на базе какого-то из готовых веб-gui были бы проще и менее "экзотичными", но в принципе - вай нот?
А язык... Не хаскель, на котором написан удивительно кривой git-annex (и хрен поправишь) - и на том спасибо
Это специально сделали, чтоб оперу на престо, наконец, допилить, да?
у чуваков на палёной луне с гитхабом проблемы, а ты про оперу
Нет, это специально сделали, чтоб оперу на престо было где похоронить.
Назови хоть одну причину допиливать Оперу Престо, кроме "существует такое явление как фанатики", вместо допиливания Firefox?
Надо же было такую идею убить электроном.
Я бы даже сказал гуём
Домен xyz это ппц... А само оно на электроне, мда...
Да вы задрали ныть. Ничего же в том же Rust-е нет от вас для GUI вот и страдают как могут
Электрон -> Хром -> Гугл -> Алфавит -> .xyz
Идея хорошая, но для серьёзных проектов скорее всего не зайдёт по причине очень большого размера репозитория с большим количеством коммтов. Проблема подобна проблеме биткоинов.Но, для всяких легковесных и небольших проектов самое то. Только зачем?
Работа в подполье или броенепоезде
> для серьёзных проектов скорее всего не зайдёт по причине очень большого размера репозитория с большим количеством коммтовА нехрен большие репы с большим количеством коммитов клонировать целиком.
git clone --depth 10 # последние десять коммитов master'а
git clone --shallow-since=<date> # это с заданной тобою датыТак же ты можешь рулить тем, какие ветки и сабмодули вытягивать.
Это не биткоин, это git. Если у тебя есть состояние репы на момент какого-то коммита, то чтобы получить все последующие состояния тебе достаточно получить патчи, с момента того коммита, вовсе не обязательно выкачивать патчи, которые смогут из пустого репа сделать это исходное состояние.
История тебе может понадобится в процессе разработки -- найти объяснение непонятной строчке кода, например, -- но вот когда понадобится, вот тогда и исправишь, git-fetch поможет.
Благодаря сжатию без потерь --depth=1 обычно не многим меньше полного репозитория - всё равно приходится выкачивать все объекты, общие для присутствующих и отсутствующих коммитов, а таких объектов - большинства, со всем оверхедом от них. Бесплатного ланча в сжатии нет, ты либо оптимизируешь под один случай, либо под другой. Гит оптимизирован под полные репозитории, что имеет смысл. Но в отличие от полного репозитория --depth=1 имеет большие проблемы. Напр. хрен сольёшь с ветками, начинающимися от отсутствующего коммита. Или метки не получишь. Геморрой не окупает выигрыш. Поэтому обычно всё тянут целиком.Чего гиту не хватает - это возможности перебазировать ветки на другую историю. Чтобы апстрим мог начать историю сначала, выкинув все коммиты, а всю информацию об авторстве с гранулярностью по строкам записав в специальный блоб.
> Благодаря сжатию без потерь --depth=1 обычно не многим меньше полного репозитория -
> всё равно приходится выкачивать все объекты, общие для присутствующих и отсутствующих
> коммитов, а таких объектов - большинства, со всем оверхедом от них.Эмм... Тут ты меня потерял. Я может недостаточно шарю во внутренностях git? Если по логике вещей: файлы хранятся блобами, так? Несколько блобов могут упаковываться в паки. Но могут и не упаковываться. Если я вынимаю ровно один коммит из ремота, то мне нужны блобы только этого коммита. И... разве git не вынимает из репа только нужные блобы на сервере, чтобы отправить их клиенту? Может быть упаковывая их в пак при этом, но только их. Разве не так? Или сервер отправляет паки в том виде, как они хранятся у него на диске? Или я вообще не о том?
> Бесплатного ланча в сжатии нет, ты либо оптимизируешь под один случай,
> либо под другой. Гит оптимизирован под полные репозитории, что имеет смысл.
> Но в отличие от полного репозитория --depth=1 имеет большие проблемы. Напр.
> хрен сольёшь с ветками, начинающимися от отсутствующего коммита.Вряд ли ты будешь сливаться с веткой, общий коммит с которой был давным-давным-давно. А если будешь, ничто не мешает тебе получить объекты от точки ветвления и до соответствующих хедов.
> Или метки не получишь.
Это, наверное, можно обойти как-нибудь. Правда я не уверен, что это удастся обойти без скриптописательства. Но в любом случае, прежде чем думать над решением проблемы, надо понять, что за метки тебе нужны. Если тебе нужны все метки, то ведь тебе и вся история тоже нужна, не?
> Геморрой не окупает выигрыш. Поэтому обычно всё тянут целиком.
Потому что обычно размер репа -- не такая большая проблема, как описывает ТС выше.
> Чего гиту не хватает - это возможности перебазировать ветки на другую историю.
> Чтобы апстрим мог начать историю сначала, выкинув все коммиты, а всю
> информацию об авторстве с гранулярностью по строкам записав в специальный блоб.Это можно скриптом сделать. Он правда выполняться будет хренову тучу времени... По-крайней мере, если делать "в лоб". Но если теоретически, ты можешь составить список всех строк проекта, составить список авторов, после чего сопоставить каждой строке автора. Потом идёшь на самое начало истории, создаёшь там ветку, и затем ребазишь туда master, в процессе разбивая его на N коммитов по количеству авторов. В каждый такой коммит суёшь только строки одного автора и так по всем авторам.
Или можно даже проще. Делаешь rebase master'а в пустую ветку, сортируешь все коммиты по автору, после чего по каждому автору squash всех коммитов. Можно потом результат почистить, выкинув оттуда "нулевые" коммиты, которые ничего не меняют. Хотя не, если один человек добавил строчку, а другой её изменил, то при таком подходе эта строчка будет дважды записана. Не, так не выйдет. История станет короче, но это не значит, что меньше.
> А нехрен большие репы с большим количеством коммитов клонировать целиком.Вот это здравое утверждение, касающиеся гита, только не надо думать что авторы "этого непонятно" способны на такие же мыслительные процессы как и вы, и соответственно ожидать что "оно" работает так-же.
>Но, для всяких легковесных и небольших проектов самое то. Только зачем?чтобы гитхаб не забанил
на что ни пойдут хипсторы, лишь бы патчи по email не слать. Бгг)
Зачем оно, если уже есть fossil, умеющий именно это?