man!( Go => D ).basics

"Сложный" пример предлагал чуть выше, а за совсем простыми можете обратиться сюда. Пример оттуда:

auto conn = connectTCP("time-c.nist.gov", 13);
logInfo("The time is: %s", conn.readAllUTF8());

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

man!( Go => D ).basics

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

while(true) {
        c.write(buf.data);
        c.write(['\0']);
        buf.clear();
        c.readUntil(buf, ['\0'], SIZE);
    }
}

Это кусок одного очень простого теста, слегка усложнённый вариант эхо сервера. Пишет в сокет то, что получил. Что c.write, что c.readUntil — асинхронные операции, в которых произойдёт переключение волокон исполнения. С моей точки зрения Fibers — абсолютный эквивалент goroutines и, что уже субъективно, гораздо удобнее async из C#.

man!( Go => D ).basics

Про асинхронность не правда. Корутины есть (называются Fiber), кроме того есть целый фреймвёрк для асинхронного io: vibe.d

Немного размышлений и советов по оптимизации кода на С++

Совсем правильный пример конкатенации должен быть таким:
auto s = concat(s1,s2,s3);
, где concat — ленивый диапазон отсюда (https://github.com/ericniebler/range-v3), ну или из std, когда будет.
В этом случае вообще не произойдёт выделения памяти. Понятно, что если дальше нужен быстрый произвольный доступ, то всё равно лучше создать именно строку через range::copy(concat(...), s). Но если потом вы будете читать пару символов или только последовательно, то лучше оставить ленивый диапазон.

Пишем на D для Raspberry Pi

Согласен, язык не так популярен на хабре, стоило подробнее описать, зачем вообще писать на D. Восполню пробел парой ссылок на статьи на хабре:
https://habrahabr.ru/post/246623/
https://habrahabr.ru/post/224419/
https://habrahabr.ru/post/197480/
https://habrahabr.ru/post/154345/

Пишем на D для Raspberry Pi

Есть динамический биндинг OpenCL. http://code.dlang.org/packages/derelict-cl
Это просто описанный интрефейс к обычному OpenCL. Как хэдеры в сях. Аналогичная штука есть для CUDA
http://code.dlang.org/packages/derelict-cuda

Пишем на D для Raspberry Pi

Холиварный вброс, но всё же отвечу. Затем, что быстрее. Бытрее писать и внезапно быстрее работает.
Писать быстрее благодаря обилию алгоритмов, шаблонов, нормальной типизации, безопасности (в виде RAII, контрактов, тестов и сборке мусора) и кучи плюшек (http://dlang.org/ctod.html).
Быстрее работает — немного спорное утверждение. Эквивалентный код чуть медленнее, но на D не пишут как на C. Банальный пример: там, где в C будет массив или копия массива, в D будет ленивый диапазон. По моему опыту замена конкатенации строк на ленивый диапазон даёт прирост скорости 6 раз. Опыт портирования проектов с С или С++ говорит об ускорении результата. Например, в фейсбуке портировали небольшую библиотеку https://code.facebook.com/posts/729709347050548/under-the-hood-building-and-open-sourcing-flint/ D версия работает быстрее.
Чтобы повторить то, что даёт стандартная библиотека диапазонов в D, понадобится куча кода на C, который никто просто не будет писать. Писать быстрый код на D быстрее. Писать обычный код ещё быстрее.
Писать супероптимизированный код на D тоже проще, так как ничто не мешает опуститься до уровня C, пользоваться указателями и всеми низкоуровневыми оптимизациями вплоть до встроенного ассемблера. Вот только мощность шаблонов и прочих фич времени выполнения будет помогать даже на низком уровне и всем этим можно пользоваться.
Ситуаций, в которых D уступает C или C++, очень мало и с каждым днём становится всё меньше.

Пишем на D для Raspberry Pi

Бенчмарков не ставил, но не вижу причин, почему он должен отличаться от x86. Бэкенд у компиляторов одинаковый, сами языки примерно на одном уровне производительности, так что +- то же самое.

SpaceX запустила ракету Falcon 9. Посадка на платформу опять не удалась

Где-то вы тут запутались. В целом всё верно, М1 — начальная масса, М2 — конечная. Вот только откуда М1+М3+М4=const? Из соображений, что стартовая масса всегда одинаковая? Это не совсем правда, скорее М1+М3+М4<=const.
По самой формуле (М1+М3+М4)/(М2+М3) = C = e^(V/I) = const, так как e^(V/I) от массы не зависит. Так как М1/М2 = С, то (М3+М4)/М3 = С, отсюда увеличение массы топлива для посадки М3+М4 = С*М3. Это линейная зависимость. Для удельного импульса Мерлина в 2.73 км/с и скорости расстыковки в 3.4 км/с получаем С = e^1.24542 = 3,4744. То есть надо взять дополнительно в три с половиной раза больше топлива, чем нужно для посадки.

SpaceX запустила ракету Falcon 9. Посадка на платформу опять не удалась

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

SpaceX запустила ракету Falcon 9. Посадка на платформу опять не удалась

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

Возражения против принятия Coroutines с await в C++17

Не согласен с искажением термина coroutine. На компилируемом языке вполне возможны корутины. Тот же boost:coroutine или даже go. Абстракция та же самая: системных потоков мало, реальных потоков исполнения с независимыми стеками много. Это же не просто таски, обрабатываемые пулом потоков, это полноценные корутины, которые можно приостановить на середине, а потом продолжить с того же места. А поток может быть и один.
Однако предложение действительно сырое, не надо тащить чужеродные непродуманные концепции в язык. Похоже MS форсит свою реализацию, даже в свой компилятор поддержку добавили.

Ленивый список в C++

Очень рекомендую посмотреть диапазоны в D. В C++ слишком много синтаксического шума, за которым идею не так просто разглядеть. Кроме того для D гораздо больше документации, статей и примеров из реальной жизни. Для начала рекомендую http://www.tutorialspoint.com/d_programming/d_programming_ranges.htm
а так же примеры отсюда: http://dlang.org/phobos/std_range.html и отсюда: http://dlang.org/phobos/std_algorithm_iteration.html

Ленивый список в C++

Хорошая идея и реализация. Ещё бы это подружить со стремлением С++ к диапазонам https://ericniebler.github.io/std/wg21/D4128.html
То есть ваш список это же перемешанные в кучу данные и ленивые генераторы. Их можно более менее вписать в ленивые диапазоны, которые не владеют данными, если отделить хранение в обычный std::list/vector/set/… .

D std.ndslice как замена Python Numpy

я понял что допустил ошибку и сравнение оказалось не совсем корректным. iota динамически создает данные которые принимает функция sliced. И соответственно мы не трогаем память до момента последней ее релокации.

Я не совсем понимаю, почему это ошибка. В реальном коде тоже будут места, которые так оптимизируются, диапазоны для того и нужны. Если задача была протестировать поиск среднего, то iota вообще не должно было быть в бенчмарке. А так это одно из основных преимуществ диапазонов. Ленивость это фича. Не нужно считать, хранить, выделять память под сущности, которые эффективно генерируются на лету. Не так давно на С++ сталкивался с ситуацией, когда ленивый диапазон выигрывал у конкатенации строк просто за счёт ухода от аллокации. А ведь на нём как и на строке работают все алгоритмы стандартной библиотеки.
Хороший пример для обработки изображений был http://habrahabr.ru/post/218429/ Это конечно не ndslice, но хорошо раскрывает потенциал диапазонов как таковых. Особенно восхищает ситуация, когда несколько поворотов изображения дают 360 градусов, компилятор это понимает и выкидывает код вообще. Это же не просто частный случай, это демонстрация просторов для оптимизмции.

Правда Сноудена

Пожертвовавший свободой ради безопасности не заслуживает ни свободы, ни безопасности. (Бенджамин Франклин)

Почему нельзя сравнивать космические аппараты New Shepard и Falcon 9

Нет. Я как раз писал о длине именно это заблуждение. Чем! выше! центр тяжести, тем легче стабилизировать, не наоборот. Наоборот для нормального маятника, у которого центр тяжести ниже точки приложения силы. В общем случае это звучит так: чем больше расстояние от подвеса (двигателя) до центра тяжести, тем стабильнее.

Почему нельзя сравнивать космические аппараты New Shepard и Falcon 9

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

Илон Маск поздравил Джеффа Безоса и объяснил, что Dragon V2 нельзя сравнивать с New Shepard

Как раз к таким коментариям, как пишете вы. Даже в твите объяснено, что это не разница 450 и 100, а 900 и 9, если говорить об энергии. Техническую сложность проектов, думаю, можно сравнивать в том же масштабе.

Компании Blue Origin Джеффа Безоса удалось посадить первую ступень ракеты New Shepard без повреждений

Ни разу не конкурент SpaceX. Тут не идёт речи о полётах в космос. Цель чисто туристическая, поболтаться чуть-чуть в невесомости и посмотреть на землю свысока. Интересно, найдутся ли желающие попробовать такой туризм? Должно быть гораздо дешевле орбитального полёта, но и впечатления не те.