Comments 36
Действительно печальная новость. День омрачён.
>> Почему я уверен в том, что этот запрос Марка будет удовлетворен сообществом:
2 пункта в подтверждение, но вот 3й как раз в тему почему некоторые в сообществе считают, что может лучше уже и на 10ку скинуть модули, так как их первоначально вообще в 7ку обещали и где гарантия, что из-за них в мае не придется опять переносить еще на 6 месяцев релиз
2 пункта в подтверждение, но вот 3й как раз в тему почему некоторые в сообществе считают, что может лучше уже и на 10ку скинуть модули, так как их первоначально вообще в 7ку обещали и где гарантия, что из-за них в мае не придется опять переносить еще на 6 месяцев релиз
Да уже пофиг. Полугодом раньше, полугодом позже, когда Java отстает от потребностей индустрии лет на пять — не смертельно.
С другой стороны, альтернативы толком нет.
С другой стороны, альтернативы толком нет.
Scala?
Ну вот это рефлекторная реакция, мол Scala. А на самом деле технологический стек там жестокий, sbt — один сплошной анекдот, сама скала больше интеллектуальная игрушка для ее создателей, чем профессиональный инструмент. Не думаю, что она победит, хотя через пять лет видно будет. На мой вкус, Scala хорошо взлетит на задачах метапрограммирования, но их гораздо меньше, чем задач общего плана.
Не без проблем, конечно, но полет нормальный. Sbt не быстрый, но свое дело делает, это он раньше был совсем отсталым. Scala сам по себе уже не новый язык, на нем есть большие проекты, например, Apache Spark.
Twitter, опять же, давно юзает его в Production и выпустил много open-source инструментов.
Java уже давно двигается по инерции, как, впрочем, и сам Oracle, который все больше катится в забвение.
Twitter, опять же, давно юзает его в Production и выпустил много open-source инструментов.
Java уже давно двигается по инерции, как, впрочем, и сам Oracle, который все больше катится в забвение.
У меня вопрос-оффтопик, а у sbt вообще есть смысл? Ну, я имею в виду, он изначально решал какие-то задачи, которых не решали иные сборщики, или просто «мы можем писать мета-язычки на скале, поэтому давайте напишем мета-язычок для сборки, просто потому что можем»?
как минимум он решает проблему, что для зависимостей с разными версиями скалы нужны разные версии билдов
зависимость собранная для скалы 2.10 не взлетит если у вас проект на 2.11 и тд
то есть главные смысл в автоматическом мэтчинге нужной версии скалы
но по мне это пример костыля, который пытается маскировать основную проблему «между версиями плывет байткод»
ну а второй момент политический: зачем нам мэйвен если мы можем и сборщик тоже использовать со скалой, в итоге scala everywhere
зависимость собранная для скалы 2.10 не взлетит если у вас проект на 2.11 и тд
то есть главные смысл в автоматическом мэтчинге нужной версии скалы
но по мне это пример костыля, который пытается маскировать основную проблему «между версиями плывет байткод»
ну а второй момент политический: зачем нам мэйвен если мы можем и сборщик тоже использовать со скалой, в итоге scala everywhere
А почему сразу мавен то в пример?
Gradle отличный сборщик.
Как по мне, так лучше бы они вложились в развитие плагина scala для него.
Ибо вот это вот «scala everywhere, но с костылями и головняком» — реально нафиг никому не уперлось кроме Typesafe.
Gradle отличный сборщик.
Как по мне, так лучше бы они вложились в развитие плагина scala для него.
Ибо вот это вот «scala everywhere, но с костылями и головняком» — реально нафиг никому не уперлось кроме Typesafe.
ну давайте быть честными, в момент становления sbt тот же gradle был не намного лучше
так как до версии 1.0 в нем очень часто после очередного milestone отваливался билд, пока не снесешь кеш в домашней директории на сборке ошибка писалась совсем не интуитивно понятная, а после сноса кеша резко все продолжало работать.
поэтому и развивались они параллельно, а менять сейчас смысла нету, так как свою задачу в данный момент делают оба
p.s. я уже не раз имел спор с билд инженерами чем вам (maven/gradle/sbt) не угодил, а выбрали (maven/gradle/sbt), ведь я могу с помощью него сделать все тоже, что вы делаете на своем. в общем это холивар =) причем очень жестокий. в любой системе можно сделать как вменяемый билд скрипт, так и такой что никто его не осилит
так как до версии 1.0 в нем очень часто после очередного milestone отваливался билд, пока не снесешь кеш в домашней директории на сборке ошибка писалась совсем не интуитивно понятная, а после сноса кеша резко все продолжало работать.
поэтому и развивались они параллельно, а менять сейчас смысла нету, так как свою задачу в данный момент делают оба
p.s. я уже не раз имел спор с билд инженерами чем вам (maven/gradle/sbt) не угодил, а выбрали (maven/gradle/sbt), ведь я могу с помощью него сделать все тоже, что вы делаете на своем. в общем это холивар =) причем очень жестокий. в любой системе можно сделать как вменяемый билд скрипт, так и такой что никто его не осилит
>> Не без проблем, конечно, но полет нормальный
>> на нем есть большие проекты, например, Apache Spark
тогда может нам еще расскажите про совместимость между версиями?
Spark до сих пор используют scala 2.10.4, так как переехать на 2.11 свежее требует достаточно много ресурсов.
а дальше будет 2.12 которая вроде как обещают совместимость с 2.11, но хз-хз, так как работу с лямбдами полностью переделали
а после 2.13 в которой collections полностью обещают переделать, в итоге нету вообще никакой гарантии что даже на уровне source code будет работать.
или может расскажите про play?
если у вас проект на play со смесью java и scala и вам нужно смигрировать с play 2.1 на последние версии java, то резко оказывается что scala 2.9 не переваривает байткод от восьмерки, нужно обновить скалу до свежей версии,
обновляем скалу и нарываемся на второй пункт — 2.1 собран только под scala 2.9, под свежую скалу нету его, следовательно просто java обновить вы не можете, нужно обновлять и скала и сам плей
плей между версиями меняет api следовательно опять секс =)
итого: смена language level с 7 на 8 для scala части выливается в обновили scala core / all frameworks / fix all changed api
вообще если подойти более обще, то оказывается, что тот же typesafe пытается как-то объяснить Одерскому, что меняя api и ломая байткод каждую версию в серьезные проекты залезть сложно, на что получает закономерный ответ «нужно больше фич, а поддержка и совместимость это вторично»
>> на нем есть большие проекты, например, Apache Spark
тогда может нам еще расскажите про совместимость между версиями?
Spark до сих пор используют scala 2.10.4, так как переехать на 2.11 свежее требует достаточно много ресурсов.
а дальше будет 2.12 которая вроде как обещают совместимость с 2.11, но хз-хз, так как работу с лямбдами полностью переделали
а после 2.13 в которой collections полностью обещают переделать, в итоге нету вообще никакой гарантии что даже на уровне source code будет работать.
или может расскажите про play?
если у вас проект на play со смесью java и scala и вам нужно смигрировать с play 2.1 на последние версии java, то резко оказывается что scala 2.9 не переваривает байткод от восьмерки, нужно обновить скалу до свежей версии,
обновляем скалу и нарываемся на второй пункт — 2.1 собран только под scala 2.9, под свежую скалу нету его, следовательно просто java обновить вы не можете, нужно обновлять и скала и сам плей
плей между версиями меняет api следовательно опять секс =)
итого: смена language level с 7 на 8 для scala части выливается в обновили scala core / all frameworks / fix all changed api
вообще если подойти более обще, то оказывается, что тот же typesafe пытается как-то объяснить Одерскому, что меняя api и ломая байткод каждую версию в серьезные проекты залезть сложно, на что получает закономерный ответ «нужно больше фич, а поддержка и совместимость это вторично»
Spark до сих пор используют scala 2.10.4, так как переехать на 2.11 свежее требует достаточно много ресурсов.
А в чем проблема? Spark можно собрать под 2.11 начиная с версии 1.2 или вроде того.
а после 2.13 в которой collections полностью обещают переделать
Поживем — увидим, но это точно не Rust, так что все не должно сломаться.
если у вас проект на play со смесью java и scala и вам нужно смигрировать с play 2.1 на последние версии java
Выстрелить себе в ногу можно разными способами. Увидев Play 2 после Play 1, уже можно было понять, что эти парни — маньяки.
>> Spark можно собрать под 2.11 начиная с версии 1.2 или вроде того.
вот именно, поэтому найти в природе 2.11 немного проблематично, даже на офф сайте
«Note: Scala 2.11 users should download the Spark source package and build with Scala 2.11 support.»
а просто взять и использовать нельзя…
>> так что все не должно сломаться.
ага, сломается только половина
я не противник скалы, сам регулярно её использую для прототипов и небольших проектов, но начинать серьезный проект который нужно будет поддерживать годами я морально не готов, так как все эти изменения немножко напрягают. сам подход bytecode мы ломаем постоянно, а source level «всего» через раз отпугивают от scala очень много компаний. тут компании задумываются над тем, что обновлять java каждые 18 месяцев это слишком часто, давайте нам релиз цикл хотя бы 2 года, а вы со scala предлагаете каждые 2 года заставлять их переписывать код.
p.s. минутка юмора: очередной раз перечитывая www.scala-lang.org/api/2.11.4/index.html#scala.collection.concurrent.Map и все его варианты с + ++: --= /: :\ ++= складывается впечатление, что Одерски пытался написать обфускатор, но люди обозвали это языком и пытаются кодить =)
вот именно, поэтому найти в природе 2.11 немного проблематично, даже на офф сайте
«Note: Scala 2.11 users should download the Spark source package and build with Scala 2.11 support.»
а просто взять и использовать нельзя…
>> так что все не должно сломаться.
ага, сломается только половина
я не противник скалы, сам регулярно её использую для прототипов и небольших проектов, но начинать серьезный проект который нужно будет поддерживать годами я морально не готов, так как все эти изменения немножко напрягают. сам подход bytecode мы ломаем постоянно, а source level «всего» через раз отпугивают от scala очень много компаний. тут компании задумываются над тем, что обновлять java каждые 18 месяцев это слишком часто, давайте нам релиз цикл хотя бы 2 года, а вы со scala предлагаете каждые 2 года заставлять их переписывать код.
p.s. минутка юмора: очередной раз перечитывая www.scala-lang.org/api/2.11.4/index.html#scala.collection.concurrent.Map и все его варианты с + ++: --= /: :\ ++= складывается впечатление, что Одерски пытался написать обфускатор, но люди обозвали это языком и пытаются кодить =)
По поводу обфускации и операторов /: :\.
В своем докладе Scala with style Мартин сам признал это ошибкой.
В своем докладе Scala with style Мартин сам признал это ошибкой.
Тиньков на скале пишут свой бэкенд, это если говорить про наших
Вас никто не заставляет использовать sbt. Можете использовать maven или gradle, если вам так удобнее. Многие scala-разработчики используют gradle и ничего в этом зазорного нет.
Заставляют, конечно, иначе стал бы я тут пыхтеть.
Вас заставляют коллеги, или разработчики фреймворков?
В случае с фреймворками все не так плохо.
В случае с фреймворками все не так плохо.
Ну и ничего, перебьёмся, у нас OSGi есть на всякий случай.
Хотя, Compact Profiles не помешали бы.
Хотя, Compact Profiles не помешали бы.
2013 год. Ничего не поменялось.
Ну задержат так задержат. Нам бы в продакшене с Java 6 на Java 7 перейти бы, а потом на Java 8. А до Java 9 мы еще не скооро доберемся
Почему не перейти сразу на Java 8?
Что за компания если не секрет? Как вы вообще в проде держите, то, что не сапортится уже долгое время?
почему не саппортится? саппортится
Android это еще во всю Java 6, Google отказался от поддержки Java 5 (в публичных библиотеках, что может быть знаком, что и у себя на проде) только полтора года назад. Кое-где может быть все существенно хуже. Волкер Симонс говорил, что SAP будет поддерживать Java 1.4 (!) еще как минимум 10 лет (!!!)
Впечатление, что сделать релиз Java физически нельзя быстрее чем за 3 года. Это длина цикла разработки таких масштабных изменений, как лямбды, модули, value типы (на 10)
Как стороннему наблюдателю мне кажется что проблема исключительно в разработчиках и/или менеджменте — тот же C# уже длительное время спокойно развивается семимильными шагами (хотя после развала sun вроде немного получше стало?).
Я думаю, что основная причина — рост сложности. База исходников растет, декомпозиция слабая, поэтому можно говорить про квадратичный рост сложности.
Sign up to leave a comment.
Выход Java 9 будет отложен на полгода