Это просто признак того, что рынок Scala растет недостаточными темпами для финансовой успешности Lightbend, и приходится менять фокус. Собственно, большинство комментариев к статьям по ссылкам о переименовании в Lightbend говорят о том же.
Я не настаиваю на верности своего утверждения, в целом мой комментарий был не об этом. Я ничего не имею против успешности Scala, просто мне (и многим другим) этот язык не подходит. Хорошо, что есть выбор.
Я выбираю Kotlin, если хочется «better Java» без излишнего упора на функциональщину. Из новых языков также понравилось писать (а ещё больше — читать) код на Go, несмотря на изначальный скепсис из-за отсутствия дженериков, null safety и immutability. Kotlin и Go — оба прагматичные языки, с opinionated ограничениями заложенными авторами языка, и своей философией.
Java 8 тоже не так уж плоха, и тут я соглашусь с одной из основных (но не единственной) причин успеха Kotlin на Android.
Думаю, что Play с Kotlin использовать ровно также как Play с Java. Могут быть какие-то особенности из-за того что Play написан на Scala, но способы их решения идентичны Java.
В зависимости от типа проекта (gradle, maven, sbt) должно быть достаточно подключить плагин для компилятора Kotlin. В gradle это делается совсем просто: https://kotlinlang.org/docs/reference/using-gradle.html
Люди почти без опыта программирования (с базовыми теоретическими знаниями java) осваивают scala без труда.
Либо речь об очень ограниченном использовании Scala (на которой можно «писать Java код» без использования продвинутых фич), либо вы сильно преувеличиваете, либо качество результата оставляет желать лучшего.
Достаточно взглянуть на курсы по Scala от Мартина Одерски на Coursera, чтобы понять что по-настоящему «освоить без труда» этот язык невозможно: https://ru.coursera.org/specializations/scala
Изобретать DSL можно и на java.
В том и дело, что невозможно. Можно делать API из методов под предметную область, но это совсем другая тема.
Kotlin позволяет делать DSL (взять хотя бы DSL для Gradle или Anko), но его возможности довольно сильно ограничены и для меня это скорее плюс.
Но extension методы котлина вам будет не менее весело вызывать из java
Но эта проблема на плечах разработчиков библиотек.
А если библиотека не развивается активно (но при этом достаточно стабильна и удовлетворяет потребности)?
Для любых недостатков есть обходные пути, но это же не значит что они несущественны.
Если есть проблемы на плечах разработчиков библиотек, значит косвенно эти проблемы и на плечах всех остальных разработчиков, которым нужно сначала дождаться пока все используемые библиотеки добавят поддержку новой версии, найти альтернативу или форкнуть и допилить самим.
Что вы подразумеваете под ростом скалы?
Имел ввиду популярность среди разработчиков. По ощущениям, популярность сохраняется только в области Big Data, во многом благодаря Spark.
В целом, мое субъективное имхо: если хочется продвинутый функциональный язык, то лучше брать что-то более «чистое» вроде Elixir и Haskell, или даже Clojure. Здесь более менее понятная ниша и ожидания.
Если хочется «простой» ООП, то остается выбор между Java, Kotlin, Go и многими другими языками в зависимости от потребностей.
Scala в этом смысле является «неведомой зверушкой», странной комбинацией ООП, ФП и собственных фич (вроде implicit приведения типов), которая вроде бы умеет все понемногу, но в итоге это только усложняет процесс разработки.
Это сугубо мое личное мнение на основе собственного опыта, статистикой и экспертными мнениями подкрепить не могу.
Вполне допускаю, что все описанные недостатки несущественны для отдельных людей и проектов, и хорошо, что у людей есть выбор. Kotlin взял немало идей из Scala, и учел многие недостатки (но и значительно ограничил возможности). Каждому свое.
Выбор между Spring и проектами с непонятной перспективой
Выбор тот же самый, что и для Java: Spring Boot, Dropwizard или любой другой.
В том и прелесть Kotlin, что в отличие от Scala не требуется изобретать велосипеды заново, а можно использовать стандартный стек технологий Java.
Я конвертировал проект на Dropwizard + Guice с Java в Kotlin, за пару часов исправил все проблемы компиляции, и можно продолжать развивать проект не отвлекаясь на поиск новых сырых альтернатив.
Вы попробуйте как-нибудь прийти в команду с проектом на Scala, который разрабатывается уже пару лет. Я бы ни за что не стал использовать Scala в качестве массового языка общего назначения. Проблемы навскидку:
— Высокий порог вхождения
— Гибкость языка приводит к тому, что одну задачу можно решить кучей способов, при этом результат зачастую выглядеть так, как будто под каждую задачу изобретается новый синтаксис языка (особенно если используются «богатые» фичи библиотек вроде scalaz)
— Плохая поддержка IDE. Из-за отсутствия жёсткого синтаксиса как такового (можно определять собственные операторы, использовать символы вроде <#= в именах методов), IntelliJ порой просто сходит с ума и светит весь код красным, пока не допишешь корректный код.
— Плохая совместимость с Java. Из Scala вызывать Java код ещё терпимо, но в обратную сторону практически невозможно.
— Проблемы обратной совместимости между версиями самой Scala: нужно иметь версии всех библиотек, скомпилированные одной версией компилятора Scala.
— Медленный компилятор
— Конкретно для Android также критичен размер рантайма, насколько помню у Scala он слишком большой для Android.
Список можно продолжать долго, но важно что все эти моменты учтены командой Kotlin, и получился действительно прагматичный элегантный язык, который двумя словами можно назвать «better Java». Пожалуй единственный другой язык на котором также было приятно писать, был C# (из которого кстати Kotlin взял много идей, но хватает и уникальных фич).
Собственно, Google не поддержал в своё время Scala, а Kotlin поддержал и довольно быстро. Это уже говорит о многом.
Кроме того, по ощущениям бурный рост Scala остановился около года назад (если тот рост, что был до этого можно назвать бурным), и я сталкивался с несколькими проектами, которые отказались от Scala и либо вернулись на Java, либо совсем ушли с JVM в сторону других языков (Go, например).
Более того, компания создателя Scala Мартина Одерски (Typesafe) сменила название на Lightbend, и теперь в первую очередь делают фреймворки для Java, и уже затем делают обертки на Scala.
Доступность — это сложное понятие и вычисляется для разных сервисов по-разному, но обычно это отношение количества выполненных запросов к общему количеству запросов, обычно описывается девятками: 999, 9999, 99999.
Разве? Обычно измеряется в процентах успешно обработанных запросов к их общему количеству — 99.9%, 99.99%, 99.999%, см. Википедию
<Если говорить про живой покер, то чего только стоит понимания человеческого взгляда
Что может иметь как положительный, так и отрицательный эффект. Взгляд это неточные данные, поэтому и его анализ можно точно также считать частью набора вероятностей с весами.
Другой вопрос, что компьютеру эти данные на вход не подают. Это тоже решаемый момент — поставьте видеокамеру и подавайте снимки лиц на вход системы. Хотя в том же онлайн покере нет никаких лиц и взглядов, насколько я понимаю.
Умные часы так и не взлетели. Просто Apple побоялся прозевать нишу, поэтому пришлось поторопиться и выпустить недоработанный сырой продукт с непонятной целевой аудиторией (ИМХО).
С VR в целом все выглядит также пока.
Действительно потенциально массовая технология будущего, на мой взгляд, — это домашние голосовые системы управления (Amazon Echo, Google Home). Siri, Google Now и Cortana так и остались игрушками, т.к. людям неудобно разговаривать с девайсом на публике, плюс вслух в толпе незнакомых людей разговаривать вслух также не слишком комфортно. А вот в качестве универсального домашнего пульта — в самый раз.
Интересно, выпустит ли Apple свой аналог Amazon Echo на базе Siri.
Я согласен, что Hibernate/JPA полезно знать новичку (хотя там тоже хватает граблей и подводных камней).
Но утверждение, что использовать JDBC напрямую «очень плохо», тоже слишком категорично.
Ни в одном из последних проектов, где я работал, не использовался Hibernate. Использовали легковесные обертки над JDBC — Spring JdbcTemplate, myBatis, JDBI. В итоге имеем полную функциональность SQL и понимание что происходит «под капотом», но без лишнего гемора с многословным JDBC.
Это всего лишь первое собеседование — тупой фильтр, чтобы не загружать технических специалистов собеседованиями с заведомо неподходящими людьми.
И все равно, на следующем же этапе 90% отсеятся. Пройти 7 технических собеседований просто выучив методичку не получится (зато натренировавшись на типовые алгоритмически задачки — вполне, но это уже другой вопрос).
Рекомендую прочесть заметку по другую сторону баррикад, от сотрудника Google: https://www.reddit.com/r/cscareerquestions/comments/1z97rx/from_a_googler_the_google_interview_process/
About 1/10 candidates pass this step, because most candidates (even with master’s degrees and claimed multi-year experience) are completely incompetent.
So be prepared to talk to an engineer who expects you to fail, and would rather be doing something else.
После такого инсайта больше понимания, почему именно все так.
Приходится как-то останавливать волну некомпетентных людей, чтобы не перегружать технических специалистов (для которых рекрутинг далеко не основной род деятельности).
Другой вопрос, что такой подход оправдан только к тем, кто активно шлет резюме в Google. А если наоборот, рекрутер из Google постучался, то такой первичный фильтр устраивать уже глупо конечно.
Так исторически сложилось. В РосКосмосе — космонавты, в NASA — астронавты.
Вот, к примеру, вчерашняя статья: https://www.theverge.com/platform/amp/2016/10/18/13321106/nasa-iss-astronauts-soyuz-rocket-launch-watch-live-stream
On board the flight will be NASA astronaut Shane Kimbrough, as well as Russian cosmonauts Sergey Ryzhikov and Andrey Borisenko.
Есть хотя бы один пример явного применения в своих продуктах? Скорее они просто покупают инженеров и хоронят конкурирующий продукт, особо не вникая.
Facebook действует гораздо адекватнее, покупая компании но оставляя их независимыми под тем же брендом (WhatsApp, Instagram, Oculus) и вкладываясь в их развитие. А если не получается купить, тогда как раз копируют идеи (Instagram Stories для конкуренции с Snapchat, например), что вполне логично.
SpaceX представляет угрозу другим коммерческим компаниям, получающих заказы от NASA.
Сам по себе полет на Марс действительно никому не нужен, но в интересах конкурирующих компаний показать свою состоятельность и не потерять возможность заниматься другими космическими заказами.
Что это за стремление вообще — непременно сделать из своего ребенка гения?
Воспитать хорошего человека с развитым кругозором и самостоятельной точкой зрения, с устойчивой психикой — отлично.
Познакомить с космосом, компьютерами, литературой — пожалуйста.
Но почему все обязательно хотят вырастить гения любыми средствами, в т.ч. используя неподходящие по возрасту методы? И почему каждый первый кружок для детей обещает помочь вам в этом?
Не понимаю. Это скорее ЧСВ родителя, чем забота о счастливом будущем ребенка.
> Так что странно почему в самой Тесла сильно удивляются росту числа желающих с десятков тысяч до сотен тысяч человек.
А может это просто маркетинговый ход, и они «удивляются» на публику, чтобы воодушевить инвесторов и повысить спрос на акции?
Это просто признак того, что рынок Scala растет недостаточными темпами для финансовой успешности Lightbend, и приходится менять фокус. Собственно, большинство комментариев к статьям по ссылкам о переименовании в Lightbend говорят о том же.
Я не настаиваю на верности своего утверждения, в целом мой комментарий был не об этом. Я ничего не имею против успешности Scala, просто мне (и многим другим) этот язык не подходит. Хорошо, что есть выбор.
Я выбираю Kotlin, если хочется «better Java» без излишнего упора на функциональщину. Из новых языков также понравилось писать (а ещё больше — читать) код на Go, несмотря на изначальный скепсис из-за отсутствия дженериков, null safety и immutability. Kotlin и Go — оба прагматичные языки, с opinionated ограничениями заложенными авторами языка, и своей философией.
Java 8 тоже не так уж плоха, и тут я соглашусь с одной из основных (но не единственной) причин успеха Kotlin на Android.
Также можно поискать по слову «Java» в анонсе переименования компании
В зависимости от типа проекта (gradle, maven, sbt) должно быть достаточно подключить плагин для компилятора Kotlin. В gradle это делается совсем просто: https://kotlinlang.org/docs/reference/using-gradle.html
Либо речь об очень ограниченном использовании Scala (на которой можно «писать Java код» без использования продвинутых фич), либо вы сильно преувеличиваете, либо качество результата оставляет желать лучшего.
Достаточно взглянуть на курсы по Scala от Мартина Одерски на Coursera, чтобы понять что по-настоящему «освоить без труда» этот язык невозможно: https://ru.coursera.org/specializations/scala
В том и дело, что невозможно. Можно делать API из методов под предметную область, но это совсем другая тема.
Kotlin позволяет делать DSL (взять хотя бы DSL для Gradle или Anko), но его возможности довольно сильно ограничены и для меня это скорее плюс.
Extension функции в Kotlin это просто синтаксический сахар и реализуется через статические методы (как и в C#, откуда взята эта фича): http://stackoverflow.com/a/28364983
Есть отдельные проблемы со статическими полями и прочим, но это встречается не очень часто и решается аннотациями вроде @JvmStatic, есть официальный гайд: https://kotlinlang.org/docs/reference/java-to-kotlin-interop.html
А если библиотека не развивается активно (но при этом достаточно стабильна и удовлетворяет потребности)?
Для любых недостатков есть обходные пути, но это же не значит что они несущественны.
Если есть проблемы на плечах разработчиков библиотек, значит косвенно эти проблемы и на плечах всех остальных разработчиков, которым нужно сначала дождаться пока все используемые библиотеки добавят поддержку новой версии, найти альтернативу или форкнуть и допилить самим.
Имел ввиду популярность среди разработчиков. По ощущениям, популярность сохраняется только в области Big Data, во многом благодаря Spark.
В целом, мое субъективное имхо: если хочется продвинутый функциональный язык, то лучше брать что-то более «чистое» вроде Elixir и Haskell, или даже Clojure. Здесь более менее понятная ниша и ожидания.
Если хочется «простой» ООП, то остается выбор между Java, Kotlin, Go и многими другими языками в зависимости от потребностей.
Scala в этом смысле является «неведомой зверушкой», странной комбинацией ООП, ФП и собственных фич (вроде implicit приведения типов), которая вроде бы умеет все понемногу, но в итоге это только усложняет процесс разработки.
Это сугубо мое личное мнение на основе собственного опыта, статистикой и экспертными мнениями подкрепить не могу.
Вполне допускаю, что все описанные недостатки несущественны для отдельных людей и проектов, и хорошо, что у людей есть выбор. Kotlin взял немало идей из Scala, и учел многие недостатки (но и значительно ограничил возможности). Каждому свое.
Выбор тот же самый, что и для Java: Spring Boot, Dropwizard или любой другой.
В том и прелесть Kotlin, что в отличие от Scala не требуется изобретать велосипеды заново, а можно использовать стандартный стек технологий Java.
Я конвертировал проект на Dropwizard + Guice с Java в Kotlin, за пару часов исправил все проблемы компиляции, и можно продолжать развивать проект не отвлекаясь на поиск новых сырых альтернатив.
— Высокий порог вхождения
— Гибкость языка приводит к тому, что одну задачу можно решить кучей способов, при этом результат зачастую выглядеть так, как будто под каждую задачу изобретается новый синтаксис языка (особенно если используются «богатые» фичи библиотек вроде scalaz)
— Плохая поддержка IDE. Из-за отсутствия жёсткого синтаксиса как такового (можно определять собственные операторы, использовать символы вроде <#= в именах методов), IntelliJ порой просто сходит с ума и светит весь код красным, пока не допишешь корректный код.
— Плохая совместимость с Java. Из Scala вызывать Java код ещё терпимо, но в обратную сторону практически невозможно.
— Проблемы обратной совместимости между версиями самой Scala: нужно иметь версии всех библиотек, скомпилированные одной версией компилятора Scala.
— Медленный компилятор
— Конкретно для Android также критичен размер рантайма, насколько помню у Scala он слишком большой для Android.
Список можно продолжать долго, но важно что все эти моменты учтены командой Kotlin, и получился действительно прагматичный элегантный язык, который двумя словами можно назвать «better Java». Пожалуй единственный другой язык на котором также было приятно писать, был C# (из которого кстати Kotlin взял много идей, но хватает и уникальных фич).
Собственно, Google не поддержал в своё время Scala, а Kotlin поддержал и довольно быстро. Это уже говорит о многом.
Кроме того, по ощущениям бурный рост Scala остановился около года назад (если тот рост, что был до этого можно назвать бурным), и я сталкивался с несколькими проектами, которые отказались от Scala и либо вернулись на Java, либо совсем ушли с JVM в сторону других языков (Go, например).
Более того, компания создателя Scala Мартина Одерски (Typesafe) сменила название на Lightbend, и теперь в первую очередь делают фреймворки для Java, и уже затем делают обертки на Scala.
Разве? Обычно измеряется в процентах успешно обработанных запросов к их общему количеству — 99.9%, 99.99%, 99.999%, см. Википедию
Что может иметь как положительный, так и отрицательный эффект. Взгляд это неточные данные, поэтому и его анализ можно точно также считать частью набора вероятностей с весами.
Другой вопрос, что компьютеру эти данные на вход не подают. Это тоже решаемый момент — поставьте видеокамеру и подавайте снимки лиц на вход системы. Хотя в том же онлайн покере нет никаких лиц и взглядов, насколько я понимаю.
Это не синонимы https://blog.golang.org/concurrency-is-not-parallelism
Умные часы так и не взлетели. Просто Apple побоялся прозевать нишу, поэтому пришлось поторопиться и выпустить недоработанный сырой продукт с непонятной целевой аудиторией (ИМХО).
С VR в целом все выглядит также пока.
Действительно потенциально массовая технология будущего, на мой взгляд, — это домашние голосовые системы управления (Amazon Echo, Google Home). Siri, Google Now и Cortana так и остались игрушками, т.к. людям неудобно разговаривать с девайсом на публике, плюс вслух в толпе незнакомых людей разговаривать вслух также не слишком комфортно. А вот в качестве универсального домашнего пульта — в самый раз.
Интересно, выпустит ли Apple свой аналог Amazon Echo на базе Siri.
Но утверждение, что использовать JDBC напрямую «очень плохо», тоже слишком категорично.
Ни в одном из последних проектов, где я работал, не использовался Hibernate. Использовали легковесные обертки над JDBC — Spring JdbcTemplate, myBatis, JDBI. В итоге имеем полную функциональность SQL и понимание что происходит «под капотом», но без лишнего гемора с многословным JDBC.
И все равно, на следующем же этапе 90% отсеятся. Пройти 7 технических собеседований просто выучив методичку не получится (зато натренировавшись на типовые алгоритмически задачки — вполне, но это уже другой вопрос).
Рекомендую прочесть заметку по другую сторону баррикад, от сотрудника Google: https://www.reddit.com/r/cscareerquestions/comments/1z97rx/from_a_googler_the_google_interview_process/
После такого инсайта больше понимания, почему именно все так.
Приходится как-то останавливать волну некомпетентных людей, чтобы не перегружать технических специалистов (для которых рекрутинг далеко не основной род деятельности).
Другой вопрос, что такой подход оправдан только к тем, кто активно шлет резюме в Google. А если наоборот, рекрутер из Google постучался, то такой первичный фильтр устраивать уже глупо конечно.
Вот, к примеру, вчерашняя статья: https://www.theverge.com/platform/amp/2016/10/18/13321106/nasa-iss-astronauts-soyuz-rocket-launch-watch-live-stream
On board the flight will be NASA astronaut Shane Kimbrough, as well as Russian cosmonauts Sergey Ryzhikov and Andrey Borisenko.
Facebook действует гораздо адекватнее, покупая компании но оставляя их независимыми под тем же брендом (WhatsApp, Instagram, Oculus) и вкладываясь в их развитие. А если не получается купить, тогда как раз копируют идеи (Instagram Stories для конкуренции с Snapchat, например), что вполне логично.
Сам по себе полет на Марс действительно никому не нужен, но в интересах конкурирующих компаний показать свою состоятельность и не потерять возможность заниматься другими космическими заказами.
Воспитать хорошего человека с развитым кругозором и самостоятельной точкой зрения, с устойчивой психикой — отлично.
Познакомить с космосом, компьютерами, литературой — пожалуйста.
Но почему все обязательно хотят вырастить гения любыми средствами, в т.ч. используя неподходящие по возрасту методы? И почему каждый первый кружок для детей обещает помочь вам в этом?
Не понимаю. Это скорее ЧСВ родителя, чем забота о счастливом будущем ребенка.
А может это просто маркетинговый ход, и они «удивляются» на публику, чтобы воодушевить инвесторов и повысить спрос на акции?