Чисто технические причины НЕ любить Rust [holywar mode activated]

армы и мипсы в хайлоаде? Ну да, ну да.

http://www.montblanc-project.eu/

Вот только такой .h содержит только интерфейс

STL

что ты понимаешь под интерфейсом сейчас?

Не передёргивай.

Первая фраза («Вот только такой .h содержит только интерфейс») — про .h, который идёт совместно с .o. А никак не про STL.

что ты понимаешь под интерфейсом сейчас?

вопрос в силе

Sigh.

В этой фразе подразумевались сигнатуры типов функций и переменных, этим файлом экспортируемых.

Что-то я не пойму, легковесные потоки выбросили, изкоробочные футуры убогие чуть менее, чем полностью - как вообще предполагается писать нормальный асинхронный код в последней надежде человечества?

https://github.com/carllerche/mio

как вообще предполагается писать нормальный асинхронный код в последней надежде человечества?

Не лишай человечество надежды - останься в Node.js.

rust это убийца C, а не элранга.

C++. Убить Си нельзя.

2) AST дженерика запихивается прямо в скомпилированный объектный файл — чтобы можно было использовать с другим типом. Применительно к C++ — это как если бы .o содержал в себе полную копию .h.

применительно к С++, .h на темплейтах содержит в себе интерфейс вместе с реализацией, и я не вижу большой проблемы выкинуть .h, а реализацию отправить в .o

изкоробочные футуры

а они в расте есть?

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

Ну вроде как да: https://doc.rust-lang.org/std/sync/struct.Future.html

а что в них убогого? вроде фьючеры как фьючеры

Исключения в расте вводить собираются или уже есть они ? А то вродебы как были заявлены но похоже в 1.0 alpha толи випиляли толи есще не завезли ...

А вообще чтото они его кардинально переделывают довольно регулярно - не сильно хороший признак.

сключения в расте вводить собираются или уже есть они ?

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

А вообще чтото они его кардинально переделывают довольно регулярно

ну так только что в бету вошли. кардинально до 2.0 больше не будут

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

Если ты пишешь на лиспе, то ты привык читать лисповый код. Если ты не пишешь на лиспе - то ты его и не читаешь. По-этому ситуацию с чтением лиспового кода непривычным человеком рассматривать смысла нет.

Если код отформатирован нормально, то они помогают его читать и всё. Ну а кашу из кода и на лиспе изобразить можно.

Разница в том, что в лиспе есть некоторый простой и четкий набор правил форматирования, по которым форматируется 99% кода. В случае запятых такого нет.

рубит тонны бабла

в смысле на ruby бабло делает?

Насколько это кроссплатформенно?

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

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

У unix-оидов с давних пор под кроссплатформенностью понимается лишь способность их софта работать под разными версиями одного и того же unix-а...

Между тем существует и нормальное понятие кроссплатформенности, подразумевающее работоспособность под разными ОС и на разных аппаратных архитектурах.

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

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

Ну и судя по гитхабу ozkriff начал писать два месяца назад. Не так уж мало.

Лично мне весьма нравятся некоторые «синтаксические фичи», ну и borrow checker. Про неприятные моменты тут тоже писал. Но «окончательное сравнение» делать не возьмусь.

Так и отлично. Когда надо — используют extern «C» и всё хорошо.

Дык, если у плюсов был бы переносимый ABI - разве это плохо?

Если ты пишешь на лиспе, то ты привык читать лисповый код.

Естественно. Об этом и пытался сказать. Пишу на С++ и никаких проблем с запятыми у меня нет - претензии на эту тему выглядят так же смешно как скобкофобия от лисп-хейтеров.

Разница в том, что в лиспе есть некоторый простой и четкий набор правил форматирования, по которым форматируется 99% кода. В случае запятых такого нет.

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

вроде, не собирались и не будут

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

ну так только что в бету вошли. кардинально до 2.0 больше не будут

$ equery l -i rust
 * Searching for rust ...
[IP-] [  ] dev-lang/rust-1.0.0_alpha2:1.0

Это у меня порты старые или он все же alpha пока ?

Это у меня порты старые или он все же alpha пока ?

Старые:

rustc -V
rustc 1.0.0-beta (9854143cb 2015-04-02) (built 2015-04-02)

Ну и судя по гитхабу ozkriff начал писать два месяца назад. Не так уж мало.

Два месяца — это вообще ни о чем.

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

нет возможности композиции, т.е. по сути все, что можно сделать с растовским фьючером - это заблокироваться на нем до завершения операции

Два месяца — это вообще ни о чем.

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

Да и вообще, больше важен размер проекта, чем его «древность». Можно делать по коммиту в неделю, а можно активно развивать.

Но вот если бы в этот ABI пролезали детали реализации (как в Itanium-ной реализации, см. выше по треду), то было бы гораздо хуже, чем сейчас.

Почему?

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

компилятор заставит чекать. man Result. ну и есть сахар на макросах (man try!), который немного упрощает. хотя проблема, конечно, остается, но в рамках концепции раста исключения - плохое решение.

порты старые

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

Гм. Потому что это детали реализации.

Да и вообще, больше важен размер проекта, чем его «древность». Можно делать по коммиту в неделю, а можно активно развивать.

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

По времени работы с языком. Бытует мнение, что на нормальное освоение языка, т.е. на то, чтобы на языке как на «родном», используя присущие языку идиомы и приемы, нужно от 6 до 12 месяцев плотной работы. До этого времени на новом языке пишут как на предшественнике, только с другим синтаксисом и набором библиотек.

Странные у тебя шутки. Это даже однозначно распарсить нельзя)

Да потому что не хочется иметь очередной буст или хуже того - собственную библиотечку utils/common, которая кочует из проекта в проект. Ну это при условии, что оно востребовано будет.

Я не очень понял, с чего новый «буст или utils/common должны возникнуть» и почему «содержимое будет копипастится». По сложности подключения - сам знаешь, всего-то надо в cargo.toml в секцию [dependencies] дописать wrapping_macros = "*". Про «непонятное будущее» - не верится, что популярные библиотеки без поддержки останутся.

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

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

Конкретно этот макрос совсем не факт что так уж много кому реально нужен - разве много кода на переполнение завязано?

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

Имхо, это довольно сильно зависит от того насколько язык заставляет «думать по новому». Раст, конечно, не хаскель какой-нибудь, но и писать совсем как на С++ не получится.

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

Тред читать лень, этот зеленый джентльмен уже выложил свой мифический вброс? Если выложит — кастаните плз, если нет — не беспокойте, просто перечеркните ему, пожалуйста, ник. Заранее спасибо.

Имхо, это довольно сильно зависит от того насколько язык заставляет «думать по новому». Раст, конечно, не хаскель какой-нибудь, но и писать совсем как на С++ не получится.

A language that doesn't affect the way you think about programming, is not worth knowing.
-- Alan Perlis

Тут уж надо определится, либо Rust действительно дает что-то стоящее программисту. Но тогда нужно время, чтобы привыкнуть писать на Rust-е, как на Rust-е.

Либо не дает. Но тогда нафиг он нужен?

Обещает сделать публикацию части списка после официального релиза Rust 1.0.

Обещает... части... когда рак на горе свиснет...

Вот это да. Платным подписчикам?

Вот это да. Платным подписчикам?

У него свой блог, он регулярно там пишет. Бывает, что просишь о чем-то рассказать подробнее, он вскоре выкладывает подробный ответ отдельным интересным постом. За время общения с ТС он ни разу на меня лично впечатления LOR-овского тро-ло-ло не произвел. Ну тут уж каждый пусть сам для себя решает.

PS. Официальный релиз Rust 1.0 вроде как назначен на май. Если тормозилловцы опять что-нибудь просрут, то это будет ни чем иным, как еще одной причиной не изучать Rust ;)

Я не очень понял, с чего новый «буст или utils/common должны возникнуть» и почему «содержимое будет копипастится».

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

Но я так понял, что атрибут всё-таки будет в стандарте?

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

Честно говоря, не понимаю чем «большая стандартная библиотека» плоха.

он ни разу на меня лично впечатления LOR-овского тро-ло-ло не произвел.

Так блогом он, в том числе, «пиарит себя». А прийти на другой ресурс и нагадить там - значит нормально? Пообещать список и развязать дискуссию, а потом сбежать я иначе назвать не могу. Готов спорить, что итоговый список будет творческим пересказом содержимого темы. Собственно, по ссылке там очередной бред про итераторы.

Если тормозилловцы опять что-нибудь просрут, то это будет ни чем иным, как еще одной причиной не изучать Rust ;)

Глупости. Уж лучше исправить всё до релиза, чем выпустить сырую версию ради того, чтобы успеть к дате.

Жизненный цикл любой новости о ЯП на ЛОРе.

• Публикуется новость о языке программирования;
• (1 стр.) Набегают анонимусы, охотники за шкворцом, неосиляторы и просто мимокрокодилы с криками «нинужно», «а зачем X, когда есть Y», «чем это лучше Z» и т.п.;
• (2-4 стр.) Просыпаются компетентные в теме ЛОРовцы и обсуждают тему;­
• (5-10 стр.) Набегают ёбн­­у­тые лиспофанбои и скатывают тему в лиспосрач;
• (10-15 стр.) Лиспофаги озалуплены, общими усилиями адекватных регистрантов и анонимусов;
• (15- стр.) Просыпается quasimoto и начинает обсуждать сам с собой монады, коммутативные диаграммы, стрелки, 2-стрелки, 3-стрелки, декартово замкнутые категории, аппликативные функторы, анаморфизмы, катаморфизмы, эпиморфизмы, параморфизмы, моноиды, полугруппы, когомологии и топосы Гротендика.

Пообещать список и развязать дискуссию, а потом сбежать я иначе назвать не могу.

Не мне быть адвокатом asfikon-а. Могу лишь сказать за себя: у меня нет оснований считать, что у человека не было списка, про который он говорил и что этот список не будет обнародован. Но я с asfikon-ом общался и вне LOR-а. Так что мое мнение базируется не на одной конкретной LOR-овской теме.

Что до самой идеи такого списка, то лично мне она кажется крайне странной. Любой ЯП — это совокупность каких-то идей, которые авторы считают важными и нужными (насколько удачными — это отдельный вопрос, т.к. тут не все может определяться желаниями авторов). Соответственно, технические претензии к возможностям языка — это либо непонимание целей авторов языка, либо же попытки притащить язык в несвойственную для него область. Например, низкоуровневость C/C++ — это большое достоинство для систем реального времени, но огромный недостаток для экспертных систем. С другой стороны — возможности записи логических правил на Prolog-е — это большой плюс для написания экспертной системы, но нифига не достоинство в нише высокопроизводительных видеоконвертеров.

Так что поиск фатальных технических недостатков в языке лишен смысла. Можно искать моменты, которые можно было бы улучшить или сделать удобнее. Но это не будет что-то принципиальное, имхо.

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

Ну что, какой вердикт вынесли уважаемые лоровцы? Не нужен?

Ну что, какой вердикт вынесли уважаемые лоровцы?

«годен к нестроевой службе»