LINUX.ORG.RU

Corrode, проект транслятора из C в Rust, получил финансирование Mozilla

 , corrode, , ,


3

8

Джеймс Шарп (James Sharp), отметившийся ранее в проекте X.org, в начале мая 2016 начал разработку проекта Corrode, целью которого является трансляция программ, написанных на C, в исходный код на Rust. Corrode написан на Haskell и распространяется под GNU GPLv2.

На текущий момент проект обзавёлся сообществом, научился транслировать некоторые программы и обрёл первые ближайшие цели и ориентиры: трансляция неподдерживаемых программ на C в Rust. В качестве субъекта тестирования был выбран исходный код CVS — давно устаревшей, но ещё используемой, системы контроля версий. Разработка и поддержка CVS была остановлена в 2008 году, а первая до сих пор не закрытая remote-уязвимость была обнаружена в 2012 году.

Джеймс рад сообщить, что он получил финансовый патронаж Mozilla, и как минимум на ближайшие несколько месяцев он может сконцентрироваться на своём свободном проекте. Mozilla рассматривает Corrode не только в качестве полуавтоматического транслятора для устаревшего кода, но и как статический анализатор нового поколения для кода на C.

>>> Подробности

★★★★★

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

Скорее вкусовщина.

Ну окай. Хотя симптоматика характерная.

В то время как у C++ страх и ненависть.

Походу, у вас «говно» == «малый размер».

cargo.

Ну вот cargo у Rust-а — это действительно киллер-фича по сравнению с C++.

Но уже сейчас для многих задач он в разы лучше С++.

Если из C++ выбросить все хорошее, что в нем есть, а потом еще и добавить C++хейтерства, то да, на Rust-е для C++неосиляторов будет в разы лучше и проще. Это уже многократно доказывалось, хоть с ObjectPascal, хоть с Java, хоть с C#.

Расскажите свою историю успеха о написание такого титанического проекта, как браузер, за 2-а года.

Servo уже стал браузером? Как интересно. Или у тех, кто не осиливает исключения, нет разницы между движком и самим браузером?

А вообще, если я правильно помню, движки для Netscape, Opera и KHTML появлялись как раз за 1.5-2 года разработки.

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

Походу, у вас «говно» == «малый размер».

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

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

Походу, у вас «говно» == «малый размер».

Только прога на раст слинкованная с std статически весит меньше, чем на C++. И да, смысла от маленькой std нет. Вон в расте есть базовый no_std, для эмбдеба. И std для белых людей. А в плюсах всё через одно место.

C++хейтерства

Я на плюсах пишу лет 5 уже. О какой хейтерсве идёт речь? Для многих моих задач раст подходит лучше. Поэтому я на него и свалил. Ни о какой фанатизме тут речи не идёт.

Или у тех, кто не осиливает исключения, нет разницы между движком и самим браузером?

Лол. Расскажите что там в браузере кроме движка то есть? Насколько я знаю, в том же хроме blink(бывший webkit) занимает большую часть кодовой базы. Потом идёт v8 и уже потом сам «браузер».

А вообще, если я правильно помню, движки для Netscape, Opera и KHTML появлялись как раз за 1.5-2 года разработки.

Опять напарываетесть на неверные сравнения. Эти движки писались во времена html4, css2 и почти полном отсутствии js. За последние 20 лет, знаете ли, многое изменилось.

Для сравнения, у меня новая версия KDE (у меня gentoo) собирается 1-1.5 часа, а chromium - 5. Там миллионы строк кода, которые нереально написать за пар лет. Тем более с такой маленькой командой. Ну и не будет забывать, что Servo - это эксперимент по переосмыслению подхода написания движка. В частности сейчас они активно экспериментируют с layout'ами и рендером.

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

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

В каком месте? У cppstd нет даже работы с fs.

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

А в плюсах всё через одно место.

Что-то из вас конкретику клещами вытаскивать нужно. Покажите на примере что и где через одно место.

Я на плюсах пишу лет 5 уже. О какой хейтерсве идёт речь?

О самом настоящем. Ну и да, 5 лет как раз подходящий срок, когда типа что-то знаешь, что-то видел и мнение имею.

Расскажите что там в браузере кроме движка то есть?

GUI, IO, интеграция с ОС.

Эти движки писались во времена html4, css2 и почти полном отсутствии js. За последние 20 лет, знаете ли, многое изменилось.

Изменилось. Только тогда все приходилось делать с нуля. И алгоритмы обработки html-элементов во время подкачки страницы, и эффективную работу с css и пр. вещи нужно было выдумывать, пробовать, переделывать.

что Servo - это эксперимент по переосмыслению подхода написания движка

О том и речь, что даже Servo оказался экспериментом. Т.е. самая большая разработка на Rust-е на данный момент — это даже не продакшен код. Так что говном в C++ бросаться легко, ибо на Rust-е ничего сравнимого по объему и сложности просто нет, посему Rust весь такой в белом.

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

Покажите на примере что и где через одно место.

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

GUI, IO, интеграция с ОС.

Ну так это в эти 5% и попадает.

Об остальном даже говорить не буду. Ваш фанатизм не перестаёт удивлять.

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

А смысл?

Ну реально интересно.

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

Не начну, обещаю.

Тут вот какая штука. Для меня STL — это не вся стандартная библиотека C++. В стандартную библиотеку C++ входит и изрядная часть стандартной библиотеки C, и такая неоднозначная вещь, как iostreams.

А STL — это то, что привнесли в C++ Степанов и Ли в середине 90-х, в первую очередь шаблоны классов vector, set, list, deque и т.д., включая концепцию внешних итераторов (которая при этом замечательно согласуется с унаследованными из C указателями).

Так вот когда вы говорите, что STL говно, очень интересно узнать почему. Мне довелось попользоваться той же Java, когда в ней генериков еще не было. И убедиться, что STL — это реально крутая вещь, отсутствие которой очень быстро ощущается.

Ну так это в эти 5% и попадает.

Правда? Кросс-платформенный GUI — это 5% от рендера страничек. Афигеть.

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

Кросс-платформенный GUI — это 5% от рендера страничек

Вы не поверите. (С)

Что там хроме от GUI? Верхня панелька вот и всё. Системную тему он не умеет, выглядит везде чужеродно. Движок GUI у него вообще свой. Вот и получаем, что от GUI там рожки да ножки. К примеру тот хромиум, который QtWebEngine весит почти столько же, сколько и хром, но не включает в себя гуи.

Понятное дело что я по сорцам не лазил, и все лично не сравнивал. Поэтому это лишь моё логическое заключение.

vector, set, list, deque

А там больше ничего и нет. Достаточно посмотреть какое количество классов содержит буст и Qt. В случае раста, весь QtCore уже реализован. И не нужно в каждой либе реализовывать свой костыль.

Но если вы просите - пожалуйста. Список того, что мне не хватает в std по аналогии с Rust:

  • option (есть в бусте, но кривой/небезопасный)
  • result (чуть менее чем полностью нереален под плюсами)
  • fs (path, file, etc.)
  • строки
  • кроссплатформенный доступ к аргументам CLI, а не указатель на char, который может содержать что угодно
  • тоже самое, но для env
  • slice (есть отдельные реализации, да)
  • any
  • нормальный print, а не убожество типа iostream и не грабли типа printf.
  • возможность запуска процессов, типа qprocess
  • работа с потоками, futures (уже есть немного, но пока примитивное)

Вот в целом и всё. Библиотека rust не намного впереди, но всё нужное есть и реализовано для людей и без UB. Все остальные ништяки в cargo.

Я даже больше скажу: меня больше бесит не убогость cppstd, а невозможность её расширения. boost не в счёт, ибо он еще более наркоманский. А все остальные пишут как хотят, изображая свои контейнеры, модели владения, синтаксис, апи и вообще все что только можно. В итоге половину либ без врапперов использовать нереально, а вторая половина не работает под всеми ОС/компиляторами.

Ну и еще 100500 претензий, но они решаются только сменой языка. Типа удобных tuple, enum и прочего.

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

result (чуть менее чем полностью нереален под плюсами)

Можно подробнее? Я набыдлил себе Result и в основном доволен. Акробат Александреску набыдлил Expected.

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

Список понятен. Кратко характеризуется так: «хочу иметь все, что нужно _мне_ в stdlib, не хочу брать это из сторонних библиотек и мне абсолютно похрен, что кому-то от stdlib нужно что-то другое». Складывается впечатление, что на C++ вы программировали только и исключительно в рамках уютненького мирка Qt.

Одна из реальных проблем C++ в том, что в нем нет и не предвидится аналога cargo (Maven, RubyGems, cabal и иже с ними). Тут у Rust-а неоспоримое преимущество.

Ирония, однако, в том, что часть вашего списка попадет в С++ stdlib еще до того, как на Rust-е напишут что-то большое и полезное.

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

работы с потоками нет в libstdc++? а ну тогда всё понятно, что уж тут непонятного. не пиши на С++ никогда, пожалей задницу сгорит же к чертям собачьим срать будет нечем.

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

Вы не поверите. (С)

Наличие std::thread ни о чём не говорит. Продвинутой работы, типа pthread тут нет. Удобств типа QtConcurrent тоже.

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

хочу иметь все, что нужно _мне_ в stdlib, не хочу брать это из сторонних библиотек и мне абсолютно похрен, что кому-то от stdlib нужно что-то другое

Лол, ват? Я хочу то, что уже есть в других std. Я ничего своего не придумываю. Список выше состоит из того, что есть в rust, что мешает иметь это в cpp?

исключительно в рамках уютненького мирка Qt.

Как что-то плохое. Выглянешь оттуда, аж страшно становится. Уж лучше раст.

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

Ирония, однако, в том, что часть вашего списка попадет в С++ stdlib еще до того, как на Rust-е напишут что-то большое и полезное.

Какая выборочная вы ванга. Значит это попадёт в stdc++, а раст не влетит. Отсыпьте и мне.

не предвидится аналога cargo

И единого стиля форматирования.

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

без растовских энамов не такой удобный.

Ну, ADT тоже можно изобразить довольно близко. Конечно, это не Rust и не Ocaml, но довольно близко. Никакого «полностью нереален».

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

Список выше состоит из того, что есть в rust, что мешает иметь это в cpp?

Например, то, что Rust пока еще нигде всерьез не используется. Есть всего один вендор (как компилятора, так и стандартной библиотеки). Нет диверсификации, как в C++, где в hard-real time используют один C++, а в каком-нибудь Facebook-е совсем другой.

Вы, видимо, никогда не сталкивались с ситуациями, когда люди отказывались использовать классы из STL (те же std::string и std::vector) в интерфейсах своих библиотек. При этом приводя кучу причин в качестве обоснования (не все из них имели смысл, но людям это не мешало).

Выглянешь оттуда, аж страшно становится.

Вы не поверите, но в C++ community есть куча людей, которым страшно становится от заглядывания в мир Qt.

С++ он сильно разный и используется в сильно разных областях. Плюс не имеет единого центра масс, как в случае с Rust-ом и Mozilla. Отсюда и очень медленное наполнение C++ной stdlib вещами, которые могут быть полезны более-менее значительно части пользователей, идет крайне медленно.

Однако, проблема в том, что вы позволяете себе называть STL говном не понимая всего этого.

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

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

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

Значит это попадёт в stdc++, а раст не влетит. Отсыпьте и мне.

Ну, если вы в словах «Ирония, однако, в том, что часть вашего списка попадет в С++ stdlib еще до того, как на Rust-е напишут что-то большое и полезное» видите тезис «раст не взлетит», то вам уже хватит. У вас и так трава позабористей моей.

Часть того, что вы описываете уже входит в C++17 (optional, filesystem, variant, any).

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

алгоритмы обработки html-элементов во время подкачки страницы, и эффективную работу с css и пр. вещи нужно было выдумывать, пробовать, переделывать.

Именно это и происходит сейчас в Servo. Основная цель проекта — параллельный браузерный движок. Алгоритмы есть, но их нужно параллелизовать, причем эффективно, а не воткнуть пару openmp директив и радоваться.

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

не сталкивались с ситуациями, когда люди отказывались использовать классы из STL

Увы, сталкивался. И это печально.

позволяете себе называть STL говном не понимая всего этого.

И продолжу это делать. Ведь мои претензии вы не опровергли (муть на тему «так и надо» не подходит под оправдание).

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

Потому, что серьезное использование != 1MLOC. Вы сами выдумываете критерии, а потом, задним числом, их озвучиваете.

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

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

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

Я знаю что оно будет в 17, но то, как оно реализовано меня убивает.

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

Мне довелось попользоваться той же Java, когда в ней генериков еще не было. И убедиться, что STL — это реально крутая вещь, отсутствие которой очень быстро ощущается.

А мне довелось попользоваться более свежими версиями Java с нормальным Collections API, где не надо на каждый чих передавать пары итераторов и нет таких невыразительных идиом, как erase-remove. С появлением ranges в стандарте ситуация, по видимому, улучшится, но пока это случится (а в С++17 уже не случится), в менее ретроградских языках появится ещё множество фич, которых будет не хватать в плюсах (впрочем, их и так достаточно).

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

Потому, что серьезное использование != 1MLOC. Вы сами выдумываете критерии, а потом, задним числом, их озвучиваете.

Задним числом? У вас с головой все в порядке. Здесь уже несколько страниц вокруг вот этого тезиса: «Так что говном в C++ бросаться легко, ибо на Rust-е ничего сравнимого по объему и сложности просто нет, посему Rust весь такой в белом.»

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

А 60KLOC на Rust-е в Dropbox-е — это, может быть и примечательно для фанатов Rust-а, но, блин, не идет ни в какое сравнение с уже упомянутыми здесь Chrome и Firefox. И, блин, именно поэтому Mozilla выбрала путь очень медленного включения в FF кода на Rust-е.

Увы, сталкивался. И это печально.

Печально и что? Валить на Rust? Тем, у кого миллионы строк на C++?

А ну да, это же не серьезно.

И продолжу это делать.

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

Ведь мои претензии вы не опровергли (муть на тему «так и надо» не подходит под оправдание).

Вы правильно указали: ваши претензии. Кроме ваших претензий есть еще и претензии других людей, которым на вас начхать так же, как и вам на всех остальных. Язык C++ существует в этих условиях уже не один десяток лет. Поэтому он такой, какой есть. И библиотека у него именно такая. И, по определению, чтобы в стандарт не включили, всегда будут недовольные, вроде вас.

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

Вы это сейчас серьезно? Вот про это: «If you want to run code on many platforms, go for Posix Threads.»

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

Тогда почему вы выдаете этот список за примеры _серьезного_ использования Rust-а?

А какое использование считается серьезным и почему именно такое? Вот обзор, где люди говорят, что пишут на Rust проекты 100+ kLoC на работе. Почему это не серьезно?

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

А мне довелось попользоваться более свежими версиями Java с нормальным Collections API, где не надо на каждый чих передавать пары итераторов и нет таких невыразительных идиом, как erase-remove.

При этом в C++ полно ретроградов, которых даже работа с парами итераторов и erase-remove не устраивает. Ну и, поскольку, C++ развивает совсем по другим правилам, чем Java, то в стандарте C++ не будет многих вещей, которые есть в менее ретроградских языках.

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

А какое использование считается серьезным и почему именно такое?

Потому что спор начался с обсуждения больших и сложных проектов, вроде KDE, FireFox-а и Chrome.

Потому, что речь идет о технологических вещах. И точка зрения бизнеса на «серьезное использование» может сильно отличаться от точки зрения разработчика.

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

У cppstd нет даже работы с fs.

Ну в расте есть, хорошо. Вот только всё равно имеются всякие штуки типа walkdir, filetime и и т.д. Не иначе как от любви к велосипедостроительству. Или всё-таки чего-то не хватает?

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

И когда в стандарт затащат filesystem, то есть ощущение, что возможностей там побольше будет.

В каком месте?

В разных. Коллекций, например, меньше. Если что, я ничего не говорил о необходимости «недостающего».

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

option (есть в бусте, но кривой/небезопасный)
fs (path, file, etc.)

Справедливости ради, вот-вот (в C++17) завезут, а первый начиная с какой-то TS уже лежит в experimental.

result (чуть менее чем полностью нереален под плюсами)

Насколько я понял, в расте так Either называют? В плюсовом std его действительно нет, но непонятно, в чём нереальность — разве что неудобство в связи с отсутствием паттернмэтчинга.

строки

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

кроссплатформенный доступ к аргументам CLI, а не указатель на char, который может содержать что угодно

А под какими платформами с этим возникают проблемы?

нормальный print, а не убожество типа iostream и не грабли типа printf.

Это уже сугубо вкусовщина.

Ну и еще 100500 претензий, но они решаются только сменой языка. Типа удобных tuple, enum

А чем плох enum class? Косяки сишных перечислений исправлены, компиляторы умеют ругаться, если в switch по значению такого перечисления указать не все варианты.

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

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

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

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

Нет. Вы что-то себе вообразили.

Тезиса, на самом деле, всего два:

1. С++ уже показал, как он себя ведет в больших и сложных проектах. Rust еще нет. Поэтому пока Rust весь такой в белом. Как оно будет, когда на нем наговнячат столько же — вопрос.

2. Обозвать STL говном легко. Объяснить почему это так — гораздо сложнее. А вам, похоже, очень сложно понять, почему STL такой. И почему в Rust, пока, возможно по другому.

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

enum в терминах Rust - это ADT.

и собственно что?

И собственно не стоит сравнивать его с enum class - это разные вещи.

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

Вот только всё равно имеются всякие штуки типа walkdir, filetime и и т.д.

В том то и дело, что rust стараются как можно больше выкинуть из std, ибо можно легко подключить нужное через cargo. В с++ такое невозможно.

даты/времени

Есть. std::time. Умеет она столько же, сколько и cpp версия. Даты нет у обоих.

которые в плюсах имеются

Пару лет как.

Коллекций, например, меньше.

Разве?

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

В с++ такое невозможно.

Невозможно что именно? «Невозможно подключить» или «невозможно легко подключить».

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

вот-вот

Вот-вот и модули завезли, и ranges.

разве что неудобство в связи с отсутствием паттернмэтчинга.

Да.

А под какими платформами с этим возникают проблемы?

Под любой. Кодировка может быть любой.

Это уже сугубо вкусовщина.

Чем? Гугл завален статьями вида «printf pitfalls».

А чем плох enum class?

Тем, что он не может содержать значение, как в rust.

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

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

Ага. Показал. Именно поэтому придумали D, Rust и всех остальных убийц.

очень сложно понять, почему STL такой

Я прекрасно понимаю. Но пользоваться им от этого не легче.

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

Можно подключить только при условии, что автор используется тот-же стиль, что и в std. Ту же модель памяти. Те же контейнеры. Протестировал под всеми ОС и компиляторами.

Примеров таких либ очень мало.

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

Окей, тогда зачем отдельно упоминать result, если он и есть один из простейших ADT?

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

fs (path, file, etc.)

В расте оно довольно куцее.

any

Любопытно: для чего тебе растовый Any пригодился?

больше бесит не убогость cppstd, а невозможность её расширения.

В каком смысле?

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

Именно поэтому придумали D, Rust и всех остальных убийц.

Спасибо, поржал. Из всех остальных убийц успеха добилась только Java. Ну, отчасти, C# на Windows.

Можно подключить только при условии, что автор используется тот-же стиль, что и в std.

За пределами Qt-шного мира это уже давно так. И с каждым годом становится все лучше и лучше. А Qt-шники должны платить и каятсястрадать.

Протестировал под всеми ОС и компиляторами.

Да, тут уж у Rust-а преимущества просто капец какие :))) Как у неуловимого Джо.

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

В расте оно довольно куцее.

С аргументацией никак?

для чего тебе растовый Any пригодился

Пока не для чего. Но QVarian довольно часто использовал, а это почти одно и тоже.

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

Ну, отчасти, C# на Windows.

Про него лучше не вспоминать. Благодаря ему, под винду на плюсах никто уже не пишет.

И с каждым годом становится все лучше и лучше.

Тем временем языку под 40 лет. Надеюсь еще лет через 10 всё станет совсем хорошо.

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

Благодаря ему, под винду на плюсах никто уже не пишет.

Да, тут давеча Adobe взял и переписал все на C#.

Надеюсь еще лет через 10 всё станет совсем хорошо.

Совсем хорошо не станет. Ибо есть диверсификация, о которой речь шла выше.

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

Ну и вы опять за своё: легаси - это отдельная история.

Да это вы, походу, имеете дело с програмульками на 20KLOC, которые взял и переписал за три-четыре месяца на другой язык, когда текущий надоел.

Кроме того, C++ никогда не был языком для разработки прикладного софта. Даже тогда, когда его пихали повсюду из-за того, что тогдашние 86-е и 286-е машины были в разы слабее, чем современные смартфоны. С++ — это язык для задач, где ресурсоемкость и производительность имеют значения. Photoshop на C++ — это разумно, Chrome/FireFox — разумно, MSSQL/Oracle — разумно. Какой-нибудь «АРМ Кладовщика» — нет.

То, что C# (как и Java чуть раньше) выжили С++ из многих неподходящих для него ниш — это очень хорошо.

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

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

Вот тебе такой пример: некоторое время назад на лоре один человек очень жаловался на растовые строки: мол нужно «бесполезные» to_string писать и конкатенация не работает так удобно, как в «других языках».

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

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

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

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

А некоторым некоторым вещам всё-таки надо быть стандартными. Я не зря про время заговорил: возникла необходимость конфиги читать на расте, решил TOML использовать - как никак «родной» формат для карго. И всё бы здорово, но растовая релизация даты читать не умеет в принципе (даже в строку), хотя в сорцах какие-то подвижки на эту тему и имеются. В итоге вместо элегантного решения через сериализацию приходится промежуточную структуру вводить, читать туда, а потом разбирать дату. Из медатанных файлов, опять же, можно получить SystemTime, которой к датам имеет опосредованное отношение. Ну и прочие такие приятности. Что-то мне подсказывает, что будь дата в std всё было бы проще.

Даты нет у обоих.

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

Пару лет как.

И?

Разве?

В расте: Vec, VecDeque, LinkedList, HashMap, BTreeMap, HashSet, BTreeSet, BinaryHeap. В плюсах: vector, deque, list, forward_list, set, multiset, map, multimap, unordered_set, unordered_multiset, unordered_map, unordered_multimap плюс несколько «адаптеров».

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

С аргументацией никак?

Мне казалось, что оно очевидно, но ладно, давай сравнивать вместе:

  • Рекурсивный обход файлов в расте надо велосипедить (или брать библитеку). В плюсах из коробки.
  • Есть в расте аналог filesystem::space_info?
  • Как в расте скопировать директорию? В плюсах можно, более того - с кучей настроек копирования (filesystem::copy_options).
  • std::fs::Permissions позволяет узнать аж одно свойство (readonly), в std::filesystem::perms «немного» побольше свойств.
  • Похожая ситуация с типами файлов.
  • В плюсах есть create_symlink, create_directory_symlink, а в расте предлагается использовать std::os::unix::fs::symlink или std::os::windows::fs::{symlink_file, symlink_dir} - это к вопросу «идентичной работы на всех ОС».
  • absolute, system_complete, resize_file, hard_link_count в раст не завезли?

Но QVarian довольно часто использовал, а это почти одно и тоже.

Как по мне, то это довольно разные вещи.

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

Благодаря ему, под винду на плюсах никто уже не пишет.

Пишут.

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

что будь дата в std всё было бы проще.

Посмотрим. Дату можно впихнуть, но только примитивную. В этом и проблема. То есть без локализации, ДНЭ, високосного года и секунды, юлианского календаря и прочих заморочек.

Тем не менее есть https://github.com/lifthrasiir/rust-chrono

Про контейнеры не понял. Всё тоже самое. Разве что мультимап отдельно пока: https://crates.io/crates/multimap

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

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

Есть в расте аналог filesystem::space_info?

Он даже в Qt только в 5.4 появился. Там какие-то заморочки с ним.

В плюсах есть create_symlink, create_directory_symlink,

Там в доке чётко написано, что не у всех fs это есть, а значит вы можете словить исключение.

std::fs::Permissions позволяет узнать аж одно свойство (readonly), в std::filesystem::perms «немного» побольше свойств.

https://doc.rust-lang.org/std/os/unix/fs/trait.PermissionsExt.html

hard_link_count

https://doc.rust-lang.org/std/os/unix/fs/trait.MetadataExt.html#tymethod.nlink

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

Именно это и происходит сейчас в Servo. Основная цель проекта — параллельный браузерный движок. Алгоритмы есть, но их нужно параллелизовать, причем эффективно, а не воткнуть пару openmp директив и радоваться.

Да, эффективно. Вчера в очередной раз посмотрел на эффективность этого Servo. Вот результат за приблизительно минуту тестирования: https://postimg.org/image/b0thfx14v/ Грешным делом думал, что увижу панику, но увидел дедлок. А так да, наплодить 337 потоков и грузить ими сайт с полной загрузкой всех ядер процессора в десять раз дольше, чем это делает хром (а после этого при прокрутке - вообще зависнуть намертво) у серво получается замечательно. Кстати, правильно рендерить оно до сих пор не умеет даже примитивный LOR (так что не рассказывайте мне про HTML5/CSS3). И вот у меня вопрос: а что же, собственно, авторы хотели продемонстрировать этим серво? Надёжность? Фейл. Безопасную работу с потоками? Снова фейл. Скорость разработки? Фейл, фейл, фейл.

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

Повторяю для тупых: проект даже не pre-alpha, а early preview. То, что он собирается - уже чудо. Чтобы ожидать от него стабильной, полноценной работы уровня Firefox/Chromium нужно быть ...

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

Один из авторов на презентации говорил, что только в мозиле этим серво постоянно занимаются 4 человека. Плюс ещё столько же постоянно занимаются им вне мозиллы. Итого, умножаем на 4 и получаем ~32 человеко-года. Неплохо для хреновины, которая ни для чего непригодна. Но хрен бы с этим. Для движка, который в перспективе будут использовать миллиарды людей, на это можно было бы забить. Но тут есть другой аспект. А позволяет ли вообще Rust работать над проектом большим командам, чтобы, подобно Java, «бить по площадям» и получать скорость разработки за счет распараллеливания задач между большим числом разработчиков? Такое впечатление, что и с этим в расте как-то не очень)

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

Один из авторов на презентации говорил, что только в мозиле этим серво постоянно занимаются 4 человека. Плюс ещё столько же постоянно занимаются им вне мозиллы. Итого, умножаем на 4 и получаем ~32 человеко-года.

Уже фейл - Патрик Уолтон занимался транслятором Rust не в меньшей степени, чем Servo.

32 человеко-года

Сравни эту заведомо завышенную оценку с Хромом.

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

Повторяю для тупых: проект даже не pre-alpha, а early preview.

Это просто словоблудие. Вот новость: Началось формирование и тестирование сборок движка Servo Когда проект выкатывается на публику, это обычно называется даже не альфой (для внутреннего тестирования), а бетой (для «посмотреть» посторонним).

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

Сравни эту заведомо завышенную оценку с Хромом.

Похоже, ты не до конца прочитал что я тебе написал.

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

Вот новость: Началось формирование и тестирование сборок движка Servo

«В настоящее время, как сообщается, движок не полностью совместим с веб-стандартами и готов лишь для проведения тестирования и экспериментов».

ШОК.

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

Я где-то писал, что ждал от него совместимости с веб-стандартами?

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

В настоящее время, как сообщается, движок не полностью совместим с веб-стандартами и готов лишь для проведения тестирования и экспериментов

Я где-то писал, что ждал от него совместимости с веб-стандартами?

Ты ожидал от него эффективности и правильного рендеринга. И, вероятно, ты ожидал, что он будет работать.

Похоже, «цифр» нет у тебя. Я то свои привёл.

Приведенные цифры неверны, интересные не приведены.

Похоже, «цифр» нет у тебя

Я и не бросаюсь «фейлами».

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

Приведенные цифры неверны, интересные не приведены.

Ещё раз: приведенные цифры озвучены одним из авторов. И это - оценка снизу, т.к. не учитывает участников, вносящих вклад не на постоянной основе.

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

Окей, даже по твоей заведомо неверной методике: https://github.com/GoogleChrome
57 человек, как минимум, работают на постоянной основе, как минимум с 2008 года, (хотя это не так, 2008 это первый стабильный релиз).
57 * 8 = 456 человеко лет.

456 / 32 = разница в 14.25 раз

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

Ещё раз: приведенные цифры озвучены одним из авторов.

Озвучены цифры про 4 человек. О том, что они занимаются исключительно Servo 4 года - это твои домыслы.

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

Озвучивались цифры про 4 человека внутри Мозиллы

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

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

То, что он собирается - уже чудо

То есть обычно подобные проекты первые несколько лет разрабатывают, не собирая?

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

А что там интересного? Твои фантазии и рассуждения о том, о чем ты совершенно ничего не знаешь?

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

В плюсах нет fs. Пока оно появится во всех популярных компиляторах [...]

Оно появится не в компиляторах, а в стандартной библиотеке. Так как оно уже в experimental, то нет никаких оснований полагать, что перевод в std займёт много времени.

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

Шта? О каком внутренеем тестировании идёт речь, есть проект FOSS?

Он будет бета, когда авторы скажу, что это бета. Сейчас же это nightly build. Ни одного релиза еще не было.

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

Тем не менее есть https://github.com/lifthrasiir/rust-chrono

На нём и остановился. Теперь бы как-то заставить все остальные библиотеки, которым нужно время, использовать именно chrono.

Всё тоже самое.

Как минимум, forward_list нет.

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

То, что он собирается - уже чудо.

Шедеврально. Если бы про проект на каком-то другом языке такое сказали, наверное обосрали бы и проект, и язык, и проектную команду. Но тут же Rust, как же можно.

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

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

С этим не спорю, но чисто с практической точки зрения меня более чем устраивает boost.

https://doc.rust-lang.org/std/os/unix/fs/trait.PermissionsExt.html

std::os::unix - не катит, уж лучше None возвращать, если оно не поддерживается.

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

Будем посмотреть. Авторы сейчас компилятором заняты, а не std.

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

Rust при том, что Servo — это большой флаг, которым долго размахивают растоманы. Оказывается, это чудо, что этот флаг вообще компилябильный :)

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

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

А так да, наплодить 337 потоков

Это что, правда? Приложение создало 337 потоков на обычной десктопной машине?

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

Я думаю, в активной фазе загрузки их было ещё больше, но к моменту зависания их осталось 337 (как видно из скриншота эппловского Activity Monitor; открыто 2 сайта - linux.org.ru (в фоне) и zr.ru (на котором Servo и застыл)).

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

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

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

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

Единственные кто им размахивают - это хейтеры, которые приплетают его к месту и нет.

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

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

Мозиле явно не хватает вашей экспертной оценки их работы.

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

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

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

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

Ну да, нить на кору - выбор Ъ-профессионалов.

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

Мозиле явно не хватает вашей экспертной оценки их работы.

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

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

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

Да тут выше asaw как раз очередной замер и провел.

Ну да, нить на кору - выбор Ъ-профессионалов.

Не, нить на кору — старперство и провинциальность. А вот 100 нитей на кору — это модно и молодежно. Главное же что? Что язык хипстерский, а проект экспериментальный. Нахрен кому-то какие-то нормальные результаты.

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

какой эксперт придумал

тю, в смысле, какой эксперт? да в какого «убивателя С++» не ткни.

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

тут даже раст ни при чем. это идеология такая

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

привычки писать на С++ как на жаве. Одной из фишек такого подхода является порождение охренительного количества потоков на каждый чих. тысячи потоков.

Я, конечно, не эксперт по Java-идиомам, но мне казалось, что там принято иметь ExecutorService и посылать ему задачи (а новомодный Stream API умеет в data-level параллелизм сам), а использовать в клиентском коде голые Thread-ы — дурной тон.

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

да есть такое но в том то все и дело что это НОВОЕ API.

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

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

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

про жаву есть тыщи ссылок в гугле про java thousand threads.

да это именно оно. это восстание java-рабов и раст их Спартак

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

про жаву есть тыщи ссылок в гугле про java thousand threads.

c++ thousand threads

About 560,000 results

java thousand threads

About 361,000 results

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

...но я понимаю, откуда такой баттхерт

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

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

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

не решит, конечно же. рукожопые решили что они обманут реальность и свои кривые руки. ага

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

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

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

Ты главное будь уверен в своей правоте и в том, что твой C++ — идеален, и у меня всегда будут джоб-офферы на контрасте с подобными тебе личностями :)

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

на Rust-е

Сомневаюсь что в близжайшие 5 лет раст отхватит достаточную долю рынка, чтобы появились rust-only вакансии. Сейчас знание раста «будет преимуществом» в паре Российских компаний, забугорные не мониторил.

на D

Сомневаюсь что когда-нибудь вообще на D будут вакансии.

Но я не про ЯП, я про гораздо более прозаичный аспект работы HR и интервьюверов. Я про адекватность и трезвый взгляд на мир.

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

Я про адекватность и трезвый взгляд на мир.

Тогда у вас шансов больше, чем у 75% пишущих на LOR-е. Как минимум :)

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

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

Да тут выше asaw как раз очередной замер и провел.

Да, это был экспертный замер производительности.

Главное же что?

Очевидно же, что главное - это то, что ты назовешь главным.

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

я не удивлен, что жабнутые пишут на c++

Или сплюплюснутые пишут на жабе.

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

Наверное, удобно считать жабистом каждого, кому не нравится Си++.

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

Или сплюплюснутые пишут на жабе.

С учетом того, сколько народу пришло в ИТ в последние 10 лет (т.е. когда C++ потеряли какую-либо популярность), это сильно вряд ли.

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

337-ми потоках на загрузку 2-х сайтов

Дык зато как удобно на распределенном кластере запускать то будет!

ИМХО, Servo это не о «выкатить замену Gecko или Webkit», а об экспериментах и поле для исследований на тему высокопараллельных алгоритмов.
С ростом количества вычислительных ядер (а тенденция есть) это даст свои плоды, да и я не думаю что перенести всё это на гринтреды на манер Go и распихать их по малому количеству posix-нитей будет проблемой. Во всяком случае это намного меньшая проблема, нежели распараллеливание существующих браузерных движков.

Плюс это дает приятные бонусы вроде ускорения обработки CSS с помощью GPU, которые можно портировать в продакшн-продукты

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

Дык зато как удобно на распределенном кластере запускать то будет!

Рендеринг страничек для браузера в кластере — это вы мощно задвинули, внушаить.

я не думаю что перенести всё это на гринтреды на манер Go и распихать их по малому количеству posix-нитей будет проблемой.

Блин, вы себе хотя бы отдаете отчет, что распределение задач по короутинам (коими и являются goroutines в Go) и распределение задач по полноценным OS threads с точки зрения максимальной производительности — это ну совершенно разные подходы? И что одно к другому ну не может просто так свестись?

Это только мне кажется, или степень вменяемости Rust-оманов по ходу дискуссии стремится к нулю?

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

Рендеринг страничек для браузера в кластере

Забыл, что без тега [sarcasm] у публики ЛОРа ломается парсер

Потоки:
- IPC через очереди и shared memory
- Системный шедулер

Корутины:
- IPC через очереди и, внезапно, shared memory
- Шедулер в рантайме бинарника

Огромная разница, да, прямо настолько, чтобы перенос кода был сложнее переписывания на параллельный манер движков с легаcи из 90х.

степень вменяемости Rust-оманов по ходу дискуссии стремится к нулю

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

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

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

- Системный шедулер
- Шедулер в рантайме бинарника
Огромная разница, да

Етить-колотить. Да разница огромная, да.

Если попытаться читать

Если пытаться читать дебидилетантов, то шансов вычитать там что-то разумное не прибавиться.

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

Нечего сказать @ Придерись к терминологии.
Я прекрасно знаю что такое IPC, как оно расшифровывается и где применяется.
Замени на слово синхронизация, если оно более общее и нравится тебе больше.

Если пытаться читать дебидилетантов

Нечего сказать @ Дави илитарностью и «прожитыми годами»

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

Замени на слово синхронизация

Да, путать «синхронизацию» и «обмен информацией», а потом апеллировать к «дави илитарностью» — это мощно. «Нечего сказать» (с)

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

Придраться к терминологии и не сказать ничего по теме, когда речь о параллельных алгоритмах, а не о способах обмена информации — это называется «слив».

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

Да разница огромная, да.

Ваше мнение очень важно для нас (с)
А по делу будет? В чем огромная разница, делающая адаптацию алгоритмов под гринтреды, подчеркиваю еще раз основную мысль, даже в блок возьму,

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

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

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

Если он не отдает себе в этом отчет, то он запросто может заявить о сливе. Не о своем, естественно.

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

Опять придирки к терминам и давка авторитетом от нечего сказать? Это уже скучно, давай что-то новое

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

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

i36_zubov
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.