Kemet писал(а):
В Go тоже есть мониторы Хоара, но работают они, вроде, классически - на основе очередей сообщений Бринча Хансена.
Нет в golang никаких мониторов.
https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80_(%D1%81%D0%B8%D0%BD%D1%85%D1%80%D0%BE%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F)Цитата:"Монитор — в языках программирования, высокоуровневый механизм взаимодействия и синхронизации процессов, обеспечивающий доступ к
неразделяемым ресурсам.[1] Подход к синхронизации
двух или более компьютерных задач, использующих
общий ресурс, обычно
аппаратуру или
набор переменных."
Гоурутины используют общее адресное пространство (что не очень хорошо в гетерогенной ос), но не используют разделяемую память. Какое-то половинчатое решение, не? Я соглашусь, что производительность важна, но не соглашусь, что производительность выше надёжности. Это правило уже оплачено сотнями миллиардов долларов из-за переполнений стека, нарушения границ сегментов, и т. п. детскими болезнями "фигак-фигак и в продакшен"
https://ru.wikipedia.org/wiki/Go#.D0.9C.D0.BD.D0.BE.D0.B3.D0.BE.D0.BF.D0.BE.D1.82.D0.BE.D1.87.D0.BD.D0.BE.D1.81.D1.82.D1.8CЦитата:"Модель многопоточности Go была создана на основе CSP (англ.) Тони Хоара по типу предыдущих распараллеливаемых языков программирования Occam и Limbo,[4], но также присутствуют такие особенности Пи-исчисления, как
канальная передача."
Там все корутины асинхронны. Наличие или отсутствие блокировки зависит от реализованного механизма. В golang реализована лишь именно асинхронная.
Как работают подобные механизмы, я вроде как, понимаю
Книжка Танненбаума у меня есть в печатном виде)))
Kemet писал(а):
Да что-то переписывали, Plan9 или Inferno? не помню.
Ничего не переписывали. То, что есть -- на уровне лабораторной работы студента 3-4 курса. На Обероне -- есть.
Kemet писал(а):
Унификация. Как следствие меньше ошибок. Есть стандартный языковой механизм и правила его использования.
Т.е. библиотека это хуже?)))
Кемет, ну представьте себе: 8086, 80186, 80286, 80386, 80х86, х64, арм, пауэр, сан, ... И тысячи их, про которые я не имею ни малейшего понятия.
Кемет, это на полном серьёзе утверждение, что раздутый язык с жирнючим рантаймом будет так легко перенести с такими специфическими конструкциями? Может косяки вылазят именно из-за этого? (а рантайм в режиме tiny (*386*) автоматом хавает около 200 кБ, не говоря уже про gc, который хоть и подправили, но он всё-равно не позволит сделать хард реал-тайм).
Ведь, если положить руку на сердце -- в ломе ломаться нечему!!!
Вот прямо сейчас смотрю на БлэкБокс с запущенной программой дорасчёта и вижу: "Выделено памяти -- 567 кБ". Карл!!! 567 кБ!!!! ВСЕГО!!!!
Kemet писал(а):
Потому что у них нет задач, для которых куцый Оберон не подошел бы.
Так и передам Ивану: задачи твои плоские, именно поэтому ты сбежал с перла на Оберон, и я программу дорасчёта решил нарисовать из-за куцести Оберона, а то что у меня на питоне и ФриПаскале ошибки лезли -- это у меня руки кривые и черепная коробка не арийского вида.))))
https://habrahabr.ru/post/195818/ -- байка с картинками и кодом про то, что в один поток программа на golang РАБОТАЕТ БЫСТРЕЕ!!! Что там на счёт унификации? )) Рейтинг статьи +21, если что.
https://habrahabr.ru/post/195574/ -- ещё одна байка. Доставил комментарий: "Разубедили, не буду пробовать Go.". Рейтинг коммента+16.
Вот ещё от туда же хороший коммент:"Вы показали явным образом, как приложение может замедлиться из-за накладных расходов, которые возникли из-за ненужного распараллеливания задачи."
Не надо меня понимать превратно. Уж лучше golang, чем Си или С++/Java. Но это далеко не оптимальное решение, имхо.