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

3

9

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

Ссылка

←	Подскажите инструменты для организации справочника по функциям разрабатываемого ПО

bash дописывать всем командам по маске агрументы

→

← 1 2 3 4 5 6 7 8 9 10 →

Ответ на: комментарий от DarkEld3r 16.04.15 14:45:27 MSK

«Засоряют» все «необязательные» элементы.

Это когда они в коде. А скобки - по бокам, их в коде нет

Другое дело, что они могут облегчать чтение кода, несмотря на то, что делают его более многословным.

Ну вот запятые не облегчают, когда синтаксическая загруженность и так высока. Когда у тебя «xf sd, y fsdf, zf d s» запятые действительно помогают, но когда в этой строке куча говна с какими-то угловыми скобками, двоеточиями, амперсандами и прочим говном, то толку от запятых около нуля.

anonymous
(16.04.15 14:51:57 MSK)

Ответ на: комментарий от Bad_ptr 16.04.15 12:12:14 MSK

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

Ну дык, это разве не одно и то же? (:

«Я ничего не знаю о языке, но он мне не нравится, надо найти список недостатков для копипасты». При этом факт, что люди, которые перечисляют недостатки, не отказываются от языка, умалчивается.

Иначе свой список он давно опубликовал бы. Но вообще из таких тем я и сам что-то новое узнаю.

DarkEld3r ★★★★★
(16.04.15 14:55:26 MSK)

Ссылка

Ответ на: комментарий от kawaii_neko 16.04.15 13:07:22 MSK

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

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

DarkEld3r ★★★★★
(16.04.15 14:57:38 MSK)

Ответ на: комментарий от cyanide_regime 16.04.15 12:06:11 MSK

Почему эту поделку надо было сделать на ржавчине, а не на С++(11)?

А в таких вещах (особенно, которые пишут «для себя») «надо» часто бывает на 100% обоснованным? При желании ведь можно было и на С и на асме сделать. Как и на джаве какой-нибудь.

DarkEld3r ★★★★★
(16.04.15 14:58:56 MSK)

Ответ на: комментарий от anonymous 16.04.15 14:51:57 MSK

А скобки - по бокам, их в коде нет

Открывающие - есть.

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

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

DarkEld3r ★★★★★
(16.04.15 15:02:20 MSK)

Ответ на: комментарий от DarkEld3r 16.04.15 14:57:38 MSK

Да не нужен тут сложный рантайм. Нужен способ переключения контекста. И все. Так делают на C и C++, довольно часто(для узкой ниши очень нагруженных бэкендов на этих языках). Это достаточно низкий уровень и никакого сложного рантайм не требует.

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

anonymous
(16.04.15 15:05:08 MSK)

Ответ на: комментарий от kawaii_neko 16.04.15 14:37:17 MSK

Уже как-то обсасывали. Он в либевентах всяких указателями работал, а в boost::asio объекты копировал. В общем очередной «смотрите онжетормозит!!!»

У меня, например получается что asio обрабатывает примерно процентов на 5-7 всего меньше в секунду, чем libevent. И это без всяких извратов и практически с доков «how to».

anonymous
(16.04.15 15:06:09 MSK)

Ответ на: комментарий от DarkEld3r 16.04.15 14:58:56 MSK

Парень заявил что у него есть проект в 5к строк и что о плюсах ржавчины он может говорить. Вот я и спрашиваю: какие плюсы у ржавчины перед C++11 именно в контексте этого проекта? Если единственным его доводом было изучение ржавчины самой по себе, то пусть идет лесом.

cyanide_regime
(16.04.15 15:07:23 MSK)

Ответ на: комментарий от kawaii_neko 16.04.15 14:40:38 MSK

Они сидят и теоретизируют, пытаясь объять необъятное.

Да вообще-то они как раз много экспериментировали. И изменяли язык по результатам экспериментов.

DarkEld3r ★★★★★
(16.04.15 15:09:57 MSK)

Ссылка

Ответ на: комментарий от DarkEld3r 16.04.15 15:02:20 MSK

Открывающие - есть.

Нет, ониже сбоку!

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

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

anonymous
(16.04.15 15:13:47 MSK)

Ответ на: комментарий от anonymous 16.04.15 15:06:09 MSK

libevent, кхм, не очень качественная библиотека (malloc на каждый чих): http://libev.schmorp.de/bench.html

Кстати, что такого asio обрабатывает?

kawaii_neko ★★★★
(16.04.15 15:15:42 MSK)

Ответ на: комментарий от anonymous 16.04.15 15:13:47 MSK

Нет, ониже сбоку!

 (let ((var1 init-form-1)
       (var2 init-form-2)
       ...
       (varm init-form-m))

По моему, скобок «внутри» хватает.

А человеку - не особо.

Но хоть немного да помогают. И ладно - твои предложения?

DarkEld3r ★★★★★
(16.04.15 15:20:22 MSK)

Ответ на: комментарий от kawaii_neko 16.04.15 15:15:42 MSK

давно уже перделали вроде.

Кстати, что такого asio обрабатывает?

а? что скажешь, то и обрабатывает.

anonymous
(16.04.15 15:23:47 MSK)

Ссылка

Ответ на: комментарий от cyanide_regime 16.04.15 15:07:23 MSK

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

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

DarkEld3r ★★★★★
(16.04.15 15:31:11 MSK)

Ответ на: комментарий от DarkEld3r 16.04.15 15:20:22 MSK

По моему, скобок «внутри» хватает.

Где? Скобки с левой стороны кода и с правой. Внутри - нету.

И ладно - твои предложения?

не перегружать синтаксис ascii-артом, очевидно же.

anonymous
(16.04.15 15:31:14 MSK)

Ответ на: комментарий от tailgunner 16.04.15 12:20:12 MSK

Поддерживается.

Ага, в виде внедрения исходника в скомпилированный файл. Да-да, конечно.

Miguel ★★★★★
(16.04.15 15:35:59 MSK)

Ответ на: комментарий от MyTrooName 16.04.15 13:20:27 MSK

есть еще опция с trait objects

А с этого момента поподробнее, пожалуйста.

эх, если бы...

Что «если бы»?

что в этом плохого?

Ну, раздельная компиляция — это, вроде как, хорошо, нет?

Miguel ★★★★★
(16.04.15 15:37:08 MSK)

Ответ на: комментарий от MyTrooName 16.04.15 13:24:26 MSK

в каждой реализации они велосипедятся независимо. это еще хуже

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

Miguel ★★★★★
(16.04.15 15:38:19 MSK)

Ответ на: комментарий от Miguel 16.04.15 15:35:59 MSK

в виде внедрения AST дженерика в скомпилированный файл

/fixed

tailgunner ★★★★★
(16.04.15 15:39:23 MSK)

Ответ на: комментарий от kawaii_neko 16.04.15 14:46:15 MSK

И это работает подо всеми доступными архитектурами и компиляторами.

А списочек можно?

eao197 ★★★★★
(16.04.15 16:01:58 MSK)

Ответ на: комментарий от anonymous 16.04.15 15:31:14 MSK

Где? Скобки с левой стороны кода и с правой. Внутри - нету.

В таком случае, запятые тоже слева и справа от токенов, но не в середине.

не перегружать синтаксис ascii-артом, очевидно же.

Заменять словами? Будет многословно.

DarkEld3r ★★★★★
(16.04.15 16:38:03 MSK)

Ответ на: комментарий от anonymous 16.04.15 15:05:08 MSK

Да не нужен тут сложный рантайм.

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

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

DarkEld3r ★★★★★
(16.04.15 16:40:16 MSK)

Ссылка

Ответ на: комментарий от eao197 16.04.15 16:01:58 MSK

А списочек можно?

x86, x86_64 с gcc/clang/icc

kawaii_neko ★★★★
(16.04.15 16:45:25 MSK)

Ответ на: комментарий от Legioner 15.04.15 14:09:19 MSK

Макросы хотелось бы видеть более интегрированные с языком. Например размещение их в namespace-ах

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

DarkEld3r ★★★★★
(16.04.15 16:46:32 MSK)

Ссылка

Ответ на: комментарий от kawaii_neko 16.04.15 16:45:25 MSK

x86, x86_64 с gcc/clang/icc

Спасибо.

А платформа, я так понимаю, Linux?

eao197 ★★★★★
(16.04.15 16:49:59 MSK)

Ответ на: комментарий от eao197 16.04.15 16:49:59 MSK

Да.

kawaii_neko ★★★★
(16.04.15 17:00:47 MSK)

Ответ на: комментарий от kawaii_neko 16.04.15 17:00:47 MSK

<зануда>
При всем уважении, это не тянет на довольно громкое утверждение «И это работает подо всеми доступными архитектурами и компиляторами.» Формально, конечно, к нему придраться нельзя, но обычно такие вещи говорят, когда _разных_ архитектур и компиляторов несколько (вроде x86, ARM, MIPS и т.д.).
</зануда>

eao197 ★★★★★
(16.04.15 17:09:49 MSK)

Ответ на: комментарий от DarkEld3r 16.04.15 16:38:03 MSK

Заменять словами?

Не надо заменять. Просто убрать.

В таком случае, запятые тоже слева и справа от токенов, но не в середине.

Это уже зависит от форматирования кода, ага. Код с запятыми так не форматируют, а если и форматируют - он выглядит обычно сверхвырвиглазно

anonymous
(16.04.15 17:18:19 MSK)

Ответ на: комментарий от anonymous 16.04.15 17:18:19 MSK

Не надо заменять. Просто убрать.

Без потери смысла? Покажи. Вон loz свой вариант привёл, но у него достаточно спецсимволов осталось.

Это уже зависит от форматирования кода, ага.

Ты издеваешься? Давай ещё раз - вот в примере с let в лиспе. После «let» будет две скобки. А это уже код.

 (let ((var1 init-form-1)
       (var2 init-form-2)
       ...
       (varm init-form-m))

Или ты пишешь вот так?

 (let 
      ((var1 init-form-1)
       (var2 init-form-2)
       ...
       (varm init-form-m))

И что вообще не бывает скобок внутри строки? С трудом верится. Можешь ссылку на свой код дать?

DarkEld3r ★★★★★
(16.04.15 17:26:42 MSK)

Ответ на: комментарий от eao197 16.04.15 17:09:49 MSK

ARM, MIPS и т.д.

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

kawaii_neko ★★★★
(16.04.15 17:35:13 MSK)

Ответ на: комментарий от DarkEld3r 16.04.15 17:26:42 MSK

После «let» будет две скобки.

Но на них никто не смотрит.

Без потери смысла? Покажи.

Чтобы знать, как можно заменить эти значки, надо понимать, что они значат. А я не в курсе.

anonymous
(16.04.15 18:04:27 MSK)

Ответ на: комментарий от DarkEld3r 16.04.15 17:26:42 MSK

И что вообще не бывает скобок внутри строки?

Они могут быть но на них никто не смотрит. Ты видишь let и видишь справа от него два столбика текста, скобки тебе не нужны. Запятые же надо отслеживать в строке, без этого ты не сможешь разделить выражения.

anonymous
(16.04.15 18:06:17 MSK)

Ссылка

Ответ на: комментарий от anonymous 16.04.15 18:04:27 MSK

Но на них никто не смотрит.

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

DarkEld3r ★★★★★
(16.04.15 18:20:39 MSK)

Ответ на: комментарий от kawaii_neko 16.04.15 14:46:15 MSK

И это работает подо всеми двумя доступными архитектурами и компиляторами.

/fixed

tailgunner ★★★★★
(16.04.15 18:24:10 MSK)

Ссылка

Ответ на: комментарий от Miguel 16.04.15 15:37:08 MSK

А с этого момента поподробнее, пожалуйста.

http://doc.rust-lang.org/book/trait-objects.html#dynamic-dispatch

короче говоря, полиморфизм а-ля java interfaces на трейтах

Что «если бы»?

там можно делать рекурсивные темплейты. пример выше по треду, Foo<T, Option<Rc<RefCell<Foo<T>>>>. и там же, выше по треду, проблемы, которые такая возможность вызывает именно в контексте ржавчины.

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

Ну, раздельная компиляция — это, вроде как, хорошо, нет?

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

раздельная компиляция - это удобно, но не так уж приоритетно

MyTrooName ★★★★★
(16.04.15 18:33:52 MSK)

Ответ на: комментарий от Miguel 16.04.15 15:38:19 MSK

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

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

Применительно к C++ — это как если бы .o содержал в себе полную копию .h.

.o без .h в cpp бесполезен. так что хоть один другого и не содержит, все равно тащатся вместе.

MyTrooName ★★★★★
(16.04.15 18:37:45 MSK)

Ответ на: комментарий от MyTrooName 16.04.15 18:33:52 MSK

А нафига она вообще сдалась то? В результате же всё равно приходится городить костыли типа lto для обхода её проблем.

Gorthauer ★★★★★
(16.04.15 18:37:47 MSK)

Ответ на: комментарий от Gorthauer 16.04.15 18:37:47 MSK

если ты про раздельную компиляцию, то, наверное, ускорение повторных сборок?

MyTrooName ★★★★★
(16.04.15 18:40:04 MSK)

Ссылка

Ответ на: комментарий от MyTrooName 16.04.15 18:33:52 MSK

Foo<T, RefCell<Option<Rc<Foo<T>>>>

нет, вот так, вроде. ну да не суть

MyTrooName ★★★★★
(16.04.15 18:41:56 MSK)

Ссылка

Ответ на: комментарий от DarkEld3r 16.04.15 15:31:11 MSK

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

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

cyanide_regime
(16.04.15 19:22:39 MSK)

Ответ на: комментарий от tailgunner 16.04.15 15:39:23 MSK

AST от исходника отличается ничем.

Miguel ★★★★★
(16.04.15 20:01:17 MSK)

Ответ на: комментарий от MyTrooName 16.04.15 18:33:52 MSK

короче говоря, полиморфизм а-ля java interfaces на трейтах

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

там можно делать рекурсивные темплейты

А, ну да.

В нормальных языках (и даже в жабе) рекурсивные дженерики делаются без труда.

раздельная компиляция - это удобно, но не так уж приоритетно

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

Miguel ★★★★★
(16.04.15 20:05:30 MSK)

Ответ на: комментарий от MyTrooName 16.04.15 18:37:45 MSK

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

Так и отлично. Когда надо — используют extern «C» и всё хорошо. А на тёмные правила манглинга завязаться невозможно, это тоже здорово.

так что хоть один другого и не содержит, все равно тащатся вместе.

Вот только такой .h содержит только интерфейс. А я говорю о том, чтобы взять STL и запихать в объектник. В виде исходного кода.

Miguel ★★★★★
(16.04.15 20:08:28 MSK)

Ответ на: комментарий от cyanide_regime 16.04.15 19:22:39 MSK

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

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

tailgunner ★★★★★
(16.04.15 20:08:57 MSK)

Ссылка

Ответ на: комментарий от Miguel 16.04.15 20:01:17 MSK

AST от исходника отличается ничем.

Это с трудом катит даже как полемический прием.

tailgunner ★★★★★
(16.04.15 20:10:18 MSK)

Ответ на: комментарий от Miguel 16.04.15 20:01:17 MSK

Байткод от исходника не отличается ничем. Объектный код от исходника не отличается ничем.

anonymous
(16.04.15 20:12:45 MSK)

Ответ на: комментарий от Miguel 16.04.15 20:05:30 MSK

В нормальных языках (и даже в жабе) рекурсивные дженерики...

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

anonymous
(16.04.15 20:13:00 MSK)

Ссылка

Ответ на: комментарий от Miguel 16.04.15 20:08:28 MSK

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

Чего хорошего? Отказывается от крестов фактически.

anonymous
(16.04.15 20:14:35 MSK)

Ссылка

Ответ на: комментарий от anonymous 16.04.15 20:12:45 MSK

Не передергивай. Ast - другая форма представления исходного кода.

anonymous
(16.04.15 20:16:24 MSK)

Ссылка

Ответ на: комментарий от tailgunner 16.04.15 20:10:18 MSK

Так и не должно катить как полемический приём. Ибо это так и есть.

Miguel ★★★★★
(16.04.15 20:31:07 MSK)

Ссылка

Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.

← 1 2 3 4 5 6 7 8 9 10 →

←	Подскажите инструменты для организации справочника по функциям разрабатываемого ПО

Development

bash дописывать всем командам по маске агрументы

→

Похожие темы