LINUX.ORG.RU
ФорумTalks

Rust developers at Google are twice as productive as C++ teams

 , ,


0

5

Google reports that Rust shines in production, to the point that its developers are twice as productive using the language compared to C++.

Чувак, кажется, побывал в ЛОРовских лолксах:

«Even six months ago, this was a really tough conversation,» he said. «I would go and I would talk to people and they would say, ‘Wait, wait you have an unsafe keyword. That means we should all write C++ until the heat death of the Universe.’»

Даже гошники заёрзали:

«When we’ve rewritten systems from Go into Rust, we’ve found that it takes about the same size team about the same amount of time to build it,» said Bergstrom. "That is, there’s no loss in productivity when moving from Go to Rust. And the interesting thing is we do see some benefits from it.

«So we see reduced memory usage in the services that we’ve moved from Go … and we see a decreased defect rate over time in those services that have been rewritten in Rust – so increasing correctness.»

И это при том что го пилился специально для того, чтобы макак и прочую бывшую студентоту было проще пылесосить учить говнокодить.

Дискасс.

https://www.theregister.com/2024/03/31/rust_google_c/

★★★★★

When we’ve rewritten systems from Go into Rust, we’ve found that it takes about the same size team about the same amount of time to build it

Вот что мне не нравится в секте адептов раста: они считают, что при агитации за свой язык можно и нужно допускать любые передёргивания. Они спокойно сравнивают затраты человеко-часов на написание приложения с нуля и на переписывание. А ведь это сильно разные объёмы работ. В первом случае нужно разрабатывать логику, протоколы, структуры данных, тесты и всё прочее. А во втором - просто перекодировать это на другом языке.

Ну и да, «you have an unsafe keyword. That means we should all write C++ until the heat death of the Universe.» :-)

Beewek ★★★
()

Наконец-то научились правильно замерять производительность программистов. Это действительно прорыв, как мне кажется.

MoldAndLimeHoney
()

Не понял как реагировать на эту статью, читая ее 1го апреля 😄

ergo ★★★
()

Ну теперь шинд^Wкрестам точно капец.

wandrien ★★
()

Я не понимаю почему Rust стал популярен у людей, чьи задачи решаются нормально и PHP. Основное что меня смущает, Rust это нескончаемая возня с памятью, зачем прописывать lifetimes если можно просто взять язык с GC? Я видел как люди пишут, что они просто все оборачивают в счетчики ссылок и другие умные указатели, но это что то странное, это непроизводительно, и неудобно.

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

Я видел лишь один проект Google на Rust, мне показалось что буквально каждая функция обернута в unsafe (возможно это был binder?). Сразу представляется история, как кого то заставляют писать на Rust, а он решает: «Хорошо, я напишу на расте, но как!». Ну или может кто то с энтузиазмом начал, не смог справится с lifetimes и просто везде вставил unsafe.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от Beewek

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

zurg
()
Последнее исправление: zurg (всего исправлений: 1)

When we’ve rewritten systems from Go into Rust

Почему всегда разговор о переписывании? Тут ведь какое дело, когда ты сморишь в код и переписываешь, ты находишь проблемы и ошибки в процессе и избавляешься от них. Если уж сравнивать, то надо писать с 0 параллельно одно и то же и вот выхлоп уже сравнивать(и по скорости и по безбажности и по продуктивности в процессе).

Loki13 ★★★★★
()
Ответ на: комментарий от Loki13

Почему всегда разговор о переписывании?

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

skiminok1986 ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Опять рабинович напел? Какая такая нескончаемая возня с памятью? это же не сишечка. В нормально спроектированной программе необходимость своими руками расставлять лайфтаймы крайне низкая.

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

Чё? Дорогой там только Arc обоснованно и понятно почему, и так что неудобно, лайфтаймы расставлять или умные указатели? с последними нет необходимости в первых

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

Как раз потому что в языках с GC все переменные, внезапно, это вот такие умные указатели

Ну или может кто то с энтузиазмом начал, не смог справится с lifetimes и просто везде вставил unsafe.

А вот тут соглашусь, есть определённая проблема с залетевшими в проект эдиками которые ни секунды не сомневаясь и не задумываясь сразу лезут в ансейф к привычным грязнокастам на сырых указателях, но это с одной стороны, а с другой - они гарантированно пометят свои художества unsafe-ами или unwrap-ми, что совершенно однозначно и формально выявляется даже простым grep-ом, а не гаданиями на статанализаторах

zurg
()
Последнее исправление: zurg (всего исправлений: 2)
Ответ на: комментарий от zurg

Опять рабинович напел? Какая такая нескончаемая возня с памятью?

В Rust уже GC добавили? Или это язык с РУЧНЫМ управлением памятью? В С++ так то тоже есть смартпоинтеры.

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

Нормальная программа это Hello World? Я просто не знаю что можно написать, не указав смартпоинтер, лафйтайм. Вот возьмем например программу есть есть граф данных, у каждой ноды свои данные, а могут быть и общие. Вот уже и никак без управления памятью.

Даже что бы вывести круг, придется возиться с памятью, смотри примеры gtk-rs.

Альтернатива, это постоянные копии. Ты мне лучше покажи эти «нормальные программы», иначе это так долго можно переговариваться.

Чё? Дорогой там только Arc обоснованно и понятно почему

Рефкаунтеры тоже имеют свою цену.

Как раз потому что в языках с GC все переменные, внезапно, это вот такие умные указатели

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 6)

Мы с C++ и вилами придём и все Ваши проблемы решим!

Forum0888
()
Ответ на: комментарий от linuxoidspb

Which of the seven most used programming languages has the most security vulnerabilities

Более точный заголовок.

theNamelessOne ★★★★★
()
Ответ на: комментарий от zurg

Как раз потому что в языках с GC все переменные, внезапно, это вот такие умные указатели

Совсем шиза. Выдыхай бобёр, выдыхай.

wandrien ★★
()
Ответ на: комментарий от thunar

Reference counting.

Если знаешь С++, то тебе это знакомо через std::shared_ptr.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

А чо ты хочешь от чела, который программирует «на индексах в массиве вместо указателей». А также доказывает производительность кода на коде без сайд эффектов, который был успешно выкинут компилятором. Какое такое управление памятью, нам в нашей деревне оно нахрен не нужно.

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

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

Подсчёт ссылок это подсчёт ссылок, а сборка мусора это сборка мусора. Два совершенно разных подхода с разными свойствами. В языки с автоматическим управлением памятью просто нет смысла пихать подсчёт ссылок, а надо сразу делать сборку мусора.

Недостатки подсчёта ссылок:

  • Замедление размазано по всей программе, поскольку каждое создание, присваивание и разрушение указателя должно сопровождаться атомарной операцией на счётчике ссылок и условным бранчем.
  • Алгоритм не способен освобождать циклические ссылки. Циклический граф ссылок никогда не будет освобождён.

Преимущества посчёта ссылок:

  • Код не имеет внезапных пауз и исполняется с предсказуемоей производительностью. Это может быть существенно важно в реал-тайм задачах.
  • Лёгкость реализации и лёгкость интеграции с существующим кодом, фреймфорками, библиотеками.

Недостатки сборки мусора:

  • Код может останавливаться в непредсказуемые моменты на непредсказуемое время. (Разные подходы к сборке мусора пытаются адресовать эту проблему, но она по своей природе фундаментальна, её можно сгладить, но не устранить.)
  • Интеграция с существующими кодовыми базами может быть трудоёмкой.

Преимущества сборки мусора:

  • Создание, присваивание и разрушение указателей выполняются с той же скоростью, что на сырых указателях. Нет накладных расходов на это.
  • Нет проблемы с циклическими ссылками.
wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 2)

Вот это я понимаю шютка на первое апреля!

Vilicus
()
Ответ на: комментарий от zurg

а с другой - они гарантированно пометят свои художества unsafe-ами или unwrap-ми

Лолкнул, буквально любая программа на расте истыкана unwrap-ами.

moonmadness
()
Ответ на: комментарий от wandrien

Подсчёт ссылок это подсчёт ссылок, а сборка мусора это сборка мусора.

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

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

Язык с GC вполне может иметь только RC для сборки мусора, и все. А инструментов/информации для построения других алгоритмов, может и не быть.

Код не имеет внезапных пауз и исполняется с предсказуемоей производительностью.

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 8)
Ответ на: комментарий от goodwin

До сих пор нет netsnmp. Приходилось юзать Сишную либу, а это в реалиях раста та ещё боль 🤦🏻‍♂️

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

skiminok1986 ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Посмотрел термины. Точно – tracing garbage collection и reference counting garbage collection.

Оба варианта могут называться garbage collection.

Значит я неверно помнил термины.

wandrien ★★
()
Ответ на: комментарий от MOPKOBKA

Это вы еще синтаксис не видели. Там даже не пахнет тем, что можно гошника затолкать на раст:

macro_rules! no_trailing {
    ($($e:expr),*) => {}
};

macro_rules! with_trailing {
    ($($e:expr,)*) => {}
};

macro_rules! either {
    ($($e:expr),* $(,)*) => {}
};
PPP328 ★★★★★
()

That is, there’s no loss in productivity when moving from Go to Rust.

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

А в гугле, видимо, все такие.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от Beewek

на написание приложения с нуля и на переписывание

Второе всегда в несколько раз сложнее:

  1. разбирать, что за хрень там написали
  2. рефакторинг, используя «современные подходы»
  3. собственно сам процесс написания того же самого с нуля
alexmaru
()
Последнее исправление: alexmaru (всего исправлений: 1)
Ответ на: комментарий от alexmaru
  1. собственно сам процесс написания того же самого с нуля

Тогда зачем растосообщество именно переписывает программы, а не пишет с нуля улучшенные аналоги? Зачем себе делать жизнь «в несколько раз сложнее»?

eyrell
()
Ответ на: комментарий от eyrell

именно переписывает программы

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

alexmaru
()
Ответ на: комментарий от alexmaru

Потому что результат нужен такой же

И как это мешает написать что-то с нуля?
Допустим, что в предметной области имеется некое множество проблем: А, Б и В, тогда решением этих проблем будет являться некое множество с результатами. Если по итогам работы вашего «черного ящика» на проблемах А, Б и В получаются решения из множества результатов, то к чему эти ограничения?

Плохое сравнение, но грубо говоря, это как переписывать pulseaudio вместо написания pipewire.

eyrell
()
Ответ на: комментарий от alexmaru

Я сначала даже не прочувствовал сарказма, поставил фейспалм. Потом всё-таки понял, фейспалм убрал. Но вы лучше всё же помечайте такие сообщения тегом «сарказм» 😊

Beewek ★★★
()
Ответ на: комментарий от eyrell

В мире опенсорса произойдут обе вещи: одни перепишут пульсаудио, а другие напишут какой-нибудь SoundManager.

Примеры первого: redis, garnet, dragonflydb. Внутри всё разное, снаружи едят те же конфиги и проходят те же тесты.

Optipng и oxipng.

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

Примеров второго дофига, почти каждый пишет свой новый аналог.

alexmaru
()
Последнее исправление: alexmaru (всего исправлений: 2)
Ответ на: комментарий от skiminok1986

Когда то все переписывали на С, потом на С++, потом на Java, node, go, C#

Теперь на раст

Все идет по старым, посконным традициям.

Что вы возбудились?

grim ★★☆☆
()
Ответ на: комментарий от eyrell

Тогда зачем растосообщество именно переписывает программы, а не пишет с нуля улучшенные аналоги?

Сам придумал, сам возмутился.

Растосообщество в большинстве своём именно что пишет с нуля улучшенные аналоги :-)

intelfx ★★★★★
() автор топика
Ответ на: комментарий от Beewek

Чуваки просто пиарятся. Мол, смотрите, как мы осилили Раст. А вообще, у нас и с плюсами всё было хорошо, но теперь ещё лучше! Эта новость больше для их внутреннего менеджмента, чем для остального мира.

seiken ★★★★★
()
Последнее исправление: seiken (всего исправлений: 1)
Ответ на: комментарий от grim

Когда то все переписывали на С, потом на С++, потом на Java, node, go, C#

Где же cat на Java, node.js, golang или c#?

Все идет по старым, посконным традициям.

Раньше масштаб был не тот.

Что вы возбудились?

Чего ж не посмеяться лишний раз? Смех полезен.

skiminok1986 ★★★★★
()
Ответ на: комментарий от seiken

Да, я на алиэкспрессе часто такое вижу. Картинка: слева «наш товар», справа «их товар». И ниже - список свойств, под «нашим товаром» - зелёные птички, а под «их товаром» - красные крестики. Хотя по факту и «наш» и «их» товар - одно и то же.

Но там это всё так бесхитростно, что сразу понятно, что маркетинговая туфта, и не воспринимается всерьёз. А тут – вроде даже какие-то «исследования» провели. А по факту - такие же врунишки.

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

Beewek ★★★
()
Ответ на: комментарий от skiminok1986

Где же cat на Java, node.js, golang или c#?

Фу, какой вы мелочный. Зачем их по одному переписывать, если можно весь shell?

https://docs.oracle.com/en/java/javase/21/jshell/introduction-jshell.html

Уроки гугления не даю, поэтому поищите на досуге на node и т.д.

Кстати, вроде на php еще shell был

Раньше масштаб был не тот.

Я не в курсе, когда у вас были старые добрые времена, когда не переписывали.

Кобол?

Ассемблер?

Так с них все постоянно переписвают.

Алгол? Фортран?

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

Чего ж не посмеяться лишний раз? Смех полезен.

Это был смех? 0_0

Я думал страдания.

Ок.

А что в этом смешного?

grim ★★☆☆
()
Ответ на: комментарий от grim

Фу, какой вы мелочный. Зачем их по одному переписывать, если можно весь shell?

https://docs.oracle.com/en/java/javase/21/jshell/introduction-jshell.html

JAVA REPL то тут каким боком?

Я не в курсе, когда у вас были старые добрые времена, когда не переписывали.

Вы однобитный? Или просто незнакомо слово «масштаб»?

Я думал страдания.

Какие же страдания? Я ж не переписываю.

А что в этом смешного?

Смешно наблюдать приближение тепловой смерти вселенной из-за моды.

skiminok1986 ★★★★★
()
Ответ на: комментарий от Beewek

Они спокойно сравнивают затраты человеко-часов на написание приложения с нуля и на переписывание. А ведь это сильно разные объёмы работ. 

В пределе — почти одинаковые. Если не больше. См. «эффект второй системы», да и законы Мерфи с Паркинсоном никто не отменял. Никто им не даст на самом деле «просто переписать». Ползучий улучшизм похоронит еще не один проект отмывальщиков бабла для Alphabet Inc.

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

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

Хотя согласен, «улучшатели» могут и тут постараться, примеры имеются.

Beewek ★★★
()
Ответ на: комментарий от skiminok1986

Извиняюсь.
Вот замена https://github.com/MichaelRoytman/UnixShell

A Unix shell written in Java

Вы однобитный? Или просто незнакомо слово «масштаб»?

Да, раньше масштабнее переписывали.

Здесь я с вами соглажусь.

Не те сейчас переписывальщики.

grim ★★☆☆
()
Последнее исправление: grim (всего исправлений: 2)
Ответ на: комментарий от Beewek

какая-то математическая модель, какие-то протоколы взаимодействия с другим софтом, разработка внешних тестов, и прочее подобное. И всё это прочее останется как есть

И устареет в момент документирования. «Покажите на этой UML-диаграмме где сломалось» (тм)

slackwarrior ★★★★★
()
Ответ на: комментарий от MOPKOBKA

В Rust уже GC добавили? Или это язык с РУЧНЫМ управлением памятью?

в каком-то смысле да, только он компил тайм; основа управления памятью в расте - ситема типов (аффинная) + RAII, а смартпоинтеры так, по вкусу, и это всё вполне себе автоматика

Я просто не знаю что можно написать, не указав смартпоинтер, лафйтайм. Вот возьмем например программу есть есть граф данных, у каждой ноды свои данные, а могут быть и общие.

Такие «проблемы» только поначалу возникают, и скорее всего из-за нажитых в других языках привычек, если программист обучаем, то всё норм, и уж точно нет проблем с графами

Альтернатива, это постоянные копии.

Неа, альтернатива - правильно спроектированная архитектура, с которой большая часть программы(в смысле управления памятью) состоит из RAII, мувинга, ссылок, стандартных контейнеров и уж только потом смартпоинтеры refcellы, и специализированные самодельные контейнеры с ансейфом и указателями

Ты мне лучше покажи эти «нормальные программы»,

да любая из базовой инфраструктуры рачта, посмотрел сейчас ripgrep(даже на лоре хвалили), c десяток файлов рандомно протыкал ни одной структуры с лайфтаймом )

Рефкаунтеры тоже имеют свою цену.

Box тоже умный указатель, но его мувинг стоит ровно столько же копирование указателя/ссылки

zurg
()
Последнее исправление: zurg (всего исправлений: 1)
Ответ на: комментарий от zurg

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

Это не проблема языка, в сложной программе невозможно определить когда именно должна быть очищена память, потому что условия для этого определяются в рантайме. Нельзя в момент компиляции вычислить где именно должен быть free.

Известно несколько решений, например GC, или различные инструменты как счетчики ссылок.

Box тоже умный указатель, но его мувинг стоит ровно столько же копирование указателя/ссылки

Я и не говорил что он влияет на производительность, но его невозможно применить в сложных ситуациях, именно поэтому есть другие смартпоинтеры.

да любая из базовой инфраструктуры рачта, посмотрел сейчас ripgrep

278 <'
24 RefCell
77 Arc

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от PPP328

Это определение макросов, метакод. Когда метакод выглядел просто? В пользовательском коде будет no_trailing!(...), with_trailing!(...) и either!(...). Очень страшно 😱

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

Когда метакод выглядел просто?

В любых нормальных языках, не?

В пользовательском коде будет

А плевать что будет в пользовательском когда в макрос прилетит что-то, чего там быть не должно. Отладку вести как?

PPP328 ★★★★★
()

Дискасс.

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

alysnix ★★★
()
Ответ на: комментарий от PPP328

Когда метакод выглядел просто?

В любых нормальных языках, не?

Пример, пожалуйста, «нормальных» ЯП с просто выглядящим метапрограммированием.

А плевать что будет в пользовательском когда в макрос прилетит что-то, чего там быть не должно. Отладку вести как?

Месье идиот? У конпелятора есть параметр для разворачивания макросни в генерируемый макросом код. Далее, макросы разворачиваются в компайлтайм, то есть «прилететь» туда может только то, что кодер-идиот завернет в макрос в коде своими руками осознанно.

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

Месье идиот? У конпелятора есть параметр для разворачивания макросни в генерируемый макросом код

Класс, особенно классно что ревья код в бакете где нет ни компилятора ни отладчика я не могу глазами увидеть ошибку другого программиста.

Я вот тут умышленно ошибку совершил. Ну давайте, найдите глазами не сравнивая код с эталонным выше.


macro_rules! either {
    ($($e:expr),* $(,)) => {}
};
PPP328 ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)