Facebook платит за устранение багов в реализации языка программирования D

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

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

А что вы думаете о Free Pascal? Не лучше ли он C++ и D вместе взятых?

А что вы думаете о Free Pascal? Не лучше ли он C++ и D вместе взятых?

Думаю что Вы бессовестно тролите. :)))

Ну а чего. Смотрю под винду есть Borland Delphi, под линукс - Lazarus. Приложение можно создать быстро и эффективно. ООП и все дела. Не каждая ведь задача сводится к написанию низкоуровневого драйвера. Тот же скайп вроде как на паскале...

Не каждая ведь задача сводится к написанию низкоуровневого драйвера.

Драйвер тоже можно, никаких проблем.

Delphi и его клон Free Pascal зашли в тупик, развивать их дальше (даже просто поддерживать) будет сложно. Есть годные Паскали, но увы, их никто не развивает.

Delphi и его клон Free Pascal зашли в тупик, развивать их дальше (даже просто поддерживать) будет сложно. Есть годные Паскали, но увы, их никто не развивает.Delphi и его клон Free Pascal зашли в тупик, развивать их дальше (даже просто поддерживать) будет сложно. Есть годные Паскали, но увы, их никто не развивает.

Lazarus развивается весьма активно и уже вполне работоспособен. Чем вам не угодил FreePascal?

Delphi зашли в тупик

http://www.embarcadero.com/ru/products/rad-studio угу, по этому эти люди творят вот такое, из безысходности своей тупиковой ситуации.

Чем вам не угодил FreePascal?

Он стал похож на C++.

Это агония

Каждый год-два выходят обновы. IDE самое удобное и безглючное, которое я видел. Читаемость кода удобнее в разы. Согласен, что всем он отдает школотой и студенчеством, так как почти все его учили. Но это еще не значит, что язык не серьезный. Мастер - это не тот, кто знает то, что не знают другие (тот же С++), а мастер тот, кто знает и умеет лучше всех (Delphi/Pascal)

Не лучше ли он C++ и D вместе взятых?

Нет.

Тот же скайп вроде как на паскале...

Нет (не совсем/не только).

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

Слишком толсто.

Ну и нахрена наследоваться? Сделал бы адаптер для SObjectizer и использовал бы его по указателю в виджете (делегирование). Или в вашем ПТУ паттернов не давали? Только множественное наследование, только хардкор.

Ну и нахрена наследоваться? Сделал бы адаптер для SObjectizer и использовал бы его по указателю в виджете (делегирование).

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

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

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

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

Или в вашем ПТУ паттернов не давали?

Нет, не давали. Их тогда еще не изобрели. ООП, кстати, тоже не давали, т.к. об этом подходе тогда в наших краях мало кто знал.

Вам же, непонятно почему не признающему множественное наследование, имело бы смысл прочитать «Объектно-ориентированное конструирование программных систем» Бертрана Мейера. Там только ООП, только «хардкор», никакой модной нынче функциональщины. Зато по ООП это одна из самых солидных книг.

А кто латает «дыры» С++? Его делают более удобным, насколько это позволяет ситуация.

Множественное наследование не нужно.

Это ограничение на количество предков не нужно. И вообще, читайте Бертрана Мейера, вместо того, чтобы слушать каких-то неосиляторов. Бертран Мейр не является сторонником С++, если что. В профессиональной литературе критика множественного наследования встречается только в литературе по языкам, где такое наследование запрещено. А аргументация запрета обычно содержит не слишком четкие определения и маловразумительные лозунги. По опыту использования C++, Python, а так же trait'ов в Scala, могу сказать, что никаких проблем множественное наследование не приносит. Т.е. вы можете сделать себе проблему, следуя определенным техникам, неясно только зачем.

Необходимость перегрузки операторов тоже спорна.

Чем оператор принципиально отличаются от функций/методов? Что плохого несет их перегрузка?

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

Там нет классов. Там есть trait'ы. Которые подобны тайпклассам Haskell, а также играют роль ограничителей для дженериков в статике. Наследование есть только для trait'ов. Поэтому если описываемая тобой система написана на rust, то сможешь. Поскольку тип может реализовывать произвольное число trait'ов.

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

В C++ эта возможность позволяет использовать си-библиотеки, даже если никто не писал для них обертки. Это можно решить разве что каким-то средством для обработки заголовочных файлов Си в компиляторе нового языка...

А еще безболезненно переходить в сишном проекте на С++. Тут уже вряд ли можно предложить альтернативу. D, как я понял, предлагает копипасту и исправление=) Пусть сами так переходят.

Проблемы ромба нет?

Эта не проблема, а точка принятия решения. В C++ нужно явно указать, виртуальная(разделяемая) у тебя база или нет - где же тут проблема, если как ты решишь, так у тебя и будет? В Питоне просто используется C3-линеаризация, как и в Scala(для trait'ов). А в Eiffel вообще можно переименовывать и выбирать методы базовых классов. Решать «проблему» ромба запретом множественного наследование достаточно глупо с технической точки зрения. С точки зрения продвижения языка, порога вхождения, маркетинга и пр., может и выгодно просто запретить.

Сам не использовал. Люди говорят, что глючит и что ни в какое сравнение с Java-средами не идет. И вообще, люди продолжают уходить с Delphi. Кто на шарпы, кто на явы... И правильно делают.

Матерый проффи, который за $100 правит двухлетний баг в чужом коде, это ты мощно задвинул, внушаить!

Просто вы плохо знаете жизнь. Или другими словами - по себе людей не судят. А вот это вам иллюстрация, что вы не правы - всего за 50$ исправлен двухлетний баг в чужом коде. Действительно - внушает! Или другими словами - собаки лают, караван идет. :)

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

Осталось доказать, что баг был исправлен «матерым процессионалом» и что именно сумма в $50 стала решающим фактором при исправлении этого бага :)

Или другими словами - собаки лают, караван идет. :)

Ну так если цель именно в том, чтобы идти и идти, то как иначе? Вот, например, что утверждалось здесь же около трех лет назад о готовности D2. Туда ему и дорога.

О! Да вы давно в теме про D. И все из года в года он плохой и ужасный? :) Не надоело следить за плохим и ужасным языком-то? ;)

В теме про D с 2001-го года. Среди прочего помню про D такие фортели, например, как отсутствие шаблонов в первых версиях. Брайт тогда считал, что в замене C++ не должно быть шаблонов. А спустя несколько лет добавил и именно шаблоны в свое время выглядели реальной killer feature D перед C++. И как внезапно в D лямбда-функции появились. Помню, как подтянулся Александреску и стал перекраивать язык еще раз. То «вирусную» константность с имутабельностью замутят, то ключевое слово shared добавят, то вместо итераторов ranges придумают, то какую-то часть стандартной библиотеки переделают. Хер знает, что люди делают, но явно не рабочий инструмент для других разработчиков.

Следить за D перестал с 2008, если не с 2007-го. Но радостные вопли очередных неофитов не дают забыть о сём долгострое. За последние 5 лет это уже третья или четвертая волна восторженных криков о том, что вот сейчас-то уж D точно выстрелит.

Так что я с интересом наблюдаю не за языком, а за поколениями новых любителей D, которые появляются, трындят чего-то, обещают золотые горы в самом ближайшем будущем, а потом исчезают так же внезапно, как и появляются. Этакое бесплатное шоу, которое must go on, забавляет и развлекает.

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

BTW, если интересно, вот еще моих мыслей на тему D, его прошлого и будущего: http://eao197.blogspot.com/2013/11/progflame-d-lor.html

Т.е. вы хотите сказать, что живете в 2007-2008 году? Или все-таки следите за языком?

Дело в том, что если вы просто с попкорном наблюдаете за «новыми любителями D» пользуясь своими воспоминаниями как оно было шесть-семь лет назад - значит вы не объективны, согласитесь? И ваши рассуждения не могут быть корректными, потому что они устарели. Если же вы все-таки следите за языком и в курсе последних событий, то поясните, почему вы продолжаете следить за языком несмотря на все его столь очевидные для вас недостатки? Неужели это всего лишь попытка обосновать когда-то принятое решение и вызвано банальной ревностью (ну не дай бог стрельнет, а я его ругал)?

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

З.Ы. продублируйте этот пост в вашем блоге, пожалуйста

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

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

Вы же, похоже, не понимаете довольно простой вещи: есть проекты, в которых хватает своей головной боли. Усугублять которые экспериментами с нестабильным языком нет никакого смысла. Для таких проектов одна простая вещь как отсутствие официального релиза языка просто ставит на языке крест и все, без разговоров и апеляций. Рисков и так очень много, незачем их число увеличивать. Готовых языков, инструментов, фреймворков и библиотек сейчас настолько много, что даже используя язык с меньшим количеством интересных фич, чем в D, можно намного быстрее, лучше и дешевле достичь результата, чем связавшись с D.

Ну так о чем я речь и вел. Что вы разочаровались семь лет назад в языке, но продолжаете все этим семь лет ругать язык, который даже уже не знаете. Да, вы не исключаете что он может быть и хорош, но вам не хочется проверять это самому и тратить время - именно поэтому вы посоветовали мне рекламировать язык путем публикации историй успеха. Но у меня нет цели рекламировать язык. Я не пиарщик, и не на окладе. Я всего лишь один из многих, кто пользуется языком D и не самый лучшей их представитель. Мне никто не публиковал никаких историй успеха, никто не агитировал и не уговаривал. Я просто взял и попробовал. И анонс рассчитан на таких же людей - кто в состоянии взять и попробовать.

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

Насчет того, что за D не стоит никакая корпорация - это очень хороший знак. Это значит что язык развивается обществом, и языку есть что предложить этому обществу. Да, состав участников поменялся один раз сильно, но это исключение и к тому же сообщество продолжает расти. И это сообщество по большей части первоклассных профессионалов (не имею в виду себя, к сожалению). И все они находят в языке что-то. И это не salary от крупной корпорации. Ведь все они делают на своем энтузиазме и поддерживает их в этом именно язык, а не корпорация. Имхо, это серьезный довод в пользу языка. Конечно, он может быть не годен именно к вашему проекту или применительно к вашей ситуации - но это более чем нормально. Каждый инструмент наиболее оптимален для чего-то. Ну а изменения - как человек, который следит за развитием языка скажу вам что breaking changes в языке отсутствуют и к ним относятся очень негативно.

Насчет же якобы моего непонимания скажу вам, что непонимание происходит с вашей стороны. Не стоит вам рассуждать что якобы данным анонсом я пытаюсь убедить вас использовать D в вашем проекте. Это вовсе не так. Более того, не считаете D достойным для вас языком - ради бога, не пользуйтесь им. Это же элементарно. :)

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

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

Проблема вашего восприятия данной новости в том, что:

• D не является таковым инструментом,
• вам его не пытаются продать.

Это новость для тех, кому интересно разрабатывать D и/или следить за его разработкою, кто находит себе в этом что-то полезное и приятное. Этим людям ваши скепсис, попкорн и морализаторство матёрого разработчика не нужны и не полезны нисколько. Поэтому все ваши (и не только) комментарии по сути являются оффтопиком.

Если уж о готовности к применению, D --- самый готовый из «новых» языков типа D, Go, Rust, Vala и др. Go официально выпущен (как и D1, кстати), но его стандартная и не только библиотека существенно уступает таковой в D. Rust и Vala --- вечно в состоянии beta.

Да не сам язык ругают. А процесс его разработки и пропаганды.

но его стандартная и не только библиотека существенно уступает таковой в D

Кстати, что там в D на счет мультипоточности, асинхронности и пр. актуальных вещей?

Поэтому если описываемая тобой система написана на rust, то сможешь. Поскольку тип может реализовывать произвольное число trait'ов.

Понятно. То есть проблемы нет?

Просто несколько расплывчатый ответ tailgunner-a смутил.

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

Под «языком D» вы и я определенно понимаем разные вещи. Похоже, для вас «язык D» — это набор языковых фич, которых в таком сочетании вы не видели раньше. Для меня «язык D» — это продукт, от которого я жду некоторого качества и стабильности.

Так вот, я не ругаю D в смысле «набора языковых фич». Я ругаю его как продукт, который все никак не может стабилизироваться. Виновата в этом команда его разработчиков и пока она не сменится, ничего не изменится.

Отсутствие корпорации за спиной, почему-то не помешало тому же Ruby развиваться совсем по другому сценарию. И даже серьезный переход от Ruby 1.8 к 1.9 и далее к 2.0 происходил совсем не так, как у D1 к D2.

Ну а то, что я столько лет обсуждаю D не показатель, поскольку:

• во-первых, в огород Java я бросаю камни чуть ли не с 1996-го и это ни о чем не говорит и ни на что не намекает;
• во-вторых, пример D — это отличное напоминание актуальности тезиса «лучшее враг хорошего». Об этом при разработке ПО нужно помнить, т.к. разработка — это компромисс между требуемым, желаемым и возможным. И нелишне об этом напоминать снова и снова на таком ярком примере, как D.

А еще безболезненно переходить в сишном проекте на С++. Тут уже вряд ли можно предложить альтернативу. D, как я понял, предлагает копипасту и исправление=) Пусть сами так переходят.

Ну так в расте не так же разве? Да и, вроде, для Д есть тулзы для автоматической генерации «обёрток».

Дополню еще

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

Чтобы оценить возможности такого языка, как D, мне достаточно просмотреть по диагонали его описание, благо опыт позволяет.

Success stories мне интересны потому, что я на полном серьезе не понимаю, зачем язык вроде D нужен здесь и сейчас. Ну вот серьезно, не понимаю. Семь лет назад это было очевидно — прямая и непосредственная замена C++, т.к. C++ был тогда совсем в другом состоянии.

Но сейчас времена изменились. С++ идет вперед как никогда быстро. Где требуется низкий уровень и высокая производительность, сырой D ни C++, ни C не конкурент. Если где-то нужен native-код, но уровнем повыше, то опять же есть Haskell и OCaml, которые дают разработчику возможность писать совсем иначе. Сюда же, полагаю, можно добавить и Rust, если он таки родится. Чуть в стороне стоят Objective-C и Go. Если не нужен native, то есть мир JVM (Java, Scala, Ceylon, Gosu) или .NET (C#, F#). Если производительность вообще не нужна, то Python, Ruby, Erlang.

И это только то, что на слуху. Есть еще и менее известные языки, тот же Eiffel, к примеру. Или даже Fortran.

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

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

Кстати, что там в D на счет мультипоточности, асинхронности и пр. актуальных вещей?

За асинхронность не поручусь, просто потому что не лез очень глубоко. Многопоточность работает, есть 2 стандартных модуля: std.concurrency и std.parallelism. Первый отвечает за более низкоуровневые вещи, я его не трогал. Второй пригоден для распараллеливания прикладных вычисления.

Что касается актуальных вещей, то всё зависит от того, что для вас актуально. Например, UTF8, UTF16, UTF32 есть, комплексные числа есть, спецфункции, регулярные выражения, есть такая штука std.algorithm, там многое перенесено из C++ Boost.

В языке есть также удобная мне вещь --- групповые операции с массивами типа:

double[] a = new double[10];
a[] = 0.1;
a[0 .. $/2] += 0.2; 

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

Приглашений подключиться к разработке языка во всем треде я не видел. Зато видел вот такое:

Я просто взял и попробовал. И анонс рассчитан на таких же людей - кто в состоянии взять и попробовать.

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

Ну.. Там нет классов.

trait Shape {
    fn area(&self) -> float;
}

trait Circle : Shape {
    fn radius(&self) -> float;
}

А потом уже мы определяем структуру данных

struct CircleStruct {
    center: Point,
    radius: float
}

И определяем для нее реализацию нужных trait'ов:

impl Circle for CircleStruct {
    fn radius(&self) -> float {
        (self.area() / pi).sqrt()
    }
}

impl Shape for CircleStruct {
    fn area(&self) -> float {
        pi * square(self.radius)
    }
}

Фактически «наследование» Circle от Shape лишь требует, чтобы твой тип реализовывал Shape, если хочет реализовать Circle. И все... trait'ы в данном случае работают скорее как интерфейсы. Наследования «конкретных» типов в Rust нет вообще, даже одиночного. Так что и проблемы нет... Является ли такое решение приемлемым? ХЗ, я пока боюсь Rust в реальных рабочих проектах применять.

Код, который будет использовать твой Circle или Shape, не будет знать о структурах, стоящих реально за объектами. Работать он будет через дженерики, для которых указывается ограничение Circle или Shape или же через ссылки с динамической диспетчеризацией.

Кстати, что там в D на счет мультипоточности, асинхронности и пр. актуальных вещей?

Вся разработка D2 ориентирована на упрощение работы с многопоточностью. Добавление в язык таких вещей, как вирусная иммутабельность серьезно упрощает работу с одними и теми же данными из несколько потоков параллельно, без необходимости синхронизации. Добавление ключевого слова shared, как я помню, служит той же цели. AFAIK, любые глобальные и статические данные в D2 автоматически делаются thread-local. А посредством ключевого слова shared разрешается доступ к этим данным из нескольких нитей. И т.д.

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

Я так понимаю ты неплохо язык знаешь? Можешь вот это прокомментировать?

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

Кстати, что там в D на счет мультипоточности, асинхронности и пр. актуальных вещей?

Большая статья на эту тему (правда от 2010 года) от Александреску: http://www.informit.com/articles/printerfriendly.aspx?p=1609144

Вот мне и интересно, для чего в этих условиях люди выбирают D.

Мне нужна была высокая точность вычислений. D поддерживает 128-битные действительные числа, может пристойно обрабатывать строки за счёт встроенного модуля регулярных выражений (нужно было грузить много данных из разных папок), имеет нужные мне спецфункции типа неполной гаммы и пусть не очень совершенный, но модуль fft. При этом работает достаточно быстро и хорошо параллелится за счёт std.parallelism. Я написал программу и посчитал нужный мне результат, мы написали статью, её приняли к печати, выйдет в декабре в журнал Нелинейная динамика (прямой ссылки пока нет, извините).

Из известных мне вариантов с нативным исполнением кода и 128 битной арифметикою есть только Fortran, я его хорошо знаю, писал на нём 7 лет, но он очень плохо разбирает строки.

Есть ещё какие-либо варианты? C/C++ не хочу, это очень не удобно работать с массивами, которые понятия не имеют о собственной длине и которые нужно руками удалять.

Ну так в расте не так же разве?

Там хуже. Но rust несколько посимпатичнее как язык. Я не вижу в D ничего такого, за что стоило бы рискнуть.

Да и, вроде, для Д есть тулзы для автоматической генерации «обёрток».

Не уверен, что они все правильно поймут в каком-то стороннем Си-коде. Вот если интегрировать такую штуку в gdc, то может и можно замутить полную совместимость с gcc.

Я так понимаю ты неплохо язык знаешь? Можешь вот это прокомментировать?

Я бы попробовал вам помочь, но не понял, честно говоря, где там код на D? Для преобразования типов нужно пользоваться to! из std.typecons, указатели вообще использовать категорически не рекомендуется. Зачем вам указатель на целые числа? Если нужен массив, пишем:

int[] p; 

double[] a = new double[10];
a[] = 0.1;
a[0 .. $/2] += 0.2; 

Правильно я понимаю, что сначала всем элементам массива присваивается значение 0.1? А вместе с инициализацией это проделать нельзя? Как-то так, например?

double[] a = new double[10]{0.1};

А потом значения элементов первой половины массива увеличивается на 0.2?

В С++ при помощи fill_n и transform не сильно сложнее получится, в принципе.

Вот если говорить как о продукте, то здесь я с вами во многом согласен. И тут отсутствие корпорации за спиной мешает выпустить полноценный релиз и держит язык в состоянии разработки. Это минус, но это уже и обсуждение совсем на другом уровне и уровне более высоком. И далеко не для всех проектов язык подходит - я бы не стал начинать на нем проект с жесткими требованиями к дедлайну. Зато проект-исследование некоторой темы, решение которой еще не известно - очень даже подходит. Как раз в силу высокого уровня языка решать такие задачи на нем проще. При этом после выработки конечного решения вы можете произвести оптимизацию. На этапе прототипирования вы можете писать так:

import std.stdio, std.algorithm, std.range;
 
enum say = (in string s) pure => s.group.map!q{ text(a[1],a[0]) }.join;
 
void main() {
    "1".recurrence!((t, n) => t[n - 1].say).take(8).writeln;
}

import core.stdc.stdio, std.math, std.conv, std.algorithm, std.array;
 
void showLookAndSay(bool showArrays)(in uint n) nothrow {
    if (n == 0) // No sequences to generate and show.
        return;
 
    enum Digit : char { nil = '\0', one = '1', two = '2', thr = '3' }
 
    // Allocate an approximate upper bound size for the array.
    static Digit* allocBuffer(in uint m) nothrow {
        immutable len = cast(size_t)(100 + 1.05 *
                                     exp(0.269 * m + 0.2686)) + 1;
        auto a = len.uninitializedArray!(Digit[]);
        printf("Allocated %d bytes.\n", a.length * Digit.sizeof);
        return a.ptr;
    }
 
    // Can't be expressed in the D type system:
    // a1 and a2 are immutable pointers to mutable data.
    auto a1 = allocBuffer(n % 2 ? n : n - 1);
    auto a2 = allocBuffer(n % 2 ? n - 1 : n);
    printf("\n");
 
    a1[0] = Digit.one;
    size_t len1 = 1;
    a1[len1] = Digit.nil;
 
    foreach (immutable i; 0 .. n - 1) {
        static if (showArrays)
            printf("%2u: %s\n", i + 1, a1);
        else
            printf("%2u: n. digits: %u\n", i + 1, len1);
        auto p1 = a1,
             p2 = a2;
 
        S0: final switch (*p1++) with (Digit) { // Initial state.
                case nil: goto END;
                case one: goto S1;
                case two: goto S2;
                case thr: goto S3;
            }
        S1: final switch (*p1++) with (Digit) {
                case nil: *p2++ = one; *p2++ = one; goto END;
                case one: goto S11;
                case two: *p2++ = one; *p2++ = one; goto S2;
                case thr: *p2++ = one; *p2++ = one; goto S3;
            }
        S2: final switch (*p1++) with (Digit) {
                case nil: *p2++ = one; *p2++ = two; goto END;
                case one: *p2++ = one; *p2++ = two; goto S1;
                case two: goto S22;
                case thr: *p2++ = one; *p2++ = two; goto S3;
            }
        S3: final switch (*p1++) with (Digit) {
                case nil: *p2++ = one; *p2++ = thr; goto END;
                case one: *p2++ = one; *p2++ = thr; goto S1;
                case two: *p2++ = one; *p2++ = thr; goto S2;
                case thr: goto S33;
            }
        S11: final switch (*p1++) with (Digit) {
                case nil: *p2++ = two; *p2++ = one; goto END;
                case one: *p2++ = thr; *p2++ = one; goto S0;
                case two: *p2++ = two; *p2++ = one; goto S2;
                case thr: *p2++ = two; *p2++ = one; goto S3;
            }
        S22: final switch (*p1++) with (Digit) {
                case nil: *p2++ = two; *p2++ = two; goto END;
                case one: *p2++ = two; *p2++ = two; goto S1;
                case two: *p2++ = thr; *p2++ = two; goto S0;
                case thr: *p2++ = two; *p2++ = two; goto S3;
            }
        S33: final switch (*p1++) with (Digit) {
                case nil: *p2++ = two; *p2++ = thr; goto END;
                case one: *p2++ = two; *p2++ = thr; goto S1;
                case two: *p2++ = two; *p2++ = thr; goto S2;
                case thr: *p2++ = thr; *p2++ = thr; goto S0;
            }
        END:
            immutable len2 = p2 - a2;
            a2[len2] = Digit.nil;
            a1.swap(a2);
            len1 = len2;
    }
 
    static if (showArrays)
        printf("%2u: %s\n", n, a1);
    else
        printf("%2u: n. digits: %u\n", n, len1);
}
 
void main(in string[] args) {
    immutable n = (args.length == 2) ? args[1].to!uint : 10;
    n.showLookAndSay!true;
}

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

Ну вот пример с главной странице rust

fn main() {
    let nums = [1, 2];
    let noms = ["Tim", "Eston", "Aaron", "Ben"];
 
    let mut odds = nums.iter().map(|&x| x * 2 - 1);
 
    for num in odds {
        do spawn {
            println!("{:s} says hello from a lightweight thread!", noms[num]);
        }
    }
}

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

Ну в Rust у каждого потока и куча своя.

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

Мы, наверное, попутались, я в Rust ничего не понимаю, я на D иногда пишу, хотя основные языки сейчас Python и FreePascal (раньше был Fortran 90).

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

Откройте для себя std::vector, умеющий все это и многое другое, а так же совместимый со всеми сишными либами.

Я так понимаю ты неплохо язык знаешь? Можешь вот это прокомментировать?

Честно сказать, я вообще с указателями в D не работаю фактически. В них нет необходимости и указатели в коде для меня признак его опасности. Низкоуровневые задачи вполне решаются с помощью слайсов. Я делал кастомный аллокатор чисто с их помощью без указателей. И уж точно такие конструкции не нужны в реальной работе - язык разработан чтобы избежать подобного. Это я к тому, что развернутый язык на твой вопрос давать не рискну, не уверен в своих знаниях - приложение действительно падает при попытке собрать код помеченный undefined behaviour, но у меня нет уверенности в причине. Если же действительно интересуешься языком, а не просто хочешь меня подловить, задал бы уже давно этот вопрос в группе новостей, в течении короткого времени тебе дадут очень развернутый и подробный ответ, а при необходимости еще и разложат по полочкам. Коммьюнити очень профессиональное и дружелюбное. Но это если действительно интересуешься языком, а так да - считай поймал меня на незнании некоторых моментов языка. ;)

Спасибо. Пробежался глазами - вроде вполне годно. Есть и spawn и send'ы с receive'ами. Жить можно, наверное. Надо прочесть статью.