https://www.opennet.ru/openforum/vsluhforumID3/111412.html Французский разработчик, действующий под псевдонимом Dominus Carnufex, на практике продемонстрировал (https://dominuscarnufex.github.io/cours/rs-kernel/en.html) реалистичность идей по переписыванию ядра Linux на языке Rust (https://www.rust-lang.org/en-US/). В настоящее время Rust уже хорошо показал себя в качестве языка низкоуровневого системного программирования и даже существует несколько (https://www.opennet.ru/opennews/art.shtml?num=46459) проектов (http://os.phil-opp.com/) по разработке новых операционных систем на языке Rust. Автор исследования относится к проектам по созданию новых ОС скептически, считая, что у них нет шансов на завоевание рынка. При этом, более полезной выглядела бы постепенная переработка ядра Linux на Rust, что позволило бы решить многие проблемы с безопасностью. <br><br><br>Чтобы не выглядеть голословным Dominus Carnufex подготовил рабочий прототип реализации интегрируемого в ядро системного вызова, код которого написан на языке Rust. Предоставленный пример может рассматриваться в качес https://www.opennet.ru/openforum/vsluhforumID3/111412.html#270 Mon, 19 Jun 2017 07:37:37 GMT &gt; "Быстрее устаревшей сишки!!!***&#187;" - это только по их тестам...<br>&gt; джабаисты тоже самое сколько себя помню утверждали о своём божке <br>&gt; (правда скромней: что такая же скорость как на Си), <br>&gt; а сколько не смотрел исходных код их бенчмарков - сплошная дуриловка: <br>&gt; * либо Си код заведомо деоптимизирован(включая исп-ние С++ библиотек тормозов), <br>&gt; * либо Java код написан уже после написания на Си, с применением <br>&gt; там оптимизаций - что соооовсем не натуральное написание...<br>&gt; И главное сам тест всегда - синтетика полнейшая! И уж точно никогда <br>&gt; не realtime.<br><br>Rust - это попытка оптимизировать для опенсурсного сообщества не машинные ресурсы, а, очень дорогие сейчас, человеческие затраты сил и времени на разработку путём отказа от ручной работы с памятью в большей части случаев, большей безопасности, достающейся "автоматически" - соответственно, идея в том, чтобы сделать ручную работу с памятью или иные неавтоматизированные действия необходимыми только тогда, когда без них не обойтись.<br>По сути, по сво https://www.opennet.ru/openforum/vsluhforumID3/111412.html#268 Fri, 16 Jun 2017 14:00:11 GMT "Быстрее устаревшей сишки!!!***&raquo;" - это только по их тестам... <br>джабаисты тоже самое сколько себя помню утверждали о своём божке <br>(правда скромней: что такая же скорость как на Си), <br>а сколько не смотрел исходных код их бенчмарков - сплошная дуриловка: <br>* либо Си код заведомо деоптимизирован(включая исп-ние С++ библиотек тормозов), <br>* либо Java код написан уже после написания на Си, с применением там оптимизаций - что соооовсем не натуральное написание... <br>И главное сам тест всегда - синтетика полнейшая! И уж точно никогда не realtime.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/111412.html#267 Fri, 16 Jun 2017 13:37:48 GMT &gt; Отжеляю котлеты от мух: <br>&gt; Rust именно из-за "подушек безопасности" - тормоз, <br><br>Очередной иметель ценнейшего мнения? Еще расскажите нам, что отсутствие алиасов на указатели фатально для оптимизатора.<br><br>&gt; т.е.в ч.н.этим не лучше Java и C#, <br><br>Мечты жабистов и шарперов такие мечты:<br>http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=java<br>http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=csharpcore<br><br><br>&gt; так причём тут сравнение и притензии на замену Си?... кернел ОС переписывают? <br>&gt; Так ОС и на Java сделать не проблема, только будет тот же тормоз.<br>&gt; А, Java то куда популярней.. и просто больше лобирования и документации, ну <br>&gt; да: синтаксис - У.Г., но и в Rust тоже... Но, Java например есть везде - а, Rust...<br><br>А еще в жабке есть сборщик мусора и без него почти никак.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/111412.html#266 Fri, 16 Jun 2017 13:21:11 GMT &gt; Я переделываю операционную систему Linux на Rust. Я бы хотел получить отзывы <br>&gt; о том, что людям нравится/не нравится в линуксе. ...<br>&gt; Dominus Carnufex <br><br>...%тонна skipped для лаконичности%<br>n) Никому не нужен Linux на ...Rust, даже - просто пользователям... (у которых всё ПО на Си и оно должно безпроблемно не только запускаться, но и линковаться к API и ядру ОС, которое на Си...)<br>m) И да, Linux это не ОС... (если даже это вашей команде не известно - можно представить что у вас "вышло"...)<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/111412.html#265 Fri, 16 Jun 2017 13:13:37 GMT Не только подушки, а и парашут(ы) в самлётах - каждому пассажиру самолёта и даже пилотам.<br><br>Отжеляю котлеты от мух:<br>Rust именно из-за "подушек безопасности" - тормоз, т.е.в ч.н.этим не лучше Java и C#,<br>так причём тут сравнение и притензии на замену Си?... кернел ОС переписывают? Так ОС и на Java сделать не проблема, только будет тот же тормоз.<br>А, Java то куда популярней.. и просто больше лобирования и документации, ну да: синтаксис - У.Г., но и в Rust тоже... Но, Java например есть везде - а, Rust... <br><br>P.S.<br>Как по мне: что то что У.Г., даже не только из-за тормозов, а именно из-за охаянного выше у Си синтаксиса, у этих же обоих - вообще отвратного, у каждого по своемому.<br> https://www.opennet.ru/openforum/vsluhforumID3/111412.html#264 Fri, 09 Jun 2017 21:43:28 GMT &gt;&gt; Дал базы отдельно - работает. Не дал - работает с базой по умолчанию.<br>&gt; Отлично. То есть получается этот твой мап принимает третьим аргументом доп. аргументы <br>&gt; для приведения в число. Логично, че. <br><br>Третьим? Там их можно передавать столько, сколько влезет. Прикольно, да?<br>[code]<br>map(...)<br> map(function, sequence[, sequence, ...]) -&gt; list[/code]<br><br>&gt; К черту единую ответственность, давайте <br>&gt; внедрим в map еще и функционал по байндингу аргументов и по <br>&gt; тому, как и в каком порядке их применять. Как это убого <br>&gt; и узкоспецифично...<br><br>Рукалицо.жпг<br>Как все запущено.<br>Убого, это не знать ничего кроме ЖопоСкрипта, но мнение иметь. Ценное.<br>Оттуда и какие-то странные фантазии насчет мапа. <br><br>[code]<br>&gt;&gt;&gt; def mymap(f, *args):<br><br>... return [f(*myargs) for myargs in zip(*args)]<br>...<br>&gt;&gt;&gt; mymap(int, ['10','12','1338'])<br><br>[10, 12, 1338]<br>&gt;&gt;&gt; mymap(int, ['10','12','1338'],[2,3,16])<br><br>[2, 5, 4920]<br>[/code]<br>Вот и вся магия. Наивный зип пишется тоже в десяток строк, если что.<br>Это при том, что к питону я https://www.opennet.ru/openforum/vsluhforumID3/111412.html#263 Fri, 09 Jun 2017 19:50:35 GMT А разве в языках Alef и Limbo из Plan 9 и Inferno не избавились от недостатков С с полной потерей обратной совместимости?<br> https://www.opennet.ru/openforum/vsluhforumID3/111412.html#262 Fri, 09 Jun 2017 17:58:23 GMT &gt; На дeбилоидность JS-ного map это как-то влияет?<br>&gt; как минимум, глупо<br><br>Прекрати, о человек-аргументация.<br><br>&gt; Дал базы отдельно - работает. Не дал - работает с базой по умолчанию.<br><br>Отлично. То есть получается этот твой мап принимает третьим аргументом доп. аргументы для приведения в число. Логично, че. К черту единую ответственность, давайте внедрим в map еще и функционал по байндингу аргументов и по тому, как и в каком порядке их применять. Как это убого и узкоспецифично...<br><br>Напиши мне при помощи своего супирмощного map следующие конструкции:<br><br>1) Применить основы в обратном порядке. Не порождая новый отреверсенный список, потому как а вдруг их мульён? И не мутируя оригинальный.<br>2) Применять ко всем строкам основу = 16. Не пользоваться лямбдами, потому что твой мап же супирмощный? Он же позволяет супирмощно внедрять аргументы?<br>3) Основ пусть будет всего два: 16 и 32, но чтобы по окончанию списка основ он начинал сначала (а не совал None) -- '10' как 16, '11' как 32, '12' как 16, '13' как 32. Не поро https://www.opennet.ru/openforum/vsluhforumID3/111412.html#261 Fri, 09 Jun 2017 15:19:47 GMT &gt; для тех, кто экономит пространство на жестком диске, <br>&gt; которое тратится на объявление функции-обертки <br><br>Отличное понимание принципов работы железа и софта на низком уровне. Хотя чего можно ожидать от JSников?<br><br>&gt; ['10', '10', '10', '10'].map(Number)<br><br>На дeбилоидность JS-ного map это как-то влияет?<br>Кстати, сравнивать в этом смысле JS с ЯПами со статистической, строгой типизацией "смотрите, им можно а нам низзя?!" как минимум, глупо. <br><br>Там выше привели пример, как оно по нормальному делается для динамической типизации.<br>&gt;&gt;&gt; map(int,['10','11','12','13'])<br><br>[10, 11, 12, 13]<br>&gt;&gt;&gt; map(int,['10','11','12','13'], [2,10,16,32])<br><br>[2, 11, 18, 35]<br><br>Дал базы отдельно - работает. Не дал - работает с базой по умолчанию. <br><br>А вот чем нужно мыслить, чтобы додуматься передавать в мапе еще и по умолчанию индекс и сам массив в вызываемую функцию, да еще и воспринимать это как эталон ...<br><br><br>