вы тупо всё время на устранение ошибок, которые могут возникнуть в продакшене, тратите на устранение compile-time ошибок при статической типизации. это раз.
ошибки, связанные с типизацией в продакшене обычно возникают на непокрытой тестами среде. опечатки и прочий хлам. это качество вашего кода и процесса разработки, а не проблема типизации в целом, это два.
автор не говорил, что не умеет. он указал на аппетиты по памяти. это три.
Ох, ну сколько можно. вы никогда не получите на статической типизации такой скорости разработки, как на языках с динамической типизацией, и наоборот про производительность. про инфраструктуру и сообщество я уже молчу.
Влепил автору заслуженный минус за троллинг.
так ведь о том и речь. C* не заточена под абстрактное «накопление данных», она заточена под задачи, в которых вам 100% не хватит одной машины (с PG, не с PG, не важно). просто если рано или поздно PG начнёт захлёбываться, и вам придётся выписывать кульбиты с шардингом и репликациями (и множеством сопутствующих проблем), C* позволит линейно и безотказно расширяться с помощью лишь одной команды в консоли.
Ну тут вы уж загнули. если задачу можно решить с помощью реляционных БД, то её нужно решить с помощью реляционных БД.
Я вообще не вижу смысла в инструментах типа C*, если ваш набор данных может обработать одна машина.
Вот эту вот фразу автор вообще непонятно откуда взял. В оригинале говорилось, что к концу года цена изрядно упадёт, а сейчас она такая потому, что это единичные экземпляры, тестовая партия так сказать. То есть цена для разработчиков, которые софт будут свой пилить конкретно под этот процессор, чтобы успеть выпустить его одновременно с выпуском нормальной партии.
Это вполне нормальная практика у производителей оборудования.
Я на днях тестировал производительность neo4j на графе (200 000 вершин, 3 000 000+ дуг), который сейчас обслуживает PG. Причём не Embedded Java API, а на Cypher. Это было убогое днище, neo4j был буквально на порядок хуже. Я думаю, автор просто напорол чуши с настройкой мускула.
За долгое время использования ни разу не натыкался на баги (кроме багов в своей голове с непониманием схемы работы вебсокетов). Сейчас у меня один инстанс на проекте обрабатывает больше сотни конкурентных подключений (правда, без DataStorage и синхронизации: у меня своя бизнес-логика с редисом).
А по поводу faye-rails — попробуйте без танцев с бубном получить из контроллера доступ к сессии (а между прочим, куки отправляются при websocket-хендшейке).
Олсо, совет на будущее: redis-objects — довольно гибкая и приятная вещь.
В теме с websockets-rails вы, похоже, так и не разобрались. Он сделан поверх faye, поэтому работает абсолютно также: в standalone-режиме требует запуска EM-сервера типа Thin и редиса.
писал выше: текущее решение справляется с этим не лучше.
усреднять не бесполезно. так вы охватите максимум людей, при этом оставив возможность читать самым ближним.
ошибки, связанные с типизацией в продакшене обычно возникают на непокрытой тестами среде. опечатки и прочий хлам. это качество вашего кода и процесса разработки, а не проблема типизации в целом, это два.
автор не говорил, что не умеет. он указал на аппетиты по памяти. это три.
Влепил автору заслуженный минус за троллинг.
Я вообще не вижу смысла в инструментах типа C*, если ваш набор данных может обработать одна машина.
Это вполне нормальная практика у производителей оборудования.
А по поводу faye-rails — попробуйте без танцев с бубном получить из контроллера доступ к сессии (а между прочим, куки отправляются при websocket-хендшейке).
Олсо, совет на будущее: redis-objects — довольно гибкая и приятная вещь.
.tap используется в основном для возвращения значения внутри метода:
вместо
оно не сокращает количество строк, а улучшает читаемость
Кроме выше означенных проблем, вот ещё. Назовите разницу между
a || a = b
и
a = a || b
С логической точки зрения её нет.
усреднять не бесполезно. так вы охватите максимум людей, при этом оставив возможность читать самым ближним.