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

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

В «низкоуровневом системном программировании» нет необходимости прохода по набору данных? Окей...

Как вам такой пример:

match v {
    0...999 => println!("some 1"),
    1000...1999 => println!("some 2"),
    2000...2999 => println!("some 3"),
    _ => println!("error"),
}

И это я закрывая глаза на goto clear_data;.

Или все ваши выкрики с галёрки ограничиваются применимостью раста для микроконтроллеров? Ну тут не скажу. Возможно в чём-то Си будет привычней.

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

А на микроконтроллерах он нужен ровно один раз при старте программы, и там уж точно не надо делать filter и map.

В таких случаях будет просто

static const some_struct_t table[TABLE_SZ] = 
{
    //XMACRO USED HERE
};
/*...*/
    n = TABLE_SZ;
    while(n--)
    {
        do_something(table+n);
    }

Ну то есть для микроконтроллеров с парой КБ памяти Rust не годится. Ок. Тут спорить не буду.

Не только на микроконтроллерах.

В любых системах реального времени стараются избежать циклов где только можно.

Количество оперативной памяти тут не при чём.

Анус Аватарку ставишь?

Поговори об этом с папой и мамой.

Что вышло, не знаю, но если бы им это удалось, то Rust можно было бы попробовать использовать в имбеде (в настояжем, а не на RPi).

lol, а что сейчас мешает? Простая моргалка светодиодом на чистом rust компилируется в 950 байт на Cortex-M4 (из них 400 байт занимает таблица векторов и 400 байт функции memset memcpy из newlib).

всякие ужасы бывают, но в случае glib есть места где by-design автоматически отработать нельзя. есть вполне реальные use-case даже в такой банальной вещи как OpenGL где нельзя просто так взять и сказать где память освобождается(это например происходит в нутре проприетарного драйвера).

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

не взлетит. оно не может взлететь.

А не на ARM?

мир вокруг отличается от того гетто

Предлагаю не жить ровно одним днём и ровно одним гетто. Мир меняется каждый день, в том числе под действием новых никому ненужных технологий (на первый взгляд).

// я не написал ни одной строчки на расте на текущий момент.

использовать в имбеде (в настояжем, а не на RPi).

А не на ARM?

А что, cortex-m уже не `настоящий имбед`?

А не на ARM?

А оно надо? Вот результаты текущего опроса:

Разновидности ARM 147
AVR 132
ESP 25
Другие 20
MSP430 18
PIC 17
8051 15
STM8 10
DSP 4

AVR сейчас активно мерджат в LLVM, про ESP не знаю, MSP430 уже есть.

mem::forget вполне поможет в этом случае.

Уверены в том, что в D без GC будут такие удобства? Там ведь, как минимум, лямбды отвалятся.

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

Теоритически можно, но в плюсах ты явно описываешь capture list и правила захвата (by ref, by copy, move-init из C++14). В D этого нет на уровне синтаксиса языка, насколько я помню.

AVR - отживает свой век, будет ещё долго популярен, но уже не торт. Могли бы и не мержить.

ESP - на пути к пику популярности (IoT же!), если бы еще внешнюю флешку не надо было вешать...

MSP430 - хорошая вещь, давно есть в GCC, что касается его поддержки со стороны llvm, то: там не всё так однозначно.

PIC - легаси;

8051 - лютое легаси (хотя на них есть bluetooth от TI, ещё проживет какое-то время);

STM8 - если бы поддерживали внешнюю память, то могли бы серьёзно подвинуть Cortex-M0/+, но не судьба, если кто-то добавит в llvm и сделает ассемблер и линковщик - будет лютый вин!

DSP - постепенно вытесняются Cortex-M4/M7 из низовых ниш, очень специфические штуки, периферию которых можно изучать годами и умереть...

А вообще применение МК в продакшоне - прерогатива азиатов (кто бы мог подумать!), и там скорее лицензируют экстензу, чем арм (см. ESP).

То есть ты предпочитаешь в очередной раз съехать с темы и не готов открыто признать то, что Rust не искоренит произвольное выполнение кода на целевых системах за разумный срок?

Ладно. Слив защитан.

Как раз таки с MSP430 все очень хорошо (если не пугает отсутствие линкера, ну и не лень пересобрать llvm с моим патчем :), код который llvm генерирует чуть ли не в два раза быстрее чем тот что на выходе msp430-gcc, он даже немного обгоняет IAR (тестировал на алгоритмах из моего проекта, your mileage may vary).
msp430-gcc был бы не так плох если бы кто-нибудь пофикслил в нем этот баг, но прошло уже два года и всем пофиг. Я пытался исправить, но мне тяжело читать код gcc, особенно когда находишь там такие комменты:

I set ... and ..., but gcc puts in a ; zero_extend anyway. Catch it here.
...
Eliminate extraneous zero-extends mysteriously created by gcc.

Я знаю С++ программистов, не хисптеров, которых в вузе заставляли учить синтаксис, а реальных, со стажем 10-15 лет. Так вот, для этих разработчиков С/С++ богаподобный язык, где ты можешь все и не платишь реально ни за что.

У меня стажа, конечно, несколько поменьше, но и мнение другое. И эпитеты типа «богоподобный» встречаются как-то больше от «восторженных нубов», а так есть 100500 вещей, которые в языке раздражают. Да, к ним привыкли и на другие языки могут не смотреть, как по объективным, так и не очень причинам, но это не отменяет того, что можно лучше и удобнее.

Ну из С транслятор нужен, из плюсов ещё нужнее, потому что поддерживать свободные проекты на этих языках, кроме авторов, почти что и некому, как бы фанаты не колотили себя пяткой в грудь. А если бы ПО было на паскале то кто-нибудь залез внутрь и прикрутил недостающий функционал или пофиксил самые злые баги. И что бы ни кричали фанаты плюсов, сейчас ПО на этом языке, в среднем, жрёт кучу времени из-за вылетов с вынужденными перезагрузками, то есть фактически спонтанно тормозит. А также ловким движением мышки превращает HDD в накопитель на магнитной ленте, и потому от пользователей требуется покупа SDD чтобы плюсы не тормозили - динамическая линковка таки распухла и сожрала ништяки которые когда-то давала. Ну а страсть использовать всё системное, ничего из него не дублировать в языковых фремворках, привела к многочисленным диким багам из-за конфликта версий. Этим и С тоже страдает, потому - пусть пишут трансляторы.

Проблема как раз в том, что из Паскаля-то транслятор написать несложно. Потому что язык простой и многое не позволяет сделать. То же, кстати, относилось к Fortran77. А вот хаки C/C++ транслировать очень затруднительно: не ясно часто, где хак полезный, где глюк, а где и то и другое разом.

Как ни странно это свидетельствует в пользу выживания C/C++, т.к. код с других языков автоматически транслировать можно, а вот с них --- нет. Зато использование хаков даёт выигрыш.

Зато использование хаков даёт выигрыш.

Особенно в игровых программах где игроки треть времени тратят на вылетания и перезагрузки, ругаются но сделать ничего не могут - лобби С/С++ заставляет их жрать глюки и уверяет что это только на пользу и якобы ускоряет. Но ускорение получается странное: в одних местах летает, а в других выстрелил и повисаешь пока скоростная С++ программа при помощи этих хаков считает по всем потокам последствия выстрела, к каким квестам он относится и т.д.

Кстати, написанные на Паскале игры вроде Звёздных рейнджеров или KM-Remix отлично идут под вайном. А C/C++ всё время падают.

Но дело всё равно уже не исправить.

Это довольно узкая область. И в неё Rust не метит. Его цель убить Си на x86, ARM, etc. То есть десктоп, мобилки, сервера и тд.

И каким образом язык влияет на итоговый бинарник? Чуть не порите.

И каким образом язык влияет на итоговый бинарник? Чуть не порите.

Читай выше. ЦПП кроме стрёмных внешних либ, неизвестных в будущем версий, тянет из системы всякое г-но типа нестабильных функций из ядра ОС. ОС постоянно обновляются, мутируют, а цпп не может за всеми их функциями-мутантами уследить. А ФПЦ использует внешние каки через свои прослойки, причём в базовой комплектации таких модулей-прослоек много. И если какие-то «инновационные» функции из ОС вызывают тошноту и понос у всех ими пользующихся, то нет смысла героически запихивать их в рот - их можно: а) выкинуть из прослойки, б) собрать в отдельную какашкину прослойку для использования на свой страх и риск, в) заменить в прослойке _своими_ альтернативными реализациями, до которых ни микрософт ни сиплюсовые разработчики линуксов не дотянутся. А теперь попробуй в си или плюсах не пользоваться тем из системы, что тебе не нравится - ну очень «легко» это будет сделать в большой программе.

http://i3.kym-cdn.com/photos/images/facebook/000/852/286/9ac.jpg

Ну не знаю, для всесторонне образованного человека там всё понятно.

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

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

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

пофикслил в нем этот баг,

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

у и не лень пересобрать llvm с моим патчем :

Уважаю! А когда его смерджад в главную ветку?

тянет из системы всякое г-но типа нестабильных функций из ядра ОС

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

Молодец, признал что рукожопые пишут программы на С++, потому как не рукожопый сложный софт на этом ЯП такая редкость... Если ты умеешь писать на плюсах не рукожопые программы, то почему других программистов не обучил? Открыл бы платные курсы «как за 2 недели отучиться от рукожопия на С++» и грёб бабло лопатой.

Сколько таких недоязыков уже было...

C и C++ созданы для того, чтоб писать программы, и поэтому они востребованы, мощны и вечны.

а смешные недоязычки, созданые ололошами с полыхающими пуканами чтоб «убить С/С++» появляются, газуют в лужи и исчезают.

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

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

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

Надеюсь, что ты понимаешь, что твоё «гетто» даже меньше «гетто с выразительными языками, GC и выведением типов»?

Ну и, на всякий случай, в расте нет GC.

в моем гетто есть Qt, Gtk, гном, кде, gimp, inkskape, Webkit, Blender...

теперь похвастайся ты, что есть в расте например для Gui.

Никому не нужны хорошие программисты, их слишком дорого готовить!

Всем нужны дешевые макаки.

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

Всегда ваш, К.О.

Static linking... не - не слышал!

Зачем так жестоко. На гитхабе C++ на первом месте. По числу открытых issue на проект. Да и по количеству активных проектов неплохо - на 7-м месте.

Это не баг а фича

Ну может для разработчиков IAR это фича (чтобы показывать насколько их продукт лучше свободных аналогов), но для пользователей это баг. Эти магические zero-extend'ы, которые сами разрабы gcc не знают откуда берутся, не только увеличивают размер кода (в худшем случае на 4 байта на инструкцию) но и замедляют исполнение (в хучшем случае больше чем в два раза).

А когда его смерджад

Ну надеюсь к релизу 4.0 успеют. Хотел к 3.9 успеть, но билдсервер нашел у меня iterator invalidation и патч откатили, а когда я пофиксил, релиз 3.9 уже прошел. Сейчас жду пока aKor (мейнтейнер msp430 бэкенда) найдет время потестить последнюю ревизию.

В D этого нет на уровне синтаксиса языка, насколько я помню.

Ну да, но ведь можно выкрутиться. Так-то у них нормального указателя с подсчётом ссылок даже нет, насколько я знаю.

А вообще какой-то синтаксис можно и добавить и даже не поломать существующий код при этом. Хотя сомневаюсь, что это приоритетно для сообщества.

А если бы ПО было на паскале то кто-нибудь залез внутрь и прикрутил недостающий функционал или пофиксил самые злые баги.

Ты серьёзно думаешь, что желающих и умеющих ковыряться в паскале больше чем в С и С++? По религиозным вопросам спорить лучше не буду, но количество программистов на языках и активность в проектах хоть как-то измерить можно.

А ФПЦ использует внешние каки через свои прослойки...

Честно говоря, не понял. С++ ведь тоже не выставляет наружу «нестабильные функции из ядра» - это всё детали реализации стандартной библиотеки. И чем тогда это отличается от «прослоек»?

Речь, насколько я помню, шла о том, что на D _сейчас_ можно писать без GC. AFAIK, это будет ну совсем уже другой D, как минимум, без stdlib и без многих плюшек языка.

То, что при желании можно развернуть D в эту сторону я не спорю. Хотя и не думаю, что это кому-то из пользователей D нужно. Как по мне, так D ценен именно тем, что это «более безопасный C++, да еще и с GC», на котором можно хоть «быстрые скрипты» писать, хоть ресурсоемкие GUI-приложения. И как раз предпочтительность D здесь именно в GC. Если же GC не нужен, то от D не так уж и много пользы.

в моем гетто есть Qt, Gtk, гном, кде, gimp, inkskape, Webkit, Blender...

Давай ты хоть на секунду остановишься, задумаешь и перестанешь валить всё в кучу? То у тебя раст и ГЦ, то Qt и gimp в одной куче оказываются.

То, что на плюсах пишут, мягко говоря, не большую часть программ - это факт, с которым сложно спорить. Очень даже гетто, особенно если со всякими джавами/шарпами/джаваскриптами сравнивать. И как только ты начинаешь мериться количеством кода, ваканциями и прочим, то сразу проигрываешь. Но можешь продолжать радоваться «победе» над молодым языком не имеющем за собой поддержки сравнимой с таковой у джавы и C#.

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

Но это не значит, что «выразительные языки» или вывод типов не нужны. Особенно забавно, что последнее и в плюсах есть.

Зачем так жестоко.

Я не плюсохейтер, если что.

По числу открытых issue на проект.

Ага, а раст - на втором. И что это доказывает?

Речь, насколько я помню, шла о том, что на D _сейчас_ можно писать без GC.

Изначально я отвечал на комментарий Corrode, проект транслятора из C в Rust, получил финансирование Mozilla (комментарий)

Все же, какие предпосылки если уже есть Rust?

Со своей колокольни вижу, что D теоретически мог бы завоевать большую популярность в среде плюсовиков, если бы GC сделали «более опциональным» - для многих это религиозный вопрос. В том, что язык нужен тем, кто пишет на питоне/шарпе/джаве как-то сомневаюсь.

Активно не слежу, но слышал про идеи прикрутить аналог shared_ptr. Опять же, Александреску сравнительно недавно сравнивал своё детище как раз с C++ и растом (ну и с Go).

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

Со своей колокольни вижу, что D теоретически мог бы завоевать большую популярность в среде плюсовиков, если бы GC сделали «более опциональным» - для многих это религиозный вопрос.

Я был тем самым плюсовиком, которого D интересовал, как раз тем, что D — в свое время был «правильно сделанным C++, но с GC». Результат я подробно описывал. За прошедшее время ничего особо не изменилось. Разве что D стал стабильнее, на C++ стало программировать проще, ну и на этом пятачке стало теснее из-за релиза Rust-а.

В том, что язык нужен тем, кто пишет на питоне/шарпе/джаве как-то сомневаюсь.

Быстрая замена Python-у и Ruby нужна. Это объясняет успех того же Go, назвать который удобным я лично не могу. Тем не менее, Python на серверах успешно заменяет.

Для разработки GUI, особенно если GUI-приложение не должно тащить за собой JDK или .NET, язык D так же выглядит весьма привлекательно.

Так что ниши для хорошего нативного языка с GC, имхо, есть. Другое дело что именно D оказался редкостным долгостроем. Хорошо, что Mozilla с Rust-ом на эти грабли не наступила.