Kotlin + React vs Javasript + React

Я без плагинов жил, нормально. Там есть проблемы, безусловно. Например, нет адекватного способа сериализовать KClass. Когда пишешь общую библиотеку, надо везде таскать KClass, чтобы потом им пользоваться (правда на такой глубине использования грех жаловаться). Ещё там какая-то странная логика при кастомных геттерах, лучше туда не лезть.
А так, пишешь data class простенький, помечаешь аннотаций и всё работает на ура.

Kotlin + React vs Javasript + React

что все ожидаемые поля есть, они могут конвертиться в нужные типы и что они не null, если так объявлено поле. И так по цепочке во всех вложенных объектах.

Kotlin + React vs Javasript + React

Если уж так рассуждать, то flow и TypeScript «забудутся и устареют». Но всё совсем не так. Каждая технология занимает свою нишу и время. JS будет жить очень и очень долго, просто потому что он живет в браузере. flow, TypeScript, React, redux, RxJs, Kotlin — это всё толи паразиты, толи симбионты. Они решают типовые проблемы, которые сам JS не спешит решать, а если решает, то медленно (ESтакой-то). В Java мире тоже самое: Kotlin решаем набор наболевших проблем. Кто-то готов ради этого учить новое, кто-то нет. И везде встречается костность людей. «Работает и хорошо», особенно, если это большая компания, где польза от новой технологии обычно перевешивается тонной легаси, необходимостью обучения всех и выроботки стандартов работы.

Kotlin + React vs Javasript + React

Класс, буду знать

Kotlin + React vs Javasript + React

Ни в коем случае не выступал против React. Я даже не выступал против JavaScript. Скорее о том, что если интересна строгая типизация на фронте, то есть хорошей язык для этого.
Никогда не сравнивал звезды, но не стал бы пытаться сравнивать язык и фреймворк.

Kotlin + React vs Javasript + React

Проблемы были бы примерно теже. TypeScript практически ничего не вносит нового, кроме адекватного наследования по сравнению с flow (могу ошибаться, не так много на нем писал). При этом у него всё таже проблема: нет гарантий того, что скомпилиный код будет работать так, как предполагалось. Когда я узнал, что степень строгости компиляции нужно указывать в конфигах и по-умолчанию она совсем слабая, я совсем растроился

Java 8 и паттерн Стратегия

Мне как-то ни разу не приходилось использовать Стратегию всместе с наследованием, но если очень хочется:

import java.util.HashMap;
import java.util.Map;
import java.util.function.Consumer;

public abstract class Duck<T extends Duck> {
    private final String name;

    public Duck(String name) {
        this.name = name;
    }

    abstract public T getDuck();

    private Map<Language, Consumer<T>> greetings = new HashMap<>();

    public void addGreeting(Language language, Consumer<T> greeting) {
        greetings.put(language, greeting);
    }

    public void greet(Language language) {
        greetings.get(language).accept(getDuck());
    }

    public String getName() {
        return name;
    }

    public static void main(String[] args) {
        DuckWithAge donald = new DuckWithAge("Donald", 18);
        donald.addGreeting(Language.RUS, duck -> System.out.println("Привет, я " + duck.getName() + " мне " + duck.getAge()));
        donald.addGreeting(Language.ENG, duck -> System.out.println("Hello, I'm " + duck.getName() + " I'm " + duck.getAge()));

        donald.greet(Language.RUS);
        donald.greet(Language.ENG);
    }

    public enum Language {
        RUS,
        ENG
    }

    public static class DuckWithAge extends Duck<DuckWithAge> {
        private final int age;

        public DuckWithAge(String name, int age) {
            super(name);
            this.age = age;
        }

        public int getAge() {
            return age;
        }

        @Override
        public DuckWithAge getDuck() {
            return this;
        }
    }
}

Наверное, есть и более элегантные варианты, в Kotlin я бы просто extension сделал бы:

fun <T: Duck> T.add(language: Language, greeting:(T) -> Unit) {}

Java 8 и паттерн Стратегия

в классической имплементации Стратегии это тоже невозможно, так как Duck всё-равно будет один, без иерархии

Java 8 и паттерн Стратегия

import java.util.HashMap;
import java.util.Map;
import java.util.function.Consumer;

public class Duck {
    private final String name;

    public Duck(String name) {
        this.name = name;
    }

    private Map<Language, Consumer<Duck>> greetings = new HashMap<>();

    public void addGreeting(Language language, Consumer<Duck> greeting) {
        greetings.put(language, greeting);
    }

    public void greet(Language language) {
        greetings.get(language).accept(this);
    }

    public String getName() {
        return name;
    }

    public static void main(String[] args) {
        Duck donald = new Duck("Donald");
        donald.addGreeting(Language.RUS, duck -> System.out.println("Привет, я " + duck.getName()));
        donald.addGreeting(Language.ENG, duck -> System.out.println("Hello, I'm " + duck.getName()));

        donald.greet(Language.RUS);
        donald.greet(Language.ENG);
    }

    public enum Language {
        RUS,
        ENG
    }
}

Java 8 и паттерн Стратегия

Будет функциональный вариант приспособленца:

Consumer<Duck>

вместо Runnable.

Как программисты-самоучки в реальности получают работу

Зачем крайности? Надо учиться равномерно, практика должна идти в ногу с теорией.
Есть книги, ценность которых раскрывается при наличии практики на ту же тему.
Есть книги, в которых рассказывают о стандартных и не очень ошибках и тебе не придется натыкаться на них самому.
Есть книги с чистой теорией, которые абсолютно ортогональны тому что, получаешь из практики.
И если первые два типа увеличивают эффективность практики, то последние вкупе с практикой создают целостную картину мира.

Почему один процесс NGINX берёт на себя всю работу?

Более того, когда будет загружен только один процессор, остальные будут свободно обслуживать систему (хрон, другие программы, программист зашёл логи посмотреть...). Меньше шансов, что подобные мелочи будут влиять на производительность приложения.

Послевкусие от Kotlin, часть 3. Корутины — делим процессорное время

много проблем с тестами такого плана

Специально писал такие тесты, чтобы было поближе к жизни. Вряд ли кто-то ради корутин слезет со спринга. А вот на Jetty пересесть можно. Примерно глянул в ту сторону, к Jetty можно свой тред пул подбросить. Но надо разбираться, что от этого пула ждет сам Jetty, так что углубляться пока не стал.

Послевкусие от Kotlin, часть 3. Корутины — делим процессорное время

Корутины тоже существуют только в рантайме языка и используют тред пул, если можно так выразиться, как среду исполнения. Насколько я понимаю, переключения контекстов минимальны — таски подбрасываются в очередь для CommonPool и потоки оттуда их забирают, не отдавая контроль операционной системе.

Сейчас для интереса запустил миллион корутин у себя на компе (простой async/await). Заняло 830мс, отъело 1,3 Мб, т.е. 132 бита на корутину. Замер пальцем в небо, без прогрева и т.д., но порядок такой.

Послевкусие от Kotlin, часть 2

У меня проект на Spring Boot, Hibernate и JSF, final решается на раз плагином
С интерфесами вряд ли будут проблемы, я говорил про наследование классов.
Насчет 100% — да, я не стал это упоминать в статье и не считаю это «нарушением интеропа», так как причиной этому то, что в Kotlin немного больший функционал (в основном, за счет компилятора), чем в Java, и, естественно, к нему нет прямого доступа из Java.

а еще косяки с дженериками

Это вы о чем?

Послевкусие от Kotlin, часть 2

Я полгода пишу на Kotlin, и всё что смог припомнить:
1. Extension написанный на Kotlin нельзя вызвать из Java. Было бы странно, если бы можно было.
2. Если написать на Kotlin класс и отнаследоваться от него на Java, могут возникнуть некоторые сложности.

Послевкусие от Kotlin, часть 2

Практический результат — написанный проект мне нравиться, язык действительно помогает сделать код безопаснее, код хорошо читается. К сожалению, влияние в мелочах, поэтому ужать всё это в одну статью не получилось.

Послевкусие от Kotlin, часть 2

В случае assertFail это не сработает, так как нет объекта, из которого можно вытащить T. А механизм один.

Послевкусие от Kotlin, часть 2

В примере с репозиторием параметр шаблона T выводится из скрытого параметра метода this (вроде бы).

Решил объяснить как работает эта магия. Из this T в общем случае не выведешь, насколько я помню. Я когда-то пробовал, решил что легче каким-то образом передавать Class T. Источник

Послевкусие от Kotlin, часть 2

Это inline функция, она не существует в runtime, вместо этого она разворачивается при компиляции в месте использования. Поэтому, T доступно — в compile time она ещё не стерта