Ну а если контрпримеров няшности крокодила - че далеко ходить-то. Успенского читал, «Чебурашку» смотрел - крокодил положительный герой, внезапно да? А еще журнал был «пра йумар». «Крокодил» называется, может слышал? :)

Не прощу, это лор и в этом треде еще не поминали Гитлера :)

Почитал я guide по расту. Без многострочных комментов не взлетит.

Без многострочных комментов не взлетит.

/* Дык
 * есть
 * же
 */

Нахер мне твой египетский Чуковский? Я из Украины. Тарас Григориевич наше всьо и он про крокодилов не писал.

В Виларибо C++ программисты пишут код для продакшена, а rust-мартышки всё еще фапают

Есть замечательная группа, из Питера. Называется „Палево“. Послушай, тебе понравится.

Из Москвы.

2 strlen
2 malloc + 2 free

Самостоятельно догадаешься, что из этого тяжелее? Не говоря уже о том, что можно хранить pascal-like строки с длиной — никто не запрещает.

Для того, чтобы вызвать malloc или free, адресная арифметика не нужна.

А вот для того, чтобы разместить все данные вручную внутри выделенной области — без этого никуда.

Если нужны (реально нужны) - нет проблем их сделать. На Rust, ага. По специальному разрешению, выдаваемому старшими.

Я вижу, как минимум, отсутствие адресной арифметики. Или она есть?

http://is.gd/krj5jO

pointer.offset всегда считает в байтах? Адресную арифметику вполне можно засчитать, хотя выглядит очень страшно.

В некоторых ЯП нет глобальных переменных, да и функций тоже нет. Одни классы с полями и методами.

pointer.offset всегда считает в байтах?

Нет. Там тип *mut u8 вот и считает в байтах.

В некоторых ЯП нет глобальных переменных, да и функций тоже нет. Одни классы с полями и методами.

И кто мешает в таких языках плодить статические переменные в классах?

А ещё есть языки, где классов нет. И?

В любом случае, это ортогонально наличию или отсутствию виртуальной машины.

Ну тогда взлетит. А в гуайде написано 2 типа комментов, // и ///.

Даже конструкция if учитывает архитектуру (хотя более обобщенно, чем разница в архитектуре между i386 и каким-нибудь ARM) (а именно то, что нельзя адресовать меньше одного байта памяти, да и проверка регистра на 0, на ASM-е за это регистр flags отвечает, а именно бит с номером 4 (с программной точки зрения, а не с физической) если считать с 0 бита в этом регистре, а такое поведение ASM-а с вероятностью в 95% базируется на том, как аппаратно проходит эта проверка (простенький вариант такой электосхемы схемы я тебе даже нарисовать могу)), именно из-за этого true и false в C не обязательны как в паскале - любое значение, отличное от 0 - true, иначе - false. В более безопасных и высокоуровневых ЯП такое поведение искусственно запрещено.

Но да ладно, это больше обобщенный пример, а вот C почему думаешь имеет столько исключений, что его стандарт (вроде выше кто-то пруф давал) тянет на 700 страниц? Да потому, что все эти исключения продиктованы разными архитектурами процессоров (по большей части i386 и x86_64), т.к. на одной архитектуре нельзя делать одно, на другой - другое, вот всё что нельзя делать везде и описывается прямо или косвенно (повлияв на архитектуру самого C) в этом талмуде.

а вот C почему думаешь имеет столько исключений, что его стандарт (вроде выше кто-то пруф давал) тянет на 700 страниц?

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

все эти исключения продиктованы разными архитектурами процессоров (по большей части i386 и x86_64)

В стандарте было ~600 страниц еще до появления x86_64. 700 страниц - это C11, в котором просто больше фич.

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

Просто для «сишных» команд людей нужно набирать опытных. Ну или совсем джуниуров на обучение(но их к важному коду не пускать). ИМХО, конечно.

Просто для «сишных» команд людей нужно набирать опытных.

Я не против, но это «обходится дороже», да и не всегда и везде таких достаточно (ну или опять мы в деньги упираемся). Опять же, если говорить о С++, то там набор фич растёт, что ещё больше увеличивает порог входа. Да и опытные люди тоже могут совершать ошибки.

Поэтому если «детские» ошибки язык не пропускает, то это здорово. Там где надо, опытные через ансейф выжмут необходимое. А джуниорам как раз можно это запретить.

Да я не спорю, что здорово. Только это другой язык. В который так же надо войти, которым так же нужно уметь пользоваться и пр. и пр. Совместимости по коду нет. Производительность и плата за рантайм пока неясны. Вот и спрашивается, стоит ли оно того...

Производительность и плата за рантайм пока неясны.

Да в принципе, ясны, если разбираться хочется.

Вот и спрашивается, стоит ли оно того...

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

Фортран, матлаб, такое впечатление, что для них чем хуже, тем лучше.

Ну на самом деле ещё APL и J, но они ужасны в другую сторону.

В этом треде не хватает Луговского

(cons 'vsl '(not dead))

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

Скорее всего, тут получится точно так же.

Скорее всего, тут получится точно так же.

Посмотрим. Пока что они многое в библиотеки выносят стараясь язык минималистичным делать. Опять же макросы какие-никакие есть. Может получится расширять внятно и не теряя совместимости.

Зачем вы разговариваете со школотой?

Няшные ли крокодилы

Простите, это тред о Rust?

Да. Не отвлекайте, пожалуйста, экспертов. Тут всем очень интересна их дискуссия.

Уродцы торжествуют чаще

Например php, ага :)

С разморозкой! :D — Почему вы так фапаете на этот Rust? (комментарий)

Переползли уже, Unity топ1 двигло, а там моно и C# внутрях, кроме того даже сюда вползли http://mono-ue.github.io/

а там моно и C# внутрях

Разве С# там не для скриптов всяких используется? Само Unity, вроде, на С++ было?

Сам движок на C++, скрипты на недоJS или C#. Но скрипты в юнити занимают огромную долю, почти все расширения на них, хотя есть возможность использовать в Pro версии обычные библиотеки: http://docs.unity3d.com/ru/current/Manual/Plugins.html
Касаемо скриптов кстати:
http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/
http://habrahabr.ru/post/224447/
Моно оказался слишком неудобным для портирования и медленным, поэтому они пилят свой транслятор из ВМ-кода в особый CPP-код, далее компилируя его как обычный C++ код.
Жаль только:

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

неудобным для портирования и медленным

Лыжи не едут - это производитель лыж виноват :) Интересно, биндя OGRE к моно в виде Axiom3D чуваки не знали, что «моно тормозит» и им нужен «особый CPP-кот»?

«Из-за AoT и ограничений LGPL мы не можем использовать Mono на iOS, что не дает нам обновить версию Mono для редактора и других платформ » (с) И еще банальностей...

«Исходные коды пока не будут открываться» (с) а то комунити начнет чего-нибудь подозревать :)

Но скрипты в юнити занимают огромную долю

Это понятно, меня сбило с толку «C# внутрях». В моём понимании это относилось как раз к внутренностям самого движка.

Про IL2CPP был не в курсе, интересно.

Я начну: Rust. Дальше?

Ada, не?

Нет.

Если никто не будет фапать — то конечно не взлетит. А так у него хоть шанс есть. От обломавшихся кукаретиков планета не взорвётся.

Так объясните, на что именно фапать. Может кто-то и присоединиться к вашей коллективной оргии одиночества.

Я ни за что не ратую. Сабж до стабилизаци синтаксиса даже рассматривать более-менее подробно не собираюсь, но по общим описаниям выглядит вкусно. Кстати, я вижу его скорее как конкурент C.

Сабж до стабилизаци синтаксиса даже рассматривать более-менее подробно не собираюсь

В пятницу 1.0.0-alpha выходит уже.

http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

Хорошо, гляну.

а в какой версии они синтаксис заморозят?

а в какой версии они синтаксис заморозят?

А в какой версии C++ заморозили синтаксис?

Одно дело не ломать обратную совместимость с тоннами существующего кода, другое — носить математические функции из пакета в пакет так, что то, что компилится в 0.12, не компилится в транке.

а в какой версии они синтаксис заморозят?

Постепенно все должны заморозить: весь синтаксис, что будет поддерживаться стабильной веткой должен быть обратно совместим. Кое что, чего еще могут поменять, убрали под feature gate`ы.

http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

ха, int убрали, ура

Кстати, здорово, что к 1.0 успели переименовать тупой 'int/uint' в 'isize/usize'. Может, не самые лучшие названия, но лучше уже так, чем оставлять в языке 'int'.

https://github.com/rust-lang/rust/commit/7deb9abd1b

$ rustc --version
rustc 1.0.0-nightly (44a287e6e 2015-01-08 17:03:40 -0800)

...

src/num.rs:153:18: 153:21 warning: the `int` type is deprecated; use `isize` or a fixed-sized integer
src/num.rs:153 impl BaseInt for int {}
                                ^~~
src/num.rs:153:18: 153:21 help: add #![feature(int_uint)] to the crate attributes to silence this warning
src/num.rs:153 impl BaseInt for int {}
                                ^~~

upd: вот PR: https://github.com/rust-lang/rust/pull/20754

Что за наркомания?

к 1.0 успели переименовать тупой 'int/uint' в 'isize/usize'. Может, не самые лучшие названия, но лучше уже так, чем оставлять в языке 'int'.

Зачем? Что не так с int?

Что за наркомания?

Да я тоже не понимаю, почему так долго с этим тянули, давно бы уже сделали, а не прямо перед бета версией. Лучше поздно, чем никогда, но, блин, логи ошибок в travis-ci во всех проектах километровые сейчас.

До сегодняшнего дня было как? Типом по-умолчанию был int, но во всех руководствах говорили, что если тебе плевать на размер, то используй i32, а не int. Это странно и криво.

Народные массы, взрощенные на плюсах, тупят и используют int как тип по-умолчанию для хранения целых чисел. А, по идее, он нужен только для хранения чего-то, связанного с памятью/индексами массивов и т.п. - чего-то реально завязанного на размер машинного слова.

Не так с этим, как минимум, то, что он ведет себя по разному на разных платформах.

Был миллиард и один срачепост на тему, чего делать с int. Это второй по масштабу срач после мутпокалипсиса). Вот одно из последних обсуждений: http://discuss.rust-lang.org/t/restarting-the-int-uint-discussion/

По идее, с первого стандарта, т.е. с 98 года