В идеале ваши "сущности" стоило бы научить самих связываться с сервером. Блокировать долгими операциями go-блок не рекомендуется. Но можно найти баланс, создавайте каналы относительно количества "сущностей", например 1 канал на 10 "сущностей". Как описано в статье, количество каналов может быть любым, никакого залипания не будет, задания которым не хватило свободных тредов будут поставлены в очередь, главное что бы эта очередь своевременно просасывалась, если не хватает тредов можно посмотреть в сторону ограничения времени опроса по таймауту, либо увеличивать количество тредов и серверные мощности.
Тоже решал подобную задачу еще года 3 тому назад на nodejs, даже в мыслях не было что подобная поделка на пару часов работы, заинтересует кого-либо на хабре.
Пример Clojure показывает что наличием должной инфраструктуры, популяризации должной не добиться. Там через interop в java, доступны все богатства и мощь JVM мира. Но как видим, только небольшая прослойка ценителей ФП осторожно работают с ним или со Scala. Так что инерция мышления, самый главный враг ФП.
>Так зачем нужен clojure и чем он быстрее в написании например JavaScript, Python, Ruby или там Java/Groovy/Scala.
Быстрее в первую очередь — REPL'лом, на него и сделан акцент в статье, к сожалению в статье видимо не удалось ясно показать чем REPL Clojure удобнее остальных REPL присутствующих в других языках. Его преимущество кроется в мелких деталях завязанных на фичах языка — иммутабельность, функциональность, чистые функции и многое другое. Как эти тонкие моменты передать в статье, я не знаю, все это познается на опыте. Если вы сможете сделать подобное сравнение, пусть даже не в пользу clojure, буду рад почитать.
По синтаксису вижу в обоих вариантах — английский, поймет ли его любой Java разработчик судить не мне. Преимущества каждый выбирает для себя сам. Кому хочется динамическую типизацию с доброй функциональщиной, почему бы нет?
Если нет аллергии на динамическую типизацию, то можно было еще рассмотреть соседа по JVM — clojure. Например ленивое получение 10 четных чисел, на Clojure выглядит так: (->> (range) (filter even?) (take 10))
Спасибо за замечание к тесту. Сделал комит с соответствующим макросом. Касательно сравнения тёплого с мягким, нужно было найти баланс, между полезностью и доступностью для новичков, все таки clojure далеко не мэйнстримовый язык.
Очевидно что разработчик делает код более поддерживаемым, а инструменты которые разработчику в этом помогают не ограничены типизацией и ООП. Строгая vs динамическая типизация, ФП vs ООП, эти холивары идут уже многие годы, истина так и не найдена.
с каких пор строгая типизация делает язык программирования «сложным» и более инженерным? не выдавайте свои предпочтения ооп фанбоя за какой то объективный факт.
привет, тесты + 2 небольших сервиса в продакшене
У всех бывают опечатки, личка — отличное место куда можно сообщить о них.
В идеале ваши "сущности" стоило бы научить самих связываться с сервером. Блокировать долгими операциями go-блок не рекомендуется. Но можно найти баланс, создавайте каналы относительно количества "сущностей", например 1 канал на 10 "сущностей". Как описано в статье, количество каналов может быть любым, никакого залипания не будет, задания которым не хватило свободных тредов будут поставлены в очередь, главное что бы эта очередь своевременно просасывалась, если не хватает тредов можно посмотреть в сторону ограничения времени опроса по таймауту, либо увеличивать количество тредов и серверные мощности.
Тоже решал подобную задачу еще года 3 тому назад на nodejs, даже в мыслях не было что подобная поделка на пару часов работы, заинтересует кого-либо на хабре.
Пример Clojure показывает что наличием должной инфраструктуры, популяризации должной не добиться. Там через interop в java, доступны все богатства и мощь JVM мира. Но как видим, только небольшая прослойка ценителей ФП осторожно работают с ним или со Scala. Так что инерция мышления, самый главный враг ФП.
Отличный пример когда мощь LISP и возможности метапрограммирования, позволили на практике сберечь чудовищное количество человеко-часов разработчика.
>Так зачем нужен clojure и чем он быстрее в написании например JavaScript, Python, Ruby или там Java/Groovy/Scala.
Быстрее в первую очередь — REPL'лом, на него и сделан акцент в статье, к сожалению в статье видимо не удалось ясно показать чем REPL Clojure удобнее остальных REPL присутствующих в других языках. Его преимущество кроется в мелких деталях завязанных на фичах языка — иммутабельность, функциональность, чистые функции и многое другое. Как эти тонкие моменты передать в статье, я не знаю, все это познается на опыте. Если вы сможете сделать подобное сравнение, пусть даже не в пользу clojure, буду рад почитать.
По синтаксису вижу в обоих вариантах — английский, поймет ли его любой Java разработчик судить не мне. Преимущества каждый выбирает для себя сам. Кому хочется динамическую типизацию с доброй функциональщиной, почему бы нет?
Я за вас несомненно рад, но этот же пример есть в самой статье. Не могли бы вы адресовать ваше негодование автору?
Если нет аллергии на динамическую типизацию, то можно было еще рассмотреть соседа по JVM — clojure. Например ленивое получение 10 четных чисел, на Clojure выглядит так:
(->> (range) (filter even?) (take 10))