Re: Интересное мнение про перспективы .NET

[reality]

Ну и конечно паттерн мэтчинг и algebraic data types ну очень крутые фичи.

А вообще если будет интересный проект на Java то пойду писать обратно на Java. Но плюсы проекта должны перевесить всю боль и страдания )

[reality]

Ну так на джаве есть все те же future и optional, а чем принципиально NPE отличается от optional unset я не сильно понимаю.

Про теорию категорий и монады я не силен рассказывать. Просто надо почувствовать всю мощь и красоту

Java Future это вообще черт знает что непонятно зачем нужно. ListenableFuture еще куда не шло, но опять же это совсем не то что map/flatMap и прочие комбинаторы. Тоже самое с Optionable из Java8. Что то не доделанное, без map/flatMap абсолютно бесполезное, а без ADT так и вообще ценность 0.

Вот кложуры в 8ке эта да клево. А так больше шума по моему.

[crypto5]

Ну и конечно паттерн мэтчинг и algebraic data types ну очень крутые фичи.

Думаю случаев когда бы они не заменялись обычными джавовскими if statements & enums исчезающе мало.
Ну или пример в студию.

[crypto5]

Ну так на джаве есть все те же future и optional, а чем принципиально NPE отличается от optional unset я не сильно понимаю.

Про теорию категорий и монады я не силен рассказывать. Просто надо почувствовать всю мощь и красоту

Java Future это вообще черт знает что непонятно зачем нужно. ListenableFuture еще куда не шло, но опять же это совсем не то что map/flatMap и прочие комбинаторы. Тоже самое с Optionable из Java8. Что то не доделанное, без map/flatMap абсолютно бесполезное, а без ADT так и вообще ценность 0.

Вот кложуры в 8ке эта да клево. А так больше шума по моему.

Вы можерте конкретный пример привести где скала в 5 раз продуктивнее или нет? Что именно не так с джавовскими futures?
А то у вас вся полемика строится: "вот в скала экзестенциональные типы это да, джава атстой"

[crypto5]

Мне кстати кажется после общения с комьюнити в последнее время что скала это как раз отличный признак компаний/проектов куда попадать не надо не в коем случае, там куча людей которые умеют хорошо "бла-бла-бла апликативные функторы", а вот код хороший писать и внятно и доходчиво обьяснять свою точку зрения это не к ним.

[reality]

Думаю случаев когда бы они не заменялись обычными джавовскими if statements & enums исчезающе мало.
Ну или пример в студию.

Таких случаев конечно же нету, при желании можно все что угодно заменить ифами. Только читаемость кода уменьшается на порядок. Больше трех ифов подряд и уже код нечитаем, а с ADT и pattern matching можно смело 10 различный типов разрулить в одном методе абсолютно прозрачно для читающего код, и уместить все это в 15-20 строчек. Нет под рукой открытой IDE чтобы вставить пример.

А вообще речь была о том что скала она как бы мертва и никому не нужна и вообще сдулась. А я вот говорю что в НЙ со скалой все очень хорошо. И в СФ насколько знаю тоже все очень в порядке. Вакансий не сотни но уже достаточно для того чтобы обратить на язык внимание. Даже если бы не было вакансий все равно можно было бы обратить внимание потому что есть много интересных концепций после которых и на Java писать можно более осмысленно и "чисто". И на Haskell тоже можно глянуть. Но это конечно если есть на это время и еще не потерян вкус к профессии.

[reality]

Что именно не так с джавовскими futures?
А то у вас вся полемика строится: "вот в скала экзестенциональные типы это да, джава атстой"

Есть у вас Future<Int> future1 = … и Future<Int> future2 = … с данными приходящими вот по сети к примеру. И нужно вам умножить два этих числа и сделать третий Future<Int> future3 с их произведением. Как вы будете делать это на Java?

[reality]

Мне кстати кажется после общения с комьюнити в последнее время что скала это как раз отличный признак компаний/проектов куда попадать не надо не в коем случае, там куча людей которые умеют хорошо "бла-бла-бла апликативные функторы", а вот код хороший писать и внятно и доходчиво обьяснять свою точку зрения это не к ним.

Есть и такие.

[crypto5]

Что именно не так с джавовскими futures?
А то у вас вся полемика строится: "вот в скала экзестенциональные типы это да, джава атстой"

Есть у вас Future<Int> future1 = … и Future<Int> future2 = … с данными приходящими вот по сети к примеру. И нужно вам умножить два этих числа и сделать третий Future<Int> future3 с их произведением. Как вы будете делать это на Java?

В джава 8 будет что то вроде new Future<Long>((f1, f2) -> f1.get() + f2.get()); ?

[reality]

Что именно не так с джавовскими futures?
А то у вас вся полемика строится: "вот в скала экзестенциональные типы это да, джава атстой"

Есть у вас Future<Int> future1 = … и Future<Int> future2 = … с данными приходящими вот по сети к примеру. И нужно вам умножить два этих числа и сделать третий Future<Int> future3 с их произведением. Как вы будете делать это на Java?

В джава 8 будет что то вроде new Future<Long>((f1, f2) -> f1.get() + f2.get()); ?

Ага и будет блокировка потока. А если это все работает поверх NIO (Netty к примеру) и поток ну никак блокировать нельзя.

[crypto5]

Что именно не так с джавовскими futures?
А то у вас вся полемика строится: "вот в скала экзестенциональные типы это да, джава атстой"

Есть у вас Future<Int> future1 = … и Future<Int> future2 = … с данными приходящими вот по сети к примеру. И нужно вам умножить два этих числа и сделать третий Future<Int> future3 с их произведением. Как вы будете делать это на Java?

В джава 8 будет что то вроде new Future<Long>((f1, f2) -> f1.get() + f2.get()); ?

Ага и будет блокировка потока. А если это все работает поверх NIO (Netty к примеру) и поток ну никак блокировать нельзя.

Во первых не будет, fork-join pool все разрулит, во вторых ну и что что будет? Треды сейчас супердешевые, как доказательство можно посмотреть как весь из себя асинхронный плей сливает сервлетам на бенчмарках

[reality]

А все кстати потому что Future в Java не монада. Хотя я конечно понимаю что монада для вас наверное звучит как ругательство, но концепция она очень мощная.

[reality]

Во первых не будет, fork-join pool все разрулит, во вторых ну и что что будет? Треды сейчас супердешевые, как доказательство можно посмотреть как весь из себя асинхронный плей сливает сервлетам на бенчмарках

Ну так у вас Netty к примеру, и нету никаково форк-джойна, и надо все это сделать асинхронно.

Про дешевые потоки и форк-джойн все разрулит не верю. Точнее точно знаю что не работает. Ну не будет летать 10000 потоков, перключене контекста все убьет. А плей тормозит по совсем другим причинам. Нетти то летает, а он весь из себя асинхронный. Просто плей кривая пристроечка поверх нетти.

[crypto5]

Во первых не будет, fork-join pool все разрулит, во вторых ну и что что будет? Треды сейчас супердешевые, как доказательство можно посмотреть как весь из себя асинхронный плей сливает сервлетам на бенчмарках

Ну так у вас Netty к примеру, и нету никаково форк-джойна, и надо все это сделать асинхронно.

Про дешевые потоки и форк-джойн все разрулит не верю. Точнее точно знаю что не работает. Ну не будет летать 10000 потоков, перключене контекста все убьет. А плей тормозит по совсем другим причинам. Нетти то летает, а он весь из себя асинхронный. Просто плей кривая пристроечка поверх нетти.

fork join pool-у не нужно 10000 тредов, в момент когда вызовется f1.get() он увидит что поток заблокирован, и вернет выполнение тела future обратно в очередь executorservice-a, пока f1 не разблокируется.

[reality]

fork join pool-у не нужно 10000 тредов, в момент когда вызовется f1.get() он увидит что поток заблокирован, и вернет выполнение тела future обратно в очередь executorservice-a, пока f1 не разблокируется.

Поток вызвавщий get() перейдет в WAITING/TIMED_WAITING состояние и будет висеть в Fork-Join пуле не давая выполняться другим таскам. Никуда он не уйдет ни в какую очередь или пул. Операционная система будет все это дело разруливать. По этому кстати в форк-джойн пуле точно так же как и в нетти и где угодно еще не рекомендуется выполнять блокирующие таски. А для блокирующих задач надо делть свой bounded ThreadPool отдельный.

Форк-джойн пул он не волшебник.

[reality]

Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.

[Интеррапт]

Форк-джойн пул он не волшебник.

Ну и при чем здесь Scala и как Scala в данном вопросе поможет?

[crypto5]

Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.

Это обычный pool будет пухнуть, а фишка fork join-a что он будет работать так как я описал. Там правда нужно вместо Future получать ForkJoinTask из forkJoinPool.

[stenking]

Фрамиворк кушает пол мега памяти а во время как джава уже подбирается к пол-гига:)

Это там указано про 0.7 MB per request, а не всего, сколько отожрет сам PHP с этим фреймворком Т.е. просто при поступлении одного запроса от сервера - сразу же отожрется эти самые 0.7 MB. Нормальные фреймворки под Джава никак не кушают пол гигабайта per request, так что сравнение некорректное.

Нет, это тотал. Ну и ещё в PHP практически нет шаред ресорсов - т.е. один request: 0.7MB, два: 1.4 и т.д.

Стенкин, а как так получается что ваш супербыстрый фреймворк отстает от джавы по производительности в 10 раз? http://www.techempower.com/benchmarks/

Хорошо, я обьясню вам как работает PHP в примитивном виде . Сначала парсится сорс код и комприлируется в opcode который потом выполняется. Практически все бенчмарки именно подразумевают такой вот вид теста. Но какой смысл в таком тесте когда это используется только для удобства разработки а в продакшине всегда стоит какой-то вид opcode кеш.

Это как скажем протестировать сколько миль вы можете пробежать через секунду после того как вас разбудить и ещё ударить по голове сковородкой:)

Что такое PHP на самом деле? Это просто много дополнительных функций С просто завёрнутые в другое название и опкод который исполняется он не сильно отличается от голого С. А вот такой настоящий тест не только даёт производительность выше чем у Джавы а ещё и огромную разницу в памяти, всё таки zend engine намного качественнее JVM написанной поколениями индусами

[Интеррапт]

Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.

Это обычный pool будет пухнуть, а фишка fork join-a что он будет работать так как я описал. Там правда нужно вместо Future получать ForkJoinTask из forkJoinPool.

Тут reality прав, кстати, что ForkJoin не предназначен для большого кол-ва потоков, которые могут долго блокироваться, так как нет смысла от хардварного параллелизма для, например, ожидания данных из сети. ForkJoin имеет смысл применять в основном только для ресурсоемких (в смысле процессора) и неблокирующих (по крайней мере на какое-то заметное время) подзадач.

[rorp]

Вы можерте конкретный пример привести где скала в 5 раз продуктивнее или нет?

Вот простой пример.

Дано: типа есть у нас распарсенная QUERY_STRING в виде мапы, в которой ключи -- это названия параметров, а значения коллекции их значений (каламбур вышел ). Требуется взять первое значение заданного параметра и сделаить с ним что-нибудь (например перевети в нижний регистр). Для простоты считаем что все параметры не могут быть null.

На скале мы делаем так:

Code: Select all

  def processFirstValue(name: String, query: Map[String, Seq[String]])(processor: String => String): Option[String] = {
    for {
      values <- query.get(name)   // берем список значений по заданному имени
      value  <- values.headOption // берем самое первое значение из списка
    } yield processor(value)      // делаем с ним что-нибудь и возвращаем

    // если чё, то эта кострукция for просто синтаксический сахар для композиции монад:
    // query.get(name).flatMap(_.headOption).map(processor)
  }

Теперь на жабе:

Code: Select all

    // блин, тут простым if-ом не обойтись. Ладно, curring в жабовской версии делать не будем
    public interface Function1<T1, R> {
        R apply(T1 arg1);
    }

    public String processValue(String name, Map<String, Collection<String>> query, Function1<String, String> processor) {
        String result = null;

        // берем список значений по заданному имени
        Collection<String> values = query.get(name);
        if (values == null)
            return result;
        
        // берем самое первое значение из списка
        String value = null;
        for (String v : values) {
            value = v;
            break;
        }
        if (value == null)
            return result;

        // делаем с ним что-нибудь и возвращаем
        return processor.apply(value);
    }

[crypto5]

Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.

Это обычный pool будет пухнуть, а фишка fork join-a что он будет работать так как я описал. Там правда нужно вместо Future получать ForkJoinTask из forkJoinPool.

Тут reality прав, кстати, что ForkJoin не предназначен для большого кол-ва потоков, которые могут долго блокироваться, так как нет смысла от хардварного параллелизма для, например, ожидания данных из сети. ForkJoin имеет смысл применять в основном только для ресурсоемких (в смысле процессора) и неблокирующих (по крайней мере на какое-то заметное время) подзадач.

Это ерунда, fork join pool как раз для большого количества тасков, которые блокируют друг друга, fork join pool трекает блокирующие зависимости и следит за тем что-бы task-a включалась когда не заблокирована, и выключалась когда заблокирована. Соответственно туда и ожидание сети можно заинтегрировать.

[vladich]

Java все-таки слишком олд скульный язык. Ни паттерн матчинга ни монад ни континуейшнз.
Хоть лямбды добавили через 20 лет после создания языка и то хорошо, а то ведь стыдоба просто была .
Без лямбд асинхронный любой код писался довольно многословно и корявенько. Если б континуэйшнз добавили как в C#, можно было бы что-то вроде async/await реализовать и вообще была бы красота. Я б и отсутствие паттерн матчинга ей бы простил.

[crypto5]

Фрамиворк кушает пол мега памяти а во время как джава уже подбирается к пол-гига:)

Это там указано про 0.7 MB per request, а не всего, сколько отожрет сам PHP с этим фреймворком Т.е. просто при поступлении одного запроса от сервера - сразу же отожрется эти самые 0.7 MB. Нормальные фреймворки под Джава никак не кушают пол гигабайта per request, так что сравнение некорректное.

Нет, это тотал. Ну и ещё в PHP практически нет шаред ресорсов - т.е. один request: 0.7MB, два: 1.4 и т.д.

Стенкин, а как так получается что ваш супербыстрый фреймворк отстает от джавы по производительности в 10 раз? http://www.techempower.com/benchmarks/

Хорошо, я обьясню вам как работает PHP в примитивном виде . Сначала парсится сорс код и комприлируется в opcode который потом выполняется. Практически все бенчмарки именно подразумевают такой вот вид теста. Но какой смысл в таком тесте когда это используется только для удобства разработки а в продакшине всегда стоит какой-то вид opcode кеш.

С чего вы взяли что в приведенном мной бенчмарке на каждой итерации парсятся срцы? Вот тут внятно написано что юзается php apc: https://github.com/TechEmpower/Framewor ... lcon-micro

Что такое PHP на самом деле? Это просто много дополнительных функций С просто завёрнутые в другое название и опкод который исполняется он не сильно отличается от голого С. А вот такой настоящий тест не только даёт производительность выше чем у Джавы а ещё и огромную разницу в памяти, всё таки zend engine намного качественнее JVM написанной поколениями индусами

Вы какую то совсем ересь несете..

[crypto5]

Вы можерте конкретный пример привести где скала в 5 раз продуктивнее или нет?

Вот простой пример.

Дано: типа есть у нас распарсенная QUERY_STRING в виде мапы, в которой ключи -- это названия параметров, а значения коллекции их значений (каламбур вышел ). Требуется взять первое значение заданного параметра и сделаить с ним что-нибудь (например перевети в нижний регистр). Для простоты считаем что все параметры не могут быть null.

На скале мы делаем так:

Code: Select all

  def processFirstValue(name: String, query: Map[String, Seq[String]])(processor: String => String): Option[String] = {
    for {
      values <- query.get(name)   // берем список значений по заданному имени
      value  <- values.headOption // берем самое первое значение из списка
    } yield processor(value)      // делаем с ним что-нибудь и возвращаем

    // если чё, то эта кострукция for просто синтаксический сахар для композиции монад:
    // query.get(name).flatMap(_.headOption).map(processor)
  }

Теперь на жабе:

Code: Select all

    // блин, тут простым if-ом не обойтись. Ладно, curring в жабовской версии делать не будем
    public interface Function1<T1, R> {
        R apply(T1 arg1);
    }

    public String processValue(String name, Map<String, Collection<String>> query, Function1<String, String> processor) {
        String result = null;

        // берем список значений по заданному имени
        Collection<String> values = query.get(name);
        if (values == null)
            return result;
        
        // берем самое первое значение из списка
        String value = null;
        for (String v : values) {
            value = v;
            break;
        }
        if (value == null)
            return result;

        // делаем с ним что-нибудь и возвращаем
        return processor.apply(value);
    }

Какая то совсем плоская шутка получилась..