|
|
|
4.19, Аноним (-), 15:59, 10/10/2014 [^] [^^] [^^^] [ответить]
| +4 +/– |
Вы против безопасности в утилитах, которые установлены повсеместно?
| |
|
5.25, Мяут (ok), 18:02, 10/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Уязвимости обычно возникают, там где вносится много новой функциональности: Shellshock из-за специфичной возможности bash (функции в переменных окружения) и реализации heartbeat в OpenSSL, приведшей к Heartbleed-уязвимости.
И если Rust - это и есть та самая новая функциональность, то cat'у у которого из изменений за последние пару лет - стиль я верю больше:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=history;f=src/cat.c;h=c
| |
|
6.27, Аноним (-), 18:30, 10/10/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
Помимо перечисленного, есть специфичные для языков уязвимости. Выход за пределы массива, разыменование нулевого указателя.
| |
|
7.55, Мяут (ok), 18:56, 13/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Конечно, они есть. Но в случае с вылизанными coreutils - ИМХО они маловероятны.
| |
|
|
5.32, Аноним (-), 21:18, 10/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Вы против безопасности в утилитах, которые установлены повсеместно?
Теперь давай сюда grep -ri "unsafe" по дереву исходников. Результат скормить wc -l.
| |
|
6.35, Аноним (-), 23:13, 10/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
А ты давай-ка посмотри какого размера блоки unsafe. Большинство однострочные, очень просто контролировать. Весь код на C/C++ в Rust считается unsafe. Всё ещё будем считать C++ безопасным?
Никто не гарантирует полной непробиваемости. Всегда найдётся тупица, который всё поломает. Но по умолчанию в Rust это сделать сложнее.
| |
|
|
|
3.60, nich (ok), 03:13, 15/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Что-то мне кажется, что это какая-то несерьёзная реализация coreutils.
| |
|
|
1.3, yantux (??), 10:55, 10/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –17 +/– |
Если речь идёт об управлении памятью, то чем это лучше java?
Что такое сопрограмма? Раньше такого термина не было. Я так понимаю, этот же термин есть в D. Зачем это придумано?
| |
|
2.5, Аноним (-), 11:22, 10/10/2014 [^] [^^] [^^^] [ответить]
| +12 +/– |
Оно более менее нормально компилируется в native приложение и не тянет за собой JRE. И оно более функционально даже чем Java 8. Хотя слово лучше/хуже это всегда холивар :)
| |
2.8, cbs (?), 11:41, 10/10/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Если речь идёт об управлении памятью, то чем это лучше java?
Дык ведь... что значит: "лучше"?
Насколько понимаю, задачи у этих языков слишком разные, чтобы ставить вопрос так.
| |
|
3.16, Аноним (-), 14:08, 10/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> оценить затраты на безопасное обращение с памятью в rust по сравнению с java разделив значения в графиках на 0
Хочешь сказать, что в Rust эти затраты стремятся к бесконечности?
| |
|
2.10, anonymus (?), 11:57, 10/10/2014 [^] [^^] [^^^] [ответить]
| +5 +/– |
>Что такое сопрограмма? Раньше такого термина не было.
Ну зачем же так открыто признаваться в своём невежестве. Почитайте Кнута, что ли.
| |
|
3.40, Минона (?), 08:36, 11/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Причем тут невежество?
Это системная проблема современного образования.
| |
|
4.49, Crazy Alex (ok), 17:46, 12/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это системная проблема современной нехватки IT-специалистов и локальная проблема конкретного идиота. Благо, для самообразования в IT есть абсолютно все условия - от горы пособий и онлайн курсов до отсутствия нужды в каком-либо специальном оборудовании чтобы всему научиться на практике.
| |
|
|
2.12, Аноним (-), 12:01, 10/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вот дурачок. Сборщику мусора java до модели памяти Rust как до луны пешком.
| |
|
3.15, Led (ok), 13:28, 10/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Вот дурачок.
Ты, наверное, даже не догадываешься, как ты прав. Круче него только ваня-однобитный-флоат. Но ваню с год назад закрыли. А этого, похоже, выпустили из дурки (года два его тут не было).
| |
|
2.33, Ordu (ok), 22:54, 10/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Если речь идёт об управлении памятью, то чем это лучше java?
Вы ждёте что вам здесь лекцию о Rust прочитают? Сходите лучше на сайт Rust и посмотрите сами, чего они там напилили, чтобы обойтись без вызовов free, запусков GC и без счётчиков ссылок.
> Что такое сопрограмма? Раньше такого термина не было. Я так понимаю, этот же термин есть в D. Зачем это придумано?
А это чтобы вы спросили.
| |
|
3.61, nich (ok), 03:46, 15/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> посмотрите сами, чего они там напилили, чтобы обойтись
> без вызовов free, запусков GC и без счётчиков ссылок.
В rust-е есть и Rc<T> и Gc<T>.
| |
|
2.62, arisu (ok), 03:49, 15/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Что такое сопрограмма? Раньше такого термина не было.
а-а-а! как же я не заметил это чудо?!
вот и подросло поколение лоботомированых дятлов.
| |
2.64, rewlad (?), 12:48, 15/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Если речь идёт об управлении памятью,
то это лучше чем в java тем, что не нужен сборщик мусора и расходы на него.
И это лучше чем в С тем, что не поработаешь случайно с освобожденной памятью,
и это проверяется во время компиляции.
Сопрограммы придуманы очень давно.
Зачем они могут, например, пригодиться?
Как правило, программировать легче и надежней,
используя блокирующие поток исполнения вызовы:
sync_a();
return sync_c(sync_b());
/**[VS]**/
async_a(function(err){
async_b(function(v){
async_c(v,function(w){
result_handler(w)
},error_handler)
},error_handler)
},error_handler)
Второй вариант возникает не от хорошей жизни,
а от невозможности использовать первый, т. к. поток всего один,
либо затратности использовать первый, т. к. потоков нужно было бы очень много.
Например в java потоки соответствуют потокам ОС, которых можно сделать тысячи.
А сопрограммы (которых в стандартной java нет)
реализуются на уровне языка, и их можно сделать на порядки больше.
| |
|
|
2.7, Аноним (-), 11:38, 10/10/2014 [^] [^^] [^^^] [ответить]
| –3 +/– |
Зачем нам безопасность, нам надо чтобы все само подгружалось!
| |
|
3.14, beerseller (ok), 12:35, 10/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Почему само? Я имею ввиду, чтобы можно было выносить разные возможности в отдельные модули (типа backend). И затем при загрузке подгружать нужную библитеку реализации.
Как пример: разные варианты работы с дисплеем: Модуль для работы с X, wayland, mir, directfb....
Что-то типа такого. Ну и понятно, что при загрузке таких модулей должно проверяться ABI
| |
|
4.21, Аноним (-), 16:00, 10/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Ну и понятно, что при загрузке таких модулей должно проверяться ABI
Ого. Может быть, и "задачу останова" вы уже решили?
Или вы имеете в виду версию ABI? Но тогда ваша хотелка реализуется не на уровне языка исходных текстов, а на уровне имён файлов собранной библиотеки, реализуется динамическим загрузчиком ОС, и уже триста лет как.
| |
|
|
|
1.11, Аноним (-), 11:57, 10/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"Практически доведена до готовности реализация типов с динамически изменяемым размером (Dynamically-sized)"
а раньше динамические массивы не поддерживались??
| |
1.22, Аноним (-), 16:22, 10/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
>> возможность порождать тысячи и даже миллионы подпроцессов
Да ну и что, даже аппаратная реализация многопоточности тут не нужна ?
| |
|
|
3.29, Аноним (-), 20:45, 10/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Это то, благодаря чему реализован механизм переключения между процессора путем интервального пика таймера, после которого один процесс меняет другой, сохраняя значения каждого регистра предыдущего.
| |
|
4.31, Аноним (-), 21:17, 10/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Речь не о процессах и даже не о нитях, это реализовано целиком в пространстве пользователя.
| |
|
5.34, Аноним (-), 22:55, 10/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Я это знаю, но тут утверждается, что всё это целиком и полностью реализовано в Ruste'е, особенно "обеспечении высокого параллелизма выполнения заданий (возможность порождать тысячи и даже миллионы подпроцессов)". Что собственно и озадачило меня :)
| |
5.36, Аноним (-), 23:30, 10/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
то есть один процесс-нить сможет изменить глобальную переменную, в другой процессе-ните уже взять её измененной?
| |
|
4.37, Аноним Аналитег (?), 00:51, 11/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> механизм переключения между процессора путем интервального пика таймера, после которого один процесс меняет другой
т.е. прерывания вы называете аппаратной реализацией многопоточности?
| |
|
5.43, Аноним (-), 15:37, 11/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вы хотите предложить какую-либо альтернативную реализацию многопоточности, которая бы обходилась без прерываний ?
| |
|
6.44, ffirefox (?), 17:36, 11/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Так уже давно предлагали. В виндах 3.x это был основной метод организации многозадачности.
| |
|
|
|
|
|
|
2.28, Аноним (-), 18:32, 10/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Едва ли. Впервые о нём слышу, хотя языком интересуюсь.
После 1.0 можно будет говорить, что что-то готово для использования.
| |
|
1.38, Kodir (ok), 01:33, 11/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Зачем надо было пилить Ржавого, когда до этого уже несколько лет существовал Ди? Если бы у мозилофилов было чуть меньше амбиций и чуть больше мозгов, они бы помогли Ди с библиотеками и язык популяризовался гораздо быстрее.
| |
|
|
3.42, Аноним (-), 14:28, 11/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Ты коммиты смотрел у Руста? там Рубистов и ЯваСкриптоПисателей гора.
| |
|
4.47, Kodir (ok), 04:12, 12/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Это-то и пугает! :)
У статического языка должны быть статические же реализаторы.
| |
|
3.50, Crazy Alex (ok), 17:57, 12/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ди это что угодно, но не питонщина. По многим причинам, начиная прежде всего с любви к TIMTOWDI. Там у них в рассылке много лет сидит ярый питонист и очень хорошо заметно, как дишные концепции ему всё время не по нраву - то хочет беззнаковые целые убрать, то bounds checks обязательные, то ещё что...
Собственно, ближе всего к правде то, что и написано на сайте - D is a C++ done right. С хорошим метапрограммированием (которого в Rust вообще нет) и кучей удобств для программиста.
| |
|
2.48, й (?), 16:24, 12/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> уже несколько лет существовал Ди?
> ...
> они бы помогли Ди с библиотеками
покажите мне green threads в этом переусложнённом монстре.
| |
|
3.51, Crazy Alex (ok), 18:14, 12/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
А зачем они там? Есть Fibers, есть Tasks, есть libasync. А делать свой менеджер потоков в языке - это ни разу не в стиле D. Вот это как раз было бы переусложнением.
| |
|
4.53, й (?), 19:49, 12/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Это всё и в Ruby есть. Green threads таки круче.
Речь не о "менеджере потоков", речь о том, что параллельный софт удобнее разрабатывать на ерланговских green threads, чем на всех этих велосипедах из твоего сообщения. Разработчики Rust это поняли, D -- нет, об чём и речь.
| |
4.54, й (?), 19:55, 12/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
О. Ещё бонусный вопрос, раз уж вы отрицаете переусложнённость D. Цель: написать UTF-8 в консоль (мы же в 21 веке знаем и про локали, и про юникод, и про винду). В Go это просто как 'Println("что надо"). Приведите не более сложный код на D, если он и правда не переусложнён.
| |
|
|
2.52, Crazy Alex (ok), 18:14, 12/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Зачем надо было пилить Ржавого, когда до этого уже несколько лет существовал
> Ди? Если бы у мозилофилов было чуть меньше амбиций и чуть
> больше мозгов, они бы помогли Ди с библиотеками и язык популяризовался
> гораздо быстрее.
У мозилловцев NIH рекордных размеров. От pdf.js до Daala.
| |
2.58, Artemciy (?), 02:18, 14/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
В D нету borrow checker-а, обеспечивающего Rust дополнительную безопасность. К тому же стандартные библиотеки D больше заточены под сборку мусора и нет разграничения памяти между задачами.
| |
|
3.59, arisu (ok), 02:42, 14/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> В D нету borrow checker-а, обеспечивающего Rust дополнительную безопасность.
об этом думают, есть даже DIP.
> К тому же стандартные библиотеки D больше заточены под сборку мусора
об этом тоже очень сильно думают, в git-е достаточно много подвижек в сторону @nogc-кода. также Александреску выкатил предварительный вариант refcounted строк, и идут обсуждения про то, как и рыбку, и ёлку: и mark/sweep GC иметь, и при необходимости rc GC. пока что ругаются.
> и нет разграничения памяти между задачами.
э? если ты про фиберы (то бишь, сопрограммы) — то да, нет. это, в общем-то, by design, а не flaw. хотя возможно, что из DIP про scoped values такое разграничение получится само собой.
пока что с escape analysis всё не очень весело, потому так.
| |
|
4.65, Artemciy (?), 22:42, 17/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> > и нет разграничения памяти между задачами.
> э? если ты про фиберы (то бишь, сопрограммы) — то да, нет.
> это, в общем-то, by design, а не flaw. хотя возможно, что из DIP про scoped values
> такое разграничение получится само собой.
> пока что с escape analysis всё не очень весело, потому так.
В Rust это называется task (задача), и она даже не фиберная а обычный поток пока что. Но зато сборщик мусора, когда он появится, будет собирать мусор отдельно в каждой задаче, а не во всем процессе. По моему опыту это охуенно важно.
Речь не о том, flaw это или не flaw, а о том что дизайн языков довольно разный, поэтому мем о том что Мозилле надо было использовать D, вместо выдумывания нового языка Rust - не совсем верный.
| |
|
5.66, arisu (ok), 23:30, 17/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Речь не о том, flaw это или не flaw, а о том
> что дизайн языков довольно разный, поэтому мем о том что Мозилле
> надо было использовать D, вместо выдумывания нового языка Rust - не
> совсем верный.
а, в этом смысле. тут не спорю. впрочем, я до сих пор не уверен, что сами авторы rust в курсе, что хотят получить на выходе и как это должно выглядеть. но не уверен, что это такой уж огромный недостаток: общая идея у них есть, а что они по дороге насочиняют… может, оно и лучше получится, чем если бы изначально план на скрижалях имелся.
| |
5.67, arisu (ok), 23:37, 17/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
p.s. с другой стороны, обмениваться данными между задачами придётся или явно указывая на смену владельца, или надеяться, что компилятор сможет сам это разрулить (тоже не лучший вариант, на самом деле), или жёстко message passing (это, собственно, подвид первого варианта). то есть, создать экземпляр какой-то фигни и расшарить её с другим потоком будет уже не просто присваиванием.
поэтому, например, в D и не внедряют task-local heaps: не очень ясно, как это разруливать так, чтобы и безопасно было, и не надо было ручной код делать, и при этом не потерялась возможность «низкоуровневости».
| |
|
6.68, Artemciy (?), 23:25, 18/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> p.s. с другой стороны, обмениваться данными между задачами придётся или явно указывая
> на смену владельца
В Rust "=" - это move, кстати.
Для копирования надо явно указывать clone.
| |
|
|
|
|
|
|