02.08.2017 19:26
Strain 652 35000 Источник


Сообщество nodejs безумно, и судя по тому что в 2016-2017 годах в различных рейтингах JavaScript брал первое место по популярности вытеснив оттуда с небольшим отрывом Java — безумие в последнее время действительно станосится массовым. Казалось бы — не хочешь не кушай, пиши на своём любимом Elixir / Erlang / Lisp / Haskell / любом другом языкое с хорошим дизайном и в ус не дуй, но в текущей ситуации к сожалению это правило перестаёт работать и приходится прилагать некоторые усилия чтобы его соблюдать.

В чём причина популярности такого реально хренового языка как JavaScript? В принципе в том же в чём и причина популярности Java, да и вообще почти всех явлений культуры и общества — в бабле. Когда такие гиганты как Facebook, Google, Microsoft и Twitter методично вливают многомиллионные потоки кровавых долларов в JavaScript инфраструктуру, пишут фреймворки, библиотеки, придумывают стандарты и архитектуры — становится действительно трудно это игнорировать. Настолько сильное вливание бабла вызывает бешеный хайп-драйвен-девелопмент. Работодатель хочет видеть у себя React, Redux, Relay, Realm, Flux, Babel, Webpack / Grunt / Brunch и ещё с десяток модных слов от наших любимых корпораций которых я даже не знаю. И ещё всё это приправлено сверху кучей плагинов для этих же технологий, всех сортов и расцветок из нашего любимого npm. Технологии от корпораций для того чтобы у нас были технологии от корпораций и минифицированный js-бандл весом 15Мб для простого SPA, о да.

В какой-то момент огромный спрос на разработку на действительно ужасном языке породил огромное множество порой довольно странных компиляторов в JavaScript из других, более приемлимых языков. Вполне логично, разработчики мучимые сильнейшим когнитивным диссонансом ( хочу денег, но не хочу JS ) как-то пытались ( и пытаются ) уменьшить боль от разработки на JavaScript. Лично я пробовал довольно много языков из этого списка, какое-то время писал на CoffeeScript подобных языках, наиболее удачный пример LiveScript — из коробки карринг, пайпы, отсутствие дурацких скобочек, точек с запятой, циклов и return-ов. Пробовал даже PureScript — пример компиляции Haskell кода ( с иммутабельностью, монадами и чудесной системой сильных типов ) в JavaScript. На деле же конечно все эти языки не являются коммерчески востребованными по очевидным причинам — нет миллионных вливаний от корпораций в развитие инфраструктуры. Если бы таковые были — зуб даю, все поголовно бы писали на Haskell и рассказывали бы друг другу за чашечкой смузи покручивая спиннер о новых монадах и аппликативных функторах от Facebook.

Казалось бы, меня как backend-девелопера это вообще не должно волновать — пусть будет npm мракобесие на фронтенде, у меня то тут порядочек, кошерное ламповое OTP прямо как в 1986. Но рано было расслабляться — они вырвали JS движок из браузера потащили эту субстанцию на backend, причём с абсолютно серьёзным выражением лица. Ведь одно дело писать на этом языке какой-нибудь SPA, и совсем другое дело какой-нибудь критически важный биллинг. Но JavaScript теперь на backend, отлично.

  • однопоточный рантайм ( в 2017 году!!! )
  • отсутствие единой системы / стандартов реализации модулей ( опять же, 2017 год на дворе )
  • отсутствие единых стандартов структуры проекта ( все творят как хотят, в исходниках бывает очень сложно разобраться )
  • слабые типы с неявными ( и порой довольно странными ) преобразованиями
  • отсутствие нормальных классов / ООП
  • отсутствие единого вменяемого и работающего статического анализатора кода ( добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function )
  • отсутствие вывода типов в самом языке или в каком-либо инструменте
  • этот чудесный контекст this ( что это значит this в этом месте кода — объект? функция? )
  • абсолютно дурацкая реализация pattern matching ( паттерн матчишь пустой список / объект — без проблем, извлекаешь оттуда undefined, ты же именно это имел ввиду, да? ) и здесь опять привет cannot read property foo of undefined
  • отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async ( если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку )
  • const ( который на самом деле НЕ const )
  • абсолютно безумный npm с пакетами качества «братишка я тебе покушать принёс» ( и даже вот с таким )

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

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

Комментарии (652)


  1. aen
    02.08.2017 22:29
    #10340448
    +48

    Какая-то бессмысленная истерика.


    1. Strain
      02.08.2017 22:34
      #10340450
      -13

      Не истерика а набор фактов и вопрос «почему всё так?» к обсуждению


      1. vilgeforce
        03.08.2017 00:35
        #10340610
        +15

        В чем факт ужасности return? В том, что не нравится лично вам, не иначе.


        1. torbasow
          03.08.2017 09:10
          #10340878
          +1

          Чем плох return, я могу предположить. Когда у функции несколько точек выхода, это не очень надёжная конструкция. Или, вот, когда return выходит не из метода, а из малозаметной стрелочной функции внутри него, это может оказаться коварной неожиданностью.
          Но фигурные скобочки и точка с запятой… Тут я теряюсь.


          1. S_A
            03.08.2017 09:26
            #10340902
            +2

            Единственная проблема с return в JS — нельзя перенести возвращаемое на следующую строку (будет undefined если перенести).


          1. vintage
            03.08.2017 09:33
            #10340916
            +6

            Или, вот, когда return выходит не из метода, а из малозаметной стрелочной функции внутри него, это может оказаться коварной неожиданностью.

            return такого не умеет.


            1. mayorovp
              03.08.2017 09:41
              #10340936
              -12

              function foo() {
    var f = () => {
        return 42;
    };
    f();
}

console.log(foo()); // undefined


              1. AndreyRubankov
                03.08.2017 10:04
                #10340992
                +11

                Известно, что функция может возвращать значение только через return (а стрелочная может и без него),
                и тут назревает логичный вопрос: Если в конце тела функции нету return, то в чем здесь проблема в языке или в том, кто даже основ языка не прочитал?


              1. vintage
                03.08.2017 10:11
                #10341018
                +6

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


                1. mayorovp
                  03.08.2017 10:12
                  #10341020
                  -1

                  Ничего не ожидал. Я продемонстрировал что return умеет выходить из стрелочной функции.


                  1. vintage
                    03.08.2017 10:23
                    #10341052
                    +9

                    Я изменил тот комментарий.


                    Было бы странно, если бы return выходил сразу из нескольких функций.


                    1. mayorovp
                      03.08.2017 10:26
                      #10341060
                      -1

                      Да, это и правда было бы странно (хотя в Scala вроде как return так и работает). Но искать точку выхода из переусложненной функции эта странность не помогает :-)


                      1. TheShock
                        03.08.2017 20:02
                        #10342252
                        +1

                        А зачем писать переусложненные функции?


                        1. mayorovp
                          04.08.2017 12:40
                          #10343436
                          -1

                          Я не знаю зачем их пишут. Но читать их мне периодически приходится.


                  1. Apx
                    03.08.2017 20:12
                    #10342274
                    +1

                    Ну хотя бы правильный пример для начала надо было написать. Потому что из примера нихрена оно не демонстрирует. Точнее не так: пример был о том что «если хочешь вернуть значение из функции — используй return». Стрелочная функция, как видно из названия — функция. Демо return statement то зачем?


                    1. mayorovp
                      04.08.2017 12:51
                      #10343478

                      Это (пере)упрощенный пример переусложненного метода. Тот, кто хочет выяснить почему foo() возвращает undefined, смотрит внутрь, находит return… а return-то возвращает значение не из внешней функции, а из внутренней.


                      Вот более жизненный пример: https://github.com/jquery/jquery/blob/731c501155ef139f53029c0e58409b80f0af3a0c/src/ajax.js#L386


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


              1. franzose
                03.08.2017 11:22
                #10341210

                Вы ожидали, что console.log выдаст 42?


                1. mayorovp
                  03.08.2017 11:23
                  #10341216
                  -5

                  Ничего не ожидал. Я продемонстрировал что return умеет выходить из стрелочной функции.


                  1. quantum
                    03.08.2017 13:23
                    #10341514

                    Как бы return выходит из той функции, которойнаписан


                    1. mayorovp
                      03.08.2017 13:28
                      #10341530

                      Ну да, так и есть.


              1. Ryss
                03.08.2017 13:23
                #10341516
                +4

                function foo() {
    var f = () => {
        return 42;
    };
    return f();
}

console.log(foo()); // 42


                Вы ожидайте результат функции, которую не возвращаете


                1. mayorovp
                  03.08.2017 13:29
                  #10341534
                  -3

                  Ничего не ожидал. Я продемонстрировал что return умеет выходить из стрелочной функции.


                  1. YemSalat
                    04.08.2017 23:19
                    #10344734

                    Так он же не вышел!
                    Ваша f() отыграла как надо, просто вы ничего не возвращаете из foo()


                    1. mayorovp
                      04.08.2017 23:28
                      #10344748

                      Почему не вышел-то? Он вышел из внутренней стрелочной функции, не затронув выполнение внешней.


                      1. YemSalat
                        05.08.2017 00:44
                        #10344806

                        Прошу прощения, опечатался, имел в виду именно что он вышел, сначала из f(), а потом из foo() (только в foo он ничего не вернул).


                        1. mayorovp
                          05.08.2017 00:46
                          #10344808

                          Но ведь если он вышел, значит умеет выходить? В чем в таком случае суть вашего комментария была?


            1. dlf42
              03.08.2017 11:34
              #10341238
              +1

              Я думаю, имелось в виду "можно перепутать return из малозаметной стрелочной функцией внутри метода с return из самого метода"


          1. vilgeforce
            03.08.2017 09:52
            #10340960
            +1

            Я, может, не совсем понимаю что вы подразумеваете под надежность. Но известные мне компилеры других языков не скомпилят программу, пока в каждой точке выхода не будет return. Если функция, конечно, не void func() :-)


            1. AndreyRubankov
              03.08.2017 09:56
              #10340976
              +1

              Есть множество языков, где есть return, но его можно не использовать (php кажется, один из таких, а еще Scala) и есть множество языков, где return отсутствует как таковой (если не ошибаюсь, к ним относится Python).
              Во всех этих языках результат последнего действия будет возвращен как результат функции.


              1. vilgeforce
                03.08.2017 10:00
                #10340980
                +1

                В python точно есть return


                1. flancer
                  03.08.2017 10:05
                  #10340998
                  +1

                  есть != обязателен к использованию


                  1. DarthKotik
                    04.08.2017 17:23
                    #10344168

                    Но в Python он обязателен к использованию (кроме случая когда функция модифицирует переданные в неё аргументы, но не думаю что что-нибудь хоть сколько-нибудь сложное можно написать на таких конструкциях) в отличие от Ruby, где в отсутствие return функция вернёт значение, полученное при выполнение последней операции


                1. AndreyRubankov
                  03.08.2017 10:06
                  #10341000

                  спасибо, значит ошибся.


              1. nikolay_karelin
                03.08.2017 11:37
                #10341244
                +1

                В Python функция без return вернет None.


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


              1. andreysmind
                03.08.2017 12:35
                #10341412
                +1

                К ним Ruby относится :)


            1. torbasow
              03.08.2017 11:09
              #10341158
              +1

              А тут я перестал понимать, о чём речь. В Javascript никакой точки выхода без return быть не может, если это только не конец функции. Я имею в виду вот что: «модуль (в данном случае функция) должен иметь только одну точку входа и только одну точку выхода».


            1. Sayonji
              03.08.2017 18:29
              #10342094
              +1

              JS еще цветочки. А вот плюсы, они еще и объект за вас сконструируют, если вы return не напишете.


              1. grossws
                06.08.2017 16:58
                #10346200
                +2

                Это UB по стандарту C++


          1. franzose
            03.08.2017 11:20
            #10341198

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


            1. torbasow
              03.08.2017 12:39
              #10341428

              Но некоторые конструкции упрощают эту задачу.


          1. Fen1kz
            03.08.2017 16:34
            #10341912
            +5

            ли, вот, когда return выходит не из метода, а из малозаметной стрелочной функции внутри него, это может оказаться коварной неожиданностью.

            public class Foo {
    public int bar() throws Exception {
        Callable<Integer> f = () -> {
            return 42;
        };
        f.call();
    }
}

            Коварный, коварный JavaS… Оу, нет, просто Java.


            1. torbasow
              03.08.2017 17:08
              #10341954

              Я и не говорил, что Javascript хуже (или лучше Java), я просто предположил, чем может не нравиться return.


              1. Fen1kz
                03.08.2017 18:04
                #10342068

                Вы поддерживаете т.з. автора о том, что return — это раздражающая особенность js


                И это ещё я молчу про субъективный взгляд на раздражающие лично меня особенности типа мутабельности, фигурных скобочек, точек с запятой, return


                1. torbasow
                  03.08.2017 20:42
                  #10342310
                  +1

                  Вовсе нет. Я высказываю предположение, что именно его может раздражать. Я не утверждаю, что return обязательно должен раздражать, мне это странно.


                  1. Strain
                    03.08.2017 20:48
                    #10342314
                    -4

                    Это моё субъективное мнение, без очевидных объективных причин, я так и написал :)
                    Касаемо меня — return делает код функции более запутанным, а ещё я постоянно его забываю писать. Потому что всю жизнь писал на Erlang, Elixir, Haskell и Lisp. И от забытых return — ов много проблем, потому что функция возвращает undefined без всяких предупреждений и программа потом падает в самом неожиданном месте по какой-нибудь совсем другой причине, отловить трудно. В общем получается много бессмысленной работы.


                    1. torbasow
                      03.08.2017 21:17
                      #10342356
                      +2

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


                      1. Strain
                        03.08.2017 22:03
                        #10342442

                        Да, неявные преобразования усугубляют такой тип ошибки ( впрочем как и почти все типы ошибок ). Касаемо return, циклов и прочих statements — тут дело в парадигме. Видимо вы хорошо владеете императивными языками в которых есть эти statements, поэтому всё и привычно. Но в функциональных языках как правило этих statements нет, да и вообще количество statements минимально потому что всё является expression. JavaScript — не настоящий мульти-парадигменный язык как это утверждается, впрочем как и не настоящий ООП язык ( привет классы JS ). Вот например Scala является и настоящим мультипарадигменным языком и настоящим ООП языком — там можно ( и как говорят многие даже нужно ) писать без этих statements. А в JavaScript слова мультипарадигменность и ООП были добавлены только ради красного словца и зачастую вводят людей из ФП в заблуждение.


                        1. Cake_Seller
                          04.08.2017 12:07
                          #10343354
                          +1

                          впрочем как и не настоящий ООП язык ( привет классы JS )

                          А я вот с вами не соглашусь. Нельзя сказать что JS не OOP язык потому что в нём нет классового наследования. Прототипное наследование вполне укладывается в парадигму OOP.


                      1. Cake_Seller
                        04.08.2017 12:02
                        #10343332
                        +1

                        Деление на ноль в JS вернет Infinity ;-)


                        1. torbasow
                          04.08.2017 12:37
                          #10343426

                          Верно — что тоже не сильно помогает. А вот Math.asin(2), например, NaN.


                    1. franzose
                      04.08.2017 03:43
                      #10342712

                      return делает код функции более запутанным

                      Интересно, каким образом? Это ведь явное ключевое слово для выхода из функции.


                    1. 0xd34df00d
                      04.08.2017 04:00
                      #10342722
                      +5

                      Касаемо меня — return делает код функции более запутанным, а ещё я постоянно его забываю писать. Потому что всю жизнь писал на Erlang, Elixir, Haskell и Lisp.

                      В Haskell у вас набор уравнений, формирующих граф, который редуцируется обычно через STG. В императивных языках у вас, внезапно, императивные функции.

                      Я давно и нежно люблю хаскель и немало на нём пишу, но на императивных языках return выглядит вполне себе естественным, как по мне.


                      1. grossws
                        06.08.2017 17:23
                        #10346238

                        В императивных языках вполне можно жить с опциональным return (scala, ruby, rust, coffeescript) при достаточной гибкости языка.


                        В том же coffeescript оно полубесполезно (особо нет функциональных конструкций).


                        В ruby куда лучше, стандартная библиотека хорошо заточена под функциональщину в ограниченном масштабе и работа с Enumerable без использования each, map, reduce/inject, all?/any? выглядит странной и неестественной.


                        В scala return надо использовать хорошо понимая (как и большинство фич, язык с приличным порогом вхождения). Например, return из лямбды вытекает во внешнюю функцию (пример со stackoverflow):


                        def sum(ns: Int*): Int = ns.foldLeft(0)((n, m) => n + m) // inlined add

scala> sum(33, 42, 99)
res2: Int = 174 // alright

def sumR(ns: Int*): Int = ns.foldLeft(0)((n, m) => return n + m) // inlined addR

scala> sumR(33, 42, 99)
res3: Int = 33 // um.

                        Но учитывая наличие pattern matching, того, что if является выражением (expression) и прочих радостей return в scala нужен не очень часто.


                        В rust всё более-менее прилично и return стоит использовать только при явном раннем выходе из функции. Но, в отличии от scala, я не припомню, чтобы он давал такие неочевидные побочные эффекты. С учетом наличия pattern matching, того, что почти всё выражение (expression) — return нужен не очень часто. В той же обработке ошибок он раньше был спрятан за макросом try!, а сейчас за его сокращением ?. В последней версии пошли ещё дальше и loop (бесконечный цикл; очевидно, без условия) тоже может являться выражением, если использовать break some_result.


                        Больше всего в таком плане раздражает java 1.8: return обязателен в функциях и "многострочных" лямбдах (т. е. вида (x) -> { return 42; }), но запрещён в однострочных лямбдах (вида (x) -> 42). Несмотря на то, что IDE умеют превращать однострочную лямбду в многострочную и наоборот (если она состоит из одного return statement, ессно), это несколько раздражает.


                    1. x67
                      04.08.2017 09:56
                      #10343034

                      А как вообще функция должна понять, что ей возвращать?
                      В разных языках это может делаться по разному — где-то функции (или переменной с названием функции) присваивается конечное значение, где-то return, но по сути это те же яйца только в профиль.


                    1. YemSalat
                      05.08.2017 02:12
                      #10344856

                      Ваша проблема в том что вы зависли в парадигме «функция обязана возвращать что-то определенное», в JavaScript'e — не обязана (аргумент про «не изучил, но критикую»)


                      1. Lofer
                        05.08.2017 11:03
                        #10345054

                        Ваша проблема в том что вы зависли в парадигме «функция обязана возвращать что-то определенное», в JavaScript'e — не обязана (аргумент про «не изучил, но критикую»)

                        Нюанс в том, что все функции всегда что-то возвращают, но это будет void (С++) или undefined в случае с js.
                        Некоторые языки программирования такие функции/Function именуют процедурами/Sub и/или предотвращают такие проблемы и вопросы с неоднозначностью поведения еще на этапе компиляции в отличие от «оно само сделает» в случае в JS.


                      1. 0xd34df00d
                        06.08.2017 01:16
                        #10345616

                        Это лишь значит, что JS — недостаточно формально корректно спроектированный язык. Функции, которые ничего не возвращают, нельзя вызвать из некоторых математических соображений.

                        У void в C++ с этим есть тоже определённые проблемы (тип очевидно населён, но создать переменную этого типа нельзя), которые иногда даже в реальной жизни больно бьют во время всяких шаблонных выкрутасов.


            1. zirix
              03.08.2017 22:47
              #10342518
              +2

              Оу, нет, просто Java.

              В java нельзя получить undefined из-за забытого return. Ваш код не скомпилируется:
              Error:(41, 5) java: missing return statement


        1. Eldhenn
          03.08.2017 09:26
          #10340900

          return не плох, он коварен. В том смысле, что он обязателен — функция не возвращает значение последнего выражения.


          1. AndreyRubankov
            03.08.2017 09:53
            #10340966
            +9

            Так это не в return дело, а в том что девелопер привык писать на языке, который не использует return.
            Если девелопер начинал обучение с более низкоуровневых языков Pascal/C/C++/C#/etc. то ему будет напротив непривычно, что return не используется.

            return коварен в Scala, где он при определенных условиях может сделать больше, чем ожидается. Но в JS он ведет себя как в большинстве C-подобных языков.


            1. vilgeforce
              03.08.2017 10:00
              #10340978
              +2

              Я вот писал на JS после многих лет C/C++ и даже Питона и никаких проблем с return и скобочками не испытывал вообще!


          1. Apx
            03.08.2017 20:16
            #10342282
            +3

            Что же такого коварного описано в документации для JS про return? Или точнее «не написано».


      1. AndreyRubankov
        03.08.2017 09:43
        #10340942
        +4

        «почему всё так?»
        js, как язык существует уже почти 20 лет (или больше?), но js, как полноценный язык, на котором можно писать больше, чем обработчик onclick, существует всего лет 5-7, ну а js, который уже имеет зачатки для больших проектов (ES2015) и того меньше, – ему всего 2 года.

        Но язык и платформа невероятно быстро развиваются. И большим недостатком этого развития является то, что «каждый тянет одеяло на себя» (на фоне этого развития можно стать SuperStar! если успеешь сделать библиотеку, которой все будут пользоваться, такую как jQuery). И теперь давно минувшие «браузерные войны» превратились в «войны фреймворков».

        К тому же стоит смотреть на историю развития: сначала Прототипное ООП продвигалось, как лучшее в мире, потом пришли Классы, которые невзлюбили те, что освоили прототипное, а теперь и вовсе хайп на стороне функционального js.
        Ах, еще JSX появился, который позволяет писать на js внутри html пока пишешь на js, который тоже не все любят.

        – Это все ведет к разделению сообщества на множество мелких юзергрупп, каждая из которых проповедует свою истину и не сильно любит чужую.

        ps: А хайп девелопмент очень просто объяснить. Большинство JS девелоперов выросли на фронтендах, где все делается не так просто, как на бекенде, и любая новая библиотека призванная улучшить ситуацию воспринимается на ура.


        1. vintage
          03.08.2017 10:21
          #10341048
          +2

          Примечательно, что до примитивного JSX был чудесный E4X, который был стандартом, поддерживался Мозиллой, Флешом и Акробатом, и который… не взлетел.


          1. mayorovp
            03.08.2017 10:29
            #10341066
            -1

            В то время фронтэндщики еще не свыклись с идеей о необходимости компилировать свои проекты, а firefox — не единственный браузер.


            1. vintage
              03.08.2017 10:38
              #10341080
              +1

              Тем не менее, сейчас бы сдуть пыль со старичка, да внедрить, но индустрия как барышня "всё, поезд ушёл, ты был классный, но я к тебе больше не вернусь, буду мучиться с новым перспективным козлом". :-) Вот и мучаются люди с огрызком в виде JSX.


              1. mayorovp
                03.08.2017 10:40
                #10341082

                Ну, все же E4X заменой JSX назвать трудно. Обработчики событий через E4X не поставить, сложные объекты — не передать. Все-таки, JSX по сравнению с E4X — шаг вперед.


                1. vintage
                  03.08.2017 10:46
                  #10341096
                  +1

                  Шаг вперёд — два шага назад :-) Добавить в E4X возможность передавать в атрибутах сложные объекты было бы не так уж сложно.


                  1. mayorovp
                    03.08.2017 10:48
                    #10341100
                    -1

                    … и чем бы оно тогда от JSX отличалось? :-)


                    1. vintage
                      03.08.2017 10:58
                      #10341126

                      DOM на выходе с возможностью его произвольного процессинга (от от DOM API и E4X селекторов, до XSLT трансформаций). Нативной поддержкой без препроцессоров. Стандарт в конце концов.


                      1. mayorovp
                        03.08.2017 12:49
                        #10341442

                        Ну а тут — то же самое, только еще гибче (что угодно на выходе).


                        1. vintage
                          03.08.2017 13:30
                          #10341538
                          -2

                          JSX на выходе даёт виртуальный дом. E4X — реальный. Преимуществ у первого перед вторым нет никаких.


                          1. mayorovp
                            03.08.2017 13:31
                            #10341540
                            +3

                            JSX на выходе дает то, на что настроено


        1. Ashot
          03.08.2017 11:07
          #10341152
          +2

          сначала Прототипное ООП продвигалось, как лучшее в мире, потом пришли Классы

          так прототипное ООП никуда не делось – классы в JS это по сути синтаксический сахар, прототипный подход остался на месте


    1. some_x
      03.08.2017 09:06
      #10340866
      +5

      По моему всё по делу. Почти со всем согласен с автором, то что в 2017 году во сферы пытаются запихать однопоточный рантайм, это не нормально.

      Я считаю это результат курса ан опопсение программирования. Бизнесу не хватает программистов и они прикладывают силы чтоб любой js junior мог пилить их бизнес задачи.


      1. staticlab
        03.08.2017 11:31
        #10341234
        +1

        Бизнесу же в конце концов надо решить задачу. Задач много, а программистов мало. С их точки зрения лучше, когда "дешёвый" js-разработчик быстренько напишет на однопоточном ЯП решение без разруливания проблем с race condition, синхронизацией и т.п., чем это будет "правильно" пилить "дорогой" разработчик на той же Java. А затем на сервере или в кластере поднимут нужное количество инстансов приложения, и вот вам многопоточность.


        В случае же, если бизнес решает, что лучше делать правильно и дорого, то он джавистов и нанимает.


        1. Strain
          03.08.2017 11:38
          #10341252
          +1

          Однопоточность не решает проблемы race condition. Вот один из самых известных исторических фактов по этому вопросу.


        1. franzose
          04.08.2017 03:46
          #10342714

          Только вот потом «сейчас и побыстрому» оборачивается проблемой «как это всё теперь поддерживать и допиливать».


        1. franzose
          04.08.2017 03:47
          #10342716

          Т.е. с самого старта проект превращается в легаси.


          1. staticlab
            04.08.2017 10:24
            #10343096

            Согласен, что дешёвые разработчики напишут говнокод, но с количеством потоков это слабо связано.


        1. AndreyRubankov
          04.08.2017 08:58
          #10342908
          +1

          Справедливости ради стоит отметить:

          1. Хороший JS разработчик стоит столько же, сколько и хороший Java разработчик, но введу того, что JS легче изучить, туда сейчас идет очень много людей. Из-за этого специалисты начинающего и среднего уровня стоят довольно дешево.
          2. JS не на много проще, чем Java. Вернее проще в одних моментах и на много сложнее в других. Java сложнее для старта, но в сотни! раз проще для поддержки проекта, если это не уродливый JavaEE, где куча XML.
          3. Многопоточность в Java используется не часто, по крайней мере для WEB. Да, сервера сами по себе многопоточны, но каждый HTTP запрос обрабатывается в одном потоке без взаимодействия с другими. Нужно еще постараться, чтобы выстрелить себе в ногу в этом месте.


          1. pnovikov
            04.08.2017 09:01
            #10342914

            Нужно еще постараться, чтобы выстрелить себе в ногу в этом месте.

            BTW, знавал людей, которые в таком окружении умудрились сделать подключение к БД синглтоном. А вы говорите...


            1. AndreyRubankov
              04.08.2017 09:52
              #10343020

              Я встречал, как кто-то в потоке обработки HTTP запроса создавал тред-пул для выполнения довольно тривиальных действий.
              Девелопер действительно постарался, он сделал пул потоков, он хотел как лучше, но упустил из виду то, что придет 100 запросов и он создаст +200 потоков и системе станет очень плохо.

              Но это по большей части исключение из правил.


          1. grossws
            06.08.2017 17:36
            #10346250
            +1

            Вернее проще в одних моментах и на много сложнее в других. Java сложнее для старта, но в сотни! раз проще для поддержки проекта, если это не уродливый JavaEE, где куча XML.

            В современном Java EE xml'а куда меньше, чем было во времена EJB2.1. 11 лет прошло от появление EJB3.0, где уже вовсю используются аннотации.


            Многопоточность в Java используется не часто, по крайней мере для WEB. Да, сервера сами по себе многопоточны, но каждый HTTP запрос обрабатывается в одном потоке без взаимодействия с другими. Нужно еще постараться, чтобы выстрелить себе в ногу в этом месте.

            Вам кажется. Как только уверенный в себе разработчик начинает на каждый запрос порождать пул соединений к базе или делать что-то типа https://habrahabr.ru/post/334138/, то concurrency там в полный рост. Со всеми проблемами, происходящими от остутствия минимального понимания JMM.


    1. mclander
      03.08.2017 20:00
      #10342248
      +13

      Ну я тоже долго плевался от JS пока не стал на нём писать серьёзные вещи.

      Как оказалось, что всё от чего я плевался либо не страшно, либо удачно засахарено в ES6/TS.

      Возможно, что просто в отделе подняли зарплату не автору, а фронтеру)


  1. CodeViking
    02.08.2017 22:47
    #10340466
    +11

    Может быть я не очень хороший программист, но JS я люблю. Однако считаю синдромом мечтать о том, чтобы всё было на JS.


    1. taujavarob
      07.08.2017 00:13
      #10346608
      -3

      CodeViking

      Может быть я не очень хороший программист, но JS я люблю.
      Многие любят JS — И это нормально.

      Ненормально и странно, когда кто-то пишет — «Я люблю С++» или «Я без ума от PHP» или «Ничего нет лучше Python»

      У уж если кто напишет — "Я люблю SQL" — его в дурку сразу определят.

      Только про JavaScript вполне нормально сказать — "Я люблю JavaScript."

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

      Имхо, конечно, имхо. (С)


      1. TheShock
        07.08.2017 02:32
        #10346706
        +5

        Почему ненормально? Я вот много лет писал на ЖС и сейчас пишу, мне нравится множество вещей на нем, но вот люблю C#, потому что мне нравятся эмоции, которые я испытываю, когда программирую на нем. Может вы ремесленник и относитесь к программированию исключительно как к монотонной скучной работе, но не все такие.
        Я вот сейчас еще на Go много пишу, но совсем его не люблю, потому что очень неудобный язык. Так что да, под решение задачи подходит и даже больше C#, но люблю я все-равно C#, к JS я нейтрален, а Go не люблю. Что тут не так?


  1. begemot_sun
    02.08.2017 22:49
    #10340468
    +10

    Наболело.


  1. ik62
    02.08.2017 22:50
    #10340470
    +15

    Когда такие гиганты как Facebook, Google, Microsoft и Twitter методично вливают многомиллионные потоки кровавых долларов в JavaScript инфраструктуру


    А зачем же они это делают? Почему не вливают в кошерные языки?


    1. Strain
      02.08.2017 23:04
      #10340486
      -5

      Могу предположить что использование JS фреймворков от фейсбука внутри самого фейсбука выглядит не так уж и страшно — из за высокого уровня культуры разработки, 100% покрытие юнит-тестами от и до. То есть они пишут инструмент для себя. Также возможно дело в средней цене за единицу времени js разработки / низком пороге входа — дешевле взять js джуна которых много, при необходимости обучить написанию тестов и дать ему таск чтобы он писал тесты и облазил в дебаггере код вдоль и поперёк пока всё не заработает как надо чем искать Scala / Java / Erlang / Elixir / Haskell / какого-то ещё разработчика.


      1. ik62
        02.08.2017 23:30
        #10340520
        +3

        Могу предположить что использование JS фреймворков от фейсбука внутри самого фейсбука выглядит не так уж и страшно — из за высокого уровня культуры разработки, 100% покрытие юнит-тестами от и до.

        Ну по идее ничто не мешает делать то-же самое на бэкенде и со строгими языками, зачем-же cвязывться с js?
        Также возможно дело в средней цене за единицу времени js разработки / низком пороге входа — дешевле взять js джуна которых много

        Вот это может быть более похоже на правду.


        1. i360u
          03.08.2017 09:29
          #10340910
          +9

          Хороший фронтендер на JS в среднем будет ничуть не дешевле аналогичных по уровню разработчиков на других популярных стеках. А зачастую и дороже. Дешевизна тут — большой миф, корни которого уходят к традиционно пренебрежительному отношению к "недопрограммистам" верстальшикам. Однако, в современных реалиях фронт часто оказывается гораздо сложнее бека.


          1. Zenitchik
            03.08.2017 13:52
            #10341580

            Вертальщик и фронтендер — две большие разницы. Я, вот, фронтеэндер, и систематически обращаюсь к верстальщикам, когда надо сотворить что-то этакое на CSS. У них уже своя наука.


            1. i360u
              03.08.2017 14:16
              #10341620

              Во первых, я о том и пишу, что фронтэндер — это вовсе не простой верстальщик. А во вторых — знать и любить CSS лучше любого верстальщика — очень не помешает любому фронтендеру. Это вообще один из показателей профессиональной зрелости, я бы не доверил писать фронт человеку, которому требуется помощь верстальщика.


              1. bano-notit
                03.08.2017 14:38
                #10341670

                А я бы доверил, потому что знать, почему 0 == '0' для фронтэндера важнее, чем знать, почему для применения того, чтобы дети с float: left не вылетали из родителя родителю нужно какие-то бордеры невидимые делать или ещё хлеще, почему при opacity !== 1 прекращает свою работу z-index.


                Просто приведения типов можно объяснить, даже this можно знать на что будет ссылаться, а вот почему z-index перестал работать вы никогда не объясните, или почему нужен position: relative там, где есть какие-нибудь вещи. Там это аксиомы, а у нас хотя бы можно как-то объяснить и предсказать поведение, хотя в некоторых очень узких местах даже в js нельзя понять какого чёрта с приведением творится.


                1. i360u
                  03.08.2017 15:19
                  #10341748
                  +1

                  В нашей команде (включая меня лично), по какой-то странной причине, у фронтендеров не имеется никаких проблем ни с первым ни со вторым. И все как-то объясняется и предсказывается. Более того, многие задачи решаются именно на уровне CSS наиболее эффективно. Но так не у всех, наверное, ок. Про профессиональную зрелость я писал.


                  1. bano-notit
                    03.08.2017 22:13
                    #10342454

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


                    1. i360u
                      04.08.2017 11:10
                      #10343234

                      Я говорю даже не о "красивостях" и анимациях. Даже простое знание селекторов и манипуляции с атрибутами могут избавить вас от огромного количества лишнего кода в JS и ненужной логики в компонентах. А это прямая зависимость с качеством кода и скоростью разработки. Остальное — также, так или иначе, позволяет оптимизировать рендер и делать многие задачи на более высоком уровне. Как следствие — CSS — становится органичной частью кода приложения, вы должны его полностью контролировать чтобы получать наиболее предсказуемый и качественный результат. А зная современные возможности веб-платформы верстать становится совсем не сложно и местами очень даже приятно. А использование какой-либо консистентной экосистемы UI-компонентов избавит вас от рутины. Но такой подход, конечно, более актуален в продуктовой разработке а не проектной (когда лендинги).


                      1. bano-notit
                        04.08.2017 11:53
                        #10343310

                        Скажем так, кнопочкам паддинги расставлять любой умеет, позиционировать оповещение с помощью pos:fix тоже все. А вот такие хаки как в этих самых лендингах, где оказывается, что браузер ведёт себя совершенно не логично, примеры такого поведения я привёл, вот это, по моему, я сам по себе как js разработчик знать не должен. Вот честно, мне легче настоящего верстальщика, который на лендингах собаку съел, спросить что там происходит и как это исправить, чем съедать свою собаку на лендингах. Я лучше мобиксовскую покушаю, это чуть перспективнее.
                        Но всё же, есть верстальщики профессионалы, люди которые знают все уловки и все баги браузера. Вот это прямо профессионалы. Я не считаю, что разработчик на js должен быть вот таким запиписечным профи в этом реально сложном деле, потому что там не получится понять, что за фигня происходит, пока ты не перелопатишь сам движок рендеринга. Лучше иметь одного профи знакомого, чем самому в этой чертовщине ломать ноги.


                        1. i360u
                          04.08.2017 12:05
                          #10343346

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


                          1. bano-notit
                            04.08.2017 12:11
                            #10343368

                            Я вас поздравляю. Я не могу сверстать всё, что мне нужно без вопросов к профи, ответы на которые всё чаще сводятся "поставь родителю position: relative".
                            Может вы и правы, что неплохо было бы иметь такой скил в коробке, но целенаправленно выучивать эти грязнейшие с точки зрения логики хаки со всякими .clearfix, уж позвольте.


                            1. punkkk
                              04.08.2017 13:46
                              #10343640
                              +1

                              ответы на которые всё чаще сводятся «поставь родителю position: relative».


                              Как вы можете претендовать на фронтенд разработку? -_-


                              1. bano-notit
                                04.08.2017 14:06
                                #10343688

                                Вот как-то вот так) Я же говорю, знакомый есть, который эти нелогичности объясняет как "ну вот так вот получилось, это нужно запомнить, чинится это вот так".


                              1. Zenitchik
                                04.08.2017 15:29
                                #10343854
                                +1

                                претендовать на фронтенд разработку

                                Да запросто, если пишешь невизуальную часть фронтенда.


                1. franzose
                  03.08.2017 23:44
                  #10342572

                  Мне всегда казалось, что фронтендер — человек, который занимается вёрсткой и пишет JS. В игровой индустрии, конечно, всё может быть иначе, но в основном-то это так.


                  1. Zenitchik
                    03.08.2017 23:48
                    #10342576

                    Во общем — Вы правы. Но когда пишешь толстый клиент, лучше чтобы за багами z-index-ов следил отдельный человек.


              1. Zenitchik
                03.08.2017 16:39
                #10341918

                Я не говорил, что не знаю CSS. Я говорил только что отдаю эту работу отдельному верстальщику. До этого два года работал без них (их не было), теперь с удовольствием освободился от необходимости подгонять внешний вид интерфейса под картинку нарисованную дизайнером — объясняю верстальщику, по какому принципу у меня элементам класс-неймы присвоены, и спокойно берусь за следующую задачу.


              1. mclander
                03.08.2017 20:09
                #10342272
                +3

                Блин. Пойду убьюсь.

                Я могу верстать, но очень средненько и очень медленно. Если из рук проф дизайнера/верстака выходит красивое приложение, а мне этого не дано…

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

                И, что странно, при этом з/п среднего фронт-сеньора сильно выше з/п отличнийшего верстака.

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


            1. AndreyRubankov
              03.08.2017 15:54
              #10341826
              +3

              Верстальщики, как и JS девелоперы, это же подмножество фронтедщиков или нет?
              т.к. Фронтэнд — это все, что связано с клиентской частью приложения, с отображением.

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


            1. odintree
              04.08.2017 22:02
              #10344632

              я уже так давно не видел верстальщиков, если честно.
              обычно из того, что видел это дело распиливают между собой дизайнер и чувак, который что-то пилит на angular/react/vue etc.
              я и сам не люблю, да и скажу честно, плохо довольно работаю с этими CSS и HTML… но как-то никому в голову не приходит верстальщика брать еще. серьезно, думал они «вымерли» уже :D


              1. bano-notit
                04.08.2017 22:12
                #10344646

                Они не вымерли, и не вымрут, пока не появятся бесплатные нормальные генераторы лендингов, а они именно с этими 2 качествами не появятся никогда.


    1. seniorcote
      03.08.2017 00:03
      #10340566

      У них есть ряд причин так делать, но забота о разработчиках и их нервах в этот ряд не входит.


  1. Hedgar2018
    02.08.2017 22:53
    #10340474
    +5

    Тащить на backend интерпретируемые языки, а еще и без типизации — маразм. Только компилируемые и со строгой, желательно именной, типизацией (Golang или Rust, конечно же).
    На клиенте же всё наоборот — нужна полная кроссплатформенность, а теперь и кроссдевайсность. Современные SPA фреймворки позволяют один такой bundle запустить на любом устройстве с экраном.
    Но не на backend, ни в коем случае.
    Пишу этот коммент только для того, чтобы выудить умные противоположные мысли из комментов к нему, если они будут.


    1. Hedgar2018
      02.08.2017 23:12
      #10340494
      +6

      [Update]
      В качестве JS только TypeScript.


      1. mclander
        03.08.2017 20:14
        #10342278

        Трудности и радости секса в невесомости сильно преувеличены (с) А. Кларк (или А. Азимов, в общем кто-то из них)

        За три месяца работы на TS был только один случай, когда типизация могла бы сэкономить мне время на отладку (бага поймалась в редакторе). В остальном мне больше нравится ES6, чем TS. Но правда у меня школа Perl, который позволяет ещё больше чем JS и спрашивает потом больно, неожиданно и на продакшене, если где что прощёлкал.


        1. raveclassic
          03.08.2017 23:18
          #10342546
          +3

          Мы сейчас в процессе переезда нескольких библиотек на TS. Я уже сбился со счету сколько скрытых багов выявляется.


    1. Iqorek
      02.08.2017 23:24
      #10340514
      +8

      Говорят, что v8 компилирует js в нативный код, думаете врут?


      1. Hedgar2018
        02.08.2017 23:36
        #10340526
        -10

        Судя по бенчмаркам, скорее всего, врут.


      1. knekrasov
        03.08.2017 11:18
        #10341188

        А в конечном счете, все выполняется на вполне себе нативном ядре процессора с его микрокодом. Так что не врут.

        Вопрос в другом, какие assumptions сделает компилятор, пока будет превращать JS в нативный код? Статическая типизация в этом смысле поможет избежать ложных assumptions и четче декларировать намерения. Но ее нет :-)


    1. timon_aeg
      03.08.2017 11:39
      #10341254

      На клиенте же всё наоборот — нужна полная кроссплатформенность, а теперь и кроссдевайсность.

      Вы с css не путаете?
      Есть всего 3,5 браузерных js движков, и все они более менее поддерживают стандарты.


    1. oleg_gf
      03.08.2017 12:27
      #10341380
      -10

      Языки с типизацией — унылое старьё. ))))


      1. 0xd34df00d
        04.08.2017 04:02
        #10342724
        +5

        Ага


        1. oleg_gf
          04.08.2017 12:16
          #10343378

          Похоже, не только Вы не заметили, что я не разделял статически типизированные языки от динамически типизированных.


          1. Muxto
            04.08.2017 15:47
            #10343904
            +3

            Ассемблер или брейнфак?


    1. franzose
      03.08.2017 12:51
      #10341444
      +1

      А чем плохи PHP, Python, Ruby?


    1. guai
      03.08.2017 14:46
      #10341682
      -2

      На большом и мощном серваке иметь быстрые скомпиленные проги, а на дохленькой трубе обмазываться интерпретируемой динамикой или тратить скудные ресурсы на JIT не кажется ли вам странным?


      1. Zenitchik
        03.08.2017 16:48
        #10341930

        Сервер — один, труб — много. Нагрузка несоизмерима. Тем более, что сейчас каждая труба может баллистику звездолёта рассчитывать в реальном времени.


        1. Free_ze
          03.08.2017 19:42
          #10342212
          +3

          сейчас каждая труба может баллистику звездолёта рассчитывать в реальном времени

          JS спешит на помощь избыткам мощности! (= Современные сайты жрут как не в себя и тормозят на десктопах, что уж о мобилках говорить.


    1. speshuric
      04.08.2017 09:06
      #10342926

      Эм… На бэкенде «интерпретируемые языки, а еще и без типизации» чуть ли не царствуют. Весь bash/shell/cmd такой. На них не пишут бизнес-логику? Ок, тогда SQL — он тоже по факту скорее интерпретирумый, с типизацией у него «всё сложно». Кстати большинство движков SQL однопоточные (внутри запроса параллельность может быть, но следующий запрос начнется только после окончания предыдущего). Если про веб, то PHP по меркам индустрии джититься стал чуть ли не вчера. ABAP, не к ночи будет помянут, тоже, хм, элегантен, как паравоз.
      А ведь это языки на которых самое мясо бизнеса зачастую крутится. Тут скорее «Golang или Rust» пока в роли белых ворон.

      [Я сторонник типизированных языков, если что]


      1. sumanai
        04.08.2017 16:27
        #10344030

        Если про веб, то PHP по меркам индустрии джититься стал чуть ли не вчера.

        Я что-то упустил, и в PHP впилили JIT? Вроде только в проекте, если речь про основную ветку.


  1. Wedmer
    02.08.2017 23:00
    #10340478
    +6

    Сразу вспомнилось Wat видео от Destroy All Software.


  1. aleXoid
    02.08.2017 23:02
    #10340480
    +6

    Боль автора полностью обоснована. В последнее время я несколько увлёкся написанием ботов с MS Botframework, используя nodejs. Пока не перешёл полностью на Typescript — написание приложения больше 1000 строк, было настоящим мучением. Очень советую автору присмотреться к Typescript, как к костылю, который частично облегчает жизнь.


    1. Strain
      02.08.2017 23:17
      #10340502

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

      — Привет, меня зовут Олег, и я иногда пишу на JS. Нет, вы не подумайте в основном я Scala разработчик, но вот иногда приходится и в npm полазить и для grunt с webpack скрипты написать. Кстати, я не писал на JS уже 2 недели
      — Давайте похлопаем Олегу

      :)


      1. x67
        04.08.2017 10:51
        #10343184

        меня зовут не Олег, я всеми силами пытался дистанцироваться от фронтенда, но несмотря на это мне уже приходилось писать на JS


    1. Iqorek
      02.08.2017 23:26
      #10340518
      +13

      Я бы не сказал, что Typescript костыль.


      1. Hedgar2018
        03.08.2017 00:01
        #10340564
        -1

        Хорошая вещь является костылём, если её предназначение — заставлять работать плохую вещь, когда её [почти] невозможно заменить.
        Если бы браузеры понимали Typescript, он бы не был костылём.


        1. Iqorek
          03.08.2017 00:18
          #10340586

          Компилятор Typescript написан на… Typescript. Если я ничего не путаю, можно прикрутить компилятор к страничке и генерировать код в браузере на лету, но так никто не делает, потому что зачем.


          1. Hedgar2018
            03.08.2017 00:29
            #10340604

            А как прикрутить к страничке что-либо, написанное на Typescript?


            1. Iqorek
              03.08.2017 07:11
              #10340764

              Написан на typescript и скомпилирован в javascript


            1. prostofilya
              03.08.2017 07:58
              #10340790
              +6

              Что-то ребята на C++/C#/Java и тд тп всю жизнь компилируют и как-то не жалуются


              1. Free_ze
                03.08.2017 19:46
                #10342220
                +1

                Ребята компилируют в байткод, а то и в маш.коды, а не занимаются пустопорожними переливаниями между разными видами текстовых форматов.


                1. Shifty_Fox
                  03.08.2017 21:02
                  #10342336

                  Ну про машинный код я еще могу понять логику, это непосредственный формат для процессора. И то, сначала код переводится в ассемблер, а уже потом в машинный код, так то.
                  В чем же разница подачи байт кода java машины или передачи javascript кода браузеру (мог бы он принимать javascript байт код напрямую, так бы и делали) мне сложно уловить.


                  1. Free_ze
                    04.08.2017 12:41
                    #10343442

                    И то, сначала код переводится в ассемблер, а уже потом в машинный код

                    А до этого происходит токенизация, построение AST, линковка… Но это не имеет значения, на выходе из компилятора получаются уже готовые к исполнению модули.

                    В чем же разница подачи байт кода java машины или передачи javascript кода браузеру

                    Про Java об заклад биться не буду, но идеи там во многом аналогичны .NET CLI. Название как бы намекает: банальный текст против некоторого удобного для выполнения бинарного представления. Выгода здесь в оптимизациях, которые может провернуть компилятор (уровня модуля), удобной раскладки метаданных (стандартизированный формат, Карл! Поэтому байткод — кроссплатформенный, а в браузеры в 2к17 до сих пор шлют текстовые файлы). Да и просто байткод — это бинарное представление объектно-ориентированного ассемблера, использующий API виртуальной машины, а не сырой исходник, который еще необходимо распарсить, переварить во внутреннее представление (для конкретного движка), а потом как-то его исполнить.


                    1. Shifty_Fox
                      04.08.2017 12:50
                      #10343472
                      +2

                      Тогда это претензии конкретно к Chrome, IE, Firefox, Safari и другим браузерам.
                      Javascript не виноват, что разработчики браузеров не хотят принимать на запуск байткод.


                      1. Free_ze
                        04.08.2017 13:00
                        #10343512
                        -1

                        Если браузеры научатся понимать некий байткод, то дни JavaScript будут сочтены, ибо он перестанет быть безальтернативен на фронте.


                        1. AndreyRubankov
                          04.08.2017 13:24
                          #10343570

                          Был Flash, он принимал на вход байткод. Но его закопали.
                          Был Silverlight, он принимал байткод, — закопали.
                          Был JavaApplet… — закопали.

                          кто следущий WebAssembly?


                          1. Free_ze
                            04.08.2017 13:37
                            #10343616
                            +1

                            КМК, у этих платформ было две беды: проприетарность (и как следствие — уязвимость) и отсутствие стандартизации. Как мне известно, WebAssembly этих проблем не должен иметь.


                            1. AndreyRubankov
                              04.08.2017 13:54
                              #10343656

                              JavaApplet, как и вся джава – это стандарт, который может быть реализован разными компаниями. Но должен будет пройти сертификацию.
                              Flash… в целом он тоже стандартизирован и ближе к закату отдали в сообщество.
                              про Silverlight не могу сказать.

                              на счет уязвимостей. Уязвимости они не в технологии, они в имплементации, так что WebAssembly не защищен от уязвимостей.
                              У WebAssembly будет всего 2-3 реализации: под WebKit, под FF и под IE, т.е. от основных игроков рынка.

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


                              1. Free_ze
                                04.08.2017 14:06
                                #10343690

                                JavaApplet, как и вся джава – это стандарт, который может быть реализован разными компаниями

                                Но не был де-факто (об этом ниже).

                                Flash… в целом он тоже стандартизирован и ближе к закату отдали в сообщество.

                                Когда он стал не нужен. Звон про уязвимости слышен до сих пор.

                                Уязвимости они не в технологии, они в имплементации, так что WebAssembly не защищен от уязвимостей.

                                Браузеры тоже не защищены от этого, но от них же никто не спешит отказываться, верно?) Я к тому, что чаще всего это были самостоятельные плагины, которыми рулила какая-то компания, которая же отвечала как за возможности, так и за безопасность. WebAssembly будет ограничена API браузера, из-за чего возможности Java-апллетов и Silverlight ей будут лишь сниться, зато у пользователей проблем будет меньше.


                        1. Zenitchik
                          04.08.2017 13:52
                          #10343654
                          +1

                          дни JavaScript будут сочтены

                          Перейдём на Lua


                          1. Free_ze
                            04.08.2017 13:58
                            #10343664

                            Ну хотя бы)


                  1. grossws
                    06.08.2017 17:47
                    #10346258
                    +1

                    И то, сначала код переводится в ассемблер, а уже потом в машинный код, так то.

                    Зачем? В ассемблер переводят из внутреннего представления бэкенда компилятора только если пользователь слёзно попросил. А так кодогенерация идёт сразу в бинарное представление в объектном файле.


          1. some_x
            03.08.2017 07:40
            #10340774

            От этого браузер не начнёт понимать js, вы просто увеличите время загрузки)


            1. andreysmind
              03.08.2017 12:41
              #10341432

              Браузер переживет. А вот время разработки и отладки уменьшится.


              1. franzose
                03.08.2017 12:53
                #10341450
                +1

                А клиенты с мобильным интернетом подождут, да? :)


                1. andreysmind
                  03.08.2017 12:59
                  #10341466

                  Оно не компилируется в рантайме каждый раз.


              1. some_x
                03.08.2017 12:59
                #10341464
                +1

                С чего вдруг оно уменьшится?
                Во первых начнёт глючить отладка, так как js появится из памяти, а не из файла. Из-за этого будет сложно ставить брекпойнты, например.
                Во вторых, какая разница до загрузки ts будут компилироваться или после, всё равно время на компиляцию будет затрачено.
                В третьих вывод компилятора удобнее читать в ide, чем в консоли браузера.


        1. Nagg
          03.08.2017 10:28
          #10341062

          Глядишь и поймут скоро без жс. с вебассембли ;-)


      1. Yeah
        04.08.2017 11:01
        #10343204
        -1

        Typescript спасает лишь частично. Всегда можно написать as any и поломать всё. То есть если язык не бьёт вас по рукам, то это, к сожалению, не более, чем костыль


        1. raveclassic
          04.08.2017 11:03
          #10343216
          +1

          У tslint есть правило no-any


        1. pnovikov
          04.08.2017 11:06
          #10343226
          +3

          Так и в Java/C# можно все скастить к object и далее к любому требуему типу. Но зачем?


    1. serg_p
      04.08.2017 00:09
      #10342608
      -1

      Согласен со статьёй на все 100 — с каждым словом


      1. staticlab
        04.08.2017 07:30
        #10342826

        Только что это изменит?


        1. serg_p
          04.08.2017 12:30
          #10343406

          Вычитал все каменты — условно, все проблемы решаемы — да вообще-то нет, нерешабельные — нерешабельны системно — никакой истерики не было. Как то так.


  1. BuccapuoH
    02.08.2017 23:06
    #10340488
    +14

    Согласен со многими фактами, приведенными в статье, но позвольте несколько замечаний и вопросов (я JS разработчик).

    1. const — слышу о нём почти отовсюду. Но вот незадача — почему все думают что он должен работать точно так же как в С/С++/<вставьте любимый язык>. Я не спорю, реализация у него не лучшая, но это специфичная для языка конструкция, коротая имеет довольно простую функцию.

    2. this — подобно const, крайне непонятая многими особенность языка. И опять же — использовать её необязательно.

    3. Отсутствие нормальных классов/ООП. Недостаток только для людей, которые привыкли к ООП. Но соглашусь, те попытки создать ООП в JS, которые были — очень далеки от привычных многим концепций в Java/C/C++/C#/<добавьте свой язык>.

    4. «Многомиллионные инвестиции кровавых денег от больших корпораций». Вы так говорите, как будто это что-то плохое. Ни один язык не станет популярным на голом энтузиазме его последователей. Нужны деньги, нужна реклама, нужна раскрутка. Как, по-вашему, работодатели узнают о языке/библиотеке/фреймворке, если он на слуху только в технических кругах?

    В общем и целом, я к тому, что у всех языков есть недостатки и достоинства. У всех есть свои ниши и свои задачи. Языки — всего лишь инструменты.

    С тем же NodeJS, многие его хаят за то, что он посягает на святая-святых — backend. Но я думаю, что если JS не подходит для backend и он настолько плох — разработчики будут жаловаться. Жалобы поднимут дискуссии, появятся решения, новые версии, патчи и исправления. И если этого будет недостаточно, то люди перестанут этим языком пользоваться. И он уйдёт из этой ниши. На его место прийдет другой и попытается привлечь к себе внимание, чтобы начать дискуссию. Потому как дискуссия и обсуждение — главные способы сделать язык лучше.

    Java тоже не сразу стала удобной. Её тоже не все готовят правильно, есть жуткий код, есть хороший.

    С радостью выслушаю мнения насчет JS и его представления на уровне backend.


    1. sfi0zy
      02.08.2017 23:47
      #10340548
      +9

      this — подобно const, крайне непонятая многими особенность языка

      Но стоит один раз понять — и все, больше никогда этот вопрос не доставит проблем. А со стрелочными функциями использовать this стало очень приятно.

      Но соглашусь, те попытки создать ООП в JS, которые были — очень далеки от привычных многим концепций в Java/C/C++/C#/

      Да нет, в ES6 классы сделали вполне нормальные. Да, в них может не хватать чего-то, к чему привыкли приходящие из других языков, но это уже не та жесть на прототипах, которую писали 10 лет назад.

      Жалобы поднимут дискуссии, появятся решения, новые версии, патчи и исправления.

      В последние годы JS вообще очень сильно развивается, столько всего появилось… Автор поста говорит, что в JS нет единой системы в отношении модулей, работы с асинхронностями, и.т.д. но ведь это по сути является следствием того, что язык развивается, люди пробуют разное и пытаются выбрать лучшее. Просто здесь (как и в том же С++, кстати) не выпиливаются многие старые решения, они просто используются все меньше и меньше.


      1. BuccapuoH
        03.08.2017 00:46
        #10340620
        +2

        Полностью согласен. Очень многие вещи усваиваются с полпинка. Как вы сказали — это уже не та жесть, которую писали 10 лет назад.


        ES6 для меня был как глоток свежего воздуха. Последующие стандарты только улучшают ситуацию.


        Я думаю, что люди из других языков и парадигм нужны в JS сообществе. Способность посмотреть на вещи под другим углом может привнести (и зачастую, привносит) хорошие идеи.


    1. quwy
      03.08.2017 00:17
      #10340584
      -3

      Но я думаю, что если JS не подходит для backend и он настолько плох — разработчики будут жаловаться

      С чего бы это? Его в бекенд отнюдь не java/c#-гуру тащат, а вчерашние формошлепы, которые больше ничего другого не знают и знать не желают. Вот они конечно же всем довольны, а так как таких с каждым днем все больше становится, то никуда эта зараза уже не денется. Можно хоронить нормальный бэкенд, его уже не спасти.

      О чем речь, эсли эта хипстота свой жабаскрипт даже на контроллеры тащит? Типичный представитель, которому лень учиться и поэтому он все хочет писать на любимом js.

      Я уже молчу про десктоп, который благодаря гигантской производительности сегодня готов простить пользователю даже «электрон».


      1. Shifty_Fox
        03.08.2017 02:03
        #10340678
        +9

        Вы знаете, после бекенда на lua/java/c++ бэкенд на node js (es7-8) сплошное удовольствие.


        1. erlyvideo
          03.08.2017 11:00
          #10341134
          -7

          это первые 20 строк кода, просветление наступит позже. А луа конечно сравнивать нельзя: кошмар похлеще js


          1. Shifty_Fox
            03.08.2017 17:10
            #10341958
            +3

            У меня сильно больше 20 строк кода, и даже больше 2000 строк, и все еще сплошное удовольствие
            Если конечно быть в теме, использовать es7-8, не делать лапшу, а писать псевдосинхронный код, ну то есть понимать инструмент и правильно его использовать.

            Непосредственно nginx использует lua, на этой базе построен openresty. На этой базе успешно строят производительные игровые серверы.
            Lua Jit по производительности практически на одном порядке с нативным C++ кодом (ну конечно мета магия и динамическая типизация делают свое дело, но и применяя виртуальное наследование и динамический диспатчинг с хеш таблицами на C++ будет такой же результат).

            Что касается парадигмы однопоточной работы. Это именно парадигма, а не какой-то там недостаток, как утверждали в ветке выше. Во первых, как в Lua, так и в JS на node нет никакой проблемы сделать мультитреды прямо из Lua\JS. И там и там прекрасно работают C++ расширения. Но смысл парадигмы в том, чтобы управляющий поток был один. Это шардинг из коробки, он принуждает вас писать приложение так, чтобы потом шардить его на самом первом уровне.
            Это возможность, в конце концов, установить ряд глобальных состояний, и быть уверенным, что другой поток его не потеряет, потому что поток один. Второй поток — второе состояние, отдельное и независимое. Для общих данных же можно использовать как расширение с мультипоточностью, так и шардинг, оставаясь в пределах одного потока на процесс.


            1. Free_ze
              03.08.2017 19:50
              #10342232

              Lua Jit по производительности практически на одном порядке с нативным C++ кодом (ну конечно мета магия и динамическая типизация делают свое дело, но и применяя виртуальное наследование и динамический диспатчинг с хеш таблицами на C++ будет такой же результат).

              Самый быстрый Lua хуже не более, чем на порядок самого тормозного С++?) Маркетинг такой маркетинг.


              1. Strain
                03.08.2017 19:55
                #10342238

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


                1. Shifty_Fox
                  03.08.2017 20:30
                  #10342298
                  +2

                  Повторюсь, включить многопоточный рантайм не проблема как в серверном Lua так и в Javascript. Но его там не включают намеренно. Полагаете, из глупости и несерьезности?


                  1. izzholtik
                    04.08.2017 09:01
                    #10342916
                    -2

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


                    1. Shifty_Fox
                      04.08.2017 12:55
                      #10343498
                      +1

                      Я осиливал модель с сериализацией объектов и передачей между потоков. И классическую модель, когда объект просто общий на два потока. Многие разработчики расширений под Lua и JS осиливали обе этих моделей. Их решения известны, и даже используются в ряде проектов. Но они используются тогда, и только тогда, когда разработчик знает зачем ему нужна именно многопоточность в одном процессе с общими данными. В остальных случаях он масштабирует сразу процессы, и это масштабирование можно разнести не только на ядра, но и на разные серверы.
                      Многопоточность с общими данными — это как бы очень специфический кейс, нужный в 0.1% задач. В остальных случаях нам важнее иметь другую многопоточность — на уровне IO, а код должен синхронно обрабатывать таски, и параллелиться по процессам.


                  1. Strain
                    04.08.2017 09:04
                    #10342922
                    +1

                    И где же эта волшебная кнопка включения? Пример? Большинство кодовой базы js / lua / python просто перестанет работать правильно в многопоточном рантайме.


                    1. Shifty_Fox
                      04.08.2017 13:01
                      #10343514

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

                      Под Lua я встречал:
                      http://lualanes.github.io/lanes/
                      Под JS я глубоко не копал этот вопрос, принцип у JS и Lua в плане C++ биндингов одинаковый, и мета методы схожие, я знаю что в JS можно провернуть похожий трюк, и встречал npm пакеты утверждающие что они этот трюк проворачивают. Возможно, готовой кнопки там нет, но ее можно сделать.


              1. Shifty_Fox
                03.08.2017 20:35
                #10342302

                Ну никто не спорит, что быстрый C\C++ код без динамических типизаций будет рвать любой язык с jit и динамической типизацией. Но это просто два уровня подхода.
                Ну и в lua и node можно делать C++ расширения, если в каком-то месте нужно решить проблему производительности.
                Другое дело что вам возможно просто не нравится концепция «скриптовый язык сверху, C++ снизу», а больше нравится концепт «не туда и не сюда, но все еще можно сделать снизу C++», как в Java\C#


                1. Free_ze
                  04.08.2017 12:50
                  #10343474
                  +1

                  в lua и node можно делать C++ расширения, если в каком-то месте нужно решить проблему производительности.

                  Node.js так воспевался возможностью писать приложения на одном языке, а тут архитектурные костыли в виде расширений на нативных языках.

                  Другое дело что вам возможно просто не нравится концепция «скриптовый язык сверху, C++ снизу», а больше нравится концепт «не туда и не сюда, но все еще можно сделать снизу C++», как в Java\C#

                  «не туда и не сюда, но все еще можно сделать снизу C++» — я бы назвал это адекватным балансом между производительностью, удобством поддержки ПО и производительностью.

                  Лично мне не нравится дизайн JavaScript, поэтому и удивляет рьяное желание засовывать его везде, начиная с бэкенда и заканчивая микроконтроллерами.


                  1. Shifty_Fox
                    04.08.2017 13:39
                    #10343622

                    Я не воспеваю идею писать все на одном языке :)
                    Я воспеваю идею писать 90% приложения на одном языке, а 10% — на голом Си.

                    «не туда и не сюда, но все еще можно сделать снизу C++» — я бы назвал это адекватным балансом между производительностью, удобством поддержки ПО и производительностью.

                    Это же вопрос вкуса. Мне нравится, когда сверху язык совсем совсем динамический, легкий, немногословный (камень в java, но без претензий), а все что требует оптимизации, делать сразу на самом низком уровне в Си.
                    Вам нравится, когда сразу баланс.

                    Могу пояснить, откуда вообще растут корни такого подхода.
                    Как правило, нужно сделать 5-10 прототипов разной направленности, протестить на пользователей, понять что развивать а что нет, а потом уже делать полноценный продакшн, но не переписывать с нуля, а вертикально развивать существующий. Для этого связка JS + C подходит отлично.

                    Если бы мне дали энтерпрайз банкинг я бы врят-ли писал его на JS, это не его задача.


                    1. Free_ze
                      04.08.2017 13:50
                      #10343652

                      Как правило, нужно сделать 5-10 прототипов разной направленности, протестить на пользователей, понять что развивать а что нет, а потом уже делать полноценный продакшн, но не переписывать с нуля, а вертикально развивать существующий. Для этого связка JS + C подходит отлично.


                      Как это потом поддерживать — вопрос (мало того, что динамический язык, так еще и половина бизнес-логики ныряет в другой язык через всякие прослойки). Ну вкусовщина, ОК.


                      1. Shifty_Fox
                        04.08.2017 19:36
                        #10344432

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


                        1. grossws
                          06.08.2017 18:07
                          #10346270

                          А есть примеры кодовой базы среднего (100k SLOC) и выше среднего (1M SLOC) размеров на JS с рассказами о поддержке такого?


                          1. Shifty_Fox
                            07.08.2017 06:44
                            #10346768

                            Могу скопировать тройку классов из клиент-серверной игры в github gist
                            Классы с сервера, используют C++ биндинги, синхронизируются с клиентом.
                            то есть весь C++ код дублируется js кодом, чтобы каждый кадр был синхронизирован, и обновлялся с сервера только при изменении ключевых параметров на сервере (нажали кнопку, пришел новый вектор движения, нажали на дверь, пришло событие открытие двери). Этот код моего проекта, я могу его публиковать, но не стану публиковать весь проект.
                            Код не претендует на идеальный, но он и не плохой, где-то хорошо, где-то не очень.
                            https://gist.github.com/dmitriy-lodyanov/d0559323986a6faaf78b93e272690766
                            https://gist.github.com/dmitriy-lodyanov/f17f7613197b75e2109d075e65b42f89
                            https://gist.github.com/dmitriy-lodyanov/d59b3301d6247fcc3ec5c52895820dc6
                            Врят ли пара классов даст представление о целом проекте. Это простая mmorpg в стиле dark souls, с видом сверху.


                            1. Shifty_Fox
                              07.08.2017 06:49
                              #10346770

                              Еще добавлю gist основного update(dt) сервера на C++. Он не дублируется на клиенте за ненадобностью, на клиент приходят постфактум физика и события, то есть на клиенте столкновения не обсчитываются.
                              https://gist.github.com/dmitriy-lodyanov/38cd8e42c7bef4889cdd752fc3459166


                              1. Shifty_Fox
                                07.08.2017 06:53
                                #10346772

                                А поддержка всего этого…
                                Наверное также, как вы поддерживаете свои проекты. Просто держите в голове архитектуру, знаете ключевые точки, знаете где нужно добавлять объекты и расширения для новых функций. Я использую классическую модель игровых циклов, когда есть дерево объектов, каждый кадр по ним проходит обновление, во время событий срабатывают триггеры. Сервер работает на 30 fps, клиент на 60 fps. Благодаря математически корректным формулам равноускоренного движения, при разных fps на сервере и клиенте объекты все равно двигаются синхронно независимо от dt.


            1. sshikov
              10.08.2017 22:28
              #10355140
              +1

              И даже больше 2000 строк...

              На сколько порядков?


        1. quwy
          03.08.2017 13:50
          #10341576
          -3

          Мое сообщение именно об этом.


        1. 0xd34df00d
          04.08.2017 04:03
          #10342726
          +1

          Не троллинга ради, но любопытства для: откуда я могу начать получать удовольствие от node.js по сравнению с C++?


          1. greendimka
            04.08.2017 10:22
            #10343090
            -2

            JS: Пишите — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите дальше — не работает. Пишите — вдруг заработало. Вот тут вы и получаете удовольствие.


            1. staticlab
              04.08.2017 11:22
              #10343252
              +2

              Выглядит как ошибка компилятора C++ при развёртывании шаблонов :D


              1. 0xd34df00d
                04.08.2017 19:25
                #10344404
                +1

                Тут хотя бы есть компилятор!


            1. bano-notit
              04.08.2017 11:59
              #10343320

              Позвольте, это не так. Там скорее так: Пишите — не работает. Пишите — не работает. Пишите — о, что-то заработало! Пишите — о, ещё что-то подтянулось! Пишите — ну а теперь вообще всё тип топ.
              Удовольствие приходит начиная с 3 шага.


              1. raveclassic
                04.08.2017 12:27
                #10343404
                -1

                На самом деле, удовольствие приходит с TS :)


                1. bano-notit
                  04.08.2017 12:37
                  #10343424
                  +1

                  Не соглашусь, тогда уж довайте на cloujer писать сразу, зачем нам сам js то?


                  1. raveclassic
                    04.08.2017 12:39
                    #10343432
                    -1

                    Ну кложа на любителя. А зачем js, когда есть ts — сам не знаю.


                    1. bano-notit
                      04.08.2017 12:40
                      #10343440
                      +3

                      Зачем ts, когда есть js, вот это я реально не понимаю.


                      1. raveclassic
                        04.08.2017 12:42
                        #10343446
                        -1

                        Тут полно комментов зачем. Хотя бы чтобы решить большинство описанных проблем на этапе компиляции.


                        1. bano-notit
                          04.08.2017 12:47
                          #10343450
                          -1

                          Позвольте, проблемы описанные тут занесены людьми, которые изначально писали на каких-нибудь плюсах да шурупах, и пришли сюда устраивать тут свои законы. В js как писали отлично без тайпскриптов так и пишут и будут писать, потому что ретурн забыть поставить — нерадивость программиста. Решения проблемы "что же возвращает функция" — jsdoc с поддержкой в ide, которая кстати работает быстрее любых flow и тем более ts, который ещё компилировать надо. Так что нет, проблем нету, они были завезены из "забугорья", и от туда же завозят решения.


                          1. raveclassic
                            04.08.2017 12:49
                            #10343466

                            Давайте просто не будем об этом. Не охота опять начинать холивар на тему ts vs jsdoc.


                          1. pnovikov
                            04.08.2017 12:55
                            #10343500
                            +1

                            Да, давайте держать типы в голове или в документации. А верифицировать их не компилятором, а пристальным взглядом. Правильно. Зачем пользоваться технологиями, когда есть человеческий мозг? :)


                            1. bano-notit
                              04.08.2017 12:58
                              #10343510
                              -2

                              Позвольте, в голое никто никогда ничего не держит, у нас есть прекраснейшие ide, которые не только типы из jsdoc'ов могут выдрать, но и свойства подсказать. Так зачем нам ещё куча компиляторов, если у нас есть уже инструмент, который и так парсит всё это дело в реальном времени и следит за всем адом преобразований, происходящем в коде?


                              1. raveclassic
                                04.08.2017 13:02
                                #10343522
                                +2

                                А для CI вы тоже IDE как-то разворачивать собрались?


                                1. bano-notit
                                  04.08.2017 13:09
                                  #10343542

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


                                  1. raveclassic
                                    04.08.2017 13:16
                                    #10343558
                                    +2

                                    Во-первых CI — не CD.


                                    Во-вторых, проверка "сходятся ли типы" является частью тестов.


                                    В третьих, как раз-таки не пофигу, так как, забивая на типы на CI, вы делаете шаг назад и тестируете подверженный багам код. Или вы из тех, кто пишет тесты на типы входных аргументов?


                                    1. bano-notit
                                      04.08.2017 13:24
                                      #10343568

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


                                      1. pnovikov
                                        04.08.2017 13:44
                                        #10343636

                                        Я вот как раз написал Reinforced.Typings, держа в голове проблему, которую решает ваша дока. Если у вас есть клиент к REST-сервису, то если у того внезапно поменяется контракт и вместо объекта { Name: '...', Age: '...' } ВНЕЗАПНО владельцы сервера решат отдавать { FirstName: '...', BirthDate: '...' } — то используя TypeScript и генерацию тайпингов вы узнаете об этом еще до того как запустите приложение. В случае с голым JS — такой баг скорее всего обнаружат таргет-юзеры.


                                        1. raveclassic
                                          04.08.2017 14:49
                                          #10343770

                                          А мы swagger-codegen используем, кода генерим TS с REST'а


                                          1. pnovikov
                                            04.08.2017 15:12
                                            #10343812

                                            А мы прямо из MVC-контроллеров. Не хочется ради такой мелочи тащить swagger в проект


                                            1. raveclassic
                                              04.08.2017 15:35
                                              #10343870

                                              Ну у нас джависты и так сваггер-спеку отдают. А тут просто звезды сошлись, чего б не генерить с нее ts.


                                      1. 0xd34df00d
                                        04.08.2017 19:30
                                        #10344414

                                        Как часто у вас ломаются тесты в процессе разработки? Да ладно там, лучше скажите, как часто у вас ломаются тесты в процессе рефакторинга?

                                        Мне хорошо, как только код собрался, в 99.5% случаев тесты сразу зелёные. Просто тайпчекер сам по себе выступает этаким тестировщиком, и зачем мне добровольно брать на себя его работу, мне не очень понятно.


                                        1. bano-notit
                                          04.08.2017 21:06
                                          #10344562

                                          Ломка тестов при изменении кода — достаточно частое явление. А если уж у вас 99.5% — да вы просто бог, мифическое существо. Ещё скажите, что люди, которые это тестируют вам обратно не отдают на доработку в 99%, если скажите, то я вам прямо поклонюсь.


                                          1. 0xd34df00d
                                            04.08.2017 21:13
                                            #10344568

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

                                            На плюсах, скажем, когда пишу, при рефакторинге тесты ломаются у меня сильно чаще. А вот на хаскеле… :)


                                            1. bano-notit
                                              04.08.2017 21:17
                                              #10344572

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


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


                              1. 0xd34df00d
                                04.08.2017 19:28
                                #10344406
                                +4

                                IDE способно лишь проверить, является ли код в известной мере консистентным с точки зрения типов, но не более.

                                Во-первых, у меня нет способа верифицировать модель кода, скажем, расставив в некоторых частях кода аннотации типов и убедившись, что всё им соответствует.

                                Во-вторых, есть ли у меня способ выразить «это Int, и это Int, но это два разные по смыслу Int'а, поэтому если я вдруг начну сравнивать один с другим или вообще использовать их в одном выражении, пни меня, пожалуйста»?


                                1. bano-notit
                                  04.08.2017 21:10
                                  #10344564

                                  Flow пробовали? Он может понять достаточно простой код, если ему расставить в нескольких местах аннотации, но к сожалению с тем же redux и connect из react-redux он уже не справляется, ему нужно в каждом месте указывать, какие типы данных ожидаются на вход колбеков.


                                  2 по смыслу разных инта… Интересно, а в ts вы тоже каждому инту свой тип даёте, или вы всё же под 2 разных по смыслу инта делаете 2 разных по смыслу типа, которые расширяют инт, ну или не расширяют, а как-то по другому просто копируют его "интерфейс", но имеют отдельное имя типа?


                                  1. 0xd34df00d
                                    04.08.2017 21:19
                                    #10344574
                                    +1

                                    Flow пробовали?

                                    Не пробовал, я вообще не фронтендщик, мне хватает чужих питонячьих скриптов, которые иногда приходится читать.

                                    2 по смыслу разных инта… Интересно, а в ts вы тоже каждому инту свой тип даёте, или вы всё же под 2 разных по смыслу инта делаете 2 разных по смыслу типа, которые расширяют инт, ну или не расширяют, а как-то по другому просто копируют его «интерфейс», но имеют отдельное имя типа?

                                    Я в ts по аналогичным причинам ничего не делаю, а в более других языках у меня есть newtype, скажем.


                                    1. bano-notit
                                      04.08.2017 21:26
                                      #10344580

                                      Я всегда страдал косноязычием, я как раз и говорил, что для разных по смыслу инта вы определите 2 разных по названию типа, чтобы компилятор вас потом по рукам бил, если ожидалось одно, а пришло другое, так вот, в jsdoc тоже есть такая конструкция как typedef, и ide будет несколько недоумевать, когда вы ей подсунете вместо функции похожей по параметрам на middleware функцию, которая ожидает 1 параметр — число и вообще возводит это число в квадрат. Но flow вообще пошлёт лесом при таких изысках, соответственно и ts должен послать.


                                      1. 0xd34df00d
                                        06.08.2017 01:17
                                        #10345620

                                        Если я правильно понял ваш исходный тезис, то в нём говорилось о ненужности компиляторов, тайпчекеров и прочих подобных инструментов, ведь есть же IDE. Flow и TS как-то уже не очень вписываются в эту парадигму.


              1. AxeLWeaver
                04.08.2017 17:21
                #10344164
                +1

                А если я пишу и у меня заработало с 1го раза? Я сломал систему?)))


                1. Strain
                  04.08.2017 17:22
                  #10344166
                  -1

                  Мои поздравления, console.log(«hello, world»)


                1. bano-notit
                  04.08.2017 21:02
                  #10344554

                  Если у вас получается с первого раза, значит вы правильно следовали мануалу "Get Started" того фреймворка, который выбрали для работы) Дальше уже нужно будет делать уже что-то, что требует отхода от этого мануала, и тогда уже начинается именно тот цикл)


                  1. AxeLWeaver
                    04.08.2017 21:05
                    #10344558

                    Спасибо, фреймворками не пользовался, лишь библиотечкой jQuery, просто вздумалось написать «Сапёра» на JavaScript, что-то похожее получилось, но всё время хочется «непоправимо улучшить», написать на чистом JS и как можно ближе к оригиналу.


                    1. bano-notit
                      04.08.2017 21:13
                      #10344570

                      jq — отдельная песня. Сам по себе неплохая идея синглтона в контексте сложности обычного интерфейса dom, но сами подумайте, это просто обвес, который добавляет только удобство и ни капельки функционала неповторимого и прибавки к эффективности. Поэтому я последнее время стараюсь незаметно подменить jq на zepto, чем и Вам советую побаловаться. Ибо быстрее, легче, а интерфейс тот же.


              1. AndreyRubankov
                11.08.2017 21:39
                #10357300

                Главное потом вдруг не выполнить npm i, который вам сломает проект обновлением зависимостей :-(


      1. BuccapuoH
        03.08.2017 11:29
        #10341228
        +10

        Не гребите всех под одну гребёнку. Фармошлёпов хватает во всех языках. Сам факт появления NodeJS (как и других библиотек/движков/языков) недвузначно намекает, что не всем нравится java/C# на бэкенде. Называть людей фармошлёпами только потому что они решили попробовать что-то новое, ИМХО, несправедливо.


        И опять же — никто не забирает хлеб у Java/C# — в них тоже денег вливают неплохо. За ними тоже не кто-попало стоит. У всех свои ниши и NodeJS — не серебряная пуля, как, впрочем, и Java/C#.


    1. AndreyRubankov
      03.08.2017 09:07
      #10340868
      +5

      1. const — слышу о нём почти отовсюду. Но вот незадача — почему все думают что он должен работать точно так же как в С/С++/<вставьте любимый язык>.

      Вот только const в ES2015 – работает точно так же как в C/C++/C#/Java: он запрещает изменять ссылку, но не запрещает изменять значения внутри объекта. Изменяемые объекты и коллекции будут работать одинаково – будут изменяться даже если их объявить с const (в java const назвали final, чтобы не давать ожидания, что весь объект будет неизменяемым).

      С тем же NodeJS, многие его хаят за то, что он посягает на святая-святых — backend.

      На самом деле NodeJs вполне подходит для некоторых задач WEB бекенда.
      Тяжелые расчеты или преобразования он сделать не может в силу единого event loop и отсутствия многопоточности, но получить данные из базы или перенаправить запрос куда-то в другой сервис (то, что сейчас многие бекенды делают) – с этой задачей NodeJs справится без проблем. Единственное чего нехватает – flow types, чтобы уменьшить количество тупых ошибок.


  1. irbis_al
    02.08.2017 23:17
    #10340500
    +4

    А Автор Топика например делал soap клиент на java?(Про сервер-soap я вообще молчу)
    Пусть попробует… а в node

    var soap = require('soap');
  var url = 'http://localhost/wsdl?wsdl';
  var args = {name: 'Имя'};
  soap.createClient(url, function(err, client) {
      client.SayHello(args, function(err, result) {
          console.log(result);
      });
  });

    Причём пусть изменит метод сервера… и потом помучается с java… а тут просто client.SayHellonew надо поменять.
    А сокеты… передать файл по сокету… попробуйте кодом на java и на node…
    В ява…
    пока есть данные читаем поток сокета пишем в выходной поток.
    в ноде
    socket.on('data',(data)=>{console.log(data)});


    А http client? а http сервер… Я Вам за 18 секунд подниму http сервер на node.
    На node код в 40 раз короче…
    И при этом(в моём опыте даже быстрее) не медленее.(Как они этого добиваются в одном потоке вообще непонятная магия)
    Я сам пишу на java и на node… и есть с чем сравнивать ,-ноде это простота кода и ёмкость… сосредотачиваюсь просто на решении., а не на обрастании синтаксических лексем.


    1. Strain
      03.08.2017 00:43
      #10340618
      +1

      А Автор Топика например делал soap клиент на java?(Про сервер-soap я вообще молчу)


      Справедливости ради нужно сказать что мой главный промышленный язык это Erlang, с 2013 года Elixir. Формально это языки со слабыми типами, как и JS ( правда без неявных преобразований ) поэтому формально ответ — нет. На Erlang / Elixir код будет тоже более компактный по сравнению с Java. Но опять возвращаясь к слабым типам — в экосистеме Erlang / Elixir есть чудесные инструменты для статического анализа такие как Dialyzer и Xref. При правильном стиле написания кода ( тут ничего сложного нет ) эти инструменты выводят алгебраические типы для 100% функций и выражений в исходниках, буквально для каждой строчки и каждой буквы кода. То есть потенциальные проблемы с типами и просто опечатки видны ещё до запуска программы ( эти утилиты анализируют скомпилированный байткод ). В отсутствии подобных инструментов заключается один из главных минусов JS экосистемы.


      1. Grox
        03.08.2017 02:00
        #10340676
        +4

        TypeScript решает это для JS. Через поддержку в IDE, ещё до компиляции. Вопрос с типами снят?


        1. Shifty_Fox
          03.08.2017 17:13
          #10341962

          Я вам еще помогу, а то по тредам либо JS, либо TS.
          Есть еще замечательный Flow, у которого есть режим совместимости синтаксиса. Он анализирует JS код и дает статические проверки. Можно не покидая JS решить эту проблему.


          1. Strain
            03.08.2017 17:51
            #10342030

            TS — всё-таки это другой язык, не JavaScript. Да и Flow предполагает написания нотации типов для функций — необходимо их явно указывать. Это лучше чем ничего, согласен. Но есть реально классные компиляторы которые позволяют выводить типы для всех функций в программе без единой нотации типа. Вот пример простой программы на PureScript ( диалект Haskell компилируемый в JavaScript ), вот этот же код в работе. Код полностью типизированный и безопасный. Ни единой нотации типа в коде нет. Вот такая магия. В 2017 году многие компиляторы так умеют. Ещё раз спасибо за совет!


        1. Yeah
          04.08.2017 11:05
          #10343222

          А как же as any?


          1. mayorovp
            04.08.2017 13:02
            #10343520

            as any не доставит проблем если так не делать..


      1. VioletGiraffe
        03.08.2017 08:13
        #10340808
        +2

        А можно поинтересоваться, где это в реальной жизни используется Erlang (который я всегда считал академическим языком, как и большинство функциональных, кроме, может быть, Lisp)?


        1. Strain
          03.08.2017 08:43
          #10340842

          Тут тоже не обошлось без корпораций конечно. Язык был создан компанией Ericsson в 1986 году, фирма продолжает и до сих пор вливать в него евро, недавно был релиз 20й версии. Изначально Erlang был создан под одну единственную задачу — написание ПО для маршрутизаторов ( этого же самого Ericsson ), в связи с этим там изначально отсутствовали некоторые казалось бы необходимые типы данных такие как например строки или maps, не было нормальных кастомных типов данных. Но со временем Erlang стал языком общего назначения на котором пишется почти всё что угодно. Используется по-прежнему в основном в телекоммуникациях / телефонии, очень хорош для высоконагруженных систем из-за простых и надёжных средств параллелизации ( которые кстати были ещё в первых версиях OTP середины 80х ). С приходом Elixir, платформа стала действительно популярной и на ней пишется буквально всё. Особый вклад в популяризацию Erlang / Elixir внёс фреймворк Phoenix — это новая рельса, без преувеличений.


        1. mayorovp
          03.08.2017 09:27
          #10340904
          +2

          На Erlang написан RabbitMQ, к примеру. Еще на нем был написан популярный XMPP-сервер, но название не помню.


          1. farcaller
            03.08.2017 10:21
            #10341042
            +2

            ejabberd.


          1. 0xd34df00d
            04.08.2017 04:07
            #10342732

            Почему «был», он и сейчас и написан, и всё ещё жив.


        1. farcaller
          03.08.2017 10:21
          #10341046

          на нем написан бекенд ныне крайне популярного в некоторых кругах чата Discord.


          1. bano-notit
            03.08.2017 13:14
            #10341498

            Да вроде на эрланге и у вотсапа бек написан...


            1. kaljan
              03.08.2017 14:56
              #10341708

              Вотсап это старый добрый xmpp под капотом


              1. bano-notit
                03.08.2017 22:21
                #10342466

                Изначально, но потом они его посадили на свои бустеры с переписью части самого ejabberd. Короче они неплохо заморочились, поэтому фб наверное таки деньги за это отвалил...


                1. kaljan
                  03.08.2017 22:37
                  #10342494
                  +2

                  а я думал фейсбук отвалил такие деньги за количество людей которые пользуются ватсапом)


                  1. bano-notit
                    03.08.2017 22:41
                    #10342500

                    Ради одних только людей у него есть свой меседжер и вообще-то говоря нехилое количество клиентов самой соц сети.


      1. irbis_al
        03.08.2017 08:52
        #10340850
        +2

        Вы сказали
        >>Справедливости ради нужно сказать что мой главный промышленный язык это Erlang, с 2013 года Elixir.
        Вот я не знаю… что тут добавить… чего тогда анализируете java против node… Вот я пишу глубоко на том и на том… и могу позволить себе небольшой анализ.(Там вверху я написал где node рвёт java как тузик грелку… но у меня есть и случаи где java пользовать предпочтительнее… просто недостатки языка это продолжение достоинст)


    1. Noa69
      03.08.2017 11:55
      #10341290
      +4

      Я Вам за 18 секунд подниму http сервер на node.

      А я вам за 1,8 секунды его положу, например.


      1. irbis_al
        03.08.2017 12:25
        #10341378
        +10

        Ой да ладно положите… Вам 40 минут на java код только писать надо будет.


        1. Noa69
          03.08.2017 12:38
          #10341420
          -2

          на bash`е все еще быстрее чем на JS


        1. Labunsky
          03.08.2017 14:09
          #10341608
          -4

          40 минут на java код только писать надо будет
          Это открыть сокет и обработку сообщений по нему 40 минут писать-то?


      1. Coffin
        03.08.2017 17:18
        #10341972
        +1

        рецепт в студию :)


        1. copist
          03.08.2017 20:59
          #10342332

          $ npm install -g node-static # install dependency
          $ static -p 8000

          (источник: Big list of http static server one-liners)


          1. bano-notit
            03.08.2017 22:22
            #10342470
            -1

            Можно всё же вместо install использовать просто i так же как и -g вместо --global.


        1. copist
          03.08.2017 21:06
          #10342346
          +1

          положить

          $ npm install -g loadtest
          $ loadtest [-n requests] [-c concurrency] [-k] URL


    1. Apx
      03.08.2017 20:20
      #10342290

      Why not python? Или рубя в который можно одной строчкой всё наговнякать?

      Не стоит забывать для чего изначально делался язык и какие тогда были ограничения


    1. zirix
      03.08.2017 23:23
      #10342550
      +1

      А http client?

      на java:


      String text = IOUtils.toString(new URL("http://...."), "UTF-8");

      (import org.apache.commons.io;)


      а http сервер

      @Controller
@EnableAutoConfiguration
public class SampleController {

    @RequestMapping("/")
    @ResponseBody
    String home() {
        return "Hello World!";
    }

    public static void main(String[] args) throws Exception {
        SpringApplication.run(SampleController.class, args);
    }
}


      1. irbis_al
        03.08.2017 23:38
        #10342562
        -4

        Да??? Прям так… Пробую скомпилить и запустить… ах блин… мне же надо либо мавен либо gradle файл сделать… так… почитаем как его делать… Ой что-то я с синтаксисом мавена не разобрался/накосячмл… сейчас погуглю.
        А в node(для линукса)

        yum install node(Вот даже ноду установлю для Вас)
mkdir myhttp
npm install express
 node mydir/bin/www

        Можете сами попробовать
        Я теперь soap клиент сделайте...websocket сделайте… файл по сокету передайте…
        И сделайте это там и там… как я в соё время сделал… и офигеете как всё просто…
        А древние говорили…
        Упрощать сложно… а вот усложнять легко.
        Я писал выше, что пишу глубоко на ноде и ява… и есть с чем сравнить… а Вы видимо только на яве.Ноде лаконичнее… легче читается… не задумываешься об всяческих лексемах.


        1. vintage
          04.08.2017 00:41
          #10342630

          websocket сделайте… файл по сокету передайте…

          Не Ява, конечно, но другой, не менее статически типизированный язык:


          import vibe.d;

this()
{
    "wss://websockets.example.com/".URL.connectWebSocket.send( "./data.bin".readFile );
}

          Сможете на ноде так же просто и лаконично?


          1. bano-notit
            04.08.2017 00:42
            #10342632
            -1

            Енто что за невиданный зверь такой?


            1. vintage
              04.08.2017 00:46
              #10342636

              Я там ссылку добавил.


              1. bano-notit
                04.08.2017 01:00
                #10342648
                -2

                Не заметил её как-то...


        1. zirix
          04.08.2017 04:34
          #10342740

          websocket сделайте… файл по сокету передайте…

          Так должно сработать:


          @ClientEndpoint
public class CustomClientEndpoint 
    @OnOpen
    public void onOpen (Session session) {
        ByteBuffer byteBuffer = ByteBuffer.allocate(1000);
        try (FileInputStream file = new FileInputStream("/path/to/file")) {
        byteBuffer.put(IOUtils.toByteArray(file));
        }
        byteBuffer.flip();

        session.getBasicRemote().sendBinary(byteBuffer);
    }
}

WebSocketContainer container = ContainerProvider.getWebSocketContainer();
container.connectToServer(CustomClientEndpoint.class, new URI("ws://localhost:8080/path"));


          1. zirix
            04.08.2017 05:06
            #10342746

            забыл maven:


                <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.5.6.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-websocket</artifactId>
        </dependency>
        <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
            <version>2.5</version>
        </dependency>
    </dependencies>


          1. irbis_al
            04.08.2017 08:18
            #10342860
            -1

            Я не знаю… насчёт интуитивно-понятности Вашего кода на ноде без всякого мавена

            var socket = new WebSocket("ws://localhost:8097/ws");
ocket.onopen = function() {
  alert("Соединение установлено.");
};

socket.onclose = function(event) {
  if (event.wasClean) {
    alert('Соединение закрыто чисто');
  } else {
    alert('Обрыв соединения'); // например, "убит" процесс сервера
  }
  alert('Код: ' + event.code + ' причина: ' + event.reason);
};

socket.onmessage = function(event) {
  alert("Получены данные " + event.data);
};

socket.onerror = function(error) {
  alert("Ошибка " + error.message);
};

            Если Вам эта длиннотень нравится
            WebSocketContainer container = ContainerProvider.getWebSocketContainer();
container.connectToServer(CustomClientEndpoint.class, new URI("ws://localhost:8080/path"));

            непонятная… не буду Вас переубеждать…
            А ещё Вам сказу… помните песню Бутусова,
            -«Тут составы смяли чтобы сделать колонны»…
            Так вот это об этом Вашем решении… Вставить в зависимость такого монстра как spring
            org.springframework.boot
            И ради этого маленького решения потянуть зависимости org.springframework.boot
            .я понимаю Вы хотели показать краткость… и она из-за спринговых аннтотаций.(Но всё равно неизящно, интутивно непонятно).
            Я сколько пищу на яве… и надо мне передать по сокету.(скопировать файл)… я ищу свои прежние решения, чтобы скопипастить подобную хрень.
            ByteBuffer byteBuffer = ByteBuffer.allocate(1000);
            try (FileInputStream file = new FileInputStream("/path/to/file")) {
            byteBuffer.put(IOUtils.toByteArray(file));

            А в ноде не ищу… мысль сама ложится.
            Мысль: Так надо забрать из сокета(не ws)
            socket.on('data',(data)=>{Работаю с данными...причём не Важно бинарные,или текстовые })

            Мысль на русском эквивалентна количеству кода.
            А Автору топика скажу(И больше уже не буду спорить..), что Node и завоевал
            популярность ибо его коэффициент Эффективность/Простота =Очень Высок.
            java тоже эффективна… но не проста.(И есть моменты, которые бы я делал только на java)


      1. fogone
        04.08.2017 18:58
        #10344360

        на котлине:
        клиент

        val html = URL("http://google.com").openStream().reader().readText()

        сервер
        fun main(args: Array<String>) {
    embeddedServer(Netty, 8080) {
        routing {
            get("/") {
                call.respondText("Hello, world!", ContentType.Text.Html)
            }
        }
    }.start(wait = true)
}


    1. Braidner
      04.08.2017 17:21
      #10344162

      Ну-ну, вы про спринг бут слышали? Все тоже делается в пару строк, но имеем нормальную типизацию. Так что не надо пудрить мозги людям.

      public class WebServiceClient {

    private static final String MESSAGE =
        "<message xmlns=\"http://tempuri.org\">Hello World</message>";

    private final WebServiceTemplate webServiceTemplate = new WebServiceTemplate();

    public void customSendAndReceive() {
        StreamSource source = new StreamSource(new StringReader(MESSAGE));
        StreamResult result = new StreamResult(System.out);
        webServiceTemplate.sendSourceAndReceiveToResult("http://localhost:8080/AnotherWebService",
            source, result);
    }
}


    1. sshikov
      10.08.2017 22:36
      #10355162
      +1

      Вы неправы. Я понимаю, что это коммент, а не статья, но то что вы демонстрируете — это скажем 10% возможностей SOAP. Поэтому у вас и получается такой короткий пример. И кстати, возьмите уже CXF — и у вас получится ровно тоже самое. И для остальных случаев, кстати.


  1. Apx
    02.08.2017 23:20
    #10340506
    +6

    Ещё пару лет понырять в js вам и удалите статью по собственному желанию))) (Java developer)


    По долгу службы пришлось тоже с js работать и ничего, жив здоров и со всеми пунктами вашими уже давно живу спокойно вместе — почти как с пилящей женой)


    P. S. По поводу одного потока — кто запрещает ранить несколько процессов и лоудбалансить их?


  1. Iqorek
    02.08.2017 23:22
    #10340512
    +13

    Вы не совсем разобрались в теме, во первых если JavaScript был ужасен, то это было до es6 и выше. Детские болезни еще не выпилили на 100%, но встречи с ними можно избежать.

    однопоточный рантайм ( в 2017 году!!! )

    Во первых это круто, потому что многопоточный почти никто не умеет писать. Да да, запускать потоки можно научиться за один вечер, делать это эффективно, увы. Во вторых, он не однопоточный, все IO операции производятся в других потоках и именно эти операции берут время, в одном потоке бежит только ваш код. Зато никаких блокировок, никаких контекст свитчей, никаких race condition (почти) и прочих многопоточных радостей, которые 1 наносекунду превращают в 1 миллисекунду.

    отсутствие единой системы / стандартов реализации модулей

    Тем не менее вопрос решен, можно выбрать один из стандартов и в принципе все будет работать

    отсутствие единых стандартов структуры проекта

    Это не проблема языка, некая стандартизация есть.

    слабые типы с неявными ( и порой довольно странными ) преобразованиями

    Например? То что они есть, не обязывают вас их использовать, иногда разные странные вещи бывают полезны.

    отсутствие нормальных классов / ООП

    Так ли нужен ООП? Я очень долго слышу мантру ООП, ООП, но по факту это всего лишь одна из техник написания кода, не всегда оправданная, это не панацея для написания правильного и хорошего кода. Правильный и хороший код, это тот, который делает то что надо, за минимальное время. Я видал не один килобайт, а может и мегабайт г-но кода написанного на ООП.

    отсутствие единого вменяемого и работающего статического анализатора кода

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

    этот чудесный контекст this

    Лучше вообще не использовать это слово. Как goto. Это реально. Жаль, но это одна из родовых травм, кто ж в 96м году знал, что так вот оно получится.

    абсолютно дурацкая реализация pattern matching

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

    отсутствие единой технологии работы с асинхронным кодом

    Эволюция, все идет в async, в браузерах уже есть, в ноде тоже, скоро код подтянется. При чем можно использовать все методы одновременно, если в этом есть резон.

    const ( который на самом деле НЕ const )

    Не понял суть наезда. Можно наехать на var, но сегодня его и использовать моветон.

    абсолютно безумный npm с пакетами качества «братишка я тебе покушать принёс»

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

    В общем JavaScript ужасен как ни крути, но он имеет бешеную популярность благодаря баблу и низкому порогу входа.

    Нет, он не идеален, но
    • Удивительно, но производительность у него не хуже чем у той же java или c# (проверял)
    • Нет заморочек с мультипоточностью, при этом асинхронность остается
    • Кроссплатформенность и обратная совместимость
    • Удобные инструменты, которые просто работают, как то например упомянутый npm

    Это мои плюсы, а еще несколько лет назад я был в вашем лагере.


    1. porn
      03.08.2017 08:48
      #10340846
      +2

      Я бы не стал приводить npm как плюс js. Посмотрите на composer хотя бы.


      1. Iqorek
        03.08.2017 09:48
        #10340952
        +3

        Это не плюс js это плюс nodejs, который поставляется с очень удобным и простым менеджером пакетов. Можно спорить о его недостатках, они как и везде есть, но у него есть неоспоримое достоинство, он тупо работает из коробки, при этом он не делает лок на себя, вы можете использовать любой другой менеджер пакетов.


    1. franzose
      03.08.2017 13:06
      #10341480
      -1

      Во первых это круто, потому что многопоточный почти никто не умеет писать.

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


      1. Iqorek
        03.08.2017 14:21
        #10341630

        Допустим делать безопасно несложно, а вот с правильностью проблема. Мультипоточное программирование на порядок сложней однопоточного и понять, где вы теряете производительность, бывает очень тяжело. То есть в теории все понятно, избегайте блокировок и синхронизаций. Пример из жизни, был у нас крутейший мультипоточный сервер, все вроде бы написано по феншую, с неблокирующим IO, immutable данными чтобы не синхронизировать между потоками и так далее, но производительность все равно не была впечатляющей. Где мы упали? В самом неожиданном месте, логер у нас, как оказалось был блокирующий (один из популярных опенсорсных на то время), то есть когда несколько потоков пишут в лог, а писали мы много и не писать не могли, только один из них это делает, остальные уходят в контекст свитч со всеми вытекающими. По сути у нас все потоки работали хуже, чем если бы у нас был один поток, потому что в этом случае у нас хотя бы не было контекст свитчей. Ну сделали мы свой логер неблокирующим, получили другую проблему, потоки работают с данными в памяти и это очень быстро, а лог то он в файл пишется, а это хоть и быстро, но как минимум в несколько тысяч раз медленней, поэтому при большой нагрузке очередь лога начинала расти, как снежный ком, получалось или надо логи дропать или тормозить всех, подождите мы за вами записывать не успеваем. В конечном итоге мы решили и эту проблему и еще несколько которые вылезли по пути. Это я к тому, что не всегда ваш код виноват в просадке производительности. В мультипоточности очень легко выпустить весь пар в свисток и не заметить этого.


        1. greendimka
          03.08.2017 16:19
          #10341880
          +1

          Вам лучше не лезть в проектирование с такими суждениями. Как один поток спас бы вас от тормозов лога? (ах, ну да — контекст свитч бы отсутствовал — наверное помогло бы :)
          Пишите на диск уйму сообщений? Кэшируем много сообщений — и пишем один блок, кэшируем много сообщение — и пишем один блок. А если каждое сообщение писать (да еще при этом каждый раз файл открывать, а записав — закрывать), то — никакая архитектура хранилища не будет справляться.


          1. vintage
            03.08.2017 16:45
            #10341924

            Кэшируем много сообщений — и пишем один блок, кэшируем много сообщение — и пишем один блок.

            Ось и так это делает. Если, конечно, не вызывать fsync после каждого сообщения.


            1. greendimka
              03.08.2017 17:20
              #10341976

              На уровне бизнес-логики ось этого не делает, т.к. ничего не знает о вашей бизнес логике. Ось это делает на уровне потоков.


              1. vintage
                03.08.2017 17:57
                #10342048

                А при чём тут пресловутая бизнес-логика?


          1. Iqorek
            03.08.2017 17:16
            #10341966

            (ах, ну да — контекст свитч бы отсутствовал — наверное помогло бы :)

            Да, помогло бы. Наш сервис большую часть процессорного времени занимался именно этими свитчами, а не обработкой запросов. Переключение контекста это относительно тяжелая операция, по крайней мере по сравнению с операцией обработки запросов в нашем сервисе.
            Кэшируем много сообщений — и пишем один блок, кэшируем много сообщение — и пишем один блок. А если каждое сообщение писать (да еще при этом каждый раз файл открывать, а записав — закрывать), то — никакая архитектура хранилища не будет справляться.

            Вам уже ответили выше, что тоже самое делает ОС, но в начале мы так и сделали, как написал выше, очень быстро мы обнаружили проблему переполнения. Вторая проблема, это вероятность потерять последние логи, в случае креша. В итоге мы сделали логер на базе spinlock что поток хотя бы не уходил в свитч. И да, это помогло.


        1. pnovikov
          03.08.2017 17:04
          #10341948

          Вообще-то то, как выйти из описанной вами проблемы, в приличных компаниях спрашивается на собеседованиях так-то…

          И еще у меня ощущение, что вы путаете многопоточность и асинхронность.


        1. vlad9486
          03.08.2017 17:38
          #10342010

          Буферизируйте лог в памяти.


          1. Iqorek
            03.08.2017 17:45
            #10342022

            См выше, по условиям задачи, нельзя было потерять даже 1 строку лога в случае падения/перезагрузки сервиса.


            1. vlad9486
              04.08.2017 10:06
              #10343054

              .


        1. kaljan
          03.08.2017 17:39
          #10342012
          -1

          Давно уже есть seq, кибана, и, самое простое — логи в базу


          1. Iqorek
            03.08.2017 17:47
            #10342026

            Это было задолго до кибан и бигдат. И это был просто пример, как можно поскользнуться на ровном месте.


        1. izzholtik
          04.08.2017 09:07
          #10342930
          +4

          Вы сейчас всерьёз приводите кривой логгер как пример сложности многопоточного программирования?


          1. Iqorek
            04.08.2017 09:43
            #10342998

            Только логгер не самописный, а из семейства log4, на тот момент один из популярных и использовали его не только мы. Но проблему до нас никто не видел да и мы ее далеко не сразу обнаружили.


      1. pnovikov
        03.08.2017 17:07
        #10341952
        +4

        Господа, я может что-то путаю, но в мою молодость умение писать многопоточный код, знание примитивов синхронизации и (желательно) идиоматических задач многопоточности (обедающие философы, читатель-писатель и т.д.) входило в базовый набор навыков программиста, который проверялся на собеседованиях еще до конкретных вопросов по языку/технологии. Это вроде как было общей теоретической базой, которой обучали во всех вменяемых IT-ВУЗах.

        Сейчас что-то изменилось? Я что-то пропустил?


        1. Iqorek
          03.08.2017 17:46
          #10342024
          +1

          Многопоточность это сложная тема, там много неочевидных вещей, которые нельзя просчитать в голове. Даже если вы хорошо знакомы с теорией. Очень легко не только не выиграть в производительности, но потерять. Я всегда делаю тесты производительности и проверяю разные варианты, в том числе и однопоточный вариант, и другого способа узнать вы идете в правильном направлении, нет.


          1. pnovikov
            03.08.2017 17:58
            #10342052
            +2

            Само собой многопоточность — это сложно. Ну так а никто и не говорит что в принципе программирование — это просто. Всегда надо думать головой и просчитывать варианты.

            Касательно непосредственно вашего примера — я не думаю что
            а) вся проблема была в переключениях контекста (ибо тогда бы вам пришлось поубивать изрядную долю процессов на своем сервере для оптимизации)

            б) что однопоточная модель, скажем, nodejs, спасла бы вас от переключений контекста, ибо как контексты бы все равно переключались, ибо как, скажем, nginx, стоящий перед вашей нодой — будет создавать новые процессы. Вы бы не решили проблему, а просто перенесли её на другой уровень или же вообще спрятали её в нерешаемые дебри.

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


            1. vintage
              03.08.2017 18:03
              #10342064

              Логи замечательно реализуются через wait-free алгоритмы. Не нужны тут никакие синхронизации.


              1. Iqorek
                03.08.2017 18:46
                #10342118
                +2

                Да, но что делать если в бассейн наливается больше воды, чем выливается? Когда есть блокировка, процесс который генерирует логи, ждет и новые логи не создает, хотя при этом простаивает. А если его не блокировать, пока я пишу первый лог, он мне еще 10 настрогает. Решений несколько:

                1. Выбрасывать логи если возникло переполнение (не наш вариант, нам нужны все логи, хотя кому то может и подойдет)
                2. В момент переполнения, начинать блокировку потоков, которые пишут в лог, пока все хорошо,
                  будет работать быстро и без блокировок, но в случае превышения емкости, сервис начнет подлагивать (ввиду того что у нас это была штатная ситуация, этот вариант тоже отмели)
                3. Использовать спинлоки, которые тормозят процесс на время записи лога, но не делают переключение контекста (и это то, что мы выбрали, как наименьшее зло)


                1. vintage
                  03.08.2017 19:51
                  #10342234
                  +2

                  Да тут даже спинлоки не нужны — хватит и атомиков. Создаём циклический буфер, один поток пишет, другой читает. На каждый поток по буферу. Логер читает из буферов раундробином. Потоки перед записью проверяют не полон ли буфер и пока полон — крутятся в бесконечном цикле. Пока логер успевает разгребать сообщения — потоки пишут в него мгновенно (записали сообщение в свободное место буфера, сдвинули индекс конца). Как перестал успевать — самые активные писатели начинают периодически засыпать.


                  Пример реализации.


                  1. copist
                    04.08.2017 15:01
                    #10343788

                    Кстати про this, в глаза бросилось

                    Это же язык GoLang, я не ошибся?

                    Это как расшифровать?

                    /// Limit channel to 512B by default
this( int size = 512 / Message.sizeof - 1 ) // что этот  this делает?
{
	enforce( size > 0 , "Channel size must be greater then 0" );
	this.messages = new Message[ size + 1 ]; // а этот?
}


                    1. vintage
                      04.08.2017 18:04
                      #10344270

                      Это D.


                      this() — конструктор.
                      ~this() — деструктор.
                      this. — экземпляр класса.


            1. Iqorek
              03.08.2017 18:33
              #10342104

              Само собой многопоточность — это сложно

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

              Нет конечно, но из всех больших бутылочных горлышек, это был крупный улов.
              А вот как раз вменяемая многопоточная модель с shared-данными вас могла бы спасти

              Не соглашусь, если вы хотите скорости и многопоточности одновременно, общие данные между потоками зло, потому что будут блокировки, их не избежать. Операции над объектами в памяти очень быстрые,
              наберите в консоли браузера 
              let sum = 0; console.time('for 1 million'); for(let i=0;i<1000000;i++) {sum+=i}; console.timeEnd('for 1 million'); console.log(sum)
              1 миллион сложений мой браузер сделал за 25мс. Если этот код разбить на два потока (не в js кончено, в другом языке) и добавить синхронизацию между потоками, а как без нее, я даже боюсь предположить во сколько раз возрастет время исполнения.
              Универсального рецепта нет, но нужно стремиться к тому, чтобы одновременно одни и те же данные обслуживал только один поток.
              асинхронный сервер для логов и какой-нибудь rabbitmq, чтобы не было проблем с логами в случае крэша основного процесса.

              Мы уперлись в недостаточно быструю операцию записи в файл, запись в сокет рабита ничем не быстрей.


              1. pnovikov
                03.08.2017 18:47
                #10342120
                +2

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

                Простите, а зачем этот код вообще выполнять в 2 потока? Если вы думаете что многопоточность — это такая волшебная таблетка, которая просто все ускоряет — вы очень сильно ошибаетесь. Я подскажу: если перед операцией sum+=i вы добавите, например, скачивание картинки — то я даже боюсь предположить во сколько раз сократиться время исполнения, если это делать в 2 потока. :)


                Не соглашусь, если вы хотите скорости и многопоточности одновременно, общие данные между потоками зло

                Очень даже добро, если правильно выстроить обращения к общим данным. Кроме того, выше вон человек заметил про что существуют механизмы неблокирующей синхронизации (wait-free), с которыми работа с общими данными становится дюже быстрее. Погуглите по слову "concurrency".


                Так js — это отличный выход, получить высокую производительность, но без явной многопоточности

                Я открою для вас секретик: любой асинхронный вызов в nodejs так же — вы будете смеяться — переключает контексты. Откройте исходники и почитайте — там внутри тредпул, если я правильно врубился. Так что js в данном случае — как раз плохое решение. Хорошее — это C с posix-тредами. Но, повторюсь, это только в случае если проблема действительно в переключениях контекста, во что я по-прежнему не верю. :)


                Мы уперлись в недостаточно быструю операцию записи в файл, запись в сокет рабита ничем не быстрей.

                Сомнительное утверждение. Запись в сокет не приводит к движению магнитной головки диска (если у вас обычный HDD, а не SSD).


                1. Iqorek
                  03.08.2017 19:00
                  #10342152
                  -1

                  Простите, а зачем этот код вообще выполнять в 2 потока? Если вы думаете что многопоточность — это такая волшебная таблетка, которая просто все ускоряет — вы очень сильно ошибаетесь.

                  Воот! Народ именно так и думает. Точнее не думает, а просто разделяет код на несколько потоков и довольный идет пить кофе. Это я встречал, не то что неоднократно, я даже не всегда был в состоянии доказать человеку, что он неправ. У него в голове, два потока работают параллельно, значит быстрей. Все, разговор окончен. Что есть цена у каждого потока, до этого доходят далеко не все.
                  Я открою для вас секретик: любой асинхронный вызов в nodejs так же — вы будете смеяться — переключает контексты. Откройте исходники и почитайте — там внутри тредпул, если я правильно врубился.

                  Он переключает контексты, но не в основном потоке, основной поток бежит пока операционная система не заморозит.
                  Сомнительное утверждение. Запись в сокет не приводит к движению магнитной головки диска

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


                  1. pnovikov
                    03.08.2017 19:09
                    #10342166
                    +4

                    Воот! Народ именно так и думает. Точнее не думает, а просто разделяет код на несколько потоков и довольный идет пить кофе.

                    Ну дык и как смена технологии спасет вас от тупого разработчика, который ею пользуется? Тут народ надо обучать, а не предлагать супер-технологии, которые избавят от всех проблем. И это, кстати, одна из проблем JS-а: он скрывает проблему, говоря "вот пишите как мы, а о потоках не думайте". Мне не кажется что такой подход может довести до добра.


                    Он переключает контексты, но не в основном потоке

                    Простите великодушно, но переключение контекста не может происходить "в потоке". Оно происходит между потоками или между процессами. Вы что-то путаете. Если я правильно понял исходники nodejs — то там все еще веселее: в рамках якобы "однопоточной" модели у вас с каждой операцией запускается (берется из тредпула, но я для простоты говорю "запускается") неопределенное количество потоков, на которых просто висят коллбеки. И это еще бОльший ад чем использование многопоточности явно — в последнем случае у вас хотя бы есть контроль над ситуацией. Для сравнения: C# использует для тех же целей I/O completion ports, которые не создают лишних потоков.


                    Попробуйте написать простенький клиент сервер

                    Потом


              1. 0xd34df00d
                04.08.2017 06:30
                #10342796
                +2

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

                А зачем там синхронизация? Один поток суммирует свою часть и получает свою частичную сумму, другой — вторую, а потом, когда они оба завершаются, обе частичные суммы складываются, и получается результат.

                И этот вариант тоже можно чуточку оптимизировать.


                1. maxpsyhos
                  04.08.2017 08:50
                  #10342902
                  -2

                  Вы так пишите, будто эти потоки есть сам по себе как данность.
                  Второй поток надо создать, запустить, подождать, пока он выполнится, и потом сложить. Опять же у ОС диспетчеризация потоков тоже не бесплатна.
                  И вот если на всю эту канитель накладных расходов будет более 12,5мс (максимальный теоретический выигрыш от параллельности), то в результате всё будет работать только медленнее.
                  И то это всё только при условии, что у нас есть ещё одно свободное процессорное ядро, иначе эти потоки просто встанут в очередь и точно так же выполнятся последовательно, только ещё с накладными расходами на содержание потоков, и всё гарантированно будет работать медленнее.

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


                  1. 0xd34df00d
                    04.08.2017 09:31
                    #10342966

                    Второй поток надо создать, запустить, подождать, пока он выполнится, и потом сложить.

                    Или достаточно кинуть задачу в очередь, а фиксированный тредпул её разгребёт.

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

                    И вообще, я тут наваял очень тривиальный и тупой бенчмарк:
                    Тута
                    2:29:24 d34df00d@deadaven ~/Programming/tmp % cat main.cpp && clang++ -O3 -std=c++14 -pthread main.cpp -o main && time ./main
#include <thread>
#include <iostream>

int main()
{
        int sum = 0;
        for (int i = 0; i < 1000000; ++i)
        {
                std::thread t { [] (int& sum) { ++sum; }, std::ref(sum) };
                t.join();
        }

        std::cout << sum << std::endl;
}
1000000
./main  0,98s user 4,21s system 66% cpu 7,765 total


                    1. maxpsyhos
                      04.08.2017 09:58
                      #10343040

                      А теперь вот мне стало интересно: откуда у вас взялось это число?
                      Как это откуда? По условию «бенчмарка» последовательная программа отработала за 25мс (принято на слово). Если её разделить на 2 половины, то в идеальном вакууме время исполнения сократится вдвое, на 12,5мс. Если накладные расходы превысят эту цифру, значит итоговая производительность не увеличилась.

                      Насколько? Какова вероятность отсутствия прочих свободных ядер?
                      А мне то откуда знать, что у вас за машина и чем ещё она загружена? Например на небольшой однопроцессорной VPS-ке вероятность отсутствия прочих свободных ядер строго равна единице, поэтому там никакие выкрутасы с многопоточностью не смогут увеличить производительность, от слова совсем.


                      1. 0xd34df00d
                        04.08.2017 19:33
                        #10344420

                        Как это откуда? По условию «бенчмарка» последовательная программа отработала за 25мс (принято на слово). Если её разделить на 2 половины, то в идеальном вакууме время исполнения сократится вдвое, на 12,5мс.

                        А, я контекст потерял, прошу прощенья.

                        Если накладные расходы превысят эту цифру, значит итоговая производительность не увеличилась.

                        К счастью, накладные расходы на более чем три порядка меньше.

                        А мне то откуда знать, что у вас за машина и чем ещё она загружена?

                        Это вам про ваше окружение надо знать, а не моё :)

                        Не, конечно, если у вас на всех проектах однопроцессорные VPS'ки, то да, никакие многопоточности вам заведомо не нужны.


                  1. AndreyRubankov
                    04.08.2017 09:43
                    #10343000

                    Вы правы на счет того, что все не так просто, как описал 0xd34df00d, но все не совсем так, как вы думаете.

                    Второй поток надо создать
                    Обычно, когда готовится многопоточность, используется пул потоков, у которого есть своя очередь задач. Так что потоки создаются только на старте приложения, т.е. это не так дорого, как вы думаете.
                    А дальше там все еще интереснее: потоки, системный планировщик и прочее, но это тянет на небольшую статью/заметку, так что расписывать в комменте не буду.

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

                    Тут стоит отметить, что системная диспетчеризация работает быстрее, чем программная. Как минимум, потому, что поток, в котором выполняется программная диспетчеризация так же может исчерпать кварт времени и он будет приостановлен для выполнения другого потока.

                    Говорить, что это будет Гарантированно медленнее – это поспешные выводы.

                    ps: Не стоит забывать, что за популярностью JS, NodeJS и асинхронности стоит львиная доля маркетинга и на самом деле далеко не все так красиво, как рассказывают в «рекламе».

                    pps:
                    12,5мс (максимальный теоретический выигрыш от параллельности)
                    А можете предоставить источник? Я так полагаю, вы читали какую-то научную работу на эту тему?


                    1. maxpsyhos
                      04.08.2017 10:09
                      #10343060

                      Говорить, что это будет Гарантированно медленнее – это поспешные выводы.
                      Не согласен. Если у вас есть ровно одно свободное ядро, на котором надо выполнить 1млн операций, то как их не диспетчерезируй, быстрее они этого не выполнятся.

                      ps: Не стоит забывать, что за популярностью JS, NodeJS и асинхронности стоит львиная доля маркетинга и на самом деле далеко не все так красиво, как рассказывают в «рекламе».
                      Я и не утверждаю, что конкретно Нода более производтельна, чем что-то другое. Я даже наоборот, почти уверен, что нодовый неявный тредпул реализован не лучшим способом. Я только о том, что распараллеливание в реальных задачах на реальном железе не всегда даёт преимущество.

                      А можете предоставить источник?
                      https://habrahabr.ru/post/334760/?reply_to=10342966#comment_10342104
                      1 миллион сложений мой браузер сделал за 25мс. Если этот код разбить на два потока...


                      1. AndreyRubankov
                        04.08.2017 12:15
                        #10343374

                        Не согласен. Если у вас есть ровно одно свободное ядро, на котором надо выполнить 1млн операций, то как их не диспетчерезируй, быстрее они этого не выполнятся.


                        И тут стоит отметить, что в случае с программой, которая создаст несколько реальных потоков – она будет получать больше процессорного времени для выполнения своих задач, чем однопоточная нода.

                        допустим OS будет диспетчеризировать 9 потоков + 1 поток вашей программы.

                        В случае с NodeJs, в системе будет всего 10 потоков. И тут, идем интуитивно, из 1 секунды, каждый поток будет выполняться по 100 мс (это не совсем так, потому что приоритеты и т.д.), т.е. NodeJs будет делать полезные действия всего 100 мс в каждой секунде.

                        В случае с приложением с реальными потоками: допустим у нас будет 20 потоков (9 потоков системы + 1 поток приложения + 10 потоков которые породило приложение).
                        В этом случае каждый поток будет выполняться по 50 мс в секунду, итого, наше приложение получает уже 550 мс процессорного времени в одну секунду.
                        И пусть из них дополнительно 20 мс уйдет на планирование (а это очень много!).

                        Итого, NodeJs будет выполнять полезные дейсвтия 100 мс, железные потоки — (550 — 20) мс.

                        Но в реальности это выглядит не так эпично, т.к. есть приоритеты потоков, а отбирая квант времени у других подсистем, они будут работать медленнее, что в общем скажется на работе всей системы. Так что в реальности «железные» потоки Будут все де выигрывать, но этот выигрыш будет примерно 150-300% (зависит от многих факторов).

                        Но NodeJs будет выигрывать на IO операциях, для которых не нужно использовать процессор, и то, если другая система не будет использовать все тот же asyncIO подход =)

                        https://habrahabr.ru/post/334760/?reply_to=10342966#comment_10342104
                        1 миллион сложений мой браузер сделал за 25мс. Если этот код разбить на два потока...

                        Есть закон Амдала, который позволяет расчитать примерный выигрыш от введения нескольких потоков.

                        Если кратко, то следствие: минимальное время выполнения задачи равно времени выполнения действий которые нельзя распаралелить. Потому, интуитивное «поделить на 2» – не будет работать. И это не говоря про то, что результат от запуска к запуску будет меняться, особенно в браузере, где «постороннего шума» невероятно много.


        1. franzose
          03.08.2017 23:36
          #10342558
          +2

          Мы в вузе не изучали многопоточность ни на одном из языков, которые у нас были: C++, C#, Delphi.


          1. pnovikov
            03.08.2017 23:53
            #10342580
            +2

            И я вам очень сочувствую.


            1. Iqorek
              04.08.2017 17:28
              #10344174

              Я тоже не помню, чтобы у нас упоминали многопоточное программирование, но вероятно потому, что тогда не было многоядерных процессоров и в мультипоточности не было особого смысла, все равно процессор то один.
              Мы уже привыкли, но многоядерные процессоры стали быть массовыми «всего» 10 лет назад.


              1. pnovikov
                04.08.2017 17:46
                #10344226
                +1

                А кто вам сказал про процессоры, молодой человек? Вытесняющая многозадачность появилась в unix вообще-то годах в 80х. А потом перекочевало в Windows 95 для UI. Равно как и ваше преславутое переключение контекстов. И сделано оно было для того, чтобы вы могли на одном камне сорта Pentium II слушать музыку в Winamp и смотреть интернет через netscape. Вы правда не читали об этом? Это потом уже человечество дошло до многоядерных процессоров и вопросов синхронизации кластеных вычислений. У вас блин операционная система многозадачна и многопоточна независимо от того, сколько у вас камней на матери. И как оно внутри работает — надо знать хотя бы в общих чертах, чтобы более-менее эффективно писать ПО под современные операционные системы. Поэтому это преподают в нормальных ВУЗах.


                1. Iqorek
                  04.08.2017 18:12
                  #10344288
                  +3

                  Многозадачность? Да, про многозадачность в частности и операционные системы, в целом, был отдельный курс. Но при чем здесь она.


          1. Free_ze
            04.08.2017 17:56
            #10344250
            +3

            Не ходите больше в такие вузы.


    1. Movimento5Litri
      03.08.2017 13:58
      #10341594
      -10

      Вы не совсем разобрались в теме, во первых если JavaScript был ужасен, то это было до es6 и выше

      Привет браузерам которые какакать хотели на всякие эти ваши новомодные es6 и заказчикам которым прям понос как надо чтобы работало на Internet Explorer 6.
      Бабель — костыль (на это даже название намекает) что впрочем не удивительно учитывая что жаваскрипт экосистема это костыль на костыле и костылём погоняющий.

      Во первых это круто, потому что многопоточный почти никто не умеет писать

      Делать евроремонт почти никто не умеет поэтому Равшан и Джамшут — крутые.

      Да но, npm работает очень просто и надежно.

      Ага, а потом кто-то обиделся и удалил 10 строчную «библиотеку» которая только и делала что делала что добавляла буковку в начало строки и все библиотеки и фреймворки перестали компилироваться, ахренеть как надёжно.
      Пакеты-вирусы это тоже показатель надёжности.


      1. staticlab
        03.08.2017 14:01
        #10341598
        +1

        Пакеты-вирусы это тоже показатель надёжности.

        Да, это очень неприятная проблема, а как с подобным борятся composer, maven, pip, nuget и прочие?


        1. Movimento5Litri
          03.08.2017 15:06
          #10341724
          -6

          а как с подобным борятся composer, maven, pip, nuget и прочие?

          Успешно.


          1. staticlab
            03.08.2017 15:17
            #10341738
            +6

            Чувствуется, что это троллинг, потому что вы не знаете наверняка.


            1. Movimento5Litri
              03.08.2017 19:22
              #10342188

              Нда…
              Для тех кто в танке:
              Абсолютно всё равно как с этим борются другие пакетные менеджеры.
              Абсолютно.
              Важно то что вирусов в них нет и трёхстрочных «библиотек» микрофреймворков тоже.


              1. bano-notit
                03.08.2017 22:26
                #10342476
                +2

                Вы в этом уверены? Вот прям на все 100%?


              1. franzose
                04.08.2017 01:16
                #10342650
                +1

                трёхстрочных «библиотек» микрофреймворков тоже.

                Просто потому, что эти языки чуть более многословны)


              1. VolCh
                05.08.2017 11:29
                #10345076

                Насчёт трехстрочных не говорил бы так уверенно про композер. Какой-нибудь полифилл вполне может уложиться в три строки.


      1. Zenitchik
        03.08.2017 14:03
        #10341600

        Привет браузерам которые какакать хотели на всякие эти ваши новомодные es6 и заказчикам которым прям понос как надо чтобы работало на Internet Explorer 6.

        От всей души сочувствую. Сам в таком же положении. Ничего, крутимся. Полифилы выручают во всех критичных случаях.


    1. Dimensi
      04.08.2017 09:06
      #10342924
      -1

      Просветите, что не так с this?
      this доступен только у функции, которая находится внутри объекта и все.
      А функции бывают с поздним связыванием и ранним. И все, что с ним не так?


      1. bano-notit
        04.08.2017 12:07
        #10343352
        +1

        Все жалуются, что если у простой функции не привязал его сразу через .call(), .bind() или .apply(), то она может ссылаться на window, А когда выносишь функцию из объекта, то она тоже теряет этот объект… Короче людям не нравится, что в каких-то местах this очевидно указывает на то, что им хочется, а в каких-то местах им нужно очевидно самим указать, на что this по их мнению должен указывать. В общем это просто не знание как работает this, не более.


  1. IonianWind
    02.08.2017 23:25
    #10340516
    +6

    однопоточный рантайм ( в 2017 году!!! )

    ServiceWorker в браузере, cluster на сервере


    отсутствие единой системы / стандартов реализации модулей ( опять же, 2017 год на дворе )

    ES6-модули в браузере, CommonJs на сервере. Ну или babel везде


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

    ну, это уже человеческий фактор


    слабые типы с неявными ( и порой довольно странными ) преобразованиями
    этот чудесный контекст this ( что это значит this в этом месте кода — объект? функция? )
    const ( который на самом деле НЕ const )

    RTFM


    отсутствие нормальных классов / ООП

    что значит "нормальные"? мне лично, например, и так норм :3


    отсутствие единого вменяемого и работающего статического анализатора кода ( добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function )

    Ну, тут самодисциплина помогает. Но да, не хватает.


    абсолютно дурацкая реализация pattern matching ( паттерн матчишь пустой список / объект — без проблем, извлекаешь оттуда undefined, ты же именно это имел ввиду, да? ) и здесь опять привет cannot read property foo of undefined

    а вот тут мне лично не очень понятно, что хотел сказать автор


    отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async ( если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку )

    Bluebird Promise.promisify в браузере, util.promisify на сервере, и коллбэки становятся промисами. Async/await — фактически те же промисы, только "подсахаренные". А фьючерсы — на фондовой бирже)


    Самодисциплина по отношению к своему коду вполне нивелирует большинство пунктов.
    И да, жизнь — боль ;)


  1. le1ic
    02.08.2017 23:46
    #10340544
    +6

    однопоточный рантайм ( в 2017 году!!! )

    это самое крутое что отличает nodejs. С введением async/await наконец это вообще стало просто сказкой.
    Многопоточность нужна только для CPU-intensive задач, которые вряд ли имеет смысл делать на JS, но если очень хочется, то можно использовать многопроцессность.

    отсутствие единых стандартов структуры проекта
    а джава что, регламентирует структуру проекта? По мне так мягкие договоренности лучше жестких навязываний

    абсолютно безумный npm
    что в нем безумного? Наоборот очень простая и круто работающая система без проблем с разруливанием несовместимых зависимостей.

    Про размер
    5Мб для простого SPA
    по факту докер имидж nodejs приложения может занимать 10-20 МБ, в то время как любого другого сотни МБ (джава со всеми зависимостями например)

    Самый существенный косяк JS — это отсутствие целочисленных типов. И это конечно жестко.
    Опциональная типизация тоже была бы nice-to-have, но для тех, кому критично есть TS.

    Все остальное это какое-то непрофессиональное нытье


    1. KoCMoHaBT61
      03.08.2017 07:41
      #10340776
      +6

      Им не просто ООП надо. Им нужен такой ООП, чтобы ответ на вопрос на собеседовании: «Назовите три принципа ООП» «Это полиморфизм, наследование и инкапсуляция» — был правильным.


      1. copist
        04.08.2017 15:17
        #10343826

        Зато у знатоков на такой вопрос всегда есть встречный: «мы говорим про С++/Java, JavaScript или Common Lisp?
        (Чьё ООП круче?)


        1. KoCMoHaBT61
          04.08.2017 15:55
          #10343934

          … и знатоки не проходят собеседование. :)


          1. copist
            04.08.2017 15:56
            #10343940

            Многие знания многие печали


    1. copist
      04.08.2017 15:10
      #10343806

      5Мб для простого SPA — это серверная или клиентская сторона?

      Серверная — вообще кайф. 5Мб кода вместе с библиотеками — это очень даже компактно. Не смотри в node_modules и в статику и всё OK.

      Клиентская — это поклёп. Современный JS может очень компактно сжиматься, даже если сложный. Ещё умеет подгружаться по мере необходимости. 5Мб для фронта возможно только с учётом стилей и картинок, но это в JS уже не относится.


      1. bano-notit
        04.08.2017 21:21
        #10344578

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


  1. apocarteres
    02.08.2017 23:55
    #10340560

    ccc


  1. k12th
    03.08.2017 00:50
    #10340626
    +6

    Все гораздо проще. Миром правит информация. Информация должна доходить до потребителя. Так как ее много, то чтобы ее донести, нужен софт. По факту оказалось, что веб — самый удобный способ доставки софта.


    Никакого глобального заговора корпораций нет. Сидите спокойно в своем OTP.


  1. bano-notit
    03.08.2017 01:56
    #10340674
    +9

    There are only two kinds of languages: the ones people complain about and the ones nobody uses.


  1. rumkin
    03.08.2017 03:27
    #10340700

    Да, вы не нервничайте так, скоро WebAssembly появится в продакшене, сможете писать хоть на брейнфаке. И бек, и фронт. Правда все равно запускать будете из JS)))


    1. kekekeks
      03.08.2017 09:43
      #10340940
      +2

      В вебассемблю до сих пор потоки не завезли. И возможность использования языков с GC (ну или возможность прикрутить свой GC). Когда будет — не известно. Но они работают над этим™.


      1. rumkin
        03.08.2017 12:13
        #10341346
        +3

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


  1. Lofer
    03.08.2017 03:39
    #10340704
    -4

    Судя по направлению развития JS начинает быть похожим на другие решения.
    А если смотреть в сторону WebAssembly, то похоже JS многих «достал», и наконец решили сделать нормальное решение.


  1. DeLuxis
    03.08.2017 07:15
    #10340766
    -3

    Порог вхождения очень низок. Каждый второй сайт в интернете тормозит из-за кривого js.
    Вся надежда на WebAssembly, как только сделают API для DOM.


    1. staticlab
      03.08.2017 08:24
      #10340814
      +2

      Вся надежда на WebAssembly, как только сделают API для DOM.

      Как только сделают API для DOM, начнётся вой, что этим API пользоваться неудобно. Затем может быть даже придумают аналоги jQuery. Но дело в том, что DOM сам по себе весьма тормозной, и на каждом из языков придётся делать какие-либо view-библиотеки на основе Virtual DOM или чего-либо подобного. Скорее всего, и фреймворки какие-то придумают.


      Опять же, другим языкам скорее всего придётся тянуть за собой многомегабайтные рантаймы. Особенно критично это будет, если разработчики решат использовать для интерфейса не DOM, а Canvas или WebGL. В таком случае появится ещё зависимость на GUI-библиотеку.


    1. i360u
      03.08.2017 09:46
      #10340946
      +3

      Тормозит cам DOM, и он будет также тормозить с API из WA. Если разработчик умеет оптимизировать работу с DOM — ничего не будет тормозить и на JS. WebAssembly — он какбе для другого и кардинально ускорить свое приложение вы сможете разве что написав свой альтернативный сильно упрощеный DOM с рендером, к примеру, в WebGL.


  1. screen_sailor
    03.08.2017 07:51
    #10340782
    -2

    JS: фрактал плохого дизайна.


  1. nuald
    03.08.2017 08:21
    #10340812
    +4

    Позвольте мне рассказать, как так получается, что для backend-а используются неподходящие технологии — так уж получилось, что я сам был виновником такого, и теперь из-за моего решения страдают другие разработчики (впрочем, они бы страдали и так и так, и я, наверное, все-таки смягчил ситуацию). Чтобы не быть голословным, я говорю про UTM-устройства FortiGate и про использующийся там Python в backend-е (сисадмины наверное знакомы с этими устройствами, хотя в России они вряд ли сильно распространены).

    Все началось, когда другая команда, работающая над FortiController (менеджер этих железок) внедрили там PHP для UI. Им было это сделать очень просто, т.к. они использовали современный Linux, и им просто надо было написать пару расширений для PHP, чтобы он нормально заработал. Наш CTO загорелся идеей скриптования в backend-е и начал это активно продвигать (его понять можно — до этого была возможность только рекомпиляции и обновления прошивки даже для малозначительных изменений). Нас поставили перед фактом — внедряйте PHP в FortiGate, и чтобы это было готово уже вчера (ибо конкуренты не дремлют).

    Я был очень сильно против, и после длительных дискуссий с угрозами увольнения мне сказали — предложи что-нибудь работающее и лучше, тогда подумаем. И мне дали всего 2 недели. Для контекста: FortiGate — это весьма кастомный Linux со своим ядром, файловой системой и никакими менеджерами пакетов. По сути, основное ПО на железке — это один исполняемый файл, в котором несколько точек входа (соответственно, ls и rm отличаются только точкой входа в этом файле). Как бы я не хотел внедрить что-нибудь достойное типа того же go-lang, я просто не мог заставить его работать в отведенное мне время. Другое условие — чтобы мы могли найти разработчиков. В итоге мне пришлось выбирать между JS, Python и PHP (я потом часть работы оформил в небольшую статью). К счастью, в то время V8 имел какие-то проблемы с нашим ядром (какие-то ioctl запросы не работали), поэтому несмотря на то, что мой непосредственный начальник хотел выбрать JS, я смог уговорить его использовать Python.

    Я, конечно, упускаю много деталей, но выводы я сделал: выбор технологий иногда определяется не самой технологией (ее плюсами и минусами), а ограничениями (например, время внедрения) и кадрами. И к сожалению, кадры на западе — это весьма плачевное зрелище. Рынок наводнен выходцами из Китая и Индии, любовь к профессии заменена на жажду легких денег, клановое мышление заставляет их покрывать друг друга и просто отторгать всех талантливых и самостоятельно думающих разработчиков в сторону. От этого и уровень — найти JS-разработчика намного проще (даже найти нормального Python-разработчика было проблемой).

    P. S. Хотел бы отметить, что я как раз недавно плотно работал с сотрудником Facebook-а, который пишет на OCaml — на нем разрабатывается Infer. Полное покрытие тестами у них не всегда есть, иногда они полагаются только на интеграционные тесты. Так что не стоить думать, что у гигантов софтоиндустрии все прекрасно, там тоже есть немало проблем.


  1. flancer
    03.08.2017 08:29
    #10340824
    +14

    Язык для разработчиков должен быть простым и распростаненным. Язык для "элитных программистов" может быть любым. Но желательно "с высоким порогом входа" — чтобы отсекались "всякие недоумки"."Elixir / Erlang / Lisp / Haskell / любой другой язык с хорошим дизайном" — кодовые слова, по которым "элитные программисты" находят друг друга.


    Я свои первые web-приложения писал на LotusScript. На Lotus, мать его, Script! И не ныл, что тип скобочек меня не устраивает. Потому что препод в универе донес до меня простую мысль — программировать можно на любом языке, который понимает компьютер. Хоть в машкодах, хоть брейнфаком.


    Дружище Strain, JavaScript популярен прежде всего потому, что браузеры другого языка не понимают. Все. Были попытки встроить в браузеры и ActiveX, и JavaApplets, и Dart. Но единственный язык, который понимает большинство браузеров — это JS. Нет никакого заговора мирового капитала против горячо любимых вами "языков с хорошим дизайном". За 300% прибыли капитал идет на любое преступление, а использовать уродливый с арихтектурной точки зрения язык в бизнесе он начинает с 0.01% прибыли. Как только тот же Erlang сможет перебить хотя бы на ту же самую сотую процента прибыль, приносимую JS'ом — бабло рекой потечет в Erlang.


    А пока что не Haskell пролазит на фронт, а JS осваивает бэк. Как тут советовали коллеги чуть выше — "сидите спокойно в своем OTP". Читайте обнадеживающие новости про Ocaml. Берегите свое психическое здоровье. А зарабатывание денег оставьте девелоперам — людям с крепкой психикой и редуцированным чувством прекрасного.


    1. Neikist
      03.08.2017 09:05
      #10340862
      -2

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

      Это все хорошо, но вот что я вижу в ваших словах: бабло, бабло, на чем угодно бабло… А как же удовольствие? Интерес? Ведь в программирование за этим идут в первую очередь? (не мне жаловаться, я вообще с 1с извращаюсь, впрочем коллегам мое нытье об отсутствии хоть какого ООП, статической типизации, анонимных и функций первого класса тоже надоело)))


      1. flancer
        03.08.2017 09:40
        #10340934
        +9

        Мы видим то, что хотим видеть. Программировать за интерес и удовольствие можно — github предоставляет поддержку таким начинаниям. Но за окном капитализм — вы ведь не за интерес с 1С извращаетесь, не так ли? В сутках 24 часа, 11 — на добычу денег (с обедом и дорогой), 6-7 на сон, остается еще 6-7 часов. Вот и получайте удовольствие — в свое свободное время. А если хотите и удовольствие получать от работы, и деньги — научитесь получать удовольствие от программирования на Java/C/C++/C#/Python/VisualBasic/PHP/JS/Perl/Ruby/...


        Программировать машины — это работа, а не искусство. Поэтому не нужно тут сопли размазывать, что молоток у тебя не с той ручкой. Бери что есть и забивай гвозди. Не любишь гвозди — бери пилу и пили. Не нравится инструмент — сделай свой. Это я про автора статьи, если что. Уж извините за выброс эмоций.


        А по поводу 1С — меняйте работу. Возьмите любой язык из популярных, который нравится чуть больше остальных, и развивайте свои навыки на нем. Всегда побеждает тот волк, которого ты кормишь.


        Все языки несовершенны по-своему. Чтобы понять, в чем именно, нужно просто достаточно долго попрограммировать на этом языке.


        1. irbis_al
          03.08.2017 09:47
          #10340950
          -3

          А вот Вы знаете не согласен… что программирование это работа, а не исскуство…
          Есть выражение, работай так, как будто тебе не нужны деньги.
          И Кто в моей конторе(я сам предприниматель) так работает… у того качественней код(и кстати те и больше всех получают и теми кадрами я поистине дорожу)… а те кто за бабули… типа выполнил ТЗ и там трава не расти… и сразу давай мне оплату… я ж тут не зря (-|-) рвал… у тех и код приходится переделывать и всегда им подсознательно подыскиваю замену.


          1. flancer
            03.08.2017 10:04
            #10340990
            +7

            Если бы программирование было искусством, то за шедевры платили бы миллионы, а все остальное — просто выкидывали в мусор. Но это не так.


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


            1. wladyspb
              03.08.2017 12:04
              #10341320
              -4

              Я бы всё же скорректировал сравнение — манки-кодинг настолько же искусство, насколько искусство — профессия строителя. А программирование как искусство — сравнимо с работой архитектора, и места для творчества обычно хватает.


      1. copist
        04.08.2017 15:25
        #10343846

        А как же удовольствие?

        Программирую на нескольких языках с одинаковым удовольствием. И как-то норм всё с баблом.
        Язык — это только инструмент. Важнее то, что на нём делается. Предмет важнее инструмента.


    1. ValdikSS
      03.08.2017 10:33
      #10341072

      Причем здесь браузер? Речь же про бекенд.


      1. flancer
        03.08.2017 12:10
        #10341338
        +4

        Согласен, не всем очевидно. JS пролазит на backend, потому что на фронте для него нет альтернатив. У меня был опыт создания фронта на GWT (Java) — пример проникновения бэкенда на фронт, и опыт создания бэкенда на nodejs (обратный пример). Дебажить в браузере GWT-шный код, да даже просто смотреть на результат преобразования java2js — то еще удовольствие.


        Многие web-программеры мечтают использовать одни и те же либы на фронте и на бэке (бизнес-логика-то похожая). JS единственный дает им такую возможность native'но. Остальные — через JS (за java applet'ы ничего не говорю, ибо не взлетело).


        1. pnovikov
          03.08.2017 12:15
          #10341354
          +3

          Вставлю 5 копеек: бизнес-логика-то похожая, но на черт побери не та же самая! Реально общего между бэком и фронтом по коду — это модели, которые туда-сюда пересылаются. Ну может еще кусочек валидации. В остальном — бэк прибит гвоздями к контексту источника данных, а у фронта такой радости нет. Как следствие — обязанности и код довольно сильно разделен и имеет не так много общего, как кажется.

          Единственный аспект, в котором изоморфный подход себя оправдывает — это шаблонизация. Круто когда на сервере и на клиенте можешь срендерить одинаковый HTML не дублируя кода. Реально, без шуток круто. Но выворачивать это обстоятельство чуть ли не в отдельную идеологию — попахивает распилом проектных бюджетов :)


          1. staticlab
            03.08.2017 12:22
            #10341370
            +2

            На самом деле в серьёзных проектах ради изоморфизма нет смысла полностью всю бэкенд-логику писать на JS. Достаточно непосредственно самого рендеринга и валидации. А весь API писать в отдельном приложении на любом другом языке.


          1. copist
            04.08.2017 15:31
            #10343858

            Вы не представляете, какими бюджетами надо обладать, чтобы скормить гуглоботу, бингу и яндексу фронт в 2М уникальных HTML страниц, написанный на неизоморфном JS в виде SPA. Кровь, пот, слёзы, маты и периодическое выпадание из поискового индекса. Никому не посоветую теперь делать публичное SPA на неизоморфном JS. Лучше забыть про PHP/Python/Ruby и прочее если фронт будет в виде SPA и открыт для индексации поисковиками.


    1. 0xd34df00d
      04.08.2017 19:35
      #10344428

      Спасибо за совет, конечно, но как-то неплохо получается совмещать приятное с полезным, и зарабатывать деньги на приятных языках.


  1. Sna1L
    03.08.2017 08:42
    #10340840
    +5

    Не люблю JS, но не могу не признать, что сам язык становится все лучше и лучше.
    Сейчас нелегкая судьба заставила работать с реактом (сам я рельсовик), так я был приятно удивлен новыми фишками языка. Даже элементарная стрелочная нотация — это уже огромный шаг в сторону удобства и красоты.
    Правда, вводит в заблуждение то, что это не сахар над function()(this по-другому работает), но это разовая проблема, имхо (даже если ты не читал документацию, то достаточно быстро поймешь, что что-то не так).


    Относительно магии this и отсутствия классов — это просто непонимание парадигмы языка, как по мне. В хаскелле вот тоже нет ооп-классов (AFAIK). И знаете, почему это не является проблемой (как мне кажется)?
    Потому что ни у кого не возникает желания писать на нем в ООП-стиле. А вот джаваскрипт все пытаются натянуть на джаву/руби/другое-класс-ооп.
    Достаточно разобраться в фундаментальных для языка вещах и непонятки по поводу this и прочего пропадут. Мне вот не нравится синтаксические новшества, связанные с классовым ООП. Готов поспорить, они появились как раз из-за того, что люди не хотят понять язык, а хотят писать на чем угодно одинаково (наводит на мысль о Scala-программистах, которые пишут на ней, как на Java).


    В общем, это не баг, а фича.


    Простите за сумбур, просто хотелось высказаться. Меня тоже волнует (беспокоит?) растущая популярность JS


    1. 0xd34df00d
      04.08.2017 19:39
      #10344440

      В хаскелле вот тоже нет ооп-классов (AFAIK). И знаете, почему это не является проблемой (как мне кажется)? Потому что ни у кого не возникает желания писать на нем в ООП-стиле.

      Следующий естественный вопрос — почему такого желания не возникает. Рискну предположить, что потому, что там есть более удобные и мощные инструменты.

      А для ООП-стиля (ну, с объектами и методами) в хаскеле, кстати, есть линзы.


  1. blazer
    03.08.2017 10:04
    #10340988
    -2

    Последних 5 лет работал с Ruby и Ruby On Rails, последние 3 месяца осваиваю Meteor JS и делаю новый проект на нам. Я искренне люблю руби и рельсы, но в 2017 году глупо не видеть того, что 90% разработки перешло во фронтэнд, а там кроме JS вариантов просто никаких нет. А если писать все на одном языке – то уже и разделение на бэк и фронт отпадает само собой, как и куча костылей для поддержки двух языков на одной платформе. Да, JS не так изящен, как Руби, но ES6 это большой шаг вперед, и он не последний. А то что Javascript существовал в таком виде лет 20 и не менялся, как раз таки говорит о том, что язык этот отнюдь не дерьмовый. MVC архитектура в современных условиях веб-разработки уже не актуальна. Вообщем, я долго ломался, переходить или нет, но когда узнал, что в ES6 больше не нужно ставить ";" в конце строк, мои колебания закончились)) Перешел окончательно, чему весьма рад. Rails впрочем может использоваться в проектах, которые не требуют фронтэнда.


    1. vintage
      03.08.2017 10:26
      #10341058
      +8

      MVC архитектура в современных условиях веб-разработки уже не актуальна.

      Тот-то все сейчас молятся на Redux, который является реализаций FLUX, которая является частным случаем MVC.


      Вообщем, я долго ломался, переходить или нет, но когда узнал, что в ES6 больше не нужно ставить ";" в конце строк, мои колебания закончились))

      Она всегда была опциональной.


  1. bormental
    03.08.2017 11:12
    #10341162
    +1

    Я понимаю, что жанр такой данной статьи — эпатаж с холиворностью. Но с КДПВ стоит брать аккуратнее. Многие новости за завтраком любят читать...


    1. bormental
      03.08.2017 11:13
      #10341168

      s/брать/быть/


  1. pnovikov
    03.08.2017 11:14
    #10341172
    +16

    А я вот согласен с автором. Блин, ребята, вся история программирования — это история о строгой типизации. О борьбе человека против никак не регламентированных кусков памяти в попытках обуздать эту стихию и сделать её хоть сколько-нибудь структурированной.

    И тут мне в личку приходят обезумевшие JS-фанаты и заявляют что «строгая типизация — говно, все скоро от неё откажутся и будут писать на нетипизируемых языках», после чего вываливают еще тонны личных оскорблений как на меня, так и на мой любимый C#.

    Далее. Хочу дополнить автора тем фактом, что судя по разброду в JS-технологиях и отсутствию одного стандартного решения хоть в каком-либо аспекте (возьмите хотя бы 5 популярнейших пакетных менедж… стойте, пока я писал этот пост — сделали шестой) — проектированием фреймворков на JS заняты люди без опыта проектирования и умения договариваться. Нуу… ладно, положим какой-то опыт проектирования у некоторых людей из JS-коммьюнити все же есть, но все эти спецы работают на крупные корпорации и делают штуки навроде React-а (надеюсь, у них-то нет времени кричать что строгая типизация скоро вымрет). С ними наверняка конкурирует еще кто-то. Все остальное развивается мягко говоря, хаотично. И это тот случай, когда рыночная «здоровая конкуренция» как раз-таки не приводит к выбору оптимального решения, а скорее засоряет эфир кучей разнокалиберных поделок неизвестной степени пригодности к использованию. Почему? Ответ прост — хайп.

    И вообще, слово этого года — «хайп». Очень, очень понравилось выражение автора «хайп дривен девелопмент». Корпорации вкладывают миллионы долларов в пиар, конференции с печеньками, трансляции и книги, блогеры пишут пресс-релизы — и все это вместо того чтобы просто дать попользоваться технологией всем тем, кто желает ей попользоваться и уже на месте решить хороша она или плоха, какие задачи она решает хорошо, а какие плохо. Но нет, вместо естественного процесса смерти неэффективных решений мы имеем толпы хомячков, которые услышали про React/Angular/nodejs/ватевер и бездумно на него молятся, без разбору поливая шоколадного колера субстанцией всех, кто посмеет им возразить и указать на недостатки. Вот примерно таким макаром JS-фанаты мне давеча заявили, что «писать в многопоточных средах в 2017 — это **ня полная».

    В общем, что хочу сказать. Читающий, должно быть, уже заметил что сама технология тут ни при чем. JS — нормальный язык для своих задач, с некоторыми… скажем так, архитектурными особенностями. И эта тема стала бы максимум — местом в документации, с которым ознакамливается всякий, кто начнет разрабатывать на JS. Но тут пришли люди, которые сказали, что архитектурные особености JS — это не баг, а фича, а все кто не согласен — должны идти лесом. Чуете о чем я? Проблема не в технологии, а в людях и сообществе вокруг этой технологии (ИМХО именно на этом в статье надо было сделать акцент). Я еще никогда не встречал более слепо верующего и агрессивного сообщества чем JS-разработчики. Я еще никогда не встречал более агрессивно продвигаемых технологий чем JS-стек.

    Очень надеюсь, что скоро это все закончится.


    1. pnovikov
      03.08.2017 12:03
      #10341314
      +8

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

      Все в курсе, что у JS низкий порог вхождения. Начать писать просто, никакого инструментария не нужно (блокнот да браузер). Базовый синтаксис прост до безобразия. И вот мальчик пубертатного возраста берет в руки этот набор инструментов, делает какую-нибудь пакость за пару дней. А дальше? А дальше предается упоенному самопиару — пишет про это статьи, записывает видео, публикует в npm, вероятно даже выступает на конференциях. В общем получает удовольствие от процесса, удовлетворяя свое эго, а не занимаясь, черт побери, развитием технологий. Нет, ну а что? Представьте что вам 20, вы занимаетесь поддержкой сайта какого-нибудь интернет-магазина ООО «Рога и Копыта», на плюсах не писали, в базы данных умеете на уровне phpMyAdmin, не знаете структур данных и алгоритмов. И тут у вас появляется возможность сделать не хвост собачий, а ажно целый opensource-проект, о котором всем можно рассказывать и с которым вас будут воспринимать всерьез. Красота! Вы когда-нибудь пробовали указать пубертатному подростку на то, что он занимается какой-то фигнёй? Если нет — то я вам сразу скажу что в ответ вас обольют весьма утонченными и изысканными оскорблениями. Поразительно похоже на реакцию JS-адептов на критику. :) Кстати, как не трудно догадаться, заканчивается это пиршество духа какой-нибудь забавной историей с left-pad.

      Предположу, что в крупных конторах происходит примерно то же самое. Группа программистов пишет какой-нибудь фреймворк для решения какой-нибудь внутрикомпанейской задачи. При том делает это чуть ли не из интереса (все же должны получать удовольствие от работы, так? Ох уж этот либеральный подход к менеджменту!) или из имитации бурной деятельности. А потом начальству надо отчитаться куда ушли деньги и как это все поможет бизнесу заработать. В такие моменты рождается байка про «да мы же тут сделали инструмент, который превосходит аналоги!», «изобрели штуку, которая сделает мир лучше», «открыли новый подход к проектированию/рендерингу/модулям/чемуугодно». И вот уже становится как-то неловко говорить, что отдел потратил время впустую, разработчики сделали нерелевантную штуковину, которая интересна только им и вообще сожгли бюджет. Начинаются поездки по конференциям. Чем это заканчивается все итак понимают.

      Ну и кулстори на десерт: я был лично знаком с человеком, который сделал небольшой фреймворк для изоморфных приложений за несколько месяцев (в рабочее время, сидя на зарплате!) и потом несколько лет занимался тем, что за деньги компании катался по конференциям, рассказывая про свое творение — и заодно про то, как хорошо работать в этой компании. А на его фреймворке, тем временем, было сделано ровно 2 работающих сайта. В итоге: фреймворк всеми забыт, компанию все итак хорошо знают, человек уволился и работает сейчас где-то в США. Только потом мне поведали что это называется «технопиар» и задумка была не сделать хороший инструмент, а разрекламировать компанию как идеальное место работы.

      Такие вот дела.


      1. bano-notit
        03.08.2017 13:40
        #10341556
        +3

        Кэтбери?


        1. pnovikov
          03.08.2017 15:37
          #10341784
          +2

          Вы же понимаете что по этическим причинам я не разглашаю ни компанию ни человека. ;)


          1. pnovikov
            03.08.2017 15:47
            #10341804
            +2

            Однако, я не могу вам помешать сделать это за меня.


  1. timon_aeg
    03.08.2017 11:43
    #10341258
    -3

    отсутствие вывода типов в самом языке или в каком-либо инструменте

    Вычеркивайте.

    class RequestMappingInfoHandlerMethodMappingNamingStrategy {};
const requestMappingInfoHandlerMethodMappingNamingStrategyInstance = new RequestMappingInfoHandlerMethodMappingNamingStrategy();
console.dir(requestMappingInfoHandlerMethodMappingNamingStrategyInstance); // RequestMappingInfoHandlerMethodMappingNamingStrategy {}


    1. staticlab
      03.08.2017 13:52
      #10341578
      +2

      Под выводом типов подразумевается вот это: https://ru.wikipedia.org/wiki/Вывод_типов


  1. usr753
    03.08.2017 12:13
    #10341344

    однопоточный рантайм ( в 2017 году!!! )

    А как же таймеры, воркеры, и его асинхронные события? Воркеры – это отдельные потоки с изолированным контекстом. Написал даже библиотеку для удобной работы с ними: https://github.com/artnv/clientThreads

    отсутствие единой системы / стандартов реализации модулей ( опять же, 2017 год на дворе )

    Вычитал (не помню в какой книжке), что паттерн Модуль еще с начала 2000х использовали в JS. Это самовыполняющиеся функция которая возвращает объект с методами из замыкания. Де-факто стандарт.

    отсутствие единых стандартов структуры проекта ( все творят как хотят, в исходниках бывает очень сложно разобраться )

    Стандарты есть, паттерны те же самые, mvc, стили различных фреймворков.

    отсутствие нормальных классов / ООП

    JS – прототип-ориентированный язык, а это модель ООП. В ПП понятие класса вообще отсутствует, при этом ПП намного гибкий чем классический подход. В объектах вся мощь JS, с помощью них создается структура приложения, неймспейсы, хранятся и передаются данные как между методами так и по сети, с помощью json

    отсутствие единого вменяемого и работающего статического анализатора кода ( добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function )

    Это скорее мир асинхронности. Нужно понимать как браузер производит загрузку кода, в какой последовательности и когда начинает выполнять. В JS, код может генерироваться, подгружаться и подключаться динамически, в разное время. Достаточно контролировать последовательность и следить за событиями.

    отсутствие вывода типов в самом языке или в каком-либо инструменте

    console.log(typeof 123)    // number
console.log(typeof '123')  // string


    этот чудесный контекст this ( что это значит this в этом месте кода — объект? функция? )

    this — это объект. this ссылается на внутренний контекст Конструктора (предоставляет доступ к внутренним свойствам) при создании через new, в случае отсутствия new будет ссылаться на глобальный контекст window. По сути, при создании через new возвращается объект this и все его свойства thix.x, this.y и т.д. Аналогично было бы вернуть объект с помощью return {x:1,y:2} в обычной функции. Если пугают конструкторы, this/new, можно использовать литералы объектов

    отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async ( если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку )

    В JS все же на событиях из-за той же асинхронности. Можно самим написать или взять готовое решение пользовательских событий по паттерну Наблюдатель/Observer, это EventManager/EventEmitter/PubSub.

    Например: данные пришли с помощью ajax, публикуется событие 
    eventManager.trigger('incomingData')
    и все подписчики которые подписаны на него, запускаются циклом. 
    eventManager.on('incomingData', function(json) {...})


    У многих есть ошибочное суждение что в JS всё легко, низкий порог вхождения и т.д. Может быть и так, в небольших приложениях, где нужно использовать пару методов JQuery, а взявшись за разработку чуть более сложного, разработчик сталкивается со своим ложным представлениям о нём. Код нужно как-то организовывать, чтобы через пару дней понять где, что работает. Придется достаточно глубоко изучить сам язык, чтобы использовать больше его возможностей, с ростом задач. Изучить API Браузера и его работу. Научится работать с асинхронностью. А уже после всего этого приниматься за библиотеки, фреймворки, а не на оборот. Впрочем зная язык можно свои велосипеды написать)


    1. mayorovp
      03.08.2017 12:56
      #10341456

      отсутствие единых стандартов структуры проекта ( все творят как хотят, в исходниках бывает очень сложно разобраться )

      В том-то и проблема, что с начала 2000х все пилят свои велосипеды.


  1. RubaXa
    03.08.2017 12:28
    #10341382

    Как однажды сказал Бьёрн Страуструп: «Существует два типа языков программирования — те, на которые все жалуются, и те, которыми никто не пользуется».


    1. dklein
      03.08.2017 16:51
      #10341934

      Выше его уже цитировали :)


      1. RubaXa
        03.08.2017 16:55
        #10341940

        Из этой же серии нравится интервью с Расмусом Лердорфом


        «Колбаса, политика и PHP: если хотите наслаждаться ими — не смотрите, как они делаются»

        PHP — просто инструмент, с помощью которого можно сколотить классные штуки. И мне нравится именно это — то, что создано с помощью PHP.


  1. Lofer
    03.08.2017 12:31
    #10341394

    отсутствие нормальных классов / ООП

    JS – прототип-ориентированный язык, а это модель ООП.

    Тут выбешивает несколько иное. Функция, которая не «функция», объект который не «объект» и нету четких границ где что находится. Я хочу получить нормальный «контейнер» в котором будут изолированы функции, я хочу безопастное контролируемое мной хранилище данных, и я не хочу, что бы Тот Парень как-то повлиял на мой код или данные.
    Вроде много лет назад именно для этих целей и сделали классы и пространства имен.
    Как это все назвать? И в JS и как решить эти проблемы, если классы это «плохо»?
    Почему Вы полагаете, что Прототип-ориентированный язык это препятсвие для решения этих проблем?


    1. usr753
      03.08.2017 13:28
      #10341532

      Тут выбешивает несколько иное. Функция, которая не «функция»

      Да, функция это объект), например она может содержать статическое свойство
      x = function() {
    console.log(x.static);
};
x.static = 123
x(); // 123


      и нету четких границ где что находится

      JS как пластилин. По началу тоже непревычно было. А хорошо это или плохо ответ у каждого свой.

      Я хочу получить нормальный «контейнер» в котором будут изолированы функции, я хочу безопастное контролируемое мной хранилище данных, и я не хочу, что бы Тот Парень как-то повлиял на мой код или данные.

      Паттерн Модуль + Фасад. Данные и код хранятся в замыкании, без возможности доступа извне, кроме определенных методов или свойств. Та же инкапсуляция по сути. А если к этому добавить Медиатор(контроллер), который координирует работу модулей + Наблюдатель, который служит для асинхроного общения, то уже получается структура полноценного приложения.
      x = (function() {
    
    var
        red     = 200,
        blue    = 300,
        green,
        
        getTotal , setGreen;
    
    getTotal = function() {
        console.log(red + blue + green);
    };    
    
    setGreen = function(arg) {
        green = arg;
    };
    
    return {
        // public methods
        getTotal    :   getTotal,
        setGreen    :   setGreen
    }
    
}());

x.setGreen(400);
x.getTotal(); // 900


      Вроде много лет назад именно для этих целей и сделали классы и пространства имен.

      Пример неймспейсов
      app = {
    model       : {},
    view        : {},
    controller  : function() {}
};

app.model.net = function() {};
app.model.admin = function() {};
app.model.user = function() {};

app.view.admin = function() {};  
app.view.user = function() {};


      если классы это «плохо»?

      Классы это хорошо, но в JS их нет, в место них объекты, другой вообще подход


      1. Lofer
        03.08.2017 14:37
        #10341664
        -1

        Да, функция это объект), например она может содержать статическое свойство

        Объект чего?
        Если это некоторый контейнер времени исполнения который можно создать в любое время и присоединить к нему как код так и данные, ну так давайте его и назовем, к примеру, RuntimeContainer.
        Если это некоторый выделенный кусок кода со свои функционалом — давайте назовем его, к примеру, function.
        А так мутант какой-то :)
        Пример неймспейсов

        Не очень удачный пример, поскольку пространстов имен это логический контейнер. Грубо говоря это синтаксис, а не исполнение/runtime. А то, что приведено это скорее вложенные классы с эмуляцией «полного имени»
        Паттерн Модуль + Фасад. Данные и код хранятся в замыкании, без возможности доступа извне, кроме определенных методов или свойств. Та же инкапсуляция по сути

        Вот! Приходится использовать кучу дополнительных примочек и костылей, что бы решить типовую задачу разработки. Т.е нужно вкладывать усилия не в решение бизнес задач клиента, а в решение типовых «нюансов» инструмента.
        Если бы это были новые не известные проблемы можно было бы понять. Но это же типовые и давно известные.
        Классы это хорошо, но в JS их нет, в место них объекты, другой вообще подход

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


    1. staticlab
      03.08.2017 13:36
      #10341546
      +1

      Функция, которая не «функция», объект который не «объект» и нету четких границ где что находится.

      Что вы имеете в виду?


      я хочу безопастное контролируемое мной хранилище данных, и я не хочу, что бы Тот Парень как-то повлиял на мой код или данные.

      Сейчас можно инкапсулировать данные в замыкании, в том числе недоступными извне будут неэкспортированные переменные модуля. Можно использовать символы. В будущем вообще ожидается https://github.com/littledan/proposal-private-methods


      Вроде много лет назад именно для этих целей и сделали классы и пространства имен.

      Классы, кажется, в первую очередь решают проблему присоединения методов к данным соответствующего типа.


  1. kozyabka
    03.08.2017 12:35
    #10341408
    +1


  1. darksimpson
    03.08.2017 14:26
    #10341650
    -3

    Рискую быть заминусованным праведным (и не очень) гневом всех двух сообществ, но выглядит все это так, как будто JS это вот такая вот Ардуина, только от удивительного мира программирования.


    1. altai2013
      03.08.2017 16:02
      #10341848
      +4

      Не понимаю, откуда берётся вот это убеждение, что у Javascript «низкий порог вхождения»? Низкий в сравнении с чем? У C#, к примеру, одна разновидность синтаксиса, одна интегрированная среда разработки, один популярный фреймворк, один источник документации. Начинающему хватит одной книжки, чтобы изучить и начать работать. Javascript настолько широк, что попытка вхождения в него просто шокирует объемом и запутанностью информации.


      1. pnovikov
        03.08.2017 16:06
        #10341864
        +2

        На самом деле IDE у C# конечно же 3: VS, Mono Develop, Rider. А еще C# есть в Unity и для мобильного Xamarin-а. Синтаксис не отличается, но может отличаться рантайм. А еще есть .NET Core, который немного отдельная песня. И Portable, и с недавних пор .NETStandard. И популярных фреймворков там до черта — одних только IoC-контейнеров вон как собак не резанных. Так что не рубите сплеча. :)

        А низкий порог вхождения у JS берется с того, что можно начать на нем программировать просто открыв консоль хрома или же создать HTML или js файл в блокноте.


        1. altai2013
          03.08.2017 16:27
          #10341892
          +1

          js файл в блокноте — это еще не программирование, это «hello world». Подобного уровня знания бесполезны, они не дадут работу и это даже не старт, это буквально ноль. В плане вывода «hello world», Javascript выглядит простым, однако ни один реальный коммерческий продукт таким образом не делается и мне трудно представить джуниора, принятого на работу фронтендером (да хотя бы верстальщиком) после осваивания консоли, блокнота и HTML. Это даже не начало, это просто ноль. И даже на пути к простейшему js-файлу лежат, как минимум, три весьма толстых по объему книжки: HTML+DOM, Javascript, CSS.


          1. pnovikov
            03.08.2017 16:37
            #10341916
            +2

            Ууу… Знаете сколько у нас людей, которые приняты на работу с навыком писать маленькие галактики внутри тега script и вызова getElementById?.. :) Вот то-то же.

            Я JS в свое время так и изучил — методом тыка. Я не пишу на нем профессионально (ну один фреймворк с клиентской частью на TypeScript не в счет :) ), но вполне в курсе разворачивающихся вокруг него баталий.

            Вот лично для меня порог входа в JS — низкий.


            1. altai2013
              03.08.2017 18:15
              #10342076
              -2

              Вы считаете, что написать SPA при помощи Javascript намного проще для начинающего программиста, чем набросать мышкой компоненты в Visual Studio/Delphi? Порог вхождения в C# вы считаете высоким?


              1. pnovikov
                03.08.2017 18:24
                #10342088
                +2

                Странное у вас представление о C#. Студия — это просто IDE, которая правильно запускает вам компилятор и позволяет писать код на любом выбранном языке. Невозможно "написать программу на Visual Studio". Можно на C#, на VB.NET, на плюсах и на всем, что вы в студию доустановите. И кто вам сказал, что программирование на C# сводится к набрасыванию компонентов мышкой? Вот найдите того, кто сказал — и в глаз ему плюньте :) Я уже 11 лет на нем пишу и как-то даже не припомню когда последний раз набрасывал компоненты мышкой куда-либо.


                А вот программирование на javascript — таки да. Сводится к написанию кода на javascript, что можно делать хоть в обычном блокноте без всяких доп. инструментов и получать какой-либо осмысленный результат.


                1. pnovikov
                  03.08.2017 18:31
                  #10342096
                  +1

                  Ну и потом — на C# можно много чего писать — не только оконные приложения. Так что порог входа туда уже тем выше, что новичку надо определиться с тем, что именно он хочет получить с помощью C#. И поставить студию, да, познакомиться с чисто студийными примитивами — проект, солюшен. Без этого никак. Дюже сложнее чем просто создать файл и написать в нем console.log('hello world'); :)


                  1. 0xd34df00d
                    04.08.2017 19:54
                    #10344468

                    Вот, кстати, да, в далёком 2002-м году, когда мне было 11 лет и у меня появился компьютер, моим первым языком стал, простите, JavaScript. Ну а что, просто — на развале купил какую-то книжку, в notepad.exe написал что-то там, сохранил, открыл в браузере — хорошо, снежинки падают, часы идут!

                    А в С++ были какие-то main, проекты, компиляция, какое-то exe… Слоооожна!

                    Через год вернулся к плюсам вполне успешно, правда.


                1. altai2013
                  03.08.2017 18:44
                  #10342114
                  -1

                  Начинающие начинают с простого ведь, правильно? Что может быть проще одностраничного приложения, скажем какого-нибудь калькулятора с кнопками и меню настроек? Просто сравним, какой объем информации придется изучить для написания такой программы на C# в VS и на Javascript в блокноте. Боюсь, приложение на Javascript в разы сложнее окажется для любого студента. И дальше проще не будет.


                  1. pnovikov
                    03.08.2017 18:51
                    #10342122
                    +1

                    Ну тут знаете ли, первое с чем столкнется студент — что такой калькулятор можно написать как минимум тремя разными способами — WinForms, WPF и напрямую вызовами WinAPI — как нетрудно заметить, охват знаний будет очень и очень разный :)
                    WinForms — это безболезненный способ, на WPF студенту сорвет крышечку от порога входа, про WinAPI я даже говорить не буду :)


                    1. altai2013
                      03.08.2017 19:06
                      #10342156

                      Представим, что это не учебная задача, где преподаватель намеренно усложняет студенту жизнь, а реальный коммерческий проект. Студент хочет написать приложение и продавать его в Google Play или Microsoft Store.


                      1. pnovikov
                        03.08.2017 19:14
                        #10342176

                        Уууу… Это еще сложнее. Если он хочет мультиплатформенное приложение, видимо для мобильных (коль скоро в списке Google Play) — ему надо будет к студии доставить еще и рантайм Xamarin-а, ознакомиться с разницей между .NET Portable и .NET Client profile. В случае с MS Store — придется познакомиться с UWP и с XAML-разметкой (там уже WinForms не используется) — а это автоматом тянет за собой MVVM-фреймворк и IoC-контейнер (хотя без последнего можно и обойтись). А если он хочет писать игрушку — то тут уже Unity. А это отдельная песня.


                        Тут даже профессиональные компании предпочитают что-то простое делать на JS — том же React Native. Потому что проще :)


                        Редкий случай, когда я признаю частичную ущербность .NET в каком-либо вопросе :) Но с другой стороны зависит от сложности приложения. Что-то по-сложнее калькулятора комфортнее делать на строго типизированном языке с кросс-платформенными билдами.


                        1. bano-notit
                          03.08.2017 22:38
                          #10342496

                          Да что вы все к RN прицепились? Он нефига не быстрее, его можно использовать тогда, когда у вас сайт на нём сделан, и вам просто нужно его малой кровью перенести на относительную постоянку на телефон, он просто не сравним ни с какими там ксамаринами и тем более явами.


                          1. pnovikov
                            03.08.2017 22:40
                            #10342498

                            Вопрос был в пороге входа в язык. Как по мне, так сравнивать пороги входа в полноценный промышленный мультипарадигменный язык с JS, в котором бесконтекстную функцию воткни на страницу и она заработает — несколько бесперспективное занятие.


                            1. altai2013
                              03.08.2017 23:13
                              #10342536
                              -1

                              Между порогом входа и промышленной мультипарадигменностью лежит пропасть. Если мы говорим о пороге входа, то для C# это одна прочитанная книжка в стиле «C# за 21 день» + интуитивно-понятная IDE Visual Studio + перетаскивание компонентов мышью и написание мизерного объема кода для обработчиков событий. Этих знаний уже хватит студенту, чтобы идти искать работу. С Javascript всё, мягко говоря, сложнее. Открыть консоль недолго и JS-файл создать тоже, только с этими знаниями никакую работу не получишь — они бесполезны, а чтобы претендовать на деньги придется изучить массу технологий и массу инструментов, чтобы только начать что-то делать.


                              1. pnovikov
                                03.08.2017 23:17
                                #10342540
                                +2

                                Я боюсь, вы очень мало знаете о C# чтобы судить о низком пороге входа. Если вы начинаете писать на C# с WinForms и перетаскивания компонент — то вы начинаете неправильно.


                                1. altai2013
                                  04.08.2017 00:00
                                  #10342594

                                  Я начинал так, как меня учили в универе: сначала консоль, потом формы. И тоже могу сказать, что это было очень просто. Даже девушки, 4 года сдававшие чужие лабораторные, садились и писали свои курсовые и дипломы на C#. Вот я тоже боюсь, что вы очень мало знаете о Javascript, чтобы судить о его низком пороге. Всё вокруг просто: и вёрстка примитивна, и CSS элементарен, и Javascript — детский сад, и React люди осваивают за час. Однако на практике почему-то не наблюдается ни избытка хороших работ, ни избытка дешёвых квалифицированных специалистов. К сожалению, о простоте Javascript пишут люди, зарабатывающие деньги в совсем других областях, не в Javascript и даже не в вебе.


                                  1. pnovikov
                                    04.08.2017 00:05
                                    #10342598
                                    +1

                                    Вы это говорите человеку, который водиночку на голом TS без зависимостей написал фреймворк-контрол для датагридов, тесно интегрирующийся с MVC. Поверьте, я знаю о чем говорю. JS гораздо проще C#.


                              1. bano-notit
                                03.08.2017 23:23
                                #10342552

                                Сколько есть книжек "js за 21 день"? Ну вообще говоря есть книжки по jq, вот это есть, недавно в книжном видел. Так же есть книжка по нововведениям по сахару в es6, которая уже не имеет никакой цены, ведь есть es7, да и вообще тепереча каждый год будет выходить новый. Но вот книжек по реакту нету, по ангуляру тоже не видел. Но я не могу сказать, что в тот же реакт высокий порожек, очень даже низкий. В ангуляр2 я пробовал писать их хелловорлд на тайпскрипте… Для меня это показалось стрелять пушкой по воробьям, это я про сам ts, да и вообще слишком много кода, который на обычном js был бы и короче и с тем же функционалом. Поэтому я просто подзабил на ангуляр.


                                1. Zenitchik
                                  03.08.2017 23:42
                                  #10342566

                                  которая уже не имеет никакой цены, ведь есть es7

                                  Имеет имеет. И ещё года три иметь будет, пока es7 не будет поддерживаться ВЕЗДЕ.


                                  1. bano-notit
                                    03.08.2017 23:59
                                    #10342592

                                    Не… Вот когда es6 будет поддерживаться везде, вот тогда да.


                        1. Strain
                          03.08.2017 22:51
                          #10342522
                          +2

                          Кстати данный бугурт возник в процессе написания RN приложения. Заказчик хочет самые новые технологии — и чтобы сразу под андроид и под ios. И пофиг что RN в бете — мы хотим это, ведь Facebook же! Я согласился по глупости, больше такой ошибки не повторю. Не буду описывать всех найденных косяков RN, проблемы с GL шейдерами которые сходят каждый раз с ума при обновлении RN, и то что на android вообще половина фич не работает. Приведу простой пример. Навигация по скринам приложения. Вещь не специфичная и нужная буквально в каждом мобильном приложении. В ! официальной! доке от Facebook есть ссылка на npm пакет react-navigation. Это недоделка, одна из худших и запутанных библиотек для навигации. Приходится костылять и напильником допиливать официально рекомендованный facebook-ом пакет. Да в нём issue блин больше чем коммитов. И это один из примеров, в самом ядре React Native проблем не меньше.


                          1. raveclassic
                            03.08.2017 23:41
                            #10342564

                            Я с RN не сталкивался, но вроде последний react-router умеет в native.


                  1. franzose
                    04.08.2017 01:23
                    #10342654

                    Подключаем jQuery (мы ж начинающие) и делаем, как умеем. На C# получится примерно то же самое, только с помощью готовых компонентов типа кнопок и полей ввода.


              1. franzose
                04.08.2017 01:21
                #10342652
                +1

                SPA и «набросать компоненты» совсем не одно и тоже. Вот если б вы сказали «сверстать форму входа и повторить её на C#», было бы другое дело. Одним «формошёпством», как некоторые выражаются, C# не ограничен, хотя начинают обычно с этого, чтобы «поиграться» и вникнуть в азы.


                1. altai2013
                  04.08.2017 10:50
                  #10343178

                  Конечно, C# одним «формошлёпством» и Visual Studio не ограничен, зато Javascript у нас почему-то ограничен блокнотом и «просто создать файл и написать в нем console.log('hello world')».


                  1. franzose
                    04.08.2017 11:15
                    #10343242

                    А я где-то говорил, что JavaScript существенно ограничен? JavaScript ограничен настолько, насколько у него есть биндингов на низкоуровневые вещи.


          1. bano-notit
            03.08.2017 22:35
            #10342488
            -1

            Здрасте) Я учил js по фану именно в консоли, а тепереча вот с новомодными реактами вожусь, да на мобиксы заглядываюсь :D


        1. bano-notit
          03.08.2017 22:33
          #10342486

          Почему до сих пор тогда нету vbs программистов? У vbs порог тогда вообще никакой по сравнению с js, ибо возможностей больше, а основная аудитория, которая скрывается под "просто открыть консоль хрома" — всё же виндузятники, а не линуксоиды. Поэтому нет, низкий порог не этим обусловлен, а скорее тем, что язык многое прощает в самом начале. В плюсах ничерта не так — забыл ; — "Молодец! Иди в жопу, я такое не понимаю!" от компилятора. В js же ты будешь писать до тех пор пока не получишь исключение типа "undefined if not a function" или "cannot read property <> of null/undefined". И только тогда ты начнёшь задумываться: "А где же я накосячил? И что вообще за фигню мне в красных строчечках пытается пропихнуть браузер?"


          1. pnovikov
            03.08.2017 22:35
            #10342490

            Вокруг VBS не было хайпа во-первых (кстати как и вокруг всего WSH, который существовал как внебраузерный скриптовый движок ооооочень задолго до nodejs), во-вторых — не было удобных инструментов отладки. Не было консоли, не было документации и уроков. Ну уроки — лишнее, согласен. Я кстати на VBS все же писал. Это было весело, но окружение как-то не располагало к глубокому изучению.


            1. bano-notit
              03.08.2017 22:44
              #10342508

              Да кто же травvbs не баловался?) На счёт хайпа позвольте всё же не согласится, до всех этих реактов и es6 js как-то жил на jq, у него был extjs, prototype, да и нокаут наконец. Не сильно он бедствовал без внимания всяких там гуглей да мордокнижных.


              1. pnovikov
                03.08.2017 22:47
                #10342514

                Дык и сумасшествия поголовного тогда не возникало. Претензий к JS до '10х годов у меня вообще нет.


                У меня в принципе нет претензий к технологиям. А вот к сообществу — таки есть, да. :)


          1. Lofer
            04.08.2017 00:02
            #10342596
            +2

            Почему до сих пор тогда нету vbs программистов? У vbs порог тогда вообще никакой по сравнению с js, ибо возможностей больше,

            VBS — на нем был сделан в конце 90х начале 200х ASP. Как вспомню тот @#$^$% что творился при отладке, до сих пор в ужас бросает. Возможно MS после этого сделал вменяемый ASP.NET забрав все что можно в контролируемое окружение с нормальным инструментарием. Это было как радуга… как фантастика после VBS для веб разработки. После этого любые «слабая типизация» или «оно само сделает» ничего кроме мата в мыслях не вызвает.


        1. pawlo16
          03.08.2017 23:52
          #10342578
          -5

          Вне виновз десктоп и юнити C# уныл, проигрывает конкурентам (java, kotiln, go, python) по всем статьям, а перспективы его там сомнительны более чем. И порог вхождения в C# всегда был высок, но сейчас конечно js переплюнул с трешем баблей-вебпаков-реактов-редаксов. проблема C# в том, что он практически такой же отстойный как java (ну может быть чуть-чуть лучше), но при этом рантайм развит и интегрирован на порядок примерно хуже чем jvm.


          1. pnovikov
            03.08.2017 23:55
            #10342582
            +2

            Ну вам по ходу дела бессмысленно объяснять про деревья выражений, LINQ и where-констрейнты в C# :) Спите спокойно: C# убог


            1. pawlo16
              04.08.2017 08:39
              #10342882
              -2

              Отнюдь нет. Я с эти работал, так что Вы можете попытаться. Заодно расскажите, как сильно наличие данных языковых фич (к которым к слову деревья выражений не относятся, в них любой ЯП умеет) повлияло на выбор C# в качестве ЯП для unity и UWP, где он действительно востребован. И почему ни кто не торопится перевести бэкенд с java/c++/nodejs на C# не смотря на наличие данных фич. В отличие от гошечки, на которую переходят с радостью я бы сказал


              1. pnovikov
                04.08.2017 08:48
                #10342898
                +1

                Любой ЯП умеет разобрать переданную лямбду на куски и транслировать в другой язык? Это какой такой ЯП так умеет кроме C# — покажите, я с радостью на него перейду. :)
                Бекенда на C# написано как раз столько, что вам и не снилось. Самый известный — для stackoverflow и из русского — moedelo. Так что тут вы тоже ошибаетесь.


                А гошечка… Ну если ваше приложение ограничивается 20-30 REST-методами для CRUD-а, то гошечка — выбор для вас, да. Как только надо сделать что-нибудь более сложное (e.g. интеграцию между несколькими сервисами, REST со сложной функциональностью, вытягивание выборки из БД по сложному запросу) — тут-то гошечка начинает только мешать и вот мои знакомые, например, с радостью съезжают с гошечки на C#, ибо как удобнее. :)


                1. pnovikov
                  04.08.2017 08:54
                  #10342906
                  +3

                  Спойлер: вся простота и красота гошечки (равно, кстати, как и nodejs) превращается в нещадное адище, когда вы понимаете что вам нужен координатор распределенных транзакций (который, кстати, в C# точно есть, насчет Java не скажу). Если вы с таким не сталкивались и считаете что проблема нерелевантна — расслабьтесь и примите как данность что вы просто пишете слишком простые вещи.


                  1. staticlab
                    04.08.2017 09:29
                    #10342958
                    +3

                    Java Transaction API точно есть. Притом с несколькими реализациями. А MSDTC — специфическая виндовая система.


                  1. pawlo16
                    04.08.2017 10:40
                    #10343142
                    -1

                    Это какой такой ЯП так умеет кроме C# — покажите, я с радостью на него перейду. :)

                    clojure, elixir. Из типизированных — F#, Scala. Good luck!


                    Бекенда на C# написано как раз столько, что вам и не снилось

                    Больше чем на c++/java/python ?? не фантазируйте ))


                    Самый известный — для stackoverflow

                    аргумент вида "твитер написан на скала — значит это хороший язык, и мне надо его использовать"


                    интеграцию между несколькими сервисами, REST со сложной функциональностью, вытягивание выборки из БД по сложному запросу

                    в гоу это всё в разы проще благодаря общеязыковым фичам и плюшкам рантайма и экосистемы. Например благодаря отсутствию "убийц времени" (эксепшнов, наследования, перегрузки операторов и функций, конструкторов, неявных преобразований типов и generic-ов).


                    координатор распределенных транзакций

                    это из области кровавого энтерпрайза и борьбы с легаси. Это не для Гоу конечно, но конкретно в данном аспекте java и кложура предпочтительней C# по многим причинам. В типичных приложениях Гоу такие задачи решаются взаимодействием и интеграцией с сервером БД. Почитайте на досуге про шардинг и репликацию, ага?


                    Если вы с таким не сталкивались и считаете что проблема нерелевантна — расслабьтесь и примите как данность что вы просто пишете слишком простые вещи.

                    Я уже понял что вы джедай, а я неопытный хелувордист в лучшем случае. Ни разу с вами не спорю. Вам как эксперту в этом вопросе безусловно лучше знать ху из ху.


                    1. pnovikov
                      04.08.2017 11:03
                      #10343208
                      +4

                      clojure, elixir. Из типизированных — F#, Scala. Good luck!

                      Вы, очевидно, не понимаете о чем идет речь. Почитайте как устроен конструктор запросов в EntityFramework.


                      Больше чем на c++/java/python

                      Мы тут вроде не сосисками меряемся. Я просто говорю о том, что бекенда на C# пишется довольно много. Это был контраргумент к


                      почему ни кто не торопится перевести бэкенд с java/c++/nodejs на C#

                      Потому что, наверное, мало кто в принципе занимается переводом тяжелого бекенда с фреймворка на фреймворк забавы ради. А так — как я и сказал. Бекенда на C# написано достаточно много, чтобы оценить все плюсы и минусы подхода. Если вам для дискуссии именно что надо "больше чем на X", то сочувствую.


                      благодаря отсутствию "убийц времени"

                      Гы. Молодой человек, если generic-и, наследование и перегрузка операторов убивают ваше время, то есть отличный выход. Готовы? Открываю тайну: не пользуйтесь ими. :) Не говоря уже о том, что сдуру можно и член сломать: если вы пользуетесь ими так, что они отнимают ваше время, а не экономят — то вы пользуетесь ими неправильно.


                      В типичных приложениях Гоу такие задачи решаются взаимодействием и интеграцией с сервером БД. Почитайте на досуге про шардинг и репликацию, ага?

                      Это вы-то меня будете шардингу учить? Спешу расстроить: после корпоративной системы документооборота с распределенными БД — вы меня точно шардингу не научите. Так или иначе шардинг и репликация даже близко ничего не имеет с распределенными транзакциями. Читайте, читайте что делает MSDTC и почему.


                      Я уже понял что вы джедай

                      А то ж.


                      1. staticlab
                        04.08.2017 11:09
                        #10343232

                        clojure, elixir. Из типизированных — F#, Scala. Good luck!

                        Вы, очевидно, не понимаете о чем идет речь. Почитайте как устроен конструктор запросов в EntityFramework.

                        Так а что не так с этими языками?


                        1. pnovikov
                          04.08.2017 11:29
                          #10343266

                          Речь идет о вот этой технике работы.


                          1. staticlab
                            04.08.2017 11:31
                            #10343270

                            Вы действительно думаете, что работа с AST — прерогатива исключительно .NET?


                            1. pnovikov
                              04.08.2017 11:35
                              #10343278
                              +2

                              В том виде, в котором это происходит в .NET — да. Когда работа с AST становится неотъемлемой частью ежедневной работы и продакшн-кода повсеместно.


                              Так-то понятное дело что AST можно написать на любом языке.


                              1. retran
                                04.08.2017 13:30
                                #10343588

                                При всей моей любви к сишарпу — ему в этом плане довольно далеко до языков умеющих в полноценный quotation и настоящие макросы.


                                1. pnovikov
                                  04.08.2017 13:41
                                  #10343626

                                  Вы думаете нам легко? Мы тоже сильно страдаем от отсутствия квазицитирования. Несколько раз порывались перейте на nemerle, но нас остановил убогий тулсет.


                                  1. develop7
                                    06.08.2017 09:00
                                    #10345774

                                    F#?


                      1. pawlo16
                        04.08.2017 11:49
                        #10343290

                        Вы, очевидно, не понимаете о чем идет речь

                        речь о "разобрать переданную лямбду на куски и транслировать в другой язык" — перечисленные ЯП умеют на много это лучше чем C#.


                        Почитайте как устроен конструктор запросов в EntityFramework.

                        А если выключить смешной снобизм и предположить что EF я не только палкой ковырял, но даже нырял туда в акваланге, то сколько ещё отстойных фреймворков надо освоить, чтобы оценить C#?


                        мало кто в принципе занимается переводом тяжелого бекенда с фреймворка на фреймворк

                        Пойнт в том, что тем не менее на гошечку переводят довольно много и часто, а на C# — практически никогда.


                        Открываю тайну: не пользуйтесь ими.

                        прикладной продовый код на Asp net (EF, WPF что там еще), который это не использует — в студию!


                        если вы пользуетесь ими так, что они отнимают ваше время, а не экономят — то вы пользуетесь ими неправильно.

                        Для означенных элементов over-engineered-abstract-pattern-driven-development опция "использовать правильно" присутствует только в области ментальной маструбации.


                        А то ж.

                        как собственно и любой джун в глубине своего ложного эго. Вопрос в этичности и уместности демонстрации оного


                        1. pnovikov
                          04.08.2017 12:06
                          #10343348
                          +4

                          перечисленные ЯП умеют на много это лучше чем C#

                          Ок. Видимо F# перенял эту фичу и .NET-а. С ним понятно. На остальные — попрошу ссылочку навроде вот этой, приведенной выше. С удовольствием почитаю.


                          сколько ещё отстойных фреймворков надо освоить, чтобы оценить C#?

                          Тут где-то читается "ниасилил".


                          на гошечку переводят довольно много и часто

                          Я и не отрицаю что на гошечку переводят хелловорлды и CRUD-сервисы. Каждому свое. Однако не стоит из факта, что на гошечку перевели 100 CRUD-сервисов, пару игр и мессенджер делать вывод, что гошечка прекрасно подойдет, например, для банкинга. Цимус C# в том, что он хорошо подходит и для первого и для второго.


                          прикладной продовый код

                          Я что-то не понял, для вас унаследоваться от Controller в MVC (сиречь — впечатать : Controller в код, а с решарпером по факту будет : Co<Enter>) — это трата времени? Тут я даже не знаю что возразить. Предстваляю какое для вас мучение Javascript — там же регулярно надо писать function руками :)


                          Для означенных элементов over-engineered-abstract-pattern-driven-development

                          Слушайте, если вы не умеете проектировать — ну так и говорите. Не стоит свои проблемы проецировать на меня.


                          как собственно и любой джун в глубине своего ложного эго

                          В мои публикации на хабре зайдите хотя бы


                          1. retran
                            04.08.2017 13:36
                            #10343608

                            Джон Маккарти изобрел s-epxressions в далеком-далеком 1958 году.

                            В мои публикации на хабре зайдите хотя бы


                            Вполне достаточно того, что вы не в курсе, что квотирование, анализ, генерация и выполнение AST в рантайме изобретены далеко не в дотнете.


                            1. pnovikov
                              05.08.2017 18:29
                              #10345318
                              +2

                              Вы видимо не поняли — вопрос был не о том, где и когда были изобретены деревья выражений, а в каких языках они повсеместно и с комфортом используются.


                              К слову: речь шла о технике использования, когда AST конструируется в compile time, а в рантайме не выполняется, а анализируется. Ну то есть без выполнения. Опять мимо.


                              1. 0xd34df00d
                                06.08.2017 01:18
                                #10345622

                                А зачем анализировать AST в рантайме, если это можно сделать в компилтайме?


                                1. pnovikov
                                  06.08.2017 07:17
                                  #10345744
                                  +1

                                  А затем, друг мой, чтобы например транслировать их в код на другом языке. Например в SQL. Конструкцию вида
                                  users.Where(x=>x.Age > 18).Select(x=>x.Name)
                                  превратить в
                                  SELECT Name FROM Users WHERE Age > 18
                                  и скормить базе данных, если тип users — EF-ный DbSet<>.
                                  А если просто массив — то превратить это в итератор по результатам


                                  То есть вы полностью сохраняете строгую типизацию и одновременно прямо из языка пишете запрос в базу данных.


                                  1. 0xd34df00d
                                    06.08.2017 09:46
                                    #10345818

                                    Зачем это делать в рантайме? Вы можете оттранслировать-отанализировать AST в нужный вам проблемноспецифичный IR во время компиляции, а во время выполнения, не знаю, подставить нужный синтаксис запросов, специфичный для вашей базы. Зачем всё в рантайм-то переносить?

                                    Я на плюсах вещи, которые из myOrmObject->select(_1 == foo && _3 <= 42); делают нужный селект с типобезопасностью и проверками, тоже писал. А на хаскеле с его Generic'ами (даже template haskell не надо) это вообще всё делается чертовски изящно, рекурсивно и даже без трихомонадок.


                                    1. pnovikov
                                      06.08.2017 09:51
                                      #10345824

                                      Зачем это делать в рантайме?

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


                                    1. pnovikov
                                      06.08.2017 09:55
                                      #10345830

                                      Ну еще иногда эта фича используется во fluent-конфигурации. Например в Automapper можно таким вот изящным образом указать функцию для вычисления проперти при маппинге:


                                      mapper.CreateMap<MyType>()
   .ForMember(x=>x.Age,
   x=>x.MapFrom(d=>DateTime.Now.Subtract(d.BirthDate).TotalYears);


                                    1. Lofer
                                      06.08.2017 11:43
                                      #10345924
                                      +3

                                      Зачем это делать в рантайме? Вы можете оттранслировать-отанализировать AST в нужный вам проблемноспецифичный IR во время компиляции, а во время выполнения, не знаю, подставить нужный синтаксис запросов, специфичный для вашей базы. Зачем всё в рантайм-то переносить?

                                      В этом и фишка, что:
                                      • можно в бизнес-логике строить запросы в процессе работы
                                      • на ходу менять базы/источники данных
                                      • провайдеры баз/источников данных занимаются трансляцией объектных выражений LinQ из «абстрактного» в «конкретный»

                                      Обычно есть некторые механизмы оптимизации.


                          1. pawlo16
                            05.08.2017 17:38
                            #10345292
                            -3

                            Я и не отрицаю что на гошечку переводят хелловорлды и CRUD-сервисы.

                            Так и запишем: bower, продакшен сервисы гугла и mail ru group — хелловорлды. Вы точно уверены, что после подобных заявлений ваша профпригодность требует дополнительных подтверждений? Интересно, почему они именно на гошечку переходят, а не на С#? ведь казалось бы — Linq, EF как без этого жыть. Может быть потому, что Asp.Net Core сливает вчистую гошечке ? Впрочем, я уже понял, что вы не любознательны


                            Я что-то не понял, для вас унаследоваться от Controller в MVC… — это трата времени?

                            Утрируете, реальный продовый код asp net полон всякого рода абстрактных фабрик визиторов по синглтонам и прочих inversion of control-извращений. Я работаю с гигантской кодовой базой, и у меня банально нет ни времени ни желания вникать что от чего наследуется, как перегружается и куда упаковано. А в гошечке на минуточку одна единственная абстракция ввода вывода, единообразно применимая ко всему включая файловую систему, веб-сервер, пайпы


                            1. pnovikov
                              05.08.2017 18:11
                              #10345304
                              +4

                              реальный продовый код asp net полон всякого рода абстрактных фабрик визиторов по синглтонам и прочих inversion of control-извращений

                              Черт побери, серьезно? Вы это вычитали на каком-то форуме про go от таких же go-фэнбоев, как вы сами? Даже ваша фраза "фабрика визиторов по синглтонам" не имеет технического смысла. Вы просто нагромоздили терминов, которые когда-то где-то слышали. Ваш уровень понимания ООП, равно как и .NET-стека находится на уровне "что-то где-то услышал, там говорят еще синглтоны есть". Настоятельно не рекомендую вам больше критиковать C# и ASP в приличных обществах — вас закидают тапками. И подучить ООП, а то вы выглядите просто смешно.


                              bower

                              Читаю в их твиттере: "Our registry now uses little go-lang proxy to serve assets faster and to conserve memory thanks to better GC". Так и говорите: "bower используют маленький прокси на go-lang". В такой формулировке это больше походит на хелловорлд чем на серьезную систему.


                              гугла

                              По второй ссылке ребята пишут, что "the core logic of the system fits in a couple hundred lines of code, all in the same file". Очуметь! Невероятно масштабный подход. Я-то думал они что-то вроде Gmail портировали на go, а у них всего-то несколько сот строк кода для какого-то, скорее всего, внутрикомпанейского сервиса. Тем паче, что портировали они с C++. С него куда ни портируй — везде будет меньше кода.


                              Asp.Net Core сливает вчистую гошечке

                              К'мон, да правда чтоли? На задачах "принять JSON-файл с клиента и отдать ему код 200"? Это мне напомнило восторженные бенчмарки "Java работает ничуть не медленнее чем C++", которые складывали друг с другом 10 тысяч float-ов. А если я на голом ассемблере напишу веб-сервис, которому гошечка будет сливать подчистую — вы побежите всех агитировать переходить на ассемблер?


                              1. pawlo16
                                05.08.2017 20:20
                                #10345368
                                -4

                                таких же go-фэнбоев, как вы сами
                                Настоятельно не рекомендую
                                подучить ООП, а то вы выглядите просто смешно.
                                К'мон, да правда чтоли?

                                переход на обсуждение моей личности и усиливающийся накал истеричной поучительности в каждом вашем каменте доказывает, что в глубине
                                души вы понимаете что гошечка на много лучше C# :-) понимаю, тяжело признать собственную несостоятельность :-)


                                Даже ваша фраза "фабрика визиторов по синглтонам" не имеет технического смысла

                                это лёкгий троллинг ООП, а тех. смысл её, которые вы не уловили из-за гнева — типичный ОППшный оверинжиниринг :-)


                                Очуметь! Невероятно масштабный подход.

                                эмоции не дают вам осилить текст до конца? "Our Go-based rewrite is 121 Go source files totaling about 21K lines of code (including comments). Compare that to the original system, which was 1400 C++ source files with 460K lines of code "


                                вот на вскидку не полный список сервисов гугла, переписанных на Go с других языков


                                • YouTube (MySQL scaling infrastructure)
                                • dl.google.com: mailing list discussion / OSCON slides
                                • Flywheel
                                • Seesaw load balancer

                                несколько сот строчек кода, ага :-)


                                Тем паче, что портировали они с C++. С него куда ни портируй — везде будет меньше кода.

                                Ещё раз — если C# по вашим словам лучше Гоу, то почему они не сделали это на C#? а как же linq и where constraint? Впрочем, ответ на этот вопрос вашего раздутого ЧСВ мне примерно понятен — в гугле работают идиоты, пишут там хелуворд :-) и кстати, откуда вы взяли что "везде будет меньше кода"? приведите пруфлинк пожалуйста или признайте, что сказали не подумав


                                На задачах "принять JSON-файл с клиента и отдать ему код 200"?

                                а приведите пример аналогичного бенчмарка с принципиально более комплексной логикой


                                А если я на голом ассемблере напишу веб-сервис, которому гошечка будет сливать подчистую — вы побежите всех агитировать переходить на ассемблер?

                                Сравнение не корректное, поскольку код на низкоуровневом ЯП сложнее высокоуровнего, в отличие от кода на гошечке, который в разы проще и понятнее, а в 90% случаев значительно короче, чем код на С#. А стоимость и скорость разработки — она таки имеет значение. (OMG, и это я рассказываю человеку, мнящему себя джедаем! детский сад какой-то :-) )


                                1. TheShock
                                  05.08.2017 20:30
                                  #10345378
                                  +1

                                  Ещё раз — если C# по вашим словам лучше Гоу, то почему они не сделали это на C#?

                                  Очень слабая аргументация. То, что пару сервисов на волне хайпа написали на Гоу (а может и чисто, чтобы поддержать технологию гугла) не означает ничего.

                                  С таким же успехом я могу спросить — почему большинство игр сейчас пишется не на Гоу, а на С++ и С#? Неужели Гоу настолько плох, что на нем нельзя написать полноценную игру и можно писать только примитивные сервисики и искусственные бенчмарки?


                                  1. pnovikov
                                    05.08.2017 21:06
                                    #10345400
                                    +3

                                    Стоп, так go — это гугловая технология?


                                    Тэээкс… сдается мне, товарищ нас троллит. Почему гугл переписал свои сервисы на свою же технологию а не на C#? И действительно...


                                    1. TheShock
                                      05.08.2017 22:00
                                      #10345440

                                      Go — компилируемый многопоточный язык программирования, разработанный компанией Google


                                  1. pawlo16
                                    06.08.2017 17:19
                                    #10346234
                                    -2

                                    пару сервисов

                                    Так это не моя аргументация, я такого не утверждал. Это вы выдаёте желаемое за действительное :-) В гугле, facebook, dropebox, Adobe, Oracle и прочих гигантах сотни, если не тысячи сервисов различного масштаба на Go. А не два :-)


                                    почему большинство игр сейчас пишется не на Гоу, а на С++ и С#?

                                    У вас совсем нет мозгов задавать такие глупые вопросы? О_о Действительно, почему ЯП с GC не вытеснит С/С++ там, где борятся за каждый так процессора? Видимо язык не очень. и из того факта, что Go не завезли в unity, конечно следует что Go на много хуже js и C#, которые в unity есть. Игровых бэкендов на Гоу написано предостаточно если что (в отличие от С#), и их число постоянно растёт.


                                    только примитивные сервисики и искусственные бенчмарки?

                                    так и запишем: youtube и dl.google.com — примитивные сервисы. Спасибо, посмеялся) docker, Kubernetes — не, не слышал :-) Вообще то гоу — системный ЯП, и написать на нём можно что-угодно. В отличие от C#, который обречён прибывать в узкой виндовз десктоп и кровавого энтерпрайза


                                    1. Lofer
                                      06.08.2017 17:45
                                      #10346256
                                      +1

                                      В отличие от C#, который обречён прибывать в узкой виндовз десктоп и кровавого энтерпрайза

                                      Это откуда такой пессимимзм?


                                      1. pawlo16
                                        06.08.2017 19:19
                                        #10346322
                                        -2

                                        А есть повод для оптимизма? Mono не выстрелил. Xamarin — маргинальщина. Net Core — кому нужен ещё один jvm 10-и летней давности без десктопа и GWT? С тяжёлым, перегруженным хламом, ООП-центрированным веб фреймворком, который в клиент примерно ни как и работает через костыли в виде kestrel. В java-мире же примерно всё то же самое, плюс минус, но на много лучше развито. И kotlin как ЯП лучше C#


                                    1. grossws
                                      06.08.2017 20:11
                                      #10346374
                                      +2

                                      Вообще то гоу — системный ЯП

                                      Расскажите, что вы под этим подразумеваете. В моём представлении язык с GC не является системным от слова совсем.


                                      Тот же D в теории может работать без GC, если не использовать стандартную библиотеку чуть более чем полностью, т. к. строки и исключения требуют GC. Но на практике я бы к системным его не относил.


                                      1. pawlo16
                                        06.08.2017 21:37
                                        #10346424
                                        -2

                                        В смысле Go делает нативный бинарник, которому не нужна ни толстая виртуальная машина, ни тормозной интерпретатор, и в этом смысле ни чем не отличается от сишечки. И в сишечку умеет весьма не плохо. Это означает, что программа на Гоу (C/C++, D, Rust) меньше греет железо при прочих равных, чем С#, java, python и т.п. Что делает её теоретически пригодной для системных задач.


                                        Почему? На D продакшен код не писал, но не вижу причин не относить его к системным.


                                        1. grossws
                                          06.08.2017 22:06
                                          #10346442
                                          +3

                                          У меня сразу возникает впечатление, что вы не имели дела с системным программированием, но только с прикладным.


                                          В смысле Go делает нативный бинарник, которому не нужна ни толстая виртуальная машина, ни тормозной интерпретатор, и в этом смысле ни чем не отличается от сишечки.

                                          Excelsior JET из набора jar'ников делает нативный код. Стала ли java после этого системным языком программирования? Та же java умеет работать на JavaCard (где nodejs, go и прочие не влезут в принципе). Правда, там из типов данных почти ничего нет (short хватит всем), память персистентная и, как правило, нет GC в принципе. Объект удаляется только при стирании апплета с карты.


                                          Го имеет GC, рантайм, стандартную библиотеку, требующую наличия ОС и прочие радости, которые не позволяют писать на нём, например, ядро ОС. В нём нет нормальной прямой работы с памятью IIRC.


                                          D относить к системным не стал бы по той же причине. Хотя vintage, может и будет несогласен.


                                          Это означает, что программа на Гоу (C/C++, D, Rust) меньше греет железо при прочих равных, чем С#, java, python и т.п. Что делает её теоретически пригодной для системных задач.

                                          Первое не доказано от слова совсем (как минимум, против Java; зачем вы приплели сюда python — не понятно). Маловероятно, что относительно простой AOT компилятор для go будет лучше сильно оптимизированного PGO JIT'а из HotSpot. Не говоря уже о том, что JIT вполне может использовать наборы инструкций, имеющиеся на target host'е, а скомпилированная программа будет ориентирована на какой-то generic target. Или ставить в один ряд компилятор go и хороший оптимизирующий компилятор типа gcc/icc, которые могут делать огромное количество оптимизаций полагаясь на отсутствие в программе UB, возлагая эту проблему на программиста.


                                          В общем, напишите менеджер памяти на go работающий на bare metal (под одну из архитектур доступных в qemu), тогда будете рассказывать какой он системный.


                                          Я из ныне живых системных языков могу назвать C, C++ (по модулю неиспользования значительного куска STL), Ada и диалекты Forth'а. Fortran ещё, хотя именно для системного программирования он особо не используется. Rust в эту область плавно заходит и proof of concept в виде ОС Redox вполне тому подтверждение.


                                          1. 0xd34df00d
                                            06.08.2017 22:30
                                            #10346476

                                            по модулю неиспользования значительного куска STL

                                            Контейнеры — это как раз не самый большой кусок STL.


                                            1. grossws
                                              06.08.2017 23:12
                                              #10346534

                                              А также тредов, примитивов синхронизации, медленно появляющихся операций по работе с fs, всяких кусков из stdio и т. д и т. п., но это пока мы говорим о bare metal. Как появился user space — всё гораздо лучше и проще.


                                          1. pawlo16
                                            06.08.2017 23:44
                                            #10346576

                                            Оси и менеджеры памяти не писал если вы об этом, но есть опыт низкоуровневого продакшена (дрова, LLVM, embeded). Я исходил из более абстрактного общепринятого понятия — низкоуровневая дёргалка компонентов оси, обеспечивающая работу других программ. Докер и Kubernetes, которые традиционно относят к системным утилитам, подходят под него, но не под ваше, которое имхо ни чем не хуже и не лучше. Факт — низкоуровневый код на Гоу писать проше чем например на C#.


                                            Excelsior JET из набора jar'ников делает нативный код

                                            ну не хватало ещё платный костыль только для того, чтобы нативный код сделать


                                            Первое не доказано от слова совсем

                                            Я переписал 2 ситемы из категории "опердень" на Гоу с С#. Результат — пиковая нагрузка на проц плюс минус та же, но мозгов сжирает меньше в разы — подтверждается различными бенчмарками и легко объясним. Думаю с java была бы принципиально та же ситуация, ибо вряд ли в .net под виндовз JIT компилятор хуже java. Что опять таки видно из бенчмарков Go vs. java. Но это только для тех частей системы, в которых не удалось распараллелить вычисления. В распараллеленных выйгрыш по перформансу при переходе на Гоу, надеюсь вы понимаете — колосальный.


                                            1. Lofer
                                              07.08.2017 01:05
                                              #10346672
                                              +2

                                              Я переписал 2 ситемы из категории «опердень» на Гоу с С#. Результат — пиковая нагрузка на проц плюс минус та же, но мозгов сжирает меньше в разы — подтверждается различными бенчмарками и легко объясним. Думаю с java была бы принципиально та же ситуация, ибо вряд ли в .net под виндовз JIT компилятор хуже java.

                                              Мельком глянул описание работы GC «Go 1.4+ Garbage Collection (GC) Plan and Roadmap» — у .Net и Go, разные стратегии работы с памятью. Не удивительно что результаты разные. Если бы задались целью оптимизировать использование памяти в C# — возможностей для оптимизации море.
                                              В распараллеленных выйгрыш по перформансу при переходе на Гоу, надеюсь вы понимаете — колосальный.

                                              Это будет в любом языке нормальном языке.
                                              Не понятно где тут «сильно круче».


                                              1. pawlo16
                                                07.08.2017 07:50
                                                #10346814
                                                -4

                                                Я выше упоминал, в Go 1.8 искаропки STW пауза не превышает 100 микросекунд не зависимо от размеров хипа. И для этого не нужно применять сложные оптимизации, выполняемые senior программистами, окончившими специальные полугодовые курсы oracle/microsoft


                                                Это будет в любом языке нормальном языке.

                                                если C# / Java / JS для вас нормальные, то они в этом плане просто сосут. Или вы имеете ввиду некий маргинальный ЯП типа хаскель?


                                                1. Lofer
                                                  07.08.2017 22:23
                                                  #10348010

                                                  И для этого не нужно применять сложные оптимизации, выполняемые senior программистами, окончившими специальные полугодовые курсы oracle/microsoft

                                                  Ничего сложного нет. Простая как грабли стратегия — нагадил? убери за собой! Кроме тебя никто не знает какая у тебя стратегия работы с памятью.
                                                  По моему мнению, как писавшему код как на С++ так и C#/Java, прямая ответственность программиста — управление памятью, а всякие GC — просто сервис, а у дареного коня всегда с кариес :).

                                                  если C# / Java / JS для вас нормальные,

                                                  Свои задекларированные возможности исполняют? Это дешевле чем «другой обычный/популярный язык»? значит нормальные.


                                                  1. pawlo16
                                                    08.08.2017 00:21
                                                    #10348116
                                                    -3

                                                    Ну то есть вам GC 1) не нужен 2) не важно как он работает. Удачи вам с ручной сборкой мусора


                                                    В другой ветке я расписал подробно, почему C# не нормальный язык, а самый что ни на есть отстой для типичных задач бэкенда. Почти всё то же самое относится и к java, плюс jar hell и jvm versions hell


                                                    1. Lofer
                                                      08.08.2017 09:57
                                                      #10348346

                                                      Ну то есть вам GC 1) не нужен

                                                      Точно в такой же мере, как и любой другой сервисный инструмент. Есть — хорошо, нету — ну и фиг с ним, сам сделаю.
                                                      2) не важно как он работает.

                                                      Не очень понято, как можно трактовать «прямая ответственность программиста — управление памятью» настолько превратно.
                                                      Важно понимать как он работает и учитывать при разработке, если можешь им управлять — еще лучше.
                                                      Удачи вам с ручной сборкой мусора

                                                      Ох уж это поколение графических интефейсов… совсем обленились люди. Следующее будет «удачи вам с расстановкой точек остановки руками» или «удачи вам чтения отладочных логов глазами»?


                                                      1. AndreyRubankov
                                                        08.08.2017 10:18
                                                        #10348372

                                                        «удачи вам чтения отладочных логов глазами»
                                                        Воу-воу-воу! Если будут логи – это уже признак, что не все потеряно ;-)

                                                        Из тех JS команд, с которыми/в которых я работал практически все негативно относятся к логгированию, мотивируя тем, что «есть же дебаггер, зачем нам логи писать? может еще аллертами дебажить?».

                                                        А учитывая, что эти же ребята хотят писать бекенды на JS, то и про логгирование может будет забыть; хотя, если какой-то airbnb напишет статью о том, что писать логи — это хорошо, тогда и логи будут)))


                                                        1. greendimka
                                                          08.08.2017 10:26
                                                          #10348394

                                                          «А покажи статью, подтверждающую то, что ты мне тут говоришь» — еще один признак эникейщика, возомнившего себя программистом.


                                                          1. AndreyRubankov
                                                            08.08.2017 10:52
                                                            #10348454

                                                            Это вы сильно жестко отзываетесь о людях.

                                                            Тут дело в другом: JS на столько полиморфный язык, что на этой базе можно разработать десятки стилей написания кода.
                                                            В столь не постоянной и хаотечиской среде есть только 2 способа получить знания: Потыкать самому и Почитать статью, в которой кто-то рассказывает про свой опыт потыкать.

                                                            Соответственно, любые книги по JS в этом скоростном «хаосе» бесполезны. Пока кто-то напишет книгу, она уже успеет 2 раза устареть. А к тому времени, когда сделают перевод, книга будет похожа на «история первобытных людей».

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


                                                            1. greendimka
                                                              08.08.2017 12:14
                                                              #10348588
                                                              +1

                                                              Может и жестко. Просто из опыта: люди отказывались признавать логические выкладки, если я не показывал им статью из интернета, в которой были бы описаны такие же выкладки. И если такие аргументы, как «нет времени искать статью для подтверждения каждой мысли» и «не на всё ещё написаны статьи» не помогали, то я считал это тупостью. Может и резко. Но никто не отменял способность думать самим вместо поиска доказательств среди чужих мыслей.


                                                    1. Free_ze
                                                      08.08.2017 11:56
                                                      #10348552

                                                      В другой ветке я расписал подробно, почему C# не нормальный язык, а самый что ни на есть отстой для типичных задач бэкенда

                                                      У вас там мягко говоря вкусовщина (конструктив только про стратегию GC) вперемешку с прикольными штучками из Go.

                                                      плюс jar hell и jvm versions hell

                                                      Что мешает так же класть рядом различные версии библиотек, если это необходимо?


                                                      1. AndreyRubankov
                                                        08.08.2017 13:18
                                                        #10348736

                                                        плюс jar hell и jvm versions hell

                                                        Что мешает так же класть рядом различные версии библиотек, если это необходимо?
                                                        в Java нельзя просто взять и положить различные версии библиотек в один класспасс. Это приведет к непредсказуемым последствиям.

                                                        хотя, за мои 5 лет в java мире на проектах различной сложности, я еще ни разу не сталкивался с этой проблемой.


                                                      1. pawlo16
                                                        08.08.2017 13:32
                                                        #10348760
                                                        -3

                                                        а горутины — это по вашему вкусовщина, прикольная фишка, или конструктивный шах и мат C# господам (на всякий случай ещё раз уточню — для бэкенда, в юнити и UWP пофиг).


                                                        Возьмём для примера перегрузку операторов. Надеюсь не надо объяснять, почему те люди, которые ввели эту синтаксическую опцию в С++, должны сдохнуть и сгореть в аду (могу пояснить на пальцах почему). Можно сказать — типа не хочешь не перегружай, а перегрузил — сам виноват, С++/С# тут не при чём. Но когда делаешь кодеревью джунов и точно знаешь, что там нет перегрузки операторов — жить проще и дышать легче. В противном случае когда видишь оператор "+", откуда взяться уверенности, что ни одному идиоту не пришло в голову его перегрузить? Вкусосвщина? не думаю (с).


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


                                                        А так можно сказать GC тоже вкусовщина, вон выше господин мне доказывает что надо радоваться любому GC, а то я типо сильно разленился. Я знаю людей, которые пол года учились прописывать какой-то дичайший XML с настройками GC jvm и теперь могут как-то там оптимизировать его работу, а тех кто не умеет, считают лохами. Вот с их точки зрения высокопроизводительный GC — вкусовщина


                                                        Что мешает так же класть рядом различные версии библиотек, если это необходимо?

                                                        мешает 1) нежелание манаться с таким зоопарком 2) возможность его не разводить, перейдя на Гоу


                                                        1. franzose
                                                          08.08.2017 13:41
                                                          #10348772
                                                          +2

                                                          Надеюсь не надо объяснять, почему те люди, которые ввели эту синтаксическую опцию в С++, должны сдохнуть и сгореть в аду (могу пояснить на пальцах почему).

                                                          Если бы это не было так удобно, это бы и не добавили.


                                                          Интересно, почему же те же игры пишут не на вашем любимом Гошечке, а на всё тех же плюсах или C#?


                                                        1. vintage
                                                          08.08.2017 13:54
                                                          #10348800
                                                          +3

                                                          могу пояснить на пальцах почему

                                                          Поясните. Я вот ощущаю гораздо больше боли от её отсутствия в некоторых языках.


                                                          Но когда делаешь кодеревью джунов и точно знаешь, что там нет перегрузки операторов

                                                          А в чём проблема увидеть перегрузку оператора? Или вы ревьюите лишь каждую 10 строчку? :-)


                                                          Другой пример — эксепшены, особенно когда они часть АПИ каких нибудь внешних зависимостей.

                                                          Их вы тоже не умеете готовить?


                                                          1. AndreyRubankov
                                                            08.08.2017 15:12
                                                            #10349014
                                                            -2

                                                            Поясните. Я вот ощущаю гораздо больше боли от её отсутствия в некоторых языках.
                                                            Я не знаю позицию почему это не нравится pawlo16, но в том, что это не самая лучшая фича, я с ним полностью согласен.

                                                            Это крутая фича, она позволяет сократить код и позволяет сделать его «красивее» для некоторых очень узких задач. Но, когда вопрос заходит про поддержку проекта, тут начинается боль. Оператор + может быть перегружен несколькими способами и то, какой из них будет вызван, зависит от порядка операндов, если они отличаются по типу.

                                                            Это увеличивает количество возможных путей выполнения кода и количество нюансов при написании и поддержке.

                                                            лично мое мнение: язык должен быть таким, чтобы проект на нем можно было легко поддерживать, т.к. большую часть жизни проекта занимает фаза поддержки.
                                                            Да, вывести продукт на рынок как можно быстрее – это очень важно, но обеспечивать легкую поддержку на протяжении его жизни, – это еще важнее.


                                                            1. vintage
                                                              08.08.2017 15:56
                                                              #10349144
                                                              +4

                                                              Оператор + может быть перегружен несколькими способами и то, какой из них будет вызван, зависит от порядка операндов, если они отличаются по типу.

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


                                                              1. AndreyRubankov
                                                                08.08.2017 16:07
                                                                #10349172
                                                                -2

                                                                Да, я не отрицаю этого. Но согласитесь, что без этой «замечательной» особенности поддержка становится проще.

                                                                На счет функций, немного проще: тут есть есть правило хорошего стиля – не использовать одинаковый порядок параметров внутри одного класса / библиотеки.

                                                                А на счет операторов — тут сложнее. тут все зависит от того, как каждый из классов реализует свою логику перегрузки: т.е. смотреть уже нужно будет сразу в нескольких местах.


                                                                1. vintage
                                                                  08.08.2017 16:31
                                                                  #10349232
                                                                  +3

                                                                  Но согласитесь, что без этой «замечательной» особенности поддержка становится проще.

                                                                  Не соглашусь. Операторы позволяют писать выразительный код. Иначе бы их в языке не было изначально.


                                                                  все зависит от того, как каждый из классов реализует свою логику перегрузки: т.е. смотреть уже нужно будет сразу в нескольких местах.

                                                                  Функции тоже можно перегрузить в разных местах. Почему вызов a+b у вас вызывает сложности, а эквивалентный ему a.add( b ) или даже add( a , b ) не вызывает?


                                                                  1. AndreyRubankov
                                                                    08.08.2017 17:40
                                                                    #10349488

                                                                    Для математических операций – это отлично подходит, не спорю.

                                                                    А вот когда начинают переопределять операторы просто, потому, что это прикольнее выглядит – это уже не особо круто, по-моему.

                                                                    dispatcher += listener;

                                                                    dispatcher.addListener(listener);

                                                                    по-моему второй вариант выглядит понятнее, чем первый.

                                                                    Оно может быть и будет понятнее со временем (человек привыкает ко всему), но по началу это будет выглядеть очень дико.

                                                                    А если учесть, что так пишутся и другие API, типа «клево же», то эта фича принесет больше вреда, чем пользы.

                                                                    Хороший код должен вызывать минимум удивления и минимум WTF?


                                                                    1. vintage
                                                                      08.08.2017 17:53
                                                                      #10349512
                                                                      +1

                                                                      А вот когда начинают переопределять операторы просто, потому, что это прикольнее выглядит

                                                                      Ну то есть проблема не в инструменте, а в голове. Такая голова любым инструментом себе ногу отстрелит.


                                                                      А так и прикольно выглядит и понятно:


                                                                      dispatcher.listeners ~= listener;


                                                                      1. TheShock
                                                                        08.08.2017 18:42
                                                                        #10349634
                                                                        +1

                                                                        А так и прикольно выглядит и понятно:

                                                                        Я сходу не скажу, ваш пример добавляет слушателя или убирает его. С плюсом и минусом контекст, если честно, понятнее.

                                                                        Но вот запрещать перезагрузку операторов, как на меня — зло. У программиста должны быть удобные механизмы, а как ими пользоваться уже должны регламентировать соглашения, а не авторитарное и не всегда удачное мнение создателя языка ограниченного языка.


                                                                      1. AndreyRubankov
                                                                        08.08.2017 18:54
                                                                        #10349656

                                                                        Ну то есть проблема не в инструменте, а в голове. Такая голова любым инструментом себе ногу отстрелит.

                                                                        – пример взят из опыта работы с .NET, и вот даже в документации есть:
                                                                        https://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx

                                                                        А так и прикольно выглядит и понятно:

                                                                        ~ – Побитовая инверсия, это унарный оператор.
                                                                        ~= – такого не существует (по крайней мере в Си).

                                                                        вот так было бы правильнее:
                                                                        dispatcher.listeners |= listener;
                                                                        Но это требует неплохой подготовки для понимания. Сейчас далеко не все разбираются в побитовых операциях.

                                                                        Но вот с удалением тогда не получится так просто и красиво.


                                                                        1. TheShock
                                                                          08.08.2017 19:04
                                                                          #10349672

                                                                          Ну OR как «addUnique» подходит, а какой побитовый оператор тогда подходит под «removeIfExists»? NOT — с натяжечкой, это ведь инверсия и применяется к одному оператору, а не к двум, XOR и AND логично вообще не подходят.


                                                                        1. mayorovp
                                                                          08.08.2017 20:23
                                                                          #10349802
                                                                          +1

                                                                          В C# для делегатов и событий операторы += и -= являются частью языка, а не какой-то пользовательской перегрузкой. Их надо просто знать.


                                                                        1. vintage
                                                                          09.08.2017 00:24
                                                                          #10350146

                                                                          – пример взят из опыта работы с .NET, и вот даже в документации есть:
                                                                          https://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx

                                                                          Это говорит лишь о том, что в МС есть как светлые, так и не очень светлые головы.


                                                                          ~= – такого не существует (по крайней мере в Си).

                                                                          В D это оператор присоединения.


                                                                          вот так было бы правильнее:

                                                                          Ну нет, операция явно не битовая.


                                                                    1. 0xd34df00d
                                                                      08.08.2017 19:54
                                                                      #10349766

                                                                      А когда пишут f <$> c, чтобы применить функцию к некоторому «контейнеру»? Или fc <*> vc, чтобы взять функцию из контейнера fc и применить её к значению в контейнере vc? Или f $! a, чтобы строго, а не лениво применить функцию?


                                                                      1. AndreyRubankov
                                                                        08.08.2017 20:16
                                                                        #10349798

                                                                        По-моему, вы промазали с комментом. Я не агитировал ни за какой язык в этом треде. А то, что вы написали для меня вообще крайне дико выглядит. Уж извините, но я лишь выразил мысль, что перегрузка операторов – это фича которая усложняет понимание и последующую поддержку кода в случаях, когда используется для «это прикольно выглядит».

                                                                        И в реальности перегрузка операторов нужна лишь в крайне редких случаях.


                                                                        1. 0xd34df00d
                                                                          08.08.2017 21:03
                                                                          #10349860

                                                                          Да не, я вам писал :)

                                                                          Там не перегрузка операторов, там добавление своих новых операторов. Называть их по имени было бы очень некрасиво, получалось бы что-то вроде

                                                                          Options `fmap` param1 `sequenceApplicative` param2 `sequenceApplicative` param3 ...

                                                                          даже с инфиксной возможностью записи функций. Как бы оно выглядело с префиксной — это вообще адище.


                                                          1. pawlo16
                                                            08.08.2017 15:12
                                                            #10349016
                                                            -3

                                                            Ладно, вот почему перегрузка операторов — один из самых лютых грехов в программировании. Сравните, что проще для понимания:


                                                            status unionGrids(Grid a, Grid b, Grid *result) {
    Grid tmp;
    try {
        tmp = a+b;
    }
    catch (...) {
        return error(...);
    }
    *result = tmp.foo();
    return status.success;
}

                                                            или


                                                            status unionGrids(Grid a, Grid b, Grid *result) {
    status rv;
    Grid tmp = a.unionWith(b, &rv);
    if (rv != success) {
        return rv;
    }
    *result = tmp.foo();
    return status.success;
}

                                                            В коде с перегруженным "+" нет нормальной передачи ошибок, и из строки "tmp = a+b" сложно понять, что этот код делает на самом деле. Когнитивная нагрузка на понимание смысла имени метода "unionWith" на много ниже, чем на "+" между объектами типа Grid. А если оператору нужно передать больше 2-3 параметров, его вызовы смешивают с обычными функциями и методами, либо как в scala добавляют spaceship operator-ы. В обоих случаях получится запутанный говнокод.


                                                            Есть несколько исключений из матана ( комплексные чисела, матрицы и т.п.) для которых перегрузка операторов выглядит естественной. Но такую перегрузку легко реализовать на уровне ЯП, не давая программистам поганить код собственными вариантами. Например, Go поддерживает комплексные числа, в 2.0 обещали матрицы.


                                                            А в чём проблема увидеть перегрузку оператора? Или вы ревьюите лишь каждую 10 строчку? :-)

                                                            странный вопрос. По моему всем ясно, что из контекста "a+b" не очевидно, осуществляется ли вызов перегруженного оператора или стандартного оператора сложения над числами. Чтобы это понять, надо проверить, а не перегружен ли где-то там оператор "+"


                                                            Их вы тоже не умеете готовить?

                                                            Из того факта, что нечто вызывает у имярека желание сблевать, логически не следует, что имярек не умеет его готовить. Логично? Благодаря эксепшенам в С++ приходилось тратить уйму времени и сил, чтобы спроектировать элегантный exception-safe код. Обычно получалось либо элегантно, либо exception-safe, но не одновременно. Поэтому 99% программ на C++ содержат миллион неявных косяков, связанных с exception safety. И когда функция с помощью эксепшенов передаёт вызывающему коду результаты своей работы, пользоваться ей — сплошная мука в сравнении с кодом, который явно возвращает ошибку как результат, а не ломает control flow


                                                            1. Free_ze
                                                              08.08.2017 15:43
                                                              #10349100

                                                              И когда функция с помощью эксепшенов передаёт вызывающему коду результаты своей работы

                                                              Функция не должна передавать через эксепшны результаты работы. Название намекает, что это не ожидаемое поведение, ломающее логику вызываемой функции, то есть корень зла не внутри, а снаружи, это лишь «стопкран».


                                                            1. mayorovp
                                                              08.08.2017 15:44
                                                              #10349102
                                                              +1

                                                              Оба приведенных фрагмента кода — ужасны. В хорошем проекте такого метода вообще не должно быть.


                                                            1. vintage
                                                              08.08.2017 16:18
                                                              #10349194

                                                              Когнитивная нагрузка на понимание смысла имени метода "unionWith" на много ниже, чем на "+" между объектами типа Grid.

                                                              В нормальный языках для "сложения" и "соединения" используются разные операторы:


                                                              1 + 2 == 3
[ 1 ] ~ [ 2 ] == [ 1 , 2 ]

                                                              Да, за нарушение семантики оператора, как и за несоответствие названия функции её действиям, нужно бить по рукам.


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

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


                                                              странный вопрос. По моему всем ясно, что из контекста "a+b" не очевидно

                                                              То есть объявление перегрузки оператора вы не ревьюите?


                                                              Благодаря эксепшенам в С++ приходилось тратить уйму времени и сил, чтобы спроектировать элегантный exception-safe код.

                                                              Пример приведёте?


                                                              1. pawlo16
                                                                09.08.2017 16:45
                                                                #10351644
                                                                -1

                                                                То есть объявление перегрузки оператора вы не ревьюите?

                                                                проверяю, но мне от этого больно, поскольку нужно уточнять тип операндов и проверять наличие перегрузки оператора. В Гоу на строчку "a+b" ни то ни другое делать не нужно и мне от этого хорошо.


                                                                Пример приведёте?

                                                                Любой код с try catch. Если эксепшен часть апи, то это на самом деле результат вызова апи. Нет ни каких оснований ломать поток выполнения при его появлении кроме намеренного усложенения вызывающего кода


                                                            1. 0xd34df00d
                                                              08.08.2017 20:08
                                                              #10349790
                                                              +3

                                                              В коде с перегруженным "+" нет нормальной передачи ошибок, и из строки «tmp = a+b» сложно понять, что этот код делает на самом деле.

                                                              А что такое Grid и что делает объединение, что у него может быть ошибка?

                                                              либо как в scala добавляют spaceship operator-ы. В обоих случаях получится запутанный говнокод.

                                                              Я не знаю, что за spaceship operator'ы в скале, ибо не очень знаю скалу, но если это, судя по контексту, как аппликативные функторы в хаскеле, то там на самом деле всё довольно просто, понятно и, что самое главное, композабельно.

                                                              Как в Go применить функцию частично?

                                                              Например, Go поддерживает комплексные числа, в 2.0 обещали матрицы.

                                                              А дуальные числа когда добавят?

                                                              По моему всем ясно, что из контекста «a+b» не очевидно, осуществляется ли вызов перегруженного оператора или стандартного оператора сложения над числами.

                                                              Перегрузить операторы для лишь скалярных типов нельзя. Вы не можете написать свой operator+, который принимает два float'а, скажем.

                                                              И когда функция с помощью эксепшенов передаёт вызывающему коду результаты своей работы, пользоваться ей — сплошная мука в сравнении с кодом, который явно возвращает ошибку как результат, а не ломает control flow.

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


                                                        1. Lofer
                                                          08.08.2017 14:05
                                                          #10348822
                                                          +1

                                                          Надеюсь не надо объяснять, почему те люди, которые ввели эту синтаксическую опцию в С++, должны сдохнуть и сгореть в аду (могу пояснить на пальцах почему).

                                                          CodeStyle & Design guide определите для проекта и будет вам счастье.

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

                                                          А тут что не так или библиотеки не должны «материться» если вы в них пихаете всякую дрянь? :) Как еще библиотека скажет, что «у вас золотые руки, но от бедер растут потому что....»?


                                                        1. Free_ze
                                                          08.08.2017 14:06
                                                          #10348824

                                                          а горутины — это по вашему вкусовщина, прикольная фишка, или конструктивный шах и мат C# господам

                                                          Это прикольная фишка Golang, но не недостаток C#. Мне кажется, что эта штука рано или поздно и в .NET-мире появится.

                                                          /* про перегрузку операторов */… Вкусосвщина?

                                                          Да, причем из «палаты мер и весов».

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

                                                          И тоже не вкусовщина, да?)

                                                          А так можно сказать GC тоже вкусовщина, вон выше господин мне доказывает что надо радоваться любому GC, а то я типо сильно разленился.

                                                          Вы сами писали, что для .NET его надо тюнить. Тут я признаю, что разные стратегии работы с памятью могут в конкретной задаче давать различные результаты.

                                                          Что мешает так же класть рядом различные версии библиотек, если это необходимо?
                                                          мешает 1) нежелание манаться с таким зоопарком 2) возможность его не разводить, перейдя на Гоу

                                                          1) да вы 2) же 3) ни дня 4) не писали 5) на .NET, признайтесь сейчас же! (=

                                                          Для использования закрытых сборок вам не нужно делать ничего. То есть вообще ничего, это дефолтное поведение.
                                                          Статическая линковка может из многих файлов сделать один (хотя, ничто не мешает в .NET собирать чужие модули в свою сборку) и дать возможность компоновщику выкинуть неиспользуемый код.


                                                          1. pawlo16
                                                            08.08.2017 16:47
                                                            #10349296
                                                            -2

                                                            Мне кажется, что эта штука рано или поздно и в .NET-мире появится.

                                                            Да, я тоже так считаю. Рано или поздно до микров дойдёт, что программисты в массе своей слишком тупы, чтобы правильно расставлять async/await. Как до г-на Одерски дошло, что implicit conversions — грех. Со временем он поймет то же самое о наследовании, перегрузке операторов и других бесполезных фичах scala. Дураки учатся на своих ошибках. Давайте будем учится на чужих прямо сейчас, не дожидаясь, пока добрые дяди соизволят подвести легковесные потоки в .net! Ну и судя по road map пока что это светлое будущее .net весьма иллюзорно, и .net господам приходится довольствоваться маргинальщиной наподобие hopac в F#


                                                            1) да вы 2) же 3) ни дня 4) не писали 5) на .NET, признайтесь сейчас же! (=

                                                            здесь я утратил нить разговора. видимо кто-то из нас кого-то недопонял


                                                            Для использования закрытых сборок вам не нужно делать ничего. То есть вообще ничего, это дефолтное поведение.

                                                            меня очень печалит dll из закрыой сборки, весящая 20-30 МБ, из которой я использую реального кода максимум пару Кб.


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

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


                                                            1. mayorovp
                                                              08.08.2017 17:23
                                                              #10349430

                                                              А что не так этим файлом-то?


                                                            1. Free_ze
                                                              08.08.2017 17:25
                                                              #10349442
                                                              +1

                                                              меня очень печалит dll из закрыой сборки, весящая 20-30 МБ, из которой я использую реального кода максимум пару Кб.

                                                              Может тогда стоит просто писать маленькие сборки?

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

                                                              Зачем это вообще может понадобиться?) Весь мир стремится к модуляризации, а гошечкины фанаты радуются монолитности.
                                                              Ну, ОК, такая возможность есть, осталась единственная проблема: лично вам не нравятся инструменты от MS (=


                                                              1. pawlo16
                                                                08.08.2017 20:01
                                                                #10349774
                                                                -1

                                                                Может тогда стоит просто писать маленькие сборки?

                                                                скажите это парням и Редмонда и авторам популярных nuget пакетов. Впрочем у минимизации бинарной сборки для .net есть и обратная сторона — на каждый чих надо тащить десяток пакетов, каждый из которых отдельно просит есть и прописывается в дичайших конфигах, а не в исходниках, как это сделано в Go, после года программирования на котором от размеров бинарников и содержимого конфига asp net core глаза начинают кровоточить, а к горлу подступает тошнота


                                                                гошечкины фанаты радуются монолитности.

                                                                не знаю чему там радуются фанаты, но я такого ни разу не видел. Проект на гошечке состоит из независимых микро(нано!)пакетов, которые при деплое собираются в корневую папку vendor


                                                                лично вам не нравятся инструменты от MS (=

                                                                Вряд ли тут дело в моей привередливости и предвзятости. Покажите мне хотя бы одного человека, который после 100 kLOC на Go и C# скажет, что тулчейн гошечки плохой, а большая VS, msbuild и nuget — это не говно говно говно…


                                                                1. Lofer
                                                                  08.08.2017 20:27
                                                                  #10349804
                                                                  +2

                                                                  а большая VS, msbuild и nuget — это не говно говно говно…

                                                                  Msbuild — это вообще-то только движок, в который можно засунуть что угодно. сделайте свои Action и он будет вам играть имперский марш при ошибке билда.
                                                                  nuget — это просто механизм доставки пакетов из репозитария. К компиляции проектов или вообще не имеет никакого отношения.

                                                                  Если у вас нет желания расширить и контролировать сборку проектов своим инструментарием — то не будет вам от него счастья. За лет 15 ковырялся в нем раза 4. На все ушло часов 80, один раз из любопытства, один раз "«сам дурак», два раза расширял цепочку своими операциями ибо не тривиальные вещи нужно было сделать. Остальное время — я по него и не помнил. Не мешай технике работать.

                                                                  Проект на гошечке состоит из независимых микро(нано!)пакетов, которые при деплое собираются в корневую папку vendor

                                                                  A .Net проект как по вашему собирается? Посмотрел проект для Sharepoint — dll от 50 до 350 кб
                                                                  для .Net Web проектов перекинуть dll размером в 10 kb… 2 mb на ходу что бы зафиксить баг или добавить новую фичу — это норма.

                                                                  Может тогда стоит просто писать маленькие сборки?
                                                                  скажите это парням и Редмонда и авторам популярных nuget пакетов.

                                                                  Nuget это несколько dll на все случаи жизни и версии .Net что программер сделал.
                                                                  Вы рассказываете такие страшные и странные вещи, которые .Net даже в 2001 году в альфа версии не делал. Откуда у вас эти все страшилки?


                                                                  1. grossws
                                                                    08.08.2017 21:05
                                                                    #10349864

                                                                    Вы рассказываете такие страшные и странные вещи, которые .Net даже в 2001 году в альфа версии не делал. Откуда у вас эти все страшилки?

                                                                    Скорее всего, оттуда же, откуда тайное знание о конфигурирования jdk'шного gc xml-ками. От незнания.


                                                                  1. pawlo16
                                                                    08.08.2017 22:16
                                                                    #10349978

                                                                    Да хрен там. Не рассказывайте сказки, я это все в хвост и в гриву мучаю уже 10 лет и немножко знаю, насколько там всё плохо. Например открываешь чистенький .csproj в студии — и оно тебе дописывает туда всякого говна типа ссылок на c:\program files, которые есть только у людей со студией. Вообще, msbuild, а особенно прилагающиеся скрипты для include — которые студия любит всовывать самостоятельно — это полный треш и угар. Там у них даже задача лежит секретная — где-то там в program files — которая позволяет в msbuild совать куски C#-кода. Если делать ссылки на GAC, или не держать все компоненты под контролем версий рядом с проектом, или иногда вносить в проекты нечто, что может как-то помешать собирать их на чистой машине без плясок с бубном — очень быстро садишься на шишку msbuild. Элементарно разобраться "как msbuild ищет исходники" — задача не тривиальная. nuget такой же галимый, периодичсеки ломает конфиги при обновлении зависимостей. У меня даже была мысль отказаться от него в пользу маргинального paket, настолько всё достало. А в гошечке никаких аналогов nuget и msbuild нет и не нужно прописывать зависимости, конфигурировать проект и думать о том, как гарантировать нормальную сборку, вы понимаете? чувствкете разницу? А для кастомизации билда используется стандартный, хорошо всем знакомый make/cmake — вписал в требования "запустите apt-get install чего нибудь" и все.


                                                                    проект для Sharepoint — dll от 50 до 350 кб

                                                                    И каков общий объём бинарников и процент мёртвого байт-кода в них?


                                                                    1. Lofer
                                                                      08.08.2017 22:42
                                                                      #10350034
                                                                      +1

                                                                      Да хрен там. Не рассказывайте сказки, я это все в хвост и в гриву мучаю уже 10 лет и немножко знаю, насколько там всё плохо. Например открываешь чистенький .csproj в студии — и оно тебе дописывает туда всякого говна типа ссылок на c:\program files, которые есть только у людей со студией.

                                                                      И причем тут язык к инфраструктуре и инструментарию? C# вообще никуда ничего не пишет. у него есть .cs файл с кодом. на все остальное ему плевать.
                                                                      Не нравится студия — не пользуйте. Ecma-334 и Ecma-335 в руки и вперед к приключениям. Делайте идельную тулзу.
                                                                      Вообще, msbuild, а особенно прилагающиеся скрипты для include — которые студия любит всовывать самостоятельно — это полный треш и угар.

                                                                      Рекомендовал бы почитать «еще глубжее матчасть». А можно просто попросить MSBuild сгенерить полный лог. Там все сразу понятно что и откуда берется и «а хто энта сделал?!».
                                                                      Пока все косяки что были при сборке (на моей памяти), это от рукожопости и не способности следовать правилам откуда что тягать в проект и куда складывать. Как только всем раздать люлей, все чудесным образом годами живет без косяков и отлично собирается и локально и билд серверами.
                                                                      Обычно хватает одного раза на команду и на всю жизнь.
                                                                      Может вспомнить правило инженера? Если ничего не помагает, прочти наконец инструкцию.


                                                                      1. pawlo16
                                                                        08.08.2017 23:23
                                                                        #10350090
                                                                        -1

                                                                        И причем тут язык к инфраструктуре и инструментарию?

                                                                        Да никому даром никакой язык не нужен без инфраструктуры. Никто уже давно не воспринимает язык отдельно от платформы. Ну кроме студентов, хелувордистов, фибоначистов и маструбаторов на трихомонады. Erlang без OTP? Ruby без Rails? Конечно речь об экосистеме. Я очень рад, что с пятого раза вы приблизились к пониманию моего тезиса, что у гошечки с инфраструктурой всё прекрасно, в .net — полная жопа, когда дело касается бэкенда.


                                                                        Пока все косяки что были при сборке (на моей памяти), это от рукожопости и не способности следовать правилам откуда что тягать в проект и куда складывать.

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


                                                                        А можно просто попросить MSBuild сгенерить полный лог. Там все сразу понятно что и откуда берется и «а хто энта сделал?!».

                                                                        Уровень тупизма этого совета превосходит все мыслимые пределы, простите. Всё равно что посоветовать внимательнее читать стектрейс и использовать отладчик. У меня — внезапно — достаточно знаний, чтобы понять что делает msbuild без подобных советов. Я ни разу не сказал что не могу этого сделать в принципе. Вопрос в том, что моё время и нервы, которые уходят на решение подобных проблем с msbuild, не пять копеек стоит, и у меня есть для этого лучшее применение. Вам должно быть стытдно, что мне приходится объяснять вам такие элементарные и очевидные вещи.


                                                                        1. 0xd34df00d
                                                                          08.08.2017 23:42
                                                                          #10350106
                                                                          +3

                                                                          Ну кроме студентов, хелувордистов, фибоначистов и маструбаторов на трихомонады.

                                                                          У фибоначистов и маструбаторов на трихомонады, кстати, есть офигительнейший stack (от тусовки с забавным названием Commercial Haskell). Там и reproducible builds, и добавление зависимостей одним токеном в .cabal-файле, и встроенное профилирование, покрытие кода, тесты и все остальные ништяки, и вообще приятно писать.

                                                                          А в ghc 8.2 ещё и хорошую модульную систему завезли.


                                                                          1. pawlo16
                                                                            09.08.2017 00:34
                                                                            #10350152
                                                                            -3

                                                                            ну прям ми-ми-ми. Ну теперь то у них попрёт софт уровня Etcd, Serf, Consul, Docker, Dl.google.com, Kubernetes, а не только факториал, подвешивающий комп… стоп. stack уже давно, а софт не попёр, даже унылый опердень не могут наваять. упс.


                                                                            1. 0xd34df00d
                                                                              09.08.2017 01:08
                                                                              #10350196
                                                                              +5

                                                                              Ну теперь то у них попрёт софт уровня Etcd, Serf, Consul, Docker, Dl.google.com, Kubernetes

                                                                              То вам утилиты подавай, то в опенсорс выкладывай продакшен-код. Вы уж определитесь, что вам надо в вашей аргументации.

                                                                              а не только факториал, подвешивающий комп…

                                                                              А, мы мифами общаемся? Как там, клавиатура у вас не развалилась ещё от ритуального набивания if err return err? Или вы специальную внешнюю аддон-кнопку купили для этой конструкции?

                                                                              а софт не попёр, даже унылый опердень не могут наваять. упс.

                                                                              А вы ту статью-то читали? Я не увидел, где там у кого что не попёрло, если честно, можете меня носом тыкнуть, если не затруднит?


                                                                              1. pawlo16
                                                                                09.08.2017 14:35
                                                                                #10351202
                                                                                -2

                                                                                То вам утилиты подавай, то в опенсорс выкладывай продакшен-код. Вы уж определитесь, что вам надо в вашей аргументации.

                                                                                какой ещё опенсорс? Мне ничего не надо. Это вы что-то хотели сказать историей про stack, видимо что он решил проблему маргинальности и пракической бесполезности хаскеля и позволил писать на нём приложения, аналогичные по пользе и популярности тем, что я упомянул. Иначе это было очередное бла-бла-бла ни о чём.


                                                                                у вас не развалилась ещё от ритуального набивания if err return err?

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


                                                                                Ну вот например про то, как типичный опердень умучает рантайм хаскеля:


                                                                                A common performance problem is that of many small updates updates to records with large numbers of fields. Records of hundreds of fields are somewhat pathological but in practice they show up in a lot of business logic that needs to interact with large database rows. Too much of this can very noticeable impact on GC pressure by doing allocations on each update.

                                                                                То есть рекорды в хаскеле невменяемые в целом, лежат у них плоскими в памяти и каждый раз при апдейте их надо клонировать. По хорошему для моделирования сущностей БД нужно заменить их на мапы и прочие словари с деревом в кишках реализации, что конечно же ни кто делать не будет — проще выкинуть хаскель и использовать ЯП с нормальными мутабельными рекордами. Например Гоу


                                                                                1. 0xd34df00d
                                                                                  10.08.2017 00:43
                                                                                  #10352772
                                                                                  +1

                                                                                  Это вы что-то хотели сказать историей про stack, видимо что он решил проблему маргинальности и пракической бесполезности хаскеля и позволил писать на нём приложения, аналогичные по пользе и популярности тем, что я упомянул.

                                                                                  Для опровержения практической бесполезности достаточно наличия случаев с практической полезностью. У меня таковые случаи есть, вот конкретно в моей разработческой практике. И я там, уж поверьте, не только факториалы считал.

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

                                                                                  Чем функторы и аппликативные функторы чужды программисту? Это можно осознать за час. Хотя тут, конечно, можно снова вспомнить про целевую аудиторию Go.

                                                                                  А вообще, так можно дойти до того, что возвращать сразу несколько значений из функции — слооооожна, надо делать в стиле С, return code и out-параметр (ну или наоборот).

                                                                                  То есть рекорды в хаскеле невменяемые в целом, лежат у них плоскими в памяти и каждый раз при апдейте их надо клонировать.

                                                                                  Вы сделали патологически неправильный вывод, что ещё от фаната ждать.

                                                                                  Хаскель — ленивый язык по умолчанию, рекорды там не плоские, клонировать их целиком не надо, а апдейты дешёвые, но невычисленный апдейт лежит в памяти невычисленным же thunk'ом, что дорого, для мелкого апдейта — дороже, чем тупо вот прям здесь его выполнить. Лечится постановкой восклицательного знака перед типом в рекорде, жаль, что автору про это не рассказали.


                                                                                  1. pawlo16
                                                                                    10.08.2017 20:57
                                                                                    #10354984
                                                                                    -4

                                                                                    Для опровержения практической бесполезности достаточно наличия случаев с практической полезностью

                                                                                    Нет. Практически полезные инструменты облегчают разработку, а хаскель только усложняет. Ваш личный опыт ни чего не доказывает вообще, поскольку я тоже программировал на хаскеле в касперском и у меня есть все основания считать хаскель бесполезным. Имеем моё мнение против вашего с одной стороны, и объективные данные, которые говорят о том что хаскель мёртвый язык, который почти ни где не применяется за редким исключением в отличие от Гоу, который решает проблемы и приносит успех на рынке практически всем, кто его использует.


                                                                                    Ну и следуя вашей инфантильной логике, что хаскель хорош уже тем что вы на нём пишете, можно было бы сделать вывод, что любой говноязык и говнофреймворк хорош включая самое дно php, nodejs, только потому, что на них внезапно тоже кто-то что-то программирует, что есть смешной абсурд


                                                                                    Чем функторы и аппликативные функторы чужды программисту?

                                                                                    Очевидно тем, что они бесполезны. Единственные не очень удачные костыли, позволяющие кое-как использовать функциональщину в практических задачах — монады. Функиональные языки программирования вообще плохо подходят для решения большинства real world задач


                                                                                    Хотя тут, конечно, можно снова вспомнить про целевую аудиторию Go.

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


                                                                                    А вообще, так можно дойти до того, что возвращать сразу несколько значений из функции — слооооожна

                                                                                    Для вас наверное можно. Гоу быстро учит не кидаться в крайности и использовать самое рациональное решение, которое зачастую единственно правильное.


                                                                                    рекорды там не плоские, клонировать их целиком не надо, а апдейты дешёвые, но невычисленный апдейт лежит в памяти невычисленным же thunk'ом, что дорого, для мелкого апдейта

                                                                                    Не гоните беса. Вижу вы даже не нюхали продовый опердень, а всё туда же — учите тех, кому за это платят. Не видя код, сделали вывод что вам одному пришла в голову банальная мысль сделать вычисления строгими. Считаете себя умнее автора статьи? очень типично для программистов на хаскеле. Рекорды там абсолютно плоские и ни какие санки-шманки на это ни каким боком не влияют. И об этом в статье идёт речь. Если бы вы хоть раз в жизни запустили профайлер и внимательно на них посмотрели, убедились бы в этом сами. Для хелуворда ведь профилирование не требуется, не так ли?


                                                                                    1. VolCh
                                                                                      10.08.2017 21:57
                                                                                      #10355074
                                                                                      +4

                                                                                      в отличие от Гоу, который… приносит успех на рынке практически всем, кто его использует.

                                                                                      Сильно попахивает ошибкой выжившего. Вы уверены, что практически ни одна компания, использующая Go ни то, что не обанкротиалсь, а даже не пожалела о решении начать его использование, поддавшись гуглохайпу?


                                                                                      1. pawlo16
                                                                                        10.08.2017 23:01
                                                                                        #10355214
                                                                                        -4

                                                                                        Уверен что есть и такие, но я не видел. Ни один ЯП не даст 100% ной гарантии успеха, слишком много всего влияет. Зато видел лично и читал десятки историй факапов на скала и нодежс от тех, кто наелся этих веществ по самые помидоры.


                                                                                        Гоу используется в продакшене как минимум ни меньше этих горе-языков, но почему то от него ни кто громко не плачет кроме тех, кто его нормально не пробовал. Может предпочитают помалкивать о факапах на Гоу потому, что понимают, что язык ни при чём?


                                                                                        Хейтеры Гоу, умеющие в Гоу, (абсолютное меньшинство, обычно не умеют) не собираются от него отказываться — это говорит о многом. А от скалы и нодежс бегут сломя голову.


                                                                                    1. franzose
                                                                                      10.08.2017 23:51
                                                                                      #10355284
                                                                                      +1

                                                                                      включая самое дно php

                                                                                      Ваши заявления чем-то подкреплены? PHP в начале своего развития был не очень, а сейчас это мегапопулярный язык, который активно развивается благодаря сообществу, а не какому-то конкретному вендору. На его основе сделана куча неплохих фреймворков. Да, на нём драйвер по ОСь не напипешь, ну так у него вполне конкретная ниша.


                                                                                    1. 0xd34df00d
                                                                                      11.08.2017 02:27
                                                                                      #10355394
                                                                                      +3

                                                                                      Вы какой-то агрессивный, это всё от Go.


                                                                                      Ваш личный опыт ни чего не доказывает вообще, поскольку я тоже программировал на хаскеле в касперском и у меня есть все основания считать хаскель бесполезным.

                                                                                      А я смотрел на Go дома, и считаю его бесполезным. Что теперь?


                                                                                      Имеем моё мнение против вашего с одной стороны, и объективные данные, которые говорят о том что хаскель мёртвый язык, который почти ни где не применяется

                                                                                      Какая разница, где он применяется? С чего бы язык мёртвый, если библиотек под него порядком, для всего, что мне было нужно, и что разумно ожидать в библиотеке, таковая библиотека была?


                                                                                      который решает проблемы и приносит успех на рынке практически всем, кто его использует

                                                                                      Мне конкретно в моей практике хаскель решает проблемы и приносит успех, что я делаю не так?


                                                                                      inb4 пишу одни фибоначчи


                                                                                      любой говноязык и говнофреймворк хорош включая самое дно php, nodejs, только потому, что на них внезапно тоже кто-то что-то программирует, что есть смешной абсурд

                                                                                      Но для гов Go вы используете ровно этот аргумент!


                                                                                      Единственные не очень удачные костыли, позволяющие кое-как использовать функциональщину в практических задачах — монады.

                                                                                      Лол.


                                                                                      Практически любое выражение в do-нотации переписывается через аппликативные функторы без всяких проблем. Единственное, что отличает аппликативный функтор от монады — в аппликативном функторе вы не можете изменить эффект в зависимости от значения (сделать Nothing из Maybe Int, если там лежит 5, например), потому что вы возвращаете не целый эффект, а новую функцию, которую надо будет обернуть, и всё.


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


                                                                                      Функиональные языки программирования вообще плохо подходят для решения большинства real world задач

                                                                                      Решаю на нём уйму задач, от парсинга и реплея логов до написания компиляторов, что я делаю не так?


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

                                                                                      Это какие-то неправильные учёные, попробуйте познакомиться с кем-то более адекватным.


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

                                                                                      Ну да, я вообще в подвале у родителей живу, денег за хаскель-то не плотют!


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

                                                                                      Не вычисление, а поле.


                                                                                      Рекорды там абсолютно плоские и ни какие санки-шманки на это ни каким боком не влияют.

                                                                                      Где — там? В хаскеле? Только если вы напишете перед вместо каждого foo что-то вроде {-# UNPACK #-} !foo, либо сделаете {-# LANGUAGE Strict #-}, либо strictness analyzer решит, что поле имеет смысл сделать строгим, и при дальнейших оптимизациях оно будет распаковано (и с этим можно бороться тильдой, кстати).


                                                                                      И об этом в статье идёт речь. Если бы вы хоть раз в жизни запустили профайлер и внимательно на них посмотрели, убедились бы в этом сами.

                                                                                      Запускал и убеждался, что я делаю не так?


                                                                                      Для хелуворда ведь профилирование не требуется, не так ли?

                                                                                      Для срача в комментах ведь фактическая корректность не требуется, не так ли? Свои го-фанаты и так схавают, а что остальные подумают — а и не важно.


                                                                                      1. pawlo16
                                                                                        12.08.2017 15:26
                                                                                        #10358128
                                                                                        -2

                                                                                        хаскель мёртвый язык, который почти ни где не применяется
                                                                                        Какая разница, где он применяется?

                                                                                        Выбор программистов — самый объективный из показателей качества языка. Если бы хаскель действительно давал какой-то профит, кроме мифического саморазвития за счёт инвесторов, программситы преодолели бы отвращение к костылным концептам хаскеля, изучили бы его и применяли.


                                                                                        любой говноязык и говнофреймворк хорош включая самое дно php, nodejs, только потому, что на них внезапно тоже кто-то что-то программирует
                                                                                        Но для гов Go вы используете ровно этот аргумент!

                                                                                        Вы бредите. На Гоу написаны десятки полезных программ, удовлетворяющих запросам миллионов людей. А на хаскеле — именно кто-то что-то пишет, не более того.


                                                                                        Решаю на нём уйму задач, от парсинга и реплея логов

                                                                                        Напугали ежа голой жопой. Парсеры любой сложности пишуься даже на сишечке с LEX & YACC, не говоря уже о Гоу, в котором это сводится к скучной рутине. Почему всегда, когда нужно хоть как-то оправдять существование хаскеля, вспоминают парсеры? можно подумать в 17-м году для кого-то проблема написать парсер


                                                                                        до написания компиляторов

                                                                                        и много людей используют ваш компилятор?


                                                                                        найти среднее арифметическое без линейного роста затрат памяти. не говоря уже о более сложном
                                                                                        Это какие-то неправильные учёные, попробуйте познакомиться с кем-то более адекватным.

                                                                                        это в касперском, единственной конторе, где программистам платили за хаскель в РФ (уж не знаю платят ли сейчас). Там отборная элита, остальные на много хуже.


                                                                                        Рекорды там абсолютно плоские и ни какие санки-шманки на это ни каким боком не влияют.
                                                                                        Где — там? В хаскеле?...

                                                                                        Да. На каждое изменение любого из полей рекорда данные копирутся из одного блока памяти в другой, что создаёт дичайшую нагрузку на GC.


                                                                        1. Lofer
                                                                          08.08.2017 23:43
                                                                          #10350108

                                                                          Вопрос в том, что моё время и нервы, которые уходят на решение подобных проблем с msbuild, не пять копеек стоит, и у меня есть для этого лучшее применение. Вам должно быть стытдно, что мне приходится объяснять вам такие элементарные и очевидные вещи.

                                                                          В полном билд-логе я ковырялся всего два раза в жизни. Все остальное время у меня не было даже и мысли туда лазить ибо все работало как ожидалось.
                                                                          Мне просто интересно, из проф любопытства, где у Вас так регулярно и упорно возникают такие фатальные проблемы и почему.

                                                                          Что я не так делаю с MsBuild? :)


                                                                          1. pawlo16
                                                                            09.08.2017 13:30
                                                                            #10350956

                                                                            сколько человек у вас работает над проектом и какой у него порядок стоимости?


                                                                            1. Lofer
                                                                              09.08.2017 22:42
                                                                              #10352580

                                                                              сколько человек у вас работает над проектом и какой у него порядок стоимости?

                                                                              До пары миллионов евро-долларов это почти типой проект. Стандартный тим от 5 до 20 человек. Были и десятки миллионов.
                                                                              Были проекты и годами-десятилетиями шли, и команды менялись не по одному разу.
                                                                              Типовая проблема: рукожопы не там взяли — не туда положили. От языка не зависит. От тузлов не зависит.


                                                                        1. TheShock
                                                                          09.08.2017 01:07
                                                                          #10350190
                                                                          +3

                                                                          Да никому даром никакой язык не нужен без инфраструктуры. Никто уже давно не воспринимает язык отдельно от платформы.

                                                                          Лол, тогда непонятно чего вы так агитируете за Go? Вот уж где инфрастуктура пока очень слабая.


                                                                          1. pawlo16
                                                                            09.08.2017 23:18
                                                                            #10352666
                                                                            -1

                                                                            Видимо показателем силы инфраструктуры у вас является


                                                                            • отсутствие стандартных средств для тестирования, замеров производительности и профилирования программ.
                                                                            • зоопарк из несовместимых решений посредственного качества;
                                                                            • стандартная библиотека, переполнененая устаревшим хламом и кучей бесполезных штук, в которой отсутствуют средства, требующиеся в большинстве программ;

                                                                            В этом случае Гоу для вас будет не достаточно хардкорный.и вам надо в какую нибудь джаву или говно-nodejs. Я встречал таких — лечится 2 месяцами строевого программирования на Гоу


                                                                            1. TheShock
                                                                              10.08.2017 04:33
                                                                              #10352896
                                                                              +3

                                                                              Это в Go то есть тулза для тестирования, в которой даже assert'ов нету? Ха-ха. Она вполне в духе языка.

                                                                              Все-равно приходится подключать сторонние либы, чтобы что-то тестировать.

                                                                              И да, я программирую на Гоу уже больше двух месяцев. Пока что больше разочарований от неоправданных ожиданий, чем комфорта. Когда я после 7 лет на JS переходил на C# испытывал противоположные впечатления.

                                                                              — зоопарк из несовместимых решений посредственного качества;

                                                                              Зачем вы описываете мне Go? Вот объясните, почему json парсится через рефлексию и теги, а env переменные при помощи flag — совершенно иначе? Где логика и последовательность? Я уж молчу о том, что эта либа крайне неюзабельна и провоцирует ошибки из-за копипасты. Именно об этом вы говорили, когда писали «несовместимых решений посредственного качества», да?


                                                                              1. pawlo16
                                                                                10.08.2017 21:58
                                                                                #10355076
                                                                                -4

                                                                                каких ещё assert'ов и зачем нужны сторонние либы для тестирования?


                                                                                Вот объясните, почему json парсится через рефлексию и теги, а env переменные при помощи flag — совершенно иначе? Где логика и последовательность?

                                                                                Потому что для flag требуется кастомизация на прикладные структуры данных, реализованная через интерфейс flag.Value, а для json — нет.


                                                                                эта либа крайне неюзабельна и провоцирует ошибки из-за копипасты

                                                                                это либа универсальная и простая как палка. Её назначение — покрытие 90% типовых кейсов. Для оставшихся 10 есть несколько более специализированных сторонних либ высокого качества, я использую launchpad.net/gnuflag в некоторых проектах для линупс-стайл флагов.


                                                                                Именно об этом вы говорили, когда писали «несовместимых решений посредственного качества», да?

                                                                                забавно что вы топите тут за C# в котором в принципе нет даже поддержки json из-за неуклюжих и переусложнённых базовых структур данных языка. Не говоря уже о флагах и тестировании. И в то же псите на гошечку, где это есть из коробки. Говоря о говноинфраструктуре, я имел ввиду отсутствие, маргинальность или кривизну того, что, как я упоминал в другой ветке, есть в Гоу


                                                                                1. Lofer
                                                                                  10.08.2017 22:48
                                                                                  #10355194
                                                                                  +2

                                                                                  Именно об этом вы говорили, когда писали «несовместимых решений посредственного качества», да?

                                                                                  забавно что вы топите тут за C# в котором в принципе нет даже поддержки json из-за неуклюжих и переусложнённых базовых структур данных языка.

                                                                                  Ну и зачем нести чушь ?! Может все таки иногда стоит почитать доументацию?

                                                                                  Data?Contract?Json?Serializer Class
                                                                                  Namespace: System.Runtime.Serialization.Json
                                                                                  Assemblies: System.Runtime.Serialization.Json.dll, System.Runtime.Serialization.dll, netstandard.dll

                                                                                  как пользоваться:
                                                                                  [DataContract]
                                                                                  internal class Person
                                                                                  {
                                                                                  [DataMember]
                                                                                  internal string name;

                                                                                  [DataMember]
                                                                                  internal int age;
                                                                                  }

                                                                                  Person p = new Person();
                                                                                  p.name = "John";
                                                                                  p.age = 42;

                                                                                  MemoryStream stream1 = new MemoryStream();
                                                                                  DataContractJsonSerializer ser = new DataContractJsonSerializer(typeof(Person));

                                                                                  ser.WriteObject(stream1, p);

                                                                                  как посмотреть результат:
                                                                                  stream1.Position = 0;
                                                                                  StreamReader sr = new StreamReader(stream1);
                                                                                  Console.Write("JSON form of Person object: ");
                                                                                  Console.WriteLine(sr.ReadToEnd());

                                                                                  Всего две строчки кода. Даже обезьянка осилить может…


                                                                                  1. pawlo16
                                                                                    11.08.2017 07:44
                                                                                    #10355512
                                                                                    -2

                                                                                    Я говорил о Net Core, где нет DataContractJsonSerializer. Там ваш код не прокатит. Вы внимательно читали написанное мной? Я специально уточнял несколько раз, что под виндовз C# — огонь в сравнении с другими ЯП. Даже обезьянка осилить может (с)


                                                                                    А ещё ваш DataContractJsonSerializer хреново готовит Dictionary<string,T> — что-то типа [{"Key":"a","Value":"33"},{"Key":"sdfs","Value":"sdfdsf"}], а нужно [{"a":"33"},{"sdfs":"sdfdsf"}]


                                                                                    1. Free_ze
                                                                                      11.08.2017 09:19
                                                                                      #10355596
                                                                                      +2

                                                                                      .NET Core создавался модульным, на минуточку)


                                                                                      1. pawlo16
                                                                                        11.08.2017 10:06
                                                                                        #10355696
                                                                                        -2

                                                                                        ну то есть в net core, как в нодежс, чтобы написать хелуворд, надо тащить в проект десяток говнобиблиотек на подобие newtonsoft.json от криворуких хипстеров — это называется модным словом "модульность". отлично например


                                                                                        1. franzose
                                                                                          11.08.2017 11:42
                                                                                          #10355992
                                                                                          +1

                                                                                          Не бывает такого, чтобы на одном языке была куча говнокодеров и говнобиблиотек, а на другом — сплошь идиллия и идеальный код. Уверен, и на Go найдется немало кода с запашком. Не понимаю, что вы всем вокруг пытаетесь доказать.


                                                                                          1. grossws
                                                                                            11.08.2017 11:50
                                                                                            #10356014
                                                                                            +2

                                                                                            Настоящий шотландец, ага. Если библиотека на го хреновая, то её написал не настоящий гошник, т. к. настоящий гошник говна не напишет. По крайней мере, выкрики местных фанатиков го часто создают именно такое ощущение.


                                                                                          1. pawlo16
                                                                                            11.08.2017 12:47
                                                                                            #10356192
                                                                                            -3

                                                                                            Не бывает такого, чтобы на одном языке была куча говнокодеров и говнобиблиотек, а на другом — сплошь идиллия и идеальный код

                                                                                            а я такого и не утверждал. Это вы самому себе оппонируете


                                                                                            Не понимаю, что вы всем вокруг пытаетесь доказать.

                                                                                            прочесть на пару каментов дальше не пробовали, прежде, чем высказать своё веское мнение?


                                                                                            1. franzose
                                                                                              11.08.2017 12:59
                                                                                              #10356210
                                                                                              +2

                                                                                              Тут тред уже настолько разросся, что непонятно, кто кому на что отвечает. Однако из общей суммы ваших комментариев я делаю вывод, что вы очень любите Go и очень не любите другие языки. Ну, по крайней мере C# уж точно.


                                                                                              1. pawlo16
                                                                                                11.08.2017 22:41
                                                                                                #10357394
                                                                                                -4

                                                                                                Я не теряю нить разговора, готов ответить за базар и ожидаю того же от тех, кто мне отвечает.


                                                                                                Вывод не правильный. Я не люблю все языки на которых программировал. Не существует хороших ЯП, все они дрянь в той или иной степени, но есть и галимое говно. Elm и Go не люблю меньше, чем C# и js, да.


                                                                                        1. Free_ze
                                                                                          11.08.2017 11:45
                                                                                          #10356000
                                                                                          +3

                                                                                          А вы не тащите говнобиблиотеки, берите сразу нормальные)


                                                                    1. mayorovp
                                                                      08.08.2017 23:45
                                                                      #10350112

                                                                      Не рассказывайте сказки, сама по себе студия никаких левых ссылок на Program Files никуда не записывает.


                                                                      Элементарно разобраться "как msbuild ищет исходники" — задача не тривиальная.

                                                                      Они вообще-то указываются в элементах <Compile>. Или вы какие-то другие исходники найти пытаетесь?


                                                                      1. pawlo16
                                                                        09.08.2017 07:45
                                                                        #10350360
                                                                        -2

                                                                        Не рассказывайте сказки

                                                                        Почесали своё уязвлённое чсв. Полегчало вам?


                                                                        1. franzose
                                                                          09.08.2017 08:02
                                                                          #10350376
                                                                          +1

                                                                          Вы тут уже на несколько экранов начесали)


                                                                1. Free_ze
                                                                  09.08.2017 11:47
                                                                  #10350674
                                                                  +1

                                                                  на каждый чих надо тащить десяток пакетов, каждый из которых отдельно просит есть и прописывается в дичайших конфигах, а не в исходниках, как это сделано в Go

                                                                  А в Go на каждый чих пакеты не нужны или их высшая сила сама подкладывает? В конфиги лезть не обязательно, есть же приятный юайчик с тремя кнопками.

                                                                  Проект на гошечке состоит из независимых микро(нано!)пакетов, которые при деплое собираются в корневую папку vendor

                                                                  Ого, а что нам это даст? Мы сможем поднимать веб-сервисы на RPi?


                                                                  1. pawlo16
                                                                    09.08.2017 18:23
                                                                    #10352036
                                                                    -3

                                                                    А в Go на каждый чих пакеты не нужны или их высшая сила сама подкладывает?

                                                                    Высшая сила в лице разработчиков стандартной библиотеки Гоу. В сравнении с которой стандартная библиотека C# поражает захламлённостью и отсутствием необходимого. Например


                                                                    • http сервер из коробки c http/2.0 и tls
                                                                    • https без использования OpenSSL
                                                                    • поддержка автоматического получения и обновления TLS-сертификатов — golang.org/x/crypto/acme/autocert
                                                                    • сериализатор asn1. В С# на минуточку даже для банального json надо прикручивать костыльную стороннюю либу, написанную криворуким хипстером.
                                                                    • data-driven шаблоны для генерации форматированного вывода text/template, html/template и т.д., плюс пакет синтаксического анализа, на котором они построены.
                                                                    • высокоуровневая поддержка обработки растровых изображений, в сравнении с которой System.Drawing — слёзы.
                                                                    • разбор флагов командной строки
                                                                      и ещё много всего нужного и полезного

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


                                                                    Ого, а что нам это даст? Мы сможем поднимать веб-сервисы на RPi?

                                                                    Уже дало. Гоу востребован во всех сегментах бизнеса, количество историй успеха, киллер-апс, репозиториев на гитхабе и популярность растёт. А С# вне венды как был в жопе, так и остался


                                                                    веб на IoT в 99% случаев хелуворд, там любой ЯП годится


                                                                    1. Free_ze
                                                                      09.08.2017 21:09
                                                                      #10352396
                                                                      +4

                                                                      У каждого свое необходимое может отличаться)

                                                                      Уже дало. Гоу востребован во всех сегментах бизнеса, количество историй успеха, киллер-апс, репозиториев на гитхабе и популярность растёт. А С# вне венды как был в жопе, так и остался

                                                                      Звучит как лозунг из буклета, не более того.


                                                                    1. 0xd34df00d
                                                                      10.08.2017 00:54
                                                                      #10352784
                                                                      +2

                                                                      Мне из этого всего списка достаточно регулярно нужен лишь разбор флагов (кстати, он у вас в Go аппликативный, монадический или в стиле унылого getopts?), наверное, а всякие хттп и прочие сериализаторы asn1 — не нужны были вообще ни разу.

                                                                      Наверное, я ненастоящий программист.


                                                        1. grossws
                                                          08.08.2017 15:32
                                                          #10349066

                                                          Я знаю людей, которые пол года учились прописывать какой-то дичайший XML с настройками GC jvm и теперь могут как-то там оптимизировать его работу, а тех кто не умеет, считают лохами.

                                                          Do tell me more about it. В java gc настраивается параметрами запуска JVM, а не xml'ем.


                                                          1. vintage
                                                            08.08.2017 16:33
                                                            #10349236
                                                            +1

                                                            Зная как выглядят параметры в яве… лучше бы это был XML :-)


                                                            1. grossws
                                                              08.08.2017 21:13
                                                              #10349874

                                                              Местами страшновато, но никто ж не пишет это руками в нормальном варианте, а загоняют в shell-скрипт. При экспериментах можно и потерпеть чуток.


                                                              Подавляющему большинству это вообще не надо, хватает дефолтных настроек конкретной версии JVM: в большинстве виртуальных машин конфигурации либо нет вообще, либо она минималистична, как в .net (IIRC, только preset client/server, concurrent или нет и большие объекты).


                                                        1. 0xd34df00d
                                                          08.08.2017 19:48
                                                          #10349762

                                                          Возьмём для примера перегрузку операторов. Надеюсь не надо объяснять, почему те люди, которые ввели эту синтаксическую опцию в С++, должны сдохнуть и сгореть в аду (могу пояснить на пальцах почему).

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


                                          1. vintage
                                            07.08.2017 00:37
                                            #10346642

                                            В D вполне себе есть прямая работа с памятью. И хоть стандартная библиотека D заточена больше под прикладное программирование и зависит от GC, но там также доступна и стандартная C библиотека (ABI совместимость, все дела), и есть куча D модулей, не требующая GC.


                                            1. grossws
                                              07.08.2017 00:40
                                              #10346650

                                              Про прямую работу с памятью я знаю. А про no-GC я читал в контексте D несколько лет назад и, на случай если мои представления устарели, решил вас скастовать ,)


                                              А насколько в D комфортно существовать без тех же exception'ов? Есть ли вещи типа option, either/result/variant, чтобы городить обработку ошибок в no-GC варианте?


                                              1. vintage
                                                07.08.2017 00:55
                                                #10346662

                                                Я ничего не писал без GC, так что имею лишь общее представление.


                                                Да, с алгебраическими типами там всё хорошо: https://dlang.org/phobos/std_variant.html


                                          1. pawlo16
                                            07.08.2017 15:02
                                            #10347428
                                            -2

                                            Rust в эту область плавно заходит и proof of concept в виде ОС Redox вполне тому подтверждение.

                                            В таком случае Go 100% системный ЯП, поскольку на нём так же написана ось. Ну а менеджер памяти пусть пишет г-н Александреску, у меня есть более интересные занятия


                                            1. grossws
                                              07.08.2017 15:06
                                              #10347438

                                              В какой момент Linux успели переписать на Go? Или вы про CoreOS только в агитке читали?


                                      1. mayorovp
                                        07.08.2017 07:31
                                        #10346798
                                        +1

                                        Вообще-то, к системным утилитам относятся не только части ОС, но и средства разработки. Поэтому даже Javascript является языком системного программирования, поскольку на нем уже написаны несколько компиляторов.


                                        1. grossws
                                          07.08.2017 07:45
                                          #10346810

                                          При таком определении почти любой тьюринг-полный язык можно называть системным, если на нём был написан хоть один интерпретатор/компилятор/транспайлер. Java, Scala, Kotlin, CL, Scheme, Clojure, Haskell, Python, Ruby, Perl, Matlab. Можно ещё поискать, но почти на любом мало-мальски популярном языке какой-нибудь, хоть игрушечный, компилятор/транспайлер/интерпретатор писали. Переводить все эти языки в разряд языков системного программирования, на мой взгляд, несколько преждевременно ,)


                                          1. VolCh
                                            07.08.2017 13:17
                                            #10347282

                                            На JS написан не "хоть один", а несколько только популярных трансляторов, активно используемых в продакшене, "игрушечных" я боюсь в порядках ошибиться.


                                            Вообще любой нормальный язык общего назначения как правило используется для системного программирования. Например, разработка веб-сервера — типичная задача системного программирования, а вовсе не прикладного. А продакшен-реди веб-сервера есть минимум на двух третях языков из вашего списка. Также для нормальных ЯПОН :) характерна на самом языке разработка экосистемы языка, разработка средств разработки — трансляторы, компоновщики, менеджеры пакетов, препроцессоры, таск-менеджеры и т. д., и т. п. — это тоже задачи системного программирования. У JS всё это есть. Более того, часто на сервер-сайде JS решает исключительно системные задачи по взаимодействию кучи различных процессов, написанных на разных языках, крутящихся на разных машинах и в разных сетях, а собственно прикладные задачи решает что-то более классическое или, наоборот, очень экзотическое, а сервисы на JS вполянют роли клея, шин, агрегаторов, диспетчеров, умных кешей и т. п., то есть тоже чисто системные задачи, а не прикладные.


                                            Никто не называет JS языком, заточенным под системное программирование, но вот отрицать, что на нём успешно и эффетивно решают задачи, относящиеся к системному программированию, можно только если иметь в виду какое-то не общепринятое деление задач на системные и прикладные.


                                            1. pawlo16
                                              07.08.2017 16:12
                                              #10347536
                                              -4

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

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


                                1. pnovikov
                                  05.08.2017 20:50
                                  #10345390
                                  +4

                                  усиливающийся накал истеричной поучительности

                                  Уверяю вас — это происходит не от офигительного обаяния go, а от вашего бездумного фанбойства и стремления судить о вещах, которые вы не знаете.


                                  типичный ОППшный оверинжиниринг

                                  Я вам еще раз настоятельно повторяю, что если все, за что бы вы ни взялись в ООП получается оверинжиниренным — то это ваша и только ваша проблема. Не надо всем об этом сообщать — мы уже итак поняли что вы не умеете проектировать. Перестаньте выдавать лично свой lack of skills за несовершенство технологии. Вы как тот мальчик, у которого и в 30 лет виновата скамейка.


                                  эмоции не дают вам осилить текст до конца

                                  Нет. 8 экранов ненужной информации не дают мне осилить этот текст до конца. И за все эти 8 экранов автор так и не удосужился пояснить что все-таки делает их система и какие именно её части были переписаны на go.


                                  dl.google.com: mailing list discussion / OSCON slides

                                  Гыгыгы. Вы просто скопировали текст с readme golang-а в гитхабе?))) Даже не удосужившись ознакомиться с конкретными примерами?))) Вот это и есть фанбойство: верить без разбора в то, что ваш любимый язык лучше всех и что на нем надо делать всё. Для тех, кто не понял: "mailing list discussion" и "OSCON slides" в оригинале были ссылками на дополнительную информацию о "dl.google.com". Бтв, я признаю что go-таки интересная вещь и беру свои слова назад — на нем можно писать вполне себе серьезные вещи. Однако до "перехода всего мира на go" — еще очень и очень далеко.


                                  если C# по вашим словам лучше Гоу, то почему они не сделали это на C#

                                  У вас какая-то странная аргументация. Давайте вот контрвопрос: почему если go лучше C# — stackoverflow написали на C#, а не на go? Очень странный критерий хорошести языка — что если он хорош, то обязательно google и обязательно должен на него что-то переписать. У гугла наверное nix-овый стек и им просто не с руки переписывать свои сервисы на штуку от мира Windows, нет? Если бы до этого google сидели на Delphi или Borland C++ — я вас уверяю, они бы переписали часть своих сервисов на C#. То, что они это не сделали — не говорит о том, что C# плох. У гугла достаточно причин не делать что-либо на C# и эти причины далеки от означенных вами.


                                  а приведите пример аналогичного бенчмарка с принципиально более комплексной логикой

                                  Я не знаю, делал ли кто-либо на go, например, импорт в базу данных здоровенного excel-файла, поэтому не могу привести пример.


                                  в отличие от кода на гошечке, который в разы проще и понятнее, а в 90% случаев значительно короче, чем код на С#

                                  А кто вам-таки сказал что мы весь код вбиваем руками? См. пример с наследованием от контроллера. Или в рядах go не принято иметь нормальные среды разработки?


                                  1. pawlo16
                                    05.08.2017 23:49
                                    #10345534
                                    -4

                                    от вашего бездумного фанбойства и стремления судить о вещах, которые вы не знаете.
                                    еще раз настоятельно повторяю
                                    8 экранов ненужной информации не дают мне осилить этот текст до конца
                                    Гыгыгы.

                                    Судя по "зачотным" диагнозам по аватарке и характерным кейвордам, фанбой — вы. Там разметка не правильная со ссылками, только и всего. Нечего сказать по существу разговора — надо высосать из пальца какую нибудь мелочь и громко прокричать. Очень по взрослому, ага.


                                    Даже не удосужившись ознакомиться с конкретными примерами

                                    Я вам привёл пример большого и сложного сервиса, переписанного на Гоу с другого ЯП. Это пойнт нашей дискуссии в отличие от вашего бла-бла-бла. Завязывайте с истериками и признайте на свежую голову, что были не правы в оценках и ляпнули не подумав про "на гошечку переводят хелловорлды и CRUD-сервисы".


                                    Про "переход всего мира на go" — это вы сейчас придумали, не я. Я в частности в самом начале чётко определил ниши С#. Но бэкенды многие переводят — факт, и относительное количество стартапов растёт.


                                    почему если go лучше C# — stackoverflow написали на C#, а не на go?

                                    По той же причине, по которой twitter написали на scala (сейчас постепенно переписывают на гоу ) — любопытсво и жажда нового. Ну так новых старапов с нуля на Гоу огромное количество, не сравнимо больше C#. Это видно даже из статистики гитхаба если что.


                                    Очень странный критерий хорошести языка — что если он хорош, то обязательно google и обязательно должен на него что-то переписать

                                    не только гугл. ещё facebook, adobe, twitter, mail ru group и т.п. Трудно найти IT гиганта, не переписывающего свои различные службы на Гоу.


                                    У гугла наверное nix-овый стек

                                    Очевидно, вы далеки от реалий IT бизнеса. Ку-ку! У всех nix-овый стек. Бэкенд на виндовз всегда был оксюморон, таковым и остался.


                                    Если бы до этого google сидели на Delphi или Borland C++

                                    , то гугл был бы не гугл, а колхоз "Светлый путь", сидящий на галимом булшэте


                                    Я не знаю, делал ли кто-либо на go, например, импорт в базу данных здоровенного excel-файла, поэтому не могу привести пример.

                                    Это все бла-бла-бла. Не вижу ни единого препятствия экспортировать excel в БД на Гоу. Пока есть один факт — хттп стек Гоу на много быстрее чем asp net core.


                                    А кто вам-таки сказал что мы весь код вбиваем руками?
                                    Или в рядах go не принято иметь нормальные среды разработки?

                                    в рядах гоу не принято использовать ненужный хлам, затрудняющий понимание программ, который надо вбивать в снипеты IDE. А IDE да, есть — Gogland. На много лучше тормозной и кривой VS.


                                    1. pnovikov
                                      05.08.2017 23:51
                                      #10345536
                                      +3

                                      Ладно, я понял что вы кроме go в жизни ничего не видели. Счастливо вам оставаться, нет уже сил с вами дискутировать.


                                      P.S.: HTTP-стек на производительность никто никогда не тестирует, потому что в реальных системах 90% времени уходит на доступ к источнику данных, а не на парсеринг запроса.


                                      1. pawlo16
                                        06.08.2017 00:54
                                        #10345594
                                        -3

                                        я понял что вы кроме go в жизни ничего не видели

                                        вы видите лишь то, что хотите видеть)) инфантилизм такой инфантилизм. Выше я говорил, что C# много лет использовал. И именно потому, что знаю его сильные и слабые стороны, мне лучше знать, насколько сильно он проигрывает Гоу во всём. Чем вам без знания Гоу и практик, отличных от ООП.


                                        Ну и в качестве подведения итогов разговора. Что даёт гошечка на вскидку .net-господам:


                                        • горуитины не только не реально повышают перформанс ( шедулер переключает их без перехода в режим ядра + стек 2-5 кб на один гринтред vs. 1 МБ на ос-тред в .net), но и убийственно упрощают разработку — линейный синхронный код vs. асинхронщина, в которую ни кто толком не умеет.


                                        • паузы GC не превышают 100 микросекунд на любом размере хипа. В то время как STW паузы в .net/net core сильно зависят от настроек GC и размера хипа, и в моём случае измерены в районе 100 миллисекунд, т.е. в 1000 раз больше, чем в Go.


                                        • кросс-платформенная компиляция out of the box и сборка программы в один самодостаточный бинарник без внешних зависимостей избавляет от dll hell, dependency hell и костылей в виде docker-а, что критически важно для микросервисов.


                                        • бинарник Гоу — это 5..15 МБ, и в функцию main процесс попадает за примерно 15 мс. Размер бинарников go-программ с включенным в них кодом рантайма получается в несколько раз меньше размера .net/net core-программ, которым для запуска нужна ещё и виртуальная машина внушительного размера.


                                        • поддержка всех необходимых средств для тестирования и замеров производительности out of the box. Благодаря этому тесты с бенчмарками на go пишутся и читаются очень просто. Фреймворки для тестирования .net в сравнении с go test — убожество. Причем профилирование можно включать/отключать удаленно в продакшн в любой момент времени, и это не снизит существенно скорость программы.


                                        • всё, что нужно, есть в стандартной библиотеке искаропки. В отличие от .net, где на любой чих начинается мучительный поиск очередной маргинальной библиотеки от непонятно кого.


                                        • скоростью компиляции существенно выше чем в C#


                                        • нормальное ООП на интерфейсах. чтобы запилить для типа имплементацию интерфейса, не надо менять тип.


                                        • нет убийц времени — эксепшнов, наследования, перегрузки операторов и функций, конструкторов, неявных преобразований типов и т.п.


                                        • простой синтаксис и go fmt, благодаря которым можно нанять роту пионэров, и они за миску риса и рюмку вайцзю напишут сложнейший продакшен код, который при этом легко читать и поддерживать. Потом можно их прогнать, нанять другую роту, и они будут нормально саппортить и рефакторить код предыдущей роты.

                                        HTTP-стек на производительность никто никогда не тестирует, потому что в реальных системах 90% времени уходит на доступ к источнику данных, а не на парсеринг запроса.

                                        Правильно! Так именно в таких случаях и проявляется вся мощь Гоу — в простом распараллеливании тяжёлого ввода-вывода


                                        1. pnovikov
                                          06.08.2017 01:19
                                          #10345624
                                          +2

                                          Слушайте, не надо мне писать портянку с рекламой go. Захочу — в интернете найду и почитаю.


                                          1. pawlo16
                                            06.08.2017 09:29
                                            #10345794
                                            -4

                                            Это были разъяснения почему C#, за который вы тут топите, для бэкенда — УГ. А не реклама.


                            1. TheShock
                              05.08.2017 18:17
                              #10345308
                              +7

                              Я работаю с гигантской кодовой базой

                              Может, если бы писали на C#, а не на Go, то она была бы не такой гигантской


                    1. 0xd34df00d
                      04.08.2017 20:20
                      #10344518
                      +3

                      в гоу это всё в разы проще благодаря общеязыковым фичам и плюшкам рантайма и экосистемы. Например благодаря отсутствию «убийц времени» (эксепшнов, наследования, перегрузки операторов и функций, конструкторов, неявных преобразований типов и generic-ов).

                      Их никто не требует использовать. И лично я не хочу переходить на Go с моих уютных плюсов и с моего уютного хаскеля потому, что там всего этого нет, и писать на Go довольно уныло.

                      И вообще


                      1. pawlo16
                        05.08.2017 19:15
                        #10345336
                        -7

                        с моих уютных плюсов и с моего уютного хаскеля

                        у вас стокгольмский синдром парадигмы разработки "чем сложнее, тем круче". В гошечке это лечится за две недели. В С++ я тратил тонны времени на бессмысленные размышления "как правильно спроектировать оператор new и присваивания, конструктор копирования, чтобы результирующий код был элегантным и оптимальным?" (в С++11 ещё конструктор с оператором перемещения добавился для "облегчения" жизни). Но почему-то код обычно получался сложным для понимания, а элегантность ломалась при первой же попытке его расширения под новые нужды. Потом появился Go, где все банально просто, без уродского оверинженеринга, ломающего продуктивность программистов, и получасовой компиляции. Поэтому программисты на Go продуктивнее программистов на C++ в 10 раз. Про хаскель я вообще молчу, ибо как можно всерьёз обсуждать язык, в продакшене не замеченный


                        1. 0xd34df00d
                          06.08.2017 04:14
                          #10345686
                          +2

                          у вас стокгольмский синдром парадигмы разработки «чем сложнее, тем круче». В гошечке это лечится за две недели.

                          Я как-то упустил момент постановки диагноза, когда случилось что-то, что надо лечить, оказывается.

                          В С++ я тратил тонны времени на бессмысленные размышления

                          Если вы тратили тонны времени, то это не значит, что все тратят тонны времени.

                          Ну а вообще, да, гошечка разработана для того, чтобы гугл мог набирать студентов по 50 р./пучок, быстро их обучать, и чтобы они не сильно лажали в работе. Значит, у Go есть целевая аудитория, никто с этим не спорит.

                          как правильно спроектировать оператор new

                          Часто operator new проектируете? Аллокаторы свои пишете?

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

                          Это довольно быстро приходит с практикой.

                          Поэтому программисты на Go продуктивнее программистов на C++ в 10 раз.

                          А чего сразу не в 100?

                          Как измеряли-то?

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

                          Можно. Я его в продакшене использую, мне норм.

                          В фейсбуке его тоже в продакшене используют, например.


                1. vintage
                  04.08.2017 09:29
                  #10342956
                  +1

                  Попробуйте любую из вариаций lisp — будете приятно удивлены.


                  1. pnovikov
                    04.08.2017 09:31
                    #10342968

                    LISP — отдельная тема. На нем, вероятно, удобно решать означенную задачу. А вот все остальные — нет :)


                    1. vintage
                      04.08.2017 09:51
                      #10343016

                      А какие — нет?


                      1. pnovikov
                        04.08.2017 09:53
                        #10343022

                        Все остальные задачи написания околобухгалтерской бизнес-логики. Опердень такой опердень.


                        1. vintage
                          04.08.2017 10:10
                          #10343062

                          И в чём проблема на лиспе описывать околобухгалтерскую бизнес-логику?


                          1. pnovikov
                            04.08.2017 10:13
                            #10343068

                            Начнем с того, что я его не знаю :) И учить ради того, чтобы проверить решает ли он мои задачи — смысла не вижу. Мне достаточно факта что никто из моих многочисленных знакомых на лиспе свои задачи (особливо — бизнес-задачи) не решает.


                            1. vintage
                              04.08.2017 10:32
                              #10343124

                              https://ru.wikipedia.org/wiki/Парадокс_воронов


                              1. pnovikov
                                04.08.2017 10:37
                                #10343136
                                -1

                                Нет, потому что я видел код на LISP и мне даже сложно предположить какие из моих задач он может теоретически решить.


                                1. vintage
                                  04.08.2017 11:59
                                  #10343322

                                  Да любые. Ну а код страшненький, да. У меня есть идея сделать аналог лиспа, но с более дружелюбным синтаксисом.


                                  1. pnovikov
                                    04.08.2017 12:10
                                    #10343362

                                    Кстати, один из сотрудников JetBrains пошел по такому же пути, только с C# и сделал nemerle. Правда он потом уволился и больше коллеги его не видели :)


                                    1. raveclassic
                                      04.08.2017 12:33
                                      #10343410
                                      +2

                                      Угарная кстати была штука.
                                      А про джетбрейнс не знал, я в свое время думал, что это дипломная работа каких-то поляков.


                              1. Idot
                                04.08.2017 12:07
                                #10343356

                                https://ru.wikipedia.org/wiki/Парадокс_воронов

                                А как в ProLog'е этот парадокс решается?


                                1. vintage
                                  04.08.2017 13:44
                                  #10343634

                                  Хз, я с ним не знаком. Но я его упомянул в другом ключе: то, что многие используют не лисп, вовсе не означает, что они не решили бы те же проблемы на нём.


                  1. 0xd34df00d
                    04.08.2017 09:34
                    #10342972

                    Давайте сразу статически строго сильно типизированные языки всё-таки.

                    СССТ, хм, надо задуматься о популяризации аббревиатуры.


      1. michael_vostrikov
        05.08.2017 15:53
        #10345240

        "Низкий порог вхождения" означает, что простые вещи можно сделать просто, сложные сложно, простые без дополнительных знаний особенностей библиотек и рантайма, сложные может получив эти знания а может и без них.


        1. altai2013
          05.08.2017 16:08
          #10345244

          Ну вот например, какие вещи в C# делают порог вхождения для новичков высоким? Какие простые вещи на C# сделать сложно?


          1. AndreyRubankov
            05.08.2017 17:00
            #10345276
            -2

            какие вещи в C# делают порог вхождения для новичков высоким?
            1. Ограничения со стороны языка и платформы, чем больше ограничений тем лучше будет код,
              но для начинающего специалиста это кажется не понятным: «почему я не могу сделать так?», «почему все так сложно?»
            2. Обилие языковых фич. Чем больше фич в языке, тем сложнее новичку в нем разобраться.
              Чем больше возможностей сделать одно и то же, тем сложнее будет проект для понимания и поддержки.
            3. Linq – удобная штука, но «писать на SQL, пока ты пишешь на C#» – это пенальти для понимания кода.
            4. Специфичный ООП, у класса может быть 2 метода с одинаковой сигнатурой, один для класса, другой для интерфейса, и какой из этих методов будет вызван зависит от того, какой тип переменной используется.


            ps: Если изучаешь язык по мере его развития, то обилие функционала не кажется таким страшным и каждая новая фича в радость. Но когда язык наращивает сильно много функционала, то новичкам становится очень тяжело его осилить. Это стоит учитывать.


            1. franzose
              06.08.2017 03:33
              #10345674
              +2

              Специфичный ООП, у класса может быть 2 метода с одинаковой сигнатурой, один для класса, другой для интерфейса, и какой из этих методов будет вызван зависит от того, какой тип переменной используется.

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


          1. michael_vostrikov
            05.08.2017 17:08
            #10345280
            -2

            Например: поле для тетриса
            Сколько кода будет на C#, включая отладочный вывод, и сколько на это потребуется времени? А на C++ с device context?


            1. AndreyRubankov
              05.08.2017 17:26
              #10345284
              +2

              Справедливости ради, стоит отметить, что тут идет не правильное сравнения.
              Вы в данном случае сравниваете JS, как DSL для браузера с языком общего назначения, на котором в принципе можно написать браузер))

              Для примера: Сколько будет времени написать бухгалтерскую программу на 1C и сколько на JS?


              1. michael_vostrikov
                05.08.2017 18:20
                #10345312

                Ну я сравниваю в контексте изучения новичком. Быстро набросал, работает, можно разбираться, как сделать лучше.
                Или вот фреймворки взять. На JS или PHP каждый может написать свой фреймворк для каких-то целей. А для C# это в основном крупные системы от больших компаний.


                1. AndreyRubankov
                  05.08.2017 19:31
                  #10345346
                  +1

                  Если смотреть на JS, как на DSL для браузера, – согласен, порог вхождения минимальные. Изучил jQuery и уже можешь что-то полезное писать.

                  Но если взять более современные подходы к JS, с нодой, бабелем, npm и прочими – это ничем не проще того же C# с его NuGet, ASP.NET и WebApi.

                  А если смотреть на JS, как на платформу для бекенда – то тут тем более не будет проще. Нужно все те же знания по базам данных, по архитектуре бекенда и т.д.

                  Что мешает написать фреймворк на C#? Ну кроме того, что все уже и так написано ;-)


                  1. michael_vostrikov
                    05.08.2017 20:24
                    #10345370

                    Это ничем не проще, но можно подходить к этому постепенно, при этом будут нормальные рабочие программы. И не знаю, как на ноде, но на PHP ходить в базу сильно проще, чем на C#.


                    1. AndreyRubankov
                      05.08.2017 23:03
                      #10345480
                      +1

                      Увы, не соглашусь, на самом деле, по сложности – одинаково.
                      На C# можно ходить в базу через ODBC, это практически так же просто, как и через PDO.
                      Хотя, на php можно еще и через MySQLi и подобные ходить, но это не лучший способ.

                      Использовать какие-нибудь Query Builders? Да без проблем как в php так и в C# такого треша валом. ORM? – тоже и там и там есть несколько реализаций.
                      Проще только от того, что меньше статической типизации? – да, соглашусь, тут проще немного, но на самом деле это не существенная разница.

                      С нодой, все так же. Да и с Java все так же обстоит.


                      1. michael_vostrikov
                        05.08.2017 23:52
                        #10345538

                        Ага. Только сначала надо это подключение установить. С PHP все ясно — что в php.ini подключено, туда и можем подключаться. А в C#?


                        odbc-connectionstring


                        On a Windows 64 bit machine, make sure you check if your C# code is compiled in x86
                        The 32-bit drivers can be found at C:\windows\SysWOW64\odbcad32.exe.
                        make sure you verify your connection works with the ODBC Data Source Administrator

                        Получение данных.
                        how-to-bind-parameters-via-odbc-c
                        odbcdatareader.read


                        OdbcCommand cmd = conn.CreateCommand();
cmd.CommandText = "SELECT * FROM [user] WHERE id = @id";
cmd.Parameters.AddWithValue("@id", 4);
OdbcDataReader reader = cmd.ExecuteReader();
reader.Read();
Console.WriteLine(reader.GetInt32(0) + ", " + reader.GetString(1));

                        Даже строку в готовом виде не получить, только отдельные поля читать.


                        pdo


                        $stmt = $pdo->prepare('SELECT name FROM users WHERE email = :email');
$stmt->execute(['email' => $email]);
while ($row = $stmt->fetch(PDO::FETCH_ASSOC))


                        1. pnovikov
                          05.08.2017 23:58
                          #10345544

                          А про EntityFramework, являющийся kind of дефолтным решением для доступа к SQL-базам в .NET вы, видимо, не слышали?


                          Да еще и диспоза в вашем коде нет. Печально.


                          1. michael_vostrikov
                            06.08.2017 00:15
                            #10345564

                            Во-во, я ждал такой коммент. Это и есть "дополнительные знания особенностей библиотек и рантайма".


                            1. pnovikov
                              06.08.2017 00:17
                              #10345566

                              EF это даже не особенность библиотеки или рантайма. Это официально рекомендуемая технология доступа к данным. В той же мере, в которой npm является официальным пакетным менеджером для node.js. Вы же не станете писать на ноде, не познав npm?


                              1. michael_vostrikov
                                06.08.2017 10:23
                                #10345862
                                +2

                                npm надо сравнивать с NuGet, а не с EF. EF можно сравнивать с Doctrine или с какой-нибудь реализацией ActiveRecord. Я запросто могу писать без Doctrine и даже без ActiveRecord, да и в общем-то без npm с composer-ом. Это будет чуть менее удобно, но без особых сложностей, что в общем-то и делают начинающие и малопрофессиональные разработчики.


                                А чтобы использовать EF надо сначала узнать что он есть и что это оказывается официально рекомендуемая технология. По запросу "php database connection" на первой странице ссылки на PDO, а по запросу "c# database connection" про entity framework написано только один раз на 3 странице. Это не хорошо и не плохо, просто это добавляет порог входа.


                          1. AndreyRubankov
                            06.08.2017 00:28
                            #10345576

                            А еще есть NHibernate, да и другие ORM.
                            Но это уже выходит за рамки «простого для понимания», так что это точно не в тему.


                        1. AndreyRubankov
                          06.08.2017 00:26
                          #10345574

                          Только сначала надо это подключение установить.
                          С этим тоже проблем нету, строка подключения берется из файла конфигураций.
                          А приведенный пример «проблемы», спокойно решается путем NuGet (composer в мире PHP). Так что уверяю вас, это надуманная проблема.

                          Даже строку в готовом виде не получить, только отдельные поля читать.
                          На самом деле, 
                          reader
                          это и есть Строка из из базы, вы к ней потом обращаетесь, чтобы взять нужные поля. И если я не ошибаюсь, есть синтаксис по-проще: 
                          reader["name"]


                          Даже если не обращать внимания, что код отличается по смыслу, можно заметить, что особых проблем нету. Да, есть небольшое неудобство с тем, чтобы закинуть параметры по одному, а в остальном – практически идентичный код.

                          Или на 2 строчки больше кода – это для вас большая проблема?


                          1. michael_vostrikov
                            06.08.2017 09:43
                            #10345812

                            Мне как-то сложно представить, чтобы composer регулировал подключения к БД. Ок, .NET инфраструктура имеет свои особенности. Но это тоже дополнительная информация, которую надо знать.


                            reader["name"] это внутреннее состояние и после следующего reader.Read() оно изменится. А $row это отдельный DTO, который можно передать куда угодно. И отдельный объект cmd, которому надо свойства присваивать и параметры биндить по одному. Это не 2 строчки кода, это больше логических сущностей. Речь же не идет о "самый простой / самый сложный", речь идет о "проще / сложнее". Вот когда после fetch я получаю готовый $row это проще.


                        1. mayorovp
                          06.08.2017 09:31
                          #10345802

                          Вообще-то, DbDataReader реализует IEnumerable, через который как раз можно получить отдельные строки в готовом виде (кстати, а что такое — готовый вид?):


                          foreach (IDataRecord row in reader) {
    // ...
}

                          Еще можно загрузить данные в DataTable:


                          var table = new DataTable();
table.Load(reader);


                          1. michael_vostrikov
                            06.08.2017 10:41
                            #10345876

                            Готовый вид это значит что я могу работать со строкой как с отдельным самостоятельным объектом, не связанным с конкретным соединением с БД. Если я могу записать этот row в массив и потом передать куда-нибудь, то хорошо. А DataTable это опять же отдельная сущность, что добавляет сложности.


                            1. Lofer
                              06.08.2017 12:01
                              #10345948

                              Готовый вид это значит что я могу работать со строкой как с отдельным самостоятельным объектом,

                              В общем-то это на разных слоях объекты Data Transfer Object и Plain Object.
                              Кто-то должен из понятий базы данных Table & Row & Field сделать Entity + Property.
                              Просто решите на каком уровне вы хотите с БД работать и все :)


            1. vintage
              05.08.2017 19:36
              #10345350

              Думаю я на D потратил времени куда меньше, чем вы на JS:


              import std.stdio;

void main()
{
    bool[10][20] field;

    field[0][4] = true;
    field[1][4] = true;
    field[2][4] = true;
    field[3][4] = true;

    void render()
    {
        foreach( row ; field ) {
            foreach( cell ; row ) {
                write( cell ? "#" : "." );
            }
            writeln;
        }
    }

    render();
}


              1. michael_vostrikov
                05.08.2017 20:28
                #10345374

                Э не, причем тут консоль) Консоль везде одинаковая. Сделайте в графике с произвольными цветом и паддингами.


                1. vintage
                  05.08.2017 22:16
                  #10345444
                  +1

                  Вы думаете это сильно сложнее?


                  import dlangui;

mixin APP_ENTRY_POINT;

extern (C) int UIAppMain()
{
    auto window = Platform.instance.createWindow( "Tetris" , null );

    bool[10][20] field;

    field[0][4] = true;
    field[1][4] = true;
    field[2][4] = true;
    field[3][4] = true;

    auto board = q{
        TableLayout {
            colCount : 10
        }
    }.parseML;

    window.mainWidget = board;

    Widget[10][20] cells;

    foreach( y , row ; field ) {
        foreach( x , _ ; row ) {

            auto cell = q{
                Widget {
                    layoutWidth : 16
                    layoutHeight : 16
                    margins : 1
                }
            }.parseML;

            board.addChild( cells[y][x] = cell );
        }
    }

    void render()
    {
        foreach( y , row ; field ) {
            foreach( x , filled ; row ) {
                cells[y][x].backgroundColor = filled ? 0x00FF00 : 0x0000FF;
            }
        }
    }

    render;

    window.show;

    return Platform.instance.enterMessageLoop;
}

                  Первый раз пишу гуй на этом языке.


                  1. TheShock
                    05.08.2017 22:25
                    #10345446
                    +3

                    D, все-таки, очень клевый. Жаль, что не взлетел, а вместо него всякие посредственные Go


                  1. michael_vostrikov
                    05.08.2017 22:53
                    #10345462
                    -2

                    Ну значит думаю можно сказать, что у D порог входа тоже ниже, чем у C#. Хотя надо знать, что означают магические заклинания "q", "parseML" и "enterMessageLoop", и почему их надо вызывать именно там. Вообще, мне JS не очень нравится, я отвечал про разные пороги входа у разных языков.


                    1. TheShock
                      05.08.2017 23:04
                      #10345482
                      +1

                      А как на счет магических заклинаний «display: inline-block;» «float: left», «script», «append(html);» и сотен других. Я уж молчу об этой странной строчке, которая выглядит как случайный набор символов:

                      $('.row:eq('+y+') .cell:eq('+x+')')

                      CSS, к вашему сведению, крайне неочевиден если не знаешь его, а использование inline-block — далеко не начинающий уровень. Я бы еще понял, если бы в том коде грубо использовались table+tr+td, но имитировать таблицу через флоаты и инлайн-блоки — нужен скилл.


                      1. michael_vostrikov
                        06.08.2017 00:02
                        #10345554

                        Я не сказал, что в JS нет магических заклинаний. Вот только если их не указать, все равно работать будет, только отображаться неправильно. Можно постепенно добавлять правила из мануала и проверять результат. И указаны они в отдельном специальном месте. Можно и через таблицы сделать, тоже будет работать. Смысл комментария же не в том, что надо обязательно верстать на дивах. А в конкатенации строк нет ничего магического. Только на C# такой результат все равно получить сложнее.


                    1. vintage
                      05.08.2017 23:09
                      #10345490

                      В вашей версии также нужно знать, что означают магические заклинания "$", "toggleClass" и <script>, и почему их нужно вызывать именно там.


                      1. michael_vostrikov
                        06.08.2017 00:13
                        #10345562

                        Да. Только из этого не следует, что все языки абсолютно одинаковы по сложности освоения.


      1. AndreyRubankov
        05.08.2017 17:37
        #10345290
        +1

        Видать давно вы не начинали изучать C# с нуля :-)
        Сейчас в нем так много синтаксического сахара, что этому может даже JS позавидовать)))

        одна интегрированная среда разработки
        VisualStudio, VisualStudioCode, MonoDevelop, IDE для Unity3D, JetBrains Ride

        один популярный фреймворк
        .NET + ASP.NET, .NET Core + ASP.NET Core, Unity3D, Xamarin, – и это только те, которые на слуху у человека не из мира .NET)
        Притом под ASP там еще есть: WebForms, WebAPI, etc., а под сам .NET: WPF, WCF, WTF =)

        один источник документации
        MSDN – довольно плохой источник информации или вы все же про StackOverflow?)))


  1. gro
    03.08.2017 15:29
    #10341774
    +5

    Вот, кажется, даже вполне конкретные аргументы, но нет, надо в дополнение начать нести про бабло и про то, что он такой герой, на бабло не клюнет. Ещё бы про жидо-массонский заговор упомянул.


  1. Ohar
    03.08.2017 16:05
    #10341860
    +1

    Бугурт очередного неосилятора.
    Из нормальных претензий только типы и статический анализ, но это решается тайспкриптом и линтером.


  1. firk
    03.08.2017 16:28
    #10341894
    +3

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


  1. elmm
    03.08.2017 17:00
    #10341942

    Давно уже на бэкэнд смотрю преимущественно со стороны клиента, но как мне помниться —
    «имеет бешеную популярность благодаря… низкому порогу входа»
    с десяток лет назад этот аргумент активно применялся для хейтерства php.
    Через десять лет, возможно место javascript займёт новый язык, с низким порогом вхождения, и будет забавно читать хейтеров, приводящих основным недостатком языка — низкий порог вхождения.

    PS: правда это не отменяет некоторых особенностей языка, которые у человека, привыкшего к нормальному ооп и другим языкам навивает мысли о пушном зверьке.


    1. firk
      03.08.2017 17:11
      #10341960

      с десяток лет назад этот аргумент активно применялся для хейтерства php.
      ну так для php это всё до сих пор актуально, просто все уже привыкли за 10 лет


  1. gbezyuk
    03.08.2017 17:31
    #10342004
    +5

    Если без истерики, то:
    * в браузерах массово ничего кроме JS нет
    * на сервере JS появился потому что хотелось один и тот же код гонять и там и там, но см. предыдущий пункт
    * ни для чего кроме предыдущего пункта на сервере JS применять не рационально — изоморфный рендеринг, и хватит
    * если на JS пишут всё подряд (читай — бэкэнд/API), это почти всегда говорит о незнакомстве разработчика с альтернативами, и более ни о чём. В частности, это ничего не говорит о JS — он для бэкэнда не создавался никогда.
    * Хотя ES4 обладает рядом спорных характеристик, ES6 — действительно крут, в нём очень много очень сладкого сахара.
    * Трудные времена рождают сильных людей. Преодоление монополии и косяков ES4 дало вебдеву очень многое. И чем слюной брызгать и про красоту Haskell рассказывать (ну да, неплох), лучше порадоваться ES6.


    1. stardust_kid
      03.08.2017 18:31
      #10342098
      +2

      Золотые слова. По всем пунктам кроме первого "Без истерики". Пост представляет собой жирный наброс, ради истерики созданный.


    1. VolCh
      05.08.2017 12:46
      #10345136

      Вполне знаком с альтернативами, но для веб-сокет сервера для трансляции событий, которые генерирует PHP выбрал ноду. Так же её выбрал для предоставления graphql API, агрегирующего данные с Restish сервисов на PHP и C#. Для первой задачи ещё Go серьёзно рассматривал.


      1. raveclassic
        05.08.2017 13:08
        #10345164

        Расскажите, почему не Go в итоге? (сам с ним работал)


        1. VolCh
          07.08.2017 06:25
          #10346764

          Рынок труда в Киеве не делает Go хорошим выбором для "одноразовых" задач.


  1. alan008
    03.08.2017 18:40
    #10342112
    +4

    хайп-драйвен-девелопмент

    драйв, дроув, дривен


  1. lomnev
    03.08.2017 19:46
    #10342222
    +1

    Хайп модулирует общественное сознание и большинство людей не могут перед этим устоять.

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

    Могу лишь порекомендовать тем, кто чувствует праведный гнев за JS, найти время и внимательнее посмотреть на новые языки с красивым классическим дизайном. Со временем ненависть к «чужим» пройдет, а профессионализм останется.

    Отличная статья, спасибо. Хотя картинку можно было бы и сменить. Она прямо таки провоцирует.


  1. forester11
    03.08.2017 20:47
    #10342312

    Хайп node.js имхо — оправдан.
    1) Во-первых комуникация в одну нить на асинке — тренд который начал поднимать голову уже достаточно давно, и показал себя очень хорошо даже в плюсах (boost::asio), и в С (libevent). Просто стало очевидным что много потоков абсолютно не требуется для создания эффективных и масштабирующихся серверов и клиентов, и все эти треды и связанная с ней синхронизация — пустая трата времени. Я думаю это открылось во времена роста P2P, когда каждый нод в P2P сети должен тянуть тысячи (ну сотни минимум) соединений не ставя на колени средний ноутбук/комп. Ну и остальной спорт «сделать сервер который осилит 10к клиентов DC++» на дешевом/домашнем железе.
    2) Гробы-фреймворки со своими новыми языками и строгим контролем владельцев, в текущих условиях устаревают уже на момент своего релиза. Смотрим на Java, С#, что там нового вышло — это все уже покрылось плесенью, и оно покрылось плесенью уже на момент выхода. Модель Node.JS в этом плане опять правильная — берем существующий язык, где войны браузеров сделали очень эффективный рантайм, делаем минималистичный рантайм базовый, и даем абсолютно открытый NPM с «уклоном в хаос» (никаких стандартов модулей как было замечено). В результате язык развивается очень быстро, революционно быстро (история вариантов промисов таже, автор заметил), так что пенсионеры неуспевают и создают такие эмоциональные статьи.

    Имхо, если смотреть на Node.JS с точки зрения «мне нужен устоявшийся фреймворк, чтобы 5 лет назад уже все придумали и стабилизировали, и еще 10 лет ничего не меняли» — то конечно Node.JS это ужас. Если смотреть с точки зрения поиска самого современного фреймворка с передовыми технологиями — то пожалуй лутше ничего нет, ибо модель «стабильности» устаревает на момент релиза. То что клиенты хотят Node.JS в результате вполне ожидаемо, это те клиенты которые хотят нового.


    1. Labunsky
      03.08.2017 21:23
      #10342374
      +1

      Всегда забавляет, что многие говорят о асинхронности как о новом тренде. Серьезно, а до появления многопоточности как писали-то?


      1. pnovikov
        03.08.2017 21:36
        #10342398
        +1

        Асинхронность и многопоточность — разные вещи. Как технически, так и с точки зрения дизайна.


        1. Labunsky
          03.08.2017 22:03
          #10342446

          разные вещи
          В контексте алгоритмов и то, и другое все-таки используется для обеспечения параллелизма


        1. Lofer
          04.08.2017 00:09
          #10342606

          Асинхронность и многопоточность — разные вещи. Как технически, так и с точки зрения дизайна.

          Серьезно? Т.е там нету работы в разных потоках, нету точек синхронизации? Магия ?!


          1. pnovikov
            04.08.2017 00:37
            #10342628
            +1

            Есть. Однако это два разных инструмента для решения разных задач. В частности асинхронность — это работа исключительно через Thread Pool и потоки вы не контролируете, равно как и не можете настроить свой дизайн потоков в приложении. Она работает по модели "поставить в очередь задачу — присвоить коллбек — делать что-то другое пока задача выполняется". Многопоточность — она именно о том, чтобы 2 и более задач выполнялись одновременно, а вы имели возможность собирать результаты, получать уведомления из этих потоков и т.п.


            Технически (на примере C#) асинхронный ввод-вывод, как уже было сказано ниже, реализуется через completion ports и не имеет ничего общего с тредами как таковыми. Отличие от многопоточности очевидно.


            Как-то так.


            1. Lofer
              04.08.2017 19:22
              #10344396
              -1

              Технически (на примере C#) асинхронный ввод-вывод, как уже было сказано ниже, реализуется через completion ports и не имеет ничего общего с тредами как таковыми.

              Если не считать того, что по умолчанию там используется… threadpool.
              А если читать мануалы MS внимательно, что там написано примерно следующее:
              1. вы можете создавать потоки руками и вручныю ими управлять, а что бы забрать результат или быть извещены о результатет то подписаться на callback

              2. если вам лень заниматься п.1 (ручное управление потоками), используйте threadpool, он предоставляет сервис управленяи потоками и их использования.

              3. если вам в лень заниматься п.2 (использовать полуавтоматическое управление потоками), используйте Tasks. Но, если вам свербит в одном месте и хочется какой-то контроль, то можете наваять свой TaskScheduler для «handles the low-level work of queuing tasks onto threads».

              и те же task наследованы от IAsyncResult через который работает п1 и п2 :)
              Это просто наслаивание сервисных оберток, а внутри старый добрый Thread и Threadpool :)
              Лень, двигатель прогресса.


              1. mayorovp
                04.08.2017 19:50
                #10344460
                +1

                Далеко не каждая задача (Task) выполняется в пуле потоков. Те, которые построены на базе TaskCompletionSource или аналогичных механизмах, не привязаны ни к какому потоку.


            1. AndreyRubankov
              04.08.2017 23:23
              #10344738

              В частности асинхронность — это работа исключительно через Thread Pool
              Чем отличается тредпул (из коробки, ака «асинхронность») от пула потоков, которые девелопер будет создавать для «многопоточности»?

              по-моему, тут что-то не так с определением, и то, о чем вы говорите, это больше походит на реактивность (но с реактивностью это vintage нас рассудит).

              Асинхронность, может быть только в случае, когда не используется CPU, сейчас самый простой пример — это IO-bound операции. Все остальное — это вариации многопоточности.


              1. pnovikov
                04.08.2017 23:31
                #10344752

                Я имел в виду что вы не можете явно начать тред и явно его грохнуть — API тредпула этого не позволяет, асинхронный подход этого не предусматривает. Само собой IO-bound разруливаются другими инструментами, но интерфейс использования тот же.


                1. Lofer
                  05.08.2017 00:55
                  #10344814

                  Я имел в виду что вы не можете явно начать тред и явно его грохнуть

                  В свое время theadpool создавал потоки «по запросу». Но это внутренняя оптимизизация.
                  API тредпула этого не позволяет,

                  Так у него другая задача — предварительно созданные thread(s) и их последовательное переиспользование, а не создание каждый раз заново и удаление.
                  Экономия на времени создания потока, а что вы будете делать с этими потоками и когда — это полностью ваша проблема.
                  Можете руками такое сделать без особых проблем (руками в массиве поместить с десяток потоков предварительно созданных и периодически дергать их) — производительность будет таже самая.


    1. pnovikov
      03.08.2017 21:32
      #10342394

      Просто стало очевидным что много потоков абсолютно не требуется для создания эффективных и масштабирующихся серверов и клиентов

      Посмотрите исходники nodejs. Я мог не так понять, но вроде как он тупо берет новый поток из тредпула на любой асинхронный вызов. Если я понял правильно, то потоков этот подход создает еще больше, чем традиционные подходы. В остальном libevent и asio — это хорошо. Но делать на этом подходе АБСОЛЮТНО ВСЕ — несколько перебор.


      Гробы-фреймворки

      За Java не скажу, но С# весьма резво развивается. Новая версия языка выходит чуть ли не каждый год, а с открытием компилятора (Roslyn) — дискуссии по вопросу "что добавить в язык" идут чуть ли не ежедневно. При достаточной квалификации — можно сделать хоть свой билд компилятора и запилить туда все, что угодно. В NuGet-е каждый день появляется что-то новое. При том никакого уклона в хаос — в большинстве случаев скачанное прекрасно работает и выполнено идеологически в более-менее едином стиле. Достаточно заметить что асинхронность на completion ports (async/await) появились в C# несколько раньше чем в ES. Как и стрелочные функции, которые появились, например, еще до того как мир узнал что такое AngularJS. Так что кто быстрее развивается — я бы поспорил. И при том это не просто "фича для галочки" или Haskell-way — фича есть, но она сложная и поэтому ей никто не пользуется. Наоборот, все изменения внедряются на хорошем инженерном уровне и гармонично вливаются в язык.


      Если смотреть с точки зрения поиска самого современного фреймворка с передовыми технологиями

      Простите, а вам шашечки или ехать? В смысле вам нужен современный фреймворк просто чтобы иметь современный фреймворк, или вам все же надо решить вашу задачу наиболее быстрым и дешевым способом? Эти задачи несколько ортогональны.


      1. mayorovp
        04.08.2017 13:22
        #10343564
        -1

        Посмотрите исходники nodejs. Я мог не так понять, но вроде как он тупо берет новый поток из тредпула на любой асинхронный вызов.

        Не на любой, а только на те, которые невозможно сделать по-другому (ну, или можно, но еще не сделали). Например, работа с DNS...


    1. pawlo16
      04.08.2017 09:40
      #10342996
      -2

      1)


      Просто стало очевидным что много потоков абсолютно не требуется для создания эффективных и масштабирующихся серверов и клиентов

      Обоснуйте, ибо звучит как лепет школьника. В чём заключаются преимущества асинхронного кода перед моделью авторов и зелёными потоками кроме того, что она для вас лично понятнее? Из того факта, что в nodejs на смену callback hell пришёл promises hell и мучительные попытки понять в каких местах нужно ставить async await, логически не следует, что это есть гут.


      2) nodejs и npm прокатывает только для тех, кто в жизни не писал на гуманном ЯП. И развивался он исключительно потому, что таких много. Голубые фишки айти давно уже поняли, что это самое дно из всего что есть вообще (кроме может PHP) и массово переходят на Гоу. Вот мнение maintainer’а кучи популярных nodejs библиотек — https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e52b — плюнул на нодкжс и перешёл на go. Вот ещё https://medium.com/digg-data/the-way-of-the-gopher-6693db15ae1f Даже вконтакте перешел с node.js на go — https://twitter.com/M0sth8/status/638132331295952896 Bower переводит инфраструктуру с node.js на go — https://twitter.com/bower/status/717426243730345986 Over9000 других переходов с node.js на go — http://lmgtfy.com/?q=switching+from+node+to+go


      А вы тут рассказываете про то какая nodejs крутая и модная. тот ещё bubble effect


  1. yogurt1
    03.08.2017 21:32
    #10342392
    +1

    Очередная статья о JavaScript, автор которой JavaScript толком-то не знает
    crossenv опечалил, пакет правда снесли уже. Но автор не указал этого, потому что хайп ему важнее


    1. staticlab
      03.08.2017 22:01
      #10342438

      и то, автор этих вирусных пакетов просто использовал фишинг: создал фейковые пакеты с названием, похожим на настоящее


  1. rboots
    04.08.2017 00:53
    #10342644
    -3

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

    На критику по пунктам:

    • однопоточный рантайм — это очень удобно, не возникает проблем с владением объектом и других ужасов.
      на многопроцессорных машинках js прекрасно параллелится запуском локального кластера
    • отсутствие единой системы / стандартов реализации модулей — их две, обе прекрасно работают,
      пользуйтесь какая нравится
    • отсутствие единых стандартов структуры проекта ( все творят как хотят, в исходниках бывает очень сложно разобраться ) — это самый популярный язык на планете, а не DSL, так чего же вы хотели? в разных сферах применения js разные стандарты, и это правильно. если не умеете читать код — так и скажите
    • слабые типы с неявными ( и порой довольно странными ) преобразованиями — странными для кого, перешедших с Java, C#, PHP, Python, Lisp, Ams? мир гораздо богаче вашего любимого языка и то, что для одних странно, для других норма. посмотрите хотя бы на haskell с его монадами и функторами, очень мощные штуки,
      кстати. в JS используются в jQuery. в институте этому не учили, правда? печалька
    • отсутствие нормальных классов / ООП — ооп здесь богаче, чем в большинстве других языков. Можете наследовать через классы, можете через прототипы.
    • отсутствие единого вменяемого и работающего статического анализатора кода ( добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function ) — развивайте дисциплину кода, не всё время за юбкой IDE прятаться. А если серьёзно, это общая проблема всех интерпретируемых языков с eval, и отказываться от этой мощи ради возможности ловить 5% самых глупых ошибок — сомнительная идея.
    • отсутствие вывода типов в самом языке или в каком-либо инструменте — изучайте синтаксис, это есть
    • этот чудесный контекст this ( что это значит this в этом месте кода — объект? функция? ) — изучайте синтаксис, это очень просто
    • абсолютно дурацкая реализация pattern matching ( паттерн матчишь пустой список / объект — без проблем, извлекаешь оттуда undefined, ты же именно это имел ввиду, да? ) и здесь опять привет cannot read property foo of undefined — не делайте логических ошибок и будет вам счастье
    • отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async ( если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку ) — их минимум четыре распространённых, каждая со своими плюсами и минусами, выбирайте ту, что больше подходит под конкретные задачи
    • const ( который на самом деле НЕ const ) — ой беда-беда
    • абсолютно безумный npm, с пакетами качества «братишка я тебе покушать принёс» ( и даже вот с таким )
      — плата за свободу творчества и отсутствие премодерации. Проблема не велика, просто всегда смотрите на число скачиваний и звёзд на github


    1. staticlab
      04.08.2017 07:54
      #10342848
      +2

      отсутствие вывода типов в самом языке или в каком-либо инструменте — изучайте синтаксис, это есть

      и всё-таки нет этого в JS


    1. Movimento5Litri
      04.08.2017 11:20
      #10343246
      +5

      На данный момент JavaScript — самый популярный ЯП на планете. И, как бы я не уважал TypeScript, Java, C#, Go, другие языки — у них нет шансов изменить статус кво.

      Лол, лол, лол, вы на какой планете живёте?
      На планете Земля самый популярный язык — Java, без Script

      Он даёт действительно много свободы и в нём нет защиты от дурака, поэтому такие люди там не задерживаются.

      Лол, толпы jquery-говнокодеров-формошлёпов и не знали…

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

      Лол, вы говорите это человеку который
      всю жизнь писал на Erlang, Elixir, Haskell и Lisp


      Как спортивный байк

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

      не делайте логических ошибок и будет вам счастье

      Лол, даже лучшие в мире программисты и компании тратящие 7 миллиардов долларов на разработку делают ошибки.

      отсутствие нормальных классов / ООП — ооп здесь богаче, чем в большинстве других языков. Можете наследовать через классы, можете через прототипы.

      Идите создайте интерфейс

      Лично я пишу на JavaScript уже 15 лет, искренне считаю его одним из самых мощных ЯП на сегодняшний день, поэтому не позволю его обижать

      Ещё один защитничек не знающий язык который защищает https://habrahabr.ru/post/214087/#comment_7360557

      И колбеки, и промисы, и async/await — нативные, поэтому код они не утяжеляют. Не знаю, что вы называете фьючерсами, я этим не торгую.

      И вы себя называете программистом?
      https://en.wikipedia.org/wiki/Futures_and_promises

      Изначальные принципы языка были настолько хороши, что 10 лет (с 1999 по 2009) язык прожил вообще без изменений.

      image


      1. serg_p
        04.08.2017 11:33
        #10343276

        Это вы Луркморе не читали :)


  1. asvahagnas
    04.08.2017 08:53
    #10342904

    ас


  1. Scf
    04.08.2017 09:35
    #10342976

    nodejs — это современная альтернатива питону.


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


  1. igrishaev
    04.08.2017 10:19
    #10343080

    Все так.


  1. ekubyshin
    04.08.2017 10:47
    #10343168

    че то текст совсем ни о чем. Какие то выдуманные проблемы.

    Давай по порядку:
    1. однопоточный рантайм в 2017 году. И че? ты не слышал об event loop и в чем его плюсы и минусы?
    2. про модули конечно лупанул, почитал бы для начала чем живет этот мир
    3. про стандарты структуры проекта конечно, тот еще вывод. Причем тут вообще язык? тут больше дело в программистах, которые на нем пишут. На любом языке можно написать такого, что волосы дыбом встанут.
    4. ну не верно же утверждение в целом, ничего там странного нет, люди вон на js умудрялись линукс в браузере запускать
    5. ну слушай, а нет конечно интерфейсов и иногда это бывает досадно, но в новом es уже не так все плохо в плане синтаксического сахара. Ну полиморфизм там не такой, а в целом задачи вполне решаются без проблем с тем, что есть.
    6. ну если хочешь прям такой строгой типизации и считаешь, что это прям большая проблема в языке, то прикрути typescript или flow
    7. про this конечно не понятно, в чем у тебя проблема. У людей, которые работают с js проблем с этим нет. Возможно тебе стоит чуть внимательнее поизучать литературу ;)
    8. ну это не такая уж и большая панацея, чтобы без нее жить нельзя было
    9. По поводу работы с асинхронным кодов — ок, а что в других языках прям строго утвержден способ работы с асинхронным кодом? да ну! прям удивление.
    10. const ( который на самом деле НЕ const ) — а что ты под этим имеешь ввиду? поясни, что в твоем понимании должно быть const?
    11. по поводу качества npm — а причем тут язык? это проблема больше вида human factor, чем проблема языка. В любом языке можно найти кучу пакетов с отвратительным качеством.

    Вообще, конечно, не понятно, как такой текст прошел из песочницы.


  1. gooddaytoday
    04.08.2017 11:50
    #10343300
    +3

    (Евангелист пришел в комментарии, все как вы любите)

    слабые типы с неявными ( и порой довольно странными ) преобразованиями

    Typescript.

    отсутствие нормальных классов / ООП

    Typescript.

    отсутствие единого вменяемого и работающего статического анализатора кода ( добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function )

    Typescript.

    отсутствие вывода типов в самом языке или в каком-либо инструменте

    Typescript.

    этот чудесный контекст this ( что это значит this в этом месте кода — объект? функция? )

    Ммм...Typescript?

    const ( который на самом деле НЕ const )

    Опять Typescript.

    отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async ( если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку )

    async/await, прямо как в любимом многими C#. Теперь и в Typescript.

    А еще вы забыли упомянуть, что в JS нет интерфейсов, декораторов и многого другого.


    1. greendimka
      04.08.2017 12:20
      #10343388
      +2

      Лично я обожаю TypeScript. Но у него есть фатальный недостаток — изобретено в Microsoft — а это значит, что религия использовать не позволяет.
      И не смотря на то, что на дворе уже не средневековье — приходится применять насилие и жестокость, чтобы заставить перейти с JS на TS. Потом радуются и облизываются, но без революций — никак не хотят облегчать себе жизнь.
      Из собственной практики предполагаю, что быть евангелистом TypeScript'а — дело нелёгкое.


      1. gooddaytoday
        04.08.2017 15:54
        #10343932

        Я где-то читал подобное:

        TypeScript создали в Microsoft. Язык прекрасен и поэтому странно, что он появился именно там.


        1. pnovikov
          04.08.2017 16:21
          #10344006

          Сюрприз-сюрприз. В Microsoft так-то много классных вещей появляется.


          1. greendimka
            04.08.2017 16:28
            #10344034
            +2

            Тсс. Вы сейчас ходите по грани оскорбления чувств верующих.


            1. pnovikov
              04.08.2017 16:31
              #10344044

              Если честно, то я на чувства верующих активно сру — сколько себя знаю. В моей текущей команде мы разрабатываем решение для склада на технологиях MS — С#/MVC/MSSQL и несколько собственных наработок. Мы подняли систему до используемого состояния, from scratch, за 4 месяца усилиями троих разработчиков. Т.е. через 4 месяца после начала разработки — в неё уже была внесена первая тысяча продуктов. Проблемы js-ников, go-шников, джавистов и уж тем паче приверженцев php/ruby/python нам неведомы. У нас лично никаких нерешаемых проблем нет и нам хорошо. :)


  1. yorick_kiev_ua
    04.08.2017 11:50
    #10343306
    +2

    Очень забавно читать коментарии «это всё неправда, это всё истерики, JS — торт… ну в смысле на typescript, конечно, и c no-any еще, ну а как иначе-то?».

    Да-да, тот самый ts, который строго типизирован и с анализатором кода. Тот самый, который перед каждым колбеком делает захват контекста «var _this = this», в котором явно указываешь тип возвращаемого значения и опечатки или забытый return(если я правильно понял претензии автора) ловятся при компиляции, с человеческими классами и так далее по списку.
    Тот самый TypeSctipt, «идеалогчески» ближе скорее к java/C# чем к js.

    Ребята, а вы разве не понимаете, что это всё равно, что сказать «да, автор, you're damn right, твои претензии оправданы и TypeSctipt взлетел именно потому, что решает часть этих проблем, а без него в сыром виде это(js) кушать невозможно»?


    1. ekubyshin
      04.08.2017 12:21
      #10343392

      современный js вполне неплохо справляется со своими задачами, каждый язык заточен под свои задачи и не стоит пытаться на js писать сложные математические рассчеты — он сделан не для этого.

      js на сервере применяется строго для определенных задач и никто не собирается применять его там, где это не целесообразно.

      Автор данной ремарки, написал в таком общем виде, что не знающий и не пишущий на js человек, может подумать, что оно действительно так и js это просто временное явление. Но на секундочку, js появился в 1995 году и вполне неплохо развивается, а последнее время набрал довольно хорошие обороты по развитию стандарта языка и самих движков.

      Практически все пункты высосаны из пальца, либо из-за недопонимания как работает js и как и что на нем можно делать, а что не следует на нем делать.


      1. yorick_kiev_ua
        04.08.2017 15:07
        #10343802

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

        Я, признаться, не готов разговаривать на таком уровне аргументации.


  1. akuzmin
    04.08.2017 17:44
    #10344220
    +1

    «Зуб даю, все поголовно бы писали на Haskell и рассказывали бы друг другу за чашечкой смузи покручивая спиннер о новых монадах и аппликативных функторах от Facebook» — хаха, сказано хорошо. Но фишка в том, что эти «компании, которые вливают деньги в JS», это никакой не заговор. Это одно из проявлений эволюционных процессов, где в условиях нормальной конкуренции JS стал более перспективен, чем Haskell. Если вы пытаетесь с этим спорить и обвиняете в этом компании, то вы просто занимаетесь боем с ветряными мельницами, сопротивляетесь действительности, природе человека, мира и всего такого.


  1. fukkit
    05.08.2017 00:56
    #10344816
    +3

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

    Странно читать эрлангера, со своей кривенькой функциональной колокольни пытающегося критиковать наш любимый универсальный наколеночный JS за наличие скобочек, ретурна, точек с запятой, и однопоточный рантайм с божественным ивентлупом.

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

    Странно читать хейтеров, сетующих что и классы то тут не настоящие и типы кучерявые, и почти любую типовую задачу 15 пакетов из репозитория решают с различной степенью бажности, а стандартная библиотека размазана по десятку топовых в этом месяце пакетов npm. Ребята, вы выползли из своих уютных замшелых нор в быстро меняющийся мир! Здесь вот так. Нам тоже это не нравится, но лучшей доли никто пока не предложил, может быть вы?

    Странно читать фанатов JS, сравнивающих в комментах свой однострочник, накиданный через точку, без проверок, обработки ошибок, в расчете на предсказуемость мира, счастливую звезду, и милость сатаны, с кодом на промышленных языках, которые не дают написать так коротко именно по причине близкого знакомства с проделками упомянутого персонажа.

    Ребята, давайте жить дружно! JS как явление — великолепен, хайп и мисьюз чего бы то ни было напротив — явление убогое и недостойное. Увлекайтесь первым, а не вторым. Свобода лучше, чем несвобода. Как говорится, /тхеард


  1. taujavarob
    08.08.2017 17:35
    #10349470
    -1

    JavaScript действительно явление (С)

    Он аналогичен… дереву.

    Из дерева можно сделать много — от зубочистки до небоскрёба.

    Попробуйте сделать зубочистку из… железобетона!

    «Всё что можно написать на JavaScript будет написано на JavaScript» (С) — Из дерева можно сделать ручку, чашку, кровать, автомобиль, шлюпку, плот, корабль, шпалы, самолёт и небоскрёб.

    Конечно, чашку можно из стекла или глины.

    Кровать из Java железа.

    Шлюпку из Go пластика.

    Корабль из Rust стали.

    Шпалы из C бетона.

    Самолёт из C++ люминия.

    Небоскрёб из C# железобетона.

    Но что из этого может сравниться с деревообработкой?

    А если вспомнить что из дерева можно гнать самогон получать бумагу — то ничего милее дерева как материала то и нет!

    Вот парень, после 20-ти лет работы с JavaScript, решил обрубить все ветви дерева и использовать ствол как таран — выбросить OOП, операторы if, for, switch, модификатор var и писать всё в стиле FP ибо он уверовал что JavaScript — мультипарадигмен. (С)

    Парадигму FP он решил поддерживать жесткой дисциплиной кодирования. А не изобретать очередной парадигменный костыль (поддержания конкретной парадигмы — одной из многих в JavaScript ) типа TypeScript или тянуть отдельные библиотеки в код.

    Его уже в дурку увези, конечно На него уже навалились бить, но он пока отбивается.

    JavaScript can be anything you want it to be and it will be sure to give you just enough rope to hang yourself with.


    JavaScript действительно явление (С)