Кэрол Хербст (Karol Herbst) из компании Red Hat, принимающий участие в разработке Mesa, драйвера Nouveau и открытого стека OpenCL, опубликовал rusticl - экспериментальную программную реализацию OpenCL (фронтэнд OpenCL) для Mesa, написанную на языке Rust. Rusticl выступает в роли аналога уже присутствующего в Mesa OpenCL-фронтэнда Clover и также разработан с использованием предоставляемого в Mesa интерфейса Gallium...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55827
Почему зависимость от python это хорошо, а зависимость от rust плохо?
Какое вообще отношение имеет python к mesa?
Если что питон есть везде а раст надо (на самом деле не стоит) ставить.
Причём питон и си это молоток и кувалда, а си и раст это две кувалды, одна с металлической ручкой, другая с пластмассовой.
Тогда уж С - это монолитный кирпич, а питон - цементный раствор.
питон - песочек из которого построили замок на берегу и который смоет ближайшим приливом
Ага. В принципе - питон-песок еще одно неплохое сравнение. Поясняю.Из песка сделали замок, потом же в нем из легированной си-стали отлили фундамент, из плюсплюс-тавра выковали балки, из буст-проката сделали внутреннюю крепость - заглядение. А далее пусть смывает, все равно заменят. И так ровно до тех пор, пока из питон-песка там будет только оформление и красивый песчаный пол во дворике крепости.
До хайпа и жесткого проталкивания везде его не было везде.
Python компилируется минут 10 от силы, Rust же тратит часа 4 на llvm и ещё 4 на rust. Вообще, мне Rust очень нравится, но иной раз собирать новый выпуск тупо впадло. Что-то похожее на Chromium/LibreOffice.На Python огромная база пакетов из коробки. При некой сноровке, никакие доп. пакеты не нужны вообще. В случае с Rust, почти на каждый чих надо какой-то crate подключать, на голом очень сложно писать что-то.
Ага, точно, рабрту с указателями победили, зато теперь с непонятных источников будем спайварь в систему тащить.
> Ага, точно, рабрту с указателями победили, зато теперь с непонятных источников будем
> спайварь в систему тащить.Cказал человек который ни разу не прочитал все исходники OpenCL на С.
Я имел ввиду не классическую реализацию OpenCL на C, а то, что пытаются на Rust. И да, победят ли они указатели, это ещё вопрос.
У меня большие проекты на Rust собираются на порядок быстрее, чем большие проекты в PAR/XAR на Python. А зачем собирать сам Rust-компилятор не являясь разработчиком Rust-а -- не очень понятно. Мне кажется, что это проблема очень специфична для Gentoo only. Но даже в Gentoo никто не запрещает использовать готовый бинарий. В общем вопрос: а зачем вы пересобираете компилятор, если речь про сборку приложений, использующих OpenCL?
[i]Но даже в Gentoo никто не запрещает использовать готовый бинарий.[/i] - Вы давно использовали готовый бинарий?Даже в либре психи прибили гвоздями несколько либ, что приходится тупо делать симлинки, чтобы заработало. icu и еще что-то.
[i]Мне кажется, что это проблема очень специфична для Gentoo only.[/i] - отлично у Вас получилось положить здоровый болт на тех, чей удел кросскомпиляция.
Вам ненужно пересобирать раст каждый раз когда вам нужно собрать проэкт на расте.
[i]пересобирать раст каждый раз когда вам нужно собрать проэкт на расте[/i] - скажите это firefox, что мне не нужно пересобирать rust.Проходит буквально несколько месяцев, я хочу собрать новый firefox - и, вуаля - нужен новый rust(и llvm).
Так это политика даже не фаерфокса наверное а мейнтенеров в вашем дистрибутиве. Вот им и говорите.Llvm же вроде не чаще жцц обновляется.
Ага - теперь у меня дистрибутив не тот. Ясно-понятно.
У вас костылинyпс неправельный. Для windows все, что нужно, доступно в бинарном виде на момент релиза.
> Ага - теперь у меня дистрибутив не тот. Ясно-понятно.Я такого не говорил.
Я у вас спросил, кто апает требования на раст для сборки фаерфокса в вашем конкретном случае.
Разрабы фаерфокса, мейнтейнеры пакета фаерфокса, разработчики раста, или может быть вы просто чего-то сами не понимаете и такого требования нет вообще?
Вы же мне свой дистр не называли, доступа к вашему пк который контролируете вы у меня нет, я не экстрасенс. Но мне вот интересно, что у вас там такое происходит.
> А зачем собирать сам Rust-компилятор не являясь разработчиком Rust-а -- не очень понятно.Человек хочет собрать все с нуля, чтобы не доверять сборку сторонним людям.
> У меня большие проекты на Rust собираются на порядок быстрее, чем большие проекты в PAR/XAR на PythonНе знаю точно сколько собирается PAR/XAR и что это вообще, но в питоне обычно запускаются скрипты без компиляции, а по поводу rust - 30 мин загрузки всякой хрени через карго для любого пакета вы учли?
> Мне кажется, что это проблема очень специфична для Gentoo only
Забыли например про LFS или другие сорс базед дистры, а также не совместимые с чужими бинарниками ОС
PAR/XAR в случае Python -- это когда собирают приложение в единый запускаемый файл, который можно перенести на другой хост, и он там будет работать.По поводу 30 минут. Я работал с разными проектами на Rust и ни разу мне не приходилось ждать 30 минут. Обычно лишь несколько секунд. А вот на python, кстати, pip обычно заставлял ждать немного дольше.
Никто не мешает установить бинарий и на уже готовую LFS. Если же человек из спортивного интереса хочет пересобирать всё, то это уже не из области практического подхода, и как-то не особо интересно.
Что такое несовместимость с чужими бинарниками ОС?
> По поводу 30 минут. Я работал с разными проектами на Rust и
> ни разу мне не приходилось ждать 30 минут. Обычно лишь несколько
> секунд. А вот на python, кстати, pip обычно заставлял ждать немного
> дольше.зависит от скорости инета, у меня при 200 кб/с пару сот мб кратов качаются ощутимое время
> Никто не мешает установить бинарий и на уже готовую LFS. Если же
> человек из спортивного интереса хочет пересобирать всё, то это уже не
> из области практического подхода, и как-то не особо интересно.Соглашусь, хотя я чужие бинри очень не люблю
> Что такое несовместимость с чужими бинарниками ОС?
попробуйте обычный бинарь динамически слинкованный с glibc запустить например на uclibc
> Не знаю ..., но ...Если очень постараться, из этих букв можно сложить слово "opennet"
>> Не знаю ..., но ...
> Если очень постараться, из этих букв можно сложить слово "opennet"нет букв т и п. И лишние буквы останутся.
Вам ненужно загружать 30 минут все исходники всех либ каждый раз когда вы пересобираете проект.
Расскажите это всё мейнтейнерам дистрибутивов, что они могут ничего не собирать, а просто "готовый бинарий" в репы тащить - узнаете много интересного про свою мамашу. Тут ребром стоит вопрос ответственности.
Вам ненужно пересобирать раст каждый раз когда вы собираете проект на расте.
И качать все исходники с нуля ненужно.Кроме того, по сравнению с сишкой и сипипишкой на ЖЦЦ раст ну очень быстро собирается.
>Тут ребром стоит вопрос ответственности.
А собирают они свои бинарники случайно не бинарникомм? А ему точно можно доверять? Или они могут отследить свой бинарник до самого Столлмана лично?
1. Питон есть везде
2. Питон - взрослый язык без постоянных внедрений
3. Питон имеет простой синтаксис, а не то, что "нетакие-как-фсе" наворочали в расте
4. Питон позволяет себя просто использовать, без помпы "про безопасность", хотя сам безопаснее раста
1. Хоть Python есть не везде (особенно в embedded). Но ОК, валидный аргумент.
2. Ну да, внедрение например asyncio и coroutines -- это так, не считается (хотя по сути теперь большие приложения на Python пишут тупо иначе). Но допустим ОК, возмём за валидный аргумент.
3. Синтаксис Python лишь кажется простым. Опять же давайте вспомним asyncio и корутины, и сравним это с Go, например. Но ОК, допустим и это аргумент сочтём за валидный.
4. Rust тоже позволяет. Для этого там есть unsafe. А по поводу безопаснее Rust-а -- это просто бред от не понимания про что речь. Напомню,что речь про safety и возможность предотвращать ошибки на стадии компиляции. А в Python с этим большое количество проблем. Начиная от системы типизации, заканчивая тем, что GIL и однопоточность на самом неделе не спасают от concurrency проблем и некорректной работы приложения.Есть и аргументы против Python в качестве glue language by default и я убеждён, что это было большой ошибкой форсить Python везде, но это сейчас не важно. Я просто хотел ответить на пункт #4.
К слову, питон тоже давно пора переписать на раст
https://github.com/RustPython/RustPython
Его давно пора выкинуть. И начать нужно с ВУЗов.
Давно пора выкинуть тебя как минимум с этого форума
> Давно пора выкинуть тебя как минимум с этого форумаЕсли от этого пердон перестанет жрать память, тормозить, плодить типа-программистов, то я самовыпилюсь. С форума.
https://docs.rs/inline-python
“Питон - взрослый язык без постоянных внедрений”Агага, лол. Язык, специально созданный для обучения детей программированию — взрослый. Этим вечером с друзьями за столом будете играть в «пирамидку»? Вы — молодец, Вы — очень, очень взрослый мальчик!
Ой, да, Паскаль и Пайтон так похожи между собой, что взрослые мальчики путают их, и не краснеют
>ПайтонПитоноид детектед. Душитель одноглазого змея.
У меня на роутере есть php, но нет питона. Т.ч не везде.
У меня на роутере есть питон, но нет пхп. Так что твой случай не важен
У питона самый отвратительный не читаемый плохо редактируемый семантически не связанный синтаксис.
Брейнфакт и то лучше.
Даже сишка лучше!
С чего вы взяли, что наличие питона где бы то ни было - это хорошо? Питона вообще не должно быть на машинах, обслуживающих реальных пользоватей. Нигде его не должно быть, поскольку сам факт его наличия - дыра безопасности.
> и нет поддержки внешних crate-пакетов в системе сборкиНу правильно, нужно засрать проект по максимуму, чтобы 1 человек все это поделие не смог сам собрать/скомпилять, темболее в оффлайне. Смузи/ржавчинохлебы сээр.
Вы не так поняли, имеется в виду удобство. cargo давно уже умеет `--offline`, они видимо автоматизацию не подвезли и много чего нужно руками делать для сборки.
cargo уже избавился от лефтпадов, тянущихся за казалось бы нормальным пакетом?
leftpad -- это из npm, причём он тут? Да и вообще, cargo - это по сути как apt, только безопаснее by design (но более сырой). "В apt уже избавились от уязвимых libsvg, тянущихся за казалось бы нормальным пакетом?" -- странный вопрос, да?
ну правильно, надо всем разрабам пердолиться с Сями, что б тебе одному удобней собирать было. Неосиляторы, сээр.
Крайне лживые утверждения! Зависимость от отступов - это самый сумасшедший бред, который я когда либо видел в языках программирования
> Крайне лживые утверждения! Зависимость от отступов - это самый сумасшедший бред, который
> я когда либо видел в языках программированиядля одноразового кода замка-на-песке, смываемого следующим приливом - просто отличная идея.
таб нажать гораздо удобнее чем пердолиться нажимая шифт-скобочки двумя мизинчиками, и не забывать еще и расставлять те столбиками.
Главное - никогда не надо этот код пытаться читать и исправлять, а уж тем более - использовать куски (а не готовые библиотеки) в других проектах. И, разумеется, ни в коем случае не надо пытаться продежаться до следующего прилива.
А вот эту ошибку - кто только не совершал. Из них жалко, конечно, только hg.
И какую версию OpenCL он реализовал? Было бы очень хорошо, если бы в результате этой инициативы Mesa научилась бы чему-нибудь выше 1.1.
Там причём комедия - для 2.0 не хватает чуть ли не только printf, её можно заставить прикинуться 2.0 через переменные окружения.Но есть другая проблема - я пытался со свежим radeon-ом завести (5500M), но под него нет libclc...
Сейчас бы проект, написанный одним человеком ради изучения ЯП, в мейнстрим тянуть. Что может пойти не так?
Растохейтерам лишь бы всё перевернуть с ног на голову или красиво лужу газануть... В очередной раз свою неадекватность показываете.Где там про мэйнстрим говорится? И чего ты выдрал из контекста "ради изучения ЯП", но опустил, что это делается "ради изучении целесообразности использования ЯП" для Mesa - к тому же, может еще и не выгорит, тебе на радость докажут нецелесообразность.
И похоже не просто студентка-первокурсница какая-то, а человек "из компании Red Hat, принимающий участие в разработке Mesa, драйвера Nouveau и открытого стека OpenCL", наверное что-то понимает в теме.
К тому же "Разработка была представлена 17 сентября на конференции XDC 2021 (X.Org Developers Conference)" что означает, что это важно "для мэйнстрима" т.к. "год назад разработчики Mesa уже обсуждали целесообразность использования языка Rust". Но тебе же виднее, что нужно тому сообществу.
И для прикидок целесообразности наверное правильнее было бы выделить одного-двух компетентных человек, а не всем сообществом кидаться "изучать ЯП".
Вот один человек и впрягся, а не всё сообщество - " Целью разработки было изучение Rust, выработка оптимальных путей интеграции Rust в Mesa, опробование создания реализаций API на другом языке и проверка сочетаемости компонентов на Rust с остальным кодом на языке Си." - не взлетит - откажутся, чего так взбурлился? А взлетит - ну, придется и остальным "компиляторщикам Месы" (ты ведь из них, ежедневно Месу перекомпиливаешь?) поднапрячься, скачать и изучить что-то новое для сборки.
>И похоже не просто студентка-первокурсница какая-то, а человек "из компании Red Hat, принимающий участие в разработке Mesa, драйвера Nouveau и открытого стека OpenCL", наверное что-то понимает в теме.Относительно впопеннетчика - какой-то лошпед.
Сравнивать великомудрого эксперта opennet и какого-то разработчика из красной шляпы, это все равно что сравнивать слона и блоху.
> Сравнивать великомудрого эксперта opennet и какого-то разработчика из красной шляпы, это
> все равно что сравнивать слона и блоху.Слона и клопа (того самого, из поговорки "мал клоп, ...").
Вам, батенька, лечится надо, вам хейтеры везде видятся. Я сам Rust учу, но не вижу смысла никуда его пихать или презентовать без более-менее продолжительного личного опыта его использования. И уж тем более считаю глупым оценивать применимость языка до его основательного изучения.
> но не вижу смысла никуда его пихать или презентоватьЛечиться, похоже, желательно Вам. Никто не пихает, а только оценивают целесообразность. И презентуют результат исследования целесообразности. А не впаривают тебе готовый продукт.
> без более-менее продолжительного личного опыта его использования.
Ну вот не нашлось никого в том сообществе, кто бы его "продолжительно лично использовал". А оценить плюсы-минусы сообществу хочется. Если что-то новое, то обычно делается это через обучение. Что предлагаете, дружно всем сообществом уйти, уступить место тем кто растом пользовался и это только для оценки необходимости нового языка?
> ...И уж тем более считаю глупым оценивать применимость языка до его основательного изучения...
Ну так может быть этот выделенный человек его основательно и изучил в процессе? Как-никак сообщество "обсуждало год назад". Сколько Вам надо, 10 лет практики? А только потом изучение целесообразности и вынести вердикт - "Не нужно!". И Вы что, удаленно мысли читаете и оценку способностям даете, что сразу уверенно кричите: " - что пэтэушник на токамаке делает?"
> И похоже не просто студентка-первокурсница какая-то, а человек "из компании Red Hat, принимающий участие в разработке Mesa, драйвера Nouveau и открытого стека OpenCL", наверное что-то понимает в теме.Точно так же, как "профессианал" из EFF, выложивший очень грязную и быструю обертку над реквест-респонс с открытой передачей паролей от гугла?
Или это карго-культ такой? Типа: четвертый зам третьего ученика второго помощника поломоя в отделе разарботки, устроенный в копрорации сделал хрень - жираф большой, ему видней?
Прям точно точно такой же?
А как сравнивал?
Или просто языком мелешь?
ну наконец то появятся безопасные утечки памяти благодаря расту.
Мда, этот rust напоминает болезнь
Вы не поверите, но это другое.Согласно китайской философии Фен-Шуй, Запад представляет собой элемент Металл. Это не только деньги и изделия из металла, но Логика, в том числе программирование.
Обратите внимание, что последнее время (лет 100) Запад действительно преуспел в создании механизмов и языков программирования. Однако, согласно тому же Фен-Шуй, это явление временное. На смену эпохе Запада (Металла) приходит эпоха Воды.
Я хотел бы увидеть боле рациональное объяснение, почему язык назван Rust (Ржавчина), чем вышенаписанное.
> хотел бы увидеть боле рациональное объяснение, почему язык назван Rust (Ржавчина), чем вышенаписанное.Если коррозия завелась, то избавиться от неё уже нельзя; можно лишь замедлить её распространение с потерей прочностных характеристик силовой конструкцией.
Эффективная борьба с коррозией достигается только в момент производства силовых элементов через применение легированных сплавов, устойчивых к агрессивной среде, вызывающей коррозию, или через специальную обработку силовых элементов в завершении технологического цикла для исключения прямого контакта с агрессивной средой, например: оцинковка, никелирование, хромирование, воронение и т.п.
Такова реальность.
Ассоциативное соотнесение виртуальности (software), реальности и фен-щуя каждый делает сам.
imho
>> хотел бы увидеть боле рациональное объяснение, почему язык назван Rust (Ржавчина), чем вышенаписанное.
> Если коррозия завелась, то избавиться от неё уже нельзя; можно лишь замедлить
> её распространение с потерей прочностных характеристик силовой конструкцией.Это вполне укладывается в философию китайцев, сейчас эпоха Металла заканчивается (смотрите, что творится на биржах; на хорошие японские машины, которые стали из пластмассы и т.п.).
> Ассоциативное соотнесение виртуальности (software), реальности и фен-щуя каждый делает
> сам.Фен-шуй это не реальность, а философия, виртуальность, которая "объясняет мир". В частности, появление названия языка. Я пока не вижу иных вариантов. Хотелось бы увидеть.
Боюсь, что бы понять философию китайцев, надо быть самому немножко китайцем. Потому добавлю.В какую-то древнюю эпоху Металла появилась маталлургия, был изобретён нож и т.п. Эпохи сменялись, но те изобретения мы до сих пор используем.
Соответственно языки, которые были придуманы во время "расцвета Металла" и прошли проверку временем, эти языки останутся. Ничего нового в том духе придумано не будет, потому что эпоха сменилась. Некоторые здесь называют новую эпоху -- эпохой Смузи. Немного похоже на китайскую Воду.
> В какую-то древнюю эпоху Металла появилась маталлургия, был изобретён нож и т.п.
> Эпохи сменялись, но те изобретения мы до сих пор используем.В эпоху развала (1985-1995) в СССР[РФ] был популярен музыкальный коллектив с названием "Коррозия метала".
Слабо разбираюсь в вопросах философии и ассоциациях, однако подобие налицо. :)
Ничего не знаю по поводу популярности, они тогда съели двух фанаток и поэтому их не слушали.
На вольфрам штале намекаешь?
>Если коррозия завелась, то избавиться от неё уже нельзя; можно лишь замедлить её распространение с потерей прочностных характеристик силовой конструкцией.Эм, нет вообще-то, можно ржавчину обратно в металл востановить или в инертное для дальнейшей коррозии соединение, попутно залив всё защитным слоем или другой гадостью.
Есть куча средств по типу WD-40 с преобразователями ржавчины например.
Не говоря уже о такой фигне как смещение потенциалов.
>Я хотел бы увидеть боле рациональное объяснение, почему язык назван Rust (Ржавчина)https://ru.wikipedia.org/wiki/Rust_(язык_программирования)
"Автор дал проекту название Rust, по его словам связанное с грибами семейства ржавчинные (англ. rust fungi)"
Автор любитель грибов ;)
>>Я хотел бы увидеть боле рациональное объяснение, почему язык назван Rust (Ржавчина)
> https://ru.wikipedia.org/wiki/Rust_(язык_программирования)
> "Автор дал проекту название Rust, по его словам связанное с грибами семейства
> ржавчинные (англ. rust fungi)"
> Автор любитель грибов ;)Это не очень весёлые грибы. По ряду версий некоторые войны в средневековой Европе возникали из-за переедания поражённых спорыньей злаков.
Ах вот оно что... Ну, это многое объясняет))
Дословно - Фенг-Шуе - Ветер-Вода.Хорошая такая философия...
Метал пишется с одним - л.
> Метал пишется с одним - л.А музыкальный жанр - с двумя? =) Он таки тоже возник в эпоху Металла. https://ru.wikipedia.org/wiki/Металлы
Где черпаете новые правила для русского языка?
Дак ржавчина ведь. Если от нее не избавится - съест все, на чем появилась.
раст напоминает, а С - это рак (Cancer)
Знаком "С" обозначается нота До - самый низкий тон. Соответственно и язык самый низкоуровневый (если не считать не получивший распространения С--; ассемблер - это не ЯП).Микрософт назвала язык C#, по сути переводить правильнее как "До-диез" https://en.wikipedia.org/wiki/C♯_(musical_note)
В эту же схему укладываются названия языков D и F#.Имена нот же означают следующее:
Do – Dominus – Господь;
Re – rerum – материя;
Mi – miraculum – чудо;
Fa – familias рlanetarium – семья планет, т.е. солнечная система;
Sol– solis – Солнце;
La – lactea via – Млечный путь;
Si – siderae – небеса.
> Имена нот же означают следующее:Враньё. https://www.youtube.com/watch?v=drnBMAEA3AM
Doe, a deer, a female deer
Твой C -- это женская особь аленя.
Си, синьор. В каждом карале свои вожаки и важенки.
Почему ассемблеры не ЯП?
В наборе команд IA-32 есть машинная инструкция с опкодом 90h. Она обменивает регистр EAX с регистром EAX. Как это запомнить? Дать команде символическое обозначение - мнемонику XCHG EAX, EAX. Или NOP. Ассемблер всего лишь переводит такие мнемоники в машинный код. При программировании на ассемблере приходится учитывать размеры опкодов (например, для выравнивания циклов) и т.п., потому от программирования непосредственно в машинных кодах оно отличается лишь внешне, а не по существу.В настоящее время ассемблеры эволюционировали до макроассемблеров, но язык макросов более высокоуровневый, чем язык Си.
Форт более низкоуровенен чем С. Тоже не язык?Дай ссылку на определение "язык программирования".
> Форт более низкоуровенен чем С.Тот факт, что шитый код может оказаться компактнее, чем программа даже на асме, не делает Форт более низкоуровневым. Си абстрагировался от машинного кода PDP с целью обеспечить трансляцию в иные целевые системы команд, при этом абстрактная машина очень похожа на физическую с плоской моделью памяти. Форт-машина стековая и надо ещё поискать процессор с единственным регистром-аккумулятором, а потом уже доказывать тезис.
> Тоже не язык?
Не вижу смысла отвечать на вопрос - Вы это сами придумали.
> Дай ссылку на определение "язык программирования".
Если решили заняться буквоедством, напоминаю исходный тезис: "ассемблер - это не ЯП". Ассемблер это программа, которая транслирует набор мнемоник. Т.о. ассемблер точно так же не язык программирования, как Си-транслятор. Можете назвать листинг мнемоник программой на языке ассемблера, если оно Вас за живое задело и если язык повернётся выдать "программа на языке шестнадцатеричных цифр".
>Форт-машина стековая и надо ещё поискать процессорhttps://cyberleninka.ru/article/n/protsessory-greenarrays-ga144
https://ailev.livejournal.com/815884.html
Спасибо, очень интересно. Но как раз показывает, насколько далёк Форт от типичных процессоров. "Самое обидное, что кроме них самих программировать на этих процессорах никто не умеет".
Чушь. Язык С назван по порядку после не выжившего языка B.
C++ как оператор инкремента "языка С", а С# - это аллюзия на "инкремент инкремента", типа C++++ (вая, там как раз 4 плюса)
> Чушь.Ответ.
> Язык С назван по порядку после не выжившего языка B.
Я в курсе, что некоторые программисты мыслят исключительно в базисе исключающего или. У них тезис "вода прозрачная" отрицает "вода жидкая".
> C++ как оператор инкремента "языка С",
Вообще-то, С++ это пост-инкремент. Если понимать его семантику, то увеличение происходит после использования, т.е. на тот момент не имеет смысла.
Что самое смешное:
for(i; ;i++) // так принято в Си
for(i; ;++i) // так принято в Си++> а С# - это аллюзия на
> "инкремент инкремента", типа C++++ (вая, там как раз 4 плюса)Эта гипотеза отличается от моей отсутствием хоть чего-то, похожего на доказательства. Решил поискать их за Вас. Нашёл:
Название «Си шарп» (от англ. sharp — диез) происходит от буквенной музыкальной нотации, где латинской букве C соответствует нота До, а знак диез (англ. sharp) означает повышение соответствующего ноте звука на полутон[8], что аналогично названию языка C++, где «++» обозначает инкремент переменной. Название также является игрой с цепочкой C → C++ → C++++(C#), так как символ «#» можно представить состоящим из 4 знаков «+»[9].
https://ru.wikipedia.org/wiki/C_Sharp#Название_языка
> раст напоминает, а С - это рак (Cancer)Смотря с какой стороны на это посмотреть.
Некоторым видится, что C - это сокращение от слова Creatоr (творец) или Creation (творение).
;)
А ещё это может значить cat, crap, cunt, clone и ещё сотню слов. Этот тред по своему безумию сложно с чем-то сравнить. На полном серьёзе обсуждают, как название языка соотносится с его качествами. А если это всё шутки, то слишком плохие, чтобы даже приподнять уголок рта и хмыкнуть.
>cuntДумаю это верная расшифровка.
С++ соответственно crap cunt.
Два куба хлорпротиксена этому анониму. От рака вообще-то умирают, а Си живёт пол века.
Ну так умирает носитель, а рак как раз живет и прорастает метастазами везде. На все платформы, на все архитектуры.
Я нашёл глубинный смысл названия. Рыжий то понятно, что для лисы родился. А плесень обеспечивает крайнюю стадию распада некоей биологической формы, неспособной жить дальше или умершей, когда уже и бактерии отработали, дальше уже прах. Т.е. как санитар леса. Хитро, посмотрим. Но до массового эмбеда руки еще долго тянуть придётся вам.
Что-то с OpenCl совсем всё плохо. Вон из блендера выкинут скоро, т.к. deprecated и стагнация opencl
Эппл сказал, что OpenCL не нужен.
Сколько суперкомпьютеров из макбуков собрали? Я конечно видел датацентры забитые макбками, но что-то мне подсказывает, это изврат. А в юзерском ПО сложение матриц не так полезно, как можно было ожидать.
Так вроде там в куду фишечек типа атомарности завезли, не осталось преимуществ. Из личного опыта, опенкл у меня фризит иксы и создаёт сильную нагрузку и куда достаточно прозрачно исполняется (если не выставлять рилтайм приоритет). Но тут я может быть что-то напутал, или баги в приложении (во всех опенкл приложениях).
Куда это проприетарный шлак призванный непускать открытые технологии и человеческие стандарты на чудосолнечные карточки новидии.Гимп с опенцл у меня отлично работал всегда.
Вы случаем кстати не на нивидевской карте опецл то тестили?
Вам ЗАПРЕЩЕНО, если что, для вас куда есть, жрите.
Опенкл в гимп? Давайте хотя бы если не хасхкат, то блендер. Бтв, я тут мимослышал, от разрабов чего-то там, что опенкл на нвидиа тоже лучше работает. Ну и чтобы фоном какие то вычисления шли и это никак не сказывалось на гуе, я такого и на амд не видел. Это явно не отлично, когда лагает.
C OpenCL очень неприятная история на самом деле. Сама идея и название суперское (OpenGL напоминает), и очень многие на это повелись. На самом деле там втихаря командует Apple (не очень это афишируя) и все что не от эппл просто душится. Много народу повелоcь, я сам уже лет 10 не меньше ждал, вот вот уже совсем скоро ну еще немного ну последний шаг... Спасибо что относительно недавно пару человек в этом признались в интервью.Короче народ не ждите Davinci Resolve c аппаратным ускорением на открытых дровах, то же самое про Blender, просто игнорируйте ЛЮБЫЕ камлания про OpenCL. Сами используй те только то что свободно. Ну или на венду.
А чего вы конкретно то ждали такого, оно с версии 1.1 уже полностью рабочее и продакшен реди было. Разворачивай хоть на кофеварках.Использовали бы себе да и всё.
Это очень грустно. Нормальный же стандарт.
Со всех сторон ползут новости про успехи Rust. Само слово rust мне уже чем-то напоминает "нанотехнологии" и "инновации" времен конца 2000-х. Такой же неприятно-хайповый осадочек.
С одной стороны, ограничение возможности появления элементарных багов это хорошо, но с другой стороны, тащить огромные блобы и завязываться на онлайн...
Если сравнивать со сферой применений Python, то там ты сначала делаешь прототип, потом находишь требовательные к производительности операции и переписываешь их на си. По крайней мере ускоряется стадия прототипирования и написания нетребовательных к производительности частей приложения. А тут тенденция обратная, переписывается работающий код на такой-же, но условно безопасный, ценой привязки к конкретному языку, контролировать развитие которого затруднительно.
Если говорить о безопасном C, то хочется чего-то такого же простого, нетребовательного и быстрого. Концепция языка vlang кажется гораздо более симпатичной.
Всё сугубо моё ИМХО
> Само слово rust мне уже чем-то напоминает "нанотехнологии" и "инновации"Человече, ты сделал мой день. Тут же все буквально 1-в-1.
> Само слово rust мне уже чем-то напоминает "нанотехнологии" и "инновации" времен конца 2000-х.Не, вот безотносительно к тому, насколько хайп вокруг rust'а обоснован, это две совершенно разные вещи, которые надо различать, если ты хочешь хоть чего-то понимать в хайпах, или если уж на то пошло, то в любых социальных процессах.
"Нанотехнологии" и "инновации" спускались сверху вниз по вертикали власти. Новости про успехи rust'а ползут, если можно так сказать, "снизу": они "стихийное" явление. Социальные процессы затеваемые сверху или проходящие стихийно очень по-разному развиваются. Например, то что затевается сверху моментально прекращает шевелиться и не подаёт больше никаких признаков жизни сразу, как только его прекращают шевелить сверху. И это касается и отдельных подпроцессов общего процесса -- то этот подпроцесс пиарился во все поля, то вдруг -- хоп -- он был признан провальным, и он просто прекратился. В стихийных же явлениях часто сложно даже выделить что-то, что можно было бы назвать подпроцессом, в них нет структуры, самый натуральный хаос.
Если ты научишься различать стихийные процессы и управляемые процессы, то ты получишь себе в копилку дополнительный инструмент детектирования теорий заговора: если ты видишь явно стихийный процесс, то любая теория, полагающая этот процес управляемым -- это теория заговора. Стихийность процесса очень сложно воспроизвести, потому как управляемый процесс неизбежно обретает структуру, которая отражает структуру (или какие-то элементы структуры) той группы, которая управляет процессом. Чем масштабнее процесс, чем менее он структурирован, чем более при этом он сложен (с точки зрения сложности системы), тем больше требуется свидетельств для того, чтобы удержать гипотезу управляемости процесса от скатывания в нулевой likelyhood.
" если можно так сказать, "снизу": они "стихийное""Нельзя так сказать. Пока раст взбулькивал где-то там снизу, всем было глубоко по барабану на него. Когда же корпорации начали форсить его, вот тогда уже ржавчина стала "инновациями и нантехнологиями"
> Пока раст взбулькивал где-то там снизуТы б хоть почитал историю, прежде чем утверждать такое. Раст не взбулькивал внизу. Он исходно разрабатывался в корпорации. В 2015 году он был зарелижен, и это запустило стихийный хайп, который никак не управляется сверху. Подпитывается -- да, управляется -- нет. Если ты думаешь иначе, расскажи мне, как Mozilla, Amazon, или кто там из корпораций, смогли убедить этого Кэрола Хёрбста запилить OpenCL на расте. Может они денег ему платили? Шантажировали раскрытием деталей убийства, совершённого им десять лет назад? Как?
Да-да-да, BLM -- тоже сугубо стихийное явление.
> Да-да-да, BLM -- тоже сугубо стихийное явление.Ну, этт... Тебе виднее. Я не интересовался BLM, я не пытался высмотреть в нём структуру. Я слышал конечно о нём, но какое мне дело до проблем негров с США?
> Может они денег ему платили?
>>> "Кэрол Хербст (Karol Herbst) из компании Red Hat"а по Вашему он в Red Hat работает на общественных началах за бесплатно?
> Шантажировали раскрытием деталей убийства, совершённого им десять лет назад?
кто его знает, в травле Столмана он таки отметился, так-что может и шантажировали.
>> Может они денег ему платили?
>>>> "Кэрол Хербст (Karol Herbst) из компании Red Hat"
> а по Вашему он в Red Hat работает на общественных началах за
> бесплатно?Ок, допустим, проплатили. Как ты думаешь, если мы прогуляемся до crates.io и проверим, как много крейтов там создано под эгидой корпораций? Половина от опубликованного наберётся? Десяток фреймворков для создания сайтов -- это похоже на управляемый процесс? Десяток пилящихся gui тулкитов -- это похоже на управляемый процесс? Даже если это управляется корпорациями, то управляется по принципам лебедь, рак и щука, причём там десятки таких несогласованных управленцев. А это уже равносильно неуправляемому процессу.
Вот доступ к базам данных, похож на управляемый процесс: всего две ORM -- diesel и quaint, и они сильно разные приоритеты имеют (для первого важнее всего type-safety, для второго -- асинхронность), а изобилие драйверов для разных бд вполне можно объяснить тем, что этих разных бд много. Но это можно объяснить и иначе: люди не любят ORM, потому что они абстрагируют от конкретного движка СУБД, прибивая гвоздями к стандартному набору фичей, разбавляя это leaking abstractions, и приходится кучу деклараций и логики писать, без которых можно обойтись, сделав sql_query("SELECT ..."), и разобрав результат как есть.
> мы прогуляемся до crates.io и проверим, как много крейтов там создано под эгидой корпорацийпрогуляемся повнимательней:
- crates.io создан и принадлежит rust foundation
- список хозяев rust foundation https://foundation.rust-lang.org/membersни одной корпорации замечено не было!
> Даже если это управляется корпорациями, то управляется по принципам лебедь, рак и щука, причём там десятки таких несогласованных управленцев. А это уже равносильно неуправляемому процессу.
ты переводишь стрелки. корпорации пропихивают язык. им пока не нужно на нём писать. как только crates.io наполнится тем, что по-твоему там отсутствует, они поимеют профит. корпорации важен результат, а не быстрота
> Вот доступ к базам данных, похож на управляемый процесс: всего две ORM -- diesel и quaint....
мало того, что перевёл тему, так ещё и наглая реклама. после этого предлагается верить, что пропихивание рака везде - спонтанный процесс
> Если ты научишься различать стихийные процессы и управляемые процессы, то ты получишь себе в копилку дополнительный инструмент детектирования теорий заговоратебе самому бы в копилку чуть
> Новости про успехи rust'а
> про успехиновости ползут, успехов как не было так и нет
> Новости про успехи rust'а ползут, если можно так сказать, "снизу": они "стихийное" явление.
стихийнее некуда
https://foundation.rust-lang.org/members/
оказывается, программа M$ Students не закончилась. на лоре тоже старые акки оживают и начинают дичь втирать
> Само слово rust мне уже чем-то напоминает "нанотехнологии" и "инновации" времен конца 2000-х.Хорошее сравнение. Кстати, Котлин с тем же ассоциируется. Даже хуже. Если раст обычно упоминают троллинга ради, то фанатики котлина действительно носятся с ним серьёзно.
Давно заметил что читатели opennet делятся на два типа по отношению к Rust:
- те кто пишет подобные комментарии (и даже хуже) - сразу видно с Rust вы не знакомы
- те кто на нем пишет (придя к нему сами)
Отсюда и такая поляризация мнений.
Rust это уникальный язык, и именно поэтому он такой популярный. Rust это не религия, а инструмент. Есть инструменты полезные, а есть уникальные, такие без которых невозможно решить определенные проблемы. Так вот Rust именно такой инструмент. При увеличении размера программы и числа контрибьютеров, становится трудно (а пророй и невозможно) отследить безопасность того или иного действия (патча) в языке который не гарантирует безопасность такого действия (типа С или С++) (в патчах в ядро обязательно пояснять почему разыменовывание указателя безопасно в комментарии). Тенденция к переписываю мне тоже понятна, ибо я сам переписал на Rust свой проект с Python - в Rust больше возможностей языка и гарантий (это не только безопасность памяти, но и уникальный баланс возможностей функциональных языков без необходимости следовать всей парадигме функционального программирования).
Я правильно понял? не нужно будет ставить проприетарный OpenCL от АMD?
Растамановский OpenCL работает со скоростью стоящей в очереди улитки.
Не правильно.
Написано же, что это еще одна реализация того что уже есть в mesa.
Фуу c++/rust в системном компоненте.
А что вы думаете об oreboot?
Да, в системных компонентах должна использоваться только ADA, а еще лучше SPARK.
Кто пишет на rust тому любая девка даст
Даст то может и даст, но им некогда, у них кровь к мозгу больше, а не в тазу. Но природа, в отличие от ИТ, медленно меняется. То, что не исползуется - отвалится, и, как следствие, тупик эволюции.
Van darklhome заинтересован!
> Кто пишет на rust тому Alyssa Rosenzweig дастfixed
Скачал
Спасибо расту за то что Миша Снойман наконец-то оставил хаскель в покое
>Rusticl выступает в роли аналога уже присутствующего в Mesa OpenCL-фронтэнда CloverАстанавитесь!!!11
Очередной хелловорд, который при том даже и близко не доделан.
> Разработка ещё полностью не завершена - уже успешно выполняются тесты CL CTS, связанные с копированием, чтением и записью буферовТ.е. всё что оно сейчас может, это скопировать память из одного места в другое? Ну такое.
Не нравится мне, что этот раст притягивают везде за уши, проталкивают в разные места. Rust это тотальный контроль большого брата над программами. Компилятор тянуть из нета. Пакеты тянуть из нета. Где это виданно что системный язык во время компиляции тянул пакеты из нета. Хотят лишить люд независимости С и простоты С.
> Где это виданно что системный язык во время компиляции тянул пакеты из нета.Системный язык это C? Ну в нем нет пакетов и пакетного менеджера. Поэтому либо держать код всех зависимостей в репозитории, либо ставить либы через системные пакеты (deb, etc).
А ещё он за кофе не бегает. И скажу по секрету: это замечательно.
Что еще замечательного? cmake, meson, autotools и еще 20 систем сборки?
>Что еще замечательного? cmake, meson, autotools и еще 20 систем сборки?Прежде что-то писать, надо уму разуму набраться. 20 разных вИдений способа сборки программного обеспечения.
> 20 разных вИдений способа сборки
> программного обеспечения.20 разных галлюцинаций.
Системный пакетный менеджер и есть пакетный менеджер для си и c++. Поэтому ни один из пакетных менеджеров "специально для C и C++" и не взлетел - не нужен.
>Системный пакетный менеджерЭто когда он есть. На винде, маке и фрибсдм его нет
>>Системный пакетный менеджер
> Это когда он есть. На винде, маке и фрибсдм его нетИсточник: "Вся Правдивейшая Опеннетная Правда о БЗДах, том 118, исправленное издание"?
https://www.freebsd.org/cgi/man.cgi?query=pkg_info&apropos=0...
> pkg_info - a utility for getting information on software package distributions.
> July 18, 1993 pkg_info(1)
> pkg_add - a utility for installing software package distributions.
> July 18, 1993 pkg_add(1)
То есть для распространения своего модуля для Linux только сколько нужно собрать разных пакетов?
Системный это С.Язык Си разрабатывался как язык системного программирования, для которого можно создать однопроходный компилятор.
(с) wikipediaСистемный язык программирования - это язык программирования для разработки системного программного обеспечения. А так, по Вашему - Perl был системным языком, когда это ещё не было мейнстримом (см. их CPAN), аналогично разные Ruby с их Gems и прочие Javascript/Node.js с их приснопамятным npm.
Да бред это всё. Нашли что цитировать, вики которая цитирует "источники".Си это яп для мерзкой примитивной и тупой архитектуры DEC.
Когда он появился разделения ПО на системное и прикладное не было.
> Когда он появился разделения ПО на системное и прикладное не было.Язык C напрямую затачивался под программирование ОС, можно сказать, что его написали для того, чтобы было проще писать и сопровождать разработку ОС UNIX, так-что, имхо, Википедия тут вовсе не врёт.
Скажем так, для очень конкретных процессоров с очень конкретным ассеммблеромм. Это важно и принципиально.То что якобы если верить на слово писателям всяких мемуаров в белл лабс было тяжело писать на ассемблере !утилиты! для юникса и они придумали ему чуть более структурную замену.
>C was originally developed at Bell Labs by Dennis Ritchie between 1972 and 1973 to construct utilities running on UnixC was originally developed at Bell Labs by Dennis Ritchie between 1972 and 1973 to construct utilities running on UnixНу да интересно но это ни разу не "затачивался под программирование ОС". Это создан для облегчения написание утилит ПОД КОНКРЕТНУЮ ОС для КОНКРЕТНЫХ ПРОЦЕССОРОВ.
А то как его потом расхайпали кто, и на каких основаниях, куда интереснее, того где там его в колокол лаборатории изобретали.
> Скажем так, для очень конкретных процессоров с очень конкретным ассеммблеромм. Это важно
> и принципиально.Ну, не знаю, почитал я про их систему команд и т.д. - очень похоже на классические x86 (которые, как пишут, как-раз вдохновлялись PDP-11). Мало того, потом даже C более-менне смог даже лечь на очень их неудачную сегментную модель, как минимум для реального режима. А если учесть, что С существует почти для всех процессорных архитектур, то и получается, что у PDP-11 был не очень-уж и такой "конкретный" процессор. Точнее, все потом пытались создать нечто похожее. и он в итоге не сильно отличался от того, что придумывали потом.
> То что якобы если верить на слово писателям всяких мемуаров в белл
> лабс было тяжело писать на ассемблере !утилиты! для юникса и они
> придумали ему чуть более структурную замену.
>>C was originally developed at Bell Labs by Dennis Ritchie between 1972 and 1973 to construct utilities running on UnixC was originally developed at Bell Labs by Dennis Ritchie between 1972 and 1973 to construct utilities running on Unix
> Ну да интересно но это ни разу не "затачивался под программирование ОС".
> Это создан для облегчения написание утилит ПОД КОНКРЕТНУЮ ОС для КОНКРЕТНЫХ
> ПРОЦЕССОРОВ.Тем не менее, то, что был такой простой и небольшой C помогло портировать Unix на ту-же Interdata [7|8]/32. Думаю, что то, что в более позднее время мешало (например, чёткое указание на размеры типов int), тогда как-раз помогало (в PDP int был 16 бит, а в Interdata уже 32) - не надо было переписывать всё ПО заменяя какой-нибудь аналог int16_t на int32_t.
> А то как его потом расхайпали кто, и на каких основаниях, куда
> интереснее, того где там его в колокол лаборатории изобретали.Ну, как-бы расхайпивать там самая колокольная лаборатория в начале очень даже помогала, и сама выполняла портирование, и помогала другим заинтересованным сторонам.
> Ну, не знаю, почитал я про их систему команд и т.д. -
> очень похоже на классические x86 (которые, как пишут, как-раз вдохновлялись PDP-11).Вот именно.
Ну. Называть это классикой, примерно как ДОМ2 классикой называть.> А если
> учесть, что С существует почти для всех процессорных архитектурХер там, это дурацкий миф. Только для Си процессоров, рисков коротко если - арм х86 risc-v
Конечно и на некоторых не совсем сишных микроконтроллерах есть сишка, но она там и не сишка вовсе, и прикручена из соображений мейнстрима.
> получается, что у PDP-11 был не очень-уж и такой "конкретный" процессор.
> Точнее, все потом пытались создать нечто похожее. и он в итоге
> не сильно отличался от того, что придумывали потом.Вы суть начали улавливать.
> Думаю, что то, что в
> более позднее время мешало (например, чёткое указание на размеры типов int),
> тогда как-раз помогало (в PDP int был 16 бит, а в
> Interdata уже 32) - не надо было переписывать всё ПО заменяя
> какой-нибудь аналог int16_t на int32_t.Может да может нет, а может кому-то в чём-то и мешало.
> Ну, как-бы расхайпивать там самая колокольная лаборатория в начале очень даже помогала,
> и сама выполняла портирование, и помогала другим заинтересованным сторонам.Продвинула сишку конкретно "Digital Equipment Corporation". А не белл лабс.
Сишку и риски, примерно как Майкрософт всему миру Виндовс втулила.
>> Ну, не знаю, почитал я про их систему команд и т.д. -
>> очень похоже на классические x86 (которые, как пишут, как-раз вдохновлялись PDP-11).
> Вот именно.
> Ну. Называть это классикой, примерно как ДОМ2 классикой называть.Удачная архитектура, которая всем понравилась, не уверен, что есть какие-либо аналогии с ДОМ2.
>> А если
>> учесть, что С существует почти для всех процессорных архитектур
> Хер там, это дурацкий миф. Только для Си процессоров, рисков коротко если
> - арм х86 risc-vА Alpha был Cи процессор? а POWER? а Itanium? а прочие MIPS-ы? А то так окажется, что все процессоры "Си-процессоры".
> Конечно и на некоторых не совсем сишных микроконтроллерах есть сишка, но она
> там и не сишка вовсе, и прикручена из соображений мейнстрима.По большому счёту и для x86 реального режима была не совсем Си-шка, там тоже были всякие _ds, _far, _huge и даже _interrupt, что не мешало ей быть диалектом всё того-же C89. Так и для микроконтроллеров - надо не только за "ножки дёргать", но считать всякое, которое не сильно зависит от типа процессора.
>> получается, что у PDP-11 был не очень-уж и такой "конкретный" процессор.
>> Точнее, все потом пытались создать нечто похожее. и он в итоге
>> не сильно отличался от того, что придумывали потом.
> Вы суть начали улавливать.Ну так рассуждать - наоборот, все кроме PDP-11 очень специфичные, раз уже он пошел в мейнстрим, а остальные скатились в маргинальщину.
>> Ну, как-бы расхайпивать там самая колокольная лаборатория в начале очень даже помогала,
>> и сама выполняла портирование, и помогала другим заинтересованным сторонам.
> Продвинула сишку конкретно "Digital Equipment Corporation". А не белл лабс.
> Сишку и риски, примерно как Майкрософт всему миру Виндовс втулила.Про Си не знаю, а про риски - не уверен - у них тогда был VAX, который совсем не RISC, если я правильно помню. А Alpha, которая была позже, так и не взлетела.
>Удачная архитектура, которая всем понравилась, не уверен, что есть какие-либо аналогии с ДОМ2.Виндовс удачная ОС которая всем понравилась.
Андроид удачная ОС которая всем понравилась.
Байден удачный президент который всем понравился.
И Пу удачный президент который всем понравился.
Ну вы поняли.
>> Скажем так, для очень конкретных процессоров с очень конкретным ассеммблеромм. Это важно
>> и принципиально.
> Ну, не знаю, почитал я про их систему команд и т.д. -
> очень похоже на классические x86 (которые, как пишут, как-раз вдохновлялись PDP-11).Очень мало там общего. Набор команд PDP-11 изучается за пару часов, при этом можно работать с восьмеричным (там так принято) опкодами, дампы вполне читаются без дизассемблирования. Самому не довелось, но слышал, что многие писали сразу в машкодах.
16-ти разрядный набор команд x86 -- не хочу вызвать реакцию фанатов, потому постараюсь наиболее мягко -- результат ухода наиболее грамотных специалистов из intel в Zilog. Удобным для человека процессор стал с приходом IA-32 и плоской модели памяти.
>>> Скажем так, для очень конкретных процессоров с очень конкретным ассеммблеромм. Это важно
>>> и принципиально.
>> Ну, не знаю, почитал я про их систему команд и т.д. -
>> очень похоже на классические x86 (которые, как пишут, как-раз вдохновлялись PDP-11).
> Очень мало там общего. Набор команд PDP-11 изучается за пару часов, при
> этом можно работать с восьмеричным (там так принято) опкодами, дампы вполне
> читаются без дизассемблирования.я в сами опкоды не вчитывался - по диагонали посмотрел что пишут на английской википедии, про универсальную команду mov, которая и в Intel может копировать что попало куда попало, но в пределах разумного (только память-память не умеет). А про страшное кодирование системы команд у Intel - с этим никто не спорит, по нему уже давно все оттаптываются. Хотя базовая система команд, которая была в исходном 8086, именно мнемоники, тоже не такая уж и огромная
> Самому не довелось, но слышал, что многие писали сразу в машкодах.
Про это тоже слышал (были такие УК НЦ - я так понимаю советский клон PDP-11), там да, ребята знали систему команд наизусть и могли ассемблировать прямо в память. С Z80 тоже было, в этом плане, нечто подобное.
Ну я некоторые опкоды того Zilog-а до сих пор помню, многие приходилось именно запоминать. С PDP-11 ситуация иная: достаточно понять, по какому принципу и из каких полей формируется команда, и можно самому почти всю таблицу написать. И многие в то время мыслили именно тем принципом и восьмеричной системой.Вот здесь https://www.opennet.me/openforum/vsluhforumID3/125293.html#59
Ordu пишет, якобы Rust возник стихийно. Возможно, это так.Си совершенно точно возник стихийно, под влиянием обстоятельств, на PDP-11 ничего иного не могло возникнуть. Оттуда же и "восьмеричные" права UNIX.
> 16-ти разрядный набор команд x86 -- не хочу вызвать реакцию фанатов, потому
> постараюсь наиболее мягко -- результат ухода наиболее грамотных специалистов из intel
> в Zilog. Удобным для человека процессор стал с приходом IA-32 и
> плоской модели памяти.Кстати, с приходом ia-32 в чём-то стало хуже - зачем-то попытались дескрипторы сегментов сделать совместимыми с 286, где впервые появился защищенный режим, но ещё 16-ти разрядный. Скажем честно - выглядело это очень не очень - когда одно логическое поле в итоге было разрезано на три части, которые хранились в разных местах дескриптора.
А сегментные регистры почти не нужны в плоской модели, в непривилегированном режиме незачем этим голову забивать. Если же углубляться в ядро, придётся вникать во всякие IDT и прочее, где такие "не очень" обычное дело.
> А сегментные регистры почти не нужны в плоской модели, в непривилегированном режиме
> незачем этим голову забивать.С этим согласен, в x86_64 они там совсем, как я понял, рудиментными стали и flat model полностью победила, а до того, использовались для разных TLS, которые thread local storage, в общем не совсем по назначению, имхо..
> Если же углубляться в ядро, придётся вникать во всякие IDT и прочее, где такие "не очень" обычное дело.
да, в IDT те-же дескрипторы, и такие-же страшные. В общем в этом смысле наследие 80286 сыграло с Intel злую шутку, ну а заодно и со всеми разработчиками всякого низкоуровневого, которым с этим потом пришлось иметь дело.
> Компилятор тянуть из нета.Ну можно собрать если нет желания. С gcc все также.
> Пакеты тянуть из нета.
Можно код всех зависимостей выкачать заранее: https://blog.rust-lang.org/2019/08/15/Rust-1.37.0.html#built...
>Можно код всех зависимостей выкачать заранееУ чистой сишки зависимости имею развер килобайт, в основном Glibc и только. У Раста 5 гигабайт крейтов, трейтов, блэйтов, и ибейтов.
То есть вы удалили все библиотеки со своей системы?
>То есть вы удалили все библиотеки со своей системы?Зачем что-то удалять? Чистый Си - это плоть и кровь GNU/Linux. Раст - это чужеродное образование. Говорим Unix-like подразумеваем чистый Си, говорим чистый Си подразумеваем Unix-like.
Ну, просто зависимости весят не килобайты. Тут скорее идея в том, что "деды так жили, и мы так будем жить", принципиально отвергая возможность постепенных изменений.
Идея называется "в чужой монастырь со своим уставом не ходят". Деды так не только жили, но и создали систему. И эта система воспроизводит сама себя. Если есть уверенность, что изменения не отразятся на системе негативно, нет смысла кого-то убеждать и агитировать, надо просто взять и сделать где-то обособленно в сторонке, а потом показать готовый результат. Если результат окажется лучше, но система его не примет -- плевать на систему, этому лучшему результату уже не нужна будет старая система.
Ну так rust community так и делает. Оно просто пилит потихоньку. И эта новость тому подтверждение.
"Поддержка Rust рассматривается как экспериментальная, но уже согласована для включения в ветку linux-next." https://opennet.ru/55443-rustlinux-next это основная ветка и есть. "В сторонке" это linux-media и т.п.
То есть я правильно понимаю, что ваша претензия к Rust заключается в том, что главный "дед" разрешил писать драйверы не только на Си, но и на Rust?
Нет, не правильно. Претензия -- это производное от "претендовать", а завладеть Rust-ом я не в праве. Быть же недовольным языком программирования -- не продуктивно, это всё равно что быть недовольным стеной. И если деятельность "rust community" на деле отличается от ранее Вами описываемой, то не надо на кого-либо стрелки переводить.
Много вы приложений на чистой сишке скомпилируете то?
Та-же меса для сборки питона если что требует.
А в случае с Си вы дискетами перекидываете? У Rust под пакеты точно такие же git репозитории. Каждый раз тянуть не обязательно, достаточно один раз.
Пакеты тянет не компилятор, а пакетный менеджер. Просто в случае Си вы используете apt, а в случае rust -- cargo.
Лучшеб добавили найтивную поддержку гетерогенных вычислений в сам язык.
И как ты себе это представляешь?
Лучше бы r600-бэкенд доделали до уровня, позволяющего запустить hashcat.
Они решили юзерспейс на расте переписать? :think
Хахаха, теперь ещё и меса будет падать.
Для Mesa деградирует фронтэнд OpenCL, написанный на языке Rust.Поправил.
> Из плюсов поддержки Rust упоминалось повышение безопасности и качества драйверов за счёт избавления от типовых проблем при работе с памятью, а также возможность включения в состав Mesa сторонних наработокЧто только народ не согласен делать, лишь бы умные указатели не использовать.
> Что только народ не согласен делать, лишь бы умные указатели не использовать.Для этого надо читать книжки или хотябы статьи. Не говоря уже о стандарте. А этого они не могут, многа букаф, не осиливают. Проще повторять мантру про раст.
И кстати не толко указатели. Уже и проблем с выходом за пределы массива давно нету. Всё "типа решаемое" растом уже давным давно решено когда его ещё в природе не было.
Но им то откуда знать если даже книжек не читать. Это стандартное поведение неудачников неосиляторов. Сидеть, ныть и ждать пока за них кто-то всё решит.Потом правда ныть что не так как они себе придумали.