JS vs Python для web?

А что скажете про .NET Core? Не работали с Asp.Net? А про ruby (ruby on rails) ? Или рубистам трудно найти работу, в Питере сейчас 90 вакансий

А по node там же express в топе?

MEAN - MongoDB, ExpressJS, Angular and NodeJS. Я бы правда Angular заменил на Vue. А вот Express - если для просто API, то да. Если для web-сокетов, то Socket.io. Если для hiload, то Moleculer.

Посмотрю обязательно. А насчет wasm я спрашивал по причине того, что если будет доступ к dom то на других языках можно будет делать frontend? Учитывая сколько хейта вокруг JS, то wasm это обход JS. Тот же blazor у мелкомягких

Тут есть проблема - старые браузеры. WASM плохо с ними дружит. Да и пока я не видел ничего вкусного кроме Elm (дико высокий порог вхождения) и TypeScript (обратносовместимый, с дико низким порогом вхождения) для frontend. Скорее всего когда-нибудь их перенесут на WASM, но в остальное (хотя что мешает сейчас продолжать пользоваться транспилером?)… Я так скажу, можно вполне проклясть человека, который на том же Rust сделает SPA, т.к. у JS есть экосистема и best practice, большое сообщество и куча инструментов. У того же «Rust в браузере» этого очень мало, а где-то нет вообще.

А нужность в браузере Python/Ruby/$lang_name. Вот вам это зачем? Чего конкретно не хватает в JS? Если просто не нравится язык - то это не аргумент в реальных задачах (в них пишется решение на эффективном стеке - бизнесу не интересно получить продукт через пару лет), так вкусовщина и схоластика.

Спасибо за адекватные пояснения. А что скажете про .NET Core? Не работали с Asp.Net?

Я так скажу, можно вполне проклясть человека, который на том же Rust сделает SPA, т.к. у JS есть экосистема и best practice, большое сообщество и куча инструментов. У того же «Rust в браузере» этого очень мало, а где-то нет вообще.

Я думаю что все не так страшно. Основная сила в HTML5 и CSS, множество фреймворков и компонентов построено на них. Остается только доступ к браузерным API - bindgen это предоставляет.

Что касается практик, фреймворки вроде yew просто повторяют тот же Elm в точности, ничего не переизобретая. Вот тут прямо видно откуда уши ростут https://github.com/yewstack/yew/blob/master/docs/getting-started/build-a-sample-app.md. Я бы смело пробовал в командах где основной бекенд язык Rust для каких-то систем поменьше, админок и тд.

MongoDB

...а потом понадобятся связи между моделями...

Значит не верно с выстроены модели.

Если пихать реляционный подход в не реляционные БД, то да - связи понадобятся. Если подходить изначально к NoSQL правильно - не понадобятся.

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

Спасибо за адекватные пояснения. А что скажете про .NET Core? Не работали с Asp.Net?

Лично я не работал, кроме как «для себя, на потыкать палочкой». Но знакомые очень хвалили сам .NET Core/Asp.Net (да и по туториалу выглядит вкусно, хоть и кондово). На счёт спроса на рынке - очень хороший. По крайней мере обе «дотнетера» находят работу достаточно быстро (Меняют просто потому что хотят больше золота).

О дивный новый мир без связей и отношений…

NoSQL - это «эмуляция» документов. И для части задач подход правильный.

Был же кейс какого-то опупенного западного кинопоиска, когда через пол-года заказчик сказал, что нужно добавить какую-то пустяковую фичу… И всё, перепроектирование и перенос бэкэнда на SQL.

А пруф и подробности можно? Слышится как редкостный бред, ибо сменить на работающем проекте БД и подход - это как переписать почти с нуля.

То, что они перевели на SQL может значить два случая: а) они не умели(ют) выстраивать грамотный не реляционный подход; б) они взялись за реализацию очень узкой и специфичной задачи (есть некоторое количество задач). Как правило грамотную реляционную архитектуру проще выстроить, чем грамотную не реляционную архитектуру.

А Deno не пробовали? Это ведь тот же JS или TypeScript только работают через Rust? Фреймворков как express нет?

А вот можно компилировать в wasm на том же rust/go/C++, а на JS можно? Есть же AssemblyScript. Как оно?

А какой смысл в Deno? Он пока не нужен. Особенно в разрезе того, что они будут выпиливать tsc и менять на свой велосипед. А на чём это работает… ну Rust есть там и что? Какие плюшки именно пользователи Deno получают, кроме +100 к ЧСВ? ИМХО ничего.

Условно говоря - пока deno не станет таким же используемым как NodeJS смысла в Deno очень мало. Да и большая част его плюсов выглядит мягко говоря сомнительными профитами, чтобы вот прям переходить туда.

А вот можно компилировать в wasm на том же rust/go/C++

Так я же говорю - можно всё. Задача какая? Просто WASM стоит применять только при условии, что очень упёрлись в скорость. Преждевременная оптимизация вредит, есть же принцип. Скорости NodeJS хватает для любой типовой задачи. Вот в узкое место встанете - тогда и пробуйте.

Go тащить в Node… Я даже не знаю как назвать. Брать убогий язык и заменять им не убогий язык (пусть и кривой) - это современный тренд?

Есть же AssemblyScript. Как оно?

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

JS настолько размазан… Я не знаю НИ одного человека кто знает и React и Angular и VUE…. Максимум палочкой потыкал

JS настолько размазан… Я не знаю НИ одного человека кто знает и React и Angular и VUE…. Максимум палочкой потыкал

С++ настолько размазан… Я не знаю НИ одного человека кто знает и QtWidgets и QML и Gtkmm и wxWidgets… Максимум палочкой потыкал.

C# настолько размазан… Я не знаю НИ одного человека кто знает и Winforms и WPF и UWP и Avalonia и Xamarin.Forms и GTK#… Максимум палочкой потыкал.

и т. д.

Полностью согласен. Правда C++ создавали умные люди. А C# индусы. многие библиотеки выглядят как потуги человека который хочет сходить в туале, но у него запор. Возьмите https://dev.epicgames.com/docs/services/en-US/Interfaces/Auth/index.html

С JS это выглядит «С шашками на танки». Сам создатель ноды ушел. Мечатся как курица без головы не имея плана. Да есть успехи, но когда я изучал реакт я от их парадигм (с большой буквы называть или с малой в JSX) офигел. Вы сдурели? Вы с одной стороны лепите КУЧУ кода. С другой пытаетесь добавить сахара. Сахара столько что диабет уже. В этом плане Svelte нравится. Но сразу скажу я не спец. Все что я вижу это бурление без толка.

Ну и еще раз про C# Я как то писал курсовик знакомой. Там был ADO.NET Ну купил книгу. НИ ОДИН пример не заработал. НИ ОДИН. Моя либа для dbf написанная в 2000 году для python 1.4 под DOS все еще работает (правда под 3-й не пробовал… надо адаптировать будет, времени нет. устал)

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

Сам создатель ноды ушел

И ушел он в Go, если не ошибаюсь. Думается, что Go - более удобная замена NodeJS, но этот миф легко развеивается, если попробовать в разработке и то, и другое. У них в некотором смысле разная область применения. Так что это не показать, человек просто сменил направление разработки. И это не потому, что Go лучше, чем NodeJS, а просто потому что Go для его задач больше подходит.

Вы с одной стороны лепите КУЧУ кода. С другой пытаетесь добавить сахара.

В Go, куда ушел создатель NodeJS, кучи кода поменьше, думаешь? Гошка гораздо более многословна. А запилить на ней то же API со всякой валидацией эндпоинтов на 200-300 - боль и страдания. Гошная система проброса ошибок заставляет писать одну и ту же конструкцию тысячи раз.

Ну а вообще NodeJS c React, Angular и VUE всё-таки мало связан. Да, язык тот же, но подходы к разработке совершенно разные.

Я совсем не хвалю Го. Лично я считаю его мертвороженным как например Эсперанто. А вот про подходы да. Руби как раз и губит DSL. Каждый раз разный подход. Я об этом твержу постоянно. JS не тот язык который имеет смысл изучать в долгосрочной перспективе. Да вы должны его выучить. Но если вы впадете в кому, через 10 лет это будет ДРУГОЙ язык. Язык останется, а вот инфраструктура нет… Это как с С#

Ну да, js быстро развивается весьма. И всё в нём очень быстро устаревает. В то же время то же самое можно сказать даже о современном Питоне. Появляются горы асинхронных фреймворков, которые сменяют друг друга и устаревают.

Go, возможно, мертворожденный, но есть ли годные альтернативы в его нише? Вот, скажем, нужно запилить быстрый сервис, который может обрабатывать кучи сетевых запросов и при этом жрать мало памяти. Java - монстр и порог вхождения высокие. C#, в принципе, аналогично. Асинхронные JS и Python жрут памяти много, кроме того потоков нет. Есть асинхронность, но она не панацея. Кроме Go ничего и не остаётся по сути. По крайней мере, из того, что более-менее популярно.

У Го ОЧЕНЬ узкая ниша. Вы как раз и назвали ее. Вопервых 99% сервисов это веб сервисы которые берут данные по HTTP и пишут в СУБД. При этом узким горлышком является или сеть или СУБД. Кроме того у Го есть свой планировщик потоков который волшебным образом меняют от версии к версии. SO до сих пор нет. В итоге запуск 10 сервисов приводит к 10 расходам памяти. Го сделан Гуглом, для Гугла… А знаете ли Гугл ОЧЕНЬ специфическая фирма и второй такой нет.

Это я для того чтоб объяснить свое отношение к ГО. Я с огромным энтузиазмом его принял, но после трех недель поиска ошибки в программе у специалиста по Го (специалист искал) я офигел. Причем я ошибку ведь нашел… Приколы с автоматическим перечитыванием конфигов с помощью inotify меня прям порадовали (inotify ведь совершенно бесплатен)

Ну у Go узковата ниша, да. Но всё же замечу, что в последнее время разработка смещается в сторону SPA. На фронтенде какой-нибудь React/Angular/Vue, а бэкенд - просто API. Соответственно пилить API можно почти на чём угодно, в том числе и на Go. То есть в данном случае эту нишу можно смело делить между Go/Php/Python или NodeJS. А так, конечно, в Go всяких Laravelей и Джанг не завезли - и для проектов, где много кода, этот язык использовать не сильно удобно.

после трех недель поиска ошибки в программе у специалиста по Го

При всех недостатках Go система проброса ошибок там ведь довольно деревянная и надежная. Если делать по-нормальному, используя errors.wrap и не используя подавление ошибок (нижнее подчёркивание), то «наверху» можно получать своего рода стектрейс, глядя на который ошибку найти довольно легко. Но если речь идёт о всяких многопоточных ошибках типа работы с одной переменной из нескольких потоков без мьютекса, то тут, конечно, это не поможет. Впрочем, а разве такие ошибки в других языках, кроме Go, как-то проще выявляются?

В итоге запуск 10 сервисов приводит к 10 расходам памяти

А где не так? Это ж нормально.

Приколы с автоматическим перечитыванием конфигов с помощью inotify меня прям порадовали

Я использую viper. Там тоже есть функция перечитывания конфигов, но она опциональная.

Все развивается по спирали. Вспоминайте мейнфреймы и как логика переползла на клиента. А потом появился веб и логика опять поползла на клиента. Да там где я отгреб был вайпер и я НЕ ПОНИМАЮ зачем все кто его использовал врубал inotify. Это что бесплатно? Вы гарантируете консистентность состояния? Это ведь тяжело сделать….

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

Да. Но это культура разрабов. У нас перешли на го потому, что обосрались в python. Разрабы просто сказали «ой python плохой»… А так я полностью согласен

ой python плохой

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

Да как угодно. Нашли для главного кучу презентаций от гугла и перешли на Го. Я тут уже писал. Короче есть фид который инсертит в SQLITE данные получаемые через вебсокет (практически без обработки). Ох тупит он. И память жрет и виснет (я залез и сразу вопрос нафига в sqlite) Второе там автокоммит. Я за 5 строк создал буффер и сначала пихал 500 записей в буффер, а потом инсертил и БАЦ пайтон прога стала быстрее гошной.

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

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

Впрочем, а разве такие ошибки в других языках, кроме Go, как-то проще выявляются?

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

И что произойдёт твоя скриптуха упадёт или у сервака питание внезапно отсохнет?

Такое себе решение. Кролик напрашивается.

Я тебе больше скажу. О том, что фид пишется в SQLITE НИКТО кроме разраба не знал. Я там подевопсил и обнаружил, что бац отказала система после переноса на другой сервер. А перенос был какой? Правильно из гита дернул, развернул. А отсутствие кэша за месяц (тех самых sqlite) сделало все неработоспособным. Волосы у меня поседели…

Да и с памятью. Если мы получаем строку, парсим JSON потом генерим JSON другой структуры и так 10 раз (ну может и не 10) и в итоге мы заняты этим постоянно. Вопрос. А нельзя распарсить 1 раз и сгенерить 1 раз?

Если хочется с большей вероятностью участвовать и разрабатывать новые фичи, создавать какие-то новые проекты - Go для бекэнда хороший вариант. Шанс ковыряния в старом говне мамонта, где все написано через Ж - достаточно мал. Даже если захотеть, то на Го сложно написать хреновый код.

Язык достойно лаконичный, работает быстрее джавы/с#, тем более питона. Многопоточность из коробки.

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

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

Даже если захотеть, то на Го сложно написать хреновый код

Но это же не так. Более-менее большой проект на Go, например, API эндпоинтов на 100, невозможно написать так, чтобы его можно было нормально поддерживать. Go достаточно молод, и в нём нет ярко выраженных шаблонов проектирования и нет крутых фреймворков на код которых можно ровняться, в результате чего все пишут кто во что горазд. Возьми 10 проектов на Go, написанных разными людьми - все они совершенно разные, а код читается хреново.

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

Язык достойно лаконичный

Можно пример лаконичности в Go? Как раз этот язык абсолютно НЕ лаконичный и многословный.

работает быстрее джавы/с#, тем более питона

Насчёт питона - естественно, а в каких конкретно задачах Go быстрее джавы и c#? Я это допускаю, но ни одного нормального бенчмарка, подтверждающего эту версию, я не встречал. Акцент тут на слове «нормального».

но когда проект надо будет горизонтально масштабировать - то на Го это сделать труда не составляет

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

JS настолько размазан… Я не знаю НИ одного человека кто знает и React и Angular и VUE…. Максимум палочкой потыкал

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

И JS не размазан. Кому надо, тот пишет на TS.

Язык достойно лаконичный, работает быстрее джавы/с#, тем более питона. Многопоточность из коробки.

Хрень же пишешь.

Я пробовал TS. Лично мне не понравилось очень. Я знаю много кого кому не понравилось. Статика на самом деле не решает проблемы. Статика не нарисует вам тип «Возраст» или «Фио» или много что еще. А если ваша задача просто получить данные и передать их дальше (или из БД в веб или из веба в БД) то статика вообще только мешает. Вы должны знать какие данные вы получаете. А так вам по большему счету всеравно. Прекрасные падения кластера серверов на Го радовали меня по ночам….

Если писать на TS хоть немного правильно (а это узнавать то, что ты получаешь от сервера), то поддержка - песня. Интерфейсы, dependency injection, декораторы - вот это наше всё.

И да, всё сейчас резко, бешенно переписали на TS.

И да, всё сейчас резко, бешенно переписали на TS.

Я имею в виду всё то, что ты перечислял выше - React, Vue и многие «взрослые» либы.

А если не узнать?

«any» спасёт всех

Ага. Вот мы и приплыли. Я такое в C# вижу пачками…

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