Отнюдь, у нас семантическое разбиение по коммитам (и читабельность их названий) является частью code review. Проблема с squash в том, что так в один коммит попадает множество не связанных между собой изменений, которые должны в истории храниться отдельно.
Тоже используем rebase модель, но без обязательного squash (чтобы история была читабельнее). Написали для этого свою консольную утилиту для работы с GH: https://github.com/sociomantic-tsunami/git-hub
Самое забавное тут то, что после изучения Rust отношение к D несколько изменилось — в плане лаконичности и выразительности последний сильно выигрывает. Впрочем, «явность» Rust-сообщество наоборот считает преимуществом. По моим ощущениям, в Rust чаще руководствуются «академической правильностью», а в D более практичный подход.
У меня после продолжительных экспериментов с Rust осталось очень похожее впечатление. Его строгость очень привлекает в больших проектах с критической важностью корректности, но затраты времени на написание простых вещей очень уж непрактичны. Вероятнее всего, даже если я решу начинать какой-либо новый проект на Rust, прототип всё равно будет написан на D.
Я для этого читал исходники :) Хотя наверняка должна быть литература по старым операционными системам (до появления многозадачности), которые использовали как раз cooperative multitasking. Fiber это всего лишь аналогичная концепция применённая в рамках одного процесса.
Согласен с тем, что в этом есть доля писькомерства, но все таки большое количество разнообразных популярных проектов для языка, который появился не так давно — показатель его практичности
Это очень популярное заблуждение. Практичность и вообще технологические достоинства языка имеют сравнительно малое влияние на популярность (если только он не откровенно ужасен). Решает громкое имя, агрессивный маркетинг, удачные пилотные проекты и в целом snowball effect. Комментарии в этом треде ("мало библиотек, должно быть с языком что-то не так") это только лишний раз подтверждают.
Программисты тоже люди :)
https://en.wikipedia.org/wiki/Cooperative_multitasking
Реализация на практике чаще всего сводится к выделению памяти для стека и регистров и коду, который переключает регистры на другой контектст. Существенное отличие от threads в том, что операционная система про них ничего не знает и контекст переключается только когда где-то в коде программы явно вызывается функция вида Fiber.yield().
Эффективность тут даже не столько в скорости переключения контекста (хотя экономить на syscalls всегда важно), сколько в количестве переключений. Равномерное распределение процессорного времени на тысячи потоков может стать причиной того, что программа проводит все время в переключениях и не выполняет полезной работы. В случае с yield, контектст будет переключен только когда программа сама посчитает это нужным.
Что будет если файбер повис. Поток тоже повиснет?
Да, поэтому системы основанные на fiber практически всегда используются в сочетании с async I/O
Как вообще очередь устроена
По разному. Концепция fiber это базовый системный примитив, который умеет только переключать контексты и больше ничего. Различные библиотеки могут реализовывать разную логику очередей на основе этого примитива. В случае с D, Fiber является частью стандартной библиотеки. А вот конкретная очередь, о которой идёт речь в статье, уже реализована в сторонней библиотеке vibe.d и основана на event loop (например, libevent).
Обычно такая библиотека также определяет абстракцию Task (например http://vibed.org/api/vibe.core.task/Task) которая использует Fiber для реализации, но также определяет такие вещи как модель передачи данных между контекстами. В некотором роде goroutine — это task в стандартном go runtime scheduler.
волокна D выполняются параллельно, в Go — конкурентно
Это неверное утверждение. В обоих языках происходит параллельное выполнение worker threads внутри которых происходит конкурентное выполнение fibers. Волокна вообще не могу выполняться параллельно сами по себе, по их определению. Разница на таком низком уровне только в том, что планировщик Go может переместить уже выполняемый fiber в другой worker thread (что создаёт иллюзию конкурентности и между goroutine), а в vibe.d соответствие неизменно.
Формулировка немного вводит в заблуждение — планировщик vibe.d не перемещает task/fiber между потоками. После того, как worker thread был выбран, конкретный task будет выполняться именно в нём до самого завершения. Причём это не дефект реализации, а осознанное решение, т.к. перемещение между потоками очень недружелюбно к оптимизации и кэшированию, а удобство, по большей части, мнимое.
Для числел с плавающей точкой требуется использовать свойство .min_normal — это сделано во избежание недопониманий о том, что это не является минимумом в том же смысле, что и у целых чисел.
Это API и реализация базового набора аллокаторов + инструментов для их композиции. Предназначены они не столько для настройки выделения памяти в библиотеках (как, например, STL allocators), сколько для реализации эффективных стратегий работы с памятью в пользовательских приложения.
Библиотеки (в идеале) должны вместо этого использовать range-based API и ленивые вычисления, чтобы откладывать принятие решений о способе аллокации как можно дольше.
Рассматривается вариант настраиваемых глобальных аллокаторов для new / delete, но я практически уверен, что это никогда не будет работать надёжно «из коробки».
Да, destroy определён таким образом специально, чтобы можно было явно вызывать деструкторы GC-объектов, не компрометируя при этом безопасность автоматического управления памятью.
Считается, что библиотеки вообще не должны выделять память каким-либо образом, оставляя это решения пользователю билиотеки, но, конечно, мало кто строго придерживается этого правила.
Делегаты выделяют память, если требуется замыкание — перенос значения со стека, если оно используется возвращаемый из функции делегатом. Без GC замыканий лучше избегать.
У меня после продолжительных экспериментов с Rust осталось очень похожее впечатление. Его строгость очень привлекает в больших проектах с критической важностью корректности, но затраты времени на написание простых вещей очень уж непрактичны. Вероятнее всего, даже если я решу начинать какой-либо новый проект на Rust, прототип всё равно будет написан на D.
Очень неохота, такие статьи надо утверждать в отделе маркетинга и вообще возни много. Лучше подождите месяц и послушайте http://dconf.org/2016/talks/lucarella.html и http://dconf.org/2016/talks/panel2.html
Что-то конкретное интересует?
Это очень популярное заблуждение. Практичность и вообще технологические достоинства языка имеют сравнительно малое влияние на популярность (если только он не откровенно ужасен). Решает громкое имя, агрессивный маркетинг, удачные пилотные проекты и в целом snowball effect. Комментарии в этом треде ("мало библиотек, должно быть с языком что-то не так") это только лишний раз подтверждают.
Программисты тоже люди :)
Мы используем не vibe.d, а схожую по архитектуре, но самописную систему.
Реализация на практике чаще всего сводится к выделению памяти для стека и регистров и коду, который переключает регистры на другой контектст. Существенное отличие от threads в том, что операционная система про них ничего не знает и контекст переключается только когда где-то в коде программы явно вызывается функция вида
Fiber.yield().Эффективность тут даже не столько в скорости переключения контекста (хотя экономить на syscalls всегда важно), сколько в количестве переключений. Равномерное распределение процессорного времени на тысячи потоков может стать причиной того, что программа проводит все время в переключениях и не выполняет полезной работы. В случае с yield, контектст будет переключен только когда программа сама посчитает это нужным.
Да, поэтому системы основанные на fiber практически всегда используются в сочетании с async I/O
По разному. Концепция fiber это базовый системный примитив, который умеет только переключать контексты и больше ничего. Различные библиотеки могут реализовывать разную логику очередей на основе этого примитива. В случае с D, Fiber является частью стандартной библиотеки. А вот конкретная очередь, о которой идёт речь в статье, уже реализована в сторонней библиотеке vibe.d и основана на event loop (например, libevent).
Обычно такая библиотека также определяет абстракцию Task (например http://vibed.org/api/vibe.core.task/Task) которая использует Fiber для реализации, но также определяет такие вещи как модель передачи данных между контекстами. В некотором роде goroutine — это task в стандартном go runtime scheduler.
Это неверное утверждение. В обоих языках происходит параллельное выполнение worker threads внутри которых происходит конкурентное выполнение fibers. Волокна вообще не могу выполняться параллельно сами по себе, по их определению. Разница на таком низком уровне только в том, что планировщик Go может переместить уже выполняемый fiber в другой worker thread (что создаёт иллюзию конкурентности и между goroutine), а в vibe.d соответствие неизменно.
Формулировка немного вводит в заблуждение — планировщик vibe.d не перемещает task/fiber между потоками. После того, как worker thread был выбран, конкретный task будет выполняться именно в нём до самого завершения. Причём это не дефект реализации, а осознанное решение, т.к. перемещение между потоками очень недружелюбно к оптимизации и кэшированию, а удобство, по большей части, мнимое.
Для числел с плавающей точкой требуется использовать свойство .min_normal — это сделано во избежание недопониманий о том, что это не является минимумом в том же смысле, что и у целых чисел.
WebAssembly выглядит хорошим шагом в этом направлении
Библиотеки (в идеале) должны вместо этого использовать range-based API и ленивые вычисления, чтобы откладывать принятие решений о способе аллокации как можно дольше.
Рассматривается вариант настраиваемых глобальных аллокаторов для new / delete, но я практически уверен, что это никогда не будет работать надёжно «из коробки».
Считается, что библиотеки вообще не должны выделять память каким-либо образом, оставляя это решения пользователю билиотеки, но, конечно, мало кто строго придерживается этого правила.