M>Вот как раз зеленые потоки решают узкую задачу и добавляют кучу сложностей по управлению.

Согласен! Уже не впервые вижу, как попытки добавить massive concurrency не очень хорошо получаются в силу изначальной заточенности языка под последовательное исполнение.

На мой взгляд, чтобы это взлетело, концепция языка (а значит и его синтаксис, и семантика) должны существенным образом измениться. Примерно так же, как добавление асинхронности через всякие там continuations и coroutines выглядит неэлегантно в сравнении с языковой поддержкой message passing.

scf> Решения именно этой проблемы я жду от project loom.

Как по мне так отличный повод взглянуть на Elixir/Erlang/LFE.

НС>Что больше всего бесит в Go — создатели проигнорили почти все, что долго и больно нарабатывалось разработчиками языков десятилетиями. И с завидным энтузиазмом зашагали по старым, давно пройденным граблям. Что то они потом фиксили, но большая часть останется с Go навсегда.

Это называется "organic growth". Язык на начальной стадии своего создания должен был решать вполне конкретные проблемы — уйти от Питоно-ужаса, но при этом сохранить очень низкие требования к квалификации программиста. А дальше — стандартная ловушка, как с JavaScript, если с самого начала расчет на "низкий входной барьер", то в какой-то момент таки придется вернуть "взятую в долг" сложность (complexity).

НС>Нет конечно. В дотнете, к примеру, есть такой CancellationToken, который, как правило, передается явно во все асинхронные методы. И ты волен реализовать любую стратегию отмены и реакции на него. А вот с green threads все плохо.

Что именно плохо? Идентификатор того самого green thread и есть cancellation token. Если нужно "отменить" асинхронный вызов, просто терминируешь этот green thread, и все (внутри он может реализовать "реакцию отмены", хотя обычно это может сделать VM — освободить память, файловые дескрипторы и т.п.)

Здравствуйте, Pzz, Вы писали:
Pzz>Если ты текст фреймворка наизусть знаешь, это, наверное, самая плохая характеристика для этого фреймворка.
А по-моему — наоборот. Когда я программил на дельфи, возможность потрассироваться по исходникам VCL была бесценна. Потому, что на все случаи жизни учебников не напишешь.
Если кто-то разбирается в потрохах фреймворка, это означает, что
1. Исходники как минимум доступны
2. Фреймворк на рынке достаточно давно для того, чтобы кто-то смог пройти всю лестницу от полного нуба и до эксперта
3. Есть настолько высокий спрос на решения на основе этого фреймворка, что есть мотивация не просто использовать его в готовом виде, но и расширять и улучшать.

Здравствуйте, Sinclair, Вы писали:

Pzz>>Если ты текст фреймворка наизусть знаешь, это, наверное, самая плохая характеристика для этого фреймворка.
S>А по-моему — наоборот. Когда я программил на дельфи, возможность потрассироваться по исходникам VCL была бесценна. Потому, что на все случаи жизни учебников не напишешь.

Возможность почитать тексты — это хорошо, но вот необходимость — такое себе.

Что до образовательных целей, есть тексты и поинтереснее какого-то там фреймворка. То же ядро BSD, например.

Здравствуйте, SkyDance, Вы писали:

SD>Идентификатор того самого green thread и есть cancellation token. Если нужно "отменить" асинхронный вызов, просто терминируешь этот green thread

А с кодом, который там выполняется что происходит? Там исключение вылазит?

Здравствуйте, SkyDance, Вы писали:

SD>Это называется "organic growth". Язык на начальной стадии своего создания должен был решать вполне конкретные проблемы — уйти от Питоно-ужаса, но при этом сохранить очень низкие требования к квалификации программиста. А дальше — стандартная ловушка, как с JavaScript, если с самого начала расчет на "низкий входной барьер", то в какой-то момент таки придется вернуть "взятую в долг" сложность (complexity).

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

Здравствуйте, Pzz, Вы писали:

Pzz>Возможность почитать тексты — это хорошо, но вот необходимость — такое себе.

Исходник — лучшая документация. Возможность работать со сложным фреймворком без подробной документации — миф. А рассчитывать что с современной скоростью развития и сложностью фреймворков ты получишь подробную документацию, заменяющую исходный код — крайне наивно. Так что таки да, необходимость.

Здравствуйте, Pzz, Вы писали:

Pzz>А что значит, "лучше"? Си, видимо, "достаточно хорош", раз смог произвести такое количество практически используемых языков, созданных с большой оглядкой на него.

Во-первых, заимствование базового синтаксиса не означает, что это С произвел язык. Во-вторых причина не в том, что он как то особенно хорош, а в том что все привыкли к нему. По большому счету, от этого базового синтаксиса мало что зависит.

Здравствуйте, Pzz, Вы писали:
Pzz>Возможность почитать тексты — это хорошо, но вот необходимость — такое себе.
Тут я, конечно же, согласен. Но я так понял, что речь-то шла вовсе не о необходимости.
Pzz>Что до образовательных целей, есть тексты и поинтереснее какого-то там фреймворка. То же ядро BSD, например.
Ну, в каком-то смысле ядро BSD — это и есть фреймворк

Здравствуйте, Sinclair, Вы писали:

Pzz>>Что до образовательных целей, есть тексты и поинтереснее какого-то там фреймворка. То же ядро BSD, например.
S>Ну, в каком-то смысле ядро BSD — это и есть фреймворк

И что прекрасно, им можно пользоваться, не читая его текстов

Здравствуйте, scf, Вы писали:

scf>В том-то и дело, что 99% кода не нужно знать ни про параллелизм, ни про асинхронность. А проблема фьюч, монад и корутин в том, что если где-то внизу есть асинхронный вызов, то фьючи, как раковая опухоль, расползаются по всему приложению. И в итоге приложение набито for comprehensions-ами тогда как собственно асинхронных вызовов в нем штук 10.

Не расползаются. Оно сразу в for-comprehension идет. И с полиморфизмом высшего порядка:

class MyWebHandler[M[_]: HttpRoute: HttpProcess: Monad]() {
  val handle: M[HttpResponse] =
    for {
      body <- HttpRoute.parseJson(maxSize=10000, bodyParser)
      ...
    } yield ...
}

Обычно у веба два полиморфных конструктора и один лифт между ними, в бизнес-сервисах — только один, низкоуровневые реализуются под конкретный тип. И монада — это не только синхронность/асинхронность. Там еще неявные контексты таскаются. Я прошел путь самурая от протаскивания http request и tracing context через implicits по дереву вызовов к передаче их через монады. Помимо http request (который от клиента) я еще обычно неразобранную часть пути таскаю (потому что маршрутизация кодом и без всяких глобальных настроек). Кроме того, в монадах можно и нелокальные переходы делать (с определенным типом результата, как в http). Или там в тестах монаду на синхронную поменять (и без distributed tracing, чтобы писать заглушки зависимостей было проще).

Да и вне контекста монад for comprehension удобны. Например, jwt разбор (мы же всё велосипедим):

def checkJwt(token: String): Option[Whatever] = 
  for {
    (head, body, tail) <- chopToken(token)
    _ <- checkSignature(head, body)
    claims <- parseClaims(body)
    _ <- validateIssuedAt(claims)
    _ <- validateExpiryTime(claims)
  } yield whatever(claims)


def chopToken(tok: String): Option[(String, String, String)] =
  tok.split(":") match {
    case Array(a, b, c) => Some((a, b, c))
    case _ => None
  }

def parseClaims(body: String): Option[String] =
  for {
    raw <- decodeBase64(body)
    json <- parseAsJson(raw)
  } yield json.as[Map[String, JsonValue]]

Без for comprehension будет грустная простыня с исключениями. Обычно с исключениями совершенно разных типов. В общем, при небольшой привычке for comprehension читается так же хорошо, как и синхронный код (потому что монада — это абстракция последовательного выполнения). И вот из моей практики монады решают гораздо более широкий класс задач (и более удобно), чем решения, прибитые к конкретному механизму вроде асинхронности или там генераторов (привет python и javascript).

Здравствуйте, ·, Вы писали:

·>А чем ConcurrentHashMap с computeIfAbsent не устраивает?

Только тем что я им редко пользуюсь и он мне в голову не пришел . Я скорее про TrieMap вспомню, там нет подобного (getOrElseUpdate может операцию запускать но не сохранять результат). Спасибо за напоминание, у меня есть тут пара ситуаций, где именно ConcurrentHashMap с computeIfAbsent будет наиболее уместным.

Здравствуйте, maxkar, Вы писали:

M>Не расползаются. Оно сразу в for-comprehension идет. И с полиморфизмом высшего порядка:

Не спорю, монады и for-comprehension полезны и удобны, когда применяются по делу. Я имел в виду, что если мы имеем цепочку вызовов:
def handleRequest: Response
def checkJwt: Option[Whatever]
def parseClaims: Option[String]
def sendAudit: Unit

если вдруг захотелось сделать отправку аудита асинхронной, и чтобы код дожидался её окончания, то придется всю эту цепочку оборачивать в эффект:
def handleRequest: F[Response]
def checkJwt: F[Option[Whatever]]
def parseClaims: F[Option[String]]
def sendAudit: F[Unit]

Хотя всему этому коду совершенно не нужно знать, что где-то глубоко внизу кто-то что-то сделал асинхронно. Но придется всё переписывать на for comprehension.
Конечно, можно сказать "мы весь код пишем на эффектах" и из бага это превратится в фичу, но for comprehension при всех его преимуществах куда менее удобен, чем примитивный код с вызовами методов и if-ами.

Здравствуйте, Shmj, Вы писали:

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

Именно так. Фремворк понижает стомость входа для большинства типовых задач. Соответсвенно, снижаются требования к квалификации. Отсюда ясно, что будет скучно, если тебе нравятся сложные задачи.

Что делать — нужно идти в новые области.

Здравствуйте, Ikemefula, Вы писали:

I>Именно так. Фремворк понижает стомость входа для большинства типовых задач. Соответсвенно, снижаются требования к квалификации. Отсюда ясно, что будет скучно, если тебе нравятся сложные задачи.
I>Что делать — нужно идти в новые области.

Или так: Фреймворк избавляет от написания boilerplate code.
И позволяют быстрее решать сложные задачи.
Новые области и фреймворки — ортогональны.

Здравствуйте, Буравчик, Вы писали:

Б>Новые области и фреймворки — ортогональны.

А что за новая область, что там для тебя фремворки заготовлены? Можно пример?

Здравствуйте, sambl74, Вы писали:

ltc>>Проблема есть. Миллионы человеко-дней по всему миру тратятся на то, чтобы разобраться с очередным фреймворком, люди по сути делают одно и то же, многократно дублируя свои усилия, наступают на одинаковые грабли.

S>Подожди. Освободившихся людей куда ты денешь ?

Вопрос логичный. Будем решать проблемы по мере их поступления.
Надо ещё будет водителей и таксистов куда-то пристроить.