Нам не обязательно ждать завершения считывания данных из сокета, чтобы начать парсинг.
Мой опыт с ФП весьма ограничен, но я вот вообще не понимаю, как на нем такое вот организовать ( мы ведь возвращаем данные из функции целым куском, а не по частям ). А вот на императивном — запросто.
Но если мы хотим асинхронный сервер, то можно выстроить ф-ии в цепочки promis'ов, тут ФП тоже будет кстати.
Насколько я понимаю, в зависимости от тяжести подзадач, это может иметь как позитивный, так и негативный эффект ( из-за оверхеда task-системы ). А распаралеливание по демонам при большом количестве запросов и железо загрузит, и оверхед сведет к минимуму.
ИМХО, в первом примере у Вас каждый пункт использует результат работы предыдущего, так что даже пресловутое ФП не поможет с многопоточностью ( в этих словах нет ничего против самого использования ФП, просто многопоточность не является поводом для его использования ). Не знаю как там вообще паралелятся микросервисы, но мне кажется, что лучший вариант — реализовать саму функцию последовательно и запускать несколько демонов для ее выполнения для разных запросов.
Не знаю, где и что там Вам говорят, но у нас тут наследование используется как инструмент для реализации run-time полиморфизма. И никто ничего из реального мира не переносит, хоть результат зачастую похож на реальный мир. И то, что у любой вещи есть множество использований, Вас тоже не должно волновать — сосредоточьтесь на том использовании, которое нужно Вам.
Современные программы — не дырки, современные программы — это мраморные скульптуры. Которые, разумеется, можно быстро, удобно и надежно делать дрелью, вот только то, что при этом получится, с трудом можно будет назвать скульптурой. Разумеется, производители дрелей будут уверять всех, что дрель даже лучше, чем молоток с зубилом, и посмеиваться над гиками, которые в 2018ом пользуются «примитивными» инструментами — но ведь по сути этот хайп ничего не изменит. А вот молотку и зубилу реклама не нужна, так как, в отличие от дрели, они давно уже показали, что с их помощью можно не только сделать скульптуру, но и сделать ее качественно.
Статистически невероятно, что в большом проекте не найдется ни одной ошибки, так же как и то, что в проекте на С среди таких ошибок не будет не одной ошибки «С-шной» природы. Но, как и большинство остальных, такие ошибки допускаются по невнимательности программиста (или из-за несоблюдения best practices), и винить в них язык — все равно что винить молоток, которым Вы ударили себя по пальцу.
Откуда разработчикам компиляторов знать, какая именно мне нужна архитектура проекта и какие именно использование assert'ов? (Если конечно я не использую втупую то, что они мне навязывают.) Мне кажется, это Вы с себя как можно больше ответственности снимаете, лишь бы поменьше думать.
Ну, мне под машины бросаться тоже никто не запрещает, и все же у меня напрочь отсутствует желание жить в клетке для животных, где машина меня точно не достанет. Я к тому что при правильной архитектуре проекта и достаточном использовании run-time assert'ов ошибки, которые Вы перечислили, отлавливаются так же, как и в Java.
Ну расскажите мне про устройство современным процессоров в данном контексте.
Разница в том, модифицировать ли регистр, или память. Даже закэшированное значение модифицируется не бесплатно.
Тогда соответствующая проверка будет в логике этого аллокатора. Вы же не можете довыделить память под стек, не убедившись, что имеющаяся закончилась?
Вообще то могу) Просто проверки будут делаться на уровне ОС. Это делается правильным менеджментом виртуальной памяти. Правда, ОСшное выделение будет производиться по 4KB, что маловато, так что не факт, что такая экономия одного if'a того стоит.
Вообще, лично меня смущает то, что я так и не понял, чем именно простые стековые аллокаторы не подходят в функциональщине. Ведь по сути и речи не идет о том, что GC может быть лучше стека, лишь отстаивается то, что он может работать не сильно медленнее. Так почему бы не использовать стек, который заведомо не менее производительный, и гораздо более тривиальный в реализации?
Я говорю об аллокации/деалокации как о логической операции, а не как о вызове malloc/free или аналогичных API. При аллокации на стандартном стеке потока максимум, что может произойти — операция добавления к регистру. В описанной Вами модели при аллокации нужно как минимум модифицировать значение в памяти, а это намного дольше модификации регистра даже если каким то образом оно окажется в кэше. Уже на этом этапе GC проигрывает, а впереди еще собственно сборка мусора, которой на стеке нет вообще.
В каком смысле статически? Если в смысле того, что не понятно заранее, сколько выделять, то есть alloca. Если распределять между потоками, то кастомный стековый аллокатор и танцы с виртуальной памятью.
Вообще-то стек — это часть памяти. Когда вы пишите в стек, вы тоже пишите в память. В ту же самую память. Другой нет.
Я говорил про аллокацию/деаллокацию, а не про само использование. И кстати, это не точно та же память, а наиболее интенсивно используемая память, которая следовательно практически гарантировано будет в кэше.
Релевантных данных практически никогда нет, с-но нечего копировать.
А проверкой на то что их нет можно пренебречь? А если их нет, чем циклический аллокатор не подходит?
Ну, чтобы способ был не примитивный — вам надо реализовать алгоритм gc.
Ну GC — это как бэ не единственная альтернатива new/delete.
Ни зачем, мы же как раз и обсуждаем тот факт, что аллокация в nurcery и в стеке — это практически одно и то же.
Зачем тогда делать функциональную VM с использованием GC?
Я не очень понимаю, почему вы считаете, что С позволяет писать более качественное ПО, чем та же Java.
Потому что через С можно выразить практически все возможности процессора, а радужный мирок Java неизбежно влечет ощутимый оверхед на многие элементарный операции.
А наиболее простой, наверное, какой-нибудь Go.
Согласен, возможно Go как раз лучший выбор, хотя ИМХО лучше начинать с языка без GC.
Мой опыт с ФП весьма ограничен, но я вот вообще не понимаю, как на нем такое вот организовать ( мы ведь возвращаем данные из функции целым куском, а не по частям ). А вот на императивном — запросто.
Насколько я понимаю, в зависимости от тяжести подзадач, это может иметь как позитивный, так и негативный эффект ( из-за оверхеда task-системы ). А распаралеливание по демонам при большом количестве запросов и железо загрузит, и оверхед сведет к минимуму.
Вообще то могу) Просто проверки будут делаться на уровне ОС. Это делается правильным менеджментом виртуальной памяти. Правда, ОСшное выделение будет производиться по 4KB, что маловато, так что не факт, что такая экономия одного if'a того стоит.
Вообще, лично меня смущает то, что я так и не понял, чем именно простые стековые аллокаторы не подходят в функциональщине. Ведь по сути и речи не идет о том, что GC может быть лучше стека, лишь отстаивается то, что он может работать не сильно медленнее. Так почему бы не использовать стек, который заведомо не менее производительный, и гораздо более тривиальный в реализации?
В стандартном стеке да, но кастомный стековый аллокатор можно сделать «бесконечным» с помощью виртуальной памяти.
А проверкой на то что их нет можно пренебречь? А если их нет, чем циклический аллокатор не подходит?
Ну GC — это как бэ не единственная альтернатива new/delete.
Зачем тогда делать функциональную VM с использованием GC?
Согласен, возможно Go как раз лучший выбор, хотя ИМХО лучше начинать с языка без GC.