В том смысле, что «моральную оценку поступка и нанесенный вред» кто оценивает, и по какому праву выданному кем конкретно?
И куда «сообщать» хорошо, а куда — фу, — кто решает?
Вот например, если я посчитаю этот ваш комментарий — нанесением существенного морального вреда, и сообщу знакомому гопнику — это тоже нормально?
Очень это все зыбко звучит, если честно. Мне бы не хотелось жить в обществе, в котором сосед определяет нанесенный вред и не считает зазорным сообщить «кому следует», причем кому именно — определяет тоже он.
On the other hand the factor of preempting a process from execution is based on a certain number of Reductions since the last time it was selected for execution, regardless of its priority level. The reduction is a counter per process that is normally incremented by one for each function call. It is used for preempting processes and context switching them when the counter of a process reaches the maximum number of reductions. For example in Erlang/OTP R12B this maximum number was 2000 reductions.
Хотите, чтобы я вам ссылку на код дал, который это реализует?
Для этого люди придумали облака, где скейлинг динамический. Других решений нет.
Вот это утверждение.
Очередь засоряется иногда. По медиане сервис справляется. И очередь не «засоряется», а просто обработка некоторых сообщений может занять продолжительное время. Это не влияет на способность остальных потоков продолжать разгребать очередь.
На Го такой паттерн нереализуем, или реализуем очень сложно. Эрланг это делает сам. Всё.
Это осознанный выбор, который работает. И я не уверен, что ошибка.
Разгребать очередь — это не такая задача, под которую имеет смысл поддерживать свой сервис. Там бизнес-логика одинаковая, поэтому удобнее все адаптеры воткнуть в один процессор, а не выносить наружу.
Ну мы как-то выбрали модель разработки посередине между монолитом и микросервисами (возможно, это архитектурно не совсем верно, но так по многим параметрам удобнее поддерживать). Каждый из таких миддл-сервисов отвечает скорее за бизнес-процесс, а не за наш внутренний процесс.
Вот один такой миддл принимает заявки от клиентов в удобном для них формате, который может быть и очередью в брокере, и открытым вебсокетом, в который льется XML (есть клиенты, которые иначе не умеют). Вот этот поток XML рвать очень не хочется, потому что пересинхронизироваться и все такое придется в полуручном режиме (не из-за нас, ага).
Еще раз повторяю: ситуация с забитой очередью — не частая, но случается. Облако — не вариант, потому что мне нужен hot code reload, я не могу позволить сервису дропнуть активные соединения, которые могут длиться месяцами.
И у меня очередь не засоряется. Понимаете, оно работает. Невзирая на ваше авторитетное утверждение, что так не бывает. Ну, возможно, это просто мистика.
Я знаю, что ее называют preemptive. По факту, это не так. Она кооперативная.
Ясно. Звучит очень авторитетно, Джон Хьюджес И Джо Армстронг посрамлены, истина торжествует.
Есть конкретные preemption точки
Ну ёлки, просто же проверить: сделайте N+1 бесконечный цикл с печатью изнутри тела (N — число ядер), и запустите параллельно. Про какую конкретно preemtive точку в этом примере можно говорить вообще?
Я знал, что она существует.
Здесь знали, а в общем случае можете и не знать.
чтобы узнать детали реализации чего-то
Как раз, чтобы узнать детали реализации, нужно просто почитать документацию.
Я же вчера уже этот пример приводил: ну вот слушают они все какой-нибудь RabbitMQ, и тут заходят 9 тяжелых для обработки сообщений. И мы зависли, пока их не обработаем. Очередь копится (а мы не можем их даже акнуть), транзакции замерзают, мы тут работаем.
Чтобы в такой ситуации не зачахнуть, надо прям неимоверные пляски с бубном устроить. Так что нет, не без проблем.
Структуры данных одни и те же, ограничения по памяти одинаковые, подходы к параллелизации делаются разными средствами, но подход все равно один и тот же будь это реальный потоки или корутины.
Во-первых, это не так. У меня вот на эрланге приложение создает около 100 000 потоков только на старте, я посмотрю, как вы это на корутинах реализуете. Во-вторых, про ошибки компилятора не зазорно и спросить у гуру.
И, в-третьих, дело даже не в этом: я же говорю, новый use-case. Ну вот разбирать строки в языках с паттерн-матчингом — это принципиально иной подход. Рекурсия имеет смысл только в языках, где хорошо сделан TCO (и мало кто об этом знает, но в руби, например, его можно опционально включить, и про это не написано ни в одном самом толстом руководстве). Если есть виртуальная машина — то в каждом языке для нее свои заморочки. Если есть прямая работа с памятью — то освобождать ее надо по-разному. Если есть нативные биндинги к низкоуровневым языкам — везде куча подводных камней, и они разные. Если в языке есть нативный доступ к AST — а вы к этому не привыкли — вы все метапрограммирование будете делать неправильно, а в туториалах про такие вещи не пишут. И так далее.
Swift после C/Obj-C — это не другой язык, это, считай, диалект поменялся. Вот LISP → Julia — это да, смена парадигмы.
Возможно, я недостаточно хороший программист, или просто тупой, но когда человек впервые сталкивается с подобной задачей — банальных навыков недостаточно. Ну, мне — моих — недостаточно.
Вопрос надо сформулировать корректно, конечно, типа: «вот ьак попробовал, и так, и смог выжать только две минуты с лучшем случае».
Я вот правда не понимаю, как вы себе представляете организацию фермы виртуалов. Как они репутацию набирать будут, чтобы кому-нибудь передать, и почему это может быть легче, или удобнее, или лучше, чем просто отвечать одним пользователем и копить карму в одной корзине, если она так уж нужна?
Кроме того, насколько могу судить, в оффлайне (приглашения на работу, хедхантинг, офферы из Китая, вот это все) — смотрят не на репутацию, а на метки. Я как только вошел в hall of fame в своих языках — предложения прямо пошли, а до этого — раз в месяц в лучшем случае, хотя с репутацией все было в порядке и тогда.
И да, и нет. Синтаксиса (по крайней мере, в нашей предметной области) мало, иногда (всегда) полезнее посмотреть на существующие use-cases, проблемы, в которые упирались живые люди. Ну, там, типа «а вот что делать, если мне нужно прочитать и обработать 150 мегов из CSV не дольше, чем за минуту?». В книгах такого не напишут.
А судьи кто?
В том смысле, что «моральную оценку поступка и нанесенный вред» кто оценивает, и по какому праву выданному кем конкретно?
И куда «сообщать» хорошо, а куда — фу, — кто решает?
Вот например, если я посчитаю этот ваш комментарий — нанесением существенного морального вреда, и сообщу знакомому гопнику — это тоже нормально?
Очень это все зыбко звучит, если честно. Мне бы не хотелось жить в обществе, в котором сосед определяет нанесенный вред и не считает зазорным сообщить «кому следует», причем кому именно — определяет тоже он.
Вот Вирдинг рассказывает: https://stackoverflow.com/a/16781443/2035262
Вот простыми словами:
Хотите, чтобы я вам ссылку на код дал, который это реализует?
Вот это утверждение.
Очередь засоряется иногда. По медиане сервис справляется. И очередь не «засоряется», а просто обработка некоторых сообщений может занять продолжительное время. Это не влияет на способность остальных потоков продолжать разгребать очередь.
На Го такой паттерн нереализуем, или реализуем очень сложно. Эрланг это делает сам. Всё.
Это осознанный выбор, который работает. И я не уверен, что ошибка.
Разгребать очередь — это не такая задача, под которую имеет смысл поддерживать свой сервис. Там бизнес-логика одинаковая, поэтому удобнее все адаптеры воткнуть в один процессор, а не выносить наружу.
Ну мы как-то выбрали модель разработки посередине между монолитом и микросервисами (возможно, это архитектурно не совсем верно, но так по многим параметрам удобнее поддерживать). Каждый из таких миддл-сервисов отвечает скорее за бизнес-процесс, а не за наш внутренний процесс.
Вот один такой миддл принимает заявки от клиентов в удобном для них формате, который может быть и очередью в брокере, и открытым вебсокетом, в который льется XML (есть клиенты, которые иначе не умеют). Вот этот поток XML рвать очень не хочется, потому что пересинхронизироваться и все такое придется в полуручном режиме (не из-за нас, ага).
Еще раз повторяю: ситуация с забитой очередью — не частая, но случается. Облако — не вариант, потому что мне нужен hot code reload, я не могу позволить сервису дропнуть активные соединения, которые могут длиться месяцами.
И у меня очередь не засоряется. Понимаете, оно работает. Невзирая на ваше авторитетное утверждение, что так не бывает. Ну, возможно, это просто мистика.
Ясно. Звучит очень авторитетно, Джон Хьюджес И Джо Армстронг посрамлены, истина торжествует.
Ну ёлки, просто же проверить: сделайте N+1 бесконечный цикл с печатью изнутри тела (N — число ядер), и запустите параллельно. Про какую конкретно preemtive точку в этом примере можно говорить вообще?
Здесь знали, а в общем случае можете и не знать.
Как раз, чтобы узнать детали реализации, нужно просто почитать документацию.
s/letters/alphanumerics/g. Я и цифры тоже писал.Так-то да, пока скорость отклика на каждое конкретное сообщение не критична.
Смотрите: два клиента, одному нужно срочно разместить одну заявку, второй заслал десять раз по стопиццот заявок, и готов ждать.
Только не нужно мне предлагать докупить мощностей, пожалуйста, потому что это не решение, а прямой путь в бедное никуда.
Поток не мой, я только объяву разместил.
Даже если такая ситуация — три раза в день? Ну вот и сразу видно, что ваши опционы не зависят от расходов компании.
При том, что в эрланге такой проблемы нет.
Нет.
Нет.
По какому ключевому слову, если вы даже не подозреваете, что такая возможность существует?
Нет.
А вот в этом как раз вообще никакой проблемы не вижу: нет иллюзии, что язык похож — нет и иллюзии, что я понимаю, как на нем код писать.
Я же вчера уже этот пример приводил: ну вот слушают они все какой-нибудь RabbitMQ, и тут заходят 9 тяжелых для обработки сообщений. И мы зависли, пока их не обработаем. Очередь копится (а мы не можем их даже акнуть), транзакции замерзают, мы тут работаем.
Чтобы в такой ситуации не зачахнуть, надо прям неимоверные пляски с бубном устроить. Так что нет, не без проблем.
Во-первых, это не так. У меня вот на эрланге приложение создает около 100 000 потоков только на старте, я посмотрю, как вы это на корутинах реализуете. Во-вторых, про ошибки компилятора не зазорно и спросить у гуру.
И, в-третьих, дело даже не в этом: я же говорю, новый use-case. Ну вот разбирать строки в языках с паттерн-матчингом — это принципиально иной подход. Рекурсия имеет смысл только в языках, где хорошо сделан TCO (и мало кто об этом знает, но в руби, например, его можно опционально включить, и про это не написано ни в одном самом толстом руководстве). Если есть виртуальная машина — то в каждом языке для нее свои заморочки. Если есть прямая работа с памятью — то освобождать ее надо по-разному. Если есть нативные биндинги к низкоуровневым языкам — везде куча подводных камней, и они разные. Если в языке есть нативный доступ к AST — а вы к этому не привыкли — вы все метапрограммирование будете делать неправильно, а в туториалах про такие вещи не пишут. И так далее.
Swift после C/Obj-C — это не другой язык, это, считай, диалект поменялся. Вот LISP → Julia — это да, смена парадигмы.
Не надо, пожалуйста, говорить за всю Испанию. С госслужбы человека здесь действительно уволить непросто. Из частной конторы — только влет.
Возможно, я недостаточно хороший программист, или просто тупой, но когда человек впервые сталкивается с подобной задачей — банальных навыков недостаточно. Ну, мне — моих — недостаточно.
Вопрос надо сформулировать корректно, конечно, типа: «вот ьак попробовал, и так, и смог выжать только две минуты с лучшем случае».
Я вот правда не понимаю, как вы себе представляете организацию фермы виртуалов. Как они репутацию набирать будут, чтобы кому-нибудь передать, и почему это может быть легче, или удобнее, или лучше, чем просто отвечать одним пользователем и копить карму в одной корзине, если она так уж нужна?
Кроме того, насколько могу судить, в оффлайне (приглашения на работу, хедхантинг, офферы из Китая, вот это все) — смотрят не на репутацию, а на метки. Я как только вошел в hall of fame в своих языках — предложения прямо пошли, а до этого — раз в месяц в лучшем случае, хотя с репутацией все было в порядке и тогда.
И да, и нет. Синтаксиса (по крайней мере, в нашей предметной области) мало, иногда (всегда) полезнее посмотреть на существующие use-cases, проблемы, в которые упирались живые люди. Ну, там, типа «а вот что делать, если мне нужно прочитать и обработать 150 мегов из CSV не дольше, чем за минуту?». В книгах такого не напишут.
О, да. И что? Вы много видели виртуалов с репутацией, которую можно долго кому-нибудь передавать?
Кроме того, для виртуала — скрипт, который подождет два дня — вообще не проблема.
Вот исменно поэтому я так люблю делать код ревью ЛИСПа.
Это я понимаю, я не понимаю — почему? Что плохого в том, что я поделюсь своей репутацией в благодарность за красивый и полезный вопрос / ответ?