SA
хотя, не он первый, не он последний. отладит своё поделие, сделает перфтесты относительно других таких же поделий на чистой скале, хайпанет, все на его либе писать будут.
Size: a a a
2020 February 05
P
он топит за перфоманс, поэтому джавовые примитивы - это хорошо. А вот убеждение, что акторы - это перфоманс и что он сможет сделать лучше, чем netty - это лечится только опытом.
Мне кажется там не на акторах всё сделано. С таким же успехом можно сказать что ZIO на акторах потому что есть zio-actors.
SA
я глубоко не копал. я увидел набор триггеров - перфоманс во главу угла, собственный класс актора (акку переизобретает наверное), нио вручную (наивняк)
P
больше всего похоже на чей-то домашний проект.
Он пишет что он автор colossus
P
colossus, по некоторым данным, самый быстрый HTTP сервер на скале, но сам не пользовался никогда: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json&l=zijunz-f&c=1
SA
ух. финагл в 4 раза быстрее http4s
SA
это довод, конечно, что он умеет писать быстрые серверы. но это же скала) финагл, например, очень стар и очен богат на функционал, он умеет практически всё. и при этом быстрый.
SA
сравнивая быстродействие, надо сравнивать еще и функционал
λ
SA
это говорит только о том, что конкуренция за звание самого быстрого в скала-экосистеме реализуется не самыми честными способами. Нужно мерять свой собственный кейс.
P
Ну я не предлагаю его использовать. Да и colossus с netty. Это всё premature optimization. Просто интересно.
SA
Python
Ну я не предлагаю его использовать. Да и colossus с netty. Это всё premature optimization. Просто интересно.
ну, код не на эффектах, обычная оптимизированная скала. если интересно, как правильно делать сетевые приложения, лучше курить финагл. его код вылизанный и документированный.
SA
https://github.com/DanSimon/scalene/blob/master/scalene/src/main/scala/scalene/http/HttpCodec.scala
> buildHeaders = new LinkedList[Header]
обычное поделие) парсинг заголовков хттп - это затратная операция, а тут линкед лист.
> buildHeaders = new LinkedList[Header]
обычное поделие) парсинг заголовков хттп - это затратная операция, а тут линкед лист.
SA
И еще на подумать. в случае refined получается, что все три модели приложения (апи, бизнес-логика, персистенс) будут использовать одни и те же типы полей, например,
LastName. Я не уверен, что это хорошая идея.λ
почему?
SA
сильная связность. при развитии приложения сущности в апи (и в базе) начнут разъезжаться с бизнес-логикой. придется либо подгонять все три модели одновременно, по сути лишая себя преимуществ раздельных моделей, либо делать разные типы в разных моделях, тогда refined теряет смысл.
SA
точнее, теряет смысл массовый refined
λ
всегда можешь сделать раздельные модели
SA
т.е. в апи - одни типы, в бизнес-логике - другие типы, в персистенсе - третьи, и у них есть некое общее подмножество?
SA
*типы полей. типы объектов доменной модели, естественно, разные