The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Инициатива по переработке инструментария для гипервизора Xen на языке Rust, opennews (ok), 18-Мрт-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


13. "Инициатива по переработке инструментария для гипервизора Xen..."  +/
Сообщение от Аноним (13), 18-Мрт-23, 10:21 
При этом в мотивировочной части описаны проблемы, которые хрустик сам по себе не решает, а тот же го более распространён, чем окамль и хрустик вместе взятые. Был ксен, да вышел весь, видимо на него на этом повороте окончательно забьют в пользу KVM и доцкеров
Ответить | Правка | Наверх | Cообщить модератору

17. "Инициатива по переработке инструментария для гипервизора Xen..."  –1 +/
Сообщение от Tron is Whistling (?), 18-Мрт-23, 10:23 
Там бы сначала оголтелую питонятину на что-то более вменяемое заменить, а не кровати переставлять.
Ответить | Правка | Наверх | Cообщить модератору

19. "Инициатива по переработке инструментария для гипервизора Xen..."  +/
Сообщение от Анонн (?), 18-Мрт-23, 10:29 
Го медленный. На нем написан только один компонент.
Окамл относительно быстрый, но для него сложно найти сопровождающих.

Плюс в оригинале еще упоминается питон: "This platform is a mix of various languages like C, Python, OCaml and even Go".

Т.е. тебе нужен разраб на OCaml, разраб на Go, разраб на Python.
Или какой-то многостаночник, которых их всех знает одинаково плохо.

Они хотят заменить весь этот зоопарк на что-то одно. И не на си.
И в данном контексте раст хороший вариант.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

27. "Инициатива по переработке инструментария для гипервизора Xen..."  +3 +/
Сообщение от Аноним (98), 18-Мрт-23, 11:11 
В Мозилле тоже так думали. Но что-то потом случилось.  
Ответить | Правка | Наверх | Cообщить модератору

28. "Инициатива по переработке инструментария для гипервизора Xen..."  +1 +/
Сообщение от Анонимусс (?), 18-Мрт-23, 11:21 
Webrender и многопоточность - это лучшее что случилось с мозилой за последние годы. Наконец-то в какой-то момент они перестали быть "тормозилой"

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

Что характерно, на опеньке это событие встретили ликованием - "Растаманов поувольнялили, хахаха", не задумываясь что чистых растовиков там было очень мало, а были как раз с++/rust. Но кого это заботило, там же ненавистный раст))

Ответить | Правка | Наверх | Cообщить модератору

53. "Инициатива по переработке инструментария для гипервизора Xen..."  +1 +/
Сообщение от Аноним (98), 18-Мрт-23, 12:32 
Все так же тормозила и тормозит. Раст не имеет отношения к скорости доп проверки не могут пройти без последствий.  

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

1 миллион долларов это зп 10 программистов в год. Ничего себе лишнего она не приписала.  

Ответить | Правка | Наверх | Cообщить модератору

89. "Инициатива по переработке инструментария для гипервизора Xen..."  +/
Сообщение от Анонимусс (?), 18-Мрт-23, 15:44 
> Раст не имеет отношения к скорости

Еще как имеет. Доп проверки - это фигня, на уровне 1% оверхеда на реальных задачах.

А вот то что они смогли распараллелить CSS - это дало огромный прирост.
То что они не смогли сделать на с++ : "By 2017, Mozilla had made two previous attempts to parallelize the style system using C++. Both had failed."
Можно конечно их просто назвать неосиляторами, но они уже написали целый браузер, поэтому вряд ли проблема только в их компетентности))
А на расте смогли.

> Просто они ничего не смогли дельного написать вот их и уволили и правильно сделали.

А ты смешной))

Ответить | Правка | Наверх | Cообщить модератору

99. "Инициатива по переработке инструментария для гипервизора Xen..."  –1 +/
Сообщение от Аноним (98), 18-Мрт-23, 16:49 
Ещё как не имеет. В хроме все итак работает быстрее. А растофанатики из самого логово раст из мозиллы, не смогли даже свой серво написать, хотя это с самого начала заявлялся как главный продукт на расте.

Ты просто не хочешь верить в очевидное.  

Ответить | Правка | Наверх | Cообщить модератору

116. "Инициатива по переработке инструментария для гипервизора Xen..."  +3 +/
Сообщение от Аноним (114), 18-Мрт-23, 18:20 
> Раст не имеет отношения к скорости доп проверки не могут пройти без последствий.

Часть этих проверок в рантайме для раста не нужна, потому что тот раст-код, что заставит тебя написать компилятор и то, как тебе придется подстроить архитектуру программы, уже исключит какой-то класс ошибок и проверок. Потому что ты там не сможешь делать некоторые вещи как в си. В расте ты это сделаешь по другому. И нередко это будет безопасно и "забесплатно", без проверок в рантайме. Но часть да, в ран-тайме будет проверяться. Но! Эти же самые проверки и сишник должен был бы, даже обязан, делать ручками в своем коде, но делает это, как показывает практика, далеко не всегда. И потому имеем бОльшую часть ошибок в программах (70%) из-за "нинастаящих погромистов".

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

141. "Инициатива по переработке инструментария для гипервизора Xen..."  –1 +/
Сообщение от Аноним (80), 18-Мрт-23, 21:37 
Там такая фишечка что в релизном билде проверки отключаются, а в отладочном тормозит настолько адово что его вообще никак не погоняешь и непонятно зачем он и его безопасности кому-то нужны. По факту можно взять плюсы со всеми украшательствами и не страдать от внезапных зависаний и проблем с отладкой. Да-да, эти ошибки потом именуют "логическими", хотя 1 в 1 что и у си.
Ответить | Правка | Наверх | Cообщить модератору

158. "Инициатива по переработке инструментария для гипервизора Xen..."  +1 +/
Сообщение от Аноним (114), 18-Мрт-23, 22:44 
Прохладные сказки. То-то гугловцы при разработке андроида для новых низкоуровневых подсистем всё шире начинают использовать раст вместо си и плюсов. Небось им поставлена задача затормозить ОС чтобы новые смарты покупали.
Ответить | Правка | Наверх | Cообщить модератору

164. "Инициатива по переработке инструментария для гипервизора Xen..."  –1 +/
Сообщение от Аноним (80), 18-Мрт-23, 23:13 
Вообще в качестве аналога си претензий особых к расту нет, сахар довольно удобный. Пока интероп не понадобится. Но этого недостаточно для написания приложух.
Ответить | Правка | Наверх | Cообщить модератору

167. "Инициатива по переработке инструментария для гипервизора Xen..."  +/
Сообщение от Аноним (114), 18-Мрт-23, 23:34 
И с интеропом там всё нормально, через ансейф обертки. Даже с явой в обе стороны работают.
Ответить | Правка | Наверх | Cообщить модератору

166. "Инициатива по переработке инструментария для гипервизора Xen..."  +1 +/
Сообщение от Аноним (114), 18-Мрт-23, 23:30 
Кстати вдогонку. Насчет производительности... Так наоборот, на си и плюсах там бОльшие тормоза были, а использование раста позволило по другому надежную архитектуру построить. Вот кусок из ссылки, что недавно скидывали про использование раст в андроиде:

"...
Safety measures make memory-unsafe languages slow

Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizers, runtime mitigations, and hardware protections. Unfortunately, these all negatively impact code size, memory, and performance.

Using Rust in Android allows us to optimize both security and system health with fewer compromises. For example, with the new UWB stack we were able to save several megabytes of memory and avoid some IPC latency by running it within an existing process. The new DNS-over-HTTP/3 implementation uses fewer threads to perform the same amount of work by using Rust’s async/await feature to process many tasks on a single thread in a safe manner.
..."
https://security.googleblog.com/2022/12/memory-safe-language...

Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

181. "Инициатива по переработке инструментария для гипервизора Xen..."  –2 +/
Сообщение от Аноним (176), 19-Мрт-23, 02:22 
Сопоставляю две странички
https://security.googleblog.com/2022/12/memory-safe-language...
https://en.wikipedia.org/wiki/Rust_(programming_language)
"In a blog post published on April 6, 2021, Google announced support for Rust within the Android Open Source Project as an alternative to C/C++.[36][37]" Запомнили апрель,2021
С 2019 по 2022 год ежегодное количество уязвимостей безопасности памяти сократилось с 223 до 85. Гистограммы показывают Равномерное снижение. Раст применяется 2 года. Значительное снижение за 4 года, далее еще отмечается что были проведены улучшения в контроле над кодом С и С++. Вообщем типичный отчет аналитического отдела. Непонятно почему снижение, работа идет но Высвечивать нужные места.
Ответить | Правка | Наверх | Cообщить модератору

223. "Инициатива по переработке инструментария для гипервизора Xen..."  +/
Сообщение от Аноним (114), 19-Мрт-23, 17:37 
> Запомнили апрель,2021
> С 2019 по 2022 год

Тебе не нравится что во второй (твоей) ссылке заявлен анонс гуглом в апреле 2021, а в статье от декабря 2022 говорится про работу с растом аж с 2019 года? Типа, несостыковочка по времени? А ты по сноске в твоей википедии прошел и потом по ссылке на этот гугловский анонс от апреля 2021? Сомневаюсь. Потому что там в конце написано, цитата:

"For the past 18 months we have been adding Rust support to the Android Open Source Project, and we have a few early adopter projects that we will be sharing in the coming months. Scaling this to more of the OS is a multi-year project."

За 18 месяцев до работа началась. До апреля 2021 года. В анонсе же говорится что _уже_ добавили поддержку раста в AOSP для всех остальных разработчиков, а не "вот сейчас соберемся и начнем добавлять и ждите через 5 лет".

> Непонятно почему снижение

Учись понимать прочитанное. Там вся статья это последовательно и доходчиво объясняет, глупо ее еще раз тебе сюда целиком копипастить, если ты ее в первоисточнике не понял. Коротко, выжимка - рассматриваются только ошибки работы с памятью. Основной вал ошибок прилетает в новом коде, потому что старый за много времени в основном был вылизан, когда сам был забагованным новым, потому вся статистика только про новый код. Старый код и компоненты прям все-все никто переписывать не собирается, это неосуществимо. В новом коде, для новых компонент, взят курс на замещение "небезопасных" языков "безопасными". Т.е. пытаются набор "си+плюсы" вытеснить набором "ява+котлин+раст". Более того: "Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language.". Правда в сегменте нативного системного кода раст составляет пока 21%, остальное на си и плюсы пока выпадает. Но взят курс на вытеснение небезопасного шлака. Потому что небезопасные языки (си/плюсы), при всём широком использовании всяких хитрых техник, инструментов и возможностей самих языков (Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE и всякое фуззинг-тестирование) в этом проекте и в других си/плюс-проектах почему-то ощутимо не помогают - там не наблюдается такого уменьшения кол-ва ошибок работы с памятью (с 223 до 85 в год). Но! Всё бОльшее вытеснение в новом коде плюсов растом позволило уменьшить. В растовском коде ошибок этого класса пока ноль. Остальное, что осталось - на совести си/плюсов (разработчиков). Стало больше раста - стало меньше си - стало меньше ошибок по памяти. По мере роста доли раста будет еще сильнее уменьшаться кол-во ошибок по памяти. Просто потому что новые модули на си/плюсах писАть перестанут, а старый плюсовой код, который не собираются переписывать, будет уже вылечен от грубых всплывших ошибок.

"As the amount of new memory-unsafe code entering Android has decreased, so too has the number of memory safety vulnerabilities. From 2019 to 2022 it has dropped from 76% down to 35% of Android’s total vulnerabilities. 2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities."


> , работа идет но

и продолжится. Даже в ядре на расте будут писАть

"What’s next?

Migrating away from C/C++ is challenging, but we’re making progress. Rust use is growing in the Android platform, but that’s not the end of the story. To meet the goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers.

As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare! "


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

Ответить | Правка | Наверх | Cообщить модератору

284. "Инициатива по переработке инструментария для гипервизора Xen..."  –1 +/
Сообщение от Аноним (13), 23-Мрт-23, 08:44 
Ага, сначала случилось это "лучше" и браузер научился течь так, что комфортно работать в какой-то момент без 24 Гб ОЗУ под один только браузер было невозможно, хотя старые версии были быстры как понос, а потом ещё половину плагинов и фич кастомизации продолбали вместе с XUL. На баги традиционно забив, один баг с рендером уже лет 5 регулярно мне в почту спамит что его опять куда-то переназначили, фиксиками и не пахнет.
Что там стало принципиально лучше - до сих пор в упор не вижу, но на корче с 4 core (+HT), 64 GB RAM и NVMe браузер умеет регулярно превращаться в лютое тормозище, приходится перезапускать. Хуже только какой-нибудь Discord и MS Teams
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

75. "Инициатива по переработке инструментария для гипервизора Xen..."  +/
Сообщение от Аноним (72), 18-Мрт-23, 14:18 
> Го медленный.

То-то  же его держат на серверах с откликом меньше миллисекунды.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

182. "Инициатива по переработке инструментария для гипервизора Xen..."  +1 +/
Сообщение от 11 (?), 19-Мрт-23, 03:17 
Быстрый GO это не тоже самое что общепринятый (общепринятый это как питон на стеридах).

А быстрый GO не больше 5 процентов гошников могут.

Ответить | Правка | Наверх | Cообщить модератору

199. "Инициатива по переработке инструментария для гипервизора Xen..."  –1 +/
Сообщение от Аноним (72), 19-Мрт-23, 11:50 
> Быстрый GO это не тоже самое что общепринятый (общепринятый это как питон
> на стеридах).
> А быстрый GO не больше 5 процентов гошников могут.

Не знаю, почему у Вас такое мнение — `net/http` из стандартной либы более чем быстр, большинство библиотек в го, как стандартных, так и сторонних, тоже довольно быстры. ЧЯДНТ?

Ответить | Правка | Наверх | Cообщить модератору

245. "Инициатива по переработке инструментария для гипервизора Xen..."  +/
Сообщение от 11 (?), 20-Мрт-23, 00:39 
>> `net/http` из стандартной либы более чем быстр

смотри с чем сравнивать. Как замена perl/python/ruby/php рвет как тузик грелку, против c/c++/rust обсирается по полной.


>>  большинство библиотек в го, как стандартных, так и сторонних, тоже довольно быстры

если делать кучу запросов к базам, к стораджам и тд, или просто быстро писать не сильно напрягаясь, то GO отличный выбор. Если надо на бирже "высокоточтку" выжимать, то как-то не то.


>> как стандартных, так и сторонних

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

>> ЧЯДНТ?

Сравниваете хрен с пальцем. GO - замена питона и прочего скриптового мусора, но там где нужно "реально быстрее всех" лучше сразу взять нормальный иструмент, c GO придется трахаться не по детски и поддерживать это довольно сложно.

Ответить | Правка | Наверх | Cообщить модератору

256. "Инициатива по переработке инструментария для гипервизора Xen..."  –1 +/
Сообщение от Аноним (72), 20-Мрт-23, 12:03 
> но там где нужно "реально быстрее всех" лучше сразу взять нормальный иструмент

А я где-то сказал, что го быстрее всех? Он достаточно быстр для многих задач, но не наибыстрейший.

Ответить | Правка | Наверх | Cообщить модератору

266. "Инициатива по переработке инструментария для гипервизора Xen..."  +1 +/
Сообщение от 11 (?), 20-Мрт-23, 22:53 
>> То-то  же его держат на серверах с откликом меньше миллисекунды.

это ваше? - все с этого началось.

если вам нужны сервисы "с откликом меньше миллисекунды" которые умеют какую-то бизнес логику, то GO не лучший выбор, только и всего. Просто все другое это 98% мира и GO там вполне подходит. ))

Ответить | Правка | Наверх | Cообщить модератору

269. "Инициатива по переработке инструментария для гипервизора Xen..."  +/
Сообщение от Аноним (72), 21-Мрт-23, 08:16 
>>> То-то  же его держат на серверах с откликом меньше миллисекунды.
> это ваше? - все с этого началось.

Согласен, перегнул всё-таки.


> если вам нужны сервисы "с откликом меньше миллисекунды" которые умеют какую-то бизнес
> логику, то GO не лучший выбор, только и всего. Просто все
> другое это 98% мира и GO там вполне подходит. ))

И то верно.
Благодарю за то, что указали на мои ошибки.

Ответить | Правка | Наверх | Cообщить модератору

214. "Инициатива по переработке инструментария для гипервизора Xen..."  –1 +/
Сообщение от Tron is Whistling (?), 19-Мрт-23, 14:01 
Микросервисы по сложению A+B и выдаче hello world - да, быстрая штука.
А вот что-то чуть посложнее... но там уже гошечкодеры не осиляют.
Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

240. "Инициатива по переработке инструментария для гипервизора Xen..."  +/
Сообщение от Аноним (72), 19-Мрт-23, 21:42 
> Микросервисы по сложению A+B и выдаче hello world - да, быстрая штука.
> А вот что-то чуть посложнее... но там уже гошечкодеры не осиляют.

То-то так "медленно" работают Syncthing, Gogs/Gitea/Forgejo, Yggdrassil, многие компоненты CoreOS (минималистичный дистриб от редхатов) написаны на Go, Hugo странички за миллисекунды генерирует, даже Ethetium на гошечке гоняется. Это не говоря уже о всяких докерах, кубернетесах, терраформах и официального компилятора Go (безусловно, скорость компилятора изначально была обусловлена тем, что первые версии были на плюсах, но впоследствии-то он сам себя компилировал)

Ответить | Правка | Наверх | Cообщить модератору

285. "Инициатива по переработке инструментария для гипервизора Xen..."  –1 +/
Сообщение от Аноним (13), 23-Мрт-23, 08:53 
В этом комментарии прекрасно всё. Если попробовать у фанов хрустика спросить где же он используется прям в живых проектах, а не hello world, то в лучшем случае найдётся ripgrep и какой-то ещё один, о которых "широко известно в узких кругах", тогда как Golang повсеместно давно и без сектантского нытья "о превосходстве"
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру