LINUX.ORG.RU

Ответ на: комментарий от th3m3

Не знаю, треды такие не видел. А может видел, но уже не помню. Пишу я на связке php/python/go уже достаточно давно и в упор не вижу каких-либо явных преимуществ у python перед php (у php перед python тоже не вижу). По крайней мере, если речь о веб-разработке. На питоне писать приятнее (лично мне), но больше каких-то явных преимуществ я не вижу. Опять-таки если рассматривать вебню. Я это начал не холивара ради, а реально интересно.

dimuska139 ()
Последнее исправление: dimuska139 (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

Под покрытием тестами я имею ввиду не что-то абстрактное, а именно «покрытие» — каждая часть кода выполнилась. Не во всех возможных комбинациях, а просто выполнилась, хотя бы раз.

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

И такой инструмент есть. Для JS. Увы, для питона мне его найти не удалось.

Поэтому на JS я могу защититься от простых мелких ошибок. А на питоне — нет.

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

А вот был бы код покрыт тестами — сразу бы все ошибки нашлись! 🙂

Ещё есть всякие `node debug` / `node inspect`, смотря что отлаживать.

anonymous ()
Ответ на: комментарий от byko3y

Руби? PHP? CL? Racket? Они постарее JS будут, а до питона почему-то не дотянули.

Э?? Ты серьёзно считаешь руби, CL и Racket менее «гибкими и фичастыми» чем питон?

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

monk ★★★★★ ()
Ответ на: комментарий от byko3y

У JS есть неустранимая нерасширяемость, которая, например, не дает vue.js полноценно отслеживать изменения переменных, как то установка атрибута объекта или значения в массиве по индексу.

Там же есть спецметоды set и get. Делай атрибуты через них и следи. Массив тоже можно свой поверх встроенного сделать.

monk ★★★★★ ()
Ответ на: комментарий от byko3y

Руби? PHP? CL? Racket? Они постарее JS будут, а до питона почему-то не дотянули.

Они все моложе питона, потому и не дотянули. Кроме CL. Но тут сыграл роль второй пункт: «более удачный стартовый синтаксис» в питоне.

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

Тьюринг-полнота еще не делает язык языком общего назначения.

Верно. Языком общего назначения JS делают области его применения.

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

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

То, что кто-то решил натягивать сову на глобус, еще не значит, что сова стала общего назначения.

Хех. Да, сову JS пришлось немного растянуть, пришить ей пакетный менеджер, но натянулось же!

Я не говорю, что питон плох. Наоборот, он хорош! Потому он и популярен. Сейчас популярны всего три вида языков:
1. legacy, языки которые первыми заняли какую-то нишу, и держатся за счёт наработок в ней
2. языки, активно продвигаемые корпорациями
3. питон.

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

anonymous ()
Ответ на: комментарий от byko3y

Уже давно идет тенденция на ввод классов к кобол

Они даже в стандарте 2002 года уже есть. Так же как и Юникод и возможность использовать значения с плавающей точкой.

А актуальный стандарт для Кобола от 2014 года.

monk ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

А вот был бы код покрыт тестами — сразу бы все ошибки нашлись!

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

Ещё есть всякие `node debug` / `node inspect`, смотря что отлаживать

Это вспомогательные инструменты.

byko3y ()
Ответ на: комментарий от monk

Там же есть спецметоды set и get. Делай атрибуты через них и следи. Массив тоже можно свой поверх встроенного сделать.

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

Ну типа да, в ES6 добавили вот такую штуку:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obje...
Но это уже новый объект, который в себе хранит старый. Причем, на ES5 это не портируется, естественно, потому что Proxy должно быть встрено в движок.

byko3y ()
Ответ на: комментарий от anonymous

Они все моложе питона, потому и не дотянули

То они моложе, то они старше - тебя не поймешь.

Корпораций за ним нет, а сообщество слишком маленькое, и не вытягивает.

И за PHP корпораций нет. Дальше что?

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

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

И отбирать программистов JS будет не у PHP и не у жавы, а именно у питона.

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

byko3y ()
Ответ на: комментарий от monk

Они даже в стандарте 2002 года уже есть. Так же как и Юникод и возможность использовать значения с плавающей точкой.
А актуальный стандарт для Кобола от 2014 года.

Актуальный стандарт кобола - это J2SE 5.0, а всё остальное - это попытка к нему приблизиться, не потеряв совместимости со старым кодом.

byko3y ()
Ответ на: комментарий от byko3y

То они моложе, то они старше - тебя не поймешь.

Э, вроде, всё понятно. Питон популярнее «за счёт возраста, и более удачного стартового синтаксиса». А раз питон старше, то остальные моложе, не?

И за PHP корпораций нет. Дальше что?

Дальше он будет умирать, сдавая свои позиции сначала руби, потом питону, теперь JS-у, очень-очень медленно, потому что под него много наработок. См.п.1 из списка.

Нет никакой разницы в этом плане между построчно покрытым тестами кодом и не построчно покрытым.

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

    if no_data or flags["DOSOMEHTING"]: # <- тут опечатка
        do_something()
Если в тесте этот код выполнится с no_data=True, то flags не считается, зато в рантайме с no_data=False он сгенерит ошибку. Покрытие тестами эту ошибку бы поймало.

anonymous ()
Ответ на: комментарий от monk

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

def get_pid_env(pid):
    with open("/proc/%s/environ" % pid) as f:
        return dict( line.split('=',1) for line in f.read().split('\0')[:-1] )

из недавнего, например: Как построить Гамильтонов путь в матрице?

g = graphs.Grid2dGraph(10,10)
for i,j in [ (1,7), (2,1), (4,4), (7,2), (7,7), (9,4) ]:
    g.delete_vertex( (i,j) )
answer = g.hamiltonian_cycle(algorithm='tsp')
answer.show()

Встречная просьба: можно код на каком-то из этих языков, который сложно написать на питоне?

И, да, что значит «сложно»? Может мне и на ассемблере это не сложно сделать...

anonymous ()
Ответ на: комментарий от byko3y

Нода возникла как раз из-за того, что на рынке возник избыток JS-макак, которых некуда девать. Нода это любопытный феномен. Ты пробовал на ней писать? Не какую-то илитную хурму типа транспиляторов, а простую макакичную «бизнес-логику» типа крудов? Это же такой адок, что просто капец. По-моему намного проще макаку обучить другому языку, чем пытаться из нее выжать что-то вменяемое на этом песдеце.

anonymous ()
Ответ на: комментарий от anonymous

Если в тесте этот код выполнится с no_data=True, то flags не считается, зато в рантайме с no_data=False он сгенерит ошибку. Покрытие тестами эту ошибку бы поймало.

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

byko3y ()
Ответ на: комментарий от anonymous

Нода возникла как раз из-за того, что на рынке возник избыток JS-макак, которых некуда девать.

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

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

byko3y ()
Ответ на: комментарий от byko3y

JS-макаку более-менее адекватную можно за миску риса нанять

Это где такие водятся? Регулярно слышу, что специалисты такого профиля просят минимум две-три миски(условно говоря)

anonymous ()
Ответ на: комментарий от anonymous

JavaScript уже победил. Это самый популярный язык. Стоит взглянуть на npm и его количество пакетов. Кто этого не понял - остался в 90-ых, скажем так. Следующая итерация js - это сделать «компилируемый js». Чтобы компилировался аля в сишечку с рантаймом как у go. Вот скринь моё сообщение и проверишь лет через 15 - «изобретут» 😀

menangen ★★★★★ ()
Ответ на: комментарий от menangen

JavaScript уже победил. Это самый популярный язык. Стоит взглянуть на npm и его количество пакетов. Кто этого не понял - остался в 90-ых, скажем так.

Так и запишем, языки, которые реализуют форматирование строк внутри стандартной библиотеки – это остатки девяностых. Всё прогрессивное человечество качает однострочные лефтпады со встроенными майнерами и рекламой из npm.

anonymous ()
Ответ на: комментарий от anonymous

И отбирать программистов JS будет не у PHP и не у жавы, а именно у питона.

JS до сих пор выезжает на веб-обезьянках, которые не хотят учить второй язык.

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

anonymous ()
Ответ на: комментарий от dimuska139

У Python сильнейшие привязки к всяким machine learning инструментам. У php их нет, так что из альтернатив только Java и Scala, но на них быстро лепить медленнее. Так что Python самое то в этой нише.

peregrine ★★★★★ ()
Ответ на: комментарий от menangen

Не будет js топом, там ООП плачет кровавыми слезами. Ну и вообще js ужасен и жив только из-за огромного количества веб-макак.

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от anonymous

Регулярно слышу, что специалисты такого профиля просят минимум две-три миски(условно говоря)

Ну у нас тут сидит как минимум один человек, который ровно за миску пишет на ноде.

byko3y ()
Ответ на: комментарий от menangen

Стоит взглянуть на npm и его количество пакетов

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

dimuska139 ()
Последнее исправление: dimuska139 (всего исправлений: 3)
Ответ на: комментарий от menangen

Стоит взглянуть на npm и его количество пакетов

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

Следующая итерация js - это сделать «компилируемый js»

Как ты думаешь, почему до сих пор Java в основном выполняется с JIT-компиляцией?

byko3y ()
Ответ на: комментарий от dimuska139

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

отдельный пакет для функции inArray

Он нужен не для этого. Якобы он работал быстрее чем indexOf.

no-such-file ★★★★★ ()
Ответ на: комментарий от anonymous

Ну вот на Racket

get_pid_env

(define (get-pid pid)
  (call-with-input-file (format "/proc/~a/environ" pid)
    (lambda (f)
      (make-hash
        (for/list ([line (string-split (port->string f) "\0")])
          (match (regexp-match "(.*?)=(.*)" line)
            [(list _ a b) (cons a b)]))))))

Второе — просто вызов библиотечной функции. Было бы так:

(define g (directed-graph (for/list ([i 10] [j 10]) (list i j))))
(for ([ij '((1 7) (2 1) (4 4) (7 2) (7 7) (9 4))])
  (apply remove-edge g ij))
(define answer (hamiltonian-cycle g #:algorithm 'tsp))
(displayln answer)

Могу и реализацию hamiltonian-cycle переписать. Будет примерно так же, как на питоне.

Встречная просьба: можно код на каком-то из этих языков, который сложно написать на питоне?

Пример сайта на Racket

#lang web-server/insta
; start: request -> response
(define (start request)
  ((phase-1 0) request))
 
; phase-1: request -> response
(define ((phase-1 n) request)
  (define (response-generator embed/url)
    (response/xexpr
     `(html
       (body (h1 "Phase 1")
             (a ((href ,(embed/url (phase-2 (add1 n)))))
                ,(format "click me! ~a" n))))))
  (send/suspend/dispatch response-generator))
 
; phase-2: request -> response
(define ((phase-2 n) request)
  (define (response-generator embed/url)
    (response/xexpr
     `(html
       (body (h1 "Phase 2")
             (a ((href ,(embed/url (phase-1 (add1 n)))))
                ,(format "click me! ~a" n))))))
  (send/suspend/dispatch response-generator))

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

monk ★★★★★ ()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от menangen

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

Это только из-за бурно растущего фронтенда, который впрочем уже устаканивается. Ситуация примерно как с пхп в нулевых, но где теперь ваш пхп? Когда переходят на стадию допиливания и длительной поддержки, такое говнище как жоэс и похапэ уже не прельщает никого. Популярность костыля typescript уже намекает на острую востребованность нормальных инструментов в нише жоэс.

Следующая итерация js - это сделать «компилируемый js». Чтобы компилировался аля в сишечку с рантаймом как у go.

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

anonymous ()
Ответ на: комментарий от peregrine

js ужасен и жив только из-за огромного количества веб-макак.

Так это в основном верстальщики с жквери. Толку с них? А с нормальными кодерами ситуация точно как везде: их мало, и они стоят дорого. За ваяние на ноде чего-то сложного тебя вообще обдерут как липку.

anonymous ()
Ответ на: комментарий от menangen

Следующая итерация js - это сделать «компилируемый js»

Это называется reasonml. Хочешь — компилируй в нативный бинарник, хочешь — в жабоскрипт через bucklescript.

Чтобы компилировался аля в сишечку с рантаймом как у go

Проще компилировать из других языков (того же rust) в wasm. Или в жс.

У других языков, как правило, более интересные системы типов (а не как в typescript) и более умный оптимизирующий компилятор, чем у всего, что есть в js-экосистеме. Ну и работает всё это на пару порядков быстрее, чем babel.

x3al ★★★★★ ()
Ответ на: комментарий от x3al

У других языков, как правило, более интересные системы типов (а не как в typescript) и более умный оптимизирующий компилятор, чем у всего, что есть в js-экосистеме. Ну и работает всё это на пару порядков быстрее, чем babel.

Ты заблуждаешься по поводу оптимизации. Хорошо написанный код на JS имеет производительность, сравнимую с хорошо написанным кодом на жаве, потому что по сути выполняемые команыд мало чем отличаются: те же самые объекты, те же самые классы, те же оптимизации локальных вычислений в стэк. Да, медленнее, чем какой-нибудь Go, и тем более языки без сборщика мусора. Но все равно очень быстро. Это и стало одним из ключевых факторов широкого распространения JS за сферу своей специализации, которого не случилось, например, у питона, потому что его нельзя настолько заоптимизировать - иначе бы питон уже давно победил всех и вся.

byko3y ()
Ответ на: комментарий от byko3y

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

У жавы статическая типизация и распакованные данные (unboxing). У JS приходится перед любой операцией проверять тип.

monk ★★★★★ ()
Ответ на: комментарий от monk

У жавы статическая типизация и распакованные данные (unboxing). У JS приходится перед любой операцией проверять тип.

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

byko3y ()
Ответ на: комментарий от byko3y

не адепт, но скажу. Преимущество ноды в том, что она есть. А это электрон и все что на нем. ЯП можно хаять в хвост и в гриву, но альтернатив-то все равно нет.

Переход на что-то другое будет, через WebAssembly, но постепенно.

olelookoe ()
Ответ на: комментарий от olelookoe

А это электрон и все что на нем. ЯП можно хаять в хвост и в гриву, но альтернатив-то все равно нет.

Для меня это звучит как «А это фастфуд и все его производные. Сою и пальмовое масло можно хаять в хвост и в гриву, но альтернатив-то все равно нет.» 8-Е.

Переход на что-то другое будет, через WebAssembly, но постепенно.

JVM в браузере уже была. Похоронили.

monk ★★★★★ ()
Ответ на: комментарий от monk

Для меня это звучит как «А это фастфуд и все его производные. Сою и пальмовое масло можно хаять в хвост и в гриву, но альтернатив-то все равно нет.» 8-Е.

Звучит неважно, но альтернатив все равно нет )

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

Ну и потом - не состоит же фастфуд целиком из сои и пальмового масла, не все так плохо )

JVM в браузере уже была. Похоронили.

Не совсем то же самое, что WebAssembly, не?

olelookoe ()
Последнее исправление: olelookoe (всего исправлений: 1)
Ответ на: комментарий от olelookoe

Преимущество ноды в том, что она есть. А это электрон и все что на нем

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

ЯП можно хаять в хвост и в гриву, но альтернатив-то все равно нет.

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

byko3y ()
Ответ на: комментарий от monk

Переход на что-то другое будет, через WebAssembly, но постепенно.

JVM в браузере уже была. Похоронили.

Несоответствие инструментов Javascript современным требованиям уже очевидно, и появление новой технологии неизбежно произойдет. Вопрос заключается лишь в том, какая именно это технология будет.
Флэш, например, очень хорошо взлетел и доминировал над вебом долгое время. По сути WAsm - это что-то похожее на подход флэша, только более радикальный. Например, в отличие от JVM в WAsm нет сборщика мусора и безумной прожорливости в плане памяти - это были весьма важные изъяны, отбивавшие охоту пользоваться жава аплетами.

byko3y ()
Ответ на: комментарий от byko3y

Несоответствие инструментов Javascript современным требованиям уже очевидно

А можно пример, в чём несоответствие и как оно должно быть (на примере «правильных инструментов»)?

no-such-file ★★★★★ ()
Ответ на: комментарий от byko3y

На мой взгляд электрон - это полнейший провал

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

olelookoe ()
Ответ на: комментарий от no-such-file

Несоответствие инструментов Javascript современным требованиям уже очевидно

А можно пример, в чём несоответствие и как оно должно быть

Нынче наметилась мода на богатые веб-приложения. Проблема в том, что JS имеет свои убогие типы и динамичность, и банально ограничивает разраба одним этим языком. Ограничения языка исправляются транспайлерами, убогость динамических типов довольно эффективно затыкается через JIT, но все равно раза в полтора-два проигрывает тому же asm.js, скомпилированному AOT, а сам asm.js с AOT где-то в 1.3 раза медленнее WebAssembly. К слову, советую заценить вот такой бенчмарк, в котором один из движков (SpiderMonkey) показывает намного ниже производительность тупо из-за особенностей реализации:
https://github.com/sniklaus/experimental-raytracer
То есть, тяжело гарантировать, что оптимизация отработает правильно и ты не получишь внезапно многократную проскадку производительности.

Еще можно сделать виртуальную машину на жаваскрипте, но тормозить это будет адово, и тогда овчинка не стоит выделки. Таким образом, нужно фундаментально иное решение в обход JS, которое позволяло бы развязать руки разрабу фронтенда и при этом было бы кроссплатформенно. Гугл уже пытался делать свой
https://ru.wikipedia.org/wiki/Native_Client
Мозилла разрабатывала asm.js, в итоге asm.js перерос в WebAssembly, и гугл отказался от Native Client в пользу WebAssembly.

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

byko3y ()
Ответ на: комментарий от olelookoe

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

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

byko3y ()
Ответ на: комментарий от byko3y

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

Что ты не понимаешь? Те же люди и электрон недолюбливают.

anonymous ()
Ответ на: комментарий от byko3y

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

После прогрева JIT — возможно. Но у JIT не всегда есть информация о всём коде.

В JS нет средств для AOT-компиляции. Ну, есть https://prepack.io/ в early development stage and not ready for production use just yet и всё.

x3al ★★★★★ ()
Ответ на: комментарий от anonymous

Что ты не понимаешь? Те же люди и электрон недолюбливают.

Ну а как же

Преимущество ноды в том, что она есть. А это электрон и все что на нем. ЯП можно хаять в хвост и в гриву, но альтернатив-то все равно нет

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

byko3y ()