Обращаем внимание на Котлин
Почему я обращаю внимание своего стороннего проекта на новый язык JVM
Если вы читали мой средний блог до того, как вы могли столкнуться с тем фактом, что моим побочным хобби в течение некоторого времени было написание приложений на Scala. Причина в основном заключается в том, что мне нравится синтаксис и приятно работать, однако в начале этого года что-то произошло.
Google объявил, что будет поддерживать Kotlin в Android. Я сразу понял, что это знак того, что Kotlin останется здесь надолго, и не только потому, что благодаря его более деловому, чем академическому подходу, гораздо больше разработчиков будут готовы принять его, чем Scala, из-за его меньшего размера и того факта, что большая часть Код Kotlin выглядит так, как будто он был написан смертными людьми, а не супер-богами Haskell.
В типичной реакции я подумал: Эй, давай попробуем, и начал работать с документацией. Затем в какой-то момент я начал скучать по сахару Uniform Access Principle, который я так люблю в Scala, одному из его ключевых преимуществ, которые, на мой взгляд, делают его таким элегантным языком.
В этот момент минималист во мне начал размахивать красным флагом и задавать вопросы. Приносит ли вам пользу этот язык? Собираетесь ли вы его практически использовать? А если нет, научит ли это чему-то новому?
Тогда ответ был отрицательный. Я пока не видел в Котлине ничего такого, чего еще не видел на другом языке, и мне нужно было сосредоточить свое время на более практических вещах.
Прошло несколько месяцев, и я пытался сделать что-то новое. Побочный проект, который я мог бы довести до конца, побочный проект, который мог бы открыть возможности, выходящие за рамки простого самовнушения, и, вероятно, привлек бы больше разработчиков, которые могли бы присоединиться к нему.
Естественно, я написал доказательство концепции на Scala. Это было красиво, элегантно и… трудно объяснить. Не только членам семьи, к которым я был в то время, но и почти всем, кто раньше не видел Scala.
Поэтому мне нужно было принять решение, мне нужно было выбрать что-то более понятное, что могло бы поднять больше людей. Безусловно, наиболее распространенным и простым способом создания серверных приложений является использование Express и Node.JS, но в среде JVM ко мне очень хорошо относятся. Я мог доверять пакетам для сторонних библиотек, которые я извлек из репозиториев maven, когда работал со Scala, роскошь, которую я жажду каждый раз, когда мне приходится иметь дело с npm, вытаскивающим что-то новое, что ломает вещи.
Другая проблема заключается в том, что, хотя я и являюсь довольно тяжелым разработчиком внешнего интерфейса в своей повседневной работе, когда дело доходит до элементов внутреннего интерфейса, мне нравится статическая типизация, динамические элементы хороши для манипуляций с DOM и быстрых прототипов, но я пошел на точка переключения всего бэкенда на .Net раньше в стороннем проекте, потому что Node стал неуправляемым.
Я не собираюсь слишком углубляться в вопрос «Почему бы и не использовать узел?». Есть множество причин, по которым не следует его использовать, а также множество причин для его использования. Но сейчас я предпочитаю избегать этого, если это вообще возможно. Итак, в этом проекте Node не было.
Следующим в моем списке возможностей было ядро .Net, но это длилось недолго. Kestrel выглядит интересным, но похоже, что, возможно, придется построить довольно много самому, если вы пойдете по этому пути, а Нэнси, похоже, находится в процессе перехода к 2.0, что всегда является самым ужасным временем для освоения технологии.
C # также является одним из самых жестоко неэлегантных языков всех времен, поощряющих непристойные методы, такие как {на новой строке и имена методов с заглавной буквы. Да, это мой побочный проект, и я могу быть немного иррациональным… и иметь вкус.
Я убедил себя, что мне нужна JVM, но ни Scala, ни Java8 не собирались ее сокращать. Да, в нем есть современные черты. Но потом я вспомнил, как нужно конвертировать данные в потоки, чтобы использовать карты и еще много всякой ерунды, с которой я привык не иметь дела. Я просто хотел улучшить Java, и, конечно же, я вернулся в Котлин.
Итак, теперь у меня наконец-то есть причина использовать Kotlin, и, игнорируя отсутствие сахара UAP, я нашел его довольно приятным. Только время покажет, окупится ли это решение, но я скажу, что для меня большое облегчение - работать с языком, который по сравнению с ним намного меньше и, честно говоря, лучше документирован сообществом, менее одержимым монадами и пишущим чистейшие и самые чистые. функциональная программа возможна.
Не поймите меня неправильно, я все еще люблю Scala, но Kotlin - это нечто среднее между элегантностью и практичностью.
