Но меня немного смутило использование целой библиотеки (kafka streams) ради трёх строчек в декларативном стиле. Да и стиль этот, скорее, функциональный.
Спасибо за статью, жаль только, что домены телеги уже "замедлены". По идее, если совместить ваше решение с goodbyedpi или zapret, должно заработать. Еще хотелось бы иметь возможность задать свой собственный DNS - чтобы была возможность подрубить свой собственный вариант (резать рекламу, обходить геоблок)
Даже без библиотек есть узкие места. К примеру, стандартный HttpClient при работе по HTTP2 мультиплексирует ~100 запросов в одном соединении, и не открывает второе соединение автоматически. Так что при его использовании приходится либо уходить на HTTP 1, либо втыкать семафор.
Говоря про ReentrantLock я бы еще добавил, что у него есть свойство fair - если его выставить, то, например, в случае двух потоков, они будут хватать монитор поочереди (что удобно, когда стоит задача типа "заставь ноги шагать поочереди")
Также у ломбока есть аннотация Synchronized - уж можно было бы и про нее сказать, чем она лучше/хуже
Но сам GraalVM - штука спорная, имхо. Стоит прибегать, только если вообще никаких других вариантов не осталось.
Java ведь изначально задумалась как прямо противоположное тому, что делает GraalVM (один код работает везде, без разных бинарников под каждую платформу). И теперь, когда сову попытались натянуть на глобус, внезапно оказывается, что постоянно всплывают неудобные моменты.
Уж если нужен бинарник, пожалуй, стоит использовать язык, который под это и создавался. Тот же Go.
Например, что, если я захочу начать стрим последовательно, а затем распараллелить? Или наоборот?
Есть ли разница, где ставить .parallel()? Или это просто "флаг"?
Если мы собираем в коллекцию результат выполнения параллельного стрима, какой инстанс будет на выходе? Например, toList() соберёт в обычный список или потокобезопасный?
Необычная обзорная статья, спасибо.
Но меня немного смутило использование целой библиотеки (kafka streams) ради трёх строчек в декларативном стиле. Да и стиль этот, скорее, функциональный.
Интересный материал, спасибо
Может у меня какая-то Java неправильная?
И как тогда Spring в рантайме из интерфейсов репозитории создает?
На первый взгляд все красиво. Но вы так и не рассказали ни про одного шахматиста, который "прокачался" с помощью вашего POC.
Про результаты статического анализа кода - тоже ни слова.
И зачем использовать python, если код все равно пишет нейросеть?
Спасибо за интересный кейс.
С почином на Хабре!)
В разработке есть похожая тема - Bus factor
Благодарю за развернутый ответ)
Вот и нативная реклама резидентных прокси подъехала. Статья с нулем конкретики и цифр.
За сколько продались, если не секрет?
Спасибо, интересная статья.
А что скажете про использование base64 для формирования общедоступных ссылок на медиафайлы пользователя, как это сделано в "национальном мессенджере"?
Спасибо. А когда наконец появится возможность передать DNS как DoH, а не Ipv4?
Примерно так же, как локальные автомобили
Спасибо за статью, жаль только, что домены телеги уже "замедлены". По идее, если совместить ваше решение с goodbyedpi или zapret, должно заработать.
Еще хотелось бы иметь возможность задать свой собственный DNS - чтобы была возможность подрубить свой собственный вариант (резать рекламу, обходить геоблок)
В современных версиях Java есть все те же удобства, куча зрелых библиотек, а пайпы можно писать через optional или stream.
Может я чего-то недопонял из материала, но для меня как джависта серьезных причин присмотреться к этому языку не нашлось.
Спасибо за дополнение)
Даже без библиотек есть узкие места. К примеру, стандартный HttpClient при работе по HTTP2 мультиплексирует ~100 запросов в одном соединении, и не открывает второе соединение автоматически. Так что при его использовании приходится либо уходить на HTTP 1, либо втыкать семафор.
вроде как в альтернативном решении это учтено
https://github.com/telemt/telemt
Говоря про ReentrantLock я бы еще добавил, что у него есть свойство fair - если его выставить, то, например, в случае двух потоков, они будут хватать монитор поочереди (что удобно, когда стоит задача типа "заставь ноги шагать поочереди")
Также у ломбока есть аннотация Synchronized - уж можно было бы и про нее сказать, чем она лучше/хуже
Советы полезные.
Но сам GraalVM - штука спорная, имхо. Стоит прибегать, только если вообще никаких других вариантов не осталось.
Java ведь изначально задумалась как прямо противоположное тому, что делает GraalVM (один код работает везде, без разных бинарников под каждую платформу). И теперь, когда сову попытались натянуть на глобус, внезапно оказывается, что постоянно всплывают неудобные моменты.
Уж если нужен бинарник, пожалуй, стоит использовать язык, который под это и создавался. Тот же Go.
Итак, мнение дизайнера:
Посмеялся от души
Как-то не очень тема не раскрыта.
Например, что, если я захочу начать стрим последовательно, а затем распараллелить? Или наоборот?
Есть ли разница, где ставить .parallel()? Или это просто "флаг"?
Если мы собираем в коллекцию результат выполнения параллельного стрима, какой инстанс будет на выходе? Например, toList() соберёт в обычный список или потокобезопасный?