Это не столько защита от дурака, сколько возможность использовать опциональность типов. Большая часть использований Optional (Option в Scala) заменяется на nullable тип в Kotlin. Так и их использование становится проще, и в коде не создается лишних инстансов.
Ну, кстати, в этом бенчмарке light-java обходит во многих случаях fasthttp. Nginx, да, проигрывает.
Но все же хотелось бы видеть чистое сравнение на разных нагрузках, разных количествах одновременных подключений и т.д.
Ну себя они в плохом свете точно выставлять не будут…
Я не против этого сервера, как и не против Go. Просто с трудом верится в такой разрыв, по сравнению с nginx, и других бенчмарков быстро не удалось найти…
инструмент заточенный под конкретные условия будет быстрее, банально потому что оверхеда меньше
Из того что инструмент заточен под конкретные условия еще ничего не следует. Это лишь говорит о том на что будут направлены усилия разработчиков, но никак не о том что получится в итоге.
наследственность давлеет над ними несмотря на многолетнее развитие
Она же еще и позволяет убрать кучу детских болячек и вылизать все технические решения
А последнюю ссылку вам бы не мешало проштудировать самому, а может даже и сделать конспект
Давайте:
https://github.com/netty/netty/tree/4.1/transport-native-epoll
https://github.com/netty/netty/tree/4.1/transport-native-kqueue
https://github.com/netty/netty/tree/4.1/transport-native-unix-common xhumanoid сверху уже ответил, что в проекте действительно по сути одна только Java. Но все же в репозитории полно нативного кода.
Где-нибудь уже сравнивалась производительность? Есть публичные бенчмарки? Вы сами сравнивали производительность с аналогичным решением на других языках?
Просто поражает, откуда такая пустословная уверенность в быстроте go…
… ведь он специально разработан для решения таких задач
Не аргумент.
В этой статье весьма спорное решение использовалось для других языков, в частности для Java. Либо приведите конкретные пруфы, либо не бросайтесь словами.
… и Java есть реализации неблокирующих вводов/выводов, доступных для использования в веб-приложениях. Но они не так распространены, как вышеописанные подходы..
Это спорное утверждение. И, как мне кажется, если привести статистику с неблокирующими вызовами на Java то она будет уж точно не хуже Go (а может даже лучше).
И ещё мне кажется, что Gradle под Kotlin ещё пока не так хорошо заточен, как Maven.
Там обратная ситуация. В Gradle и скрипты можно теперь писать на Kotlin и в нем раньше появилась инкрементальная компиляция для него.
Да и сама система сборки создавалась не жестко под один определенный язык (по сравнению с Maven), и как результат, имеет более гибкую систему настройки.
Отказаться от Java гугл и не сможет (в теории, конечно, возможно, но это уж в совсем далекой перспективе, как мне кажется). Вся официальная поддрежка Kotlin пока заключается лишь в том что в Android студии он будет по умолчанию (без необходимости ставить плагины) и то что они они у себя опубликуют материалы о том как писать на Kotlin под Android.
это перевод…
Документация по Kotlin на русском
Про делегаты вообще не слова, как и про вариативность. Про coroutines так же ничего не сказано…
Да и просто описание синтаксиса Kotlin сейчас уже не очень актуально, до этого и так было много статей по этому поводу.
Тут вы ошибаетесь
Посмотрите хотя бы:
https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites
Да разнообразие и популярность фрейморков для веба в Java говорит об обратном:
Spring, Dropwizard, Spark, Vert.x и т.д.
Но все же хотелось бы видеть чистое сравнение на разных нагрузках, разных количествах одновременных подключений и т.д.
Ну себя они в плохом свете точно выставлять не будут…
Я не против этого сервера, как и не против Go. Просто с трудом верится в такой разрыв, по сравнению с nginx, и других бенчмарков быстро не удалось найти…
Из того что инструмент заточен под конкретные условия еще ничего не следует. Это лишь говорит о том на что будут направлены усилия разработчиков, но никак не о том что получится в итоге.
Она же еще и позволяет убрать кучу детских болячек и вылизать все технические решения
А последнюю ссылку вам бы не мешало проштудировать самому, а может даже и сделать конспект
https://github.com/netty/netty/tree/4.1/transport-native-epoll
https://github.com/netty/netty/tree/4.1/transport-native-kqueue
https://github.com/netty/netty/tree/4.1/transport-native-unix-common
xhumanoid сверху уже ответил, что в проекте действительно по сути одна только Java. Но все же в репозитории полно нативного кода.
Зачем тогда вообще Java упоминаете? Если про нее ничего сказать не можете…
Просто поражает, откуда такая пустословная уверенность в быстроте go…
Чем можете подтвердить это утверждение?
Не аргумент.
В этой статье весьма спорное решение использовалось для других языков, в частности для Java. Либо приведите конкретные пруфы, либо не бросайтесь словами.
Это спорное утверждение. И, как мне кажется, если привести статистику с неблокирующими вызовами на Java то она будет уж точно не хуже Go (а может даже лучше).
Поэтому и существуют некоторые сложности для сборки других языков.
П.с. пока искал нашел еще одну интересную статью: Maven is broken by design
Там обратная ситуация. В Gradle и скрипты можно теперь писать на Kotlin и в нем раньше появилась инкрементальная компиляция для него.
Да и сама система сборки создавалась не жестко под один определенный язык (по сравнению с Maven), и как результат, имеет более гибкую систему настройки.