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

Я тоже не понял, потому и решил уточнить.

Возможно, о том, что возможность спровоцировать утечку (и невызов drop) с помощью Rc известна и не считается unsound.

Но вот это меня всё равно беспокоит.

И да, я не уверен, это будет вообще читаемо, если ту же информацию в s-выражениях записать.

(public check-read-write
        
        ([T (+ partial-eq (:: fmt debug))]
         [R (-> (fn (&mut &[u8])) 
                (:: s11n (result T)))] 
         [W (fn (&mut (Vec u8)) &T)])
        
        ([value     &T] 
         [bytes-hex &[u8]]
         [read      R] 
         [write     W]))

Так где твой список-то?

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

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

Библиотеки для того и нужны, чтобы кочевать из проекта в проект, не?

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

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

И ещё один момент - если ты пишешь код на работе за деньги, то «уносить с собой» библиотеки, как правило, не имеешь права.

не будет списка. Автор - тролль

скорее всего будет, просто он подготавливается и подсобирает материал на статью в свой бложик http://eax.me (хотя фиг его знает:))

даже не желая думать что можно как-то лучше?

«Как будто что-то хорошее».

Или я тебя не понял или вижу только положительные моменты от «думания как можно лучше». Даже если никуда не уходить с привычных языков/библиотек, то они ведь всё равно развиваются. В том числе, заимствуя идеи обкатанные в других языках.

Ну и расширение кругозора.

AST дженерика запихивается прямо в скомпилированный объектный файл — чтобы можно было использовать с другим типом.

И почему это плохо?

Раздельная компиляция?

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

Не, не слышали.

ХЗ о ком ты.

«C++ name mangling rules» не существуют

А, ну-ну.

но по-моему бред, что нельзя например писать

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

Разница в том, что без запятых можно обойтись.

Без скобок, зачастую, тоже. Можно использовать отступы. Но ведь такой лисп тебе не понравился бы?

Можно использовать отступы.

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

Без скобок, зачастую, тоже.

но зачем? Скобки в отличии от запятых код не засоряют.

Ты заацептил 1к соединений, породил 1к файберов, но у тебя только 32 физические коры.

В каждом треде висит accept, так что файберы изначально неплохо распределены.

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

Точно, начитался c10k, но в жизни не писал хайлоада.

Понятно, что это реализуется рантаймом ЯП

В go нет потоков, соответственно никаким «воровством задач» там и не пахнет.

Поэтому в Rust нет зеленых потоков

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

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

Как ни странно, проблема на ELF'ах решается до непристойного тривиально: берем и переопределяем write/read/send/recv/writev/readv/sendmsg/recvmsg/poll/select/sleep таким образом, чтобы вместо блокировки происходило переключение в другой файбер. Проблема решена!

И в самом крайнем случае, никто не мешает сделать wrapper'ы для вызовов функций сторонних библиотек, которые будут делегировать выполнение «сложных функций» другим рабочим потокам. Примечательно, что код по-прежнему останется линейным.

Кстати, одна из причин, по которым из Rust убрали green threads - трудность взаимодействия с Си-библиотеками.

Вот это неосиляторы.

Хотелось бы уточнить степень убогости ржавчины: там вообще нет ничего, что позволило бы реализовывать файберы, или все же есть подобие setjmp/longjmp, поверх которых можно накостылить по болбшой нужде?

Проблема решена!

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

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

Как-то сильно много костылей за удовольствие писать «линейный» код

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

Закапывайте очередной D мертворожденный язычок с вырвиглазным синтаксисом.

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

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

Никакой полиморфной рекурсии — упираемся в бесконечное развёртывание шаблона

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

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

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

«C++ name mangling rules» не существуют. Речь там идёт всего лишь об одной из реализаций

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

что C++ и perl по сравнению со ржавчиной просто кросавчеги.

C++

согласен

perl

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

тут рядом уже холиварят по поводу S-expr, подключайся

там вообще нет ничего, что позволило бы реализовывать файберы, или все же есть подобие setjmp/longjmp, поверх которых можно накостылить по болбшой нужде?

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

То есть часть, где я писал про врапперы и делегацию задач в отдельные треды ты не понял?

Я не понял, как это сделать, если у вас есть необходимость дергать функции какой-нибудь сторонней библиотеки масштаба OpenSSL или APR. Что там внутрях — хз. Перекомпилировать всю библиотеку подсовывая ей врапперы вместо функций вроде fprintf?

Как ни странно, проблема на ELF'ах решается до непристойного тривиально: берем и переопределяем write/read/send/recv/writev/readv/sendmsg/recvmsg/poll/select/sleep таким образом, чтобы вместо блокировки происходило переключение в другой файбер. Проблема решена!

В OCaml'e стоит заюзать async (зеленые нити), как все блокирующие операции из стандартной либы заменяются заглушками и ничерта не компилится. Обойти конечно это можно костылями, но тут как говорится ССЗБ.

LD_PRELOAD?

Кстати, одна из причин, по которым из Rust убрали green threads - трудность взаимодействия с Си-библиотеками.

Вот это неосиляторы.

Им явно не хватает сильных специалистов твоего уровня.

Хотелось бы уточнить степень убогости ржавчины

ЕМНИП, для желателей странного всё еще есть libgreen.

LD_PRELOAD?

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

Ты спрашиваешь есть ли такое под винду? Не знаю. Но думаю что есть. Тем более, ld емнип имеет параметр -wrap который на винде должен работать.

Будь добр, почитай вот это, перед тем, как продолжать дискуссию: http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_DeshpandeSponslerWeis... . У меня создается впечатление, что ты не осознаешь, что файберы требуют серьезной поддержки в со стороны рантайма ЯП, в частности наличие нетривиального планировщика. Я не знаю, внесли ли предлагаемые изменения, но на момент написания статьи в Go была одна глобальная очередь горутин, из которой все потоки ОС таскали себе файберы для выполнения, беря глобальный лок(sic!). К слову, эта глобальная очередь как раз и объясняет, почему Go не может в масштабирование, это как пресловутый GIL в питоне. Файберы вообще никак не распределены - они попадают в общую глобальную очередь. Действительно, work stealing в Go нет (не было?) - я переоценил разработчиков - его предлагают добавить в статье, чтобы уменьшить миграцию горутин и связанные с этим проблемы с кэшем.

Если ты не писал хайлоад, то зачем высказываешься на эту тему? Во всяких там nginx нет файберов, это не нужно. В принципе, иногда себя хорошо показывают сопрограммы, как стековые, так и стековые. Для плюсовиков они доступны в boost, в том числе и в booat.asio, который де-факто стандарт для работы с сетью и с «асинхронным» вводом/выводом. Полноценные green-thread пока не очень себя показывают. Успех только у ерланга, но там несколько иная модель взаимодействия.

setjmp/longjmp очень медленные. Кроме того:

The environment of a call to the setjmp macro consists of information sufficient for a call to the longjmp function to return execution to the correct block and invocation of that block, were it called recursively. It does not include the state of the f loating-point status flags, of open files, or of any other component of the abstract machine.

Пока самое качественное решение, что я видел было в boost.context. И работает гораздо быстрее.

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

Ну да, ну да. Только вот setjmp/longjmp/ucontext уже очень много лет и они позволяют творить в языке совершенно дикие вещи. А ржавчина, получается, ничерта не может.

Сейчас начнется про молодость, комьюнити и ко-ко-ко, но кому в 2015 нужно какое-то УГ без намека на батарейки?

Им явно не хватает сильных специалистов твоего уровня.

Я и впрямь невысокого мнения о мозилловцах, если ты об этом.

Будь добр, почитай вот это

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

Тогда ты неверно используешь термины. Говори сопрограммы, а не «зелёные треды» и все будет понятно.

Если ты не писал хайлоад

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

Для плюсовиков они доступны в boost, в том числе и в booat.asio, который де-факто стандарт для работы с сетью и с «асинхронным» вводом/выводом

Ясно. Иди-ка ты с такими стандартами лесом. Учитывая, что asio выглядит как лапша и при этом еще ухитряется тормозить, дальнейшие вскукареки про «тормоза файберов» со стороны анонимного легиона игнорирую.

Им явно не хватает сильных специалистов твоего уровня.

Я и впрямь невысокого мнения о мозилловцах, если ты об этом.

Нет, я не об этом.

setjmp/longjmp очень медленные

Тред почитай. 78 миллионов пар setjmp/longjmp в секунду.

качественное решение
boost

Ну да, ну да.

В asio есть сопрограммы, которые избавляют от колбэчной лапши. Тормозит? Ты что-то делаешь не так. Производительность там на уровне libevent и libev.

booat.asio, который де-факто стандарт для работы с сетью и с «асинхронным» вводом/выводом

http://www.upload.ee/image/2501318/must-not-facepalm.jpg

Сейчас начнется про молодость, комьюнити и ко-ко-ко, но кому в 2015 нужно какое-то УГ без намека на батарейки?

а кто говорит про 2015? подожди пару-тройку лет - будут тебе твои батарейки. а твой libgreen был уже давно, если его еще не дропнули с тех пор за ненужностью

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

Производительность там на уровне libevent и libev.

Ну да, ну да. http://habrahabr.ru/post/152345/

Тогда ты говоришь про какие-то свои файберы, а не green threads/горутины, о которых изначально шла речь, т.к. горутинам очень даже нужен планировщик, с work stealing и периодическим локом глобальной очереди.

чтобы спроектировать хороший язык, нужно время

И борода! Ты забыл про бороду!

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

while (!good) {
  implement_idea();
  try_it();
  good = was_it_good_enought();
}

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

А хаскелисты? У них лямбды многострочные.

Но вообще мне отступы тоже не нравятся. А фигурные скобки и запятые вполне устраивают.

Поправка

The longjmp function restores the environment saved by the most recent invocation of the setjmp macro in the same invocation of the program with the corresponding jmp_buf argument. If there has been no such invocation, or if the function containing the invocation of the setjmp macro has terminated execution211) in the interim, or if the invocation of the setjmp macro was within the scope of an identifier with variably modified type and execution has left that scope in the interim, the behavior is undefined.

Т.е. setjmp/longjmp для переключения туда-сюда использовать нельзя.

Другое посиксовое решение - ucontext_t уже давно deprecated. И вот оно относительно тормозное.

По поводу boost'а. Не надо быть столь религиозным, там очень разные библиотеки. Где-то говно, где-то все хорошо. Попробуйте boost.context.

но зачем? Скобки в отличии от запятых код не засоряют.

Не понимаю такую логику. «Засоряют» все «необязательные» элементы. Другое дело, что они могут облегчать чтение кода, несмотря на то, что делают его более многословным.

while (!good) {
  implement_idea();
  try_it();
  good = was_it_good_enought();
}

ты в своем алгоритме забыл выкидывать ненужное.

а так у тебя как раз очередной D получится

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

Т.е. setjmp/longjmp для переключения туда-сюда использовать нельзя.

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

Значит ты не профессионал, разговаривать с любителями мне неинтересно.