Язык программирования Rust (2 стр)

_zerg_
> т.к. вижуал ассист загибается на сколько нибудь крупных проектах.
да вроде не загибается..
>100mb C++ кода - достаточно крупный?

_zerg_
> рефакторинг - это неотъемлемая часть процесса разработки
я бы с тобой поспорил... Но опять все выльется в обсуждение ООП

_zerg_
> Extract Method, Extract Variable, Rename Method/Variable, Change Signature -
> самые ходовые рефакторинги.
поставил visual assist

_zerg_
> т.к. вижуал ассист загибается на сколько нибудь крупных проектах.
вот прикол, у мну VA не загибается и шустро работает, а эклипс сам по себе провисает через каждые пять минут - что со мною не так? :-/

Попробовал написать простую программку.

fn main(args: [str]) {
  let mut ind : uint = 0u;
  while ind < args.len() {
    io::println("hello world from '" + args[ind] + "' !");
    ind += 1;
  }
}

Кстати говоря, for в rust нету. Только while + do-while.
Для итерации по контейнерам предлагают вызывать "методы" и передавать им блок в стиле ruby.
Отгадайте, где ошибка =) 

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

Правка: for все таки есть, но он foreach.

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

ffinder
> а какие отличия ты считаешь достаточными, чтобы отказаться от плюсов?
Нормальная IDE для D. :)

ffinder
0. модули, пространства имен и контроль порядка инициализации внутри них
1. контролируемые compile-time вычисления для пользовательских типов ( то есть автоматические по желанию компайлера и явное, несмотря на его желание )
2. замена интерфейсов и классического наследования на класс-реализации, trait-ы и концепты с compile-time контрактами ( безопасности ради ).
3. расширение синтаксиса, добавка новых нотаций и семантик в язык ( см regex в perl )
4. минимизация влияния синтаксиса на рантайм производительность ( см operator[ ]  для string и map в плюсах ).
5. явное описание расположения данных в памяти ( отсутствие гарантий по умолчанию ради производительности )
6. повышение декларативности кода, встраивание семантик чистоты, ссылочной прозрачности и неизменяемости и их выведение.
7. средства compile-time проверки корректности программы на отсутствие гонок данных, невалидных указателей / итераторов / overflow / underflow ( на основе явных контрактов и инвариантов в коде )
8. отсутствие разбиения на ref/value типы при отсутствии синтаксических различий при их использовании.
9. агрессивная специализация функций и типов. Контроллируемая адаптируемость кода к многопоточному доступу без его переписывания ( по сути неявные аспекты ).
10. простая привязка библиотек на си / с++ ( без адовых шаблонов )
11. удобная ide под это.

Methos
Это всё клёво, когда троллишь на форуме, какой язык круче, а когда сидишь и делаешь ПКБ, то ничего, кроме процедурщины и СТЛ, и не надо на самом деле.

TarasB
В том посте я никого не троллил. Что еще за ПКБ?

> то ничего, кроме процедурщины и СТЛ, и не надо на самом деле.
Оно не надо, если ты никогда не ошибаешься и тебе плевать на то, сколько времени оно работает и сколько озу кушает. Или уже "понял и смирился".
Сядь-ка попиши под 100mhz пентиум с 95й виндой, чтобы оно не лагало, саппортить и фиксить не пришлось ( это не выдуманная задача ).

В каждом треде про новый фреймворк/либу/яызк есть пост "не нужен, уже есть %toolname%".
Да, процедурщины и stl достаточно для реализации всего, что хочется. Однако, все эти тулзы иногда не дают просто выразить простую идею и написать читаемый, корректный и быстрый код. Поэтому в списочке есть пункт про влияние синтаксиса на перфоманс. Более того, помощь ( в виде проверки контрактов ) не помешает и позволит не сидеть в дебагере и трейсить код хотя бы в части случаев. Профи со здоровенным опытом могут продолжить писать на том, на чем им нравится, не оглядываясь на новые технологии.

Methos
> ожидаю комменты: "в D все это есть", "да ты зажрался", "айда в фп"
хотел бы я сам "айда в фп", но языков с достаточным контролем низкоуровневых вещей нету.

Methos
> Что еще за ПКБ?

Это единственная реально 100% рабочая парадигма.

Methos
> Сядь-ка попиши под 100mhz пентиум с 95й виндой, чтобы оно не лагало, саппортить
> и фиксить не пришлось ( это не выдуманная задача ).

Ну и? Ничего кроме старой доброй процедурщины в голову не лезет для таких задач.

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

Насчёт читаемости ФП ты погорячился. На говнокоде как раз можно нынче обсирать хаскелл, в том числе и за то, что нихрена не понятно уже в 10-строчной процедуре.
Возможность расширять синтаксис, как и перегрузка оператора [] и прочите такие вещи хороша, но только когда станет очень точно ясно, для чего именно это надо, иначе это граната в руках обезьяны.

Methos
> Более того, помощь ( в виде проверки контрактов ) не помешает и позволит не
> сидеть в дебагере и трейсить код хотя бы в части случаев.

Оно всё клёво, но не получится ли, что контракты описываешь дольше, чем ты бы просидел в отладке, не используя их?

TarasB
> Возможность расширять синтаксис, как и перегрузка оператора [] и прочите такие
> вещи хороша, но только когда станет очень точно ясно, для чего именно это надо,
> иначе это граната в руках обезьяны.
Для этого как раз существует контракт, формально описывающий семантику операций и компилер, который в состоянии это проверить.

> Насчёт читаемости ФП ты погорячился.
Так я про декларативность писал, а не про ФП.

> Оно всё клёво, но не получится ли, что контракты описываешь дольше, чем ты бы
> просидел в отладке, не используя их?
Контракты для реализаций проверяются, а значит и выводятся. Думаю да, может получиться так, что без написания контрактов ручками будет быстрее, чем с дебагером. Это для случаев, когда выразить контракты сложно. Но я считаю, что контракты покажут вам больше ошибок, чем вы найдете способом, после которого полезли трассировать в дебагер.

Methos
> Для этого как раз существует контракт, формально описывающий семантику операций
> и компилер, который в состоянии это проверить.

Нет, для этого существует стандарт фирмы и самоконтроль. Абстракции - штука опасная. Когда ПКБ, то от них толку не очень много, больше улетаешь в абстракции, чем тупо идёшь к цели.

Methos
> Но я считаю, что контракты покажут вам больше ошибок, чем вы найдете способом,
> после которого полезли трассировать в дебагер.

Насчёт контрактов, которые покажут все возможные ошибки, есть язык АТС. Хватит ли тебе крепкости яиц, чтобы на нём писать?

TarasB
> Насчёт контрактов, которые покажут все возможные ошибки, есть язык АТС. Хватит
> ли тебе крепкости яиц, чтобы на нём писать?
Мы как то отошли от выводимых контрактов в императивном языке к написанным ручками в функциональном.

TarasB
> Нет, для этого существует стандарт фирмы и самоконтроль. Абстракции - штука
> опасная. Когда ПКБ, то от них толку не очень много, больше улетаешь в
> абстракции, чем тупо идёшь к цели.
А кому стандарт фирмы мешал ошибаться хоть раз?

Methos
в каком месте это похоже на хаскель?