Язык программирования D и Rust. Пробовали? Что можете сказать?

Я совсем немного пробовал работать с D, первое впечатление положительно. А по Rust посмотрел доклад, как увидел этот убогий стиль именования всего и вся в стиле: to_string, do_work, bla_bla_bla, что аж тошно стало. Понятно, что это не критерий оценки языка, так, просто, мысли в слух.

Добавлено через 12 часов 4 минуты
Ясно. Никто не пробовал. Я могу сказать, что D чем-то похож на C#, чем мне и понравился.

1

Сообщение от korvin_ Да неужели?

Да, такое впечатление складывается, потому что вы отметаете все аргументы с формулировкой "так никто не делает" либо "сам дурак, если так делаешь", т.е. с позиции, когда всё уже сделано и пофикшено, и можно расслабленно вздохнуть, надеть цилиндр и монокль, взять в руку бокальчик коньячку и наслаждаться выполненным проектом. А вот если "так всё-таки кто-нибудь делает" или "на проекте есть дурак", то приходится с этим "наделанным" сражаться, чтобы сделать как надо. А это и есть львиная доля процесса разработки. И если один инструмент запрещает делать плохо, а второй позволяет, то первый предпочтительнее.

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

Ну вот вы, кажется, не хотите согласиться с тем фактом, что некоторые (все) люди случайно косячат.

Сообщение от korvin_ Так какой инструмен предпочтительней остальных?

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

Сообщение от ct0r Каким образом, если я забуду drop реализовать?

Я по этому поводу уже писал. Забыли реализовать drop - получили глобальную багу, протянутую по всем местам, где у вас ресурс используется. А вот забыли руками освободить ресурс в конкретном месте - получили очень сильно локализованную багу, которую заметить куда сложнее. В случае с drop этот самый drop - единственное место, где можно забыть освободить ресурс, захваченный при конструировании объекта. Во втором случае конкретно детерминировать место проблематично, всё зависит от локальной логики использования ресурса.

Сообщение от ct0r Если он интересен и может облегчить мне жизнь.

Ну, если направленность инструмента не входит в вашу область интересов, то, естественно, конкретно вам он не нужен. Поэтому вопрос надо было ставить не как "Зачем его изучать?", а как "Зачем его изучать мне?" Вам - незачем, у вас направленность другая (наверное).

Сообщение от ct0r Я в тему влез с намеком, что новичку раст изучать скорее всего не нужно.

Намёки опасны тем, что, в зависимости от степени завуалированности, их бывает сложно верно интерпретировать.

Сообщение от ct0r А то его сейчас всякие упорные растоманы и хипстеры пиарят куда ни попадя.

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

0

Сообщение от ct0r Каким образом, если я забуду drop реализовать?

А еще можно в дропе ничего на самом деле не дропать. Ай какая дыра!

Сообщение от ct0r Если он интересен и может облегчить мне жизнь.

Ну значит вам - не может. Хз.

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

Почему нет?

Хипстеры в основном реакт-редаксы пиарят и смерть всего не-js.

Добавлено через 47 минут

Сообщение от korvin_ Видио какие-то (шарпо|EF-)проблемы?

нет

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

И в чем же целенаправленная стрельба в примере выше? Или это шарп виноват?

0

Сообщение от silent_1991 Да, такое впечатление складывается, потому что вы отметаете все аргументы…

Какие «все аргументы»? Я спросил, чем создание объекта отличается от using. Никаких отличий пока не нашлось, вот теперь пример разбираем.

Сообщение от Psilon нет

Где же нет, если да? Объясни для не-шарпистов, что в этом примере происходит и почему «use after free» возникает.

0

Сообщение от silent_1991 В случае с drop этот самый drop - единственное место, где можно забыть освободить ресурс, захваченный при конструировании объекта.

Как и деструктор в плюсах. Так что это явно не киллер-фича.

Сообщение от silent_1991 у вас направленность другая

У меня распределенные системы, облака, хайлоад.

Сообщение от silent_1991 отсутствием множества проблем, присущих последним

И наличием других, свойственных только ему.

Сообщение от Psilon А еще можно в дропе ничего на самом деле не дропать. Ай какая дыра!

А еще можно в плюсах выделить память умным указателем, а потом освободить трижды. Ай какая дыра!

0

Сообщение от korvin_ Какие «все аргументы»? Я спросил, чем создание объекта отличается от using. Никаких отличий пока не нашлось, вот теперь пример разбираем.

Тем, что нужно знать, где разрушать объект. Можно разрушить раньше времени, а можно позже. И то и то нежелательно. Энивей, декларативное время жизни, где компилятор сам выводит место, где можно объект безопасно разрушить, лучше, чем явный вызов free, по-моему с этим все согласны.

Сообщение от korvin_ Где же нет, если да? Объясни для не-шарпистов, что в этом примере происходит и почему «use after free» возникает.

Есть такой термин, как Navigation Property. Если вкратце, то для оптимизации EF грузит только непосредственные филды сущности, но не филды подсущностей, т.к. это требует подзапросов, и часто не нужно. Если идет запрос свойства, которое не было загружено, то идет запрос в БД для его заполнения.

Дальше проблема в том, что есть такая штука, как Automapper. Он занимается генерацией кода в стиле
При маппирование результата работы этой функции, он опрашивает все свойства, даже если ему нужны только те, которые мы явно добавили в Include. Это вызывает дополнительный вызов в БД через Navigation Property. Т.к. это возникает за пределами метода, то есть когда DbContext разрушен, возникает исключение.

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

Сообщение от ct0r Как и деструктор в плюсах. Так что это явно не киллер-фича.

По сути раст как раз энфорсит умные указатели. Деструктор в этом плане менее мощный.

Сообщение от ct0r И наличием других, свойственных только ему.

Каких?

Сообщение от ct0r А еще можно в плюсах выделить память умным указателем, а потом освободить трижды. Ай какая дыра!

Лол, а плюсы никто и не трогал, отличный язык. При чем тут они?

0

Сообщение от korvin_ Я спросил, чем создание объекта отличается от using.

Тем, что в случае с using можно создать объект и без using и получить утекший ресурс. Можно накосячить, можно не накосячить. В случае с drop накосячить таким образом нельзя.

Сообщение от ct0r А еще можно в плюсах выделить память умным указателем, а потом освободить трижды. Ай какая дыра!

В расте можно в drop ничего не дропать. В плюсах можно в деструкторе ничего не дестрактить. В шарпе можно в Dispose ничего не диспозать. В джаве в close ничего не клозать. И получить бесполезные using/try-with-resources в двух последних. Вот это эквивалентный пример. Так что во всех 4 языках можно накосячить одинаковым образом (ничего не освободить в деструкторе), но только два первых не позволяют накосячить другими обсуждаемыми способами благодаря RAII. В двух последних об "автоматическом" освобождении надо ещё дополнительно озаботиться, т.е. оно никакое не автоматическое на самом деле.

1

Сообщение от Psilon Деструктор в этом плане менее мощный.

Умные указатели легко реализуются поверх деструктора.

Сообщение от Psilon Каких?

1. Нет либ для многих вещей (по крайней мере нужных мне).
2. Если есть, то заброшены давно и не поддерживаются. (потому что написаны просто чтоб пощупать новый язык)
3. Если активно поддерживаются, то из-за малого кол-ва пользователей нельзя ничего сказать о их качестве и стабильности.
4. Если вообще все норм, то это обычно одна либа, без альтернатив.

Сообщение от Psilon При чем тут они?

Раст именно что хочет потеснить плюсы, как и си.

0

Сообщение от ct0r Умные указатели легко реализуются поверх деструктора.

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

Сообщение от ct0r 1. Нет либ для многих вещей (по крайней мере нужных мне). 2. Если есть, то заброшены давно и не поддерживаются. (потому что написаны просто чтоб пощупать новый язык) 3. Если активно поддерживаются, то из-за малого кол-ва пользователей нельзя ничего сказать о их качестве и стабильности. 4. Если вообще все норм, то это обычно одна либа, без альтернатив.

Проблема любого нового языка в том, что он новый. Постепенно решается. Например я для своего телеграм бота нашел почти все: крейт веб-сервера, крейт OWIN слоев, крейт многопоточных map-reduce, крейт конфигурирования, крейт логгирования... Единственное, чего не нашел, в текущем варианте opencv не весь функционал еще перенесен, я сейчас как раз активно занимаюсь написанием врапперов алгоритмов вроде SIFT для распознавания изображений. Не сказал бы, что продакшн реди, но свои проекты на нем писать уже можно.

Сообщение от ct0r Раст именно что хочет потеснить плюсы, как и си.

Раст ничего не хочет, это просто язык. Я вот пишу себе ботов и веб-приложения, и не лезу в системное программирование.

Резюме: если на все новое вокруг смотреть как на хипстерскую фигню, можно оказаться на месте COBOL-разработчиков конца нулевых.

0

Сообщение от Psilon Есть такой термин, как Navigation Property. Если вкратце, то для оптимизации EF грузит только непосредственные филды сущности, но не филды подсущностей, т.к. это требует подзапросов, и часто не нужно. Если идет запрос свойства, которое не было загружено, то идет запрос в БД для его заполнения. … При маппирование результата работы этой функции, он опрашивает все свойства, даже если ему нужны только те, которые мы явно добавили в Include. Это вызывает дополнительный вызов в БД через Navigation Property. Т.к. это возникает за пределами метода, то есть когда DbContext разрушен, возникает исключение.

Что мешает брать DbContext из ConnectionPool'а или как там у вас в шарпах, без создания его на каждый запрос? Обычно в Java вообще и при использовании Hibernate в частности (в котором тоже можно лениво подгружать вложенные объекты, что могло бы привести к похожей ошибке) так и делают. Без всяких using/try-with-resources.

0

korvin_, http://mehdi.me/ambient-dbcontext-in-ef6/ - тут написано, почему так. Вкратце - DbContext является Unit of Work, который под капотом конечно же использует пул соединений. Но его разрушение нужно из-за того, что иначе он тащит с собой ненужные кэши и т.п.

0

Сообщение от Psilon Проблема любого нового языка в том, что он новый. Постепенно решается.

Отлично, будем ждать.

Сообщение от Psilon Раст это и есть плюсы на стероидах во многом.

Заметно по времени компиляции.

Сообщение от Psilon Я вот пишу себе ботов и веб-приложения

Можно и на ассемблере для души ваять то же самое, кто ж спорит.

Сообщение от Psilon Резюме: если на все новое вокруг смотреть как на хипстерскую фигню, можно оказаться на месте COBOL-разработчиков конца нулевых.

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

0

Сообщение от ct0r Отлично, будем ждать.

Будем

Сообщение от ct0r Заметно по времени компиляции.

Не знаю как у вас, а у меня например время компиляции OpenCV с CUDA=ON занимает 6.5 часов. Ни с одним крейтом раста у меня подобного ада не было.

Сообщение от ct0r Можно и на ассемблере для души ваять то же самое, кто ж спорит.

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

Сообщение от ct0r Просто есть такое понятие - окупаемость инвестиций, которым неплохо бы руководствоваться.

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

0

Сообщение от silent_1991 но только два первых не позволяют накосячить другими обсуждаемыми способами благодаря RAII

Угу. Примерно так и говорил преподаватель студентке которой я курсач на C# сделал (сам его не зная). В смысле в С# using неполноценный RAII.

0

Возвращаясь к теме. ADT. Их нет в D, но есть в Rust. Правда в Rust рекурсивными они могут быть только косвенно. (Касательно предыдущей дискуссии, ADT нет в C#, хотя, конечно есть в F#.)

0

KolodeznyDiver, ну, рекурсивные структуры запрещены в любом языке по очевидным причинам.

Использовать же Box<Trait> никто не мешает.

0

Сообщение от Psilon рекурсивные структуры запрещены в любом языке

В Haskell они разрешены и широко применяются. То что их нет в Rust я и не считаю недостатком. Идеология Rust более низкоуровневая чем у настоящих функциональных языков. А описать деревья и графы и с такими ADT можно.
http://science.raphael.poss.na... mmers.html c заголовка "Recursive data structures".

0

KolodeznyDiver, рекурсивные структуры != рекурсивные типы. У структуры есть дополнительное ограничение: её размер известен на этапе компиляции. В расте это решается боксами. Соответственно список в расте это:
Что тут косвенного?

0

Сообщение от Psilon рекурсивные структуры != рекурсивные типы

В Rust существуют рекурсивные типы (не структуры)?
Кое где не в Rust рекурсивные структуры - это частный случай рекурсивных типов. Но не будем оффтопить. В Rust размер типа жёстко задан на этапе компиляции. Т.е. в Rust, как и в си, представление типа в памяти можно представить из его описания. Меньше скрывается под капотом. Под косвенным я и имел ввиду Box<>. Кое где не в Rust это спрятано от программиста, а реализация зависит от компилятора. Оба подхода имеют + и -.

0

KolodeznyDiver, `Box<T>` просто явное указание "я не знаю размер типа". Не вижу в этом особых плюсов и минусов. Писать поболее, читать полегче, вот и все.

Рекурсивных структур не бывает нигде, потому что структура - это фигня, имеющая конечный размер. Рекурсивное определение же конечного размера иметь не может. По крайней мере, пока мы говорим об общепринятом в современном энтерпрайзе определении, то есть C/C++/C#/Java/... Если вы имеете ввиду структуру в более теоретическом смысла - то да, написать без бокса не получится, но никакой косвенности я не вижу. Вот если бы и в бокс нельзя было структуру писать, и нужно было бы реализовывать трейт, типа `ListTrait` чтобы его туда запихнуть, тогда была бы косвенность. А так - просто мы явно пишем то, что в других языках делается неявно. По сути какой-нибудь лисп тут автоматически просто подставляет Box в терминах раста. Менее или более рекурсивными они от этого не стали, имхо.

0

Сообщение от Psilon Рекурсивных структур не бывает нигде, потому что структура - это фигня, имеющая конечный размер. Рекурсивное определение же конечного размера иметь не может. По крайней мере, пока мы говорим об общепринятом в современном энтерпрайзе определении, то есть C/C++/C#/Java/... Если вы имеете ввиду структуру в более теоретическом смысла

Вот именно. в C/C++/C#/Java так, а кое где не так. Давайте оставим этот спор. Я не имел ввиду что в Rust сделано плохо.

0