Опубликован релиз 1.48 языка системного программирования Rust, основанного проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54113
Специальная олимпиада в комментариях объявляется открытой.
Let the srach' begin...
Системный язык, а такой малопортируемый, аж стыдно. Nim благодаря бекенду C/C++ портируется куда угодно.
Нет платформ, кроме юникс лайка и виндовс
И? Я про них и имел в виду. Даже в них он портирован не везде нормально.
У вас опечатка в слове "linux на полутора аппаратных платформах из сотен".
Это если вы про домашние компы. Но вот предприятия могут заплатить за софт в разы больше чем несколько млн. пользователей.
А мак? А, прости Господи, фрибсд?
Не правда. Debian поддерживает большинство. Можно и Gentoo собрать. 1,5 платформы – это вам к винде.
Системный язык, не требующий понимания работы с указателями?
Ой-вей. Даже в Visual Basic можно напрямую с памятью работать...
Системный язык программирования - это на котором можно написать системные компоненты, библиотеки, приложения.Для абсолютного большинства такого софта нет никаких ограничений на управление памятью.
С какого момента стало считаться, что если нельзя написать ядро - это не системный язык программирования?
Во-первых, на Nim можно. Во-вторых по всем бенчмаркам он по потреблению памяти и производительности часто обгоняет и Rust, и чистый C. Хотя у него достаточно простой сборщик мусора.
И для embedded он тоже отлично подходит
>библиотеки, приложенияА это прикладное программирование.
>С какого момента стало считаться, что если нельзя написать ядро - это не системный язык программирования?
С момента определения критериев системного языка программирования.
>Во-первых, на Nim можно. Во-вторых по всем бенчмаркам он по потреблению памяти и производительности часто обгоняет и Rust, и чистый C.
И каким образом, если язык транслируемый? Особенно интересно, как скормленный компилятору си код из транслятора быстрее, чем тот-же код не из транслятора. Это такой-же бред, как заявлять, что ассемблер медленнее, например, раста.
>И для embedded он тоже отлично подходит
И каким образом? Вы-же выше писали, что на нём нельзя написать ядро.
> И каким образом? Вы-же выше писали, что на нём нельзя написать ядро.
> > Во-первых, на Nim можно.И даже без этого, для embed он тоже может подойти, там обычно нет динамического выделения памяти, и даже если нужно, в Nim можно явно вызывать malloc/free. Зачем он во встройке -- это другой вопрос, но использовать вполне реально. Хотя бы как макроязык поверх C.
> Особенно интересно, как скормленный компилятору си код из транслятора быстрее, чем тот-же код не из транслятора
Скорее всего, очень крутой спец на C напишет код лучше, чем очень крутой спец на Nim.
Средний программист на Nim, с другой стороны, вполне может получить более быстрый код на C.
Любые заявления, что нужно становиться лучшим спецом по C идут в комплект с нужно становиться лучшим спецом на ассемблерах. Для критичных мест уж проще делать C/ASM вставки, благо, это реально.
C/C++ лишь бекенд при компиляции. Никакого удобночитаемого Си кода там не будет. За этим в Vala.
Бенчмарки тут, к примеру: https://github.com/kostya/benchmarks
Как видите, Nim держится достойно, порой обгоняя Rust и даже Си.
Даже Nim быстрее раста. Ещё вопросы?
Только в программе на Rust зачем то используют сетевое соединение:fn notify(msg: &str) {
use std::io::Write;
if let Ok(mut stream) = std::net::TcpStream::connect("localhost:9001") {
stream.write_all(msg.as_bytes()).unwrap();
}
}Уверен, что для замедления кода.
Ага. При этом C++ версия использует libnotify, когда в правилах тесте написано, что тестируется с использованием только стандартных функций.Еще момент: в Rust зачем-то конвертируется строка в набор unicode-символов перед итерацией, тогда как в C++ итерация идет по байтам.
В общем, шляпа это, а не тест. В каждой реализации тестируется разное.
Сишные бенчмарки там плохи - ну что это:
>> char *out = output;
>> ...
>> while (str != ends) {
>> uint32_t n = __builtin_bswap32(*(uint32_t*)str);
>> *out++ = chars[(n >> 26) & 63];
>> *out++ = chars[(n >> 20) & 63];
>> *out++ = chars[(n >> 14) & 63];
>> *out++ = chars[(n >> 8) & 63];
>> str += 3;
>> }.
Иначе Nim будет не_быстрее !!1111
Он просто не компилируется если вы не умеете с указателями работать.
> Он просто не компилируется если вы не умеете с указателями работать.Я, я умею, смотрите, смотрите: unsafe { ...*...*...*****... }
И компилируется прекраснейше. Только потом почему-то падает :-( Наверное, надо было проверить что там в этом указателе? Ну я хз, хруст же ж безопастный язык, хотелось побыстрее наговнякать, а не писать мильен проверок - это и на си может каждый дурак!
> это и на си может каждый дурак!из ваших слов непонятно, иронизируете ли вы, или нет.
А в Nim якобы нельзя?
Требует он всё, но в особых случаях, когда это реально надо, а не когда попало
Самый здравый подход
Это как не летающий самолет. Никакой это не системный язык. И создан он из ложной гипотезы что уязвимости по работе с памятью в нормальных языках появляются случайно, а не кто-то их специально добавляет.
Теория заговора? Есть какая-то организация добавления уязвимости памяти? Интересно и интересно, не расскажете ли?
Есть. И не одна. Любая организация, разрабатывающая софт на C занимается добавлением уязвимостей, связанных с неправильным доступпом к памяти. Особо поехавшие разработчики при этом факты некорректного доступа, отловленные валгриндом и асаном, ещё и отрицать пытаются.
>Есть какая-то организация добавления уязвимости памяти?Как будто ты их сам не знаешь: NSA, CIA, MI6, ФСБ.
Это такой ТООООЛСТЫЙ троллинг? Просто я испытываю испанский стыд...
Разве ZOG выгодно делать уязвимости в языках программирования?
То есть, по-твоему, все уязвимости связанны с памятью, клоун?
95% ошибок это доверять входящим данным без проверки. Без разницы откуда - файл, сокет, ввод, аргументы приложения и т.д. Ошибки с памятью, в основном, тоже являются этой же проблемой - слепое доверие что где-то оно чистится и я не выпрыгнул на границы. Если проблему с памятью можно ещё как-то решить придумав Rust, то остальные 95% сами себя не смогут излечить.
Но ошибки работы с памятью иногда позволяют обойти все защиты, что поставили для предотвращения SQL инъекций, command line инъекций и всяких других инъекций.
Я и вижу, как в безопасном "PHP" каждый второй Moodle не изобилует то залочками, то SQL-инъекциями, хотя казалось бы…
> Если проблему с памятью можно ещё как-то решить придумав Rust, то остальные 95% сами себя не смогут излечить."Сами себя" не смогут. Но если ты приложишь чутка усилий, то ты сможешь заставить своих программистов не совершать ошибок типа "забыл проверить входящие данные". Система типов ведь для специально для этого и дана, чтобы описывать в ней требования по работе с данными.
У тебя есть два варианта, либо создать тип Checked<T>, либо тип Unchecked<T>. За каждым из типов прячутся разные стратегии. За первым -- отказываться работать с T, если он не был завёрнут в обёртку Checked -- но это надо переделать все API за которыми прячется код работающий с T. За вторым -- заворачивать все входящие T в Unchecked<T>, и обрезать все возможности для программиста добраться до T, кроме как вызвав метод Unchecked::check(&self) -> &T. Этот вариант не требует кардинальных изменений API, но надо будет отследить все места, где данные входят в программу.
Есть ещё подход -- принудительно проверять всё в момент создания T, и это хорошо, но ровно до тех пор, пока у тебя нет возможности столкнутся со 100500 инстансами T, из которых реально нужны лишь парочка. Раст, кстати, так делает со строками: он проверяет валидность utf8-строк на входе, программер может отложить эту проверку на потом, жонглируя &[u8] слайсами, но ежели он хочет API для работы с черектерами и строками из них, ему придётся вызывать конструктор str, а тот проверит валидность utf8.
Твои проблемы решаются даже без раста, если по-хорошему. И они решались ещё до появления раста именно таким образом. Я подцепил идею, по-моему, из cl-sql, который давал API для сборки строк SQL-запросов, при этом проверял и экранировал все непроверенные/неотэкранированные ещё строки, при этом не проверяя и неэкранируя то, что не нужно экранировать.
Системный язык, в релизах которого до сих пор нет доступа к SIMD - это какой-то совершенно не системный язык. Ну или это такой себе "системный" язык из экосистемы GNOME, где перегибают с минимализмом.
> SIMD and vendor intrinsics module
Простите. Имел ввиду не только SIMD, а instrinsics в принципе:https://doc.rust-lang.org/std/intrinsics/
> This is a nightly-only experimental API. (core_intrinsics)
> Простите. Имел ввиду не только SIMD, а instrinsics в принципе:
> https://doc.rust-lang.org/std/intrinsics/
>> This is a nightly-only experimental API. (core_intrinsics)"intrinsincs" практически не нужно. Особенно SIMD.
Нужны эффективно сделанные функции. Иногда они могут быть реализуемы одной ассемблерной командой. В других случаях (и их большинство, и особенно это касается SIMD) эти функции должны делаться прямо на Асм.
Возьмём например вычисление синуса. Там где есть машинная команда его вычисляющая, естественно ожидать, что обращение (в языке высокого уровня) к соответствующей функции скомпилируется в эту машинную команду. В других случаях произойдёт вызов подпрограммы. Команды SIMD сами по себе ничего особенно интересного не вычисляют. Их место в специальных функциях (вроде видеокодеков например) и соответствующих библиотеках.
Только мне кажется, что синтаксис выглядит уродливым? Намешали боб с горохом, 6аслоили огурцы и яблоки.
Да так оно и есть, они скрестили кресты с ML, добавив рандомайзера, а потом объявили, что долго трудились над созданием нового языка. Разницу пропили.
Не понял. В соседней ветке про движок Servo говорили что проект закрыли. Я поверил и бросил учить как бесперспективный :)
Servo это же браузерный движок, лучше в Интернет заходить перестал.
А как это относится к расту?
Servo на Rust?
Ну и что? Разве Servo единым?
Да, мы вот - прекрасно обходимся. И, заметьте - у нас 80% интернета, и еще 20 у откушенных, которые тоже обходятся. А у мурзилы - ноль."И в том зрим мы для всех [хрустописак] благий пример!"
Больше тратьте время на написание ненужно на нескучном безопастном язычке - и вы нам совершенно не угроза.
"Кто не пишет на расте - тот ест" (с)
Разогнали и тех и других и тех кто делает движок и тех кто делает язык.Любители смузи узнали что кроме памятебезопасоности есть еще куча проблем с безопасностью которые они покрыть не в состоянии. А так как на получившемся велосипеде еще и невозможно писать программы его закрыли.
> невозможно писать программыЧто за чушь?)
Не чушь, а мелкая ошибка в форме глагола - "написать". Писать-то можно, причем - бесконечно.
Но доделать до работающего - ни у кого пока не получилось.А бесконечные деньги кончились даже у мурзилы - и писатели хрусть-хрусть массово полетели за борт без спасательных плотиков.
Другие гребцы толпятся у борта, и чавойта ржут.
Это никак не коррелируют с языком)
Как раз на Расте писать комфортно, в отличие от многих других языков, особенно C.
как и было сказано - писать можно, ДОписать до чего то юзабельного - никто не смог.
Что конкретно на нем не смогли дописать, что смогли на другом языке?Если вам приведут пример софта, где частично используется раст, как фаерфока, вы скажете "что ж ани ни асилили полнастью переписат, ни нужна!". Если привести пример полностью на раст, как редокс ос, скажете " ни нужна, есть 100500 аналогов, раст только для нинужна". Такие у вас вот обычно дискуссии
> Что конкретно на нем не смогли дописать, что смогли на другом языке?Ничего не смогли, в том и дело.
> Если вам приведут пример софта, где частично используется раст, как фаерфока, вы
> скажете "что ж ани ни асилили полнастью переписат, ни нужна!". ЕслиЕстественно.
> привести пример полностью на раст, как редокс ос, скажете " ни
что она никому не нужна и никем не используется. Снова здрасьте.
> нужна, есть 100500 аналогов, раст только для нинужна". Такие у вас
> вот обычно дискуссииНу, да.
По факту - ни браузера у вас нет. Ни линукса (или хотя бы там - макоси). Одни недоделки и феерическое ненужно для запуска в ненужном эмуляторе.
Вот там еще от одного анонима список - так и хочется спросить - кто все эти люди и зачем они ненужно?
Ну ладно, подождем, подождем - вдруг свершится чудо, хоть ruffle окажется не bullshit bingo а работающей альтернативой.
Хотя, конечно, открытое правление рептилоидов в ближайшие двести лет более вероятно.
>)Фронтендер, идите обсуждать языки на платформу "ВКонтакте", вас там поймут и оценят.
alacritty, ripgrep, boringtun, dropbox, discord, trust-dns, polaris, resvg.Действительно, ни у кого не получилось.
Это не чушь. мозилла за 20 лет не написана браузер на руст? Не на присала (то что некоторые части фаерфокс на руст не считается). Значит невозможно.
Точнее, передали другим, выбросить и забить было жалко.
Язык молодой, к нему только присматриваются остальные конторы. Если посмотреть новости по всяким Микрофейсгуглам, то везде "мы тут применили его в небольших задачах, переписали мелкие сервисы, ваукруто, будем пробовать дальше". Скорее всего, пробовать реально будут и скорее всего, пробуют прямо сейчас. А вот итоги этих больших проб будут ещё не скоро.
Начал писать учебный проект на раст. Посмотрим, что выйдет, хочу реально познать, что чего стоит. Пока написал генерацию перестановок, вроде жить можно
а в планах чё? как жизнь вообще?
Математические подсчёты, максимальная клика графа и некоторые другие подобные вещи
ну это скучно. Айда какие-нибудь красно-черные деревья хотя б
Красно-чёрные деревья, как и вся эта linked машинерия довольно плохо показывает себя на современных процессорах, в связи с тем что она не может в локализацию размещения в памяти. Кеш-промахи на кеш-промахах. Если тебе не нужны какие-то особые свойства сортированных деревьев, и всё что тебе нужно ассоциативный массив, то лучше хеш-табличку брать, она локализует.Красно-чёрные деревья тогда взлетели в популярности на фоне DoS'ов на хеш-таблички нацеленных, но это быстро кончилось, потому как проще в хеш-табличку запилить хеш-функцию с умом сделанную -- потеряешь чуть больше на вычислении хеша, зато память почём зря грузить не будешь работой.
> Красно-чёрные деревья тогда взлетели в популярностиВот и выросло поколение хрустов. У них особые хеш таблички работающие быстрее деревьев. Ура товарищи, поколение готовое к уборке польской клубники - готово войти в строй !
А ты веришь в то, что деревья работают быстрее? У тебя какие-то измерения на руках есть, или может ты читал кого-то, кто намерял такое, или ты просто так веришь, религиозно?
Я посчитал за тебя. Я взял 10M пар рандомных u64 и использовал их как ключ/значение для внесения в native-american/afro-american деревья и те же ключи/значения в хеш-таблички. Прошёлся несколько раз по этим парам, деля их поровну между разным количеством ассоциативных массивов. Например, в первый раз был миллион хештабличек и миллион деревьев, каждое из которых содержало 10 пар ключ/значение. На последней итерации было по сто хештабличек и деревьев, в каждом из которых было 100k пар.При этом на каждой такой итерации я замерял суммарное время создания и время суммирования всех значений хранящихся в контейнерах.
Хештаблички использовали дефолтную хешсумму стандартной растовой реализации хештабличек, то есть с устойчивостью к HashDoS. Память под хештаблички я не предвыделял (размеры можно было посчитать заранее и предвыделить, но я решил, что это будет нечестно по-отношению к деревьям).
Так же, я НЕ пытался намеренно создавать деревья таким образом, чтобы их элементы были бы максимально ровным слоем размазаны по куче -- все пары ключ/значение каждой таблички я вбрасывал серией, чтобы все выделения памяти связанные с деревом были бы последовательны и ничто бы не затёсывалось между ними.
Подробности по ссылке[1]. Ниже результаты (ах, да, euclidian distance нужно игнорить, это типа для грубой проверки одинаковости содержимого получившихся структур).
generated 1000000 + 1000000 maps of size 10
Euclidian distance between sums: 0
htable: (1.4651s, 0.2207s) (GenTime, SumTime)
rtable: (1.2479s, 0.3766s) (GenTime, SumTime)
generated 100000 + 100000 maps of size 100
Euclidian distance between sums: 0
htable: (1.1254s, 0.1540s) (GenTime, SumTime)
rtable: (1.1358s, 0.4749s) (GenTime, SumTime)
generated 10000 + 10000 maps of size 1000
Euclidian distance between sums: 0
htable: (1.3795s, 0.1816s) (GenTime, SumTime)
rtable: (1.4985s, 0.5023s) (GenTime, SumTime)
generated 1000 + 1000 maps of size 10000
Euclidian distance between sums: 0
htable: (1.2782s, 0.2284s) (GenTime, SumTime)
rtable: (2.0798s, 0.5645s) (GenTime, SumTime)
generated 100 + 100 maps of size 100000
Euclidian distance between sums: 0
htable: (1.4600s, 0.2728s) (GenTime, SumTime)
rtable: (6.1659s, 1.3407s) (GenTime, SumTime)Как видишь, на размерах до сотни пар (ключ, значение) хеш-табличка может создаваться чуть медленнее, но к размеру в 100k пар, дерево создаётся в разы медленнее. Суммирование же всех значений по этим контейнерам всегда быстрее на хеш-табличке. То есть, можно предположить, что при заполнении map'а высчитывание хеша плюс-минус компенсируется кеш-промахами, пока этих кеш-промахов не становится совсем уж много (по нескольку штук на каждую вносимую пару, их ведь O(log(N)) где N -- это количество элементов в дереве). При итерации по всем элементам, когда хештабличке уже не нужно считать хеши, она работает быстрее, хотя дерево продолжает так же мазать мимо кеша.
Я тебе реально говорю, деревья могут быть лучше, если тебе нужно, скажем, сортировать элементы, то есть нужны какие-то особые свойства деревьев. И то, стоит подумать, нельзя ли как-нибудь на хеш-табличке выкрутиться. Но если тебе нужен просто ассоциативное отображение, то деревья в помойку летят сразу.
Спасибо, познавательно.
Сразу минусы, что интересно, то есть на опеннете писать на языке и самому разбираться в вопросе не поощряется?
Поощряется. Но не в комментариях к новостям, а на форуме.
Тут, если что, обсуждается сам сабж, а вовсе не учебные проекты на нем.
Ну просто по обсуждениям иногда складывается впечатление, что половина хейтеров сам язык в глаза не видела.Я ещё могу понять похвальбу без опыта работы с языком, идеи-то в нем интересные заложены. Но дикий хейт в духе "гарантии безопасности не нужны, пиши на Си", ну он странноват
как язык вне системного применения будет наверно шикос. системное.... ну тут как раз все предлагаемые преимущества куда то пропадают. улучшат то может быть.
Его единственный шанс что кто-то напишет над ним нормальных фреймворк как рельсы для руби, которым можно будет хоть как-то нормально пользоваться.
>как язык вне системного применения будет наверно шикос. системное.... ну тут как раз все предлагаемые преимущества куда то пропадают. улучшат то может быть.на расте давно уже юникс-подобную микроядерную ОС (Redox) с простеньким казино и шлю... GUI и пакетным менеджером запилили (даже недобраузер, калькулятор и реверси запилили), но для некоторых опеннетовских специалистов он всё равно упорно не системный. Для этих особенных опеннетовских специалистов - раст так же как и Си позволяет при необходимости напрямую работать с памятью. Более того, настоящими специалистами раст как раз считается перспективным для разработки ядер операционных систем. Или мсье пропустил новости и дискуссии о возможном включении раста в разработку ядра линукс, написании на нем драйверов?
PS: Куда уж системнее (написанная микроядерная ОС, обсуждение титанами разработки ядра линукс возможности включения языка в возню с ядром)?
Ведущие опеннетовские аналитики вам ответят, что редокс такой же хеллоуворлд, как и все, что на раст, поэтому не считается, раст г..., у-тю-тю! Ну вы понимаете, мнение здешних аналитиков выстрадано килочеловекочасами слоднейшего анализа
ну написали её в режиме с++ и что? на плюсах написали в тысячи раз больше полезного. блимн даже на питоне в сотни раз больше если не тысячи. А тут redox? и писали её в сплошных хаках и unsafe. извини что жалуюсь, но обещанной "защищенности" там нет. Её не может быть в местах работы с железом. поэтому как говорится мед, пиво пил , по усам текло , а в рот не попало. и redox из разряда - посмотрите как я могу. ну если у человека голова нормальная он и на с/с++ и на расте и многих других сделает. это скорее не от хорошего языка, а от хорошего программера. дай ему вруки другой язык он сделает может ещё лучше. не превозноси то чего нет.
Чего уж там, не мелочитесь, скажите ещё, что в руках профессионала даже PHP станет языком системного программирования.
Если очень захотеть...
Проблема не в этом, а в оговороке что он решает большую часть ошибок, но это не так. Если не проверять каждый чих от входящих данных - оно не сделает волосы шелковыми. Ничто не спасет от несуществующего файла на который 100% опирается приложение или же того что во входящем сообщении мусор.
Вообще вы правы на сто процентов. Но, согласитесь, если компайлер умеет бить по рукам за явные фейлы с памятью, это лучше чем ничего?
> если компайлер умеет бить по рукам за явные фейлы с памятьюНу смотри, типичная проблема... Из стороннего файла читается два числа: размер буфера и позиция внутри буфера. Выделяем блок, обращаемся по индексу. КАК твой компилер это обработает? Да никак. Только run-time проверка, которая и без раста везде есть.
>КАК твой компилер это обработает?Зная, что при работе с массивом допустимый индекс должен быть в диапазоне от 0 до длины массива указанной при выделении. Компилятор может ПОТРЕБОВАТЬ преобразовать обычный int в тип с ограниченным диапазоном значений(n >= 0 && n < sizeof(array)). При обычных n++ нужно проверять только верхнюю границу, в случае числа из файла, обе. Вообще такое требуется не только указателям, но Rust не Ada, чтобы развить собственную философию недопустимости неправильных состояний любых переменных на этапе компиляции.
Ну опять же, понятно что все ошибки языком не исправить. Если у вас банально ошибка в логике алгоритма, не поможет ни раст, ни си, ни джава, разве только доказательство корректности проги (если не ошибетесь в описании условий корректности).Но ошибки типа дабл-фри, забытое фри, дэнглин поинтер раст так просто не пропускает, нужно уже постараться чтобы их поставить. Это разве мало?
Спасает то, как элегантно тут сделана проверка на ошибки, при чем без использования исключений!
Результат открытия файла пакуется в Result и, пока его не "распакуешь", работать дальше с файлом физически не выйдет.
И остаётся несколько вариантов: или не обрабатывать ошибку и программа в случае чего будет паниковать (сама закрываться) с описанием проблемы, или ошибка будет обработана.
Ну это стырено из языков семейства ML, где появилось несколько десятилетий назад. Кстати, макро WITH-OPEN-FILE из Lisp, тоже адаптированная много где, в данном месте удобнее.
А если функция возвращает `Result<(), Err>`? Это элегантно можно не проверить.
Будет предупреждение компиляции, если значение типа Result никак не используется (потому что тип Result имеет атрибут #[must_use]).
> Если не проверять каждый чих от входящих данных - оно не сделает волосы шелковыми.И не должен. Единственное, что он должен, это обеспечить отсутствие UB и явно указать вам на места с возможными ошибками, чего раст вполне удачно добивается с помощью системы типов.
Написал .unwrap() - ССЗБ
Где? Сейчес там нули.
Публичный эксгибиционизм - да, не поощряется.
Если это ненавидимый экспертами opennet, Rust, то не поощряется.
Поверь ничего больше ты и не сможешь написать. Даже просто судя по тому что такие простые вещи как генерация перестановок для тебя достижение на этом языке.
Почему же это не смогу?
>> Даже просто судя по тому что такие простые вещи как генерация перестановок для тебя достижение на этом языке.Потому что ты даже больше одного предложения в комментариях прочитать не можешь
Это не аргумент, знаете ли. Сейчас достижение это, а потом будет больше. Пока я не вижу фундаментальных препятствий
Если не видишь препятствий, значит, ты ещё ничего не понял...
А какие же препятствия?
Он похоже тоже ещё не понял.
> Потому что ты даже больше одного предложения в комментариях прочитать не можешьууу, кажется, этот комментатор еще более мерзкий чем я. Мне определённо есть чему поучиться
Так раст жыф или мёртв? Что будет с ним через пару лет? Ваши прогнозы.
Стоит ли его изучать сейчас при наличии С++, vala, nim?
Стоит конечно количество вакансий растет.
Язык по синтаксису так себе.
Но на перспективу точно надо учить.Сам поклонник Nim но на него не найти работу.
Честно и на Rust сложновато сейчас.Поэтому в данный момент работаю Go разработчиком.))
На перспективу нужно изучать квантовые вычисления, у раста перспективы весьма мутные.
Если смотрите вакансии - С, С++ - их сильно больше. Раст где то на уровне вижалбейсика.
Ага и следующие лет 40 жрать макароны.
Речь про реальные перспективы.В данный момент я в Go и достаточно просто найти вакансию 4000$+ для Senior 10+ лет опыта.
Даже в России.
Go занял свою нишу нагруженных микросервисов.
И крупные компании готовы платить очень хорошо за Go.
Простые задачи пишутся на PHP, Python, Node.js а тяжелые выносятся в микросервисы на Go.Rust сейчас в этой же нише и его часто тянут вместо Go.
Плюс с Go же он разделяет большую нишу в блокчейн проектах.
И хорошие перспективы в Hardware.Знакомый парень работает в Берлине в блокчейн сфере с Rust.
Оклад в 100к евро до оплаты налогов.
Примерно 75к евро в год или 6,25к евро в месяц(568,75 тыс рублей в месяц) после налогов.
Готовы за 568тыс учить Rust ? ))
> Ага и следующие лет 40 жрать макароны.Какие макароны? Уже извилины проржавели?
> Речь про реальные перспективы.
> ...Вот и дальше по тексту видны все ваши перспективы. Жизнь на планете обезьян и быть одной из них. Вебобезьянкой.
Все ваши перспективы всю оставшуюся жизнь клепать кривые вебсервисы и прочую вебню.
Достойных и действительно проектов вроде автомобилестроения, самолётостроения и т.д., вам не видать. Ну разве что сайтик склепать или апликашку-какашку для мобилок с какими нибудь пакемончиками показывающими статистику.Вот и все ваши перспективы.
> Знакомый парень работает в Берлине в блокчейн сфере с Rust.
> Оклад в 100к евро до оплаты налогов.
> Примерно 75к евро в год или 6,25к евро в месяц(568,75 тыс рублей в месяц) после налогов.Дорогие мои опеннетные былинщики о "100к500/год за раст", довожу до вашего сведения, что в неметчине после 53k в год, минимальная налоговая ставка состовляет 42% (и остается такой до 270к).
Поэтому, в реальности у него от 100к останется где-то 64к евро в год, если он женат (и жена взяла 5 нал. класс) есть пара детей. Если холостой, то 54к евро.
Проверяется любым онлайновым калькулятором налогов, если что
http://www.google.com/search?q=brutto+netto+rechner
>[оверквотинг удален]
>> Оклад в 100к евро до оплаты налогов.
>> Примерно 75к евро в год или 6,25к евро в месяц(568,75 тыс рублей в месяц) после налогов.
> Дорогие мои опеннетные былинщики о "100к500/год за раст", довожу до вашего сведения,
> что в неметчине после 53k в год, минимальная налоговая ставка состовляет
> 42% (и остается такой до 270к).
> Поэтому, в реальности у него от 100к останется где-то 64к евро в
> год, если он женат (и жена взяла 5 нал. класс) есть
> пара детей. Если холостой, то 54к евро.
> Проверяется любым онлайновым калькулятором налогов, если что
> http://www.google.com/search?q=brutto+netto+rechnerДавайте вы оставите свой великосветский тон себе.
Я вам не мальчик к которому можно так обращаться.Живут люди не первый год и прекрасно понимаю как правильно решать проблему налогов.
Семья ребенок + грамотный бухгалтер и фирма через которую все проводится.
На которую идут налоговые вычеты.
Ибо получают ЗП в криптовалюте и проводить это по закону сложнее чем обычно.
Зато криптовалюты освобождённы от НДС.
В каждой стране есть такие возможности друг в Нидерландах платит ниже 20% опять же благодаря фирме и грамотному бухгалтеру.Если вы холост и впервые в Германии да будете платить и церковный налог и кучу лишней херни.
И даже если платить по максимуму оно того стоит.
Страна с высоким уровнем жизни и прекрасной медициной.
И налоги идут на дело, а не на яхты олигархам.И на будущее прежде чем показывать свой гонор и показывать какой вы умный мистер кеп.
Разберитесь в вопросе.
и вежливо уточните почем такой маленький процент указан при налогообложении.
> Давайте вы оставите свой великосветский тон себе.
> Я вам не мальчик к которому можно так обращаться."По плодам^W словам их узнаете их"(с)
> Живут люди не первый год и прекрасно понимаю как правильно решать проблему налогов.
> Семья ребенок + грамотный бухгалтер и фирма через которую все проводится. На которую идут налоговые вычеты.Началось "ты просто не знаишь! А люди ..."
Не бухгалтер, а услуги налогового консультанта или соотв. конторы (маст хев для зарплат выше 35 000/год), не "оклад" (если через фирму), а доход (но и тут шибко умных "крутильщиков" ждет облом), вычитаются еще и различные страховые взносы - пенсионные, медицинские, по уходу ...
Былинщики, как обычно, палятся на мелочах.> И даже если платить по максимуму оно того стоит.
> Страна с высоким уровнем жизни и прекрасной медициной.
> И налоги идут на дело, а не на яхты олигархам.И все, потому что перешли на rust! Или к чему этот спрыг с темы?
> И на будущее прежде чем показывать свой гонор и показывать какой вы умный мистер кеп.
> Разберитесь в вопросе.
> и вежливо уточните почем такой маленький процент указан при налогообложении.Классические опеннетные "пальцы веером и сопли пузырями", но "гонор" конечно у меня.
Дорогой местный знаток "ихних реалий", я "ихнюю" налоговую декларацию уже 17 год заполняю, 8 из них с помощью нал. консультанта/конторы (им идет процент от "возврата", если что), да и о размере айтишных зарплат (в том числе и того, что "остается") знаю совсем не из опеннетных комментариев. Но вы продолжайте, продолжайте ...
Я вижу вы еще и знаток русского языка.
С давлением на авторитет.Я более 20 лет в профессии и повидал таких умников на OpenNet c начала его появления.
В отличии от многих я считаю годы успешной коммерческой разработки не с 13 лет.
Да и пожил в нескольких странах включаю ту в которой вы 17 лет так неудачно заполняете декларацию.
Продолжайте в том же духе зная что есть молодой парень 30+ годов который делает это с умом в отличии от вас.А раз вы такой знаток Google как заявляете советую почитать про налогообложение криптовалют.
Я же не гордый и воспользуюсь информацией любезно предоставленной моим знакомым.Просьба не отвечать и оставить свое мнение при себе.
Мне не интересно тратить время на токсичных людей которые не могут конструктивно обсуждать какие либо темы.
> Я вижу вы еще и знаток русского языка.
> С давлением на авторитет.
> Я более 20 лет в профессии и повидал таких умников на OpenNet
> c начала его появления.
> В отличии от многих я считаю годы успешной коммерческой разработки не с
> 13 лет.Как и ожидалось, как только подловили на деталях, пошел юлеж и много бла-бла с "давлением на личности" и 0 по теме ...
> Да и пожил в нескольких странах включаю ту в которой вы 17 лет так неудачно заполняете декларацию.
Именно поэтому перепутали оклад с доходом. Подумаешь, разница в десяток-другой тысяч на соц. страховки, которые во втором случае оплатить нужно уже с этого дохода. Мелочь. Да и крупная контора по налоговым вопросам, получающая процент - ничто по сравнению с опеннетными "знатоками".
> Продолжайте в том же духе зная что есть молодой парень 30+ годов
> который делает это с умом в отличии от вас.В былинах опеннета вообще каждый третий - помощник Линуса, каждый четвертый - консультирует Кнута ...
> А раз вы такой знаток Google как заявляете
... а читать седалищем и приписывать что-то оппоненту тут умеет каждый второй
> советую почитать про налогообложение криптовалют.
> Я же не гордый и воспользуюсь информацией любезно предоставленной моим знакомым.Об обязательных соц. страховках и тарифах в следующий раз почитать не забудьте, фантазер. Подсказка: медицинская - это 14% c дохода (правда есть кап на 50 с лишним тысячах).
> Просьба не отвечать и оставить свое мнение при себе.
> Мне не интересно тратить время на токсичных людей которые не могут конструктивно обсуждать какие либо темы.Этот былинщик порвался, вносите следующего!
> количество вакансий растетБыл уже такой перехайпаный язычок - руби. Году этак в 2010м по всем публичным местам бегали смузихлёбы и рассказывали ровно то же самое, что сейчас рассказывают про руст. И про "использование крупными компаниями" и про "рост числа вакансий" и про его "безопасность", которая заключается в принудительном ооп и за счёт этого устраняет 100500 надуманных проблем. Пишут на нём до сих пор, и даже есть какие-то продукты-флагманы типа редмайна с паппет'ом, которые пытаются выдавать за "популярность" те кто его по дурости выучил, поведясь на хайп.
Знаем писали.
В 99% случаев это конечно Ruby on Rails был.
Ну хайпы хайпами я в свое время зарабатывал на Ruby больше чем сейчас ))Сейчас Senior в России дай бог 4-5$k зарабатывает.
А в 2013 мне платили почти в два раза больше.
С бонусами больше чем в два.Когда вакансий стало меньше, спокойно мигрировал в Go.
Может мне было проще так как я еще писал на Python.
Но для опытного разраба сменить язык дело пары месяцев.Что тут сказать я раньше на Borland Delphi и С++ писал и где теперь он.
Теперь все в Embarcadero Rad Studio с ценником как у крыла боинга.
А вакансий тупо нет.Надо мониторить вакансии и смотреть в какой технологии и языке хорошие ЗП.
И не тонны legacy говнокода как в Java.С подобным фильтром сейчас платят лучше всего в Go и Node.js.
Это и выучил.Сидеть на попе ровно и кричать что все новое от лукавого как многие тут.
А после получать 50 тыс руб. в месяц с 20 годами опыта не для меня.
> Но на перспективу точно надо учить.На какую перспективу? Чтобы мозги проржавели? Чтобы потом быть не в состоянии ничего кроме вебсервиса сделать?
Ну есть в расте unsafe где можно рабоать с памятью напрямую (а системном без этого никак), но толку ноль. Толку ноль потому что эти люди не будут понимать как работать с памятью.
Не делайте из мухи слона. Займитесь делом.
>> Но на перспективу точно надо учить.
> На какую перспективу? Чтобы мозги проржавели? Чтобы потом быть не в состоянии
> ничего кроме вебсервиса сделать?
> Ну есть в расте unsafe где можно рабоать с памятью напрямую (а
> системном без этого никак), но толку ноль. Толку ноль потому что
> эти люди не будут понимать как работать с памятью.
> Не делайте из мухи слона. Займитесь делом.Я лет 20 делом занят и благо не превратился в мамонта который отвергает все новое.
И вам того же желаю!
Да
Спасибо за подробный и развёрнутый ответ.
Спасибо. Незачто.
у Киркора на "да" есть свой ответ
Зависит от того для чего.Если вы хотите стать переводчиком с человечьего на компьютерный и иногда обратно - то да, учить все языки без разбору, авось пригодятся. )
Если вы хотите решать реальные проблемы то нужно изучать технологии: базовые протоколы, крипту, сети, С, и основные либы для работы с изображениями, видео, математикой, криптой и тп.
Нет не нужно. Если только для развлечения или знать как не надо делать языки.
> как не надо делать языки.После этого неплохо было бы пояснить, чем вас конкретно не устраивает раст
Я мимо проходящий.
Но просматривая код на Rust вижу его невероятную синтаксическую загруженность. Как у C++.И разобраться в коде, что он делает, довольно сложно. Пробираясь через эту замусоренность.
Вот, мимокрокодил, а выводы делает. Шоб вы все были здоровы.Мне тоже раньше казалось, что у Раста с синтаксисом что-то не то.
Однако, достаточно лишь немного начать разбираться и понимаешь, что всё на своём месте да так красиво, что диву даешься.
Конечно, есть объективные претензии к некоторым речевым оборотам, но оно во всех языках есть.А вот C/C++ после Раста радуют всё меньше и меньше. Знаешь, то самое чувство копчиком, что используешь совершенно морально устаревшие технологии, какие бы там 11, 14, 17, 20 стандарты ни выходили. Жизни им ещё надолго обеспечено, но вот свою жизнь продолжать тратить на них становится несколько затратно что ли)
> да так красиво, что диву даешься.Ну тут вы явно преувеличиваете, но в целом "всё не так плохо, как говорят"
> Стоит ли его изучать сейчас при наличии С++, vala, nim?Конечно. Опыт раста будет тебе очень полезен и в C, и в C++, если сам раст не потребуется.
Можно спорить, стоит ли изучать хаскелл или лисп, и насколько это сделает тебя более сильным программистом в других языках. Но то что раст тебя сделает сильнее - это без вопросов.
Я бы плюсанул лисп и хаскелл, на самом деле
Плюсанул если бы знал что это такое.
Ad hominem аргументы вечно в моде.
Плюсануть -- это одно, но вот перечислить конкретные знания/умения/навыки, которые человек оттуда подцепит, и которые окажутся ему полезными -- это другое. Я вот не могу сказать ничего конкретного, лишь всякую неконкретику, типа "функциональный подход".
Что ж, справедливо, тогда давайте раскрою чуть по-подробнее.Лисп - очень изящое мета программирование и система макросов. Вот принято ужасаться этих скобок, а не деле в этом все и изящество - Лисп сразу пишется в виде абстрактного синтаксического дерева. И так как код представлен в виде списков, как и самые обыкновенные данные, то кодом можно манипулировать с такой же лёгкостью, как и данными = метапрог и потрясающая система макросов. Мы в универе писали эмуляцию ленивых вычислений и бесконечных списков в стиле Haskell, вышло очень красиво.
Теперь Haskell. Haskell в шутку можно назвать "плюсами от ФП", ибо они вобрал все основные концепции ФП в себя. Лямбда-функции, использование списков, map/fold к спискам, алгебраические типы данных и сопоставление с шаблоном (pattern matching). Вещи очень удобные. А ещё ленивые вычисления - позволяют работать с бесконечными списками или решать задачи на динамическое программирование в пару строк. Может на самом хаскеле и не будешь прогать (хотя я прогнал, там для парсинга языков удобные библиотеки, например), то получишь хорошее представление о ФП, что ФП-фичи других языков поймёшь легко. Я после курса хаскела в момент разобрался с джавскими streamами, например
> Лисп - очень изящое мета программирование и система макросов. Вот принято ужасаться
> этих скобок, а не деле в этом все и изящество -
> Лисп сразу пишется в виде абстрактного синтаксического дерева. И так как
> код представлен в виде списков, как и самые обыкновенные данные, то
> кодом можно манипулировать с такой же лёгкостью, как и данными =
> метапрог и потрясающая система макросов. Мы в универе писали эмуляцию ленивых
> вычислений и бесконечных списков в стиле Haskell, вышло очень красиво.Вот это и есть неконкретика. Да это красиво, мне тоже нравится. Но если уж говорить неконкретно, то я бы сказал, что lisp учит писать языки заточенные под задачу. Не API создавать для решения задачи, а языки. (Если мысль не ясна, то стоит глянуть на loop из common-lisp'а, на cl-iterate -- это внешний пакет дающий замену для loop; -- на cl-sql -- SQL в синтаксисе s-expr, на лисповские "шаблонизаторы" html'я, если их так можно назвать, хотя они html в синтаксисе s-expr). Я в целом склонен думать об APIs как о языках, после опыта lisp'а, но C'шные API довольно ограничены синтаксисом в своих выразительных возможностях, поэтому я затрудняюсь сказать, насколько мне такое мышление помогает работать с C.
> Теперь Haskell. Haskell в шутку можно назвать "плюсами от ФП", ибо они
> вобрал все основные концепции ФП в себя. Лямбда-функции, использование списков, map/fold
> к спискам, алгебраические типы данных и сопоставление с шаблоном (pattern matching).
> Вещи очень удобные. А ещё ленивые вычисления - позволяют работать с
> бесконечными списками или решать задачи на динамическое программирование в пару строк.
> Может на самом хаскеле и не будешь прогать (хотя я прогнал,
> там для парсинга языков удобные библиотеки, например), то получишь хорошее представление
> о ФП, что ФП-фичи других языков поймёшь легко. Я после курса
> хаскела в момент разобрался с джавскими streamами, напримерДа, это становится конкретикой, особенно если вспомнить о том, что все современные языки -- swift, go, rust, -- набиты функциональщиной.
Код пишется, в первую очередь, для людей, а им гораздо понятнее вменяемый синтаксис, а не AST с туевой хучей скобок. Скобки - это просто синтаксический мусор. Делать вид, что AST'шность является плюсом, может только синтаксический террорист. Это просто прикольная фича для метакодинга и годная отмазка, чтобы компилятор упростить. На деле же, тот факт, что все разные по смыслу языковые конструкции выглядят идентично - жирнейший минус. Это как ассемблере - пока код не прочитаешь досконально раза два-три, не поймёшь, о чёс там вообще речь. А в нормальных языках код можно охватить взглядом и сразу понять, какую его часть имеет смысл разбирать.Haskell в этом смысле антипод Lisp'ам: синтаксис сделан не для роботов, а для людей. Единственный существенный недостаток - фанатично чистая функциональщина, сильно ограничивающая удобство и целесообразность написания кода в реальных проектах.
Короче, оба языка хороши для исследований в области разработки языков программирования, и для этого их и стоит применять, но для практического применения очень слабо пригодны. Вы, конечно же, приведёте примеры вполне юзабельного софта, написанные на них, и я не стану отрицать, что на них писать можно. Вот только не нужно, для этого есть языки поуниверсальнее и поприятнее.
Хороший программист не ищет способов выпендриться умениями вроде чтения Матрицы по абракадабре на экране, а понимает разницу между research и production и выбирает инструмент, соответствующий задаче.
> Конечно. Опыт раста будет тебе очень полезен и в C, и в C++не лучше ли потратить время и деньги - непосредственно на C и C++ ? Опыт в них точно будет полезен для программирования на них же.
А вот про хаскел и лисп спорить не о чем - да, если ты программист а не макака - их надо представлять хотя бы в объеме университетского быстрокурса, чтобы НЕ писать на сях то, что незачем писать на сях.
Или хотя бы понимать, какой жуткой страдаешь фигней, рисуя наколеночную реализацию лямбды.
R и пролог можно пропустить, все равно этим занимаются специальные люди в специальной клетке.
> не лучше ли потратить время и деньги - непосредственно на C и C++?Есть вещи, которые сложно освоить в C/C++. Скажем как ты научишься писать код, который сделает борроу-чекер счастливым, если у тебя нет борроу-чекера? Можно попытаться заменить его статическими анализаторами, но rust может научить думать в терминах лайфтаймов.
Люди, приходящие в раст, часто начинают ругаться матом. И не только из-за борроу-чекера, но ещё и потому, что их привычные способы решения проблем не работают. В расте приходится осваивать новые методы решения проблем, потому что многие привычные для C/C++ программистов в расте под запретом из-за лайфтаймов, или, скажем, из-за отсутствия наследования. Осваивать новые подходы полезно. Развивающе.
> Скажем как ты научишься писать код, который сделает борроу-чекер счастливым,
> если у тебя нет борроу-чекера?а зачем? Если в перспективах у тебя его и не будет, а будет только нечто lint'ообразное или valgrind (то есть если писать все равно на плюсах потом).
По-моему это как раз малополезно для общего развития (ну то есть с тем же или большим эффектом можно осваивать новые подходы к штанге или учиться разводить кроликов), ибо вне экосистемы не встречается.
Полезно. Я пишу на C и вижу места, где борроу-чекер будет ругаться. Более того, я заранее обдумывая ещё ненаписанный код, задумываю его таким, чтобы там не было бы причин бесить несуществующий в C борроу-чекер.> вне экосистемы не встречается.
Смотря что называеть "встречается": то что делает раст -- это доведённое до уровня синтаксиса то, что грамотные программисты на C делают и так. То есть, вроде как и нет, но вроде как и есть.
Rust более популярен чем Nim и Vala вместе взятые.
имела жаба гадюку!
Rust ещё как жив. И набирает популярность. С чего вообще кто-то думает что он стагнирует?Сам на нем пару бекендиков написал. Очень фановый язык
> С чего вообще кто-то думает что он стагнирует?Mozilla облажалась финансово и скинула с себя Rust и Servo на open source сообщество и другие корпорации, которые подвязались на Rust и теперь будут вынуждены его финансировать (Amazon, Google, Microsoft и т.д.). Опеннетовский аноним считал это как сигнал, что Rust - все, потому что фактчекинг не для нашего анонима: наш аноним не читатель, а писатель.
> Mozilla облажалась финансово и скинула с себя Rust и Servo на open
> source сообщество и другие корпорации,в результате майкрософт скупит репу этой штуки и что хотите то и делайте, ведь она одна и централизованая...
Как фановая труба.
Унесите
Это обратно в уборную. И смывайте за собой в следующий раз.
Аргументация во
Всё уже доказано сотни раз...
Что доказано? Что тут много луддитов? Я вот сам не очень люблю многие технологии сегодня, но раст выглядит обещающе в своей миссии
То есть люди, которые против перехода на кастрированный язык, где всё принесено в жертву ради мнимой безопасности, - это луддиты? А люди, которые создают этот язык, наверное в твоих глазах, прогрессивные учёные? Ничего другого от сектантов и не ожидал...
а что ты хотел от ярых противников раста если у них общий IQ меньше 100
Отлично, хейтеры и неосиляторы раста будут выкинут забортному истории.
"Жаль" только мало кто из присутствующих доживёт до этого в этом измерении :)
Лучшый язык, по сравнению с си
Все верно, брат! На этом языке прогает только илита!
Несколько мух не могут ошибиться!
ну знаешь секира выглядит красивее деревенского топора, но дрова ей колоть замучаешься)))
Я тоже люблю неуместные сравнения. Особенно про дельфинов.Вот например, СИ - это как самка дельфин, а раст - он как дельфин самец. Ни тот, ни другой не несут икры.
как язык несистемнорго уровня сойдет, но в систему его смысла нет брать. из за чего и сам знаешь. это как имя того кого недьзя называть. ахаха. но растаманов набежало много. кстати питонщиков и то меньше да и умнеть они начали. а в расте чет школоло много.
Школоло? Этих как раз в C/C++ полно, по понятным причинам.
Средний новичок C/C++ - какой-нибудь первокурсник, до этого почти не программирующий, или школяр, улучшающий свои знания для будущих экзаменов
А вот средний новичок Раста - уже понюхавший пороху. Достаточно народа из C/C++, есть и опытные представители мира скриптовых.
Типичные новички из мира Раста :)
https://habr.com/ru/post/487116/
> переписали с Go на Rustрука-лицо...
Ээм. В чем проблема, собственно?)
В первой итерации переписали на Раст без оптимизаций и получили производительность уровня оптимизированного Go + плюшки отсутствия проблем gc.
Закрытый язык обновился.
в мире тонны шлака обновляются ежесекундно, но надо ли эти пользоваться?
Он не проприетарный вообще-то
Настолько не, что даже технически не поощрает не-опенсорс либы)
Вернее, умерший в комментариях опеннета.
Уже вижу подорванные пердачки опеннетных экспертов которым РАСТНИНУЖОН, но комментарии ещё недостаточно настоялись. Пожалуй, вернусь позже.
Просто фронтэнд этого недоязычка весит пол гигабайта, GCC - 147мб. Вопрос: если растоманы не могут написать нормально ЭТО, то, что говорить о других проектах, о других программистах?
Гениальная аргументация
Если мой аргумент пустой, то ты ведь можешь его раздавить, уничтожить, растоптать, но ты зачем-то надел клоунский нос и пустился в клоунаду. Зачем? Ах, ну, да! Растоманы-то бездарности...
Пол гига - это только бинари. А вот при сборке отжираются все 8 гигов.
Бинарь пол гига? Это ты о чем? Redbox OS которая на расте весит меньше.. С потолка пол гига взял?
>Бинарь пол гига? Это ты о чем? Redbox OS которая на расте весит меньше..И? Речь-то про компилятор. Подмена понятий или тред не читал?
>Просто фронтэнд этого недоязычка весит пол гигабайта, GCC - 147мб.
И кстати про пол гига писал не я. Точно подмена понятий.
Правильно, дай им настояться, и тогда получится качественный дженкем.
Чтобы сделать безопасный язык, который будет обходится без сборщика мусора и рантайма, вот обязательно нужен такой уродливый синтаксис. Что мешало сделать си подобный синтаксис? С заимствованием адекватных конструкций из других языков. Тот же классический switch case заменить на удобный match и пр.
Что ты подразумеваешь под адекватными конструкциями из других языков на момент полувековой давности, раз уж говоришь "мешало", а не "мешает"?
Нормальный там синтаксис, и очень C-подобный
Советую попытаться хоть немного разобраться, будешь сильно удивлен :)
>Нормальный там синтаксис, и очень C-подобныйlet big_n =
if n < 10 && n > -10 {
println!(", малое по модулю число, умножим его в десять раз");
10 * n
} else {
println!(", большое по модулю число, уменьшим его вдвое");
n / 2
};
В каком месте это похоже на Си?
Несколько кубиков сахара, нет скобочек и всё, мозг ломается? :)Вот как это выглядит на C++ (printf для наглядности):
auto big_n = [n] {
if (n < 10 && n > -10) {
printf(", малое по модулю число, умножим его в десять раз\n");
return 10 * n;
} else {
printf(", большое по модулю число, уменьшим его вдвое\n");
return n / 2;
};
}();Колоссальная разница, правда? Только Раст чуть почище.
Тоже C++: auto big_n = n < 10 && n > -10 ? 10 * n : n / 2;
А с int вместо auto заработает и в C.Если для Си-разработчика это слишком сложно, могу только посочувствовать.
> Несколько кубиков сахара, нет скобочек и всё, мозг ломается? :)Да.
> Колоссальная разница, правда? Только Раст чуть почище.
> Тоже C++: auto big_n = n < 10 && n > -10С++ не Си, а чудовищный монстр. Его синтаксис это пример того, как делать не надо. Он такой же "системный" как и Rust, только проблемы у них разные.
Вот на Сint big_n;
if (n < 10 && n > -10) {
printf(", малое по модулю число, умножим его в десять раз");
big_n = 10 * n;
} else {
printf(", большое по модулю число, уменьшим его вдвое");
big_n = n / 2;
};Вывода типов нет, потенциал для получения UB на неинициализированном big_n, ненужные круглые скобки вокруг условия. А так примерно то же самое.
Ну так и Python окажется C подобным. Тоже просто избавиться от лишних скобочек.
Так эти скобочки и в C не нужны. if (n<10) a++; хуже чем if n<10 {a++} из-за потенциальной опечатки if (n<10); a++;
if (n<10); это гарантированный warning, что зачастую ошибка компиляции.
Ну, ОК. "А эту пружину, торчащую из дивана, мы оставили как дань уважения первым разработчикам"
Вот вам подушечка, прикройте её.
зато это потом удобно читать - а для борьбы с глупыми опечатками (хотя мне трудно придумать КАК так вы умудряетесь "опечататься" если это не долбежка носом в клавиатуру - вот ЧТО нужно хотеть нажать чтобы рядом со скобкой появилась ; ? ) как раз и существуют компиляторы.Бесскобочный синтаксис где оператор перемешан с параметрами выглядит совершенно омерзительно.
Ну да, не для тех чье сознание необратимо искажено пихоном.
> КАК так вы"Вы" - это кто? "Все, кроме безошибочного меня"? Ну так это до первой ошибки, вот тогда будете вспоминать, что же вы такое хотели нажать.
> а для борьбы с глупыми опечатками
Ну, в C не только глупые опечатки могут привести к проблемам. Поэтому и существуют предупреждения компиляторов, статические анализаторы, ASAN, TSAN, MSAN, UBSAN и подобные.
> };В конце зачем это " }; "? Нет, ты не сишник, ты си плюс-плюсник. Выше один индивид написал "C/C++" А таукого языка в природе нет.
Если не сложно поясните пожалуйста как в данном примере может быть не инициализирован big_n?
В данном примере никак. Если условие разрастётся, то в одной из веток переменная может быть неинициализирована. gcc предупреждение по этому поводу не выдает.
> В данном примере никак. Если условие разрастётся, то в одной из веток
> переменная может быть неинициализирована. gcc предупреждение по этому поводу не выдает.исторически так сложилось, что такого рода проверками занимаются статические анализаторы (cppcheck, pc-lint, PVS-studio). Сейчас такие проверки понемногу добавляют в компиляторы, но да, с этим действительно пока есть определённые проблемы.
На таком примере:
#include <stdio.h>int main(int argc, char* argv[])
{
int q1, q2, q3;if (argc > 2)
q1 = 1;switch (argc)
{
case 0:
q2 = 1;
break;
default:
break;
}printf("%d %d %d\n", q1, q2, q3);
return 0;
}MSVC 6.0 (98 года разработки) нашел все три использования неинициализированных переменных, как и clang 3.8.1 (). GCC 9.2 нашел только q3. Почему так всё плохо именно с GCC сказать сложно.
>int big_n;
>if (n < 10 && n > -10)
>};Ненавижу когда Си плюс-плюсник выдаёт из себя сишника. Ты совершил 2 ошибки.
-Wall -Wpedantic -WextraКомпилятор доволен. Но верно - я не сишник, и принятых там церемоний не знаю.
Компилятор доволен. Но верно - я не сишник, и принятых там церемоний не знаю.+++ компилятор не искусственный интеллект, то что ему удалось скормить фрагмент кода еще не значит что код работает так как вы там себе возомнили
Нарушенные параграфы стандарта в студию.
> Он такой же "системный" как и Rust, только проблемы у них разные.не, почему - есть и похожие: одуплить что машина реально сделает когда ты тут эти заподвыподверты накодил очень мало кто на этой планете может. к сожалению в системных вещах это достаточно фатально - ведет к массе дурных проблем на ровном месте. торвальдс gcc то костерит за это, а желающих долго и много что-то вот реально системное прогать и вовсе не видно. Как максимум редокс шутейный, и тот - микроядро мертворожденное, наверное как раз чтобы спихнуть все проблемы на пользователя, дескать и хрен с ним что все это тормозит.
> if n < 10 && n > -10 {Не сработает, сравнения надо в скобки взять, иначе компилятор будет ругаться о приоритетах операций.
не могу let напоминает Visual Basic с его Dim или как там
а в целом Perl с магическими символами
нужен синтез c+rust или dlang+rust наверное
9 компаний, который используют Rust в Production
https://serokell.io/blog/rust-companies
6 компаний + 2 noname'а + npm(что символизирует)
И ни в одной из тех шести он не является основным.Интересно, что те, кто пишут на аде не гадят ссылками на языкометрию. Этим занимаются любители жаб и сортирных названий.
> ни в одной из тех шести он не является основнымА должен? Это же системный язык, а не скриптовый
Нынче скрипты более системны, чем раст.
В каком смысле? Раст в чем-то менее системный, чем C или JavaScript? А в чем? :)
Если у тебя в этом списке 2 noname, то ты немного отстал от жизни. Лет на 5
И кто такие, например, coursera?
ты сейчас серьезно или тролль?
> Coursera uses Rust for their programming assignments feature where students need to write and run a computer program to solve a problem.Вот это была хорошая шутка. Заставляют студентов на нем писать, вот это действительно незаменимый язык :D
> Заставляют студентов на нем писатьФормируют у хомяков блевотный рефлекс? Это хорошо... Лишь бы не сдохли и не пошли кричать "Свободная касса!".
спамеры
Тут вот в комментарии в скрытой ветки от критика Rust'а прозвучало, что мол "это кастрированный язык". А что в нем кастрированного, растохейтеры могут объяснить? На расте нельзя чего-то написать? А то очень странное было заявление
проблема не в кастрированности. А в том , что он выполняет заявленные методы безопасности только частично, а рекламировался как безопасный вариант относительно почти всех языков.
Ну вообще я тут с вами в чем-то соглашусь. Назвать раст исцелением от ошибок нельзя. Да и вообще, хардкорное избавление от ошибок разве что в функциональщине с зависимыми типами возможно (и то, там не всегда удаётся завершимость доказать. Ибо неразрешимая проблема). Но ведь лучше всё-таки язык с таким контролем памяти, чем без никакого?Я к Расту присматриваюсь для математических расчётов. Ищу язык, на котором не так легко совершить ошибку, как в Си, но который при этом работает побыстрее без всяких накладных расходов на гц ( как Джава какая-нибудь)
> Назвать раст исцелением от ошибок нельзя=> не нужен.
Нет ЯП который бы исправил тот же дедлок, разве что ЯП однопоточный. Так что на твоём месте бякать не вникая это так себе. Поверхностное мышление
Ну по такой логике надо в машкодах или асме прогать.
идея классная. за полностью. за одно будем запускать по одной линейке процев в 2 года и сразу проводить набор спецов асма. вот будет 100% прогнозируемость развития и такая же работоспособность. при этом не понадобиться такого разнообразия конструкций. будет как у маков 5 типов компов и хватит всем.))) и что самое главное производительность будет на порядки выше современных систем( там вообще наверно будет использована 5 часть того что сейчас уходит на по в работе(ось). вот только это утопия. увы. и отсутствие конкуренции сильно замедлит развитие технологий( которые к слову частенько с боОльшими багами)
На асме человек пишет хуже, чем GCC компилит, не обольщайтесь
> На асме человек пишет хуже, чем GCC компилит, не обольщайтесьзависит от ситуации, поэтому почему-то в кодеках видны комиты вида "SSE4: gain w.r.t. C: 3.5x" - это конечно не глобальный выигрыш, а в тяжелой операции, но когда вот такого там и тут, оказывается что в сумме кодек разика в два быстрее портабельной сишной версии чего-то, и когда это приходит к выбору 720p мы на этом железе сжуем или 1080 - вот извините!
Ещё у тебя может переполниться int при математических операциях на проде. Но выпадет ошибка при отладке.Убираются излишние проверки как плата за производительность.
Нельзя вот так сделать оптимально.
Но в каждом ЯП у цифр есть пределы.
Тот кто жалуется что ЯП только частично безопасный видимо плохо вникал
я вообще склонен считать все языки опасными. какими бы они изначально не задумывались. их делают все таки люди, а нам свойственно ошибаться, в том числе и в самом фундаменте конструкции языков. не зря же все ищут идеальный язык и никак не найдут. но я склонен считать раст незавершенным инструментом( даже сломанным ) чисто концептуально. с/с++ хоть не прикидываются пушистыми, а честно говорят - вот те контроль, но накосячишь сам и выкручивайся. я думаю это проблема маркетологов языка. незачем было так пиарить "безопасность" языка. А теперь все ждут этого, а его нет. только в чистой прикладухе. в системном его реально можно сравнить с плюсами. так зачем столько пиара и гонора.
> Я к Расту присматриваюсь для математических расчётов. Ищу язык, на котором не так легко совершить ошибку, как в Си, но который при этом работает побыстрее без всяких накладных расходов на гц ( как Джава какая-нибудь)В математических расчётах, к сожалению, от статической типизации практически нет никакой пользы - как правило, все переменные типа double/Real/Double/float. Поэтому особенной разницы между Питоном и Хаскелем ждать, увы, не приходится. А уж Rust и C будут вообще неразличимы.
Как мне кажется, достаточно преспективной может быть полиморфные по типу чисел реализация вычислительных алгоритмов. То есть, для быстрого счёта - IEEE 754 double, для тестов - поля Галуа или целые, для контроля вычислительных ошибок - интервальные числа или UNUM. Но тут Rust почти не добавляет плюсов - полиморфизм слишком многословен. Ближе всего, наверное, из имеющихся языков к идеальному Хаскель с включённой по-умолчанию энергичностью вычислений.
Я дискретник, у меня даблов нет вообще. У меня много комбинаторного перебора и алгоритмов на графах
> В математических расчётах, к сожалению, от статической типизации практически нет никакой пользы - как правило, все переменные типа double/Real/Double/float. Поэтому особенной разницы между Питоном и Хаскелем ждать, увы, не приходится. А уж Rust и C будут вообще неразличимы.Эмм... тут ты меня потерял. Что значит статическая типизация не нужна? Если не статическая типизация, значит динамическая, то есть при каждом извлечении значения из переменной мы первым делом выясняем тип этого значения в рантайме, и на основании этого подбираем нужную трактовку операции +. Это ужасно медленно.
Нужна. Но польза от строгой статической типизации далеко не такая серьёзная, как в обычной бизнес-логике, где "компилирующаяся программа на Хаскеле, скорее всего, правильно работает".Увы и ах, но вычислительные алгоритмы очень тяжело типизируются так, чтобы типизация выявляла ошибки.
А, я понял тогда. ок.
> там не всегда удаётся завершимость доказать. Ибо неразрешимая проблемаЭто не так работает. Если не удаётся доказать завершимость, значит есть вероятность, что программа будет виснуть. Поэтому программу меняют так, чтобы завершимость можно было доказать.
По идее да. Но вообще "проблема остановки" (или в англ. источниках "halting problem") не разрешима, для машины Тьюринга (а значит алгоритма) нельзя сказать, остановится она или нет.
Т.е. если вы для прог любых можете доказать завершимость, то в теории вы в не Тьюринг-полном языке. Весь вопрос в том, насколько нужна Тьюринг-полнота и полная мощность, даваемая МТ
Неразрешимость проблемы остановки означает, что существует программы, для которых невозможно доказать остановятся они или нет. Для всех остальных программ это доказать можно.То есть написать доказанно останавливающуюся (или не останавливающуюся) программу можно и на Тьюринг-полном языке. Но для этого сначала нужно написать конструктивное доказательство существования решения проблемы, и по этому доказательству построить программу. Такая программа существует согласно cоответствию Карри — Ховарда.
Да, существуют Тьюринг-неполные языки, в которых любая компилирующаяся программа останавливается, но для написания доказанно-останавливающихся программ они не обязательны.
Проблема возникает только если мы пишем программу, а потом пытаемся доказать, что она останавливается. В общем случае это невозможно. Но всегда можно эту программу подкорректировать так, чтобы она решала нужную задачу и доказуемо останавливалась.
Если этого сделать нельзя, значит не существует такого доказательства для нашей задачи. То есть задача просто неразрешима и написать программу для её решения невозможно. В этом случае переформулируют задачу.
TL;DR Проблема остановки особого практического значения не имеет.
> TL;DR Проблема остановки особого практического значения не имеет.Точнее практическое значение в том, что серебрянной пули не существует. Или пишем доказательства, или используем Тьюринг-неполные языки, или, как обычно делается, пишем программы, которые вроде бы интиутивно должны работать и, в общем, работают, но неизвестно не сломаются-ли в какой-то ситуации.
Раст в этом плане даёт возможность писать большую часть программы так, что она доказанно обладает определёнными свойствами (отсутствие memory corruption). И доказательства (или интуитивная уверенность) требуются только для того, что unsafe части не нарушают инвариантов safe части.То есть примерно то же, что и для языков с GC, но без GC.
Введение unsafe позволяет разделить программу на Rust на два куска:
- огромный, как правило, медленный, но safe.
- маленький hotpath, но unsafeВ результате, особо тщательно проверять и тестировать нужно только маленький, unsafe кусок. Это сильно увеличивает производительность.
>> TL;DR Проблема остановки особого практического значения не имеет.
> Точнее практическое значение в том, что серебрянной пули не существует. Или пишем
> доказательства, или используем Тьюринг-неполные языки, или, как обычно делается, пишем
> программы, которые вроде бы интиутивно должны работать и, в общем, работают,
> но неизвестно не сломаются-ли в какой-то ситуации.Коллективное бессознательное опеннета искренне верит в интуицию опытного программиста. Философия уровня боевиков про кунг-фу: достаточно натренированный мастер может хером своим отбить удар хоть закалённого меча, хоть кузнечного молота. А если не может, значит мало тренировался.
если у системщика нет интуиции - хана системе, хоть на каком япе... там очень много мест где можно дров наломать и никакой яп от этого не спасет, скорее создаст соблазн нанять дешевых вебобезьян в надежде что с мегаязыком будет беопасно даже с ними - а чуда как обычно не произойдет, вон в соседней новости друпал которому лет уж сколько и буферов нет RCE радует
> если у системщика нет интуиции - хана системе, хоть на каком япе...Ну да, ну да. Спасибо за наглядную демонстрацию содержимого коллективного бессознательного.
А вообще была как-то статья, что завершимость алгоритма Евклида доказывается в агде, вроде бы, с некоторыми костылями
> Поэтому программу меняют так, чтобы завершимость можно было доказать.Хочу отметить, что любая корректная GUI программа может выполняться вечно. :-)
Формально да. На практике GUI-программа обычно и в самом простом случае представляет из себя мейн луп и обработчики (кнопок, полей, ещё чего-то). И эти все обработчики должно завершаться (и желательно довольно быстро)
Он скорее чересчур разросшийся уже.
Для бэкенда веб-сервисов пойдет, а для программ консольных, графических, загрузчиков и своих операционных систем я бы взял язык Zig.
Андрей перелогинтьтесь =)
Можно конкретнее пожалуйста? С упором на плюсы Zig
C удовольствием!
- zig имеет си-подобный синтаксис, намного проще его читать чем Rust
- модули у Zig - это просто файлы, берешь такой и const mything = @import("./relpath.zig");
- ленивая компиляция - компилятор пытается разобраться только в том, что реально используется в коде main либо в том, что экспортируется библиотекой
- обработка ошибок... Вы когда-нибудь программировали на Rust свою библиотеку? Вас бесила необходимость при любой обработке ошибок руками самому писать тип ошибок? В Zig есть интересный тип ошибки, который генерируется компилятором. Ты проходишься по нему через классический switch и компилятор гарантирует, что все возможные типы ошибок обработаны. Либо можно ошибку пробросить дальше с помощью оператора try! . Еще раз, для всего вышеописанного не придется написать ни одного класса и ни одной специальной структуры для ошибок
- dead code elimination - вот в Расте оно работает через оптимизации и компилятор медленно думает, а у Zig из-за ленивой компиляции ненужное даже не входит в процесс компиляции
- Вместе с компилятором zig в комплекте идут исходники libc для множества платформ, например есть mingw, glibc нескольких версий, для других архитектур всякая всячина. В случае с Rust нужно отдельно через rustup качать бинарные тулчейны с сайта мозиллы, если туда еще будет доступ. Нельзя доверять чужим бинарникам, особенно когда не дают инструкций как их собрать.
- Свои аллокаторы можно определять. Вообще язык с ручной работой с памятью, поэтому такие штуки как wasi, wasm писать на Zig одно удовольствие (да, биндинги на js приходится писать ручками, но оптимизация-то гарантированно на нашей стороне)
- В zig есть система сборки, которая умеет искать зависимости через pkg-config и... Было там майкрософтовское поделие такое, с телеметрией... vcpkg! точно.
- Вместо макросов в zig используются compile-time выражения на таком же языке, как и выражения в рантайме, что делает код читаемым! Для сравнения почитайте стандартную библиотеку Zig и например пакет serde/serde_json. Или стандартную библиотеку Раста.
- в Zig нет unsafe, потому что zig не лицемерит. Системный язык не может быть не-unsafe. Поэтому можно писать что угодно, а не безопасные обертки над unsafe, как это приходится делать в случае с Rust. Для примера попробуйте написать двусвязный список без использования стандартных примитивов-контейнеров Vector и List в Rust. Это больно. На Zig я написал двусвязный список строк динамического размера для своего небольшого проекта на webassembly за полчаса, и он работает на любых платформах и как и все остальное в Zig аллокатор передается туда как аргумент, то есть можно взять любой аллокатор без изменения кода
- для zig любители уже написали тулчейны чтобы программировать homebrew игры для psp и gameboy (Zig-PSP и ZigGBA)
- если вам мало, просто возьмите и попробуйте язык, в конце концов надо определять нужность вещи практикой работы с ней, а не баззвордами типа "безопасный язык"
Забыл упомянуть, что у Zig намного лучше взаимодействие с си, что через ffi, что через импорт си-файлов напрямую, ну и конечно на Zig можно писать нормальные динамические библиотеки, которыми можно УДОБНО пользоваться из си, из Rust и из любых других языков, что умеют в ffi, а еще что Zig умеет компилировать си. Если бы у вас получилось в ваших сишных зависимостях переписать скрипт сборки чтобы он использовал `zig cc`, возможно с аргументом -target, то можно было бы обойтись вообще без компилятора си в системе.
> zig имеет си-подобный синтаксис, намного проще его читать чем RustО да, такое же уныло г:
> pub fn main() void {
Первое что там написано : в зависимостях llvm и gcc/clang. Собственно, если у меня уже есть gcc или clang да еще и llvm для которой нужна полноценная ос и окружение - на какой черт мне эти все зиги фиги с растами всместе взятыми ? Дырень головного мозга какая-то и массовый психоз. Не решают эти хрусты с зигами ровно ни единой проблемы, а лишь создают их. И авторы у них безмозглые и недальновидные идиоты.
>> bootstrap-zig
>> Stage 1: Build Zig from C++ Source Code
>> gcc >= 5.0.0 or clang >= 3.6.0
>> Stage 2: Build Self-Hosted Zig from Zig Source Code
> Первое что там написано : в зависимостях llvm и gcc/clang. Собственно, если у меня уже есть gcc или clang да еще и llvm для которой нужна полноценная ос и окружение - на какой черт мне эти все зиги фиги с растами всместе взятыми ?Вам? Вам оно действительно ни к чему. Ни то, ни другое.
> И авторы у них безмозглые и недальновидные идиоты.
> или clang да еще и llvm для которой нужна полноценная ос и окружениеА ведь так дышал, так дышал! (с)
" реально используется в коде main либо в том, что экспортируется библиотекой "
и как это живет например с обработчиком прерывания, который вызывается "непонятно почему" сам по себе, железом? или с неочевидными механизмами типа call tables и динамического импорта из .so?" dead code elimination - "
он случайно обработчик irq не выпилит в чем-нибудь сиситемном? потому что main и все остальные его нигде не вызывают, это железо делает!" Вместе с компилятором zig в комплекте идут исходники libc для множества платформ "
если речь про бутлоадеры и проч - а без этого libc можно? или куда он будет в бутлоадере вызовы делать, вообще?" в Zig нет unsafe, потому что zig не лицемерит. Системный язык не может быть не-unsafe. "
идея что системное программирование может быть safe вообще вилами по воде писана - я например неверный адрес в dma вкатил разок, и какая разница на каком яп это было сделано, яп же не знает что это число оказывается будет адресом памяти для той железяки и она танцуя от него половину памяти системы прострелит.
А ещё у нас есть группа в Телеграме. Приходите, и друзей приводите! :-)
ещё у нас есть группа в Телеграме. Приходите, и друзей приводите! :-)это не та которую экстремистской признали? :)
> программ консольныхСамый приятный опыт написания консольных утилит у меня был именно на Rust. При помощи крейта Clap и процедурных макросов весь CLI-интерфейс описывается за пару минут. GUI-крейты еще в зачаточном состоянии и пока не могут конкурировать с многолетными монстрами индустрии. Но никто не мешает юзать на расте GTK, QT или вообще Skia.
Написание консольных утилит - это создание своего решения какой-то задачи, обычно пишут новую утилиту когда альтернативного готового решения или библиотеки нету. Поэтому "опытом написания" я считаю процесс написания программы с использованием возможностей языка, а не процесс использования библиотеки вроде Clap. Каждая библиотека дает свой опыт использования, приятный или неприятный, но это не дает полного впечатления об используемом языке программирования. Писать клей для чужих библиотек скучно, попробуйте своё решение, это возвысит вас с точки зрения творчества, инженерного мышления и логики и это прекрасно!
И желательно лет через 15 когда появится реальная проблема которую нужно быстро решить в офлайн написав максимально алгоритмически эффективную программу ^_^
И как обычно повылазила толпа хейтеров, которые только и умеют helloworld'ы писать. Если вообще хоть что-то умеют...
Другого на расте и не написать, вон, Мозила за 15 лет не смогла браузер на раст переписать... Везде Си торчит.
> Другого на расте и не написать, вон, Мозила за 15 лет не
> смогла браузер на раст переписать... Везде Си торчит.даже спорить не буду, сразу видно идиота.
Я немного поспорю. А то другие же читают и верят.1. Что на Расте не написать? Конкретнее.
На Расте можно написать что угодно, хоть ОС, хоть фронт в вебе.2. Мозилла планировала переписать всё на Раст? Они сумасшедшие что ли? Боюсь представить стоимость переписывания такого проекта с одного язык на другой.
Для разумных людей это не переписывание, а постепенное вытеснение, что Мозилла и делает, когда пишет новые модули на Расте.
И не 15 лет. 15 лет назад началась разработка. Релиз 1.0 произошел 5 лет назад.
Переписать браузер на новый язык, не имея планов отстать в развитии от хрома на миллион лет?
1. Раз он такой хороший почему на нем никто ничего, из того что ты перечислил, так и не написал?2. Раз Мозилла такая последовательная зачем она выгнала и разработчиков Раста и Серво на мороз?
Растофанатик конечно не сможет ответить на эти вопросы, но мимо проходящий мог бы и задуматься.
ОС на Rust как бы есть, Redox вроде зовется
На реальном железе, за пределами тепличных условий виртуалки она даже не запускается. А в качестве ещё одной "запускалки процессов" при работе в юзерспейсе из-под unix она наxep никому не нужна. Многие ключевые компоненты заброшены, достаточно посмотреть на список мейнтейнеров.
Редокс на железе смотрит на тебя как на гавно.https://i1.wp.com/simonothen.com/wp-content/uploads/2019/11/...
Мы тут о возможностях языка или нужности конкретного человека софта?
Redox доказывает, что на Расте можно писать что угодно. А больше ничего от него и не требуется.
просто *конкретного софтаЯ уже боюсь эту клавиатуру :)
" Redox доказывает, что на Расте можно писать что угодно. "
теоретически ось можно хоть на го с питоном писать а практически, фанаты фуксии кажется с этим здорово обломались, где клоун рассказывавший несколько лет назад что она вот-вот всех победит?
Ржали всем офисом. Реактос больше ОС чем ваше редокс.
1. А что, надо бросаться и что-то писать просто потому, что это возможно?
А ничего, что написание ос - это очень дорого и очень сложно, и просто не имеет смысла, когда рыночек уже поделён? Есть смысл в учебных ОС, но не более того.А если не ос, а что-то более прикладное, то использование системных языков чаще сводится к использованию тяжёлых функций, которые для скриптовых слишком. Например, Deno - нода на Расте от автора ноды. Rust в Discord. Много таких примеров.
Ждать много проектов на чистом Расте не имеет смысла, это вряд ли когда-нибудь случится и слава яйцам.
Исключая системные случаи, писать в 2021 только на Расте или только С - шиза.2. Ну тут просто. Два фактора: самой мозилле немного дурно и раст уже вырос из мозиллы. Девы Хруста сами говорили, что фонд им выгоднее с юридической точки зрения.
Серво же выполнил свою миссию и позволил Firerox значительно ускориться за счёт использования его наработок.
А доводить новый движок до ума не лучше, чем писать новую ос. Ты ещё скажи, что Firerox надо было за 5 лет целиком переписать на Раст :)
Целиком на Rust шиза? А как тогда не целиком, по-нормальному, не совсем понял?
> 1. А что, надо бросаться и что-то писать просто потому, что это возможно?Это зависит от.
Когда что-то переписывают на расте, налетают местные комментаторы с криками "зачем переписывать на недоязычке, когда это уже есть! Ненужна! Фу, растоманы, что с них взять!"
Когда не переписывают, местные могут с чувством превосходства и собственной важности писать "А почему не написали на расте! Не смогли на этом недоязычке?! Растоманы, что с них взять!"В общем, win-win ситуация.
По моему C++ самый лучший язык на сегодняшний день. Раст тож неплох, но синтаксис страшный :(
А можно конкретнее, что в синтаксисе Раста страшного?
И самое главное: сколько времени ты вложил в изучение Раста, чтоб поставить какое-то мнение? Ты ведь не код мельком глянул несколько раз, правда же?Меня вот, как C++ dev, C++20 очень мотивирует переходить на Rust :)
Особенно некоторые новые языковые конструкции и невозможность использовать во всех основных компиляторах в 2020 модули/некоторые другие фичи из стандарта 2020 года.
> А можно конкретнее, что в синтаксисе Раста страшного?хотя-бы то что наплодили кучу субдиалектов - и в отличие от плюсовиков даже не документировали это нормально. и закооючек добавили еще больше, ну куда, их в сях то многовато было, плюсовики усугубили, растовики догнали и перегнали, не забыв сделать то же что плюсовики с подвидами синтаксиса, только не утруждая себя стандартизацией и документацией особо
Какие ещё диалекты? Чувак, это был не табак.
Лучший, если уж на то пошло, SML (хотя и он не лишен недостатков).
С++ на звание лучшего никак не тянет, тогда уж С.
SML - это, конечно, прекрасно, но вот отсутствие стандартизированной системы модулей убивает весь кайф, особенно без вменяемой системы сборки и зависимостей вроде Cargo. Опять же, 2020 год на дворе, а UTF-8 всё ещё не завезли, и в целом стандартная библиотека скудновата. Короче, язык сильно нуждается в допиливании, после которого он будет почти идеален. Впрочем, оттуда почти всё удобное завезли в Rust (кроме GC и функторов), так что уже, в общем-то, и не нужно.
> без вменяемой системы сборкиhttps://www.smlnj.org/doc/CM/index.html
> UTF-8 всё ещё не завезли
https://www.smlnj.org/doc/smlnj-lib/Util/str-UTF8.html
> стандартизированной системы модулей
https://ru.wikipedia.org/wiki/%D0%AF%D0%...
> в целом стандартная библиотека скудновата
https://www.smlnj.org/doc/smlnj-lib/index.html
https://smlfamily.github.io/Basis/index.html> не нужно
Кому как. Ничего не имею против Раста, но вот он мне как раз не нужен, в отличие от SML.
Я не про те модули, не путай красное с тяжёлым. Что до SML "по версии" SMLNJ, ну, я рад за них. А можно эти плюшки завезти во все реализации - через стандарт, например? Язык-то хороший, я же ничего не говорю, но не без изъянов, как и его инфраструктура. Порядка не хватает, отсюда и непопулярность. Хотя, есть же C++... Короче, ты понял, о чём я.
> Я не про те модули, не путай красное с тяжёлымПро аналог Cargo? Ну нет такого, да. Либо я пока о его существовании не знаю.
> А можно эти плюшки завезти во все реализации - через стандарт, например?
В MLton все это тоже вроде есть. Как минимум юникод. И бинарник он компилит вроде как без лишних телодвижений (утверждать не берусь, т.к. пока с SML/NJ работаю).
А стандарт у SML один - The Definition. Единственный нормальный стандарт из мной виденных. У Раста, кстати, пока вообще никакого стандарта нет. Точнее, он определяется единственной реализацией.> Хотя, есть же C++...
Фу-фу-фу, его точно не надо.
> Порядка не хватает, отсюда и непопулярность
Скорее, тут в целом непопулярность ФП. У Лиспа вон все вышеуказанное есть, однако ж тоже малопопулярен. Erlang - то же самое. Народу гораздо привычнее сношать мозг кучей паттернов и антипаттернов ООП, и с умным видом цитировать банду четырех.
Порядка в SML как раз побольше, чем у остальных.
А есть еще вот такая штука: http://cml.cs.uchicago.edu/. Пока не пробовал, но выглядит интересно.
Ну вот я про то, что юникод, модули в смысле Rust (они и без Cargo работают, кстати), систему сборки и т.п. лучше бы включить в стандарт. А заодно бы ad-hoc polymorphism завезти, а то стыдно как-то в 2020 году использовать разные операторы сложения для int и float. Насчёт ФП не согласен. У SML и с императивщиной всё прекрасно, в отличие от того же Haskell, так что дело явно не в ФП. Про ООП и паттерны полностью согласен. Вообще, такое впечатление, будто основная разработка ведётся профессиональными мазохистами-писькомерами. Типа, чем дольше по колючей проволоке можешь проползти голый, тем ты круче - особенно, если ползёшь agile'ово. Ну, тут всё как в жизни: где невидимая рука рынка смажет, там и будут роиться.
> А заодно бы ad-hoc polymorphism завезти, а то
> стыдно как-то в 2020 году использовать разные операторы сложения для int
> и float.Ну уж что что, а полиморфизм в ML есть из коробки (система типов ХМ же):
- fun f x y = (x, y);
val f = fn : 'a -> 'b -> 'a * 'bи хоть ты int туда передавай, хоть real - все одно.
Кстати, я очень удивился, когда увидел type variable. До ML я познакомился с Rust и теперь постоянно смотрю: а что же в Rust взяли из ML. Обозначение 'a, например, взяли, но поменяли семантику: теперь это не type variable, а life time. Оператор match - это один в один case из ML и т.д.
Чего не хватает Расту, так это формального определения и доказанной корректности. Хотя систему типов уже вроде верифицировали и RustBelt чего-то там ковыряют дальше. Доковыряли бы до конца - цены б Расту не было, идея с ownership мне прям очень нравится.А вот в модном нынче Go, например, полиморфизма как раз нет - надо определять вагон и маленькую тележку функций для каждого возможного типа параметров. Или писать одну функцию, принимающую interface{}, а в ней - длиннющий type case. Ну не костыль ли, а?
Кстати, есть ещё MLKit с region-based memory management:
https://github.com/melsman/mlkitЗанятная фича.
> Кстати, есть ещё MLKit с region-based memory management:
> https://github.com/melsman/mlkit
> Занятная фича.Ага. Но мне сейчас нужны для работы SML/NJ и CakeML.
> Автоматическое управление памятью в Rust избавляет разработчика от ошибок при манипулировании указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п.В моей системе нет ни одной программы на rust, go, fpc, ..
А как проги на rust работают на ядрах Linux+PAX ?
Давай для начала просто перечислим программы для Линукс, из сколько-нибудь популярных репозиториев, где применяется Раст. Так я начал Firefox ой похоже всё.
Gnome разве что, но это буквально одна либа. Да и в фф вроде далеко не основное место занимает. Всё что было на расте в фф всегда было глючным мусором, никак у них не выходит ничего. Пусть остаётся в плоскости веб фреймворков.
> Давай для начала простоДля начала надо разобраться как прога rust будкт работать на ядрах OS и процессорах которые жестко следят за обращением к области памяти после её освобождения, разыменованием нулевых указателей, выходом за границы буфера и т.п.
Гтк зависит от либы написанной на расте. На паскале та игрушечка клон червей, на хаскеле… Какой-то вм был на хаскеле, не существует ни одной востребованной программы на хаскеле. На го сейчас много утилит которые в норме должны были быть написаны на питоне, я тже не использую, но кому-то вроде нравится.
> Какой-то вм был на хаскеле, не существует ни одной востребованной программы на хаскеле.pandoc
Да, точно. Не видел, не понравились зависимости. Не могу сказать, где используется.
А как у них с инклюзивной терминологией?
изыди!
В следующем двух недельном скрам спринте (версия 1.4.9) отполируют терминологию, если что.
" В следующем двух недельном скрам спринте (версия 1.4.9) отполируют терминологию, если что. "
а разве не пора переходить нна этот, как его, кан-банан?!
Нет указателей - нет проблем с указателями!
И начинают забивать шурупы картонными коробками...
Очки протри, эксперт.
https://doc.rust-lang.org/1.30.0/book/first-edition/raw-poin...Всё есть, просто нужно уметь читать. Хотя, зачем тебе-то? Ни дай баг ещё поумнеешь и перестанешь петросянить.
А он (rust) случайно не на C написан ? А на каком снандарте 2017 или посвежее ?
Надеюсь, что на C89
Rust написан на Rust'е. Для бутстрапа можно использовать OCaml (ооочень долго придётся собирать последнюю версию) или C и C++ (с помощью mrustc).
Частично даже C++20.
Поначалу Раст писали на Окамле, потом Раст пишут на Расте. Си плюс-плюсник не пишет компилятор Раста, Си плюс-плюсник переходит на Раст.Чистый Си совершенен как алмаз с чистого Си никто не переходит на Раст. Потому-что чистосишник познал совершенность структурного кода.
Ничего (вроде) не имею против раста. Просто песня хорошая :) https://www.youtube.com/watch?v=1S1fISh-pag
https://www.youtube.com/watch?v=p7vVOheKoTM
Плюсую за НТР
Классика!!
>Си плюс-плюсник переходит на Раст.Ага, щаззз.
раст это всего лишь фронтенд для С++ компилятора
так зачем плодить сущности ? пишите сразу на С++
>раст это всего лишь фронтенд для С++ компилятораLLVM писан на Си плюс-плюс?
Бэкенд - LLVM, фронтенд - Rust?
Вот народ ругается что rust - это всего лишь по большей части фикция и глобальных проблем не решает. Так чтобы в этом разобраться необходимо отлично разбираться в low-level программировании вообще. Стоит ли вместо С,С++ учить Rust? Именно вместо. Или лучше ограничиться связкой Nix,Python + C,C++?
Или.
Или.
По мне стоит изучить всё. Rust появился как ответ на проблемы Си и плюсов, потому хорошо бы на них до этого тоже пописать, чтобы иметь представление
Проблемы в головах, а не в языке.
Учить всё отличный способ не знать ничего обо всем.
Какой-нить ассемблер (на общем уровне) и С на хорошем уровне должны знать все программисты. Это дает хорошее понимание работы ЯП на нижнем уровне и соответствующие проблемы. Остальные языки программирования изучать и использовать по желанию.
> Какой-нить ассемблерИ обязательно заставлять на асме написать ООП-прогу со всякими полиморфизмами и виртуальностями, чтобы не подхватить в будущем ООП головного мозга.
> И обязательно заставлять на асме написать ООП-прогу со всякими полиморфизмами и виртуальностями, чтобы не подхватить в будущем ООП головного мозга.Сказала обезьянка занимающаяся вебнёй
Обезьяна знающая ассемблер точно такая же обезьяна. Хотя она квантовую физику выучит она все равно будет обезъяной.
> Учить всё отличный способ не знать ничего обо всем.Лучше и не скажешь !
Вот скажи, ты адекватен? :) Нашёл, у кого спрашивать мнения - у кучки петросянов, оголтелых фанатиков, консерваторов эпохи палеозоя и прочих отбросов программистского общества. Изучай, что интересно тебе, и делай собственные выводы. А здесь тебе только в уши нассут, что ничего лучше сишки нет, и сегфолты только у лохов, а у настоящих профессионалов, которых можно пересчитать по пальцам одной руки токаря, бабочки летают да птички поют.
зачем издеваться над трупом? даже мозилла уже от него отказалась
Т.е. опенсорс для вас = труп? Разработка сообществом, все дела?
Надо же его сдать куда-нибудь для опытов.
В фонд Apache. Да и они возьмут ли? Они Жабку любят.
Потому что он на порядкок по возможностяи превосходит C.
Поэтому что наконец основали независимый фонд, а подданство мозиллы.
Потому что много крупных компаний и корпораций в нем заинтересованы.
Мне продолжать?
> Мне продолжать?Да, конечно, продолжай рассказывать, почему Мозила за 15 лет не смогла написать на расте бравзер.
Потому что Раст хуже C и С++Раст просто мозилловский DSL не нужный даже самой мозилле.
> Потому что Раст хуже C и С++По поводу C++ можно еще поспорить, язык развивается семимильными шагами, пускай и имеет проблемы из-за необходимости совместимости
Но C? Он же как смс в сравнении с мессенджером, максимально дубовый, минимум возможностей
это как васап и однокласники, время кто-то валит видео, смайлики и нотификации, батарея дохнет за полдня, зато не смс...
Это у Си-то минимум возможностей? Ну насмешили.
мозила загибается и уже уволила разработчиков кансервы и прочих
Тут так часто упоминают этот тупняк как аргумент, что не вижу смысла поддаваться на троллинг
Особенно смешно "15 лет"
разработчикам наверное не смешно - их таки уволили куда им и дорога
>Мне продолжать?Конечно, продолжай рассказывать, как космические корабли бороздят просторы Большого театра.
И какие несуществующие проблемы решены в этот раз?
> В модулях синтаксически разрешено использование ключевого слова unsafeПохоже, они проблемы рожают, а не решают.
Использовал unsafe - ССЗБ, но хотя бы пометил другим людям возможное веселье
> хотя бы пометилты же понимаешь, что когда в сырцах миллионы строк, никто не сможет прочитать, где там унсейв...
Компилятор сможет. А ты - нет.
find . -type f -name *rs -exec grep unsafe -Hn {} \;
То же самое, что сказать, найди все голые указатели в Си, и будет тебе счастье.
> То же самое, что сказать, найди все голые указатели в Си, и
> будет тебе счастье.Как ты будешь их искать? У тебя есть хороший регексп для детекта использования указателей в C? Всё что мне приходит в голову простого будет путать умножение, декларации типов, декларации переменных и собственно разадресации.
решения называются статическим анализаторома чего в растовском коде можно регэкспом найти - вообще загадка, его перетряхивают в каждой версии - так что с статическим анализом или альтернативными реализациями не богато
> решения называются статическим анализаторомОга. А в расте встроенный статический анализатор, который ещё позволяет размечать код, оставляя там подсказки этому анализатору.
> а чего в растовском коде можно регэкспом найти - вообще загадка, его
> перетряхивают в каждой версии - так что с статическим анализом или
> альтернативными реализациями не богатоОга-ога. С каждой версией меняют написание ключевого слова unsafe. Да. Точно. Как же я мог забыть об этом.
" А в расте встроенный статический анализатор, который ещё позволяет размечать код, оставляя там подсказки этому анализатору. "
это хорошо но сомнительно что он реально сможет ловить все косяки столь сложного синтаксиса который постоянно меняют, и вообще, сишникам и тем более плюсовикам на осознание типовых проблем потребовалось много лет, а тут - бац и в дамки? а такое бывает вообще? или это маркетинг?"Ога-ога. С каждой версией меняют написание ключевого слова unsafe. Да. Точно. Как же я мог забыть об этом."
будет где-нибудь в редоксе каком-нибудь 10 000 хитов этого слова, и дальше чего? а, ну мы же умные, ассемблер возьмем и анализер перестанет матюкаться.
> " А в расте встроенный статический анализатор, который ещё позволяет размечать код,
> оставляя там подсказки этому анализатору. "
> это хорошо но сомнительно что он реально сможет ловить все косяки столь
> сложного синтаксиса1. Это не C, это раст. В расте нет необходимости ловить косяки синтаксиса.
2. Синтаксический анализатор растра встроен в компилятор, проблем с пониманием нового синтаксиса не возникает.> сишникам и тем более плюсовикам на осознание типовых проблем потребовалось много лет, а тут - бац и в дамки?
Да, естественно. Раст разрабатывался с оглядкой на все те типовые проблемы, которые сишники и плюсовики осознавали десятилетиями.
> "Ога-ога. С каждой версией меняют написание ключевого слова unsafe. Да. Точно. Как
> же я мог забыть об этом."
> будет где-нибудь в редоксе каком-нибудь 10 000 хитов этого слова, и дальше
> чего?А это смотря что тебе нужно. Зачем тебе приспичило искать эти unsafe'ы? Чтобы аудит кода проводить? Ну вот бери и проводи. там ~700 unsafe'ов на ~30k строк кода ядра. Вот бери каждый модуль в котором есть unsafe, и проверяй, что unsafe'ы в этом модуле либо не позволяют нарушать инварианты, либо экспортируются как unsafe. Раст -- это не волшебная палочка, которая позволит тебе проводить аудит взмахом этой палочкой. Он может помочь, указав тебе на те ~700 мест, которым следует уделить особое внимание.
> Да, естественно. Раст разрабатывался с оглядкой на все те типовые проблемы, которые сишники и плюсовики осознавали десятилетиями.Тем не менее они осознали и решили. А растоманы похоже нет. И врятли смогут.
> Тем не менее они осознали и решили.Осознали. Но не решили. Решить проблемы языка можно лишь меняя язык. Но менять C нельзя, потому что это кощунство и ересь. C++ менять можно, но лишь накидывая в него всё больше и больше всякой хрени. Выкидывать нельзя ничего. Таким способом проблемы невозможно решить, и C с C++ -- подтверждения тому.
>Использовал unsafe - ССЗБ, но хотя бы пометил другим людям возможное весельеКоты тоже метить умеют.
Убожество. Vlang хоть меньше по весу если так уж хочется у6людочного синтаксиса.
> Убожество. Vlang хоть меньше по весу если так уж хочется у6людочного синтаксиса.Люди придумывают какие-то нелепые поделки только ради того, чтобы не писать на убогом С.
> чтобы не писать на убогом С...не смогли осилить даже С.
" Для размещения библиотек поддерживается репозиторий crates.io. "какой ассортимент! скоро его уже майкрософт купит в дополнение к гитхабу?
Если из новости в новость копипастятся целых 2 параграфа это вроде и не новость уже. Не?
Растишки любят повторять "халва, халва..."
тут на расте учат операционки писать. https://os.phil-opp.com/А неверующие пусть продолжают пукать мозгом.
Тут Мозила не смогла за 15 лет браузер на расте написать... А ты про операционки...
За 150 лет не смогла.
Блог о написании хелоуворлда для x64. Не ведитесь на это, почитайте исходники апача или бзд, линукса до пятерки - вот это действително приятное чтиво. А это все ниочем и непонятно зачем и даже не интересно.
не умеешь работать - руководи. Не умеешь руководить - учи других.
AWS собирает разработчиков компилятора Rust и Tokio
https://www.theregister.com/2020/11/27/aws_hires_rust_compil.../"""Rust is a critical component of our long-term strategy, and we're investing to deliver Rust engineering at Amazon scale."""
Это если тут опять начнут спрашивать "а что на вашем здрасте написано?"
