Comments 93
Я часто так делаю:
Конечно, если эта структура не экспортируется из пакета, тогда открытые методы Lock и Unlock ни к чему.
// SafeCounter is safe to use concurrently.
type SafeCounter struct {
v map[string]int
sync.Mutex
}
// Inc increments the counter for the given key.
func (c *SafeCounter) Inc(key string) {
c.Lock()
c.v[key]++
c.Unlock()
}
// Value returns the current value of the counter for the given key.
func (c *SafeCounter) Value(key string) int {
c.Lock()
defer c.Unlock()
return c.v[key]
}Конечно, если эта структура не экспортируется из пакета, тогда открытые методы Lock и Unlock ни к чему.
Полностью согласен. В примере надо было использовать композицию — единственно верная абстракция тут.
И наверное стоит использовать RWMutex. Непонятно мне лично зачем в примере статьи блокировка при получении значения. Вернее, зачем тут единая блокировка с изменением значения. Мы ж должны иметь возможность читать значение в любое число конкурентных горутин, если не происходит изменение значения.
И наверное стоит использовать RWMutex. Непонятно мне лично зачем в примере статьи блокировка при получении значения. Вернее, зачем тут единая блокировка с изменением значения. Мы ж должны иметь возможность читать значение в любое число конкурентных горутин, если не происходит изменение значения.
Но такой планировщик реализован в проекте vibe.d
Формулировка немного вводит в заблуждение — планировщик vibe.d не перемещает task/fiber между потоками. После того, как worker thread был выбран, конкретный task будет выполняться именно в нём до самого завершения. Причём это не дефект реализации, а осознанное решение, т.к. перемещение между потоками очень недружелюбно к оптимизации и кэшированию, а удобство, по большей части, мнимое.
Интересная статья!
Есть два вопроса:
есть ли в D эквивалент Go-шного race detector?
в приведенных примерах, как и сказано в статье, волокна D выполняются параллельно, в Go — конкурентно. То есть приведенные примеры не являются эквивалентными. Есть где примеры именно эквивалентных конкурентных программ Go и D.
Статья интересная, но странная. С самого начала заяввили, что вещи не эквивалентны и давай их сравнивать… Зачем? Они же о разном…
Есть два вопроса:
есть ли в D эквивалент Go-шного race detector?
в приведенных примерах, как и сказано в статье, волокна D выполняются параллельно, в Go — конкурентно. То есть приведенные примеры не являются эквивалентными. Есть где примеры именно эквивалентных конкурентных программ Go и D.
Статья интересная, но странная. С самого начала заяввили, что вещи не эквивалентны и давай их сравнивать… Зачем? Они же о разном…
Речь о такого рода сообщениях? "fatal error: all goroutines are asleep — deadlock!". Такого пока нет.
И в Go и в go.d/vide.d волокна выполняются конкурентно на фиксированном числе системных нитей. Так что примеры эквивалентны.
И в Go и в go.d/vide.d волокна выполняются конкурентно на фиксированном числе системных нитей. Так что примеры эквивалентны.
Нет, я не только о выявлении во время выполнения, но и об https://golang.org/doc/articles/race_detector.html. Он и помогает разработчикам ничего себе не отстрелить.
Выше уже написали, что планировщики не эквивалентны друг другу.
Кстати, а в какой миг viber.d решает, что пора переключиться на другой fiber внутри системного потока?
Количество системных потоков можно задавать из программы?
Выше уже написали, что планировщики не эквивалентны друг другу.
Кстати, а в какой миг viber.d решает, что пора переключиться на другой fiber внутри системного потока?
Количество системных потоков можно задавать из программы?
The race detector only finds races that happen at runtime, so it can't find races in code paths that are not executed. If your tests have incomplete coverage, you may find more races by running a binary built with -race under a realistic workload.Так себе костыль. Статические проверки надёжнее.
Выше уже написали, что планировщики не эквивалентны друг другу.Они не идентичны, но в данных примерах они действуют эквивалентно — раскидывают волокна по ограниченному набору нитей.
Кстати, а в какой миг viber.d решает, что пора переключиться на другой fiber внутри системного потока?Когда вызывается функция yield, переключающая контексты.
Количество системных потоков можно задавать из программы?Разумеется.
Вы сужаете 'эквивалентность' тут. Гошка дает управление конкурирующими горутинами и позаботится о переключении выполняющейся сейчас задачи. Программист может это сделать и в ручном режиме, но нет надобности: я знаю, что при отправке значения в канал, io операции, системном вызове или GC, планировщик позаботится о том, какую горутину выполнять следующей.
Получается, что в D управление конкурентностью 'ручное' и несколько менее изящное. Первое должно увеличивать число ошибок программистов на D при написании конкурентностью о кода.
Возможный в целом подход, но на мой взгляд более рискованный и в коде не смотрится естественно.
Получается, что в D управление конкурентностью 'ручное' и несколько менее изящное. Первое должно увеличивать число ошибок программистов на D при написании конкурентностью о кода.
Возможный в целом подход, но на мой взгляд более рискованный и в коде не смотрится естественно.
Любая кооперативная многозадачность "ручная", что в Go, что в D. В этом её единственное отличие от вытесняющей. Реализации блокирующих примитивов (каналы, мьютексы и тп) в обоих языках "вручную" вызывают yield для освобождения нити.
Однако не 'в ручную'. В Go у тебя есть планировщик и правила переключения и вытеснения.
Вопрос про количество ошибок и времени вхождения остается открытым.
Вопрос про количество ошибок и времени вхождения остается открытым.
Нету в Go никакого выстеснения, о чём вы? Я ещё раз повторяю, степень ручной работы в обоих языках одна и та же. Посмотрите примеры в статье. yield в одном из примеров — эквивалент Gosched, который вам точно также придётся вызывать вручную, например, в таком случае:
for {
select {
case <-boom:
fmt.Println("BOOM!")
return
default:
fmt.Print(".");
runtime.Gosched();
}
}Но в GO мне не нужно вызывать Goshed, я не думаю о том, что сейчас делает планировщик, в каком из тредов будет исполнена моя горутина, будет ли она "украдена" другим тредом или нет.
Я думаю о том, какая часть кода когда должна отрабатывать, оставляя реализацию "под капотом" GO. Это принципиальное отличие. (пример, как по-другому делается приведенный вами код — ниже в комментарии).
Я думаю о том, какая часть кода когда должна отрабатывать, оставляя реализацию "под капотом" GO. Это принципиальное отличие. (пример, как по-другому делается приведенный вами код — ниже в комментарии).
При кооперативной многозадачности всегда надо думать о том сколько волокно непрерывно владеет нитью.
Так что если вы реализуете тяжёлое вычисление и не вставляете периодически Goched, то рано или поздно столкнётесь с такой проблемой, что все нити будут заняты вычислениями трёх волокон, а остальным придётся ждать своего часа продолжительное время..
Ваш код делает не то же самое, а реализует совсем другой алгоритм.
Так что если вы реализуете тяжёлое вычисление и не вставляете периодически Goched, то рано или поздно столкнётесь с такой проблемой, что все нити будут заняты вычислениями трёх волокон, а остальным придётся ждать своего часа продолжительное время..
Ваш код делает не то же самое, а реализует совсем другой алгоритм.
На сколько я знаю Go может переключить на другую горутину в любой момент (если горутина работает долго и не прерывается для yield), тут плюс в том что не нужно самому вставлять yield в долгие обработки, и минус — в некоторых местах нужно использовать локи с расчетом что горутина может переключится в любой момент, а в DLang наоборот (в этом плане DLang мне больше нравится).
Ещё одна разница, горутины сами разливаются по потокам (и ядрам) в отличие от файберов в DLang. И тут тоже плюсы и минусы, плюс в том что можно нагрузить все ядра, минус — коммуникация между горутинами из разных потоков убивает производительность.
Т.е. в Dlang можно лучше затюнить, но больше кода. С другой стороны горутины в Go переключаются быстрее чем файберы в Dlang, в Go на это упор.
Ещё одна разница, горутины сами разливаются по потокам (и ядрам) в отличие от файберов в DLang. И тут тоже плюсы и минусы, плюс в том что можно нагрузить все ядра, минус — коммуникация между горутинами из разных потоков убивает производительность.
Т.е. в Dlang можно лучше затюнить, но больше кода. С другой стороны горутины в Go переключаются быстрее чем файберы в Dlang, в Go на это упор.
На сколько я знаю Go может переключить на другую горутину в любой момент
А тут говорят обратное.
Ещё одна разница, горутины сами разливаются по потокам (и ядрам) в отличие от файберов в DLang.Задачи в vibe.d работают аналогично.
Dlang можно лучше затюнить, но больше кода.Во всех примерах эквивалентного кода на D получилось меньше.
А тут говорят обратное.
Дата публикации статьи — 11 апреля 2012.
Задачи в vibe.d работают аналогично.
Огласите список популярных проектов на vibe.d, желательно с публикациями. Хотя бы уровня того самого криковатого фронтенда.
Дата публикации статьи — 11 апреля 2012Приведите статью по свежее, пожалуйста :-)
Огласите список популярных проектов на vibe.d, желательно с публикациями. Хотя бы уровня того самого криковатого фронтенда.Опять писькомерство. Ну, вот, например: www.sociomantic.com
Ну, вот, например: www.sociomantic.com
А можно opensource и чтобы было видно, кто этим пользуется (из компаний)?
Просто на Go популярные есть проекты с открытым исходным кодом, которые я могу сейчас взять и потрогать. Это Docker, InfluxDB, вот уже и CockroachDB. Да и тот же Gogs.
Кстати, а на D есть распределенные базы данных? :)
Согласен с тем, что в этом есть доля писькомерства, но все таки большое количество разнообразных популярных проектов для языка, который появился не так давно — показатель его практичности, дело явно не в легаси.
Я вижу, например, что на го даже довольно неожиданные проекты пишут.
Приведите статью по свежее, пожалуйста :-)
Я поискал, ситуация действительно изменилась с тех пор, но немного. Как раз тогда Вьюков переписал шедулер.
Вот ссылки:
https://github.com/golang/go/issues/11462
https://github.com/golang/go/issues/10958
http://morsmachine.dk/go-scheduler
Если кратко, то в го планировщик не полностью вытесняющий.
Согласен с тем, что в этом есть доля писькомерства, но все таки большое количество разнообразных популярных проектов для языка, который появился не так давно — показатель его практичности
Это очень популярное заблуждение. Практичность и вообще технологические достоинства языка имеют сравнительно малое влияние на популярность (если только он не откровенно ужасен). Решает громкое имя, агрессивный маркетинг, удачные пилотные проекты и в целом snowball effect. Комментарии в этом треде ("мало библиотек, должно быть с языком что-то не так") это только лишний раз подтверждают.
Программисты тоже люди :)
Go распиарен куда сильнее, с этим никто не спорит. Но как и любой хайп, этот вскоре закончится.
Социомантик как раз и запилил свою распределённую базу. Но как и любой коммерческий проект не особо горит желанием её оупенсорсить. А вот кто финансирует разработку всяких Gogs и CockroachDB? Очевидно, корпорация добра не плохо вложилась в продвижение языка. С тем же успехом она могла бы популяризировать любой примитивный язык. Basic, например, или JavaScript. Ой, вы только посмотрите сколько успешных проектов на JS — вот она, серебряная пуля, не эти ваши никому не нужные нишевые компилируемые языки.
Судя по ссылкам он вообще не вытесняющий. Пока горутина не разрешит — никто её с нити не снимет.
Социомантик как раз и запилил свою распределённую базу. Но как и любой коммерческий проект не особо горит желанием её оупенсорсить. А вот кто финансирует разработку всяких Gogs и CockroachDB? Очевидно, корпорация добра не плохо вложилась в продвижение языка. С тем же успехом она могла бы популяризировать любой примитивный язык. Basic, например, или JavaScript. Ой, вы только посмотрите сколько успешных проектов на JS — вот она, серебряная пуля, не эти ваши никому не нужные нишевые компилируемые языки.
Судя по ссылкам он вообще не вытесняющий. Пока горутина не разрешит — никто её с нити не снимет.
А вот кто финансирует разработку всяких Gogs и CockroachDB?
У CockroachDB 20 fulltime разработчиков и список инвесторов открыт, а в Gogs большую часть написал один разработчик Unknwon, можно у него спросить, сколько ему гугл платит.
Очевидно, корпорация добра не плохо вложилась в продвижение языка. С тем же успехом она могла бы популяризировать любой примитивный язык. Basic, например, или JavaScript.
Не очевидно. С Dart так не получилось, хотя его, в отличие от Go, усиленно пиарили.
сколько успешных проектов на JS
Legacy, отсутствие альтернатив. Плохой пример. Посмотрим, что будет, если WebAssembly выстрелит.
Социомантик как раз и запилил свою распределённую базу.
Если учитывать еще и полностью коммерческие проекты на Go, не выложенные в опенсорс, то D вообще видно не будет. Надо спросить у itoolabs, Badoo, Yandex, Uber, Dropbox, Twitch, Cloudflare, Microsoft, New Yourk Times, DigitalOcean, Disqus, Iron.io, MongoDB, SoundCloud, SpaceX (список получается уже слишком большим, аналогичного о D нет), сколько им гугл занес денег. Многие из этих компаний начали использовать Go до хайпа, когда сообщество было мало, историй успеха почти не было, а версия 1.0 только появлялась. Гугл делал язык для себя, а пиар гуглом сильно преувеличен. Кстати, можете сами посчитать упоминание о Google на https://golang.org/.
Пока горутина не разрешит — никто её с нити не снимет.Хз, я поверял так: делал лимит на 1 поток, и запускал не прерывный бесконечный цикл, и при этом соседние горутины отрабатывали.
Пример кода приведёте?
Сейчас попробовал такой код, в итоге горутины работают параллельно, даже если запустить ещё 10 горутин — кол-во потоков не увеличивается (смотрел через /proc//status), хотя лучше было-бы как-то достать ид текущего треда из Го.
При вызове функции в цикле с определенной вероятностью горутина может отпустить поток.
Если просто суммировать число в бесконечном цикле, то не отпустит точно, но такие случаи очень редки и видимо пошли на компромисс. Issue на гитхабе открыт и когда это станет критично, то исправят.
Если просто суммировать число в бесконечном цикле, то не отпустит точно, но такие случаи очень редки и видимо пошли на компромисс. Issue на гитхабе открыт и когда это станет критично, то исправят.
Ну, вот, например: www.sociomantic.com
Мы используем не vibe.d, а схожую по архитектуре, но самописную систему.
Не суть важно в данном контексте :-) Может расскажите свою историю (не)успеха? Go судя по всему выехал в основном на них.
Многовато придётся рассказывать :) Don довольно много упоминает в http://dconf.org/2014/talks/clugston.html
Что-то конкретное интересует?
Что-то конкретное интересует?
Всё интересует, может серию статей?
Всё интересует, может серию статей?
Очень неохота, такие статьи надо утверждать в отделе маркетинга и вообще возни много. Лучше подождите месяц и послушайте http://dconf.org/2016/talks/lucarella.html и http://dconf.org/2016/talks/panel2.html
Если sociomantic не использует vibe.d, то кто? :)
волокна D выполняются параллельно, в Go — конкурентно
Это неверное утверждение. В обоих языках происходит параллельное выполнение worker threads внутри которых происходит конкурентное выполнение fibers. Волокна вообще не могу выполняться параллельно сами по себе, по их определению. Разница на таком низком уровне только в том, что планировщик Go может переместить уже выполняемый fiber в другой worker thread (что создаёт иллюзию конкурентности и между goroutine), а в vibe.d соответствие неизменно.
А кто может объяснить как файберы работают? Как я понимаю они просто не все регистры процессоры загружают и из-за этого переключение контекста быстрее идет?
Что будет если файбер повис. Поток тоже повиснет?
Как вообще очередь устроена. Как программа понимает какие данные для какого файбера предназначены? И ведь нужно еще время на то чтобы нужный файбер активировать.
Что будет если файбер повис. Поток тоже повиснет?
Как вообще очередь устроена. Как программа понимает какие данные для какого файбера предназначены? И ведь нужно еще время на то чтобы нужный файбер активировать.
https://en.wikipedia.org/wiki/Cooperative_multitasking
Реализация на практике чаще всего сводится к выделению памяти для стека и регистров и коду, который переключает регистры на другой контектст. Существенное отличие от threads в том, что операционная система про них ничего не знает и контекст переключается только когда где-то в коде программы явно вызывается функция вида
Эффективность тут даже не столько в скорости переключения контекста (хотя экономить на 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.
Реализация на практике чаще всего сводится к выделению памяти для стека и регистров и коду, который переключает регистры на другой контектст. Существенное отличие от 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.
Но такой планировщик реализован в проекте vibe.d, правда синтаксис запуска параллельного потока всё ещё не столь лаконичен как в Go
Совсем не такой, от слова совсем. Для начала надо реализовать такую мелочь как динамический расширяемый стек, иначе весь смысл файберов вообще теряется. Ну и заканчивая тем, что планировщик намного сложнее и не требует ручной передачи управления, потому что все делается само с помощью рантайма и компилятора. Этим D всегда будет отличаться и не сможет догнать банально потому что Go содержит все это в своей спецификации. В особенности это касается сетевого I/O, которое, по сути, с планировщиком одно целое.
Однако, эквивалентный функционал реализуется не особо сложнее ручной реализацией цикла наблюдения.
Не реализуется. Select может ждать на любом количестве каналов, не будет жрать процессор или требовать использовать костыли в виде Sleep или условных переменных. Все потому что рантайм и планировщик все сделают сами. В том числе дадут другим горутинам работать, пока кто-то ждет на select. В этой конструкции вся суть модели конкурентности Go и простым циклом она не реализуется при всем желании.
На подумать — конкурентность Go ни капли не страдает даже в условиях, когда всего один worker thread. Более того, до 1.5 именно так и было — по-умолчанию количество потоков было равно 1. В 1.5 его стали задавать равным числу процессорных ядер.
Совсем не такой, от слова совсем.
Не вырывайте цитаты из контекста: "Все гопотоки (волокна, fibers, сопрограммы, coroutines, greenlets) выполяются кооперативно на ограниченном числе нативных потоков (нитях, threads), тем самым максимально утилизируя ядра процессора (cores). "… "такой планировщик реализован в проекте vibe.d".
Для начала надо реализовать такую мелочь как динамический расширяемый стек, иначе весь смысл файберов вообще теряется.Копировать стек при переполнении — не самая светлая идея на мой взгляд. А позволять смертельно зациклившейся в рекурсии программе отъедать до 250 мегабайт памяти под стек — вообще какая-то дичь.
В особенности это касается сетевого I/O, которое, по сути, с планировщиком одно целое.vibe.d использует асинхронный I/O. Но стандартная библиотека, да, использует синхронный.
Select может ждать на любом количестве каналов, не будет жрать процессор или требовать использовать костыли в виде Sleep или условных переменных.Да нет, ожидание нескольких каналов в Go реализуется так же бесконечным циклом: play.golang.org/p/fodHZpVaci
На подумать — конкурентность Go ни капли не страдает даже в условиях, когда всего один worker thread.В D она тоже не страдает :-)
Пример не совсем корректный. Вот так было бы лучше https://play.golang.org/p/rX7SbuOAKP
Одна горутина, один канал, один таймер. Select не нужно делать в бесконечном цикле.
Вы привели пример не ожидания нескольких каналов, в вычисления в бесконечном цикле, внутри которого есть каналы. Вычисление с циклом выносится в отдельную горутину и остается чистый select, который умеет ждать любое количество каналов.
Одна горутина, один канал, один таймер. Select не нужно делать в бесконечном цикле.
Вы привели пример не ожидания нескольких каналов, в вычисления в бесконечном цикле, внутри которого есть каналы. Вычисление с циклом выносится в отдельную горутину и остается чистый select, который умеет ждать любое количество каналов.
Мой пример показывает, что горутина будет крутиться в бесконечном цикле пожирая процессор, пока не будет остановлена либо явно через Gosched, либо неявно, через Sleep или обращение к пустому/полному каналу.
Ваш же пример просто переносит этот блокирующий цикл в другую горутину, но он также не отпустит нить, пока не завершится.
Ваш же пример просто переносит этот блокирующий цикл в другую горутину, но он также не отпустит нить, пока не завершится.
Изначальное утверждение "Select может ждать на любом количестве каналов, не будет жрать процессор или требовать использовать костыли в виде Sleep или условных переменных."
Select НЕ ЖРЕТ процессор. Собственно это и показано в более корректном примере. Select отдельно, вычисления отдельно.
Ваш пример был или "не о том" или неверен, в том смысле, что он не опровергает утверждения о том, что select способен ждать любого количества каналов, не выжирая процессор и без sleep.
Select НЕ ЖРЕТ процессор. Собственно это и показано в более корректном примере. Select отдельно, вычисления отдельно.
Ваш пример был или "не о том" или неверен, в том смысле, что он не опровергает утверждения о том, что select способен ждать любого количества каналов, не выжирая процессор и без sleep.
jin.go — отличная библиотека, но всё же select не получился. Приведённый в статье пример очень так себе. Гораздо лучше с задачей селекта справляются обычные D сообщения. С сообщениями можно писать так:
Тогда из другой задачи можно писать
Основной недостаток в том, что сообщение отправляется задаче, а не в некий канал. Передача данных реализуется через передачу владения, что быстро и безопасно. Просто не выглядит как поток или канал.
receive(
(int val) {
},
(double val) {
},
(int i, double d) {
},
(MyStruct s) {
}
);Тогда из другой задачи можно писать
tid.send(42);
tid.send(3.14);
tid.send(10, 10.0);
tid.send(MyStruct(args));Основной недостаток в том, что сообщение отправляется задаче, а не в некий канал. Передача данных реализуется через передачу владения, что быстро и безопасно. Просто не выглядит как поток или канал.
Изначально была аналогичная реализация, но с замыканиями не очень удобно работать. Например, чтобы выйти из цикла, приходится писать так:
Кроме того, селект по типу, вынуждает вводить кучу лишних типов исключительно для этого селекта. Так что ручной цикл по каналам получается в итоге проще, понятней и даёт больше гибкости.
auto quit = false;
for( !quit ){
receive(
(int val) {
},
(Quit q) {
quit = true;
}
);
}Кроме того, селект по типу, вынуждает вводить кучу лишних типов исключительно для этого селекта. Так что ручной цикл по каналам получается в итоге проще, понятней и даёт больше гибкости.
> Если вы уже наигрались с Go, устали от копипасты, ручного жонглирования мьютексами и всерьёз подумываете о приобретении протезов для рук, то позвольте предложить вашему вниманию перевод Tour of the Go с эквивалентным кодом на D и краткими пояснениями.
ну а где эквивалетная стандартная библиотека с хотябы с таким же составом и сабильностью библиотек golang.org/pkg и поддерживаемая разработчиками?
ну а где эквивалетная стандартная библиотека с хотябы с таким же составом и сабильностью библиотек golang.org/pkg и поддерживаемая разработчиками?
и где там библиотека для http сервера и клиента и шаблонов?
где библиотеки для работы с изображениями и криптографией?
где библиотеки для работы с изображениями и криптографией?
я спрашивал про стандартную библиотеку от производителя а не поделки с интернета
все ясно окончательно с эти вашим D.
все ясно окончательно с эти вашим D.
А, так вам шашечки нужны, а не ехать? :-)
я спрашивал про стандартную библиотеку от производителя а не поделки с интернета
все ясно окончательно с эти вашим C.
я спрашивал про стандартную библиотеку от производителя а не поделки с интернета
все ясно окончательно с эти вашим C++.
я спрашивал про стандартную библиотеку от производителя а не поделки с интернета
все ясно окончательно с эти вашим JS.
все ясно окончательно с эти вашим C.
я спрашивал про стандартную библиотеку от производителя а не поделки с интернета
все ясно окончательно с эти вашим C++.
я спрашивал про стандартную библиотеку от производителя а не поделки с интернета
все ясно окончательно с эти вашим JS.
работа с почтой? поддержка rpc? тоже нет?
вывод — D сферическиский язычек в вакууме — без батареек, но зато якобы красивый.
вывод — D сферическиский язычек в вакууме — без батареек, но зато якобы красивый.
Полнофункциональный драйвер для mongodb на D есть?
Который хоть кто-нибудь использует и написал об этом.
Который хоть кто-нибудь использует и написал об этом.
Gridfs, automated cluster topology discovery and maintenance, failover, pre-fetching, гибкая настройка consistency-level?
Хорошо ли протестирована библиотека? Кто ей пользуется?
Я бы не называл это полнофункциональным. Условие "Который хоть кто-нибудь использует и написал об этом." вроде бы тоже не выполняется.
А значит, нет :)
Зато на го есть. И его используют сами 10gen и это один из самых лучших драйверов для монги. Я считаю, что при разработке приложения, которое использует эту БД, логичнее выбирать Go, чем D. Как вы считаете?
Хорошо ли протестирована библиотека? Кто ей пользуется?
Authenticated connections are supported by using a URL connection string such as «mongodb://user:password@host». Note that the driver currently only supports the «MongoDB-CR» authentication mechanism. Since new MongoDB versions, starting with 3.0, default to the new «SCRAM-SHA-1» method, it is necessary to manually switch to the old method. See
stackoverflow.com/questions/29006887/mongodb-cr-authentication-failed for more information.
Я бы не называл это полнофункциональным. Условие "Который хоть кто-нибудь использует и написал об этом." вроде бы тоже не выполняется.
А значит, нет :)
Зато на го есть. И его используют сами 10gen и это один из самых лучших драйверов для монги. Я считаю, что при разработке приложения, которое использует эту БД, логичнее выбирать Go, чем D. Как вы считаете?
Я считаю, что монгу вообще не стоит использовать, но это уже совсем другая история :-)
А http2 есть?
Вроде нет.
Вроде может быть что-то в vibe.d, но я найти не смог и упоминаний нет.
Если вдруг кто-то будет писать http2 на D, не забудьте добавить в список имплементаций.
Если вдруг кто-то будет писать http2 на D, не забудьте добавить в список имплементаций.
http://code.dlang.org/packages/libhttp2
Модуль в активной разработке, сейчас идёт его интеграция в vibe.d.
Так что прямо сейчас http2 нет, но скоро будет.
Модуль в активной разработке, сейчас идёт его интеграция в vibe.d.
Так что прямо сейчас http2 нет, но скоро будет.
То есть Select реализуется простым перебором? Получается, что мы крутим вечный цикл с проверкой не пришло ли нам чего-нибудь?
Как-то много смен контекста может выйти и очень сильно выжирает проц, думаю. В Go же запустить рутину или нет решает планировщик. Что весьма удобно. Выходит, что корутины на D потяжелее горутин.
Как-то много смен контекста может выйти и очень сильно выжирает проц, думаю. В Go же запустить рутину или нет решает планировщик. Что весьма удобно. Выходит, что корутины на D потяжелее горутин.
А как по вашему планировщик это решает? ;-)
Переключение волокна — это просто смена указателя на стек. Но погонять бенчмарки, конечно, надо. :-)
Переключение волокна — это просто смена указателя на стек. Но погонять бенчмарки, конечно, надо. :-)
Как я понял, в D происходит запуск рутины, проверка наличия данных в канале и смена контекста, если нет. В Go рутина при чтении из канала и в случае отсутствия данных в нем добавляется в очередь на чтение из него. И потом, при появлении в канале данных, рутина отправляется в очередь на запуск. Ну и так далее. Select же добавляет в несколько очередей на чтение из каналов. И при отсутствии секции default планировщик запусти рутину только в случае наличия данных в одном из каналов.
Приятно видеть, что D на 3 месте. Я начал его изучать — как по мне, неплохой язык (неэкспертное мнение cppшника-самоучки).
К слову, на github 115 470 репозиториев на Go. На D же 6 985. При этом D более чем в два раза старше.
потомучто просто языки нафиг не нужны никому кроме автора и кучки энтузиастов — какие бы они красивые не были.
нужна богатая инфраструктура и стандартная либа — примеры успеха Swift, Kotlin со всей java инфраструктурой и ее богатством ну и Go естественно.
нужна богатая инфраструктура и стандартная либа — примеры успеха Swift, Kotlin со всей java инфраструктурой и ее богатством ну и Go естественно.
Я не говорил, что это ключевой фактор. Но решив написать на D, я рискую не найти либы для какого-нибудь специфичного протокола, например Diameter. При этом не вижу серьезных причин, почему качество репозиториев на D должно быть лучше.
Но решив написать на D, я рискую не найти либы для какого-нибудь специфичного протокола
Вы всегда можете подключить существующую библиотеку на языках C, C++, Objective-C.
При этом не вижу серьезных причин, почему качество репозиториев на D должно быть лучше.
> Вы всегда можете подключить существующую библиотеку на языках C, C++,
везде можно использовать C, C++,
а вот писать на одном языке позволяют только нормальные современные языки с богатой и продуманной библиотекой.
а весь красивый и уютный мирок D в вакууме рушится об реальный мир разработки ПО и вынужденное копание в стороннем коде.
— я использовал D для написания пары небольших утилит и GUI програм лет 5 назад — с тех пор никаких изменений сущесвенных в D так и не случилось. D не стал популярным.
везде можно использовать C, C++,
а вот писать на одном языке позволяют только нормальные современные языки с богатой и продуманной библиотекой.
а весь красивый и уютный мирок D в вакууме рушится об реальный мир разработки ПО и вынужденное копание в стороннем коде.
— я использовал D для написания пары небольших утилит и GUI програм лет 5 назад — с тех пор никаких изменений сущесвенных в D так и не случилось. D не стал популярным.
везде можно использовать C, C++,
Как много языков имеют ABI совместимость с C и C++, не требуют никаких прослоек, используют совместимые типы и не внедряются в систему сборки?
В каком языке вы можете просто слинковать существующую системную библиотеку и начать использовать, не подключая всяких биндингов? Мне, например, для использования простой библиотеки потребовалось всего-лишь описать её интерфейс в .di файле. Это заняло не больше, чем клон самой библиотеки с гитхаба. Для более сложных случаев есть специальная утилита htod. И нет, это не автогенератор прослоек или биндингов, это просто генератор заголовков для использования из D. Никаких накладных расходов, никаких преобразований типов.
Я видел, что предлагает Rust, знаю как пишутся плагины для node.js, активно использовал JNI, на работе пишу XS для perl, и поверьте, удобнее, чем из D c C и C++ взаимодействуют только С и С++.
вот именно сколько лет прошло — а кроме «удобного ABI» так ничего и не появилось
значит язык не так уж и хорош на деле если используют сишные libcurl odbc и прочее и не хотят делать свои имплементации на красивом D
значит язык не так уж и хорош на деле если используют сишные libcurl odbc и прочее и не хотят делать свои имплементации на красивом D
Для чего-то важного и популярного типа libcurl есть свои реализации. Тот же vibe.d. Там есть даже свой event loop, оборачивающий kqueue, epoll и win32 в общий интерфейс, называется libasync. А некоторые вещи лучше вообще не переписывать, например OpenGL. Его лучше максимально дёшево слинковать.
Ещё ABI очень важен для редких задач. Упомянутый мной выше co2mon из питона и node.js люди используют стартом отдельного процесса, с которого берут stdin и stdout. Это действительно наиболее простое решение для них. А D просто линкует библиотеку, зовёт функцию и получает данные.
D позволяет решать действительно сложные и редкие задачи просто, а Go простые задачи очень просто.
Здесь всё зависит от задач и от программистов. Те, кто писал сайтики на php могут продолжить заниматься этим на Go. Те кто закапывался в алгоритмы и оптимизации в C++ радуются D.
Ещё ABI очень важен для редких задач. Упомянутый мной выше co2mon из питона и node.js люди используют стартом отдельного процесса, с которого берут stdin и stdout. Это действительно наиболее простое решение для них. А D просто линкует библиотеку, зовёт функцию и получает данные.
D позволяет решать действительно сложные и редкие задачи просто, а Go простые задачи очень просто.
Здесь всё зависит от задач и от программистов. Те, кто писал сайтики на php могут продолжить заниматься этим на Go. Те кто закапывался в алгоритмы и оптимизации в C++ радуются D.
В Go есть встроенные решения для unit тестирования и бенчмарков. Не принято создавать пэкэдж для 1 функции.
Просто неясно, почему нужно перейти с Go на D. Корутины в D работают, судя по всему не так хорошо и просто как в go. Неизвестно насколько они дешевы. Могу ли я вместо использования паттерна Worker'ов использовать порождение корутин?
Кстати, есть ли в D какая-то замена кросс-компиляции? Вещь на самом деле удобная и нужная.
Есть ли опыт успешного применения в больших проектах в продакшене?
Да и вообще есть ли большие проекты на D?
Обобщенный код — это, конечно, удобно, но как показала практика не необходимо.
Просто неясно, почему нужно перейти с Go на D. Корутины в D работают, судя по всему не так хорошо и просто как в go. Неизвестно насколько они дешевы. Могу ли я вместо использования паттерна Worker'ов использовать порождение корутин?
Кстати, есть ли в D какая-то замена кросс-компиляции? Вещь на самом деле удобная и нужная.
Есть ли опыт успешного применения в больших проектах в продакшене?
Да и вообще есть ли большие проекты на D?
Обобщенный код — это, конечно, удобно, но как показала практика не необходимо.
Неизвестно насколько они дешевы.
Давайте потестим, выбирайте поле для битвы :-)
Могу ли я вместо использования паттерна Worker'ов использовать порождение корутин?
Не понял о чём вы.
Кстати, есть ли в D какая-то замена кросс-компиляции?
Не интересовался этим вопросом, но через LLVM должно быть можно.
Да и вообще есть ли большие проекты на D?
А есть ли большие проекты на Go?
Обобщенный код — это, конечно, удобно, но как показала практика не необходимо.Все так говорят, пока проект не погряз в копипасте.
"Все так говорят, пока проект не погряз в копипасте."
Можно примеры из мира разработки на GO?
Можно примеры из мира разработки на GO?
А есть ли большие проекты на Go?
Ниже привели примеры. Если посетить сайты данных проектов, то можно увидеть, какие крупные компании ими пользуются.
Все так говорят, пока проект не погряз в копипасте.
Знаете, за чуть менее чем десяток немалых проектов на Go я копировал только один файл с функциями для логирования и делал я это только потому, что считаю это незаслуженным для отдельного пакета. Возможно, мне повезло.
Давайте потестим, выбирайте поле для битвы :-)
Думаю для проверки эффективности корутин/каналов следует написать что-то такое http://play.golang.org/p/XX9uhAPUB9
Не знаю насколько результаты будут отражать действительность.
А сколько на D проектов уровня Docker, Kubernetes, Syncthing, etcd, InfluxDB, NSQ, Consul, Prometheus, Nomad?
Язык появился достаточно давно и если он во всем так прекрасен, то проектов должно быть много. Александреску даже в Facebook успел поработать (в котором, иронично, под проекты на go отдельное место на гитхабе выделили).
Пока что видно только vibe.d, который был уже тогда, когда только выходила первая версия го и мне рассказывали, насколько крутой D и как же я глупо поступаю, выбирая Go.
В последнее время появляются истории о переходе на go с других ЯП с одной стороны, и man!(GO => D) с другой. Кажется, я чего-то не понимаю, но первым доверяю больше, чем абстрактным словам о преимуществах.
Язык появился достаточно давно и если он во всем так прекрасен, то проектов должно быть много. Александреску даже в Facebook успел поработать (в котором, иронично, под проекты на go отдельное место на гитхабе выделили).
Пока что видно только vibe.d, который был уже тогда, когда только выходила первая версия го и мне рассказывали, насколько крутой D и как же я глупо поступаю, выбирая Go.
В последнее время появляются истории о переходе на go с других ЯП с одной стороны, и man!(GO => D) с другой. Кажется, я чего-то не понимаю, но первым доверяю больше, чем абстрактным словам о преимуществах.
А какой там у них уровень? Я про них ничего не слышал. Кроме разве что докера, который — не более, чем кривоватый фронтенд к линуксовым контейнерам.
Качество языка никак не кореллирует с его популярностью, к сожалению. Вы и сами демонстрируете это — выбираете язык не по возможностям, не по выразительности, не по скорости, не багоёмкости, а по популярности.
Качество языка никак не кореллирует с его популярностью, к сожалению. Вы и сами демонстрируете это — выбираете язык не по возможностям, не по выразительности, не по скорости, не багоёмкости, а по популярности.
У них много кода и и пользователей.
Go удобно и просто решает мои практические задачи, я на нем пишу на работе и для себя. Это получается быстро, особо с прекрасным плагином для IDEA, авторы которого (из Jetbrains) мне могут ответить в реальном времени в русском slack по го (где я в том числе нашёл место работы и где мне могут помочь с go).
Go использует огромное количество компаний, для части из них это основной язык разработки, что даёт некоторую уверенность в будущем языка. Мне регулярно (пусть и не часто) приходят на почту предложения поработать на go. Я могу послушать русский подкаст о этом языке каждую неделю, и даже поучаствовать в нем, если захочу, поделившись опытом. У меня есть много коллег, которые пишут на этом языке с опытом разработки реального проекта, который приносит деньги.
Что может предложить мне D из этого?
Go удобно и просто решает мои практические задачи, я на нем пишу на работе и для себя. Это получается быстро, особо с прекрасным плагином для IDEA, авторы которого (из Jetbrains) мне могут ответить в реальном времени в русском slack по го (где я в том числе нашёл место работы и где мне могут помочь с go).
Go использует огромное количество компаний, для части из них это основной язык разработки, что даёт некоторую уверенность в будущем языка. Мне регулярно (пусть и не часто) приходят на почту предложения поработать на go. Я могу послушать русский подкаст о этом языке каждую неделю, и даже поучаствовать в нем, если захочу, поделившись опытом. У меня есть много коллег, которые пишут на этом языке с опытом разработки реального проекта, который приносит деньги.
Что может предложить мне D из этого?
Docker — кривоватый фронтенд к линуксовым контейнерам? о_О да уж. Даже если вам чем-то не нравятся детали его реализации, вы не можете отрицать, что подход докера к поставке и развёртыванию приложений сильно упрощает эти процессы. Я помню, как лет десять назад на локальном форуме в файлообменной сети провайдера я писал инструкции по настройке Apache+PHP+MySQL, и как это было довольно геморройно. Теперь с помощью докера их можно запустить одной командой в консоли — например,
Kubernetes — это менеджер облачной инфраструктуры, etcd — распределённое строго консистентное key-value хранилище, Consul — service discovery. С другими перечисленными проектами я не сталкивался, но конкретно эти проекты (и докер, конечно же) весьма большие и используются в продакшне очень многими крупными компаниями. Ничего сравнимого на D, насколько я в курсе, нет. А ещё на Go написан gogs, с помощью которого (и с помощью докера) я поднял аналог гитхаба для личных нужд за десять минут.
Не поймите неправильно, я лично Go не очень люблю, я фанат Rust, и лет пять назад я немного писал на D и даже слал им баги в багтрекер. D мне весьма понравился, особенно по сравнению с C++, на котором я тогда тоже чуть-чуть писал. Но тогда у D, например, не было нормального пакетного менеджера, не было нормальных библиотек почти ни для чего, и были очень противные баги в компиляторе, которые долго не чинились. Поэтому лично меня не зацепило сильно. Если бы сейчас не было Rust'а, есть вероятность, что я бы писал какие-то свои проекты на D.
docker-compose up.Kubernetes — это менеджер облачной инфраструктуры, etcd — распределённое строго консистентное key-value хранилище, Consul — service discovery. С другими перечисленными проектами я не сталкивался, но конкретно эти проекты (и докер, конечно же) весьма большие и используются в продакшне очень многими крупными компаниями. Ничего сравнимого на D, насколько я в курсе, нет. А ещё на Go написан gogs, с помощью которого (и с помощью докера) я поднял аналог гитхаба для личных нужд за десять минут.
Не поймите неправильно, я лично Go не очень люблю, я фанат Rust, и лет пять назад я немного писал на D и даже слал им баги в багтрекер. D мне весьма понравился, особенно по сравнению с C++, на котором я тогда тоже чуть-чуть писал. Но тогда у D, например, не было нормального пакетного менеджера, не было нормальных библиотек почти ни для чего, и были очень противные баги в компиляторе, которые долго не чинились. Поэтому лично меня не зацепило сильно. Если бы сейчас не было Rust'а, есть вероятность, что я бы писал какие-то свои проекты на D.
Отличная статья, спасибо! Было бы неплохо еще добавлять комментарии в код для новичков.
Мне манера подачи, безотносительно к конкретным ЯП, напоминает посты вида "как из php сделать почти java", "как в delphi добавить почти async/await", и т.п.
Берем язык со своей экосистемой, пытаемся из него сделать что-то, чего он не может и не предназначен для этого, получая в лучшем случае что-то внешне похожее на уровне исходного кода, и вуаля.
Берем язык со своей экосистемой, пытаемся из него сделать что-то, чего он не может и не предназначен для этого, получая в лучшем случае что-то внешне похожее на уровне исходного кода, и вуаля.
Sign up to leave a comment.
man!( Go => D ).concurrency