А нужны ли все эти ваши гринтреды, корутины, I/O асинхронщина

А что именно тебе не понятно в golang (касательно заявленной темы)? Покажи примеры кода.

А нужны ли эти ваши убогие тролли и школота, не осилившие конкаренси?

Достаточно воткнуть больше памяти, ядер и пользоваться ФП для эффективного утилизирования всего этого.

Для эффективного утилизирования «всего этого» отлично подходит пресс.

А нужны ли

da

А нужны ли эти ваши убогие тролли и школота, не осилившие конкаренси?

Школота как раз этим и упарывается не понимая зачем это нужно и где следует применять.

Про производительность такого подхода: Царю про 10к в надежде перевести дискуссию в конструктив (комментарий)

А ещё ты словишь проблем, если захочешь создавать нити для каждого соединения, потому что по умолчанию создать больше где-то тридцати тысяч не сможешь. Надо будет открутить лимиты во многих местах. Последний лимит в 125 тысяч на 16 гигов придётся откручивать в ядре Linux. Причём недостаточно будет просто число поменять в конфиге. Придётся патчить, так как лимит там достаточно захардкожен.

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

на современном то железе

воткнуть больше памяти, ядер

«Хоп, хипстерок,...»

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

Вот к примеру как применять идрис

https://journals.agh.edu.pl/csci/article/download/1413/1840

Ну и в книге Бреди есть глава отдельная type safe concurent programming.

Т.е. треды нужны, никуда не денешься. Другое дело что инструменты есть гораздо более удобные и мощные чем голанг и иже с ними.

Достаточно воткнуть больше памяти, ядер и пользоваться ФП для эффективного утилизирования всего этого.

Из-за людей которые так считают, gitlab + nextcloud + WordPress не влазят в 8 гб ОЗУ, ну ёлыпалы...

Ты чьих будешь?

А что именно тебе не понятно в golang

как раз голэнг и хайпают: «Горутины! каналы!» — это все костыли и не нужно в долгой перспективе: «Достаточно воткнуть больше памяти, ядер и пользоваться ФП для эффективного утилизирования всего этого».

Придётся патчить, так как лимит там достаточно захардкожен.

Это проблемы реализации. Ее можно допилить с учетом нового железа в долгосрочной перспективе.

При этом всём современные асинхронные серверы на современном железе могут выжать порядка десятка миллионов одновременных соединений.

Знаю. Но поддерживать такой код — не очень.

Так без этого на работу программистом в 2018 не берут.

Т.е. треды нужны, никуда не денешься.

Я как раз за них (нативные) и топлю.

Но поддерживать такой код — не очень.

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

Что не так?

А касаемо другой темы, но по golang — можно? Чтоб два раза не вставать.

Вот пример из тура по Go:

package main

import "fmt"

func main() {
	s := []int{2, 3, 5, 7, 11, 13}
	printSlice(s)

	// Slice the slice to give it zero length.
	s = s[:0]
	printSlice(s)

	// Extend its length.
	s = s[:4]
	printSlice(s)

	// Drop its first two values.
	s = s[2:]
	printSlice(s)
}

func printSlice(s []int) {
	fmt.Printf("len=%d cap=%d %v\n", len(s), cap(s), s)
}

И его вывод:

len=6 cap=6 [2 3 5 7 11 13]
len=0 cap=6 []
len=4 cap=6 [2 3 5 7]
len=2 cap=4 [5 7]

То, что из пустого слайса можно сделать непустой, ещё куда ни шло (хотя подташнивать начинает уже в этот момент, да). Но может мне кто-нибудь объяснить, почему при урезании слайса с конца capacity не меняется, а при урезании с начала — меняется?

Зачем усложнять рантаймы и писать нечитаемою асинхронщину?

Чтобы не орать потом «Почему я не делал сразу асинхронщину и что теперь делать с этим набором костылей?»

Асинхронщина это и есть набор костылей.

И в чём же костыльность? Хотя что это я спрашиваю, ты ж ММВ

Какой годный фброс ящитаю

Но может мне кто-нибудь объяснить, почему при урезании слайса с конца capacity не меняется, а при урезании с начала — меняется?

Так там же прямо написано:

The capacity of a slice is the number of elements in the underlying array, counting from the first element in the slice.

Асинхронщина это и есть набор костылей.

Я бы обобщил: любая программа — это набор костылей.

Невнимателен, грешен.

Тогда другой вопрос: почему при урезании с конца можно всё вернуть взад, а с начала — нельзя?

Тогда другой вопрос: почему при урезании с конца можно всё вернуть взад, а с начала — нельзя?

Потому что в структуре, описывающей слайс не хранится capacity слева (отрицательная часть).

Слайс - это структура с тремя полями - указатель на первый элемент, длина слайса и capacity. Вот из этого всё и следует.

Оно само по себе большой костыль. Весь вот этот сраный цикл с конечными автоматами и callback-ами. Гугли «callback hell». В былые времена писали с нормальными тредами, а потом началось...

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

А ты не с улицы Герцена?

Оно само по себе большой костыль. Весь вот этот сраный цикл с конечными автоматами и callback-ами. Гугли «callback hell».

А при наличии call/cc (который придумали полвека назад) никакого callback hell'а нет. Там, где нет call/cc, делают что-то типа async/await или промисы.

http://okmij.org/ftp/continuations/against-callcc.html

Это проблемы реализации. Ее можно допилить с учетом нового железа в долгосрочной перспективе.

Ну и где реализация? :-)

Мне знаком этот подход — считать, что знаешь лучшее решение. Иногда ты действительно знаешь лучшее решение, но зачастую нет. Просто что-то забываешь, или в чём-то ошибаешься. В любом случае всё решает реализация идеи. Если идея была хорошая, то реализация взлетит. Если нет — ты поймёшь, где ошибался. Win-win.

Так ведь корутины и нужны для того, чтобы было типа синхронно? Или не так?

Во времена Ильи Муромца улицы Герцена не было. Так что, да, для Илюшеньки я с улицы Герцена.

Я к тому, что надо уже прямо сейчас, начинать писать на ВУ ФП языках (очень подходящих для многопроцессорных систем) читабельный линейный код, а не выбирать говнотехнологии 60х годов с асинхронным подходом (пусть даже и засахаренном). Все это окупится довольно скоро.

Оно само по себе большой костыль

Да это мы уже поняли. Дальше тоже можно не читать:

Вся эта сраная логика с ветвлениями и циклами. Гугли «индусский код». В былые времена писали нормальные программы на 1000 строк максимум, а потом началось...

Итог: неверно, попробуй ещё раз

читабельный

Мля, они опять выходят на связь...

У вас есть дурная привычка не отвечать на неудобные вопросы.

Посему еще:

писать на ВУ ФП языках (очень подходящих для многопроцессорных систем)

Это вы в книжках вычитали про «очень подходящих» или подсмотрели где-то на практике? Где именно?

Сможете ответить?

Там, где нет call/cc, делают что-то типа async/await или промисы.

А если примисов и async/await тоже нет?

Все это окупится довольно скоро.

Я уже 10 лет это слышу.

Тогда асинхронщина представлена каким-либо принципиально новым интерфейсом, либо её вовсе нет. Очевидно же, не?

http://okmij.org/ftp/continuations/against-callcc.html

Там аргументы против неограниченного (undelimeted) call/cc. С ними я согласен. Но что-то вроде http://lisperator.net/pltut/cps-evaluator/continuations уже сильно облегчает жизнь.

А если примисов и async/await тоже нет?

Тогда как в 1С: параметр обратного вызова и всё.

нечитаемою асинхронщину?

Вангую что чел просто никогда не читал ни того ни другого сложнее хелоуворлда, потому и не знает что читаемое а что нет.

Какой «индусский код»?
Имеет место конкретная архитектурная кривизна. Эдакая попытка построить псевдомногозадачный велосипед.

Раз речь зашла про ФП, то вообще-то, Haskell как раз имеет гринтреды, корутины заменяются продолжениями, обернутыми в монаду, или теми же гринтредами, и почти все IO в Haskell асинхронное из коробки.

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

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

Пользоваться nodejs и golang дело вкуса, кому-то нравится пользоваться java, C++ или даже C#, в котором теперь асинхронщина вполне себе годна, а кто-то до сих пор пользуется С и рулит блокирующим и неблокирующим вводом вручную, это лишь механизмы. А вот то, что ты, тролололо, наверняка вкурсе, но всё же, возможно не вкурсе, что mainloop, блокирущий-неблокирующий ввод, таймеры и прочее использовали люди писавшие ещё на asm в мохнатых годах, не говоря уже про С, зачем-то говоришь только о nodejs и golang, хотя там просто сахара завезли для удобства(и то только в golang, ибо программирование на Nodejs напоминает программирование на С + glib).

архитектурная кривизна

Так в чём _именно_ эта кривизна заключается?

Нужны, если правильно сделаны. См. Erlang.

Вот этот main loop, с самопальным планировщиком(если он вообще есть).
Необходимость ручного сохранения состояний. Конечные автоматы, опять же.
Это же ни что иное, как попытка заменить механизмы ядра ОС своим велосипедом.
Да, при определённых условиях этот велосипед едет быстро, ибо лёгкий. Но он всё равно ущербный.

Да, при определённых условиях этот велосипед едет быстро, ибо лёгкий. Но он всё равно ущербный.

Т. е. хоть какое-то понимание есть? Good

попытка заменить [универсальные] механизмы ядра ОС своим [специализированным] велосипедом

Про то, что это один из методов оптимизации рассказывать ведь не надо? Все остальные заморочки(большинство, по крайней мере) тоже оттуда родом. А решение не ущербно за отсутствием достойных альтернатив - здесь ресурсов сервера, наверное, всегда не хватать будет

хоть какое-то понимание есть?

Ага. Сам проектировал и писал на си асинхронщину. И другие реализации неоднократно видел. Гемор это, лютый гемор.

А решение не ущербно за отсутствием достойных альтернатив - здесь ресурсов сервера, наверное, всегда не хватать будет

С таким стремительным ростом количества ядер, который наблюдается в последние годы, нужно бы начинать использовать другие архитектуры.
Вон, тот же Freeswitch, будучи изначально спроектированным как «heavy multi-threaded» с блокирующим I/O, довольно неплохо выстрелил, если сравнить с Asterisk-ом.