но не вижу причин почему бы раст так не смог.

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

Кстати вспомнил, что мне в Rust не понравилось. Чтобы использовать методы из реализованного интерфейса, его (интерфейс) нужно заимпортить. Может просто непривычно, но всё равно не нравится. Хотя проблему решают локальные импорты внутри функции, но всё равно некрасиво смотрится.

Например, CVE-2015-0488

A specially crafted certificate could cause JSSE to raise an exception

получить эксепшн в джаве - это несомненно очень опасно.

просто оставлю это здесь

Evaluation of performance and productivity metrics of potential programming languages in the HPC environment

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

это не баг, это фича. иначе будут проблемы, вплоть до конфликтов имён.

Ну перенеси мне на этап компиляции следующую проверку

Тут должна быть(в идеале) ошибка компиляции. Компилятор должен заставить программиста доказать, что индекс соответствует, например так:

if (index < v.size()) {
    v[index]; // ok
}

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

И это вполне под силу системе на основе зависимых типов.

Да, но будет ли удобно на таком языке писать? Раст - это всё-таки компромисс между безопасностью и сложностью. Потенциально ему ничто не мешает быть (сильно) медленнее С++, при этом гарантий больше. Уже неплохой результат.

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

На счёт удобства. Во время использования должно быть примерно так же. Вот на границе модулей, при описании интерфейсов(в широком смысле слова), да, придётся что-то писать более подробно. Но по факту, это будет то, что сейчас пишут в документации... Но над юзабильностью так же надо думать при проектировании языка, да.

это не баг, это фича. иначе будут проблемы, вплоть до конфликтов имён.

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

пускай тогда и требует импорт, а пока проблем нет, пусть сам ищет

а потом будет еще пять разных ситуаций и все их нужно будет обрабатывать по особенному?

Какие ещё пять ситуаций? Я говорю про эту ситуацию.

А тебе говорят, что подобных ситуаций в языке может быть(и будет) много, так что если ты начнешь вводить всякие сложные правила, то получишь C++.

то получишь C++

скорее, perl

Нет, нет, нет. Не надо вводить лишнюю зависимость от контекста в язык.

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

Ну это тебе. А если посмотреть шире, то Coq мейнстримом не стал и даже «более простой» хаскель тоже не так уж популярен. Раст от мейнстрима меньше отличается, это тоже преимущество.

Если я правильно понял того анона, он как раз имеет в виду «обычный» императивный язык(причем с рантаймом по тяжести равного Сишному), в котором реализованы вот такие вот развитые проверки. По-моему идея хорошая, но работы много и вряд ли мы такое увидим ближайшее время.

Спасибо, интересно.

TL;DR: C больше не король HPC, Go и Rust его победили по всем параметрам. Rust победил немного больше.

По-моему идея хорошая, но работы много и вряд ли мы такое увидим ближайшее время.

По моему, тоже. Вот только я не согласен с выводом, что «промежуточные», между таким «максимально продвинутым» языком и текущими мейнстримовыми, языки не нужны.

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

Кстати, аноним ещё и про шаренные данные говорил. Так вот раст уже с этим вполне успешно справляется - на обьект одновременно может быть только одна мутабельная ссылка или много, но иммутабельных.

В расте приняты корявые решения в синтаксисе. Шаблоны плюсовые тоже не подарок. Но не смотря на многословность, они читаются лучше rust'овских дженериков. И возможности потенциально имеют бОльшие(если концепты будут).

Ну и лайфтаймы. При этом язык тут и с перлом сравнивали и с С++. Так вот - не представляю как можно реализовать все хотелки про зависимые типы и оставить язык простым.

Думаю, это возможно, просто нужны исследования. Вопросы синтаксиса должны быть проще семантики.

на обьект одновременно может быть только одна мутабельная ссылка или много, но иммутабельных

А что плохого в ссылке на мутабельные данные, если они lock/wait -free или защищены какими-то блокировками?

Там не очень уж качественный код на си.

В расте приняты корявые решения в синтаксисе. Шаблоны плюсовые тоже не подарок. Но не смотря на многословность, они читаются лучше rust'овских дженериков. И возможности потенциально имеют бОльшие(если концепты будут).

Тут со всеми тремя пунктами не согласен. Давай лучше на примерах. Что в расте сделано коряво и как сделал бы ты? Аналогично с плюсовыми теплейтами, которые лучше растовых читаются, только чур с учётом того, что в расте на типы накладываются реальные ограничения.

Насчёт больших возможностей - только одно в голову приходит. А именно то, что там своего рода «утиная типизация» и из-за этого проще использовать шаблонные функцию с типами, которые о них ничего не знают. Насколько это будет проблемой для раста пока судить не могу. В любом случае, ограничения по типам (трейтам) несут одновременно и преимущества, а «нужного» поведения можно добиться через макросы.

Думаю, это возможно, просто нужны исследования.

Ну дык, я смотрю на раст как на подвижки в правильном направлении. Тем более, что кроме «исследований» нужны и практические эксперименты, чтобы сильнее повлиять. Если бы хаскел был только теорией, то о нём знали бы куда меньше, а так «приобщиться» любой может.

А что плохого в ссылке на мутабельные данные, если они lock/wait -free или защищены какими-то блокировками?

Ничего. Но раст и это учитывает. Если тип реализует трейт Sync, то с ним можно из разных потоков взаимодействовать.

Вроде ж растовские дженерики невозможно частично специализировать? Или я отстал от жизни?

Если тип реализует трейт Sync, то с ним можно из разных потоков взаимодействовать.

А он что-то умеет проверять в плане корректности реализации?

Вроде ж растовские дженерики невозможно частично специализировать?

Да, действительно, нельзя. Тем не менее, они там что-то думают на тему Higher-Kinded Types.

А он что-то умеет проверять в плане корректности реализации?

А как ты это представляешь?

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

Evaluation of performance and productivity metrics of potential programming languages in the HPC environment

Прочёл. Занятно, хотя и могло бы быть интереснее. Например, хотелось бы посмотреть сравнение с реализацией на питоне, который они ругают за «тормоза» и динамическую типизацию. Тем интереснее сравнить с Gо - есть ли заметный выигрыш в скорости и строках кода. Опять же, про фортран столько говорится - могли бы и на нём реализовать.

Ну и некоторые моменты достаточно спорные или не совсем корректные (ну или я их так понял).

Чисто технические причины

НЕ любить

не перестаю проигрывать с таких ущербанов :D

afiskon дайте ссылку на свой список, пожалуйста. не хочу все 10 страниц сраобсуждения пролистывать.

у него в профиле ссылка на его «список». жаль вас разочаровывать, конечно...

По скорости на момент написания этих строк Rust сравним с Java, Go и Haskell: ... Я искренне надеюсь, что со временем его как-то разгонят, но до тех пор в плане компромисса скорости и безопасности он не намного интереснее Scala или Go

Наглейшее 4.2!
Ну или «со временем» наступило оччень внезапно и непредсказуемо, да! (что, в свою очередь, заставляет усомниться в «правильности» остальных пунктов =) )

http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp Ржавчина идет между Си и плюсами. Т.е. на втором месте.

Пардоньте за некропост. Статическую компоновку называли?

Статическую компоновку называли?

Дык, можно и динамически линковаться, разве нет?

По крайней мере в Cargo сейчас так нельзя. Это намекает на то, что разработчики зачем-то предпочитают статическую компоновку, а динамическую «дорисовали сбоку».

Лямбдочки еще 1) нарезать правильно из кода надо 2) надо бороться с thread starvation. Первый пункто особенно сочный, особенно когда надо линейный код превратить в чередующийся набор функций и IO-операций. Или когда в одном из них происходит блокировка, то неплохо бы как-то разбудить другие грин трэды чтобы дать им поработать. Но безопасно конечно, ведь та блокировка могла быть по грин мьютексу (который надо реализовать), а не по IO операции

void iter2(unsigned long *count)
{
    ++*count;
}
//...
unsigned long count = 0;
//...
for (forever = 1, count = 0; forever; )
        iter2(&count);

на что люди не идут чтобы не использовать глобальные переменные

это что, какое-то табу?

Это намекает на то, что разработчики зачем-то предпочитают статическую компоновку, а динамическую «дорисовали сбоку».

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