• Состоялся финальный релиз Angular 2
    0
    Выше сказали что Реакт использует внутри Shadow DOM. А вы даже не заметили. Вот я и возмутился.

    А view layer очень даже прямым боком, Shadow DOM это изоляция компонентов (один из возможных на сегодняшни день способов), А Virtual DOM способ увеличить перформанс View Layer, которым React и является.
  • Состоялся финальный релиз Angular 2
    0
    Можно только порадоваться за Meteor, получается они ушли с Ангуляр на Реакт?
  • Состоялся финальный релиз Angular 2
    +1
    Скорее путать Виртуальный и Теневой ДОМ это печально…
    А на счет «подлагивания» вы приложения на Ангуляре видели? Вот там лаги так лаги. (Смотреть тот же Google Trends)
  • Состоялся финальный релиз Angular 2
    –1
    Практически всем. Выше написал про реюз части шаблона без бойлерплейта компонента (и минусов компонента/директивы). Пропсы которые легко прокидывать, оверрайдить. В реакте компоненты на голову выше.
  • Состоялся финальный релиз Angular 2
    0
    Не так, Angular фрэймворк, а React библиотека. Хочется чтобы ангуляр был фреймворком поверх идей в React. Чтобы можно было просто взять Angular а там всё из коробки, сделали за тебя решение. Чтобы легко и быстро стартануть свой первый проект на React. Кстати как раз для этого появился оффициальный create-react-app (https://github.com/facebookincubator/create-react-app)
  • Состоялся финальный релиз Angular 2
    –9
    Я особо не следил за развитием ангуляра, но надеялся что они всё-же сделают нормальные компоненты. Это моя основная претензия к первому ангуляру. Хочется пропсов из React, хочется jsx like шаблоны. Но нет, к сожалению angular 2 не альтернатива React'у.
  • Состоялся финальный релиз Angular 2
    +5
    Чтобы в ангуляре переиспользовать часть шаблона — нужно городить компонент либо делать $compile, так было в первом так и осталось во втором. Всё еще директивы, так же убого выглядит template. Всё ещё остался двух-сторонний биндиг в лице NgModel, будем дальше городить странные компоненты форм. Это всё еще лапша из компонентов а не лаконичное f(state) = DOM. Travel Debugging без плясок невозможен. Появился какой-то АОТ компилятор, но он не поможет если я хочу делать темплейты в рантайме, когда нельзя просто сделать For и нельзя завязываться на конкретный компонент.

    React как библиотека дает надежный фундамент, да в каждой команде есть свой набор обвязок, но это не минус приложений на реакте, а плюс. Плюс который показывает всю гибкость подхода и неограниченное число возможностей.
  • Состоялся финальный релиз Angular 2
    0
    «Желательно знание jquery, backbone, react, angular»
  • Состоялся финальный релиз Angular 2
    –6
    Сделали улучшенную версию AngularJS =\ Недо-компонентный подход.
    Мир будет дальше гавно кодить. Только конечно TypeScript завели, самый большой плюс наверное.
  • Удостоверяющий центр из Китая по ошибке выдал пользователю SSL-сертификат для домена GitHub
    0
    Спасибо за ликбез
  • ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет
    +1
    ARG89 Без проблем: https://www.youtube.com/watch?v=-Y4XS7ZtQ2g&index=2&list=PLeI8rYvNSwbX64S1js06pKbgNctnv3Uc7 :)
  • ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет
    0
    Обделили ссылочкой http://jetconf.by/
    Или JET Conf не проплатил? :trollface:
  • Удостоверяющий центр из Китая по ошибке выдал пользователю SSL-сертификат для домена GitHub
    0
    Хром использует системное хранилище сертификатов, afaik. Т.е. в самом хроме их нельзя посмотреть.
  • Удостоверяющий центр из Китая по ошибке выдал пользователю SSL-сертификат для домена GitHub
    +2
    В Firefox: Preferences -> Advanced -> Certificates -> View Certificates -> Удаляем все WoSign сертификаты.

    Пусть лучше показывается окно с ошибкой сертификата, чем вот так китайцы будут подкладывать нам свинью.
  • Scala vs Kotlin (перевод)
    +2
    Мощное заявление.
  • Scala vs Kotlin (перевод)
    +2
    Нельзя так просто впилить фичу в язык. Каждая новая фича будет взаимодействовать со всеми существующими фичами + будет влиять на существуещий код. Впиливать фичи и сохранять при этом обратную совместимость — дорого стоит.
  • Scala vs Kotlin (перевод)
    +1
    webassembly+es5 (javascript es5 — масло маслянное) же. Но суть не в этом, в Java notnull типы в обозримом будущем не впилят, Groovy так и останется скриптовым языком, и т.д. C++ не станет таким же безопасным как Rust, а в Go не добавят дженерики(citation needed). Scala/Clojure — это отдельный мир, Kotlin «паразитирует» на Java и это должно стать причиной его успеха.
  • Scala vs Kotlin (перевод)
    +3
    Ну почему, можно еще сравнивать по типизации(groovy vs продакшен языки), наличии рантайма(Scala Native vs JVM), различным гарантиям (Kotlin с notnull типами vs другие языки под JVM) и т.д.
  • Scala vs Kotlin (перевод)
    +3
    По синтаксису вижу в обоих вариантах — английский


    Хорошая шутка, я все же говорил что у Clojure Schema подобный синтаксис, а вот Kotlin — С подобный.
  • Scala vs Kotlin (перевод)
    +2
    В статье все-таки немного другой код и только для сравнения синтаксиса языков.

    Ну и для примера аналогичный Clojure код на Kotlin

    (->> (range) (filter even?) (take 10))
    range.asSequence().filter { it % 2 == 0 }.take(10)
    


    В чем преимущество? Преимущество Kotlin в том, что любой Java разработчик поймет Kotlin вариант, а вот поймет ли он семантику и синтаксис Clojure варианта?
  • Scala vs Kotlin (перевод)
    +2
    Это действительно очень нужный и полезный код. Как правило мы не считаем последовательности Фибоначчи и не генерируем четные числа.
  • Краткий обзор Kotlin и сравнение с C#
    0
    Ну мое мнение: C++ тормозит, да еще и падает с сегфолтами. А если серьезно то Kotlin генерирует байткод очень похожий на байкод языка Java, т.е. перформанс тут не будет отличаться от Java. Но т.к. в Kotlin например можно заинлайнить лямбду, то он даже выигрывает в производительности. И таких мелких примеров много, и еще больше будет (я очень жду связки when + sealed class).

    На jpoint и jet будут доклады от Дмитрия Жемерова про производительность Kotlin с JMH бенчмарками, рекомендую.
  • Краткий обзор Kotlin и сравнение с C#
    +3
    Джава тормозит? Можно поинтересоваться, что не тормозит?
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    > А если я уберу явное указание типа, то он не даст мне вызывать методы на этой штуке точкой, только «специальным оператором ?.». Это все по сути и является монадой Option.

    Это по сути является тем, что вы не можете вызывать на инстансе типа T? никаких методов, пока не сделается null-check. В рантайме естественно нету никаких T? а есть только T, и боже упаси нету Optional[T]. Монадой Option тут не пахнет.

    > его можно проверить только в runtime

    С поддержкой IDEA это не большая проблема. Yaml это посути замена properties, но не XML

    > А что это такое?

    Пожалуй гугл лучше справится с этой задачей
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    Статические методы отлично заменяются higher-order functions и extension functions, как еще может мешать отсутсвие статических методов?
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    > А как inline будет сочетаться с override?

    так как это применяется к higher-order functions то логично что никак, продолжать?

    Если говорить про interop, то это будет просто статический метод в соответсвующем пакете.
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    > хотя с Java такой «нестабильности» инспекций никогда не было

    была, после выхода java 8 инспекции могли подсвечивать правильный java 8 код, хотя поддержка джавы 8 была объявлена :) это так, почему-то вспомнил

    Если сравнивать с Java, то да, десятилетием разрабаттываемая поддержка джава действительно выглядит серьезнее и в ней меньше багов (хотя случаются)

    Но мой поинт был именно в том, что среди других альтернативных JVM языков, Kotlin имеет действительно хороший тулинг с рождения.
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    +1
    Ну не сахар это :) Это система типов блин, String? это именно тип, который может быть String | Null.

    Кстати подписочная модель дешевле чем в год по версии покупать, а еще подарили год, когда переходил на подписку. У меня стойкое ощущение что разозлились в основном те, кто пиратил :)
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    > Я за день использования зафайлил два бага (в идее), еще один не зафайлил, многие вещи работают через раз почему-то, хотя с Java такой «нестабильности» инспекций никогда не было.

    Баги в идеи у меня сыплются и без Kotlin, так же как они сыплются у меня в WebStorm.

    > По документации нет поиска, нет индекса, нет «use» как в Javadoc. Навигация по доке kotlin.collections и попытка там что-то найти — то еще удовольствие.

    site:kotlinlang.org bla-bla? pdf?

    В целом действительно, плагин отваливался в RC, потом починили. Теперь с каждым днем становится только стабильнее. Проблем с навигацией, инспекциями и подстветкой никогда не имел. Если сейчас взять груви или скалу, то Котлин плагин выглядит куда более зрелым. Прямо сейчас у парней сломалась подстветка груви в спок тестах, причем как в стабильной версии так и в eap.
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    > Допустим, я вам верю, хотя это не так. Как именно будут происходить compile-time проверки для результатов вызова Java-методов из внешних библиотек? Kotlin вводит для них понятие nullable-типа, т.е. делает инверсию: non-nullable типы становятся «по умолчанию», а nullable требуют специального обращения. И все nullable проходят все необходимые проверки, причем в runtime, потому что иначе все в рантайме просто развалится: в Java нельзя полагаться на результаты анализа внешних библиотек, в runtime может быть совершенно другой JAR с совершенно другой реализацией указанных интерфейсов. ManagedExecutorService и вот это все. В результате string? a = someFunc(); Type? b = a?.someMethod();, и все это в runtime будет полностью аналогично Option(someFunc()).map(_.someMethod). Такой же «кривой слой абстракции с runtime-penalty», как Option, только в профиль. Если очень прям так хотелось этого, можно было патч для javac написать, или annotation processor какой-нибудь, чтобы проверял наличие Optional в nullable-типах, а не аж целый язык изобретать.

    Хватит троллить, честное слово.
    1. Если мы говорим про чистый Котлин без вызова Java — то там в худшем случае есть nonNull проверки в начале метода.
    2. Если мы говорим про интероп Kotlin и Java, то на границе с Java создается nonNull check, что есть просто вызов функции.

    Никаких объектов и if(o.isPresent()) {o.get()}.

    Так что никак это не аналогично. Пожалуйста, разберитесь в субъекте, прежде чем обсуждать его.

    > Это не конспиративная теория, это бизнес. Точно так же Microsoft добавляет поддержку Linux повсюду не потому что уверовал в идеалы Free Software, и собирается выбросить виндовс и закружиться со Столлманом в радостном танце. Коммерческие компании не занимаются благотворительностью, они занимаются маркетингом, и Kotlin сделан чтобы заработать больше денег, а не чтобы сделать Java-программистов счастливыми и улыбающимися. Это не «плохо», это «реальность».

    А также реальность что JetBrains пишет внутри на Kotlin и делал язык в первую очередь для себя, маркетинга у них мало, в основном такое вот сарафанное радио. В отличии от M$ которые пропихивают за откаты продукцию в гос органы и в учебные заведения. Или вот, трек Kotlin на jetconf.by, как ты думаешь, сколько JetBrains заплатила за него? Ответ — 0.0$.

    > Spring Boot-то тут при чем?

    @EnableAutoConfiguration избавляет от большого колличества конфигураций, многое можно прямо в application.yml подхачить, а если нужен свой бин — то да, JavaConfig. Ваш легаси с XML, ну да, придется отставить XML видимо. Мои же два последних проекта были вообще без единого XML (если говорить про настройку фрэймворков).

    > я уже сделаю нужную страницу на JSF

    А потом это нужно поддерживать и дорабатывать, делать API для мобильного приложения и вот это все. Зато за пять минут наколенке! Кстати из последнего Technology Radar от ThoughtWorks JSF выпилили совсем, т.е. они признали технологию говном мамонта, такие дела.
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    Достаточно было прочитать первое предложение из доки, чтобы не писать столько бессмысленных вопросов: https://kotlinlang.org/docs/reference/inline-functions.html

    > JIT уже делает inlining

    Только когда глубина стека меньше 10, а в современных веб приложениях это примерно никогда.

    Спросите парней которе пишут под андроид, почему они повально побежали на Kotlin ;)
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    Что значит «попробуйте и поймете»? Я пишу на Котлин каждый день и не вижу проблем ни с туллингом ни с документацией.
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    +1
    > Сделали conditional dereference — круто, но это просто синтаксический сахар над Optional.map (Java) или Option.map (Scala).

    Вы всё напутали, это всё compile-time проверки, с соответствующим (то есть нулевым) влиянием на перформанс. Это первый язык на JVM который так _решил_ проблему Null. Именно решил, а не создал поверх кривой слой абстракции с runtime-penalty и назвал его Optional.

    > Java-код ведь не дает никаких гарантий относительно возврата NULL.

    Всё так, именно поэтому Котлин автоматически расставляет nonNull проверки на границе с Java кодом. А также обращает внимание на аннотации @Nullable/@Notnull

    > Scala с Java нормально кооперируются, даже EJB-контейнеры спокойно жуют Scala-классы.

    Со scala-lang.org:

    Accessing Java classes from Scala code is no problem at all. Using a Scala class from Java can get tricky, in particular if your Scala class uses advanced features like generics, polymorphic methods, or abstract types.

    По факту когда ты просто пишешь код на скале, а потом просто пытаешься вызвать его из Java получается куча странных имен и долларов в коде, но так и надо конечно, никаких проблем.

    > Попробуйте Lombok

    Летали, знаем, закапайте стюардессу.

    > JetBrains думает, что выпустив Kotlin сможет создать vendor-lock на свою платформу и доить клиентов, видимо, но вряд ли это сработает.

    Нужно больше конспиративных теорий! Еще раз, есть плагин для Eclipse, нравится Eclipse? Пользуйтесь им, в чем проблема. Также сообщество сделала подсветку в Sublime/Atom, возможно уже есть vim плагин.

    > но когда появляется десяток XML-конфигураций со ссылками на классы, а к ним еще сотня JSF-страниц

    На дворе вроде 2016, Spring-Boot без XML, REST и Angular.
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    А можно больше конкретики?
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    Там где в Java вы бы использовали Optional, вы не используете ничего, когда у вас есть маленькая вспомогательная функция — вы её инлайните. Думаю больше о производительности будет рассказано тут: http://javapoint.ru/talks/jemerov/
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    –1
    Jtalk Конечно открытой IDE и плагина для эклипса недостаточно чтобы победить Java, именно поэтому в котлине решена «billion-dollar mistake», идеальный интероп с джавой. Рантайм очень маленький(6К методово, 500кб) и скорость кода на Котлине зачастую превосходит джава код, и при этом глаза не обязаны фильтровать тонны мусора. Время компилиции такое-же как у Java, идеальная поддержка в той же открытой IDE(Intellij Idea Community Edition, Android Studio).

    Scala — тормозит в IDE и при сборке проекта, не интерабельна с джавой (в обе стороны) и имеет слишком богатую библиотеку.
    Groovy — заслужил звания языка с пазлерами, и в первую очередь для многих это динамический язык со всеми вытекающими.
    Gosu, Phantom — очевидно эти языки изначально были мертворожденными, за ними никто не стоит их никто не продвигает.
    Ceylon — хорошая попытка, действительно интересный язык… Но он напоминает Scala со своими наваторскими идеями и задвигает интероп с Java на второй план.

    Итого получается что Kotlin это тот язык который имеет смысл тянуть в существующий проект, использовать его бок обок с написанным Java кодом, при этом это современный язык, с высокими гарантиями безопасности(smart-casts,NPE-free code) и умным компилятором.

    Так какие объективные причины не взлететь Kotlin?
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    –3
    Мне интересно, все те люди которые в опросе «Используется ли Kotlin в вашей компании?» ответили «Нет, и не собираемся пробовать» не знают что такое Котлин, или у них какие-то объективные причины? Потому что из всех JVM языков, Котлин единственный который может конкурировать с Java.
  • Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE
    0
    > Какие JVM-языки (помимо Java) вы используете в production?

    Сюда явно можно относить только тот код, который бежит на проде.

    > Используется ли X в вашей компании?

    А вот сюда как раз «вы знаете X» и «написали один класс для билда в проекте на X»