JavaScript как явление

[aen]

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

[Strain]

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

[vilgeforce]

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

[torbasow]

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

[S_A]

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

[vintage]

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

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

[mayorovp]

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

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

[AndreyRubankov]

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

[vintage]

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

[mayorovp]

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

[vintage]

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

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

[mayorovp]

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

[TheShock]

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

[mayorovp]

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

[Apx]

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

[mayorovp]

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

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

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

[franzose]

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

[mayorovp]

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

[quantum]

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

[mayorovp]

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

[Ryss]

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

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

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

[mayorovp]

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

[YemSalat]

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

[mayorovp]

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

[YemSalat]

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

[mayorovp]

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

[vilgeforce]

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

[AndreyRubankov]

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

[vilgeforce]

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

[flancer]

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

[DarthKotik]

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

[AndreyRubankov]

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

[nikolay_karelin]

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

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

[andreysmind]

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

[torbasow]

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

[Sayonji]

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

[grossws]

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

[franzose]

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

[torbasow]

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

[Fen1kz]

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

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

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

[torbasow]

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

[Fen1kz]

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

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

[torbasow]

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

[Strain]

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

[torbasow]

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

[Strain]

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

[Cake_Seller]

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

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

[Cake_Seller]

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

[torbasow]

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

[franzose]

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

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

[grossws]

В императивных языках вполне можно жить с опциональным 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, ессно), это несколько раздражает.

[x67]

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

[YemSalat]

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

[Lofer]

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

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

[Eldhenn]

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

[AndreyRubankov]

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

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

[vilgeforce]

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

[Apx]

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

[AndreyRubankov]

«почему всё так?»

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

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

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

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

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

[vintage]

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

[mayorovp]

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

[vintage]

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

[mayorovp]

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

[vintage]

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

[mayorovp]

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

[vintage]

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

[mayorovp]

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

[vintage]

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

[mayorovp]

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

[Ashot]

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

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

[some_x]

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

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

[Strain]

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

[franzose]

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

[franzose]

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

[AndreyRubankov]

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

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

[pnovikov]

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

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

[AndreyRubankov]

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

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

[grossws]

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

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

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

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

[mclander]

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

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

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

[dmitryprogrammer]

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

[taujavarob]

CodeViking

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

Многие любят JS — И это нормально.

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

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

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

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

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

[TheShock]

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

[taujavarob]

но вот люблю C#, потому что мне нравятся эмоции, которые я испытываю, когда программирую на нем.

Ну какие могут быть эмоции в этой Microsoft инкарнации Java? Какие? — Не шутите так. Время Java и С# (с эмоциями, с эмоциями) осталось в конце прошлого века.

[begemot_sun]

Наболело.

[ik62]

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

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

[Strain]

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

[ik62]

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

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

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

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

[i360u]

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

[Zenitchik]

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

[i360u]

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

[bano-notit]

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

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

[i360u]

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

[bano-notit]

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

[i360u]

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

[bano-notit]

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

[i360u]

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

[bano-notit]

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

[punkkk]

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

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

[bano-notit]

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

[Zenitchik]

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

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

[useq]

я сам по себе как js разработчик знать не должен

Если вы позиционируете себя исключительно как js-разработчика, то разумеется не должны. Однако, если же вы имеете смелость называть себя фронтенд-разработчиком, то как минимум обязаны.

[franzose]

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

[Zenitchik]

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

[Zenitchik]

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

[mclander]

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

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

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

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

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

[AndreyRubankov]

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

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

[odintree]

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

[bano-notit]

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

[Hedgar2018]

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

[Hedgar2018]

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

[mclander]

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

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

[raveclassic]

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

[Iqorek]

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

[Hedgar2018]

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

[knekrasov]

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

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

[oleg_gf]

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

[oleg_gf]

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

[Muxto]

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

[franzose]

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

[Zenitchik]

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

[Free_ze]

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

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

[speshuric]

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

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

[Wedmer]

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

[aleXoid]

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

[Strain]

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

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

:)

[x67]

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

[Iqorek]

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

[Hedgar2018]

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

[Iqorek]

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

[Hedgar2018]

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

[Iqorek]

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

[Free_ze]

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

[Shifty_Fox]

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

[Free_ze]

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

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

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

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

[Shifty_Fox]

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

[Free_ze]

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

[AndreyRubankov]

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

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

[Free_ze]

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

[AndreyRubankov]

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

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

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

[Free_ze]

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

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

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

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

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

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

[Zenitchik]

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

Перейдём на Lua

[Free_ze]

Ну хотя бы)

[grossws]

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

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

[some_x]

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

[andreysmind]

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

[franzose]

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

[andreysmind]

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

[some_x]

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

[Nagg]

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

[Yeah]

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

[raveclassic]

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

[pnovikov]

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

[serg_p]

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

[serg_p]

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

[BuccapuoH]

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

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

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

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

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

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

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

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

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

[sfi0zy]

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

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

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

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

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

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

[BuccapuoH]

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

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

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

[Shifty_Fox]

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

[erlyvideo]

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

[Shifty_Fox]

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

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

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

[Free_ze]

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

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

[Strain]

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

[Shifty_Fox]

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

[Shifty_Fox]

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

[Strain]

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

[Shifty_Fox]

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

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

[Shifty_Fox]

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

[Free_ze]

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

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

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

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

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

[Shifty_Fox]

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

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

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

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

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

[Free_ze]

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

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

[Shifty_Fox]

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

[grossws]

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

[Shifty_Fox]

Могу скопировать тройку классов из клиент-серверной игры в 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, с видом сверху.

[Shifty_Fox]

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

[Shifty_Fox]

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

[sshikov]

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

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

[greendimka]

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

[bano-notit]

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

[raveclassic]

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

[bano-notit]

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

[raveclassic]

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

[bano-notit]

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

[raveclassic]

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

[bano-notit]

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

[raveclassic]

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

[pnovikov]

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

[bano-notit]

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

[raveclassic]

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

[bano-notit]

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

[raveclassic]

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

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

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

[bano-notit]

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

[pnovikov]

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

[raveclassic]

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

[pnovikov]

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

[raveclassic]

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

[bano-notit]

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

[bano-notit]

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

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

[bano-notit]

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

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

[bano-notit]

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

[AxeLWeaver]

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

[Strain]

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

[bano-notit]

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

[AxeLWeaver]

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

[bano-notit]

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

[AndreyRubankov]

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

[bano-notit]

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

[AndreyRubankov]

На сайте npm любой модуль нам предлагают установить так:
npm install expresshttps://www.npmjs.com/package/express

модуль будет добавлен в депенденси со следующим синтаксисом:
"express": "^4.15.4"

Смотрим документацию:
https://docs.npmjs.com/getting-started/semantic-versioning

эта запись означает что данный модуль будет обновляться при выходе минорных релизов, т.е. 4.15.4 -> 4.50.1 без проблем будет обновлен.

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

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

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

[bano-notit]

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

[AndreyRubankov]

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

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

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

Facebook в их рядах. И это уже Ваша проблема, а не проблема вендора, т.к. Ваш продукт сломался из-за обновления версии.

[vintage]

Есть и более чудесные примеры. Например, разработчики Angular1 меняют API в минорных версиях, так как версии 2+ уже заняты фактически новым фреймворком с тем же именем.

[mayorovp]

А вот то, что поведение под капотом приводит к несовместимости — проблемы пакета.

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

[BuccapuoH]

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

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

[AndreyRubankov]

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

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

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

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

[irbis_al]

А Автор Топика например делал 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… и есть с чем сравнивать ,-ноде это простота кода и ёмкость… сосредотачиваюсь просто на решении., а не на обрастании синтаксических лексем.

[yorlin]

Ваше сравнение звучит как: А вы хоть раз пробовали собрать БМВ по запчастям? А вот если взять полуготовый жигули без колёс и хоп хоп колёса прикрутил и машина. Так вот БМВ — финя, а Жигули — класс.
А теперь покажите пожалуйста сравнительный код СОАП клиента на джава и на голом джаваскрипте.
Мне кажется нечестным сравнивать полуготовое решение, с голым языком. Уж хотя бы со спрингом сравнивали б…

[Strain]

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

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

[Grox]

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

[Shifty_Fox]

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

[Strain]

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

[Yeah]

А как же as any?

[mayorovp]

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

[VioletGiraffe]

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

[Strain]

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

[mayorovp]

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

[farcaller]

ejabberd.

[farcaller]

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

[bano-notit]

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

[bano-notit]

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

[bano-notit]

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

[irbis_al]

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

[Noa69]

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

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

[irbis_al]

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

[Noa69]

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

[Labunsky]

40 минут на java код только писать надо будет

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

[Coffin]

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

[copist]

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

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

[bano-notit]

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

[copist]

положить

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

[Apx]

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

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

[irbis_al]

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

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

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

[vintage]

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

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

import vibe.d;

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

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

[bano-notit]

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

[vintage]

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

[bano-notit]

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

[irbis_al]

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

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)

[fogone]

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

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)
}

[Braidner]

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

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);
    }
}

[sshikov]

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

[Apx]

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

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

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

[Iqorek]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет, он не идеален, но

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

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

[porn]

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

[Iqorek]

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

[franzose]

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

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

[Iqorek]

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

[greendimka]

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

[vintage]

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

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

[greendimka]

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

[vintage]

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

[Iqorek]

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

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

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

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

[pnovikov]

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

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

[vlad9486]

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

[Iqorek]

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

[vlad9486]

.

[Iqorek]

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

[Iqorek]

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

[pnovikov]

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

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

[Iqorek]

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

[pnovikov]

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

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

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

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

[vintage]

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

[Iqorek]

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

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

[vintage]

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

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

[copist]

Кстати про 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 ]; // а этот?
}

[vintage]

Это D.

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

[Iqorek]

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

Так 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, чтобы не было проблем с логами в случае крэша основного процесса.

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

[pnovikov]

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

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

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

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

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

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

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

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

[Iqorek]

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

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

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

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

Сомнительное утверждение. Запись в сокет не приводит к движению магнитной головки диска

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

[pnovikov]

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

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

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

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

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

Потом

[maxpsyhos]

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

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

[maxpsyhos]

А теперь вот мне стало интересно: откуда у вас взялось это число?

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

Насколько? Какова вероятность отсутствия прочих свободных ядер?

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

[AndreyRubankov]

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

Второй поток надо создать

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

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

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

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

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

pps:

12,5мс (максимальный теоретический выигрыш от параллельности)

А можете предоставить источник? Я так полагаю, вы читали какую-то научную работу на эту тему?

[maxpsyhos]

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

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

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

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

А можете предоставить источник?

https://habrahabr.ru/post/334760/?reply_to=10342966#comment_10342104

1 миллион сложений мой браузер сделал за 25мс. Если этот код разбить на два потока...

[AndreyRubankov]

Не согласен. Если у вас есть ровно одно свободное ядро, на котором надо выполнить 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» – не будет работать. И это не говоря про то, что результат от запуска к запуску будет меняться, особенно в браузере, где «постороннего шума» невероятно много.

[mayorovp]

Как-то проглядел я этот ваш комментарий раньше...

Если в системе 10 потоков и каждый находится в состоянии "готов к работе" — то эта система загружена на 1000%/N (где N — число ядер). Разумеется, на такой системе все будет тормозить. И все "преимущество" многопоточных программ в таких условиях сводится к тому что они жадно отбирают ресурсы у остальных. Не уверен что это хорошо.

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

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

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

Выше уже приводили цифру: 8 микросекунд на синхронизацию потоков. Именно такова будет последовательная часть при разделении суммирования на два потока. На фоне параллельной части (12,5мс) ее можно не учитывать.

Так что конкретно для этой задачи деление на два — работает.

[franzose]

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

[pnovikov]

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

[Iqorek]

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

[pnovikov]

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

[Iqorek]

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

[Free_ze]

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

[Movimento5Litri]

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

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

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

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

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

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

[Movimento5Litri]

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

Успешно.

[Movimento5Litri]

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

[bano-notit]

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

[franzose]

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

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

[VolCh]

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

[Zenitchik]

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

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

[Dimensi]

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

[bano-notit]

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

[IonianWind]

однопоточный рантайм ( в 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 — фактически те же промисы, только "подсахаренные". А фьючерсы — на фондовой бирже)

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

[KoCMoHaBT61]

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

[copist]

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

[KoCMoHaBT61]

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

[copist]

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

[copist]

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

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

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

[bano-notit]

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

[apocarteres]

ccc

[k12th]

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

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

[bano-notit]

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

[rumkin]

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

[kekekeks]

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

[rumkin]

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

[Lofer]

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

[i360u]

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

[screen_sailor]

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

[nuald]

Позвольте мне рассказать, как так получается, что для 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. Полное покрытие тестами у них не всегда есть, иногда они полагаются только на интеграционные тесты. Так что не стоить думать, что у гигантов софтоиндустрии все прекрасно, там тоже есть немало проблем.

[flancer]

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

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

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

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

[Neikist]

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

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

[flancer]

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

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

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

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

[irbis_al]

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

[flancer]

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

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

[wladyspb]

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

[copist]

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

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

[ValdikSS]

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

[flancer]

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

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

[pnovikov]

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

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

[copist]

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

[Nondv]

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

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

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

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

[blazer]

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

[vintage]

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

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

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

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

[bormental]

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

[bormental]

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

[pnovikov]

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

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

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

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

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

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

[pnovikov]

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

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

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

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

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

[bano-notit]

Кэтбери?

[pnovikov]

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

[pnovikov]

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

[usr753]

однопоточный рантайм ( в 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 Браузера и его работу. Научится работать с асинхронностью. А уже после всего этого приниматься за библиотеки, фреймворки, а не на оборот. Впрочем зная язык можно свои велосипеды написать)

[mayorovp]

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

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

[RubaXa]

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

[dklein]

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

[RubaXa]

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

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

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

[Lofer]

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

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

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

[usr753]

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

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

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 их нет, в место них объекты, другой вообще подход

[Lofer]

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

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

Пример неймспейсов

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

Паттерн Модуль + Фасад. Данные и код хранятся в замыкании, без возможности доступа извне, кроме определенных методов или свойств. Та же инкапсуляция по сути

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

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

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

[kozyabka]

[darksimpson]

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

[altai2013]

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

[pnovikov]

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

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

[altai2013]

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

[pnovikov]

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

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

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

[altai2013]

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

[pnovikov]

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

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

[pnovikov]

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

[altai2013]

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

[pnovikov]

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

[altai2013]

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

[pnovikov]

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

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

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

[bano-notit]

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

[pnovikov]

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

[altai2013]

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

[pnovikov]

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

[altai2013]

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

[pnovikov]

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

[bano-notit]

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

[Zenitchik]

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

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

[bano-notit]

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

[Strain]

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

[raveclassic]

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

[franzose]

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

[franzose]

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

[altai2013]

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

[franzose]

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

[bano-notit]

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

[bano-notit]

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

[pnovikov]

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

[bano-notit]

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

[pnovikov]

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

У меня в принципе нет претензий к технологиям. А вот к сообществу — таки есть, да. :)

[Lofer]

Почему до сих пор тогда нету vbs программистов? У vbs порог тогда вообще никакой по сравнению с js, ибо возможностей больше,

VBS — на нем был сделан в конце 90х начале 200х ASP. Как вспомню тот @#$^$% что творился при отладке, до сих пор в ужас бросает. Возможно MS после этого сделал вменяемый ASP.NET забрав все что можно в контролируемое окружение с нормальным инструментарием. Это было как радуга… как фантастика после VBS для веб разработки. После этого любые «слабая типизация» или «оно само сделает» ничего кроме мата в мыслях не вызвает.

[pawlo16]

Вне виновз десктоп и юнити C# уныл, проигрывает конкурентам (java, kotiln, go, python) по всем статьям, а перспективы его там сомнительны более чем. И порог вхождения в C# всегда был высок, но сейчас конечно js переплюнул с трешем баблей-вебпаков-реактов-редаксов. проблема C# в том, что он практически такой же отстойный как java (ну может быть чуть-чуть лучше), но при этом рантайм развит и интегрирован на порядок примерно хуже чем jvm.

[pnovikov]

Ну вам по ходу дела бессмысленно объяснять про деревья выражений, LINQ и where-констрейнты в C# :) Спите спокойно: C# убог

[pawlo16]

Отнюдь нет. Я с эти работал, так что Вы можете попытаться. Заодно расскажите, как сильно наличие данных языковых фич (к которым к слову деревья выражений не относятся, в них любой ЯП умеет) повлияло на выбор C# в качестве ЯП для unity и UWP, где он действительно востребован. И почему ни кто не торопится перевести бэкенд с java/c++/nodejs на C# не смотря на наличие данных фич. В отличие от гошечки, на которую переходят с радостью я бы сказал

[pnovikov]

Любой ЯП умеет разобрать переданную лямбду на куски и транслировать в другой язык? Это какой такой ЯП так умеет кроме C# — покажите, я с радостью на него перейду. :)
Бекенда на C# написано как раз столько, что вам и не снилось. Самый известный — для stackoverflow и из русского — moedelo. Так что тут вы тоже ошибаетесь.

А гошечка… Ну если ваше приложение ограничивается 20-30 REST-методами для CRUD-а, то гошечка — выбор для вас, да. Как только надо сделать что-нибудь более сложное (e.g. интеграцию между несколькими сервисами, REST со сложной функциональностью, вытягивание выборки из БД по сложному запросу) — тут-то гошечка начинает только мешать и вот мои знакомые, например, с радостью съезжают с гошечки на C#, ибо как удобнее. :)

[pnovikov]

Спойлер: вся простота и красота гошечки (равно, кстати, как и nodejs) превращается в нещадное адище, когда вы понимаете что вам нужен координатор распределенных транзакций (который, кстати, в C# точно есть, насчет Java не скажу). Если вы с таким не сталкивались и считаете что проблема нерелевантна — расслабьтесь и примите как данность что вы просто пишете слишком простые вещи.

[pawlo16]

Это какой такой ЯП так умеет кроме C# — покажите, я с радостью на него перейду. :)

clojure, elixir. Из типизированных — F#, Scala. Good luck!

Бекенда на C# написано как раз столько, что вам и не снилось

Больше чем на c++/java/python ?? не фантазируйте ))

Самый известный — для stackoverflow

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

интеграцию между несколькими сервисами, REST со сложной функциональностью, вытягивание выборки из БД по сложному запросу

в гоу это всё в разы проще благодаря общеязыковым фичам и плюшкам рантайма и экосистемы. Например благодаря отсутствию "убийц времени" (эксепшнов, наследования, перегрузки операторов и функций, конструкторов, неявных преобразований типов и generic-ов).

координатор распределенных транзакций

это из области кровавого энтерпрайза и борьбы с легаси. Это не для Гоу конечно, но конкретно в данном аспекте java и кложура предпочтительней C# по многим причинам. В типичных приложениях Гоу такие задачи решаются взаимодействием и интеграцией с сервером БД. Почитайте на досуге про шардинг и репликацию, ага?

Если вы с таким не сталкивались и считаете что проблема нерелевантна — расслабьтесь и примите как данность что вы просто пишете слишком простые вещи.

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

[pnovikov]

clojure, elixir. Из типизированных — F#, Scala. Good luck!

Вы, очевидно, не понимаете о чем идет речь. Почитайте как устроен конструктор запросов в EntityFramework.

Больше чем на c++/java/python

Мы тут вроде не сосисками меряемся. Я просто говорю о том, что бекенда на C# пишется довольно много. Это был контраргумент к

почему ни кто не торопится перевести бэкенд с java/c++/nodejs на C#

Потому что, наверное, мало кто в принципе занимается переводом тяжелого бекенда с фреймворка на фреймворк забавы ради. А так — как я и сказал. Бекенда на C# написано достаточно много, чтобы оценить все плюсы и минусы подхода. Если вам для дискуссии именно что надо "больше чем на X", то сочувствую.

благодаря отсутствию "убийц времени"

Гы. Молодой человек, если generic-и, наследование и перегрузка операторов убивают ваше время, то есть отличный выход. Готовы? Открываю тайну: не пользуйтесь ими. :) Не говоря уже о том, что сдуру можно и член сломать: если вы пользуетесь ими так, что они отнимают ваше время, а не экономят — то вы пользуетесь ими неправильно.

В типичных приложениях Гоу такие задачи решаются взаимодействием и интеграцией с сервером БД. Почитайте на досуге про шардинг и репликацию, ага?

Это вы-то меня будете шардингу учить? Спешу расстроить: после корпоративной системы документооборота с распределенными БД — вы меня точно шардингу не научите. Так или иначе шардинг и репликация даже близко ничего не имеет с распределенными транзакциями. Читайте, читайте что делает MSDTC и почему.

Я уже понял что вы джедай

А то ж.

[pnovikov]

Речь идет о вот этой технике работы.

[pnovikov]

В том виде, в котором это происходит в .NET — да. Когда работа с AST становится неотъемлемой частью ежедневной работы и продакшн-кода повсеместно.

Так-то понятное дело что AST можно написать на любом языке.

[retran]

При всей моей любви к сишарпу — ему в этом плане довольно далеко до языков умеющих в полноценный quotation и настоящие макросы.

[pnovikov]

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

[pawlo16]

Вы, очевидно, не понимаете о чем идет речь

речь о "разобрать переданную лямбду на куски и транслировать в другой язык" — перечисленные ЯП умеют на много это лучше чем C#.

Почитайте как устроен конструктор запросов в EntityFramework.

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

мало кто в принципе занимается переводом тяжелого бекенда с фреймворка на фреймворк

Пойнт в том, что тем не менее на гошечку переводят довольно много и часто, а на C# — практически никогда.

Открываю тайну: не пользуйтесь ими.

прикладной продовый код на Asp net (EF, WPF что там еще), который это не использует — в студию!

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

Для означенных элементов over-engineered-abstract-pattern-driven-development опция "использовать правильно" присутствует только в области ментальной маструбации.

А то ж.

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

[pnovikov]

перечисленные ЯП умеют на много это лучше чем C#

Ок. Видимо F# перенял эту фичу и .NET-а. С ним понятно. На остальные — попрошу ссылочку навроде вот этой, приведенной выше. С удовольствием почитаю.

сколько ещё отстойных фреймворков надо освоить, чтобы оценить C#?

Тут где-то читается "ниасилил".

на гошечку переводят довольно много и часто

Я и не отрицаю что на гошечку переводят хелловорлды и CRUD-сервисы. Каждому свое. Однако не стоит из факта, что на гошечку перевели 100 CRUD-сервисов, пару игр и мессенджер делать вывод, что гошечка прекрасно подойдет, например, для банкинга. Цимус C# в том, что он хорошо подходит и для первого и для второго.

прикладной продовый код

Я что-то не понял, для вас унаследоваться от Controller в MVC (сиречь — впечатать : Controller в код, а с решарпером по факту будет : Co<Enter>) — это трата времени? Тут я даже не знаю что возразить. Предстваляю какое для вас мучение Javascript — там же регулярно надо писать function руками :)

Для означенных элементов over-engineered-abstract-pattern-driven-development

Слушайте, если вы не умеете проектировать — ну так и говорите. Не стоит свои проблемы проецировать на меня.

как собственно и любой джун в глубине своего ложного эго

В мои публикации на хабре зайдите хотя бы

[retran]

Джон Маккарти изобрел s-epxressions в далеком-далеком 1958 году.

В мои публикации на хабре зайдите хотя бы

Вполне достаточно того, что вы не в курсе, что квотирование, анализ, генерация и выполнение AST в рантайме изобретены далеко не в дотнете.

[pnovikov]

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

К слову: речь шла о технике использования, когда AST конструируется в compile time, а в рантайме не выполняется, а анализируется. Ну то есть без выполнения. Опять мимо.

[pnovikov]

А затем, друг мой, чтобы например транслировать их в код на другом языке. Например в SQL. Конструкцию вида
users.Where(x=>x.Age > 18).Select(x=>x.Name)
превратить в
SELECT Name FROM Users WHERE Age > 18
и скормить базе данных, если тип users — EF-ный DbSet<>.
А если просто массив — то превратить это в итератор по результатам

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

[pnovikov]

Зачем это делать в рантайме?

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

[pnovikov]

Ну еще иногда эта фича используется во fluent-конфигурации. Например в Automapper можно таким вот изящным образом указать функцию для вычисления проперти при маппинге:

mapper.CreateMap<MyType>()
   .ForMember(x=>x.Age,
   x=>x.MapFrom(d=>DateTime.Now.Subtract(d.BirthDate).TotalYears);

[Lofer]

Зачем это делать в рантайме? Вы можете оттранслировать-отанализировать AST в нужный вам проблемноспецифичный IR во время компиляции, а во время выполнения, не знаю, подставить нужный синтаксис запросов, специфичный для вашей базы. Зачем всё в рантайм-то переносить?

В этом и фишка, что:

• можно в бизнес-логике строить запросы в процессе работы
• на ходу менять базы/источники данных
• провайдеры баз/источников данных занимаются трансляцией объектных выражений LinQ из «абстрактного» в «конкретный»

Обычно есть некторые механизмы оптимизации.

[pawlo16]

Я и не отрицаю что на гошечку переводят хелловорлды и CRUD-сервисы.

Так и запишем: bower, продакшен сервисы гугла и mail ru group — хелловорлды. Вы точно уверены, что после подобных заявлений ваша профпригодность требует дополнительных подтверждений? Интересно, почему они именно на гошечку переходят, а не на С#? ведь казалось бы — Linq, EF как без этого жыть. Может быть потому, что Asp.Net Core сливает вчистую гошечке ? Впрочем, я уже понял, что вы не любознательны

Я что-то не понял, для вас унаследоваться от Controller в MVC… — это трата времени?

Утрируете, реальный продовый код asp net полон всякого рода абстрактных фабрик визиторов по синглтонам и прочих inversion of control-извращений. Я работаю с гигантской кодовой базой, и у меня банально нет ни времени ни желания вникать что от чего наследуется, как перегружается и куда упаковано. А в гошечке на минуточку одна единственная абстракция ввода вывода, единообразно применимая ко всему включая файловую систему, веб-сервер, пайпы

[pnovikov]

реальный продовый код 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-ов. А если я на голом ассемблере напишу веб-сервис, которому гошечка будет сливать подчистую — вы побежите всех агитировать переходить на ассемблер?

[pawlo16]

таких же 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, и это я рассказываю человеку, мнящему себя джедаем! детский сад какой-то :-) )

[TheShock]

Ещё раз — если C# по вашим словам лучше Гоу, то почему они не сделали это на C#?

Очень слабая аргументация. То, что пару сервисов на волне хайпа написали на Гоу (а может и чисто, чтобы поддержать технологию гугла) не означает ничего.

С таким же успехом я могу спросить — почему большинство игр сейчас пишется не на Гоу, а на С++ и С#? Неужели Гоу настолько плох, что на нем нельзя написать полноценную игру и можно писать только примитивные сервисики и искусственные бенчмарки?

[pnovikov]

Стоп, так go — это гугловая технология?

Тэээкс… сдается мне, товарищ нас троллит. Почему гугл переписал свои сервисы на свою же технологию а не на C#? И действительно...

[TheShock]

Go — компилируемый многопоточный язык программирования, разработанный компанией Google

[pawlo16]

пару сервисов

Так это не моя аргументация, я такого не утверждал. Это вы выдаёте желаемое за действительное :-) В гугле, facebook, dropebox, Adobe, Oracle и прочих гигантах сотни, если не тысячи сервисов различного масштаба на Go. А не два :-)

почему большинство игр сейчас пишется не на Гоу, а на С++ и С#?

У вас совсем нет мозгов задавать такие глупые вопросы? О_о Действительно, почему ЯП с GC не вытеснит С/С++ там, где борятся за каждый так процессора? Видимо язык не очень. и из того факта, что Go не завезли в unity, конечно следует что Go на много хуже js и C#, которые в unity есть. Игровых бэкендов на Гоу написано предостаточно если что (в отличие от С#), и их число постоянно растёт.

только примитивные сервисики и искусственные бенчмарки?

так и запишем: youtube и dl.google.com — примитивные сервисы. Спасибо, посмеялся) docker, Kubernetes — не, не слышал :-) Вообще то гоу — системный ЯП, и написать на нём можно что-угодно. В отличие от C#, который обречён прибывать в узкой виндовз десктоп и кровавого энтерпрайза

[Lofer]

В отличие от C#, который обречён прибывать в узкой виндовз десктоп и кровавого энтерпрайза

Это откуда такой пессимимзм?

[pawlo16]

А есть повод для оптимизма? Mono не выстрелил. Xamarin — маргинальщина. Net Core — кому нужен ещё один jvm 10-и летней давности без десктопа и GWT? С тяжёлым, перегруженным хламом, ООП-центрированным веб фреймворком, который в клиент примерно ни как и работает через костыли в виде kestrel. В java-мире же примерно всё то же самое, плюс минус, но на много лучше развито. И kotlin как ЯП лучше C#

[grossws]

Вообще то гоу — системный ЯП

Расскажите, что вы под этим подразумеваете. В моём представлении язык с GC не является системным от слова совсем.

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

[pawlo16]

В смысле Go делает нативный бинарник, которому не нужна ни толстая виртуальная машина, ни тормозной интерпретатор, и в этом смысле ни чем не отличается от сишечки. И в сишечку умеет весьма не плохо. Это означает, что программа на Гоу (C/C++, D, Rust) меньше греет железо при прочих равных, чем С#, java, python и т.п. Что делает её теоретически пригодной для системных задач.

Почему? На D продакшен код не писал, но не вижу причин не относить его к системным.

[grossws]

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

В смысле 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 вполне тому подтверждение.

[grossws]

А также тредов, примитивов синхронизации, медленно появляющихся операций по работе с fs, всяких кусков из stdio и т. д и т. п., но это пока мы говорим о bare metal. Как появился user space — всё гораздо лучше и проще.

[pawlo16]

Оси и менеджеры памяти не писал если вы об этом, но есть опыт низкоуровневого продакшена (дрова, LLVM, embeded). Я исходил из более абстрактного общепринятого понятия — низкоуровневая дёргалка компонентов оси, обеспечивающая работу других программ. Докер и Kubernetes, которые традиционно относят к системным утилитам, подходят под него, но не под ваше, которое имхо ни чем не хуже и не лучше. Факт — низкоуровневый код на Гоу писать проше чем например на C#.

Excelsior JET из набора jar'ников делает нативный код

ну не хватало ещё платный костыль только для того, чтобы нативный код сделать

Первое не доказано от слова совсем

Я переписал 2 ситемы из категории "опердень" на Гоу с С#. Результат — пиковая нагрузка на проц плюс минус та же, но мозгов сжирает меньше в разы — подтверждается различными бенчмарками и легко объясним. Думаю с java была бы принципиально та же ситуация, ибо вряд ли в .net под виндовз JIT компилятор хуже java. Что опять таки видно из бенчмарков Go vs. java. Но это только для тех частей системы, в которых не удалось распараллелить вычисления. В распараллеленных выйгрыш по перформансу при переходе на Гоу, надеюсь вы понимаете — колосальный.

[Lofer]

Я переписал 2 ситемы из категории «опердень» на Гоу с С#. Результат — пиковая нагрузка на проц плюс минус та же, но мозгов сжирает меньше в разы — подтверждается различными бенчмарками и легко объясним. Думаю с java была бы принципиально та же ситуация, ибо вряд ли в .net под виндовз JIT компилятор хуже java.

Мельком глянул описание работы GC «Go 1.4+ Garbage Collection (GC) Plan and Roadmap» — у .Net и Go, разные стратегии работы с памятью. Не удивительно что результаты разные. Если бы задались целью оптимизировать использование памяти в C# — возможностей для оптимизации море.

В распараллеленных выйгрыш по перформансу при переходе на Гоу, надеюсь вы понимаете — колосальный.

Это будет в любом языке нормальном языке.
Не понятно где тут «сильно круче».

[pawlo16]

Я выше упоминал, в Go 1.8 искаропки STW пауза не превышает 100 микросекунд не зависимо от размеров хипа. И для этого не нужно применять сложные оптимизации, выполняемые senior программистами, окончившими специальные полугодовые курсы oracle/microsoft

Это будет в любом языке нормальном языке.

если C# / Java / JS для вас нормальные, то они в этом плане просто сосут. Или вы имеете ввиду некий маргинальный ЯП типа хаскель?

[Lofer]

И для этого не нужно применять сложные оптимизации, выполняемые senior программистами, окончившими специальные полугодовые курсы oracle/microsoft

Ничего сложного нет. Простая как грабли стратегия — нагадил? убери за собой! Кроме тебя никто не знает какая у тебя стратегия работы с памятью.
По моему мнению, как писавшему код как на С++ так и C#/Java, прямая ответственность программиста — управление памятью, а всякие GC — просто сервис, а у дареного коня всегда с кариес :).

если C# / Java / JS для вас нормальные,

Свои задекларированные возможности исполняют? Это дешевле чем «другой обычный/популярный язык»? значит нормальные.

[pawlo16]

Ну то есть вам GC 1) не нужен 2) не важно как он работает. Удачи вам с ручной сборкой мусора

В другой ветке я расписал подробно, почему C# не нормальный язык, а самый что ни на есть отстой для типичных задач бэкенда. Почти всё то же самое относится и к java, плюс jar hell и jvm versions hell

[Lofer]

Ну то есть вам GC 1) не нужен

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

2) не важно как он работает.

Не очень понято, как можно трактовать «прямая ответственность программиста — управление памятью» настолько превратно.
Важно понимать как он работает и учитывать при разработке, если можешь им управлять — еще лучше.

Удачи вам с ручной сборкой мусора

Ох уж это поколение графических интефейсов… совсем обленились люди. Следующее будет «удачи вам с расстановкой точек остановки руками» или «удачи вам чтения отладочных логов глазами»?

[AndreyRubankov]

«удачи вам чтения отладочных логов глазами»

Воу-воу-воу! Если будут логи – это уже признак, что не все потеряно ;-)

Из тех JS команд, с которыми/в которых я работал практически все негативно относятся к логгированию, мотивируя тем, что «есть же дебаггер, зачем нам логи писать? может еще аллертами дебажить?».

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

[greendimka]

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

[AndreyRubankov]

Это вы сильно жестко отзываетесь о людях.

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

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

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

[greendimka]

Может и жестко. Просто из опыта: люди отказывались признавать логические выкладки, если я не показывал им статью из интернета, в которой были бы описаны такие же выкладки. И если такие аргументы, как «нет времени искать статью для подтверждения каждой мысли» и «не на всё ещё написаны статьи» не помогали, то я считал это тупостью. Может и резко. Но никто не отменял способность думать самим вместо поиска доказательств среди чужих мыслей.

[Free_ze]

В другой ветке я расписал подробно, почему C# не нормальный язык, а самый что ни на есть отстой для типичных задач бэкенда

У вас там мягко говоря вкусовщина (конструктив только про стратегию GC) вперемешку с прикольными штучками из Go.

плюс jar hell и jvm versions hell

Что мешает так же класть рядом различные версии библиотек, если это необходимо?

[AndreyRubankov]

плюс jar hell и jvm versions hell

Что мешает так же класть рядом различные версии библиотек, если это необходимо?

в Java нельзя просто взять и положить различные версии библиотек в один класспасс. Это приведет к непредсказуемым последствиям.

хотя, за мои 5 лет в java мире на проектах различной сложности, я еще ни разу не сталкивался с этой проблемой.

[pawlo16]

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

Возьмём для примера перегрузку операторов. Надеюсь не надо объяснять, почему те люди, которые ввели эту синтаксическую опцию в С++, должны сдохнуть и сгореть в аду (могу пояснить на пальцах почему). Можно сказать — типа не хочешь не перегружай, а перегрузил — сам виноват, С++/С# тут не при чём. Но когда делаешь кодеревью джунов и точно знаешь, что там нет перегрузки операторов — жить проще и дышать легче. В противном случае когда видишь оператор "+", откуда взяться уверенности, что ни одному идиоту не пришло в голову его перегрузить? Вкусосвщина? не думаю (с).

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

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

Что мешает так же класть рядом различные версии библиотек, если это необходимо?

мешает 1) нежелание манаться с таким зоопарком 2) возможность его не разводить, перейдя на Гоу

[franzose]

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

Если бы это не было так удобно, это бы и не добавили.

Интересно, почему же те же игры пишут не на вашем любимом Гошечке, а на всё тех же плюсах или C#?

[vintage]

могу пояснить на пальцах почему

Поясните. Я вот ощущаю гораздо больше боли от её отсутствия в некоторых языках.

Но когда делаешь кодеревью джунов и точно знаешь, что там нет перегрузки операторов

А в чём проблема увидеть перегрузку оператора? Или вы ревьюите лишь каждую 10 строчку? :-)

Другой пример — эксепшены, особенно когда они часть АПИ каких нибудь внешних зависимостей.

Их вы тоже не умеете готовить?

[AndreyRubankov]

Поясните. Я вот ощущаю гораздо больше боли от её отсутствия в некоторых языках.

Я не знаю позицию почему это не нравится pawlo16, но в том, что это не самая лучшая фича, я с ним полностью согласен.

Это крутая фича, она позволяет сократить код и позволяет сделать его «красивее» для некоторых очень узких задач. Но, когда вопрос заходит про поддержку проекта, тут начинается боль. Оператор + может быть перегружен несколькими способами и то, какой из них будет вызван, зависит от порядка операндов, если они отличаются по типу.

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

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

[vintage]

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

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

[AndreyRubankov]

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

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

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

[vintage]

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

Не соглашусь. Операторы позволяют писать выразительный код. Иначе бы их в языке не было изначально.

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

Функции тоже можно перегрузить в разных местах. Почему вызов a+b у вас вызывает сложности, а эквивалентный ему a.add( b ) или даже add( a , b ) не вызывает?

[AndreyRubankov]

Для математических операций – это отлично подходит, не спорю.

А вот когда начинают переопределять операторы просто, потому, что это прикольнее выглядит – это уже не особо круто, по-моему.

dispatcher += listener;

dispatcher.addListener(listener);

по-моему второй вариант выглядит понятнее, чем первый.

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

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

Хороший код должен вызывать минимум удивления и минимум WTF?

[vintage]

А вот когда начинают переопределять операторы просто, потому, что это прикольнее выглядит

Ну то есть проблема не в инструменте, а в голове. Такая голова любым инструментом себе ногу отстрелит.

А так и прикольно выглядит и понятно:

dispatcher.listeners ~= listener;

[TheShock]

А так и прикольно выглядит и понятно:

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

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

[AndreyRubankov]

Ну то есть проблема не в инструменте, а в голове. Такая голова любым инструментом себе ногу отстрелит.

– пример взят из опыта работы с .NET, и вот даже в документации есть:
https://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx

А так и прикольно выглядит и понятно:

~ – Побитовая инверсия, это унарный оператор.
~= – такого не существует (по крайней мере в Си).

вот так было бы правильнее:

dispatcher.listeners |= listener;

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

Но вот с удалением тогда не получится так просто и красиво.

[TheShock]

Ну OR как «addUnique» подходит, а какой побитовый оператор тогда подходит под «removeIfExists»? NOT — с натяжечкой, это ведь инверсия и применяется к одному оператору, а не к двум, XOR и AND логично вообще не подходят.

[mayorovp]

В C# для делегатов и событий операторы += и -= являются частью языка, а не какой-то пользовательской перегрузкой. Их надо просто знать.

[vintage]

– пример взят из опыта работы с .NET, и вот даже в документации есть:
https://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx

Это говорит лишь о том, что в МС есть как светлые, так и не очень светлые головы.

~= – такого не существует (по крайней мере в Си).

В D это оператор присоединения.

вот так было бы правильнее:

Ну нет, операция явно не битовая.

[AndreyRubankov]

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

И в реальности перегрузка операторов нужна лишь в крайне редких случаях.

[pawlo16]

Ладно, вот почему перегрузка операторов — один из самых лютых грехов в программировании. Сравните, что проще для понимания:

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

[Free_ze]

И когда функция с помощью эксепшенов передаёт вызывающему коду результаты своей работы

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

[mayorovp]

Оба приведенных фрагмента кода — ужасны. В хорошем проекте такого метода вообще не должно быть.

[vintage]

Когнитивная нагрузка на понимание смысла имени метода "unionWith" на много ниже, чем на "+" между объектами типа Grid.

В нормальный языках для "сложения" и "соединения" используются разные операторы:

1 + 2 == 3
[ 1 ] ~ [ 2 ] == [ 1 , 2 ]

Да, за нарушение семантики оператора, как и за несоответствие названия функции её действиям, нужно бить по рукам.

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

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

странный вопрос. По моему всем ясно, что из контекста "a+b" не очевидно

То есть объявление перегрузки оператора вы не ревьюите?

Благодаря эксепшенам в С++ приходилось тратить уйму времени и сил, чтобы спроектировать элегантный exception-safe код.

Пример приведёте?

[pawlo16]

То есть объявление перегрузки оператора вы не ревьюите?

проверяю, но мне от этого больно, поскольку нужно уточнять тип операндов и проверять наличие перегрузки оператора. В Гоу на строчку "a+b" ни то ни другое делать не нужно и мне от этого хорошо.

Пример приведёте?

Любой код с try catch. Если эксепшен часть апи, то это на самом деле результат вызова апи. Нет ни каких оснований ломать поток выполнения при его появлении кроме намеренного усложенения вызывающего кода

[Lofer]

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

CodeStyle & Design guide определите для проекта и будет вам счастье.

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

А тут что не так или библиотеки не должны «материться» если вы в них пихаете всякую дрянь? :) Как еще библиотека скажет, что «у вас золотые руки, но от бедер растут потому что....»?

[Free_ze]

а горутины — это по вашему вкусовщина, прикольная фишка, или конструктивный шах и мат C# господам

Это прикольная фишка Golang, но не недостаток C#. Мне кажется, что эта штука рано или поздно и в .NET-мире появится.

/* про перегрузку операторов */… Вкусосвщина?

Да, причем из «палаты мер и весов».

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

И тоже не вкусовщина, да?)

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

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

Что мешает так же класть рядом различные версии библиотек, если это необходимо?

мешает 1) нежелание манаться с таким зоопарком 2) возможность его не разводить, перейдя на Гоу

1) да вы 2) же 3) ни дня 4) не писали 5) на .NET, признайтесь сейчас же! (=

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

[pawlo16]

Мне кажется, что эта штука рано или поздно и в .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

[mayorovp]

А что не так этим файлом-то?

[Free_ze]

меня очень печалит dll из закрыой сборки, весящая 20-30 МБ, из которой я использую реального кода максимум пару Кб.

Может тогда стоит просто писать маленькие сборки?

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

Зачем это вообще может понадобиться?) Весь мир стремится к модуляризации, а гошечкины фанаты радуются монолитности.
Ну, ОК, такая возможность есть, осталась единственная проблема: лично вам не нравятся инструменты от MS (=

[pawlo16]

Может тогда стоит просто писать маленькие сборки?

скажите это парням и Редмонда и авторам популярных nuget пакетов. Впрочем у минимизации бинарной сборки для .net есть и обратная сторона — на каждый чих надо тащить десяток пакетов, каждый из которых отдельно просит есть и прописывается в дичайших конфигах, а не в исходниках, как это сделано в Go, после года программирования на котором от размеров бинарников и содержимого конфига asp net core глаза начинают кровоточить, а к горлу подступает тошнота

гошечкины фанаты радуются монолитности.

не знаю чему там радуются фанаты, но я такого ни разу не видел. Проект на гошечке состоит из независимых микро(нано!)пакетов, которые при деплое собираются в корневую папку vendor

лично вам не нравятся инструменты от MS (=

Вряд ли тут дело в моей привередливости и предвзятости. Покажите мне хотя бы одного человека, который после 100 kLOC на Go и C# скажет, что тулчейн гошечки плохой, а большая VS, msbuild и nuget — это не говно говно говно…

[Lofer]

а большая 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 году в альфа версии не делал. Откуда у вас эти все страшилки?

[grossws]

Вы рассказываете такие страшные и странные вещи, которые .Net даже в 2001 году в альфа версии не делал. Откуда у вас эти все страшилки?

Скорее всего, оттуда же, откуда тайное знание о конфигурирования jdk'шного gc xml-ками. От незнания.

[pawlo16]

Да хрен там. Не рассказывайте сказки, я это все в хвост и в гриву мучаю уже 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 кб

И каков общий объём бинарников и процент мёртвого байт-кода в них?

[Lofer]

Да хрен там. Не рассказывайте сказки, я это все в хвост и в гриву мучаю уже 10 лет и немножко знаю, насколько там всё плохо. Например открываешь чистенький .csproj в студии — и оно тебе дописывает туда всякого говна типа ссылок на c:\program files, которые есть только у людей со студией.

И причем тут язык к инфраструктуре и инструментарию? C# вообще никуда ничего не пишет. у него есть .cs файл с кодом. на все остальное ему плевать.
Не нравится студия — не пользуйте. Ecma-334 и Ecma-335 в руки и вперед к приключениям. Делайте идельную тулзу.

Вообще, msbuild, а особенно прилагающиеся скрипты для include — которые студия любит всовывать самостоятельно — это полный треш и угар.

Рекомендовал бы почитать «еще глубжее матчасть». А можно просто попросить MSBuild сгенерить полный лог. Там все сразу понятно что и откуда берется и «а хто энта сделал?!».
Пока все косяки что были при сборке (на моей памяти), это от рукожопости и не способности следовать правилам откуда что тягать в проект и куда складывать. Как только всем раздать люлей, все чудесным образом годами живет без косяков и отлично собирается и локально и билд серверами.
Обычно хватает одного раза на команду и на всю жизнь.
Может вспомнить правило инженера? Если ничего не помагает, прочти наконец инструкцию.

[pawlo16]

И причем тут язык к инфраструктуре и инструментарию?

Да никому даром никакой язык не нужен без инфраструктуры. Никто уже давно не воспринимает язык отдельно от платформы. Ну кроме студентов, хелувордистов, фибоначистов и маструбаторов на трихомонады. Erlang без OTP? Ruby без Rails? Конечно речь об экосистеме. Я очень рад, что с пятого раза вы приблизились к пониманию моего тезиса, что у гошечки с инфраструктурой всё прекрасно, в .net — полная жопа, когда дело касается бэкенда.

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

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

А можно просто попросить MSBuild сгенерить полный лог. Там все сразу понятно что и откуда берется и «а хто энта сделал?!».

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

[pawlo16]

ну прям ми-ми-ми. Ну теперь то у них попрёт софт уровня Etcd, Serf, Consul, Docker, Dl.google.com, Kubernetes, а не только факториал, подвешивающий комп… стоп. stack уже давно, а софт не попёр, даже унылый опердень не могут наваять. упс.

[pawlo16]

То вам утилиты подавай, то в опенсорс выкладывай продакшен-код. Вы уж определитесь, что вам надо в вашей аргументации.

какой ещё опенсорс? Мне ничего не надо. Это вы что-то хотели сказать историей про 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.

То есть рекорды в хаскеле невменяемые в целом, лежат у них плоскими в памяти и каждый раз при апдейте их надо клонировать. По хорошему для моделирования сущностей БД нужно заменить их на мапы и прочие словари с деревом в кишках реализации, что конечно же ни кто делать не будет — проще выкинуть хаскель и использовать ЯП с нормальными мутабельными рекордами. Например Гоу

[pawlo16]

Для опровержения практической бесполезности достаточно наличия случаев с практической полезностью

Нет. Практически полезные инструменты облегчают разработку, а хаскель только усложняет. Ваш личный опыт ни чего не доказывает вообще, поскольку я тоже программировал на хаскеле в касперском и у меня есть все основания считать хаскель бесполезным. Имеем моё мнение против вашего с одной стороны, и объективные данные, которые говорят о том что хаскель мёртвый язык, который почти ни где не применяется за редким исключением в отличие от Гоу, который решает проблемы и приносит успех на рынке практически всем, кто его использует.

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

Чем функторы и аппликативные функторы чужды программисту?

Очевидно тем, что они бесполезны. Единственные не очень удачные костыли, позволяющие кое-как использовать функциональщину в практических задачах — монады. Функиональные языки программирования вообще плохо подходят для решения большинства real world задач

Хотя тут, конечно, можно снова вспомнить про целевую аудиторию Go.

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

А вообще, так можно дойти до того, что возвращать сразу несколько значений из функции — слооооожна

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

рекорды там не плоские, клонировать их целиком не надо, а апдейты дешёвые, но невычисленный апдейт лежит в памяти невычисленным же thunk'ом, что дорого, для мелкого апдейта

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

[VolCh]

в отличие от Гоу, который… приносит успех на рынке практически всем, кто его использует.

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

[pawlo16]

Уверен что есть и такие, но я не видел. Ни один ЯП не даст 100% ной гарантии успеха, слишком много всего влияет. Зато видел лично и читал десятки историй факапов на скала и нодежс от тех, кто наелся этих веществ по самые помидоры.

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

Хейтеры Гоу, умеющие в Гоу, (абсолютное меньшинство, обычно не умеют) не собираются от него отказываться — это говорит о многом. А от скалы и нодежс бегут сломя голову.

[franzose]

включая самое дно php

Ваши заявления чем-то подкреплены? PHP в начале своего развития был не очень, а сейчас это мегапопулярный язык, который активно развивается благодаря сообществу, а не какому-то конкретному вендору. На его основе сделана куча неплохих фреймворков. Да, на нём драйвер по ОСь не напипешь, ну так у него вполне конкретная ниша.

[pawlo16]

Вы так говорите, будто бы PHP до сих пор не сдох потому что он сильно хорош, а не потому, что на нём террабайты легаси и миллионы индусов, дизигнеров и домохозяек остались от тёмных времён. lol

> PHP в начале своего развития был не очень

PHP в начале своего развития вообще-то создал веб каким мы его знаем. А вот нововведения как раз таки и сделали его оверинженерным УГ-м

> На его основе сделана куча неплохих фреймворков

Коллега похапэшник мне регулярно рассказывает про некий «ларавэль». В частности, что практическая (а не заявленная в рекламах) сложность использования данного инструмента ниже, чем для веб-фреймворков на С++, но выше чем для Yesod на Haskell. Остальное про «ларавэль» — исключительно матом. А вы говорите — неплохие. Может, у вас прсото не достаточно квалификации в похфпэ чтобы оценить уровень дна или ничего лучше похапэ не пробовали?

> у него вполне конкретная ниша.

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

[franzose]

А вот нововведения как раз таки и сделали его оверинженерным УГ-м

Например, какие?

Те кто хочет, пишут и на PHP нормально. Помимо «ларавеля» есть Symfony, хороший фреймворк.

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

Было бы странным писать сайты на Go, неправда ли?

Вы так говорите, будто бы PHP до сих пор не сдох потому что он сильно хорош, а не потому, что на нём террабайты легаси и миллионы индусов, дизигнеров и домохозяек остались от тёмных времён. lol

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

[pawlo16]

например ООП с наследованием

«Было бы странным писать сайты на Go, неправда ли?» — это ещё почему? их пишут много, и я в том числе

«сложных SaaS» — а вы уверены что вот прям все эти системы на голом похапэ написаны? потому что то, что видел я, сводится к кондовой веб-морде на похапэ, за которой С/С++/Go/Java и подпорки типа memcached, redis и nginx. Опять таки не вижу как это противоречит моему мнению о похапэ

[franzose]

например ООП с наследованием

ООП не нужно?

[VolCh]

PHP не сдох, имхо, именно потому, что развивается. В том числе заимствуя многое из других стэков. Я пишу на нём без малого 20 лет и по сути сейчас мне в нём не хватает дженериков и демонов "из коробки". Влияние legacy имеется, но это лишь влияние, а не что-то решающее.

[pawlo16]

хаскель мёртвый язык, который почти ни где не применяется
Какая разница, где он применяется?

Выбор программистов — самый объективный из показателей качества языка. Если бы хаскель действительно давал какой-то профит, кроме мифического саморазвития за счёт инвесторов, программситы преодолели бы отвращение к костылным концептам хаскеля, изучили бы его и применяли.

любой говноязык и говнофреймворк хорош включая самое дно php, nodejs, только потому, что на них внезапно тоже кто-то что-то программирует
Но для гов Go вы используете ровно этот аргумент!

Вы бредите. На Гоу написаны десятки полезных программ, удовлетворяющих запросам миллионов людей. А на хаскеле — именно кто-то что-то пишет, не более того.

Решаю на нём уйму задач, от парсинга и реплея логов

Напугали ежа голой жопой. Парсеры любой сложности пишуься даже на сишечке с LEX & YACC, не говоря уже о Гоу, в котором это сводится к скучной рутине. Почему всегда, когда нужно хоть как-то оправдять существование хаскеля, вспоминают парсеры? можно подумать в 17-м году для кого-то проблема написать парсер

до написания компиляторов

и много людей используют ваш компилятор?

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

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

Рекорды там абсолютно плоские и ни какие санки-шманки на это ни каким боком не влияют.
Где — там? В хаскеле?...

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

[pawlo16]

концепции языка не обязаны быть такими, чтобы к ним было какое-то отвращение, которое надо было бы преодолевать.

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

На Гоу написаны десятки полезных программ, удовлетворяющих запросам миллионов людей.

На упомянутых вами PHP и nodejs тоже

ну на PHP писали легаси по тем же причинам, по которым сейчас пишут на js под браузер. а что за мегаприложения на nodejs?

А на хаскеле — именно кто-то что-то пишет, не более того.

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

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

Парсеры любой сложности пишуься даже на сишечке с LEX & YACC

Только с parsec и ему подобными их разрабатывать будет существенно быстрее и надёжнее, потому что repl, типобезопасность и вот это всё.

на сколько быстрее? приведите цифры в человеко-часах из достоверного источника. надёжность гарантируют тесты и бенчмарки, суть которых чуть менее чем полностью не зависит от ЯП и используемых библиотек.

не покажете что-нибудь характерное интересное на Go, желательно, в стиле того же parsec?

https://github.com/valyala/quicktemplate — можете попытаться, но на хаскеле вы никогда не напишете такой же быстрый парсер/лексер. Вообще на Гоу много хорошо зарекомендовавших себя шаблонных движков в продакшене. Думаю имеет смысл вам глянуть рассказ Роба Пайка об идиомах Гоу, применяемых при написании парсеров чтобы понять, почему на Гоу эта работа по соотношению всех факторов делается проще чем в haskell. Ну и парсер-комбинаторы есть сейчас во всех языках, в том числе Go, и пользоваться ими ни чуть не сложнее чем parsec

Почему всегда, когда нужно хоть как-то оправдять существование хаскеля, вспоминают парсеры? можно подумать в 17-м году для кого-то проблема написать парсер

Почему всегда, когда нужно хоть как-то оправдять существование го, вспоминают микросервисы и горутины? можно подумать в 17-м году для кого-то проблема написать парсер и асинхронщину

1) Асинхронщины в Гоу нет за ненадобностью, в Гоу есть одновременность. Если вы не знаете разницу между этими понятиями, вы вообще не представляете что такое Гоу. Писать параллельно выполняющийся код в 17 году на языках без легковесных потоков — таки да, проблема.

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

и много людей используют ваш компилятор?

В корпоративных рамках — вполне

вполне — это сколько? и есть ли у этих людей выбор — пользоваться вашим компилятором или нет?

На каждое изменение любого из полей рекорда данные копирутся из одного блока памяти в другой

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

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

что создаёт дичайшую нагрузку на GC

… что в большинстве случаев не играет роли, потому что эти объекты не уходят дальше nursery area, а аллокации и вообще управление памятью в nursery area

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

[pawlo16]

А если на Haskell — работа остановится навсегда.

А это теперь критерий выбора языка, насколько быстро можно в приказном порядке на него кого-то перевести?

Именно так. Вижу вы понятия не имеете об элементарной диверсификации кадров. Ходите сюда, рассказывать буду для таких же дремучих как вы. Если я как тимлид прниял решение использовать Go, то в последствии мне легко найти или заменить людей в команде. А код на Haskell может читать лишь тот, кто его написал, и то не всегда. Выбирая Haskell, бизнес попадает в зависимость от причуд и капризов малозначительных исполнителей. Если надо вдруг работать в команде, от Хаскеля всех заколбасит. А от Го — максимум будут слышны пара вздохов, но затем народ втянется, привыкнет.

ну на PHP писали легаси по тем же причинам, по которым сейчас пишут на js под браузер.

Так и на PHP до сих пор пишут,

а что за мегаприложения на nodejs?

Да вот хоть рядом Крок писали про их чатбота на nodejs.

Предпочитаете прикидываться дурачком и делать вид будто бы написанные на Гоу kubernetes, docker и сотни известных robust software в области телекоммуникаций равнозначны говносайтикам на похапэ и чатботам на nodejs — ок, вопрос с вашими критериями качества и значимости ПО закрыт.

А можно хотя бы пример такого достоверного источника для какой-нибудь другой пары инструментов для создания парсера?

У вас серьёзные пробелы в общем образовании — к вашему сведению отрицательные тезисы не доказывают. Вы утверждаете, что «с parsec и ему подобными их разрабатывать будет существенно быстрее и надёжнее». Либо обоснуйте своё утверждение чем то более существенным, чем субъктивный личный опыт, либо признайте, что ляпнули не подумав.

А насколько эффективнее, кстати, гошники сишарперов? Приведите цифры в человеко-часах из достоверного источника.

я приводил ссылки в этом треде на блогпосты, в которых люди подробно описывали опыт перехода на Гоу с C# и других языков.

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

вполне — это сколько?

Да, это все те люди, которые пользовались предыдущей версией.

Как я и думал цифра на столько мизерная, что вам даже стыдно её привести))

В Go вы жертвуете персистентностью, например.

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

Понятно, впрочем, откуда идут ваши вздохи. Go недостаточно сложный. Если не сложно — значит это не настоящее программирование.

У меня такое чувство, что то, о чём вы говорите, проще и разумнее на шелле написать.

Может и так. Приведите хотя бы один пример опердня на шелле. И объясните челеовеку, что хаскель не подходит для разработки типичного db-centric софта. С чем я кстати согласен.

[franzose]

Если я как тимлид прниял решение использовать Go

А на каком основании вы это решили?

[TheShock]

Потому что фанатик, очевидно ведь

[VolCh]

Не факт. Я вот тоже чуть его не выбрал, просто начитавшись постов на Хабре :)

P.S. Если бы выбрал, то возможно, тоже сейчас бы фанател :)

[pawlo16]

На основании теории подтверждённой практикой, потому что это модно и хипстеры любят Гоу и потому что гошечка челенжит айдентити у дураков))

[vintage]

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

Давайте я покажу вам кое что по круче: Diet-NG. Компилируется в машинные коды на этапе компиляции. Может чем-то подобным похвастать Go?

[TheShock]

У go вообще крайне неприятный синтаксис встроенного шаблонизатора.

[pawlo16]

quicktemplate всё же несколько другое — он генерит произвольный текст, а Diet-NG — html. Но спасибо, интересно. Думаю, такое в принципе возможно в Гоу, пока не встречал. Хотелось бы сравнить производительность Diet-NG с другими аналогичными движками.

[vintage]

It supports pluggable transformation modules, as well as output modules, so that many other uses are possible.

[vintage]

Уж точно не tree. Оно из семейства yaml/haml/pug/jade.

[Lofer]

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

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

Что я не так делаю с MsBuild? :)

[pawlo16]

сколько человек у вас работает над проектом и какой у него порядок стоимости?

[Lofer]

сколько человек у вас работает над проектом и какой у него порядок стоимости?

До пары миллионов евро-долларов это почти типой проект. Стандартный тим от 5 до 20 человек. Были и десятки миллионов.
Были проекты и годами-десятилетиями шли, и команды менялись не по одному разу.
Типовая проблема: рукожопы не там взяли — не туда положили. От языка не зависит. От тузлов не зависит.

[TheShock]

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

Лол, тогда непонятно чего вы так агитируете за Go? Вот уж где инфрастуктура пока очень слабая.

[pawlo16]

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

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

В этом случае Гоу для вас будет не достаточно хардкорный.и вам надо в какую нибудь джаву или говно-nodejs. Я встречал таких — лечится 2 месяцами строевого программирования на Гоу

[TheShock]

Это в Go то есть тулза для тестирования, в которой даже assert'ов нету? Ха-ха. Она вполне в духе языка.

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

И да, я программирую на Гоу уже больше двух месяцев. Пока что больше разочарований от неоправданных ожиданий, чем комфорта. Когда я после 7 лет на JS переходил на C# испытывал противоположные впечатления.

— зоопарк из несовместимых решений посредственного качества;

Зачем вы описываете мне Go? Вот объясните, почему json парсится через рефлексию и теги, а env переменные при помощи flag — совершенно иначе? Где логика и последовательность? Я уж молчу о том, что эта либа крайне неюзабельна и провоцирует ошибки из-за копипасты. Именно об этом вы говорили, когда писали «несовместимых решений посредственного качества», да?

[pawlo16]

каких ещё assert'ов и зачем нужны сторонние либы для тестирования?

Вот объясните, почему json парсится через рефлексию и теги, а env переменные при помощи flag — совершенно иначе? Где логика и последовательность?

Потому что для flag требуется кастомизация на прикладные структуры данных, реализованная через интерфейс flag.Value, а для json — нет.

эта либа крайне неюзабельна и провоцирует ошибки из-за копипасты

это либа универсальная и простая как палка. Её назначение — покрытие 90% типовых кейсов. Для оставшихся 10 есть несколько более специализированных сторонних либ высокого качества, я использую launchpad.net/gnuflag в некоторых проектах для линупс-стайл флагов.

Именно об этом вы говорили, когда писали «несовместимых решений посредственного качества», да?

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

[Lofer]

Именно об этом вы говорили, когда писали «несовместимых решений посредственного качества», да?

забавно что вы топите тут за 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());

Всего две строчки кода. Даже обезьянка осилить может…

[pawlo16]

Я говорил о Net Core, где нет DataContractJsonSerializer. Там ваш код не прокатит. Вы внимательно читали написанное мной? Я специально уточнял несколько раз, что под виндовз C# — огонь в сравнении с другими ЯП. Даже обезьянка осилить может (с)

А ещё ваш DataContractJsonSerializer хреново готовит Dictionary<string,T> — что-то типа [{"Key":"a","Value":"33"},{"Key":"sdfs","Value":"sdfdsf"}], а нужно [{"a":"33"},{"sdfs":"sdfdsf"}]

[Free_ze]

.NET Core создавался модульным, на минуточку)

[pawlo16]

ну то есть в net core, как в нодежс, чтобы написать хелуворд, надо тащить в проект десяток говнобиблиотек на подобие newtonsoft.json от криворуких хипстеров — это называется модным словом "модульность". отлично например

[franzose]

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

[grossws]

Настоящий шотландец, ага. Если библиотека на го хреновая, то её написал не настоящий гошник, т. к. настоящий гошник говна не напишет. По крайней мере, выкрики местных фанатиков го часто создают именно такое ощущение.

[pawlo16]

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

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

Не понимаю, что вы всем вокруг пытаетесь доказать.

прочесть на пару каментов дальше не пробовали, прежде, чем высказать своё веское мнение?

[franzose]

Тут тред уже настолько разросся, что непонятно, кто кому на что отвечает. Однако из общей суммы ваших комментариев я делаю вывод, что вы очень любите Go и очень не любите другие языки. Ну, по крайней мере C# уж точно.

[pawlo16]

Я не теряю нить разговора, готов ответить за базар и ожидаю того же от тех, кто мне отвечает.

Вывод не правильный. Я не люблю все языки на которых программировал. Не существует хороших ЯП, все они дрянь в той или иной степени, но есть и галимое говно. Elm и Go не люблю меньше, чем C# и js, да.

[Free_ze]

А вы не тащите говнобиблиотеки, берите сразу нормальные)

[mayorovp]

Не рассказывайте сказки, сама по себе студия никаких левых ссылок на Program Files никуда не записывает.

Элементарно разобраться "как msbuild ищет исходники" — задача не тривиальная.

Они вообще-то указываются в элементах <Compile>. Или вы какие-то другие исходники найти пытаетесь?

[pawlo16]

Не рассказывайте сказки

Почесали своё уязвлённое чсв. Полегчало вам?

[franzose]

Вы тут уже на несколько экранов начесали)

[Free_ze]

на каждый чих надо тащить десяток пакетов, каждый из которых отдельно просит есть и прописывается в дичайших конфигах, а не в исходниках, как это сделано в Go

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

Проект на гошечке состоит из независимых микро(нано!)пакетов, которые при деплое собираются в корневую папку vendor

Ого, а что нам это даст? Мы сможем поднимать веб-сервисы на RPi?

[pawlo16]

А в 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% случаев хелуворд, там любой ЯП годится

[Free_ze]

У каждого свое необходимое может отличаться)

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

Звучит как лозунг из буклета, не более того.

[grossws]

Я знаю людей, которые пол года учились прописывать какой-то дичайший XML с настройками GC jvm и теперь могут как-то там оптимизировать его работу, а тех кто не умеет, считают лохами.

Do tell me more about it. В java gc настраивается параметрами запуска JVM, а не xml'ем.

[vintage]

Зная как выглядят параметры в яве… лучше бы это был XML :-)

[grossws]

Местами страшновато, но никто ж не пишет это руками в нормальном варианте, а загоняют в shell-скрипт. При экспериментах можно и потерпеть чуток.

Подавляющему большинству это вообще не надо, хватает дефолтных настроек конкретной версии JVM: в большинстве виртуальных машин конфигурации либо нет вообще, либо она минималистична, как в .net (IIRC, только preset client/server, concurrent или нет и большие объекты).

[vintage]

В D вполне себе есть прямая работа с памятью. И хоть стандартная библиотека D заточена больше под прикладное программирование и зависит от GC, но там также доступна и стандартная C библиотека (ABI совместимость, все дела), и есть куча D модулей, не требующая GC.

[grossws]

Про прямую работу с памятью я знаю. А про no-GC я читал в контексте D несколько лет назад и, на случай если мои представления устарели, решил вас скастовать ,)

А насколько в D комфортно существовать без тех же exception'ов? Есть ли вещи типа option, either/result/variant, чтобы городить обработку ошибок в no-GC варианте?

[vintage]

Я ничего не писал без GC, так что имею лишь общее представление.

Да, с алгебраическими типами там всё хорошо: https://dlang.org/phobos/std_variant.html

[pawlo16]

Rust в эту область плавно заходит и proof of concept в виде ОС Redox вполне тому подтверждение.

В таком случае Go 100% системный ЯП, поскольку на нём так же написана ось. Ну а менеджер памяти пусть пишет г-н Александреску, у меня есть более интересные занятия

[grossws]

В какой момент Linux успели переписать на Go? Или вы про CoreOS только в агитке читали?

[mayorovp]

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

[grossws]

При таком определении почти любой тьюринг-полный язык можно называть системным, если на нём был написан хоть один интерпретатор/компилятор/транспайлер. Java, Scala, Kotlin, CL, Scheme, Clojure, Haskell, Python, Ruby, Perl, Matlab. Можно ещё поискать, но почти на любом мало-мальски популярном языке какой-нибудь, хоть игрушечный, компилятор/транспайлер/интерпретатор писали. Переводить все эти языки в разряд языков системного программирования, на мой взгляд, несколько преждевременно ,)

[VolCh]

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

Вообще любой нормальный язык общего назначения как правило используется для системного программирования. Например, разработка веб-сервера — типичная задача системного программирования, а вовсе не прикладного. А продакшен-реди веб-сервера есть минимум на двух третях языков из вашего списка. Также для нормальных ЯПОН :) характерна на самом языке разработка экосистемы языка, разработка средств разработки — трансляторы, компоновщики, менеджеры пакетов, препроцессоры, таск-менеджеры и т. д., и т. п. — это тоже задачи системного программирования. У JS всё это есть. Более того, часто на сервер-сайде JS решает исключительно системные задачи по взаимодействию кучи различных процессов, написанных на разных языках, крутящихся на разных машинах и в разных сетях, а собственно прикладные задачи решает что-то более классическое или, наоборот, очень экзотическое, а сервисы на JS вполянют роли клея, шин, агрегаторов, диспетчеров, умных кешей и т. п., то есть тоже чисто системные задачи, а не прикладные.

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

[pawlo16]

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

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

[pnovikov]

усиливающийся накал истеричной поучительности

Уверяю вас — это происходит не от офигительного обаяния 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 не принято иметь нормальные среды разработки?

[pawlo16]

от вашего бездумного фанбойства и стремления судить о вещах, которые вы не знаете.
еще раз настоятельно повторяю
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.

[pnovikov]

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

P.S.: HTTP-стек на производительность никто никогда не тестирует, потому что в реальных системах 90% времени уходит на доступ к источнику данных, а не на парсеринг запроса.

[pawlo16]

я понял что вы кроме 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% времени уходит на доступ к источнику данных, а не на парсеринг запроса.

Правильно! Так именно в таких случаях и проявляется вся мощь Гоу — в простом распараллеливании тяжёлого ввода-вывода

[pnovikov]

Слушайте, не надо мне писать портянку с рекламой go. Захочу — в интернете найду и почитаю.

[pawlo16]

Это были разъяснения почему C#, за который вы тут топите, для бэкенда — УГ. А не реклама.

[Ritan]

Захочу — в интернете найду и почитаю.

не осилите, для этого вам придётся нос вывернуть градусов на 180, так он у вас задран

[TheShock]

Я работаю с гигантской кодовой базой

Может, если бы писали на C#, а не на Go, то она была бы не такой гигантской

[pawlo16]

с моих уютных плюсов и с моего уютного хаскеля

у вас стокгольмский синдром парадигмы разработки "чем сложнее, тем круче". В гошечке это лечится за две недели. В С++ я тратил тонны времени на бессмысленные размышления "как правильно спроектировать оператор new и присваивания, конструктор копирования, чтобы результирующий код был элегантным и оптимальным?" (в С++11 ещё конструктор с оператором перемещения добавился для "облегчения" жизни). Но почему-то код обычно получался сложным для понимания, а элегантность ломалась при первой же попытке его расширения под новые нужды. Потом появился Go, где все банально просто, без уродского оверинженеринга, ломающего продуктивность программистов, и получасовой компиляции. Поэтому программисты на Go продуктивнее программистов на C++ в 10 раз. Про хаскель я вообще молчу, ибо как можно всерьёз обсуждать язык, в продакшене не замеченный

[vintage]

Попробуйте любую из вариаций lisp — будете приятно удивлены.

[pnovikov]

LISP — отдельная тема. На нем, вероятно, удобно решать означенную задачу. А вот все остальные — нет :)

[vintage]

А какие — нет?

[pnovikov]

Все остальные задачи написания околобухгалтерской бизнес-логики. Опердень такой опердень.

[vintage]

И в чём проблема на лиспе описывать околобухгалтерскую бизнес-логику?

[pnovikov]

Начнем с того, что я его не знаю :) И учить ради того, чтобы проверить решает ли он мои задачи — смысла не вижу. Мне достаточно факта что никто из моих многочисленных знакомых на лиспе свои задачи (особливо — бизнес-задачи) не решает.

[vintage]

https://ru.wikipedia.org/wiki/Парадокс_воронов

[pnovikov]

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

[vintage]

Да любые. Ну а код страшненький, да. У меня есть идея сделать аналог лиспа, но с более дружелюбным синтаксисом.

[pnovikov]

Кстати, один из сотрудников JetBrains пошел по такому же пути, только с C# и сделал nemerle. Правда он потом уволился и больше коллеги его не видели :)

[raveclassic]

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

[Idot]

https://ru.wikipedia.org/wiki/Парадокс_воронов

А как в ProLog'е этот парадокс решается?

[vintage]

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

[michael_v89]

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

[altai2013]

Ну вот например, какие вещи в C# делают порог вхождения для новичков высоким? Какие простые вещи на C# сделать сложно?

[AndreyRubankov]

какие вещи в C# делают порог вхождения для новичков высоким?

1. Ограничения со стороны языка и платформы, чем больше ограничений тем лучше будет код,
   но для начинающего специалиста это кажется не понятным: «почему я не могу сделать так?», «почему все так сложно?»
2. Обилие языковых фич. Чем больше фич в языке, тем сложнее новичку в нем разобраться.
   Чем больше возможностей сделать одно и то же, тем сложнее будет проект для понимания и поддержки.
3. Linq – удобная штука, но «писать на SQL, пока ты пишешь на C#» – это пенальти для понимания кода.
4. Специфичный ООП, у класса может быть 2 метода с одинаковой сигнатурой, один для класса, другой для интерфейса, и какой из этих методов будет вызван зависит от того, какой тип переменной используется.

ps: Если изучаешь язык по мере его развития, то обилие функционала не кажется таким страшным и каждая новая фича в радость. Но когда язык наращивает сильно много функционала, то новичкам становится очень тяжело его осилить. Это стоит учитывать.

[franzose]

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

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

[michael_v89]

Например: поле для тетриса
Сколько кода будет на C#, включая отладочный вывод, и сколько на это потребуется времени? А на C++ с device context?

[AndreyRubankov]

Справедливости ради, стоит отметить, что тут идет не правильное сравнения.
Вы в данном случае сравниваете JS, как DSL для браузера с языком общего назначения, на котором в принципе можно написать браузер))

Для примера: Сколько будет времени написать бухгалтерскую программу на 1C и сколько на JS?

[michael_v89]

Ну я сравниваю в контексте изучения новичком. Быстро набросал, работает, можно разбираться, как сделать лучше.
Или вот фреймворки взять. На JS или PHP каждый может написать свой фреймворк для каких-то целей. А для C# это в основном крупные системы от больших компаний.

[AndreyRubankov]

Если смотреть на JS, как на DSL для браузера, – согласен, порог вхождения минимальные. Изучил jQuery и уже можешь что-то полезное писать.

Но если взять более современные подходы к JS, с нодой, бабелем, npm и прочими – это ничем не проще того же C# с его NuGet, ASP.NET и WebApi.

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

Что мешает написать фреймворк на C#? Ну кроме того, что все уже и так написано ;-)

[michael_v89]

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

[AndreyRubankov]

Увы, не соглашусь, на самом деле, по сложности – одинаково.
На C# можно ходить в базу через ODBC, это практически так же просто, как и через PDO.
Хотя, на php можно еще и через MySQLi и подобные ходить, но это не лучший способ.

Использовать какие-нибудь Query Builders? Да без проблем как в php так и в C# такого треша валом. ORM? – тоже и там и там есть несколько реализаций.
Проще только от того, что меньше статической типизации? – да, соглашусь, тут проще немного, но на самом деле это не существенная разница.

С нодой, все так же. Да и с Java все так же обстоит.

[michael_v89]

Ага. Только сначала надо это подключение установить. С 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))

[pnovikov]

А про EntityFramework, являющийся kind of дефолтным решением для доступа к SQL-базам в .NET вы, видимо, не слышали?

Да еще и диспоза в вашем коде нет. Печально.

[michael_v89]

Во-во, я ждал такой коммент. Это и есть "дополнительные знания особенностей библиотек и рантайма".

[pnovikov]

EF это даже не особенность библиотеки или рантайма. Это официально рекомендуемая технология доступа к данным. В той же мере, в которой npm является официальным пакетным менеджером для node.js. Вы же не станете писать на ноде, не познав npm?

[michael_v89]

npm надо сравнивать с NuGet, а не с EF. EF можно сравнивать с Doctrine или с какой-нибудь реализацией ActiveRecord. Я запросто могу писать без Doctrine и даже без ActiveRecord, да и в общем-то без npm с composer-ом. Это будет чуть менее удобно, но без особых сложностей, что в общем-то и делают начинающие и малопрофессиональные разработчики.

А чтобы использовать EF надо сначала узнать что он есть и что это оказывается официально рекомендуемая технология. По запросу "php database connection" на первой странице ссылки на PDO, а по запросу "c# database connection" про entity framework написано только один раз на 3 странице. Это не хорошо и не плохо, просто это добавляет порог входа.

[AndreyRubankov]

А еще есть NHibernate, да и другие ORM.
Но это уже выходит за рамки «простого для понимания», так что это точно не в тему.

[AndreyRubankov]

Только сначала надо это подключение установить.

С этим тоже проблем нету, строка подключения берется из файла конфигураций.
А приведенный пример «проблемы», спокойно решается путем NuGet (composer в мире PHP). Так что уверяю вас, это надуманная проблема.

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

На самом деле,

reader

это и есть Строка из из базы, вы к ней потом обращаетесь, чтобы взять нужные поля. И если я не ошибаюсь, есть синтаксис по-проще:

reader["name"]

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

Или на 2 строчки больше кода – это для вас большая проблема?

[michael_v89]

Мне как-то сложно представить, чтобы composer регулировал подключения к БД. Ок, .NET инфраструктура имеет свои особенности. Но это тоже дополнительная информация, которую надо знать.

reader["name"] это внутреннее состояние и после следующего reader.Read() оно изменится. А $row это отдельный DTO, который можно передать куда угодно. И отдельный объект cmd, которому надо свойства присваивать и параметры биндить по одному. Это не 2 строчки кода, это больше логических сущностей. Речь же не идет о "самый простой / самый сложный", речь идет о "проще / сложнее". Вот когда после fetch я получаю готовый $row это проще.

[mayorovp]

Вообще-то, DbDataReader реализует IEnumerable, через который как раз можно получить отдельные строки в готовом виде (кстати, а что такое — готовый вид?):

foreach (IDataRecord row in reader) {
    // ...
}

Еще можно загрузить данные в DataTable:

var table = new DataTable();
table.Load(reader);

[michael_v89]

Готовый вид это значит что я могу работать со строкой как с отдельным самостоятельным объектом, не связанным с конкретным соединением с БД. Если я могу записать этот row в массив и потом передать куда-нибудь, то хорошо. А DataTable это опять же отдельная сущность, что добавляет сложности.

[Lofer]

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

В общем-то это на разных слоях объекты Data Transfer Object и Plain Object.
Кто-то должен из понятий базы данных Table & Row & Field сделать Entity + Property.
Просто решите на каком уровне вы хотите с БД работать и все :)

[vintage]

Думаю я на 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();
}

[michael_v89]

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

[vintage]

Вы думаете это сильно сложнее?

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;
}

Первый раз пишу гуй на этом языке.

[TheShock]

D, все-таки, очень клевый. Жаль, что не взлетел, а вместо него всякие посредственные Go

[michael_v89]

Ну значит думаю можно сказать, что у D порог входа тоже ниже, чем у C#. Хотя надо знать, что означают магические заклинания "q", "parseML" и "enterMessageLoop", и почему их надо вызывать именно там. Вообще, мне JS не очень нравится, я отвечал про разные пороги входа у разных языков.

[TheShock]

А как на счет магических заклинаний «display: inline-block;» «float: left», «script», «append(html);» и сотен других. Я уж молчу об этой странной строчке, которая выглядит как случайный набор символов:

$('.row:eq('+y+') .cell:eq('+x+')')

CSS, к вашему сведению, крайне неочевиден если не знаешь его, а использование inline-block — далеко не начинающий уровень. Я бы еще понял, если бы в том коде грубо использовались table+tr+td, но имитировать таблицу через флоаты и инлайн-блоки — нужен скилл.

[michael_v89]

Я не сказал, что в JS нет магических заклинаний. Вот только если их не указать, все равно работать будет, только отображаться неправильно. Можно постепенно добавлять правила из мануала и проверять результат. И указаны они в отдельном специальном месте. Можно и через таблицы сделать, тоже будет работать. Смысл комментария же не в том, что надо обязательно верстать на дивах. А в конкатенации строк нет ничего магического. Только на C# такой результат все равно получить сложнее.

[vintage]

В вашей версии также нужно знать, что означают магические заклинания "$", "toggleClass" и <script>, и почему их нужно вызывать именно там.

[michael_v89]

Да. Только из этого не следует, что все языки абсолютно одинаковы по сложности освоения.

[AndreyRubankov]

Видать давно вы не начинали изучать 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?)))

[gro]

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

[Ohar]

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

[firk]

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

[elmm]

Давно уже на бэкэнд смотрю преимущественно со стороны клиента, но как мне помниться —
«имеет бешеную популярность благодаря… низкому порогу входа»
с десяток лет назад этот аргумент активно применялся для хейтерства php.
Через десять лет, возможно место javascript займёт новый язык, с низким порогом вхождения, и будет забавно читать хейтеров, приводящих основным недостатком языка — низкий порог вхождения.

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

[firk]

с десяток лет назад этот аргумент активно применялся для хейтерства php.
ну так для php это всё до сих пор актуально, просто все уже привыкли за 10 лет

[gbezyuk]

Если без истерики, то:
* в браузерах массово ничего кроме JS нет
* на сервере JS появился потому что хотелось один и тот же код гонять и там и там, но см. предыдущий пункт
* ни для чего кроме предыдущего пункта на сервере JS применять не рационально — изоморфный рендеринг, и хватит
* если на JS пишут всё подряд (читай — бэкэнд/API), это почти всегда говорит о незнакомстве разработчика с альтернативами, и более ни о чём. В частности, это ничего не говорит о JS — он для бэкэнда не создавался никогда.
* Хотя ES4 обладает рядом спорных характеристик, ES6 — действительно крут, в нём очень много очень сладкого сахара.
* Трудные времена рождают сильных людей. Преодоление монополии и косяков ES4 дало вебдеву очень многое. И чем слюной брызгать и про красоту Haskell рассказывать (ну да, неплох), лучше порадоваться ES6.

[VolCh]

Вполне знаком с альтернативами, но для веб-сокет сервера для трансляции событий, которые генерирует PHP выбрал ноду. Так же её выбрал для предоставления graphql API, агрегирующего данные с Restish сервисов на PHP и C#. Для первой задачи ещё Go серьёзно рассматривал.

[raveclassic]

Расскажите, почему не Go в итоге? (сам с ним работал)

[VolCh]

Рынок труда в Киеве не делает Go хорошим выбором для "одноразовых" задач.

[alan008]

хайп-драйвен-девелопмент

драйв, дроув, дривен

[forester11]

Хайп node.js имхо — оправдан.
1) Во-первых комуникация в одну нить на асинке — тренд который начал поднимать голову уже достаточно давно, и показал себя очень хорошо даже в плюсах (boost::asio), и в С (libevent). Просто стало очевидным что много потоков абсолютно не требуется для создания эффективных и масштабирующихся серверов и клиентов, и все эти треды и связанная с ней синхронизация — пустая трата времени. Я думаю это открылось во времена роста P2P, когда каждый нод в P2P сети должен тянуть тысячи (ну сотни минимум) соединений не ставя на колени средний ноутбук/комп. Ну и остальной спорт «сделать сервер который осилит 10к клиентов DC++» на дешевом/домашнем железе.
2) Гробы-фреймворки со своими новыми языками и строгим контролем владельцев, в текущих условиях устаревают уже на момент своего релиза. Смотрим на Java, С#, что там нового вышло — это все уже покрылось плесенью, и оно покрылось плесенью уже на момент выхода. Модель Node.JS в этом плане опять правильная — берем существующий язык, где войны браузеров сделали очень эффективный рантайм, делаем минималистичный рантайм базовый, и даем абсолютно открытый NPM с «уклоном в хаос» (никаких стандартов модулей как было замечено). В результате язык развивается очень быстро, революционно быстро (история вариантов промисов таже, автор заметил), так что пенсионеры неуспевают и создают такие эмоциональные статьи.

Имхо, если смотреть на Node.JS с точки зрения «мне нужен устоявшийся фреймворк, чтобы 5 лет назад уже все придумали и стабилизировали, и еще 10 лет ничего не меняли» — то конечно Node.JS это ужас. Если смотреть с точки зрения поиска самого современного фреймворка с передовыми технологиями — то пожалуй лутше ничего нет, ибо модель «стабильности» устаревает на момент релиза. То что клиенты хотят Node.JS в результате вполне ожидаемо, это те клиенты которые хотят нового.

[Labunsky]

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

[pnovikov]

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

[Labunsky]

разные вещи

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

[Lofer]

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

Серьезно? Т.е там нету работы в разных потоках, нету точек синхронизации? Магия ?!

[pnovikov]

Есть. Однако это два разных инструмента для решения разных задач. В частности асинхронность — это работа исключительно через Thread Pool и потоки вы не контролируете, равно как и не можете настроить свой дизайн потоков в приложении. Она работает по модели "поставить в очередь задачу — присвоить коллбек — делать что-то другое пока задача выполняется". Многопоточность — она именно о том, чтобы 2 и более задач выполнялись одновременно, а вы имели возможность собирать результаты, получать уведомления из этих потоков и т.п.

Технически (на примере C#) асинхронный ввод-вывод, как уже было сказано ниже, реализуется через completion ports и не имеет ничего общего с тредами как таковыми. Отличие от многопоточности очевидно.

Как-то так.

[Lofer]

Технически (на примере 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 :)
Лень, двигатель прогресса.

[mayorovp]

Далеко не каждая задача (Task) выполняется в пуле потоков. Те, которые построены на базе TaskCompletionSource или аналогичных механизмах, не привязаны ни к какому потоку.

[AndreyRubankov]

В частности асинхронность — это работа исключительно через Thread Pool

Чем отличается тредпул (из коробки, ака «асинхронность») от пула потоков, которые девелопер будет создавать для «многопоточности»?

по-моему, тут что-то не так с определением, и то, о чем вы говорите, это больше походит на реактивность (но с реактивностью это vintage нас рассудит).

Асинхронность, может быть только в случае, когда не используется CPU, сейчас самый простой пример — это IO-bound операции. Все остальное — это вариации многопоточности.

[pnovikov]

Я имел в виду что вы не можете явно начать тред и явно его грохнуть — API тредпула этого не позволяет, асинхронный подход этого не предусматривает. Само собой IO-bound разруливаются другими инструментами, но интерфейс использования тот же.

[Lofer]

Я имел в виду что вы не можете явно начать тред и явно его грохнуть

В свое время theadpool создавал потоки «по запросу». Но это внутренняя оптимизизация.

API тредпула этого не позволяет,

Так у него другая задача — предварительно созданные thread(s) и их последовательное переиспользование, а не создание каждый раз заново и удаление.
Экономия на времени создания потока, а что вы будете делать с этими потоками и когда — это полностью ваша проблема.
Можете руками такое сделать без особых проблем (руками в массиве поместить с десяток потоков предварительно созданных и периодически дергать их) — производительность будет таже самая.

[pnovikov]

Просто стало очевидным что много потоков абсолютно не требуется для создания эффективных и масштабирующихся серверов и клиентов

Посмотрите исходники nodejs. Я мог не так понять, но вроде как он тупо берет новый поток из тредпула на любой асинхронный вызов. Если я понял правильно, то потоков этот подход создает еще больше, чем традиционные подходы. В остальном libevent и asio — это хорошо. Но делать на этом подходе АБСОЛЮТНО ВСЕ — несколько перебор.

Гробы-фреймворки

За Java не скажу, но С# весьма резво развивается. Новая версия языка выходит чуть ли не каждый год, а с открытием компилятора (Roslyn) — дискуссии по вопросу "что добавить в язык" идут чуть ли не ежедневно. При достаточной квалификации — можно сделать хоть свой билд компилятора и запилить туда все, что угодно. В NuGet-е каждый день появляется что-то новое. При том никакого уклона в хаос — в большинстве случаев скачанное прекрасно работает и выполнено идеологически в более-менее едином стиле. Достаточно заметить что асинхронность на completion ports (async/await) появились в C# несколько раньше чем в ES. Как и стрелочные функции, которые появились, например, еще до того как мир узнал что такое AngularJS. Так что кто быстрее развивается — я бы поспорил. И при том это не просто "фича для галочки" или Haskell-way — фича есть, но она сложная и поэтому ей никто не пользуется. Наоборот, все изменения внедряются на хорошем инженерном уровне и гармонично вливаются в язык.

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

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

[mayorovp]

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

Не на любой, а только на те, которые невозможно сделать по-другому (ну, или можно, но еще не сделали). Например, работа с DNS...

[pawlo16]

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

[yogurt1]

Очередная статья о JavaScript, автор которой JavaScript толком-то не знает
crossenv опечалил, пакет правда снесли уже. Но автор не указал этого, потому что хайп ему важнее

[rboots]

Плохому танцору, как оказалось, даже язык мешает. 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

[Movimento5Litri]

На данный момент 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) язык прожил вообще без изменений.

[serg_p]

Это вы Луркморе не читали :)

[asvahagnas]

ас

[Scf]

nodejs — это современная альтернатива питону.

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

[igrishaev]

Все так.

[ekubyshin]

че то текст совсем ни о чем. Какие то выдуманные проблемы.

Давай по порядку:
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, чем проблема языка. В любом языке можно найти кучу пакетов с отвратительным качеством.

Вообще, конечно, не понятно, как такой текст прошел из песочницы.

[gooddaytoday]

(Евангелист пришел в комментарии, все как вы любите)

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

Typescript.

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

Typescript.

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

Typescript.

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

Typescript.

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

Ммм...Typescript?

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

Опять Typescript.

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

async/await, прямо как в любимом многими C#. Теперь и в Typescript.

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

[greendimka]

Лично я обожаю TypeScript. Но у него есть фатальный недостаток — изобретено в Microsoft — а это значит, что религия использовать не позволяет.
И не смотря на то, что на дворе уже не средневековье — приходится применять насилие и жестокость, чтобы заставить перейти с JS на TS. Потом радуются и облизываются, но без революций — никак не хотят облегчать себе жизнь.
Из собственной практики предполагаю, что быть евангелистом TypeScript'а — дело нелёгкое.

[gooddaytoday]

Я где-то читал подобное:

TypeScript создали в Microsoft. Язык прекрасен и поэтому странно, что он появился именно там.

[pnovikov]

Сюрприз-сюрприз. В Microsoft так-то много классных вещей появляется.

[greendimka]

Тсс. Вы сейчас ходите по грани оскорбления чувств верующих.

[pnovikov]

Если честно, то я на чувства верующих активно сру — сколько себя знаю. В моей текущей команде мы разрабатываем решение для склада на технологиях MS — С#/MVC/MSSQL и несколько собственных наработок. Мы подняли систему до используемого состояния, from scratch, за 4 месяца усилиями троих разработчиков. Т.е. через 4 месяца после начала разработки — в неё уже была внесена первая тысяча продуктов. Проблемы js-ников, go-шников, джавистов и уж тем паче приверженцев php/ruby/python нам неведомы. У нас лично никаких нерешаемых проблем нет и нам хорошо. :)

[yorick_kiev_ua]

Очень забавно читать коментарии «это всё неправда, это всё истерики, JS — торт… ну в смысле на typescript, конечно, и c no-any еще, ну а как иначе-то?».

Да-да, тот самый ts, который строго типизирован и с анализатором кода. Тот самый, который перед каждым колбеком делает захват контекста «var _this = this», в котором явно указываешь тип возвращаемого значения и опечатки или забытый return(если я правильно понял претензии автора) ловятся при компиляции, с человеческими классами и так далее по списку.
Тот самый TypeSctipt, «идеалогчески» ближе скорее к java/C# чем к js.

Ребята, а вы разве не понимаете, что это всё равно, что сказать «да, автор, you're damn right, твои претензии оправданы и TypeSctipt взлетел именно потому, что решает часть этих проблем, а без него в сыром виде это(js) кушать невозможно»?

[ekubyshin]

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

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

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

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

[yorick_kiev_ua]

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

Я, признаться, не готов разговаривать на таком уровне аргументации.

[akuzmin]

«Зуб даю, все поголовно бы писали на Haskell и рассказывали бы друг другу за чашечкой смузи покручивая спиннер о новых монадах и аппликативных функторах от Facebook» — хаха, сказано хорошо. Но фишка в том, что эти «компании, которые вливают деньги в JS», это никакой не заговор. Это одно из проявлений эволюционных процессов, где в условиях нормальной конкуренции JS стал более перспективен, чем Haskell. Если вы пытаетесь с этим спорить и обвиняете в этом компании, то вы просто занимаетесь боем с ветряными мельницами, сопротивляетесь действительности, природе человека, мира и всего такого.

[fukkit]

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

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

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

Странно читать хейтеров, сетующих что и классы то тут не настоящие и типы кучерявые, и почти любую типовую задачу 15 пакетов из репозитория решают с различной степенью бажности, а стандартная библиотека размазана по десятку топовых в этом месяце пакетов npm. Ребята, вы выползли из своих уютных замшелых нор в быстро меняющийся мир! Здесь вот так. Нам тоже это не нравится, но лучшей доли никто пока не предложил, может быть вы?

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

Ребята, давайте жить дружно! JS как явление — великолепен, хайп и мисьюз чего бы то ни было напротив — явление убогое и недостойное. Увлекайтесь первым, а не вторым. Свобода лучше, чем несвобода. Как говорится, /тхеард

[taujavarob]

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 действительно явление (С)

[taujavarob]

Парадигму FP он решил поддерживать жесткой дисциплиной кодирования. А не изобретать очередной парадигменный костыль (поддержания конкретной парадигмы — одной из многих в JavaScript ) типа TypeScript или тянуть отдельные библиотеки в код.

Вообще наблюдается явный тренд — не изобретать новые языки, а брать JavaScript и соблюдать жёсткие правила написания кода (стиль, что писать, как писать, как не писать, что не использовать (классы, к примеру и наследование) и т.д.… ).

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

На это обычно возражают — что за всеми кодировщиками не уследишь, ибо «один в лес, другой по дрова» — и в коде будет каша из парадигм (где ООП, где FP, где потоки, где Redux, где mobX и ...) — да, нужен Сталин нужна твёрдая дисциплина кодирования и всяческие надсмотрщики помощников для её поддержания.

Свободно же можно выбирать не язык, а дисциплину кодирования — и вот этих самых помощников для её (дисциплины кодирования) поддержания.

А язык уже выбран! (С)

[eugenk]

Поменял сейчас typescript на Scala.js и дико этим доволен. Что же касается популярности js, причина мне кажется в бешеном удобстве броузера, как среды исполнения программ(что его тащат в бакенд, согласен, тупизм). У меня понимание этого пришло 4 года назад и было это так. Был в одном из моих проектов некий алгоритм компрессии звука(одна из многочисленных вариаций adpcm), который мне нужно было портануть с adsp-2185 на FPGA. В ходе портирования я обнаружил в старых исходниках ошибку. Когда начальство осознало, что ошибка там действительно имеет место быть, меня попросили написать декодер, по возможности минимизирующий последствия этой ошибки в кодере. Для этого разумеется пришлось по ходу работы рисовать кучу графиков и их анализировать, что я делал на матлабе. А потом возникла задача представить мои результаты совсем уже высокому начальству. Спрашивается что делать? Из кабинета оно выходить не изволит. Что, матлаб ему на комп ставить? Тогда я взял в зубы d3.js и за пару дней написал веб-страничку, загружающую мои файлы с тестовыми данными и строящую графики. Причем интерактивные, с кучей фич, что на матлабе сделать сильно труднее. И мне это настолько понравилось, что я забросил QT, JavaFX и т.п, и пишу сейчас (для своих целей)графические интерфейсы только броузерные.

[scoffer-by]

Что-то в этом мире сдохло…

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

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

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

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

[taujavarob]

самолет братьев Райт тоже выглядит нелепо по-сравнению с современными лайнерами и истребителями.

Почему нелепо. Два крыла, мотор, колеса — принципиально ничего нового.