Go выпущен в составе Google App Engine 1.5

> она прошла долгий эволюционный путь

Ну вот, то есть DC не сразу строился. Всё покажет время.

Единственно не понятно о какой «специфической инфраструктуре» в отношении Go идет речь? Компилятор в натив, две руки, две ноги — где здесь специфика относительно тех же сей?

>Java — отличный язык и платформа

жаба - инфицированный апендикс программерской мысли. Породил кучу отребья типа дотнета. не нужен.

Но да. Жаба, это платформа.

Единственно не понятно о какой «специфической инфраструктуре» в отношении Go идет речь? Компилятор в натив, две руки, две ноги — где здесь специфика относительно тех же сей?

У меня создалось впечатление, что особенности Go (включая отсутствие функционала) заточены под облачную архитектуру компании Google, с целью снизить расходы на оборудование. Возможно, я не прав — не вникал в детали языка.

К сожеалению развитие Java как языка практически остановилось а Scala не вызвала того интереса как хотелось.

жаба - инфицированный апендикс программерской мысли.

Видимо, очень серьезно инфицированный аппендикс, если после 15-и лет существования он уже делит пальму первенства по популярности с языком C (по разным метрикам). :)

А что Вы предлагаете в качестве «правильного» языка / платформы?

Go - это Limbo для обычных людей.

>А что Вы предлагаете в качестве «правильного» языка / платформы?

лисп, перл, луа.

>> Си не подходит для сравнения просто потому, что 30 лет назад, когда он занял свою нишу, поддержка исключений в языках была экзотикой.

Да, а ведь уже был PL/I...

Как Unix был упрощенным Multics, так и Си был упрощенным PL/I %)

>он же простой как валенок, что в нём инопланетного-то?

Хочу бэктрекинг! Там где хочу!:)

>лисп, перл, луа.

Ёоооо. Лисп при всей его красоте, как известно, инопланетная технология. Инопланетные платформы не предназначены для людей. Перл - самая популярная спагетти-платформа. Луа - те же скрипты, вид сбоку.

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

Там не (с)только денежки мекрософт. Что с того, что несколько человек работают в MS Research. Вот кстати - http://www.haskell.org/pipermail/libraries/2011-May/016330.html

>goroutines служит для легковесного и быстрого создания потоков, типа легких тредов в erlang.

Возможно я плохо читал но мне все же немного не понятно а кто занимается переключением этих легковесных потоков?

Шедулер. К.О.

>менеджер памяти - это, вообще-то, не только борьба с утечками

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

Поясню для непонятливых: системный шедулер или нечто внутрипрограммное?

Юзерспейсовый, иначе какой смысл был бы городить всё это? :)

Тем кто ковырял, там кооперативная или вытесняющая?

Поэтому каждый более-менее серьезный проект тащит за собой свой аллокатор. Там уж и до GC не далеко, угу.

>Юзерспейсовый, иначе какой смысл был бы городить всё это? :)

Тогда профит от такого огорода отсутствует начисто. Сначала система переключает управление на поток шедулера который, в свою очередь, передает управление одному из потоков.

По поводу кооперативной многозадачности можно сказать точно - она там есть:

The sync package provides a safe mechanism for initialization in the presence of multiple goroutines through the use of the Once type. Multiple threads can execute once.Do(f) for a particular f, but only one will run f(), and the other calls block until f() has returned.

Тогда профит от такого огорода отсутствует начисто.

Тогда нужно задаться вопросом - почему yaws, использующий юзерспейс потоки эрланга, показывает такие результаты по сравнению с apache.

Единственное что еще приходит на ум это борьба с фрагментацией

ты с эмбедщиной или с RT работал когда-нибудь?

С эмбедами работаю постоянно, но в эмбедах память стараются выделять сразу и далее никаких malloc/free не используют. Встречал реализации где free - вообще пустая функция.

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

Но каждый такой процесс должен периодически отдавать управление своему шедулеру иначе переключения не будет.

Само собой, но в erlang вытесняющая многозадачность, в отличии от go, так что тут проблем нет.

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

Там суть скорее в том, что треды ОС тяжёлые (~1,7KB), могут разделять память и переключение контекста дорогое. А самодельные на уровне VM - лёгкие (100B), ничего не разделяют (shared nothing, copy everything), и переключаются довольно просто (yield каждые 1000 редукций).

За время переключение потока системой юзерспейсовый успеет переключить сотню. Да и количество системных потоков не резиновое.

>в erlang вытесняющая многозадачность

Поскольку erlang язык интерпретируемый я бы назвал его модель многозадачности псевдовытесняющей. То есть решение о переключении управления должно приниматься каждый N-ый шаг интерпретатора поскольку по таймеру переключать задачи невозможно. Другими словами шедулер работает постоянно а не в определенные моменты времени (по прерыванию таймера). Подозреваю что реализовано это не настолько примитивно но суть та же.

Да, смена кольца на x86 занимает внушительное время но если один из процессов сделает синхронный системный вызов то все остальные процессы заморозятся. Привязать процесс к конкретному ядру так же не получится.

> псевдовытесняющей

Глупости. Каким требованиям вытесняющей многозадачности не удовлетворяет erlang?

> Привязать процесс к конкретному ядру так же не получится.

Ты не пьян, случаем?

Поскольку erlang язык интерпретируемый

Только всё-таки компилируемый (HiPE).

Но примерно так - там ориентируются на количество редукций, а не на квант времени. Переключение происходит по достижению некого количества вызовов функций (т.е. редукций) - когда в лёгком процессе вычисляются последовательно N функций совершается переход на шедуллер (их там на самом деле несколько - по количеству ядер). Получается, что шедулеру не нужно ничего кроме как знать куда «прыгнуть» когда ему передадут управление в следующий раз, а переход на шедуллер происходит автоматически, т.к. компилятор уже подоготовил шитый код.

Насчёт того почему нет блокировок (и процесс переключений не прерываются) - функции просто не могут заблокироваться, всё IO и IPC осуществляются отдельными примитивами (асинхронными сообщениями).

Привязать процесс к конкретному ядру так же не получится.

man affinity ?

Но в данном случае процесс (нативный), который прибит к ядру, это контейнер для шедуллера и его лёгких процессов (уровня VM).

но если один из процессов сделает синхронный системный вызов то все остальные процессы заморозятся.

Выше как раз написал - в ерланге это и есть «жертва» из-за которой такой профит. Никакой код просто не может сделать «синхронный системный», типа синхронного IO или FFI (к FFI там тоже специальный подход - erlang drivers). Нельзя разделять память, можно посыдать асинхронные сообщения.

В хаскеле, кстати, похожая ситуция - по факту IO, STM, мутабельность рулятся в VM.

Если по шедулеру на ядро то конечно affinity уже имеет место быть, иначе никак.

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

Возникает вопрос - можно ли написать например бесконечный цикл

А циклов там и нет :) Есть рекурсия (с TCO), она попадает под правило редукций, т.к. каждый шаг рекурсии является редукцией.

>Лисп при всей его красоте, как известно, инопланетная технология. Инопланетные платформы не предназначены для людей.

Лисп человечен, как никто другой.

Перл - самая популярная спагетти-платформа.

Перл лаконичен и выразителен. Кто же виноват, что в голове людей в основном спагетти?

Луа - те же скрипты, вид сбоку.

Вообще странное заявление. Луа многолик, прост и надежен. И только потом внедряемый интепретируемый ЯП.

А этак мы и перлы с башами не глядя прибъем...

>Поскольку erlang язык интерпретируемый

Вздор

>цикл

В эрланге нет поддержки императивной парадигмы :-)

в эмбедах память стараются выделять сразу и далее никаких malloc/free не используют

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

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

Вот сборщиков мусора не встречал. Как правило имеется список занятых блоков и список свободных. Такой подход я видел в частности в реализации USB подсистемы, но я видел не все эмбеды :)

>компилятор все равно будет эти рекурсии в циклы разворачивать

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

>Лисп человечен, как никто другой.

Лисп не человечен, Лисп сверхчеловечен.

А если было бы иначе, то он был занимал первое место в топе языков, а не си, жаба и пхп.

Ура! Go в массы!

> лисп, перл, луа.

Все три с динамической системой типов. В топку.

Ладно бы назвал Ada, C, SML, они хоть на нормальные языки издали похожи.

Хвостовая рекурсия как раз и разворачивается в цикл.