А зачем портировать в функциональный мир именно бинарную кучу? Есть несколько весьма хороших чисто функциональных подходов к организации кучи, например goo.gl/VMgdG2
Разработчики Haskell, Scala, Clojure и вскочили на подножку «мощного электровоза Java» создав свои компиляторы.
1. Haskell здесь вообще не к месту. Ни к Java, ни к JVM разрботка Haskell никогда не была привязана. И не будет, не надейтесь. Все попытки реализации хоть какого-то подобия ghc поверх JVM по понятной причине ни к чему не привели.
2. Scala / Clojure это как раз-таки пример «Java-хейтеров», как вы их назвали. Они используют JVM и байткод, но создавались именно по той причине, что у Java куча проблем (о которых в статье ни слова не сказано).
В функциональных языках это обеспечивает возможность point-free код. Композиция функций как базовая идея значительно выигрывает за счет того, что объект выполнения дейсвтия «откладывается на потом» (haskell):
sum = foldl + 0
Попробуйте написать это если "+" должен идти на последнем месте. На мой взгляд, это серьезная ошибка в дизайне языка Elixir, которая значительно ограничивает возможности написания выразительного кода.
В обработчике запроса нужно «ручками» анализировать «тип» запроса (например, /user/volch.html или /user/1.json) и вытягивать или один объект или коллекцию, или вдобавок к ним кучу всяких «лучшие темы», «последние комментарии» и т. д.
Ок, только при чем тут REST тогда? Если у вас запросы на /user/volch.html отдают коллекцию, а /user/1.json — объект, то что-то не так спроектировано (по крайней мере, с точки зрения REST resources).
так чтобы шаблон мог независящие от параметров запроса данные сам вытащить из приложения.
По описанию похоже на какой-то шаблон-driven development. Обычно наоборот делают — приложение отдает шаблону все, что нужно.
Сумбурно объяснил, но, надеюсь, понятна основная мысль, что без поддержки со стороны фреймворка чистота рест-контроллеров сильно нарушается.
Современные web-системы имеют тенденцию к decoupling на всех уровнях. Посмотрите на привычные Flask (python), Sinatra (ruby), или весь Clojure-овский стек. Есть сервер, которые выполняет базовые вещи — request/response handling. Все остальное — прикручивается дополнительно: ровно то, что вам нужно и тогда, когда вам нужно. Нужны темплейты — прикрутили. Нужны сессии пользователей — прикрутили. База или ORM — прикрутили. И т.д.
И там и там — изолированные. И там и там — с собственным scheduler-ом(ами). И там и там общение через обмен сообщениями (только механизмы адресации сообщений разные). Общий подход к обеспечению concurrency — это серьезная overlap между языками — гораздо больший, чем между go и ruby.
Меня всегда удивляют подобные комментарии. Почему сразу «слабаки! ниасилили»? Крупный и успешно развивающийся проект, почему вы считаете, что там сидят недоразвитые имбицилы, которые принимают решение на уровне «асилил/ниасилил»?
Между erlang/golang есть объективная разница (как на уровне языка, так и на уровне платформ(ы) для разработки) — у каждого свои плюсы/минусы. И даже если решение было принято не на основе этих объективных причин, а, например, на уровне «команда увереннее чувствует себя на go» (что вполне субъективно) — то в этом нет ничего плохого.
Тот же комментарий, что и выше. Я и не говорил, что это плохо. ООП без наследования теряет свою суть чуть более чем полностью. Инкапсуляция и полиморфизм касаются других парадигм не в меньшей степени (а иногда и в большей), чем ООП.
Вы не поняли, я нигде не писал «не-ооп» это плохо. Мне нравится такой подход в организации кода и я его использую. Но это не отменяет того, что семантика языка явно не предоставляет механизмы для работы «внутри» ООП парадигмы.
Естественно, вы можете и на C писать, выкручивая себе руки и голову так, чтобы воссоздать функционал классов и наследования там, где создатели языка его не предполагали. Только язык не будет помогать вам это делать, ибо у него другая семантика. Как говорится «на Pascal-e можно писать на любом императивном языке», так и «ооп можно всунуть в любом императивный язык, были бы структуры». Это не делает дизайн языка хоть сколько-нибудь ООП-шным.
(а это уже очень большая разница), golang по дизайну предначначен для написания concurrent кода с последующей параллелизацией выполнения. Последнее различие фундаментально и изначально ставит языки по разным углам. При таком количестве различий — сравнивать языки без привязки к задаче — не имеет никакого смысла. Python с Ruby можно сравнивать без контекста — потому что там общих черт больше, чем различий. А Golang намного ближе к Erlang — тут сравнение было бы конструктивным.
P.S. Предвидя возможный возражения, скажу сразу — задача «написать сервер» слишком общая. А если уже сравнивать с gevent-ом, то event-based concurrency внутри одного thread-a всегда будет уступать возможностям собственного планировщика с возможностью работать на нескольких ядрах.
В Golang возможности фреймворка Gevent заложены в дизайн самого языка.
это зависит от компилятора и интерпретатора
Интерпретируемый динамически типизированный (python) VS. компилируемый статически типизированный (golang). Более высокая скорость работы первого возможна только при повышенной криворукости разработчиков компилятора второго.
Ещё я заметил, что сторонники ООП практически никогда не выступают с критикой других парадигм.
Хорошее замечание. Но тут дело снова-таки в распрораненности. Чтобы критиковать технологию нужно хорошо в ней разбираться. ООП-программистов, которые хорошо разбираются в FP и продолжают при этом больше склоняться в сторону ООП, я не знаю. Ни одного. Хотя много пишу на функциональных языках и много общаюсь с «единодумцами». Есть очень известная цитата, не помню кого (к сожалению), «Самая большая проблема изучения ФП в том, что после его изучения сложно смириться с тем, что делают ООП языки».
А поверхностый взгляд на вопрос приводит к критике вида «все это фигня» — что не разумно считать критикой at all.
1. Haskell здесь вообще не к месту. Ни к Java, ни к JVM разрботка Haskell никогда не была привязана. И не будет, не надейтесь. Все попытки реализации хоть какого-то подобия ghc поверх JVM по понятной причине ни к чему не привели.
2. Scala / Clojure это как раз-таки пример «Java-хейтеров», как вы их назвали. Они используют JVM и байткод, но создавались именно по той причине, что у Java куча проблем (о которых в статье ни слова не сказано).
Попробуйте написать это если "+" должен идти на последнем месте. На мой взгляд, это серьезная ошибка в дизайне языка Elixir, которая значительно ограничивает возможности написания выразительного кода.
Ок, только при чем тут REST тогда? Если у вас запросы на /user/volch.html отдают коллекцию, а /user/1.json — объект, то что-то не так спроектировано (по крайней мере, с точки зрения REST resources).
По описанию похоже на какой-то шаблон-driven development. Обычно наоборот делают — приложение отдает шаблону все, что нужно.
Современные web-системы имеют тенденцию к decoupling на всех уровнях. Посмотрите на привычные Flask (python), Sinatra (ruby), или весь Clojure-овский стек. Есть сервер, которые выполняет базовые вещи — request/response handling. Все остальное — прикручивается дополнительно: ровно то, что вам нужно и тогда, когда вам нужно. Нужны темплейты — прикрутили. Нужны сессии пользователей — прикрутили. База или ORM — прикрутили. И т.д.
А чем REST для веба не устраивает?
Между erlang/golang есть объективная разница (как на уровне языка, так и на уровне платформ(ы) для разработки) — у каждого свои плюсы/минусы. И даже если решение было принято не на основе этих объективных причин, а, например, на уровне «команда увереннее чувствует себя на go» (что вполне субъективно) — то в этом нет ничего плохого.
Между этими языками просто катастрофическая разница. И помимо очевидного (python / go):
динамически типизированный / статически типизированный
интерпретируемый / компилируемый
ооп / «не-опп»
(а это уже очень большая разница), golang по дизайну предначначен для написания concurrent кода с последующей параллелизацией выполнения. Последнее различие фундаментально и изначально ставит языки по разным углам. При таком количестве различий — сравнивать языки без привязки к задаче — не имеет никакого смысла. Python с Ruby можно сравнивать без контекста — потому что там общих черт больше, чем различий. А Golang намного ближе к Erlang — тут сравнение было бы конструктивным.
P.S. Предвидя возможный возражения, скажу сразу — задача «написать сервер» слишком общая. А если уже сравнивать с gevent-ом, то event-based concurrency внутри одного thread-a всегда будет уступать возможностям собственного планировщика с возможностью работать на нескольких ядрах.
Архитектуры чего?
Benchmark-и в студию тогда. Судя по public тестам — вполне себе адекватные.
Разговор сейчас о Python/Go, а не о C++. Писать модули для Python на C/C++ — занятие достаточно геморное (повторять этот опыт уж точно не хочется).
«все это» — это «достаточно криворукие» разработчики в google и «модуль в составе boost»? Необычный подход к выбору технологии.
В Golang возможности фреймворка Gevent заложены в дизайн самого языка.
Интерпретируемый динамически типизированный (python) VS. компилируемый статически типизированный (golang). Более высокая скорость работы первого возможна только при повышенной криворукости разработчиков компилятора второго.
Хорошее замечание. Но тут дело снова-таки в распрораненности. Чтобы критиковать технологию нужно хорошо в ней разбираться. ООП-программистов, которые хорошо разбираются в FP и продолжают при этом больше склоняться в сторону ООП, я не знаю. Ни одного. Хотя много пишу на функциональных языках и много общаюсь с «единодумцами». Есть очень известная цитата, не помню кого (к сожалению), «Самая большая проблема изучения ФП в том, что после его изучения сложно смириться с тем, что делают ООП языки».
А поверхностый взгляд на вопрос приводит к критике вида «все это фигня» — что не разумно считать критикой at all.