Яка мова програмування найкраща для Back-end?

Alex Asd 09.11.2024 02:34

Assembler

Roman Gorodishcher Principal Engineer в Twilio 04.11.2024 20:49

Зацікавив напрям Backend-у

lol

guest 03.11.2024 21:47

Python & C++.

Seven Berg 04.11.2024 19:05

нееет для нативных приложений лучше WASI+Rust!

guest

Seven Berg 06.11.2024 15:47

Сразу пишу, шё это не чат ГПТ!

Seven Berg

Олександр Мощенко 06.11.2024 15:50

«вчора», «хвилину тому» = «сразу»
чатгпт, який запустили на електронному термометрі.

Seven Berg

Seven Berg 06.11.2024 16:15

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

Seven Berg 02.11.2024 20:16

Вот почему джс рвет все остальные языки программирования для веб приложений. Разработчики могут использовать один и тот же язык и синтаксис для всего стека приложения.
Это упрощает обучение и позволяет разработчикам быть более универсальными. Некоторые части кода могут быть легко переиспользованы между клиентом и сервером.Это особенно полезно для валидации данных, форматирования и бизнес-логики.JavaScript работает с JSON напрямую, что упрощает обмен данными между клиентом и сервером.Node.js хорошо подходит для приложений с высокой конкурентностью благодаря своей асинхронной природе.
Это может обеспечить лучшую производительность для определенных типов приложений по сравнению с PHP. npm (менеджер пакетов для Node.js) предоставляет огромное количество библиотек и инструментов.Многие из этих инструментов могут использоваться как на клиенте, так и на сервере. Возможность создавать приложения, которые могут рендериться как на сервере, так и на клиенте, улучшая производительность и SEO.Node.js отлично подходит для приложений реального времени благодаря встроенной поддержке WebSockets или юзаем сокет.ио. Инструменты для разработки, тестирования и отладки могут быть общими для клиентской и серверной частей. Думаю этого достаточно. Надо, 1000 раз подумать при выборе стека технологий, нужно вам юзать ту же пыху или нет!

Trip Trip 02.11.2024 21:58

Навіщо порівнювати ноду з php якщо є .Net Core?=) Цікаво буде послухати про переваги ноди, окрім «одна мова на бек і фронт».
Тому шо я писав і на ноді і на .net core а ще на Python flask. І з цього всього нода і фласк це тупо забивання цвяхів мікроскопом=)

Seven Berg

Seven Berg 02.11.2024 22:12

На 122-ой такое говорили, шё на клиенте должно быть только три вещи, html,css,js, остальное все вторично...

Trip Trip

Trip Trip 02.11.2024 22:53

При чому тут клієнт к ноді і пхп?)
І що таке 122?=)

Seven Berg

Seven Berg 03.11.2024 17:50

Использование JavaScript как на клиенте, так и на сервере (через Node.js) предлагает значительные преимущества по сравнению с использованием PHP на сервере и JavaScript на клиенте. Это упрощает разработку, улучшает производительность и способствует более эффективному обмену данными между клиентом и сервером.

Trip Trip

Олександр Шпак Oarsman в Self Employed 03.11.2024 23:19

Это упрощает разработку

Ніт, не спрощує. PHP має набагато потужніші вбудовані можливості, особливо що стосується роботі з DOM та всіма суміжними технологіями: xPath, XSLT (хай йому грець), XML, тощо. При використанні nodejs додається купу головного болю на кшталт постійного слідкування за оновленням сторонніх бібліотек та модулів.

Деякі речі дійсно на JS робити простіше й ефективніше, наприклад імплементувати вебсокети, але таких переваг не сильно багато.

Seven Berg

Seven Berg 04.11.2024 18:39

Почему хлопцы? Например, Node.js предлагает множество мощных библиотек для работы с DOM и XML, таких, как Cheerio и jsdom. Эти библиотеки также обеспечивают функциональность, аналогичную PHP, и позволяют эффективно манипулировать HTML и XML документами. Cheerio, например, использует синтаксис jQuery(хотя несколько устаревший), что делает его удобным для разработчиков, знакомых с этой библиотекой.

Олександр Шпак Oarsman в Self Employed 04.11.2024 21:14

Почему хлопцы?

Тому що баклажани. Смачні такі, з фіолетовою шкіркою.

Например, Node.js предлагает множество мощных библиотек для работы с DOM и XML, таких, как Cheerio и jsdom.

Вони написані на JS, що робить їх неефективними по споживанню пам’яті, продуктивності та іншим речам.

Seven Berg

Qaraimam 04.11.2024 05:38

А если на клиенте js не используется, тогда что?

Seven Berg

Seven Berg 04.11.2024 18:32

Например?

Qaraimam

Qaraimam 05.11.2024 02:03

Например, клиент написан на чём угодно другом, и не под браузер.

Seven Berg

Qaraimam 03.11.2024 02:29

Тут явный недостаток выставлен как преимущество. Благодаря своей асинхронной природе node.js очень плохо подходит для приложений с высокой конкурентностью. Более того, это ограничение ещё кардинально влияет на архитектуру в целом. Сейчас поясню. Поскольку приложение работает только в 1 поток, то чтоб увеличить перфоманс, что делают? Запускают параллельно новые ноды, а больше ничего там сделать и не смогут, это единственный вариант. В то время как многопоточное приложение может в один инстанс заменить весь кластер с джаваскриптом. Смотрим далее. Поскольку нод с джаваскриптом целая куча, то соответственно они дёргают базу данных на каждый чих. В то время как многопоточное приложение может просто брать данные из кэша внутри приложения, даже не из редиса там какого-то, то есть совсем ничего не дёргать на чтение. И перфоманс многопоточного инстанса сразу вырастает на порядки по сравнению со всем кластером на джаваскрипте. Смотрим далее. Поскольку у многопоточного приложения — монопольное использование базы данных, в отличие от кластера, то следовательно оно может буфферизовать запись и апдейты. То есть не писать апдейты в базу на каждый rest-запрос, а копить изменения в буфере, и скидывать его периодически в базу данных одной транзакцией. Перфоманс при этом растёт экспоненциально по сравнению со всем кластером в целом. Не на порядок, а в тысячи и десятки тысяч раз.

Seven Berg

Witness 03.11.2024 07:25

Благодаря своей асинхронной природе node.js очень плохо подходит для приложений с высокой конкурентностью.

это фраза не соответствует истине. Как раз с конкуренстностью у ноды все замечательно в силу ее асинхронности. А в вебе основные задержки на I/O а не CPU bound. а для такого рода задач мультитредовость (ака паралелизм) не имеет никакого преимущества.
и перфоманс у джавы (я ж так понимаю намек на нее) будет такой же как и приложения на ноде. При условии одинаково прямых рук у разработчиков.

P.S.

Тут явный недостаток выставлен как преимущество. Благодаря своей асинхронной природе node.js очень плохо подходит для приложений с высокой конкурентностью.

а еще неплохо бы вам выучить базовую терминологию, что такое «конкурентность», и что такое «параллелилизм» с «асинхронностью»

Qaraimam

Qaraimam 03.11.2024 13:48

Асинхронный код может выполняться только в 1 потоке, иначе это уже не асинхронный код. А значит в асинхронном коде в каждый момент времени может выполняться код только 1 хендлера. Ну и смотрим. Когда начинает выполняться хендлер, первым делом что делается? Парсится jwt-токен, а там sha256 хэш, который считается дольше, чем выполняется весь код с бизнес-логикой. А может быть вообще подпись, которая считается в 250-300 раз дольше чем хэш. Это хорошо, если будет дёргать C++ код со вставкой на ассемблере с AES-инструкциями, но этого может и не быть. И всё это делается в 1 потоке. Только за счёт одной авторизации асинхронный код уже нагружается. Плюс ещё парсинг json, до выполнения кода бизнес-логики.

Witness

Dmitriy Mozgovoy JavaScript / NodeJS Developer 03.11.2024 15:11

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

Технічно асинхронному коду взагалі все рівно де виконуватися- на сусідньому потоці, чи на rpc сервері за 1000км, якщо це чиста функція і не треба доступу до верхнього скоупу.

И всё это делается в 1 потоке.

Кожен в світі ноди знає, що криптографія і інші важкі API операції виконуються Сішним кодом на внутрішньому пулі потоків.

Qaraimam

Witness 03.11.2024 16:25

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

Qaraimam

Олександр Шпак Oarsman в Self Employed 03.11.2024 16:10

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

Це задача БД, а не рівня застосунку. Якщо ви зберетеся багатопоточний застосунок використати в кластері, то будете однакові проблеми з нодою.

Qaraimam

Seven Berg 03.11.2024 17:53

Вы утверждаете, что из-за асинхронной природы Node.js он плохо подходит для приложений с высокой конкурентностью. Однако, на самом деле, асинхронная модель позволяет Node.js эффективно обрабатывать множество одновременных соединений, особенно в I/O-интенсивных приложениях. Это делает его отличным выбором для веб-приложений, которые требуют высокой пропускной способности и быстрого отклика.Хотя Node.js работает в одном потоке, это не означает, что он не может масштабироваться. Используя кластеризацию, вы можете запускать несколько экземпляров Node.js на разных ядрах процессора. Это позволяет распределять нагрузку и эффективно использовать ресурсы системы, что значительно улучшает производительность при высоких нагрузках.Вы упоминаете, что многопоточные приложения могут кэшировать данные внутри приложения, в то время как Node.js «дергает» базу данных на каждый запрос. Однако это зависит от архитектуры приложения. В Node.js также можно реализовать кэширование данных (например, с использованием Redis или встроенного кэша), что позволяет уменьшить количество запросов к базе данных и повысить производительность. Вы правы в том, что многопоточные приложения могут буферизовать записи и обновления для оптимизации работы с базой данных. Однако это также возможно и в Node.js с помощью различных стратегий кэширования и пакетной обработки запросов. Например, можно реализовать механизм очередей или использовать ORM-библиотеки, которые поддерживают транзакции и пакетные операции.

Qaraimam

Anton Plotkin Executive Director в WebCEO 04.11.2024 00:40

Формулювання як в чата джіпіті якогось)

Seven Berg

Олександр Шпак Oarsman в Self Employed 04.11.2024 00:43

Хтось чат-бота тут тренує...

Anton Plotkin

Trip Trip 04.11.2024 02:01

Блін, ну нам двом не може «здаватися». Я теж прийшов до такого висновку=)

Anton Plotkin

Олександр Мощенко 04.11.2024 09:10

в такому великому шматкові тексту жодного разу не згадано 122. Я думаю це можна використовувати як маркер: є 122 — це севенберг чваниться, нема 122 — це бот.

Trip Trip

Seven Berg 04.11.2024 18:42

122-ая forever!

Seven Berg 04.11.2024 18:41

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

Anton Plotkin

Олександр Шпак Oarsman в Self Employed 04.11.2024 21:15

Навіщо? В тебе немає власної думки?

Seven Berg

Seven Berg 04.11.2024 23:19

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

Олександр Шпак Oarsman в Self Employed 04.11.2024 23:31

Так твоя задача щось бездумно наколупати на форумі, чи сформувати власну думку, чомусь навчитися, поділитися досвідом? Яка цінність твоїх постів для інших? На рівні нуля. Бо це не твоя особиста думка.

Seven Berg

Qaraimam 04.11.2024 05:52

Ну вот смотри. Ты можешь взять сервер, написанный на Go, и в начале функции main поставить GOMAXPROCS(1), чтобы установить выполнение всего кода инстанса в 1 потоке ОС. Получится асинхронное приложение, ровно точно такое же как под Node.js. Теперь твоя задача доказать, возможно с помощью chatgpt, что это однопоточное асинхронное приложение работает не хуже того же самого кода, но только без ограничения в количестве потоков. Удачи!

Seven Berg

Seven Berg 04.11.2024 18:51

Но это утверждение не совсем верно. Хотя можно создать однопоточное асинхронное приложение на Go с использованием GOMAXPROCS(1), это не означает, что оно будет работать так же эффективно или масштабируемо, как аналогичное приложение на Node.js. Go изначально предназначен для работы с параллелизмом и предлагает более мощные инструменты для управления конкурентными задачами. Поэтому в большинстве случаев приложения на Go будут показывать лучшие результаты по производительности и масштабируемости по сравнению с однопоточными приложениями на Node.js. По словам моего знакомого он го учил две недели, что это за язык, который можно выучить за две недели?При использовании нескольких потоков (при GOMAXPROCS > 1) планировщик Go может более эффективно распределять горутины по ядрам процессора. Если GOMAXPROCS установлен на 1, все горутины будут выполняться в одном потоке, что может привести к увеличению времени ожидания и накладным расходам на переключение контекста.

Node.js работает в однопоточном режиме, Go изначально спроектирован для работы с параллелизмом. Поэтому такое делать не совсем правильно! Хлопцы шё скажите?

Qaraimam

Олександр Шпак Oarsman в Self Employed 04.11.2024 21:16

Чому не державною?

Seven Berg

Qaraimam 05.11.2024 02:06

У тебя АИ-агент утратил основную линию мысли, и она утекла куда-то.

Seven Berg

Artem Olenchenko 06.11.2024 10:43

таке вiдчуття що копiрайтер комент писав, шо попало

Seven Berg

Serhii 06.11.2024 11:09

Так і є, комментарі генерує нейромережа

Artem Olenchenko

Seven Berg 06.11.2024 15:46

Хлопцы, завидуйте, я не против!

Serhii

Владислав Бутник Software Engineer в Speed4Trade 31.10.2024 18:12

Typescript для початку достатньо

Seven Berg 31.10.2024 22:11

Посмотрите это www.youtube.com/...RPCTFPc&ab_channel=fwdays

Владислав Бутник

Владислав Бутник Software Engineer в Speed4Trade 01.11.2024 15:18

Да, ошибка страшная, но почему он рекламирует Rescript вместо JavaScript? Владелец этой темы поскорее хочет найти работу и чтоб язык был лёгким, с этим прекрасно справляется TypeScript. Rescript (практически) нигде не пользуется спросом, поэтому он в основном для энтузиастов.

Seven Berg

Seven Berg 30.10.2024 21:05

Мне кажется хлопцы, шё джаваскрипт побеждает, шё на фронтенде, шё на бэкенде! Тимур Гофарович, так говорил, а он как известно,пургу нести не будет!

Qaraimam 31.10.2024 18:03

Там нет статической типизации, без этого ничего победить не выйдет на бекэнде.

Seven Berg

Seven Berg 31.10.2024 21:55

Не совсем существует куча инструментов для решения этой задачи:
1. Flow
Flow это инструмент от Facebook для проверки типов в JavaScript. Он позволяет добавлять аннотации типов и проверять их во время разработки, обеспечивая более безопасный код без необходимости перехода на TypeScript. Flow менее строгий по сравнению с TypeScript и может быть проще интегрирован в существующие проекты2.
Пример использования Flow:

// @flow
function add(a: number, b: number): number {
return a + b;
}

3. JSDoc
JSDoc — стандарт комментариев для JavaScript, который позволяет разработчикам добавлять аннотации типов в комментариях к коду. Хотя это не обеспечивает статическую типизацию в полном смысле, инструменты, такие как TypeScript и Flow, могут использовать эти аннотации для проверки типов3.
Пример использования JSDoc:

/**
* @param {number} a
* @param {number} b
* @returns {number}
*/
function add(a, b) {
return a + b;
}

3. Применение линтеров
Линтеры, такие как ESLint с плагинами для проверки типов, могут помочь выявлять потенциальные проблемы с типами в коде JavaScript. Хотя они не обеспечивают статическую типизацию, они могут помочь поддерживать качество кода и избегать ошибок1.
Другими словами, хотя JavaScript является динамически типизированным языком, существует несколько инструментов и подходов, которые позволяют разработчикам добавлять уровень контроля над типами данных. Использование TypeScript или Flow может значительно повысить надежность и предсказуемость кода, особенно в крупных проектах.
И вишенка на торте, это использование wasm types. вот с курсача
WebAssembly (Wasm) предоставляет возможность взаимодействовать с JavaScript, но для этого необходимо учитывать различные типы данных, используемые в обоих языках. Вот основные моменты о том, как применять типы WebAssembly в JavaScript.
Основные типы WebAssembly
WebAssembly поддерживает несколько типов, которые можно использовать при взаимодействии с JavaScript:
Числовые типы:
int32: 32-битное целое число.
int64: 64-битное целое число.
float32: 32-битное число с плавающей точкой.
float64: 64-битное число с плавающей точкой.
Ссылочные типы:
funcref: ссылка на функцию.
externref: ссылка на объекты, которые могут быть переданы в Wasm из JavaScript.
Взаимодействие между WebAssembly и JavaScript
Загрузка и компиляция модуля
Для начала вам нужно загрузить и скомпилировать ваш .wasm модуль с помощью JavaScript. Вот пример кода:

async function loadWasm() {
const response = await fetch(’module.wasm’);
const bytes = await response.arrayBuffer();
const module = await WebAssembly.compile(bytes);
const instance = await WebAssembly.instantiate(module, {
env: { /* ваши импорты */ }
});
return instance;
}

loadWasm().then(instance => {
// Используйте instance.exports для доступа к экспортируемым функциям
});

Передача данных между JavaScript и WebAssembly
При взаимодействии между JavaScript и WebAssembly необходимо учитывать различия в типах данных:
Числа: Для передачи чисел между JavaScript и Wasm можно использовать стандартные числовые типы. Например, вы можете передать int32 из Wasm в JavaScript следующим образом:

const result = instance.exports.someFunction(42); // Передаем число 42
console.log(result); // Получаем результат выполнения функции

Ссылки: Чтобы передать объект или функцию, используйте ссылочные типы. Например:

const importObject = {<br>env: {<br>importedFunction: () => console.log(’Hello from JS!’)<br>}<br>};

<p>const instance = await WebAssembly.instantiate(module, importObject);<br>instance.exports.exportedFunction(); // Вызов функции из Wasm, которая использует импортированную JS функцию</p>

<p>Работа с памятью<br>WebAssembly использует линейную память, которая представляется как ArrayBuffer в JavaScript. Вы можете выделить память и работать с ней следующим образом:<br><code><br>const memory = new WebAssembly.Memory({ initial: 10 });<br>const array = new Uint32Array(memory.buffer);</code></p>

<p>// Запись значения в память<br>array[0] = 42;</p>

<p>// Чтение значения из памяти<br>console.log(array[0]); // Выводит 42</p>

<p>________________________________________________________________________________<br>Использование WebAssembly вместе с JavaScript открывает новые возможности для производительных приложений. Понимание типов данных и методов взаимодействия между двумя языками является ключевым для эффективной разработки. С учетом различий в типах и механизмах передачи данных можно создавать мощные и производительные решения.<br>Чуть-чуть много получилось, зато надеюсь, будет понятно всем.</p>

Qaraimam

Qaraimam 31.10.2024 22:22

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

Seven Berg

Seven Berg 31.10.2024 22:34

www.youtube.com/...e_ve_path=MzY4NDIsMjg2NjY
В конечном итоге выбор подхода зависит от конкретных требований проекта и команды разработки.

Qaraimam

Азаза Заазааз 31.10.2024 22:25

А вона і не треба.

Qaraimam

Seven Berg 31.10.2024 22:46

Вы серьезно?А если типы при сериализация послетают?В JavaScript, если не объявлять типы данных, это может привести к проблемам при сериализации и десериализации объектов. JavaScript является динамически типизированным языком, что означает, что переменные могут принимать значения разных типов в любое время. Это создает неопределенность при сериализации объектов, так как не всегда можно точно определить, какой тип данных должен быть использован.
При сериализации объектов в формат JSON (или другие форматы) JavaScript не сохраняет информацию о типах данных. Например, если объект содержит функции или специальные объекты (например, Date), они могут быть потеряны или неправильно интерпретированы.
Пример:

const obj = {
    date: new Date(),
    greet: function() { return "Hello"; }
};

const serialized = JSON.stringify(obj); // Функция будет проигнорирована
console.log(serialized); // {"date":"2023-10-31T12:00:00.000Z"}

При десериализации вы получите объект без информации о том, что date был объектом Date, и функция greet будет потеряна.
Когда вы десериализуете данные, полученные из внешнего источника (например, API), JavaScript не знает, какие типы данных ожидать. Это может привести к ошибкам выполнения, если данные не соответствуют ожидаемым типам.
Пример:

const jsonData = '{"name":"Bob","age":"25"}'; // age как строка
const user = JSON.parse(jsonData);
console.log(user.age + 5); // Выведет "255", а не 30

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

Олександр Шпак Oarsman в Self Employed 01.11.2024 00:15

что переменные могут принимать значения разных типов в любое время

Це трохи не відповідає дійсності. Давайте спочатку розберемося, що саме ви маєте на увазі під змінними. Якщо так звані класичні змінні, то для атомарних значень в const не дозволяється міняти значення (об’єктам, звісно, пофігу, але це інша історія)

Якщо ж ви маєте на увазі поля об’єктів, або методи, то тут також є можливість створити поле-константу

const object1 = {};

Object.defineProperty(object1, 'property1', {
  value: 42,
  writable: false,
});

object1.property1 = 77;
// Throws an error in strict mode

console.log(object1.property1);
// Expected output: 42

При сериализации объектов в формат JSON (или другие форматы) JavaScript не сохраняет информацию о типах данных.

Так, тому що так звана конвертація в JSON не є серіалізацією об’єктів. А сам формат є спрощеним та ніколи не задумувався як типовий серіалізатор об’єктів, як це є в інших мовах програмування, по типу Java або C#.

При десериализации вы получите объект без информации о том, что date был объектом Date, и функция greet будет потеряна.

Так, це явно написано в документації, я не розумію, чому ви очікуєте якоїсь іншої поведінки? Вас не турбує той факт, що навіть назва метода — JSON.stringify(), а не serialization

Когда вы десериализуете данные, полученные из внешнего источника (например, API), JavaScript не знает, какие типы данных ожидать.

А це взагалі не потрібно в світі JS. Парсер чітко зможе визначити, де Object, де Array, Boolean, Number чи String. Ви створюєте проблему там, де її в принципі не існує.

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

Ні, результат дуже передбачуваний, ви до строки додаєте строку. Результат буде — строка. Це правила цієї мови. Так, вони інколи здаються трохи дивними, але в них є логіка та свої переваги. Не треба приходити зі своїм уставом в чужий монастир та казати потім, що попи не ті пісні співають та всі моляться не в ту сторону.

Seven Berg

Seven Berg 01.11.2024 00:46

Це трохи не відповідає дійсності. Давайте спочатку розберемося, що саме ви маєте на увазі під змінними. Якщо так звані класичні змінні, то для атомарних значень в const не дозволяється міняти значення (об’єктам, звісно, пофігу, але це інша історія)

Вы правы в том, что при использовании const в JavaScript нельзя переназначить переменную, но это не означает, что объекты, объявленные с помощью const, являются неизменяемыми. Вы можете изменять свойства объектов:

const object1 = {};<br>object1.property1 = 42; // Это допустимо

<p>Однако использование Object.defineProperty для создания неизменяемого свойства — это хороший способ обеспечить неизменность конкретного поля. Тем не менее, это не является стандартной практикой для большинства случаев.<br>Кроме того, важно понимать тот факт, что const предотвращает переназначение переменной, но не делает объект неизменным. Для создания неизменяемых объектов можно использовать Object.freeze() или другие методы.<br></p><blockquote>Так, тому що так звана конвертація в JSON не є серіалізацією об’єктів. А сам формат є спрощеним та ніколи не задумувався як типовий серіалізатор об’єктів, як це є в інших мовах програмування, по типу Java або C#.</blockquote>

<p>Да, JSON не является полноценным механизмом сериализации объектов, как в других языках программирования. Он действительно предназначен для передачи данных в простом формате. Однако важно отметить, что JSON.stringify() и JSON.parse() это стандартные методы для работы с данными в JavaScript. Они обеспечивают удобный способ обмена данными между клиентом и сервером. Но как вы отметили, они не сохраняют информацию о типах данных (например, функции или специальные объекты). Формат JSON действительно упрощает структуру данных и не предназначен для сохранения всех аспектов оригинального объекта и это следует учитывать при проектировании систем.<br>JavaScript может определить типы данных при парсинге JSON (объекты, массивы и т.д.). Однако проблема возникает при попытке использовать данные после десериализации.<br>Например, если вы ожидаете число, а получаете строку из-за неправильного формата данных (например, «42» вместо 42), это может привести к ошибкам:<br></p><pre>const jsonData = ’{"age":"25«}’; // age как строка<br>const user = JSON.parse(jsonData);<br>console.log(user.age + 5); // Выводит «255», а не 30

<p>Имелось ввиду, что хотя JavaScript может определить базовые типы данных при парсинге JSON, важно помнить о возможных несоответствиях типов и обрабатывать их соответствующим образом.<br></p><blockquote>Ні, результат дуже передбачуваний, ви до строки додаєте строку. Результат буде — строка. Це правила цієї мови. Так, вони інколи здаються трохи дивними, але в них є логіка та свої переваги. Не треба приходити зі своїм уставом в чужий монастир та казати потім, що попи не ті пісні співають та всі моляться не в ту сторону.</blockquote>

<p>Результат сложения строки и числа будет строкой. Это поведение действительно предсказуемо в контексте JavaScript:<br></p><pre>const age = «25»;<br>console.log(age + 5); // «255»

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

Олександр Шпак Oarsman в Self Employed 01.11.2024 01:31

Тем не менее, это не является стандартной практикой для большинства случаев

Це є нормальна практика для тих випадків, які вимагають незмінність значень полів. Для всіх інших випадків можливість змінювати значення — норма мови. Вона так була задумана. Спеціально.

Кроме того, важно понимать тот факт, что const предотвращает переназначение переменной, но не делает объект неизменным.

Це явно написано в документації. Так, це варто знати та розуміти перед тим, як використовувати.

Формат JSON действительно упрощает структуру данных и не предназначен для сохранения всех аспектов оригинального объекта и это следует учитывать при проектировании систем.

Ніколи в світі JS не стояла задача передачі обʼєктів між системами. Сподіваюсь, що ніколи й не буде стояти.

По-перше це вкрай небезпечно. Колись MS експериментували з такими ідеями за часів IE6. Вони придумали «геніальну» ідею, мовляв, давайте перевикористовувати компоненти, які створили інші розробники, в себе на сторінках. Результат був передбачувано поганим — кількість шкідливого коду, який так розповсюдили, була неймовірною.

По-друге, модель роботи this вимагає повного відновлення контексту обʼєкта, а при наявності якогось замикання, тягнути з серіалізованим обʼєктом прийдеться ще й купу зайвого. Інколи це цілий проект.

По-третє, посилання в JS може вести на шматочок DOM дерева розміром із всю сторінку. Як ви збираєтеся це передавати, я не в курсі.

Там є ще багато інших причин, чому в JS немає серіалізації/десеріалізації, але цих вже достатньо для того, щоб зрозуміти, що це зайве.

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

Важливо розуміти, що коли ви змінюєте мову програмування, то вам треба вивчити її, а не казати, що там щось не правильно, бо ви звикли до іншого. Тоді у вас не буде проблем.

Seven Berg

Seven Berg 01.11.2024 02:14

На самом деле задача передачи объектов между системами существует в JavaScript, и такая возможность была разработана для выполнения практических задач и создания современных приложений. Серийный обмен данными между системами — важная часть многих JavaScript-приложений. Например, обмен JSON-данными позволяет передавать структурированные объекты, такие как массивы и словари, между сервером и клиентом. Рассмотрим несколько причин, почему это необходимо и может быть безопасно реализовано:

JSON и сериализация объектов. JavaScript поддерживает сериализацию данных в формат JSON. JSON (JavaScript Object Notation) позволяет безопасно передавать данные между системами без передачи функций или контекста, что делает его идеальным для взаимодействия между клиентом и сервером в веб-приложениях. JSON-сериализация не содержит методов или привязок к контексту, а передает только данные, что исключает риски безопасности.

Безопасность передачи данных. JavaScript не передает ссылки на объекты DOM при передаче данных. Даже если объект содержит ссылки на DOM-элементы, JSON.stringify просто игнорирует их. Это защищает от потенциальных уязвимостей, которые могли бы возникнуть при передаче структуры страницы. Дополнительные средства безопасности, такие как CORS (Cross-Origin Resource Sharing) и CSP (Content Security Policy), также контролируют передачу данных между доменами, обеспечивая безопасность.

Простота и безопасность передачи данных без методов. В JavaScript функции и замыкания не могут быть сериализованы, так как сериализация предназначена исключительно для передачи данных. Это обеспечивает дополнительную безопасность и контроль над передаваемыми объектами. Даже если у объекта есть методы или контекст замыкания, при преобразовании его в JSON они будут проигнорированы, что позволяет передавать только необходимые данные.

Широкое использование в API. Современные API используют JSON как стандарт для передачи данных. Поскольку JSON является безопасным и структурированным форматом, он легко интегрируется с REST API и GraphQL и используется во многих популярных фреймворках, таких как React и Angular. Это обеспечивает высокую совместимость и делает обмен данными между системами стандартной практикой.

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

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

Олександр Шпак Oarsman в Self Employed 01.11.2024 23:53

Схоже, що хтось тут тестує свої AI-моделі...

Seven Berg

Seven Berg 02.11.2024 18:53

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

Олександр Шпак Oarsman в Self Employed 03.11.2024 00:23

Хотя мне лично очень приятно, что меня сравнивают с АИ

Це не позитивна характеристика в данному випадку

Seven Berg

Qaraimam 01.11.2024 13:51

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

Олександр Шпак Oarsman в Self Employed 01.11.2024 23:55

JSON типізований. Там є об’єкти, масиви, строки, числа, булеві значення та null. Чого вам ще не вистачає?

Qaraimam

Seven Berg 02.11.2024 19:18

В класическом JSON нет прямого эквивалента для «undefined» или «неопределенного» значения, которое есть в некоторых языках программирования (например, JavaScript).
Хотя null в JSON часто используется для представления отсутствующего или неопределенного значения, он не всегда может адекватно передать семантику «неопределенности» в контексте конкретного приложения.
В JSON есть разница между отсутствующим полем и полем со значением null, что может создавать неоднозначности при интерпретации данных.
При сериализации объектов, как мною было упомянуто выше, из языков программирования в JSON могут возникать проблемы с представлением специфических типов данных или состояний (например, NaN или Infinity для чисел). Этой инфы будут достаточно, что бы крепко задуматься...

Олександр Шпак Oarsman в Self Employed 03.11.2024 00:30

В класическом JSON нет прямого эквивалента для «undefined» или «неопределенного» значения, которое есть в некоторых языках программирования (например, JavaScript).

Є. Відсутність ключа в даних є 100% еквівалентом undefined.

В JSON есть разница между отсутствующим полем и полем со значением null, что может создавать неоднозначности при интерпретации данных.

Які ще неоднозначності? Якщо ключ відсутній, то це undefined, якщо значення ключа дорівнює null, то це... (та-дааам) — null. Не натягуйте сову на глобуса.

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

Проблеми можуть виникати тільки в голові у програмістів, які не змогли адекватно розібратися з технологією. Стандарт JSON каже, що приймається тільки певний перелік типів даних. Нічого більше. Дотримуйтеся стандартів та не вимагайте від нього чогось за його межами. Все!

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

Так, вам треба задуматися, навіщо ви від стандарта вимагаєте того, що в нього не входить?

Seven Berg

Seven Berg 03.11.2024 17:47

Стандарты JSON: JSON был разработан как простой и легковесный формат обмена данными, который должен быть легко читаемым и понятным. Спецификация JSON (RFC 7159) не включает в себя поддержку NaN и Infinity, поскольку эти значения не являются стандартными числовыми значениями в большинстве языков программирования.Вы правы в том, что отсутствие ключа в JSON может интерпретироваться как undefined в контексте JavaScript. Однако, важно отметить, что JSON сам по себе не имеет концепции undefined. Это значение возникает только в JavaScript. В JSON просто нет этого типа, и отсутствие ключа — это не то же самое, что и undefined, поскольку в других языках программирования это может быть интерпретировано по-разному.Действительно, в JSON есть разница между отсутствующим полем и полем со значением null. Однако эта разница может создавать путаницу при интерпретации данных. Например, если вы ожидаете, что поле должно содержать значение, а его нет (отсутствует), это может вызвать ошибки или неправильное поведение в вашем коде.

Олександр Шпак Oarsman в Self Employed 03.11.2024 23:29

и отсутствие ключа — это не то же самое, что и undefined,

Аналогів undefined немає в популярних мовах програмування. Там це undeclared скоріше. Тому в інших мовах відсутність ключа й буде аналогом undefined в JS.

Однако эта разница может создавать путаницу при интерпретации данных.

Не може

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

Не може.

Seven Berg

Illia Vakelchuk 25.10.2024 15:28

Розглянемо ситуацію, якщо ви 0 у беці.
Java ± рік на вивчення + фреймворки, знайти роботу відносно важко, через конкуренцію та відсутність пропозицій, в основному зараз багато вакансій на Senior.
PHP — до 6 місяців на вивчення, вакансій менше, але й конкуренції менше, знайти роботу реально.
С# схожа ситуація як і з Java.
JS — 6-12 місяців, конкуренція дуже велика, пропозицій мало.
Власне все залежить від вашої персональної ситуації

Seven Berg 30.10.2024 21:11

Кажись пыха уже все... У нас это слово на 122-ой даже не принято упоминать!

Illia Vakelchuk

Азаза Заазааз 31.10.2024 13:26

А при чому тут 122? Більша частина інтернету написана досі на пхп, і роботи там на найближчі 20-30 років више криші. Легасі саме себе підтримувати не буде, а переписувати його тим паче ніхто не буде.

Seven Berg

Seven Berg 31.10.2024 21:38

нам на ней не разрешают писать, я тоже раньше на ней писал, сейчас тоже самое можно написать на node.js

Illia Vakelchuk 31.10.2024 15:09

На Djinni всього 243 вакансії по пхп, з 0 досвіду 8, тому не так вже й мертва 0_0

Seven Berg

Seven Berg 02.11.2024 19:24

Я бы сюдою, хлопцы еще го добавил, но это как говориться на любителя.

Illia Vakelchuk

Qaraimam 03.11.2024 03:03

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

Seven Berg

Seven Berg 06.11.2024 15:52

А зачем, если и нода это вытягивает? Платформа Node.js и ось может выполнять параллельные операции ввода/вывода своими средствами, а во время обработки данных средствами JavaScript-кода, он работает в однопоточном режиме. JavaScript и платформа Node.js с самого начала своего создания не были предназначены для решения задач, интенсивно использующих ресурсы процессора. В случае с JS, работающим в браузере, выполнение таких задач спровоцирует притормаживание пользовательского интерфейса. В Node.js это может ограничить возможность запрашивать у платформы выполнение новых асинхронных задач ввода/вывода и возможность реагировать на события, связанные с их завершением. Нельзя добавить в JavaScript возможность работы с потоками, это приведёт к изменению самой природы этого языка. Посмотрите что такое синхронизация в других языках, например в джава. Вы еще про квантовую суперпозицию сюдою напишите!

Qaraimam

anonymous 22.10.2024 19:49

-

Serhii 23.10.2024 13:18

Вкотитися в айті з плюсами майже нереально.

anonymous

anonymous 23.10.2024 14:03

-

Serhii

Happy 28.10.2024 08:55

Це чому? Здавалося б навпаки, на плюси не така велика кількість новачків і конкуренція значно нижча

Serhii

Serhii 28.10.2024 11:29

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

Happy

Seven Berg 30.10.2024 21:16

Наши были в юбисофте на суммерскуле, берут в основном студентов.

Serhii

Азаза Заазааз 31.10.2024 13:29

Ну взагалі є, бо самі розробники на плюсах зацікавлені, щоб хтось педалив разом з ними, просто досвід з плюсами мало куди переноситься потім, бо кожна контора вибудовує свій особливий гівностайл, і одні плюсовики далеко не факт, що зрозуміють інших. Це з джавою і шарпом все відносно зрозуміло, бо їх там натаскують на бест практісес по написанню бойлерплейта.

Serhii

Seven Berg 31.10.2024 21:40

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

Alex Perchatochnikov Zultys Inc 30.10.2024 18:14

Только нужны по плюсами в основном не джуниоры, а для новичков в С++ ничего не завозят. Expert friendly...

Happy

Seven Berg 30.10.2024 21:15

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

Serhii

Азаза Заазааз 31.10.2024 13:31

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

Serhii

Seven Berg 30.10.2024 21:13

Соглашусь шё питон для машинлернинга, да в принципе вроде на нем все можно писать... Остальное все на любителя...

anonymous

Dmitry O 10.11.2024 03:20

Достатньо рандомний набір технологій.

anonymous

Darling Queen 22.10.2024 01:12

Залежіть від редактора. Якщо vim, то напевно Lisp. Якщо emacs — то швидше Java.

Dmytro Horenetskyi mobile developer в self employed 24.10.2024 12:34

якщо сприймати мову як інструмент, то ide це колір. дивно для забивння цвяхів обирати мікроскоп, бо він червоний

Darling Queen

Олександр Мощенко 24.10.2024 12:57

ide це кінцівки, якими тримають інструмент. дивно тиснути на педалі долонями.

Dmytro Horenetskyi

Азаза Заазааз 31.10.2024 22:26

Якщо в тебе є цвях і мікроскоп, то цвях треба забивати мікроскопом. Бо це швидше ніж знайти молоток, і задача все одно буде виконана правильно.

Dmytro Horenetskyi

Alla Kaplia Node.js developer в Weblium 21.10.2024 12:27

Думаю, не менше важливо визначити задачі, які ви хочете вирішувати. Яка мова програмування здатна покривати ці задачі — таку і обирайте. Якщо хочете легко — вам нічого робити в розробці. Так не буває.

Serhii 21.10.2024 14:00

У автора задача — знайти роботу :))

Як на мене, є дві групи варіантів:
— C# vs Java
— Javascript/Typescript vs Python

Я б обирав між C# та Typescript

Alla Kaplia

Dmytro Horenetskyi mobile developer в self employed 24.10.2024 12:32

У автора задача — знайти роботу :))

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

Serhii

Anton Katrus 21.10.2024 11:10

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

Vlad Skachkov не мэнт в НГУ 03.11.2024 20:52

уявляю собі ші-фреймворк на php

— внучёк, возми скриптов домой.
— дед, да у нас этих скриптов, как говна за баней!
— то всё ШИ нагенерил, а это домашнее, дед сам писал!

типу кажу йому — прикрути форум до сайту.

возьми и руками прикрути. совсем обленились.

Anton Katrus

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 19.10.2024 22:29

В зависимости от типа бэкенда, для крупных проектов рекомендуется Java, а для небольших проектов — Golang. Если вы предпочитаете стек Windows, то C# может быть альтернативой Java. Для облачных лямбд можно использовать JS и Python. Если вам нужно анализировать данные и скорость не является критичной, то Python будет хорошим выбором.

Vlad Proshin Full Stack Developer в DRUPFAN 20.10.2024 08:49

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

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 20.10.2024 11:05

Реально владею всем, кроме JS, но с ним пересекались мои команды, и я видел плюсы и минусы. Основной — Java. Для бэкенда, на мой взгляд, важна многопоточность. Она хорошая в Java и отличная в Go.
Так как код меняется нечасто и может работать годами, то важно, чтобы от версии к версии языка не приходилось всё переписывать с новыми подходами.
Ещё важным будет не быстрое написание кода, а простота понимания и поддержки, потому что обычно всё не переписывается часто и Написав раз, придётся поддерживать годами.
Тут ещё Rust упоминали, но не думаю, что он подходит. Разве что если писать свой «nginx» или что-то быстрое и компактное. Он больше для системного программирования.

Vlad Proshin

Vlad Proshin Full Stack Developer в DRUPFAN 20.10.2024 11:24

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

писать свой «nginx»

Что, и это для вас как два пальца об асфальт?
...и самое главное: ЗАЧЕМ???

*терзается сомнениями

Andy W 21.10.2024 01:05

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

А навіщо?
Точніше, навіщо мові мати такі поновлення, які заставляють адаптувати свій код, щоби воно працювало?
Ну, я розумію, що на PHP з його зворотніми несумісностями навіть у мінорних версіях це як «здрасьтє».
Але з точки зору бізнесу чи навіть програміста, який хоч трохи париться за якість — це звіздец.

писать свой "nginx"

Что, и это для вас как два пальца об асфальт?
...и самое главное: ЗАЧЕМ???

Це ж класно, коли є Pingora :)
github.com/cloudflare/pingora

Vlad Proshin

Andrii Sevastianov 20.10.2024 11:31

Тут ещё Rust упоминали, но не думаю, что он подходит.

Ну... А чим Rust не підходить у порівнянні з Java? Особливо, якщо ви за класичну багатопоточність? Як на мене, гарантій того, що у нас немає гонок, дуже великий важиль.

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 20.10.2024 12:03

Я не очень хорошо знаком с Rust, чтобы спорить. Мой вывод основан на том, что:
Rust всё-таки больше считается заменой C, а на C я бы не стал писать веб сервисы.
Мне интересно, что может предложить Rust полезного для бэкенда по сравнению с Java.
В Java уже есть много готового для крупных проектов. Есть много библиотек на любой вкус. Ещё немаловажно, что Java работает на любом процессоре и при этом работает достаточно быстро. Есть удобная отладка уже скомпилированного кода. Библиотека, написанная в 2005 году, вполне готова к использованию на ARM, и её не нужно перекомпилировать.
Как язык Rust будет не хуже, но и причин написать новый веб сервис на Rust я не вижу.
Для каких то хайлоад инфраструктурных вещей может подойти.

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 13:10

З Rust для беку проблема зовсім в іншому, так він часто заміна C++, але разом з тим Rust також і досить високорівненвий з точки зору написання коду, прикладний код на Rust виглядає зрозуміло і читабельно, немає явного управління памʼяттю і т.д. що властиво системним мовам. З того що він може запропонувати беку це апка яка буде працювати максимально швидко, потребувати дуже мало ресурсів, також через свою систему хендлінгу помилок теоретично буде менше багів. Із запуском на різних платформах теж немає ніяких проблем, Java давно не монополіст в цьому ’write once, run everywhere’ (чи ’run once, debug everywhere’ =))) А проблема Rust на беці у іншому, у нього досить сира екосистема, нема ліб на будь який смак, треба зшивати тех стек самостійно, нема образного Spring чи NestJS, де більшість речей з коробки, ну або такі фреймворки лише в стадії розробки, давно за цим не слідкував. З ORM взагалі біда, простіше писати Raw SQL, ніж користуватися тим, що пропонує Rust екосистема на даний момент. Якщо підсумовувати мінуси Rust для беку, то це буде дорога, повільна розробка, бо спеціалістів мало, вони дорогі, а також багато системного коду (в сенсі всяких утиліт і хелперів які є в Spring з коробки) доведеться написати самому. Можливо у майбутньому щось зміниться, бо мова все ще має свій хайп-трейн і екосистема продовжує розвиватися

Serhii 21.10.2024 14:01

Sqlx залишив дуже приємне враження, але так, це і є по суті raw sql

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 21.10.2024 14:33

так, його і мав на увазі під Raw SQL

Serhii

Alex Perchatochnikov Zultys Inc 30.10.2024 18:17

Когда на Растений без unsafe можно будет написать что-либо сложнее «Hellow, world», тогда заходите.

Pavlo Vuiko

Serhii 30.10.2024 19:00

Та вже можна, давно

Alex Perchatochnikov

Andrii Sevastianov 20.10.2024 17:41

Rust всё-таки больше считается заменой C

Так, його хочуть занести в embedded, але виходить не дуже. Причина скоріше полягає у тому, що умовному C++/Java/C# розробнику набагато простіше вивчити Rust, ніж Сі. А проблема, чому Сі важкий, лежить у тому, що там немає звичайних контейнерів. А в Rust вони як раз є. А сішні двозв’язні циклічні списки в Rust реалізувати майже неможливо. Плюс багато існуючого коду.

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

Ну... в Rust є своя бібліотека досить велика, більше того він просто інтегрується з нативними бібліотеками, тому я не думаю, що це дуже велика перевага. Можливо є питання з ORM, але я там просто не в курсі.

Знову, ніша Rust це блокчейн, а це P2P, досить складні мережеві взіємодії.

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

Ну... якщо брати проблеми з race conditions, deadlocks, то відлагодження дуже сильно обмежено. Саме гарантій на етапі компіляції Java дає мало. Плюс ADT особисто мені зжається краще з точки зору не помилятися при написанні коду, ніж ООП.

Artyom Krivokrisenko 30.10.2024 20:34

Так, його хочуть занести в embedded, але виходить не дуже.

Уже давно занесли и пишут.

А сішні двозв’язні циклічні списки в Rust реалізувати майже неможливо.

Такие же точно как в Си реализуются элементарно (через raw pointers). Безопасные так же реализуются через Rc < RefCell < Node > > .

Lev Pasichnyi Senior DevOps Engineer в LevArc 20.10.2024 23:14

Давайте без церкви і адептів Rust. Пишіть firmware(прошивки), embedded, linux kernel, використовуйте інструменти за призначенням.

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 23:27

А чому ви вважаєте, що Rust призначення лише у цьому? Це General purpose мова програмування, на якій нормально можна писати майже все що завгодно, той же бекенд і десктопні апки, з єдиним нюансом, що екосистему для себе треба буде допилювати, бо мова досить молода

Lev Pasichnyi Senior DevOps Engineer в LevArc 20.10.2024 23:49

Я її бачив, мені її важко читати, будь яку іншу ні. Писали про borrow checker ( підозрюю що компілюється воно теж не так швидко, яке хотілося би ). Ну і якісь складні речі зі складними валідаціями, спілкуванням з іншими мікросервісами, зовнішніми сервісами і т.п. Підозрюю що буде як з ассемблером: hello world буде ок, місяць розробки і в тому коді вже ніхто окрім вас не розбереться.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 21.10.2024 00:09

Не погоджуюся, що важко читається, можливо вам просто незвично, бо мова не C подібна. Так швидкість компіляції не швидка, як і у будь якої LLVM мови, по типу Swift. Ну і час компіляції Rust має свою причину, є дуже багато перевірок при компіляції, але ці перевірки фактично гарантують те що апка не впаде в рантаймі, якщо звісно не використовуєш .unwrap().

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

Rust це вам не Haskell) код самої мови не більш складний ніж в більш традиційних мов по типу C#, Java, Python, TS, просто незвичні на перший погляд деякі кодові конструкції, тому ви помиляєтеся, що код на Rust одноразовий і його важко підтримувати. Є звісно деякі сумнівні синтаксичні рішення, наприклад те, що синтаксис стрілочної функції виглядає ось так: || {} а не більш звичне для C# та JS/TS () => {} чи те що тип змінних позначається через двокрапку, а return тип функцій стрілочкою -> але все інше цілком собі зручно і читабельно.

З реальних проблем Rust для бекенду, це те що у нього сирувата екосистема, небагато розробників, що власне не позитивно впливає на time-to-market Rust проєктів, але це пояснюється тим, що мова досить молода, в майбутньому це може змінитися на краще

Lev Pasichnyi Senior DevOps Engineer в LevArc 21.10.2024 00:13

переконали, передивлюся ще раз )

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 21.10.2024 00:18

можете ось глянути код мого пет проєкту, як на мене там код виглядає досить читабельно)
github.com/...a-vuiko/fin-control-be-rs

Andrii Sevastianov 21.10.2024 01:12

Пишіть firmware(прошивки), embedded, linux kernel, використовуйте інструменти за призначенням.

Ну... ви бачили багато вакансій, де треба firmware, embedded, Linux kernel та треба писати на Rust? Я ні. Це блакитна мрія, але Rust там майже не використовується. Тому я не думаю, що це призначення Rust, і на мою думку він для цього не дуже заточений.

А от де він використовується, це blockchain, тобто багатопоточні мережеві застосунки, де ціна помилки дуже висока, плюс інколи є вимоги до перформансу. І в цій ніші він дуже непогано почувається, а це набагато ближче до Java та Backend чим до Embedded.

Artyom Krivokrisenko 30.10.2024 20:37

Пишіть firmware(прошивки), embedded, linux kernel, використовуйте інструменти за призначенням.

Можно спросить, кто вас назначил главным по гейткипингу использования Раста?

Lev Pasichnyi Senior DevOps Engineer в LevArc 30.10.2024 20:50

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

Artyom Krivokrisenko

Artyom Krivokrisenko 30.10.2024 21:02

но писать прямо проекты на нём.... это изврат.

Simply a difference in skill

Trip Trip 20.10.2024 19:18

Реально владею всем

:D

Если вы предпочитаете стек Windows, то C# может быть альтернативой Java.

.Net уже лет 6 как кроссплатформенный
и хостят его в 99% на линуксе.

Для облачных лямбд можно использовать JS и Python.

Ага, а еще C#, Java, Ruby ...
При чем в случае с Azure Functions питон далеко не лучший выбор.

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 20.10.2024 19:22

> Net уже лет 6 как кроссплатформенный
и хостят его в 99% на линуксе.
Хостить сейчас можно, но разработка из Visual Studio которой например нет на мак. То есть оно все равно так или иначе ближе к Windows.
> Ага, а еще C#, Java, Ruby ...
Ну я про то что имеет смысл, а не про то что позволяет платформа ;)

Trip Trip

Trip Trip 20.10.2024 19:32

но разработка из Visual Studio

Половина знакомых Rider юзают, замечательно работает на маке:)

Andrii Sevastianov 20.10.2024 11:26

У чому проблема оцінювати? Мови мають багато спільного

Vlad Proshin

Vladimir Plakhotnik 19.10.2024 17:52

Найкраща мова для бекенду це мова асемблера 🤘вчити важко і хто його знає як там з роботою) але 100% будеш крутий та почнеш призерати інших осоьливо js-івців))))

Бартоломео Россі 20.10.2024 18:19

Не обов’язково вчити asm щоб знущатись з джс-івців. Достатньо вивчити любу компільовану мову. Втікає...

Vladimir Plakhotnik

Азаза Заазааз 30.10.2024 20:50

Будь-яку компільовану мову, компілюватись вона буде в джаваскріпт.

Бартоломео Россі

Konstantin Strukov 18.10.2024 17:42

така щоб не супер тяжка у вивченні, але й щоб можна було знайти роботу

Роботу можна (і навіть нескладно) знайти навіть з мовою, яку ти взагалі не знаєш — за умови, що знаєш «все інше». Твоя проблема не в тому щоб «потім знайти роботу», а в тому, щоб «потім знайти ПЕРШУ роботу». От від цієї пічки й пляши. Покури гуголь, подивись хто і на який стек взагалі готовий наймати інтернів сьогодні (не забувай про курси від галер, через які теж можна вскочити вайті) — оце й буде твій шортліст. Далі пробуєш руцями парочку варіантів й зупиняєшся на тому, що легше йде.

Олексій Хількевич 18.10.2024 16:55

така щоб не супер тяжка у вивченні, але й щоб можна було знайти роботу?

нічого так губу закатав

Може ще 10кілобаксів на місяць і lap dance?

Напиши хоч шо нібуть хоч на чому нібуть з сучасних мов і не буде ніяких питань, якийсь простенький чат напиши від а до я от.

no name three 18.10.2024 15:25

Це шо, технічний топік?

Vic Programmer 18.10.2024 17:42

“Talk is cheap. Show me the code.”
― Linus Torvalds

no name three

no name three 18.10.2024 15:02

Тільки не JS, він популярний, але саме для розуміння гадаю краще щось більш стандартизоване. Я б брав Python, Ruby або Java/Kotlin.

на яку мову найбільший попит

На JS :)
Java популярна досі у великих компаніях, Python більш популярний ніж Ruby, але на Ruby всі вакансії то фулстек або бекенд, а на пітон багато і інших вакансій. Ну а JS використовують багато, щоб писати фронтенд і бекенд на одній мові.

А за PHP я взагалі не в курсі

Slavik Savko 18.10.2024 15:12

На JS :)

Так тут мова про бек. А JS популярна бо це більше про фронт. Ну максимум фуллстек і то в адекватних проєктах JS там серьйозні сервіси на JS не пишуть. Наче ж масова істерія по NodeJS заглохла. Чи ні?

no name three

no name three 18.10.2024 15:22

Сумніваюся що заглохла. В інших коментарях немало людей кажуть JS.

Я не слідкую, бо я теж скептично ставлюся до «основного» бекенду на JS. А якісь проксі сервери, серверлесс функції, чи невеликі «не основні» сервіси, чого б і ні.
Хоча це все можна писати на чому завгодно, але багато пишуть на JS, бо типу універсальна мова яку майже всі знають, не те що ваш Java/Python/Ruby/PHP

Ihoro S. Software Engineer в EPAM 18.10.2024 19:06

Наче ж масова істерія по NodeJS заглохла

От вашє не здохла. Подивіться кількість вакансій і не тільки у нас в Україні.

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 20:22

Ну JS це дійсно так собі, але TS це інша справа. Чому це на Node.js серйозного нічого не пишуть? Це від роду задачі залежить, звісно з якимись справляється не дуже, у будь якої технології є свої мінуси, але у більшості випадків це один з найкращих варіантів, найшвидший time to market на рівні з Python чи PHP, але при цьому кращий перформанс і величезна екосистема, яка продовжує розвиватися швидкими темпами, також біль ощадлива до ресурсів заліза порівнюючи з Java

Олександр Шпак Oarsman в Self Employed 19.10.2024 20:43

кращий перформанс і величезна екосистема

У PHP є такий фреймворк hyperf, який передає привіта всім хейтерам PHP та працює на рівні з Fastify.
А величезна екосистема — то може грати проти мови, а не на користь ;)

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 21:47

Fastify можна зробити ще швидшим, якщо використати uWebSockets.js (альтернативна імплементація HTTP серверу, яка ще їсть менше ресурсів) До того ж я сумніваюся, що PHP може працювати більш ефективно ніж Node.js, з точки зору споживання ресурсів, зважаючи як все працює під капотом.
Щодо екосистеми, то краще, щоб вона була велика а не маленька) єдина проблема великої екосистеми це те що вибору так багато, що розбігаються очі)

Марк Сахарчук 18.10.2024 14:16

YAML

Elvira Solnyshkina Java Developer в BotsCrew 18.10.2024 11:27

Обирай що завгодно, потім все одно велика вірогідність того, що треба буде вивчити другу і третю мову. Писала онлі на Java, тепер ще і Python з JS додалися. Останній звісно ну такеееее собі, але що поробиш — життя бентежне :) для мене Java — то любов, а інше то короткострокові інтрижки)

Олександр Шпак Oarsman в Self Employed 18.10.2024 11:42

Бачив як джавісти пишуть на JS. Без сліз дивитися не можна. :D Прямо відчуваєш їх фізичний біль від написання коду...

Elvira Solnyshkina

Serhii D Software Developer 18.10.2024 12:12

Можеш показти приклад ? що такого джавісти пишуть на javascript?

Олександр Шпак Oarsman в Self Employed 18.10.2024 12:16

На жаль, ні. То був мікросервіс, який пропонував GraphQL ендпойнти над ElasticSearch. Там було багато чого, що взагалі непотрібно, наприклад декларація класу зі структурою відповіді ;)

Serhii D

Serhii D Software Developer 18.10.2024 12:24

Я джавіст, але зараз пишу апп на next.js на TS, все помічаю інтерфейсами. Це дозволяє мені легко вносити зміни, рефакторити, так як я можу швидко знайти місця на які ці зміни впливають.

Олександр Шпак Oarsman в Self Employed 18.10.2024 16:15

TS != JS.
Я жабаскриптіст. Пишу з повним використанням динамічної типізації та приведення типів в коді. Не маю взагалі проблем ані з рефакторінгом, ані з внесенням змін. Ніяких проблем з пошуком місць, на які ці зміни впливають, не маю, бо таких місць майже немає :D Код лаконічний та простий, 150кб на весь проект немініфікованого JS. SaaS SPA.

Serhii D

Serhii D Software Developer 18.10.2024 19:05

Поняття ʼне маю проблемʼ в кожного ростяжиме. Я бачу який код пишуть спеціалісти на джаваскріпт і яка у них норма.

Олександр Шпак Oarsman в Self Employed 18.10.2024 20:58

Може вони не такі вже й спеціалісти? ;)

Serhii D

Ihoro S. Software Engineer в EPAM 18.10.2024 19:09

Я жабаскриптіст

жабаскріптізьор

Не маю взагалі проблем

Вони почнуться як тільки крім вас ще хтось почне писати із вами, а ще краще штук 5 людей.

Олександр Шпак Oarsman в Self Employed 18.10.2024 21:11

Вони почнуться як тільки крім вас ще хтось почне писати із вами, а ще краще штук 5 людей.

Ні, не почнуться. Це стара як світ лякалка. Одна людина колись сказала, що система мусить бути написана таким чином, щоб навіть джун не зміг її зламати. Ви скажете, що це неможливо. Але вихід лежить прямо перед носом. Джун не мусить писати код, який може щось зламати. Його рівень абстракцій, з яким він працює, мусить бути таким, щоб тільки користуватися напрацюваннями, а не вносити в них зміни. Тому, більш складні задачі будуть вирішувати більш досвідчені розробники, а їх вже не так багато.

Архітектура проекту рулить. Я вже писав, що в мене в проекті лише 150 кілобайт JS коду. Для того, щоб написати новий функціонально непростий компонент, мені доволі часто потрібно написати 0 (нуль) рядків JS. От скажіть, як в таких умовах інший розробник може щось зламати, якщо він ніколи не буде писати JS код?

Ihoro

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 13:44

Звучить ніби я Шемсединова послухав)) TS прийшов на заміну JS у більшості випадків не просто так. Наведений вами приклад з джуном і зламом системи валідний якщо доводиться в якийсь кор функціонал зміни вносити, а якщо взяти не цю ситуацію, а банально більш поширену, ви працюєте з X іншими розробниками на проєкті, і кожен пише свій набір фіч, тепер скажімо один з цих розробників йде у відпустку, або звільняється, і вам треба доробити, або пофіксити його фічу, хочу я на вас подивитися, як ви без статичних типів будете вʼїзджати у все, що написала ця людина і скільки у вас на це пішло б часу.

Олександр Шпак Oarsman в Self Employed 20.10.2024 17:00

TS прийшов на заміну JS у більшості випадків не просто так

Не шукайте кореляції там, де її немає. Основна причина винекнення TS — хтось не вміє принципово працювати з нестрогою динамічною типізацією. Все, ніяких інших пояснень немає, вся решта — балачки та смаковщина.

якщо доводиться в якийсь кор функціонал зміни вносити

Не пускайте низькорівневих розробників в високорівневий код. Ви ж не довіряєте операції на серці чи на мозку студентам? То чому ви довіряєте вносити зміни в ядрі системи джунам?

як ви без статичних типів будете вʼїзджати у все, що написала ця людина і скільки у вас на це пішло б часу.

Ви працюєте з розумово відсталими людьми, чи що? Немає ніякої проблеми прочитати код іншого розробника. Взагалі. Незалежно від того, статична це типізація, динамічна, чи ще щось. Ви працюєте з певними задачами та їх реалізацією в коді, які зазвичай продиктовані архітектурою проекту та вимогами з боку бізнесу. Якщо вам щось не зрозуміло та потребує пояснень з боку інших розробників, то ви або розбираєтеся, або вас звільняють як непрофпридатного із займаної посади.

Pavlo Vuiko

Serhii D Software Developer 20.10.2024 19:05

Основна причина винекнення TS — хтось не вміє принципово працювати з нестрогою динамічною типізацією

̶В̶і̶д̶о̶м̶и̶й̶ ̶а̶в̶т̶о̶р̶и̶т̶е̶т̶ ̶т̶а̶ ̶л̶а̶у̶р̶е̶а̶т̶ ̶п̶р̶е̶м̶і̶ї̶ ̶Т̶ю̶р̶и̶н̶г̶а̶ невизнаний геній Олександр Шпак.

Олександр Шпак Oarsman в Self Employed 20.10.2024 21:18

Дякую, дякую

Serhii D

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 22:10

Основна причина винекнення TS — хтось не вміє принципово працювати з нестрогою динамічною типізацією

От всі дурні, один ви розумний)

Не пускайте низькорівневих розробників в високорівневий код. Ви ж не довіряєте операції на серці чи на мозку студентам? То чому ви довіряєте вносити зміни в ядрі системи джунам?

Я мав на увазі, що іноді від одного функціоналу залежить інший функціонал, і якщо там внести зміни без оцього злого TS, то доведеться все переробляти ручками і надіятися, що нічого не забув, а TS одразу б червоним підсвітив

Ви працюєте з розумово відсталими людьми, чи що?

Я працюю з професіоналами, це ви по ходу або працюєте одні на пет проєкті, або фічі на вашому проєкті прості як 2 копійки. Бо якщо фіча комплексна і її писав хтось інший, то треба час щоб у ній розібратися, навіть якщо код написаний добре

Олександр Шпак Oarsman в Self Employed 21.10.2024 00:16

От всі дурні, один ви розумний)

Та про це вже сотні книжок написано мабудь, а ви до сих пір це якось інакше трактуєте. Людина, яка звикла роками робити одне й те саме, не може так просто звільнитися від своїх звичок та переналаштуватися під інші умови навколишнього середовища. Першим же ж її бажанням буде змінити все навколо під себе. Не змінюватися, не розвиватися, я залишитися в тому стані, який комфортний.

Я мав на увазі, що іноді від одного функціоналу залежить інший функціонал, і якщо там внести зміни без оцього злого TS, то доведеться все переробляти ручками і надіятися, що нічого не забув, а TS одразу б червоним підсвітив

Окрім сильнопов’язаної архітектури є ще її антагоніст — слабкопов’язана архітектура, внесення змін в якій дуже рідко призводить до зміни функціональності в продукті в цілому. Прикладом може бути той самий *nix way, якому вже десь під 50 років, та який довів свою нереальну ефективність. Ваші проблеми та страхи — від вашого способу мислення та кругозору.

Я працюю з професіоналами,

Щось перевелися професіонали...

це ви по ходу або працюєте одні на пет проєкті

Не намагайтеся принижувати мої досягнення. Якими б не були мої проекти, що б я не робив, це не зробить ВАШ досвід кращим. Один проект я розвивав 7 років поспіль, інший — 10. З командами. Давайте я вам для прикладу наведу, що перший SaaS SPA я робив ще під IE6. Тоді ще ані React’ом, ані Angular’ом не пахло. Це було 17 років тому (летить час...)

Бо якщо фіча комплексна і її писав хтось інший, то треба час щоб у ній розібратися, навіть якщо код написаний добре

Якщо ви страждаєте від того, що вам складно читати інший код, то він вже написаний погано. Це ж «Л — логіка». Єдиний код, який всім буде важко читати, й тому хто пише, й тому, хто читає, це високооптимізований код, там де читабельність взагалі не в пріоритеті. Там навіть коментування не завжди допоможе.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 21.10.2024 00:26

перепрошую, але читаю те що ви пишете, і у мене виникають якісь сумніви, що ви брали участь в розробці проєктів зі складними фічами, якщо вважаєте, що динамічна типізація і GRASP легко роблять складні, комплексні фічі легкими. Якщо фіча комплексна, то і код буде комплексний, так, він може слідувати всім бест практісам по рідабіліті, GRASP та SOLID, але це на вирішує проблеми, що коду буде багато, що може бути якась комплексна взаємодія між модулями і сервісами, на те щоб вникнути в цю інфраструктуру потрібен час, що вже говорити коли треба вносити у неї зміни

Олександр Шпак Oarsman в Self Employed 21.10.2024 01:59

і у мене виникають якісь сумніви, що ви брали участь в розробці проєктів зі складними фічами

Так, це передбачувана поведінка.

якщо вважаєте, що динамічна типізація і GRASP легко роблять складні, комплексні фічі легкими

У вас це не вкладається в голові, тому що ви намагаєтеся приміняти патерни, підходи, архітектуру, які вам зрозумілі та звичні, до архітектур, які мають інший базис під капотом, які розвивалися в умовах повної динаміки. І, звісно ж, ви одразу відкидаєте щось незрозуміле та невідоме як заздалегідь неправильне. Але динамічна типізація — це світ з іншими правилами, пізнавши який ви можете тільки занурившись в нього.

Приведу простий приклад. Є якийсь ендпойнт API, він видає перелік якихось конкретних даних. Перша ж ваша думка буде — описати структуру елементів. Якщо з’являється вимога додати якийсь фільтр, ви одразу почнете описувати параметри та їх тип. Це логічні та прості дії, повністю в парадигмі строгої типізації. Якщо додати ще один ендпойнт, операції повторяться. Звучить все круто, логічно, передбачувано.

В світі динамічної типізації два ендпойнти не відрізняються між собою. В них однакові риси — перелік даних та функція фільтрації. Процедура фільтрації під капотом буде однакова — прийняти параметри, визначити ті, з якими можна працювати, провалідувати значення, сформувати запит, повернути результат. Різниця між ендпойнтами буде лише в ... конфігурації роботи функцій. Динамічна типізація дозволяє написати універсальні методи, функції, процедури, які будуть однаковими для всіх ендпойнтів. Тобто у вас буде умовний десяток функцій на сто ендпойнтів API. І тисяча класів для статичної типізації (умовно). Як на мене, перевага очевидна, конфігурування завжди краще за написання коду.

Далі, динамічна типізація стимулює використовувати fail safe та fault tolerant підходи, коли помилка є частиною нормального процесу та не призводить до зупинки всього. Немає параметру? Ок. Є зайві п’ять — теж Ок. Параметр може бути масивом або скаляром? Не проблема, конвертуємо в масив та обробляємо як масив. Тобто, ваша система завжди буде намагатися «зрозуміти», що від неї хочуть та не падати, якщо щось пішло не так. Тому що на вхід може прийти все, що завгодно. Це аксіома.

Я вже приводив приклад того, що код мого нового проекту складає лише 150Кб немініфікованого JS. З них 65Кб — згенеровано. Писали б на якомусь реакті або TS — були б мегабайти.

Pavlo Vuiko

Vic Programmer 18.10.2024 17:55

Прочитайте про SOLID (можете у Роберта Мартіна в Clean Archirecture наприклад), зрозумієте нвіщо це. I JavaScript тут нідочого. Проблема «кодінгу з акцентом» зазвичай зовсім інша — наприклад з незнанням Arbnb github.com/airbnb/javascript стайлгайду.
А так років з 5 тому вперше почав щось став писати комерційне на Node, довелось бо не було кому. Там мене команда куди я потрапив, токсити почала типу «нафіг тут Java-іст» (хоча за плечима вже були і Delphi, C++ власні намгання стартапів з PHP і т.д. і звісно купа фрондендовгого JS, я навіть пам’ятаю як JQuery був новомодним. Виявилось так звані експерти були не в курсі, про defined behavior коли в JS можна ділити на 0. Фленагана навіть не відкривали.
Це в принципі про Український ІТ на загал, з 23 річними Senior React developers. По факту першопричина усе та сама старат тема про «сири по 500». Деякі ІТ-шники в тучні роки справді зажрались. Потім почали токсити, на рівні Stack Overflow в певний момент, при чому дуже массово.

Марк Сахарчук 18.10.2024 14:18

Так JS це ж та сама джава, тільки скрипт :)

Ihoro S. Software Engineer в EPAM 18.10.2024 19:10

тільки скрипт

сквірт

Марк Сахарчук

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 00:37

Бачив як джавісти пишуть на JS.

Для них і придумали TS типу як для електрокару генератор шуму мотора 🙃

Elvira Solnyshkina Java Developer в BotsCrew 18.10.2024 11:56

Розвернемо питання в інший бік: а JS-деви що пишуть на Джаві гарно? :)

Elvira Solnyshkina

no name three 18.10.2024 15:02

Не пишуть)

Elvira Solnyshkina

Vitaliy Yermolenko 18.10.2024 10:09

Rust.

no name three 18.10.2024 15:23

І писати Linux 2.0!

Vitaliy Yermolenko 18.10.2024 15:58

Немає різниці, хоч 0.99!

no name three

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 20:37

На Rust бекенд вакансії можна перерахувати на пальцях однієї руки

Vitaliy Yermolenko 19.10.2024 22:03

Кілька разів на тиждень приходять пропозиції.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 22:23

от не вірю) саме на бек, не блок чейн чи ще щось? Я сам працював Rust бекенд розробником більше року і у мене залишилося багато колег Rust розробників, то вакансій на бек дуже мало, а хороших вакансій серед них ще менше, тому я свічнувся назад на Node.js і був щасливий

Vitaliy Yermolenko 20.10.2024 12:54

А що там у Yalantis Rust вже не комільфо? Rust department вже не працює?

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 12:54

NDA =)

Vitaliy Yermolenko 20.10.2024 13:00

Не цікаві ніякі пропозиції — все норм із бекендом у поточному Rust проєкті.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 13:15

радий за вас, що вам вдалося знайти хороший бекенд проєкт на Rust) якими лібами користуєтеся? tokio, axum, sqlx, tracing?

Vitaliy Yermolenko 20.10.2024 13:29

warp, diesel, tokio, lettre, utoipa, etc.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 13:32

охх, diesel це така біль, особливо тексти його помилок компіляції, а ще оці танці як написати з ним складну кверю, коли документація просто жахлива

Vitaliy Yermolenko 20.10.2024 13:35

Так, іноді дуже боляче, але коли розрезолвено, то просто пісня...

Pavlo Vuiko

Anatoliy Kurinnyy python developer в self employed 20.10.2024 23:06

жахлива документація це про 90% rust бібліотек

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 23:25

плюсую, ще чомусь Rust розробники дуже переоцінюють Rustdoc, і недооцінюють Readme і окремі сайти з документацією і прикладами

Anatoliy Kurinnyy

Serhiy Brytskyy Працює в Oracle 18.10.2024 02:03

Питання має стояти не «Яка мова програмування найкраща для Back-end», а «Яка мову програмування найкраще вчити для Back-end, щоб не супер тяжка у вивченні, але й щоб можна було знайти роботу».
Моя скромна особиста рекомендація — Java, виходячи з ринку, з того, на чому найбільше створюють бекенди.

Oleg Skalozub Golang dev 18.10.2024 07:56

Що питиння, що відповідь — сльози.
Не все впирається в складність вивчення, є різні регіони де та чи інша мова домінує, але і є мови де відносно просто знайти робоиу всюди як js і як java, якщо є декілька років досвіду.

рекомендація — Java

Я так розумію, що тут в вашій системі координат зійшлося і просто вивчити і швидко знайти роботу?)

Serhiy Brytskyy

Serhiy Brytskyy Працює в Oracle 18.10.2024 17:10

Чоловіче, я починав програмувати, коли ви ще казали котові «вуйко посуньтеся». Тому свій тон притримайте для когось іншого. Сльози в нього.
Ці всі «інші» мови, як каже моя знайома, вже давно з"їв і висрав.
Тому написав

Моя скромна особиста рекомендація

. Але приходять малолєтки і починають хамити.

Oleg Skalozub Golang dev 19.10.2024 22:09

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

Тому, замість

висрав

можеш, дідуля, канеша і спробувати в більш аргументований коментар, а не в форматі зупсував повітря і пішов, а можно в більш аргументованій формі, тільки, давай вуйко дідусь без втрати свідомості і підняття тиску, бо я переживаю

Маю надую, що в ораклі аргументи типу

Чоловіче, я починав програмувати, коли ви ще казали котові «вуйко посуньтеся». Тому свій тон притримайте для когось іншого. Сльози в нього.
Ці всі «інші» мови, як каже моя знайома, вже давно з"їв і висрав.

не приймаються

Serhiy Brytskyy

Volodimir Nazarenko Senior .Net Developer / Teamlead в Perfectial 18.10.2024 00:02

Бажано компільована

Andrew Levytskyi Full-stack developer в NDA 17.10.2024 23:51

PHP сила!)

Oleg Skalozub Golang dev 18.10.2024 07:58

в якому місці?

Andrew Levytskyi

Slavik Savko 18.10.2024 09:35

Усі хейтять (навіть PHPшники) та намагаються вбити. Але ніяк зараза не помре
Хіба це не сила? Та це ***ана чорна магія сотого левелу

Азаза Заазааз 18.10.2024 10:29

Хейтили, років 10-15 назад, коли PHP був зовсім іншою мовою, і на ній писали вкатуни. Зараз цю почесну ношу взяв на себе Python.

Slavik Savko 18.10.2024 10:45

Ну не знаю. Ніколи не чув про PHP гарні прям відгуки. Сама мова це як на мене триндець повний що тоді що зараз. Єдине що варте поваги це величезна кількість усього що на ній написано.
І саме прикольне що хайповий Python на 4 роки старший за php

Азаза Заазааз 18.10.2024 10:46

Ну дивлячись що саме вважати пітоном, бо пітон 2 який давно здох, і пітон 3 це різні мови, і хайпанувся саме третій пітон.

Олександр Мощенко 18.10.2024 10:52

та хіба? якраз хайпонувся, імхо, пітон десь 2.4 — 2.7 версій. Коли 3 вийшла в інфопросторі вже не було такого ажіотажу навколо нього.
і на третій досить довго деякі мейнстрімні ліби ледь не принципово не переповзали. Правда не пам’ятаю хто

Азаза Заазааз 18.10.2024 11:04

Третій хайпонувся як еталон гівномови, а чого так сталось бо між 2 і 3 зламали сумісність і були потрібні раби-вкатуни щоб переписати це все. А ці раби були не найкращої якості, і за пітоном закріпився коричневий слід, а потім його ще й різного роду «інфлюенсери» почали продавати як вайті в айті, там тіпа пітхон за годину, і розфорсили ще більше цей коричневий слід.

Олександр Мощенко 18.10.2024 11:05

фу, двачєр
в пехопе теж від 5.6 до 8.2 добре так позмінювали всякого. В мускулі з 5.7 на 8 теж перекочуватися треба з обережністю
мова розвивається і це нормально.

Азаза Заазааз 18.10.2024 12:02

2 і 3 це не розвиток, це переписування.

Олександр Мощенко 18.10.2024 12:07

та так про все можна сказати. типізація в пхп — не розвиток а дописування, match — не розвиток а цукор, null-safe — не розвиток а викреслювання.
Розвиток же буває не тільки кількісний, а й якісний.

Олександр Шпак Oarsman в Self Employed 18.10.2024 11:12

Є первна упередженість до PHP. Є дійсно речі, за які їх треба бити ногами боляче-боляче, наприклад, за абсолютно рандомні позиції параметрів функцій, коли в одному місці порядок A/B, а в іншому B/A. Це вже виправляється шляхом створення обʼєктних обгорток або введенням нових функцій, але процес йде повільно.

В іншому є речі, які просто геніально зроблені, наприклад SimpleXML. Свого часу подобалися магічні методи, там можна було зробити доволі цікаві речі, коли можна рознести публічну (що доступно ззовні, не public) частину методів модуля, та внутрішню його кухню, не обмежуючи себе в ООП можливостях.

www.php.net/...functions.named-arguments

Oleksandr Dubyna Senior Full Stack Software Engineer в xneelo (Pty) Ltd 18.10.2024 11:36

Олександр Шпак Oarsman в Self Employed 18.10.2024 11:41

Офігеніум! Очікую аналогічного в JS!

Oleksandr Dubyna

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 01:22

Офігеніум! Очікую аналогічного в JS!

Бо дужки зараз заважають? ({name, age}) => {}

Олександр Шпак Oarsman в Self Employed 19.10.2024 11:28

Там трохи ідея в іншому. У вас є функція, яка приймає два параметри

function foo(a, b){ ... }

Але коли її викликаєш цю функцію, то ти можеш передати параметри по позиції

foo(2, 65)

Або використовуючи імена параметрів

foo(b: 2, a: 65)

Це просто офігезно, коли в тебе функція перевантажена (в мене таких в коді валом через особливості фреймворка), і, щоб додати якийсь параметр наприкінці, не треба городити город з обʼєктом або вставляти андефайнеди або нулі в проміжку

foo(1, 2, undefined, undefined, undefined, true)
foo(1, 2, { boo: true })
foo(1, 2, boo: true)

Останній варіант простий та лаконічний, але, на жаль, поки не реалізований.

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 16:05

Або використовуючи імена параметрів

Ну так функціонально це те саме, тільки і того що не можна буде викликати обома способами, але ж воно і не потрібно.
По дизайну функція повинна намагатись мати невелику кількість параметрів, де їх опціональність зростає зліва направо. Якщо там велика кількість параметрів і велика кількість опціональних то це все рівно загортають в об’єкт.
Тому не буде смислу заради пропуска одного чи двох параметрів з умовно 5-6 послідовних параметрів звергатись до останнього там за його ім’ям, якби це було можливим.

Це просто офігезно

Офігенно воно б було, якщо таки додали пропуски параметрів, як в масивах, але поки там заглохло. Для пропуску кількох параметрів саме те, ще й скорочується кількість символів, що гарно для мініфікації.

foo(1, 2, , , , true)

Хоча технічно є сумнівний костиль :)

foo(...[1, 2, , , , true])

але, на жаль, поки не реалізований.

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

Олександр Шпак Oarsman в Self Employed 19.10.2024 18:19

По дизайну функція повинна намагатись мати невелику кількість параметрів, де їх опціональність зростає зліва направо.

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

І не буде, бо як мінімум це ламає мініфікатори

Не ламає наче. Є якесь імʼя в декларації функції, воно буде замінено на коротке, а у викликах буде зроблене аналогічне. Ніяких проблем не бачу.

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 20:40

воно буде замінено на коротке, а у викликах буде зроблене аналогічне.

Чомусь зараз для того же самих деструктиризованих параметрів функцій це не робиться, очевидно тому що це не повністю безпечне перетворення

Denis Yemelianov 17.10.2024 16:06

Для Back-end підходять кілька мов, вибір залежить від ринку та цілей:

JavaScript — універсальний вибір, особливо якщо вже знаєш фронтенд.
Python — простий у вивченні, зростає попит у веб-розробці та аналітиці.
Java — для масштабованих систем, стабільний попит у великих компаніях.
C# (.NET) — популярний у корпоративних проєктах.

Якщо тільки починаєш — Python або JavaScript будуть гарним стартом.

Taras Terletsky Python Backend Engineer в SoftServe 18.10.2024 14:23

Python — простий у вивченні, зростає попит у веб-розробці та аналітиці.

Це з якого року зростає? З 2010-го? Попит був завжди. Також всі завжди забувають за cybersec/telecom/networking-домени, де пайтон завжди був, є і буде популярним для написання бекенду.

Denis Yemelianov

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 20:42

Ну на JS писати бек це мазахізм, для цього є TS, щодо Python, а він точно зростає на беці? Бо неадавно мій колега, дуже хороший Python інженер і інженер в цілому захотів свічнутися в Node.js, бо Python почав рухатися в сторону заміни PHP по його словах

Denis Yemelianov

Леонид Мартынюк инженер-программист в 1World online R&D Сenter 17.10.2024 11:52

вчити тре програмування а не мови програмування. а задавати подiбнi питання взагалi безглуздо — кожен вiдповiсть про те що йому подобвется вбо що вiн вмiе бо що зараз модно.
Особисто я при можливостi використовую PHP просто тому шо вiн простий i заточений на бекенд с самого початку свого iснуванняю I проекти на ньому можна розгорнути на будь якому дешевому i не потребуючому адмiнiстрування вiртуальному хостингу

Slavik Savko 17.10.2024 12:32

заточений на бекенд с самого початку свого iснування

Коли його створювали навіть слів таких не було :-)

Леонид Мартынюк

Serhii 17.10.2024 12:41

~~Жопа есть, а слова нет~~

Слова не було, а бекенд був

Sergey Lysak T/T Lead 17.10.2024 12:45

...Забув хто з великих вчених, читав якось публічну лекцію.
— Кисень був відкритий в 1773 ...
і тут із зали каверзне питання:
— А чим же люди дихали до того, га??

Таких каверзних питань у форумних холіварах да, повно :)

Serhii

Sergey Lysak T/T Lead 17.10.2024 12:43

Announce: Personal Home Page Tools (PHP Tools)
Lerdorf, Rasmus (1995-06-08)
groups.google.com/...6z7A/m/M9FkTUVDfcwJ?pli=1

Oleg Skalozub Golang dev 18.10.2024 07:59

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

Леонид Мартынюк

Олександр Шпак Oarsman в Self Employed 18.10.2024 08:35

Це було за царя Гороха ще. Тоді ще Go навіть в планах не було.

Oleg Skalozub Golang dev 19.10.2024 21:50

Так, і чим старіша мова, тим більше депрікейтед речей вона тягає за собою, нащастя з молодими простіше будувати проекти)

ПС з молодими, не з маленькими

Олександр Шпак Oarsman в Self Employed 19.10.2024 22:52

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

Oleg Skalozub Golang dev 20.10.2024 12:37

саме в цьому треді піднімалося питання про що з самого початку була пиха тому історія про старе і молоде є тут актуальною

Ruslan Polutsygan 17.10.2024 10:59

тільки не го

Oleg Skalozub Golang dev 18.10.2024 08:01

О_о ну мені вже, слава богу, запізно дослухатися до цієї паради, але цікаво чому?

Ruslan Polutsygan

Ihoro S. Software Engineer в EPAM 18.10.2024 19:14

Передивилися Саню Соловйова і інших гейтерів)

Yevhen Radionov Software Engineer в SQUAD 20.10.2024 14:31

Схоже на те

Ihoro

TAlex Laravel PHP Developer 16.10.2024 22:13

Мова алгоритмів, паттернів, архітектури. А далі натягується на будь який синтаксіс будь якої МП

Oleg Skalozub Golang dev 18.10.2024 08:05

я канеша не проти, але ну камон, на довго вас вистачить, якщо почати не з хелоу ворда, а з гофа, Роберта Мартіна, Фаулера і т.д. і все це на мові алгоритмів?

TAlex

Марк Сахарчук 18.10.2024 14:24

Роберта мартіна давно вже пора на звалище. Та ще шляпа

Serhii D Software Developer 18.10.2024 14:43

А хто його вже замінив ?

Марк Сахарчук

Порохобот 18.10.2024 22:19

Где-то с середины 2010-х, с паттернами из гофа стало модно делать так:
— вводишь в гугл название паттера гоф
— добавляешь «antipattern»
— читаешь...

Serhii D

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 20:48

А можете навести приклад? Бо з мого досвіду, щоразу коли я зустрічаю людину, яка хейтить GoF паттерни, то це зазвичай адепт FP, який начитався «розумних» книг, форумів, відео і нічого складніше пари простих пет проєктів не написав використовуючи набуті знання, або якщо і писав щось серйозне, то там одноразовий код непридатний для підтримки і розширення

Порохобот 19.10.2024 21:00

«singleton antipattern»
«factory antipattern»
«subject observer antipattern»
«facade antipattern»

итд, итп

Практически всё, что ООП-апологетами строилось на абстрагировании путём наследования — с 2010 постепенно стало трактоватъся, как анти-паттерн.
Т.к. концепт наследования — это в ООП не фича, а баг.

Pavlo Vuiko

Олександр Шпак Oarsman в Self Employed 19.10.2024 21:08

Пройде ще років 10-20 та ООП взагалі почнуть вважати антипаттерном :D

Порохобот 19.10.2024 21:14

Это едва ли. Разве что, написание кода — станет прерогативой ИИ.

Олександр Шпак Oarsman в Self Employed 19.10.2024 21:49

Я б посперечався. Вже давно помічаю, що структурування інформації наносить більше шкоди, ніж вирішує проблем. Це контрінтуїтивно, але в мене є докази ;) Спочатку візьмемо ШІ та його спосіб роботи. Якщо надати йому на вхід шмат тексту, то він не робить ніякого синтаксичного аналізу. Дані беруться як є, тупо потік чогось. Після обробки відповідь генерується так само в «довільній формі». Отже, ми маємо процес обробки, але структурування даних тут не відіграє жодної ролі, результат все одне буде потрібний користувачу.

Другий момент. В реальному світі порядку дуже мало, можна помітити певні тенденції, але завжди зʼявиться якесь виключення. Тому, коли ми структуруємо щось, то ми суттєво обмежуємо себе в розвитку системи. Вона стає крихкою та ненадійною. Будь-яка нова ситуація, яку треба обробити, вимагає втручання, переписування, внесення змін, та навіть видалення з системи. Це час та додаткові ресурси.

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 21:59

Потім обі**уться, побачать, що написаний номи код неможливо підтримувати, вносити зміни і розширювати і повернуться назад до ООП 😅

Олександр Шпак Oarsman в Self Employed 19.10.2024 22:53

Ні, скоріше забудуть як страшний сон та більше не будуть повторювати власних помилок...

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 21:33

Будь який патерн існує для того, щоб вирішити конкретну задачу, а не просто для того щоб його впихнути в проєкт, якщо той же сінглтон вирішує задачу, то це не антипатерн, те саме можете прикласти до інших перелічених патернів. Щодо наслідування, то погоджуюся, що це зло в 90% випадків але буває і трохи помічне. Також щодо GoF патернів додам, що це підходи, які довели свою важливість і помічність протягом десятиліть розробки ПЗ для десятків тисяч проєктів в проді (навідмінну від всякого новомодного pure FP та іншої лабуди), до того ж ці патерни не прив’язані до ООП намертво, їх можна використовувати і без ООП

Порохобот 19.10.2024 21:56

а не просто для того щоб його впихнути в проєкт, якщо той же сінглтон вирішує задачу

Как правило, если в проекте синглтон — его приходится выковыривать и выкидывать. Потому что, мешается под ногами — и усложняет всё, от DI и расширения системы, до написания тестов (поди мокни этот синглтон в тесте, к примеру).

И это несроста так. Поскольку синглтон нарушает сразу несколько тех же принципов SOLID (как многие другие паттерны ГоФ).

Многие паттерны ГОФ навеяны ООП-парадигмой 90-х, в исполнении Буча и Румбауха — где каждая проблема решалась наследованием. И соответственно, устарели ещё в середине 2000-х — когда начался тренд в пользу композиции.
Впрочем, где-то в ГОФ уже тоже проскакивало, что композиция часто предпочтительнее.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 13:32

Как правило, если в проекте синглтон — его приходится выковыривать и выкидывать. Потому что, мешается под ногами — и усложняет всё, от DI и расширения системы, до написания тестов (поди мокни этот синглтон в тесте, к примеру).

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

И это несроста так. Поскольку синглтон нарушает сразу несколько тех же принципов SOLID (как многие другие паттерны ГоФ).

Наведіть приклади, я не погоджуюся.

Многие паттерны ГОФ навеяны ООП-парадигмой 90-х, в исполнении Буча и Румбауха — где каждая проблема решалась наследованием.

До чого взагалі наслідування до GoF паттернів? Мені в голову не приходить жоден з них, який на наслідуванні завʼязаний, або щоб при його імплементації можна було цього наслідування уникнути

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 13:58

ще додам, що імплементацію і доцільність використання деяких GoF паттернів сильно залежить від мови програмування. Наприклад Builder в TS/JS фактично немає сенсу, бо можна банально на вхід конструкора чи функції передавати обʼєкт який містить в собі купу необовʼязкових полів з дефолтними значеннями, також в функцій є дефолтні значення параметрів, Rust наприклад так не вміє, тому там Builder використовується дуже часто і без нього ніяк. Так само в JS/TS не особливо є сенс імплементовувати Strategy як в Java, бо можна банально створити Map, де ключ це значення з енама, а значення це функція яка щось робить. Ну і думаю багато такого можна навести для різних комбінацій мов і патернів

Pavlo Vuiko

Serhii D Software Developer 20.10.2024 19:11

Так само в JS/TS не особливо є сенс імплементовувати Strategy як в Java, бо можна банально створити Map, де ключ це значення з енама, а значення це функція яка щось робить.

Ви тільки що описали як реалізувати патерн стратегію на js. На java його також можна так само імплементувати, через мапу.

Pavlo Vuiko

Serhii D Software Developer 20.10.2024 19:12

template method завʼязаний на наслідуванні.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 22:33

ніколи не бачив, щоб його на практиці використовували, але ок, це лиш один з 20+ GoF патернів

Serhii D

Myroslav Berlad Software Architect 16.10.2024 21:36

та котру знаєш

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 20:51

Тут людина не знає, тому власне і питає

Myroslav Berlad

Viktor Zhurbenko Dev 16.10.2024 15:34

Python + Typescript. Перший активно в веб і ML живе, на другому весь фронт і трошки беку. Але взагалі берете вакансії по локації де хочете працювати і обиратєте з топ3 що більше до вподоби.

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 20:52

На Typescript дуже багато беку) одна з найпопулярніших мов там

Viktor Zhurbenko

Сергій Цимбалюк 16.10.2024 14:39

У нас тут помалу в коментарях шортліст формується:
— Haskell
— Rust
— Clojure

Slavik Savko 16.10.2024 14:49

Х"ня У нормальних пацанів повинен бути такий
— ML
— C
— Common LISP

Sergey Lysak T/T Lead 16.10.2024 14:56

Швидше з’явиться ШІ програміст який замінить 80% програмістів людей, аніж цей список якось можна буде побачити у дійсності, а не в маргінальних холіварах на форумах.

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 20:55

Перепрошую, але це список мов для людини, яка не хоче знайти роботу, а хоче писати пет проєкти з важливим виразом обличчя) це якщо говорити про бекенд, на блок-чейн вже простіше для Rust знайти роботу

Roman DevOps 16.10.2024 14:29

Go, Rust

Emma Orlova SDE 16.10.2024 14:00

Clojure звісно

Sergiy Morenets Java evangelist 16.10.2024 11:39

Java

Vic Programmer 16.10.2024 13:13

Java — яка ?
Java EE / Jakarta EE Whyldfly, WebLogic, Web Sphere EJB і т.д.
Spring MVC
Spring Boot
Spring WebFlux
Play Framework
Vaadin Framework
Google GWT
Apache Struts (він як фенікс повстав з попелу)
і там ще купа
Насправді на вивчення одного чогось, якщо новачок — піде дуже суттєво часу. Далі там звісно воно +/- всюди те саме і не так вже і сильно на повірку відрізняється навіть як різні мови програмування.

Sergiy Morenets

Сергій Цимбалюк 16.10.2024 14:25

Зараз не 2010-й рік, звісно Spring Boot.

Vic

Vic Programmer 16.10.2024 15:01

А чому не Flux чи Play ? Ну окрім — прое тіа де міняють вендора і просять те що на цьому навояли, переписати на звичайні контролери.

Anton Pokhyla Software Engineer 17.10.2024 18:14

Раджу ознайомитись з Vert.x і Quarkus ;)

Vic

Олександр Шпак Oarsman в Self Employed 17.10.2024 19:12

І що, як досвід використання vert.x?

Anton Pokhyla

Anton Pokhyla Software Engineer 17.10.2024 19:18

Позитивний. Окрім перформансу/ефективності, він набагато легший і простіший у підтримці/розробці порівняно з тим самим спрінгом 🙂

Vic Programmer 17.10.2024 22:27

Це з того же розряду, що і на Rocket та чи Dragon — тільки мова Java. Напевно переваги є — тільки ті хто це започатковує, з проекту пропадають на +500 чи там звалює у Лондонській Fecebook як це часто в моєму випадку. А ви потім з цим залишайтесь на одиниці в комерційному проекті і коли виникають проблеми — їх вже не нагуглити, вже вам в дебегер (а коли воно ще і закрите не дай, то взагалі жопа з декомпіляцією і т.д.). Я так в перше Kotlin-м зайнявся, років з 5 тому, а до того : Groovy, Scala та Ruby.
Так що погратись можна — в коли буде черговий комерційний проект, то особисто я оберу надійну і перевірену технологію, дуже сильно бажано відкриту.

Anton Pokhyla

Anton Pokhyla Software Engineer 17.10.2024 22:39

В цьому є свій сенс, але навіть при цьому для якихось високонавантажених систем де ключовою є простота і легкість я однозначно буду дивитись в сторону Vert.x і його похідних — там на відміну від Spring’a можна відразу знайти причину неполадки прямо в коді, натомість розплутати спагетті весни часом буває не так просто ;(

Vic

Vic Programmer 18.10.2024 03:12

Та є статистика, в 80% випадках провалу по швидкості — це проблема в роботі з базою данних. При чому не так вже і важливо якою конкретно. З NoSQL , потрібно так само вміти працювати як і з реляційними моделями данних. І там теж купа особливостей. За великим рахунком для звичайного CRUD між : PostgreeSQL, MySQL, Oracle чи MS SQL — буде набагато менше різниці, ніж хитромудрі сплетіння проміж Claud Spaner та BigTable або Dynamo DB та Mongo і Neo4J та Hadoop/HBase заодно.

Anton Pokhyla

Vic Programmer 16.10.2024 11:04

А взагалі то цікава тема. Чи можна виділити об’єктивні критерії оцінки якостей. Для прикладу :
Маркетингові — просунутість технології на глобальному ринку :
Розмір комьюніті
Компанія/ї які роблять підтримку та контролюють чи коньрибьютять в стек
Наявність якісної документації, книг, кукбуків, відео,тренінгів, конференцій тощо
Наявність та кількість якісних фреймверків які дозволяють вирішувати нагальні бізнес проблеми, ціна таких рішень — чи потрібні ліцензійні відрахування і т.п.
Технічні
Трудомісткість створення базових операцій, (станом на зараз це здебільшого мікросервіси CRUD із REST API під SPA Web та мобільні апки)
Накладні розходи на performance — тобто CPU та пам’ять, тобто як дорого коштують абстракції
Безпека — які базові і додаткові механізми захисту від кібр загроз, як самого стеку так і най популярніших фреймверків
Ринкові
Бажання бізнесів на глобальному і українському ринку працювати із технологією. ЛПР C рівня CTO, CEO і т.д. згодні працювати та інвестувати в технологію бо бачать бізнес перспективи (як бачимо періодично гасять десятки тисяч долларів на різні flutter-и і потім пишуть про це статті, що воно не виправдалось)
Наявність людей згодних менторити і створювати команди на певній технології (так є токсичні болота, де не беруть чи виживають джуніорів або світчерів взагалі)
Наявність відкритих вакансій тобто попиту і кількість кандидатів тобто пропозиції

Sergey Lysak T/T Lead 16.10.2024 14:01

Навіть теоретично складно. Бо треба звести до єдиного параметру.
А навіть моделі — і близько немає.

Тому на практиці — швидкість розробки переважає практично все.
Не завжди звісно, тому й «Rust» буває найкращим вибором.
Але «PHP» рулить!

Бо сили які впливають — час, гроші, люди.

А «CPU» частенько — набагато дешевше коштує — ніж час-гроші-люди.

Vic

Vic Programmer 16.10.2024 14:58

Ну остання теза — це не з життя часто. Звісно я кажу з позиції чувака, який от прямо зараз моніторить сервіс у якого 10-11 мільйонів викликів на добу.
Та починаючи десь з 18 року, куди мене тільки не заносило, на проектах зоопарки усе, де усе що завгодно від PHP до Erlang. Node зараз — загально розповсюджений.
Головна перевага PHP — це якраз розповсюджені фреймверки та CMS. Реально під більшу частину WEB — 80% там готово, треба налаштувати та підтюнити.
Node як і Java — це більше як конструктори типу Lego, перший явно копіює кращі ідеї з другого.
Ну а Go, С++ та Rust — з розряду екзотики, лише з FAANG народ постійно каже, що там С++ це мало не головна мова.

Sergey Lysak T/T Lead 16.10.2024 16:03

Звісно я кажу з позиції чувака, який от прямо зараз моніторить сервіс у якого 10-11 мільйонів викликів на добу

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

У холіварах частенько враження що з отакою принцесою спілкуюсь.

10-11 мільйонів викликів на добу — яких, якого типа, і т.д. і т.п.
Ну ви ж інженер. Ну невже не розумієте що ці числа мало що значать.
Ну от до «сервера» з LLM всього «пара десятків викликів на добу». Смішне навантаження, раз плюнути такий сервіс написати! :)

де усе що завгодно від PHP до Erlang

ну да, все що завгодно може бути.
а ніколи не було цікаво якісь відсотки пошукати?

Головна перевага PHP — це якраз розповсюджені фреймверки та CMS

А яка була в нього перевага що на ньому писали фреймворки та CMS?
чи він з ними зразу народився?

Node як і Java — це більше як конструктори типу Lego

не розумію цієї аналогії.

перший явно копіює кращі ідеї з другого

Писав професійно на Java, зараз на Ноді. Не знаю про що ви.
Є загальні ідеї в комп’ютер сайенс та інженерії, які десь реалізуються.
Наприклад загальна ідея — JIT. або GC.
Що з JVM взято в Node.js — не знаю.

Підкажіть, цікаво.

лише з FAANG народ постійно каже, що там С++

У Meta
Hack та JS :)

Здається ніхто не згадав мову бекенда у Meta :)

Vic

Andrii Sevastianov 16.10.2024 18:59

Теоретично це дати бюджет на розробку одного завдання, та вести її за допомогою різних інструментів. Та порівняти витрати.

А на практиці те що ти знаєш, або маєш мотивацію вивчити.

Sergey Lysak T/T Lead 16.10.2024 20:05

Теоретично це дати бюджет на розробку одного завдання, та вести її за допомогою різних інструментів

І практично це чимало разів робилося. Просто випадково, не дуже точно — але робилося.

З останнього такого випадку що чув:
на доповіді про RoadRunner питання з залу було
а чого ви взагалі не відмовитесь від PHP, у вас же великі команди на Go

А тому, що в нас чимало замовників, і перевірено не раз:
поки команда на Go викатує першу фічу, команда на PHP вже 3тю проситься зробити

Та порівняти витрати.

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

Ну і, бувають задачі з високими вимогами скажімо до використання ресурсів заліза.
Матриці перемножати на «php» не дуже вийде, хоча й швиденько код би написався

ну і сама історія пхп — наочна.
Лердорф його написав бо надоїло довго писати на perl.
От і зробив собі штуку — на якій набагато швидше та простіше писати те що йому треба було, аніж на perl

Andrii Sevastianov 16.10.2024 21:07

Практично це у контексті однієї фірми. А там зазвичай виникне багато історичного контексту. Ідея як раз робити рандомізоване подвійне сліпе дослідження.

Sergey Lysak T/T Lead 16.10.2024 22:06

Цікаво звісно.
Але в мене сумнівів немає, що завдання
написати з нуля, тільки на системній бібліотеці, універсальну CMS функціоналом Wordpress
3ма програмістами
за перше місце боролися б PHP та Python
на другому опиналась би Node.js — з JS/TS
на третьому Java/C#
на четвертому Go
... і десь там, на 7ому змагалися б Rust з С++ :)

Уточнення до завдання — тільки голе API такої CMS — не змінило б ці місця.

З єкомерс — так само б залишилось.

Andrii Sevastianov 16.10.2024 22:12

Швидше так. Але якщо будуть строгі вимоги щодо багів, то не впевнений. Якщо будуть вимоги по швидкодії, також.

Sergey Lysak T/T Lead 16.10.2024 22:21

з багами можна боротись процесами розробки. Які уповільнять розробку, і тоді битися будуть втрьох PHP Python та strict TS(за any — катування!) — а в потилицю будуть дихати Java з C#

можна поставити чимало інших вимог, які можуть просто викинути з змагання «php» взагалі

Або, як колись
А на оцій вашій Джаві — можна драйвер відеокарти написати?
Отож! Фігня ота ваша Джава, Плюси — форева!

Andrii Sevastianov 18.10.2024 10:54

з багами можна боротись процесами розробки. Які уповільнять розробку,

Тут я не впевнений. Часто проекти доходять до тієї межі, коли виправлення одного багу додає інший. Тут, наприклад, якщо брати compcert, ти ми маємо компілятор Сі та математичний доказ того, що він працює коректно, багів немає. А от без математичного доказу, завдяки лише процесу, я не дуже впевнений, що такого можна досягти.

В принципі, якщо брати лише обробку текстів та БД (сайти як головний приклад), то я згоден у тому, що розробка нових можливостей на PHP буде одна з найшвидших. Але я наводив Haskell більше як приклад надійності, у більшості випадків якщо код компілюється, він працює правильно, сама мова не дає можливості десь помилитися, та чогось не догледіти. Це трохи інший вимір, який, все ж таки, як на мене, часто не дуже важливий у бізнесі, де важливіше все ж таки зворотній зв’язок. Важливо викатити версію як можна швидше, а там може її треба буде повністю змініти та переписати, тому наявнять багів взагалі не партить. А от коли з’явиться ± вдалий прототип, тоді пофіксити 90% потрібних робочіх кейзів.

А на оцій вашій Джаві — можна драйвер відеокарти написати?

Я не бачу проблему написати на Java операційну систему.

Олександр Шпак Oarsman в Self Employed 18.10.2024 11:14

Я не бачу проблему написати на Java операційну систему.

Тільки одне запитання, хто буде запускати VM?

Andrii Sevastianov 18.10.2024 15:42

А є проблема скомпілювати в нативний код?

Азаза Заазааз 18.10.2024 12:12

Я не бачу проблему написати на Java операційну систему

Так андроїд вже існує, якщо в минуле копнути то Solaris мав все користувацьке оточення написане на джаві, JDE. Навіть ядро на джаві хтось уже писав.

Олександр Шпак Oarsman в Self Employed 16.10.2024 22:18

Щось мені так здається, що PHP все одне б зайняв перше місце... Там все впирається в те, наскільки швидко ти зможеш написати власний фреймворк.

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 22:38

думаю, що Node.js по швидкості розробики на одному місці з Python та PHP має бути, з іншим погоджуюся

Олександр Шпак Oarsman в Self Employed 16.10.2024 23:21

В JS немає стільки базових функцій, які є в PHP «з коробки».

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 17.10.2024 09:11

можливо не має, але якщо використовувати NestJS, то швидкість написання коду точно зрівняється, якщо не перевершить PHP та Python

Олександр Шпак Oarsman в Self Employed 17.10.2024 12:19

Там умови стояли —

тільки голе API такої CMS

Якщо взяти фреймворки, то на PHP все одне вийде швидше, бо там є той самий Ларавель.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 17.10.2024 12:35

ну так, задача написати саме API, без фронт енду, не було рестрікшену, що не можна використоувати фреймворки. Чому ви думаєте, що з Laravel буде швидше, ніж з NestJS?

Олександр Шпак Oarsman в Self Employed 18.10.2024 16:17

Більше документації та комʼюніті

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 18.10.2024 17:31

не погоджуюся) у JS/TS найбільше комʼюніті, це загальновідомий факт, з опитувань

Vic Programmer 18.10.2024 13:44

якщо використовувати NestJS

Ну як же не хайпонути з нещодавно вивченим фреймверком «який усіх порве».
В реальнотсі — якщо вам треба завтра їхати і часу на старт, скажімо півтора місяці на усе про все. То з Wordpress, Joomla!, Drupal, Megento і т.д. — ви ставете і налаштовуєте готовий функціонал, можливо дописуєте якусь payment інтеграцію — якої нема в списку, наприклад з україньскими платіжними системами. Так само наприклад із Java, тільки платформи часто корпоративні із зкаритим кодом — типу Adobe AEM, SAP Hybris і и.
А NestJS — дозволяє з коробки написати hello world, по факту це черговий аналог тих же Spring, Zend, Laravel і т.п., це набір інструментів «зроби сам з полуфабрикатів». Щоби зробити тільки базовий сайт які дають CMS-ки посто MVP із простою мордою, навіть без адмінки і т.д. — ну місяць і піде з тестуванням, та там буде доволі убого і величезна купа багів. І по суті на Node є лише ghost.org/docs з загально росповсюджених і величезна купа велосипедів, яким до рівня Wordpress чи Drupal, як рачки до Луни.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 18.10.2024 19:32

стоп, задача ж була написати бекенд для своєї CMS, а не cклепати базовий сайт з CMS

Vic

Vic Programmer 19.10.2024 00:06

Тут чисто флейм тема, тролонута — яка мова краще щоб почати вчити. Прийшла ідея зробити критерії об’єктивної оцінки. Прийшли до виводу — а хрін зробиш такі критерії, є суттєво різні типи задач, суттєво різні вимоги до усього і бекенд-бекенду різнь. Базовий CRUD — можуть просто усі. Якісь мови як то : PHP, Python чи Ruby — дають можливість дуже швидко накидати щось — але мають свої вади перформанс, секюріті і т.д . Це так звана ціна абстракцій. Далі JavaScript та Node (насправді дуже спірний фреймверк, дуже далеко не для новачків хоча як і у випадку із PHP щось робити можна мало не одразу). Далі — стовпи ентерпрацсу : C# та Java (усі F#, VB for .NET, Groovy, Scala, Kotlin і т.п. різновиди діалектів). І останнє — хайперформанс це про проекти із навантаженням рівня Big Tech. Go, Rust та C++. Той же Google Search як відомо здебільшого написаний на С++. Youtube як я знаю по інсайтам теж на великий процент. На Go написані принциповий клаудний софт — особливо важливі Docker та Kubernetes.
А питання «яка краща» це з розряду «таби або пробіли і якщо пробіли — то два або чотири».
Ну і улюблена для нашого ІT тема із Senior React JS Developer, яких як займо у колег із заходу просто не буває. Там є якась технологія на проекті інженер її вивчає, у нас якщо нема комерційного досвіду — вас не візьмуть на роботу з великою вірогідністю, наймаючий менеджер не стане ризикувати, специфіка аутсорс бізнеса.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 00:24

так до чого ця ваша відповідь мені? Контекст коментарю був зовсім у іншому

Vic

Vic Programmer 19.10.2024 00:54

Ну так ви так само топите за Node як абсолют. Я у відповідь задрачую.
Звісно нема ніяких абсолютів.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 00:57

ну задрочилися ви тут добре. Node.js це прекрасна технологія з максимально швидким тайм ту маркетом, як у Python та PHP, але з кращим перформансом і екосистемою, яка дуже швидко продовжує розвиватися, найбільшим комюніті, звісно є слабкі місця як от робота з файлами, важке I/O та CPU intenisve задачі, але ніщо не ідеальне

Vic

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 01:31

звісно є слабкі місця як от робота з файлами, важке I/O та CPU intenisve задачі

Це щось з пропаганди єретиків- ніяких особливих проблем там немає з цим

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 21:09

Ну якщо у вашого застосунку мало користувачів, або ендпоінтами які містять перелічені речі дуже мало користується, то проблем не буде. А якщо вся апка заточена на роботу зі вказаними речима і багато користувачів, то швидкість роботи апки кости за інфраструктуру вас здивують)) не можу знайти відео, як знайду додам, там була доповідь на FwDays, що для вказаних задач вибрали Node.js і кости на Клауд були просто шалені, потім переписали на Java і кости зменшилися в разів 10, там була робота з файлами і багато I/O. Щодо CPU intensive, камон, це всім відомий мінус, один потік JS і все таке... Попереджуючи згадку про Worker Threads, то вони теж не допоможуть далеко у всіх ситуаціях, а допоможуть лише там де у вас вхідні і вихідні об’єми даних, для CPU intensive задачі, малі, інакше у вас весь перформанс з’їсть серіалізація/десереалізація даних для передачі в Worker Thread. Із FFI схожа ситуація, до того ж його виклик теж блокує Event Loop, можна зхрестити обидва варіанти але знову ж таки не факт, що це вилікує будь-яку ситуацію і для того, щоб це був взагалі сенс розглядати, то треба, щоб у сервера було кілька ядер, чим більше, тим краще)

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 22:01

Це залежить наскільки там оптимізована архітектура та код і які абстракції- те що круто виглядає по патернам з книжок, часто погано для заліза. Оверхед платформи в процентному відношенні яка впливає на продуктивність не такий великий як у того що зазвичай їй намагаються скормити. Звичайно що якщо переписати там на плюсах, то це інший рівень при умові що все правильно з мультипоточністью розрулили, а от за велику різницю між Node і Java дуже сумніваюся. Хоча може на щось специфічне натрапили- баги продуктивності теж бувають в самій ноді, не без цього.

Щодо CPU intensive, камон, це всім відомий мінус, один потік JS і все таке...

Здебільшого це відоме кліше.
По перше дуже важко найти синхронну задачу на бекенді для JS, яка буде впливати на відклик через блокування івентлупу. Що там такого синхронного може бути, що воно вплине на відклик івенлупу? Фібоначчі з мільйона порахувати? Що там такого синхронного на десятки чи сотні мс?
Якщо така і знайшлась, то буд-який код можна написати так, щоб час від часу івентлуп таки зміг зробити тік з полінгом. Вже навіть там scheduler.yield() (dou.ua/forums/topic/50406) запилили, хоча як я вже тут писав можна обернути в асинхронну функцію і час від часу в синхронному коді викликати

await new Promise(r => setImmediate(r))

В сиву давнину теж був такий хак, але ж з промісами і async-await тепер це читабельно, а з відсутніми 4мс на setTimeout це ще й набагато продуктивніше.
Звісно деякий оверхед залишиться, але набагато менше, чим це кудись делегувати ще і з витратами на серіалізацією і комунікацію.
Якщо для малих блокуючих задач робити декомпозицію через івенттуп, а для великих делегування, то проблема практично зникає в контексті бекенду.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 19.10.2024 22:12

Ось відео про яке я говорив:
youtu.be/...bBAV0?si=t-5Saj4pd8_UhN73

Щодо роздроблювання через setImmediate, так це дійсно робочий варіант, але разом з тим час виконання цієї задачі збільшується. Щодо CPU інтенсів задачі на беці, то у мене було таке, там грубо кажучи був готель і в ньому ієрархія як він ділиться, корпуси, секції, поверхи, кімнати і треба було робити робити всякі нетривіальні пошуки по ньому, по типу знайти 2 вільні 4-зіркові номери поруч, і нюансах був що ця інфа зберігалася одним великим JSON для кожного готелю, і треба було щоразу робити циклами пошук по цьому всьому і це займало 200-300 мс CPU обчислень, власне єдиний раз коли я скористався Worker Threads в продакшині)

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 22:42

Ось відео про яке я говорив:

Дякую, якось по дивимось що там за переполох :)

але разом з тим час виконання цієї задачі збільшується.

Як раз в мультипотоках потоки отримують умовно однаковий час ЦП (на пріоритет і нюанси заб’ємо), а кількість вільних ядер не безкінечна, вони все одно конкурентні. Обчислювані ресурси нізвідки ж не з’являться скільки потоків не додавай.
А тут інші важкі задачі які відслідковують затримку івентлупу через ’isNeeded()’ фактично не будуть виконуватись, поки перша важка задача не завершиться. Тобто тут це черга, просто яка дає івентлупу вертітись і майже весь цп буде йти на активну важку задачу та івентлуп зі всіма там його IO, але ж це корисна робота, щоб прийняти там нові підключення і т.д. Сам оверхед на проміси невеликий.

і треба було щоразу робити циклами пошук по цьому всьому і це займало 200-300 мс CPU обчислень

Ну не знаю, щоб там було на 200-300мс це треба готель на мільйони номерів і капець які заплутані зв’язки. Навряд чи там в імплементації голі цикли з операторами і всякі мікрокеші. Люди люблять функціональщину.

Pavlo Vuiko

Олександр Шпак Oarsman в Self Employed 19.10.2024 22:57

ця інфа зберігалася одним великим JSON для кожного готелю, і треба було щоразу робити циклами пошук по цьому всьому і це займало 200-300 мс CPU обчислень

А потім ці люди забороняють мені колупатися в носі :D

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 10:15

???

Олександр Шпак Oarsman в Self Employed 20.10.2024 10:22

Там за умовами задачі вже напрошуються декілька оптимізацій навіть не розпочинаючи роботу над імплементацією. Але маячню розповідаю саме я ;)

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 10:33

не хочу розкривати NDA, але там по іншому впринципі не вийшло б зробити, дані про кожен готелі були великими, 8-12 мегабайт, клієнт по якійсь причині не хотів давати інше БД окрім Redis

Олександр Шпак Oarsman в Self Employed 20.10.2024 17:08

Мені достатньо тих даних, що ви надали, щоб спрогнозувати всі проблеми, та запропонувати способи їх вирішення. Маю зараз аналогічну проблему з іншою командою розробників, яких я попереджав, що їхня архітектура більше схожа на рахітектуру та не буде працювати. Мені сказали «хлопчик, йди звідси», та нагородили щось за своїм розумінням. Через рік воно успішно прилягло, але слухати мене все одне не стали. :D В кожного є право на обісратися...

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 20:34

мені здається що тут буде досить важко отримати обʼєктивний результати, тому що з різними інструментами можуть працювати різні по кваліфікації і швидкості роботи розробники. Та і тут треба знайти спонсора для такого експеременту)

Sergey Lysak T/T Lead 16.10.2024 20:40

а якщо дивитися глобально — то спонсорами виступає світовий замовник.

той же пхп ніколи не мав серьозної підтримки корпораціями — і масово використовується. чого ж так, хто йому рекламу зробив?

або Node.js — яка корпорація і скільки вклала в його старт і розкрутку?

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 20:57

щодо PHP та Node.js, як на мене, основна відповідь це низький рівень входу який підкупляє новачків. З PHP знаючи базу в програмуванні та HTML вже можна наклепати невеличкий (або величкий) сайтик, там буде жахливий код, але це буде працювати! А це дає цьому розробнику дуже великий заряд дофаміну, типу «ого, я тут лише місяць вчився і вже зробив сайтик, ото я крутий», коротше вклавши набагато менше зусиль в навчання і роботу з PHP, Python, JS, можна отримати набагато більший результат, ніж з C#, Java, C++. В Go впринципі теж досить низький поріг входу.

а якщо дивитися глобально — то спонсорами виступає світовий замовник.

Тут не погоджуюся, тому що важко порівнювати випадки по типу «спочатку мали одне, потім повністю переписали на інше і отримали офігенні результати», тому що наступна ітерація може просто виправляти архітектурні/кодові прорахунки попередньої реалізації, або буде банально більше знань і досвіду в домені, і тут справа буде не у самій мові чи фреймворку. Я погоджуюся, що було б прикольно якби якась багата компанія провела б конкурс де є задача імплементувати якусь апку, і над нею будуть паралельно працювати X команд на X технологіях і в кінці порівняти результати, але на таке ніхто б не дав гроші, і знову ж таки команди було б важко між собою урівняти, бо на якійсь технології люди будуть більш професіональними чи продуктивними, або менш

Andrii Sevastianov 16.10.2024 21:13

Я погоджуюся, що було б прикольно якби якась багата компанія провела б конкурс де є задача імплементувати якусь апку, і над нею будуть паралельно працювати X команд на X технологіях і в кінці порівняти результати

Я бачу скоріше грант, та щоб розробляли студенти... Але в принципі можна порівнювати фунціонал, наприклад, npm, pip, cargo, cabal, ...

Pavlo Vuiko

Sergey Lysak T/T Lead 16.10.2024 21:18

В Go впринципі теж досить низький поріг входу

але так швидко як на пхп — все одно не наклепаєш.

а якщо ми візьмемо пхп навіть 7+ — то Go то просто убога мова. Семантично обрізана.

«спочатку мали одне, потім повністю переписали на інше і отримали офігенні результати»

Це взагалі буде нерелевантним, тому що головне — це досвід у домені. І якщо переписують ті що вже писали цей проєкт — в них купа експертизи більш важливої за мову программування

Я погоджуюся, що було б прикольно якби якась багата компанія провела б конкурс де є задача імплементувати якусь апку

Я бачив змагання між FoxPrошниками та Clipperістами, і 1Сниками та дельфістами.

А так як я профейсійно (тобто за гроші) писав на асемблері, plain C, FoxPro, 1C, Java, C#, PHP, JavaScript/TypeScript — то маю впевнену думку — що у мовах дає переваги у розробці, на яких розмірах і на яких типах задач.

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

Спрощено
якщо на умовному «php» за 1цю часу напишуться 3 проєкти, а на умовному «go» 1 — то слава піде по світу про «php» — і серед замовників і серед програмістів.

Звісно, в історії кожної мови-тулзи є деталі які можно віднести просто до «везіння».
Ну наприклад Node.js повезло що — весь вебюай на JS і енжин V8 не пропієтарний.

А Python повезло що його полюбили науковці і коледжи.

і над нею будуть паралельно працювати X команд на X технологіях і в кінці порівняти результати, але на таке ніхто б не дав гроші,

Так. Я б особисто — не дав. Мені свого досвіду та емпирічної статистики достатньо :)

бо на якійсь технології люди будуть більш професіональними чи продуктивними,

Продукт повинен приносити — гроші.
Чим швидше він буде приносити — тим краще.

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

Ніхто не заважає тому ж Rust ком’юніті повторити такий успіх пхп — заробляйте гроші — і потягнуться і програмісти і замовники.
І Go ком’юніті теж.

Pavlo Vuiko

юнит тест 17.10.2024 09:56

а якщо ми візьмемо пхп навіть 7+ — то Go то просто убога мова. Семантично обрізана.

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

Азаза Заазааз 18.10.2024 11:01

кубернетес и докер написали на го

Може тому що кубернетес і докер писали в гуглі? А у гугла була своя мова написана сішниками, для чуваків які сі не освоїли, але освоїли мережі.

Andrii Sevastianov 16.10.2024 21:11

той же пхп ніколи не мав серьозної підтримки корпораціями — і масово використовується. чого ж так, хто йому рекламу зробив?

Як на мене тут працюють еволюційні закони. Не хто краще, а хто перший захопив нішу. Виникла потреба у екомерсі, PHP виявився кращим за Perl.

Sergey Lysak T/T Lead 16.10.2024 21:26

Так, факторів багато. І тим що я назвав — швидкість розробки — не вийде все пояснити і в мене.

PHP виявився кращим за Perl.

А — чим?

Якщо б з нуля стартовала боротьба між
PHP Java Go
я голову дам — PHP знову переміг би :)
на ньому знову швидше би написались і проєкти і ліби з фреймворками.

а якщо б на пустому полі єкомерс між
Java Go
то Java перемогла б.
Бо більш семантично потужна аніж Go

Andrii Sevastianov 16.10.2024 21:35

А — чим?

Звідки я знаю, а просто констатую факт. Як я пам’ятаю, на початку 2000-х сайти писали на PHP та Perl. Так, був ASP та VB, але... там виникала проблема, що треба Windows хостінг, а в ті часи це було трохи коштовно. Так ось Perl зник, PHP лишилося. Так, в ті часи періодично з’являлася Java, але я лише пам’ятаю, що у порівнянні з PHP вона потребувала у декілька разів потужніше залізо.

Далі вже з ніши PHP намагався його вибити Ruby, але не вийшло.

У Python відгризти долю вийшло трохи краще.

Sergey Lysak T/T Lead 16.10.2024 21:42

на початку 2000-х сайти писали на PHP та Perl.

І на PHP їх було легше=швидше писати, і народ масово побіг з Perl на PHP

періодично з’являлася Java, але я лише пам’ятаю, що у порівнянні з PHP вона потребувала у декілька разів потужніше залізо.

Це теж. Але на ній писати сайти тої пори було ще важче чим на Perl.

з ніши PHP намагався його вибити Ruby, але не вийшло.

Так. Ruby вбили його ж фічі :) Вони виявились класними, до момента появи легасі на Ruby. І вийшло як з Perl — потім фіг той старий код зрозумієш, щоб щось пофіксати, додати, змінити.

У Python відгризти долю вийшло трохи краще.

Та не дуже, як я бачу.
Хоча то моя інф бульбашка — я з ним тільки в тулзах для ШІ зтикався.

Andrii Sevastianov 16.10.2024 22:22

І на PHP їх було легше=швидше писати, і народ масово побіг з Perl на PHP

Ну так, плюс розвивався швидше.

Та не дуже, як я бачу.

У мене більше Python як CDI, AI, ... Але до мене звертаються HR з Django, тому припускаю, що вакансії таки є.

Sergey Lysak T/T Lead 16.10.2024 22:27

Та є звісно.
Знав навіть хлопців, які після пари років на ларавелі спробували джангу, і
та ну його нах той лаварель з пихою! більш ніколи, не повернусь назад!

Andrii Sevastianov 16.10.2024 21:36

Бо більш семантично потужна аніж Go

Це мені незрозуміло. 90% я фікшу помилки, а не пишу код. Тому, як на мене, синтаксична потужність не дуже впливає, а інколи провокує вбік.

Sergey Lysak T/T Lead 16.10.2024 22:31

Це мені незрозуміло

тренд всіх мов програмування з іх розвитком, і Go теж — додавання семантичних можливостей.
З чого б це він такий був, якби не дуже впливав :)

У PHP 8+ як на мене взагалі «здуріли», якусь Scala вирішили зробити, не інкаше :)

Andrii Sevastianov 16.10.2024 23:04

Ну... треба щось додавати? Семантику додавати просто. По факту це просто синтаксичний цукор. Є команда, от вона й додає. Плюс розробникам приємно. Мови, в які не додають нові фічі, вмирають. Плюс менеджери будуть обирати — мови розвивається.

Для мене парадігма це більше обмеження, заборона.

Sergey Lysak T/T Lead 16.10.2024 23:25

Семантику додавати просто

Та ну :)
Ви багато мов програмування створили?

По факту це просто синтаксичний цукор

По якому факту?
Нє, я в курсі що фраза «та це просто синтаксичний цукор» повинна вказувати на велику обізнаність і глибину.

А по факту — бувають зміни syntactic sugar, а бувають — семантичні.

Вам думаю не треба пояснювати, ви в курсі різниці ;)

Плюс розробникам приємно

А чого ж їм приємно робиться?

Мови, в які не додають нові фічі, вмирають

Он як. А чого ж так, що за сила природи така, воно ж просто — «синтаксичний цукор», не впливає.

Для мене парадігма це більше обмеження, заборона.

Ну, люди різні бувають.

Більшість програмістів радіє продуманим покращенням у мовах програмування якими користуються.
Ви з іншої групи, меншості, яким це все заважає.

А Go ком’юніті вимагало дженеріки чомусь. Дивні люди.
До речі — дженеріки це синтаксичний цукор чи семантичний? ;)

Andrii Sevastianov 16.10.2024 23:45

А чого ж їм приємно робиться?

З’явилася нова фіча в мові X, якої немає у мові Y.

Ви з іншої групи, меншості, яким це все заважає.

Я не скажу, що заважає. Наприклад, Haskell дозволяє компілювати застосунок так, щоб використовувалися усі ядра процесора. Але... якщо у нього додати змінні, то цієї можливості вже не буде. Тому парадигма функціонального програмування для мене це відсутність змінних.

До речі — дженеріки це синтаксичний цукор чи семантичний? ;)

50/50. Прибирає копіпасту, але точніше я не можу сказати, бо знайомився з Go до появи дженеріків.

Sergey Lysak T/T Lead 16.10.2024 23:49

З’явилася нова фіча в мові X, якої немає у мові Y.

Це тіпа як у дівчат — у Тані є сумочка, а в мене немає?
Ну, мабуть і такі почуття у програмістів бувають, до інших мов...

Прикольно, чого тільки не почуєш :)

50/50

Ну я так і подумав що ви не знаєте різниці :)

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

Ну може трішки додасть знань та скромністі :)

Andrii Sevastianov 17.10.2024 09:54

Це тіпа як у дівчат — у Тані є сумочка, а в мене немає?

Ну.... якщо подивитися на топік про те, яка мова найкраще, то саме так й виглядає. Насправді у мене написання коду займає 10% часу, решта відлагодження. Тому написати коду трохи більше чи трохи менше не питання. Багато розробки в embedded ведеться на чистому Сі, на ньому реалізований також той же PHP. І якось все робиться...

Ну я так і подумав що ви не знаєте різниці :)

Будь яку річ можна назвати трамваєм, якщо про це домовитися. Для мене просто різниця не бінарна, скоріше в деяких випадках ми можемо просто згенерувати існуючий AST (так, відлагодження), в інших треба генерувати код за вимогою (як були перші шаблони в C++, або Ada). А в деяких типу async/await треба дописувати багато.

Sergey Lysak T/T Lead 17.10.2024 12:18

на ньому реалізований також той же PHP. І якось все робиться...

Це да, люди йолопи — замість того щоб писати на C — пишуть на Go, а то й взагалі — вигадують усякі «Basic» і пишуть на них.

Будь яку річ можна назвати трамваєм, якщо про це домовитися

Я перевірив у чатгпт. Він знає про ці домовленності — що є синтасисом що семантикою. Ви — ні.
Про що й натякнув — ви не розумієтесь про що кажете :)

Сергій Цимбалюк 17.10.2024 11:06

або Node.js — яка корпорація і скільки вклала в його старт і розкрутку?

Гугл, дофіга.

Sergey Lysak T/T Lead 17.10.2024 12:05

Можете поділитися більш конкретною інфою про це дофіга?

Node.js: The documentary
youtu.be/...iUGy0?si=yA9cGxlyAjU_hbpi

В подібні проєкти, після їх успіху багато хто вкладається. Тому що не треба — дофіга вкладатись :)

юнит тест 17.10.2024 12:10

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

Sergey Lysak T/T Lead 17.10.2024 12:15

Осталось уточнить — на другие языки — это на какие?
И почему каждый из этих перечисленых — не труп

А так да, Истину глаголите!

юнит тест 17.10.2024 19:01

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

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 13:23

Що ви городите? Який труп? Більшість бекенд проєктів стартує зараз на Node.js, та і серед існуючих проєктів Node.js займає лідерство. У Node.js є абсолютно все щоб пиляти на ній апки всіх масштабів. От цікаво почути на що її мігрують на вашу думку?

Олександр Шпак Oarsman в Self Employed 20.10.2024 17:10

Більшість бекенд проєктів стартує зараз на Node.js

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

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 20.10.2024 22:31

Оцінюю з того які найчастіше зʼявляються нові проєкти в компаніях у який я працював

Олександр Шпак Oarsman в Self Employed 21.10.2024 00:20

Це, звісно ж, показник... Ви не думали про те, що більшість проектів стартують на ноді, тому що в масі розробники іншого нічого не знають? Це як, опитування серед алкоголіків показало, що споживання алкоголю є життєвою нормою.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 21.10.2024 00:31

так компанії у яких я працював спеціалізуються не лише на Node.js, було і багато спеціалістів на Java, Go, C#. Я спілкувався з архітектами які власне беруть участь у пре-сейлах, і якраз на більшість проєктів Node.js найкраще підходить за рахунок тайм-ту-маркету і інших її плюсів

Олександр Шпак Oarsman в Self Employed 21.10.2024 02:00

Вам просто дешевше так писати. А в компанії, де є купа джавістів, проекти будуть писати на ... Java

Pavlo Vuiko

Vic Programmer 17.10.2024 23:51

пхп ніколи не мав серьозної підтримки корпораціями

Ага, а перший скрипт написаний на PHP виглядав отак
  Hey, you are using Netscape!<p> 
Та насправді дуже довго PHP підтримував Yahoo!
Тим не менше : PHP — як і Apache, Linux та MySQL. Це свого роду феномен інтеренету. Хакерска поробка, м’яко кажучи дуже сильно не ідеальна, але була зроблена в потібний час коли стала вирішувати нагальну практичну задачу. Отримала велику аудиторію і стала потупово еволюціонувати, від мало не лайна до зрілого продукту.
В корпоративному світі — аналоги : MS DOS, Windows 95, PhotoShop, BASIC і т.д.

Andrii Sevastianov 16.10.2024 21:09

Я натякав на рандомізоване сліпе подвійне дослідження.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 21:10

ааа, не зрозумів вас ордазу, але все таки, як його провести, щоб результати були ± обʼєктивними, тобто щоб мали хоч якийсь сенс?

Vic Programmer 17.10.2024 23:43

Це як виявляється робили, при чому науковці. Першим спонсором був — Пентагон. А числені досліди які робили інші компанії на різних хакатонах та хешкодах, тільки підтвердили висновки з попередніх дослідів.

Pavlo Vuiko

Vic Programmer 17.10.2024 23:40

Теоретично це дати бюджет на розробку одного завдання, та вести її за допомогою різних інструментів. Та порівняти витрати.
А на практиці те що ти знаєш, або маєш мотивацію вивчити.

На практиці і справді як виявилось — що змагання не проміж технологіями, а проміж ІТ командами. Нещодавно справді дивився досліди, де науково підтверджено, що ІТ команди та навіть окремі ІТ-шники відрізняються один від одного по результатах, подекуди в 20 разів.
Я завжди думав що це НПЛ-шна херня. Інша справа — як конкретно досягається ці результати, тобто чому так ? Як і у випадку з тими же шахами — тренування та теоритичні знання, 80% успіху.

Віталій Мартиник Senior Software Engineer в United Software 16.10.2024 10:18

Асемблер топ

Slavik Savko 16.10.2024 10:54

Для PIC контролерів взагалі топ.

Віталій Мартиник

Vic Programmer 16.10.2024 11:09

Тільки якщо вміти його готувати. Сучасні компілятори генерують асемблерний код, значно оптимальніший навіть за програмістів середньої кваліфікації. Той же memcpy чи memcmp — вже написати під конкретний тип процесора, це вже чемпіонат серед топ професіоналів. А компілятори ще вміють підібрати під контекст, конкретний метод (не завжди добре, та часто краще за людину).
Про трудомісткість створення типових CRUD, важко навіть зробити оцінку.

Віталій Мартиник

Sierżant Kwiatkowski Software Engineer в TS Imagine 15.10.2024 22:49

який молоток краще щоб забивати цвяхи

Сергій Цимбалюк 15.10.2024 22:53

Тут питання скоріше: якого кольору молоток :)

Sierżant Kwiatkowski

Бартоломео Россі 15.10.2024 23:35

А чи був взагалі молоток?

Slavik Savko 16.10.2024 11:03

Бажано залізний і з ручкою. Виробник не сильно важливий. Головне щоб завжди були доступні у продажу ручки для цих молотків.
Вагу треба підбирати оптимальну під конкретних вид та розмір цвяхів. Домашньому майстру краще тримати у господарстві принайні 3 різних види молотків — маленький молоточок щоб було зручно забивати невеликі цвяхи у важкодоступних місцях, середній як універсальний інструмент на більшість випадків життя і великий для складних випадків.
Сам ще пробував забивати цвяхи пасатіжами та цеглиною. Не дуже зручно, не рекомендую. Але народ подекуди юзає якщо діватись нікуди.
Ще звісно існують професійні пневматичні і навіть піротехнічні засоби забивання цвяхів. Але їх краще використовувати у великих проєктах де потрібно забивати дуже багато цвяхів бо вони значно дорожчі у обслуговуванні та потребують дуже специфічних навичок

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

Sierżant Kwiatkowski

Vic Programmer 16.10.2024 12:44

Є купа роботи, де треба дерев’яні молотки — киянки, або пластикові, обрезинені і т.д. і залізо рішуче не підходить :) Особливо хитромудрі молотки та і взагалі інструмент при виготовленні музичних інструментів.

Oleksandr Velychko IT-technologies 15.10.2024 22:20

відкриваю linkedin і роблю пошук вакансій Worldwide по кожній мові окремо і оцінюю результати пошуку: Java, Python, Rust, Go та все інше
Ринок диктує умови

Vic Programmer 16.10.2024 10:05

Ну тут і Генрі Форд теж висловився

If I had asked people what they wanted, they would have said faster horses.
та
Any color the customer wants, as long as it’s black.

Як відомо велике американске вміння — це створбювати потреби (тобто і ринок), а не просто їх задовільняти.

Oleksandr Velychko

Mr M 15.10.2024 22:12

Хочеш працювати на великі компанії, банки, державні структури (при цьому влізти по коліно в легасі, підтримувати те, що написано в 19xx, бути маленьким гвинтиком в великій корпоративній машині), тоді тобі в:
— Java
— C# (.NET)

Хочеш працювати на стартапи, пити смузі і згодом лізти у фронтенд щоб стати фулл-стак девелопером (при цьому бути 201 кандидатом на вакансію), тоді тобі в:
— JS (NodeJS)

Любиш подьоргати слоника за хоботок, тоді тобі в:
— PHP

Можна ще вчити Python, але для бекенду він дуже нішевий і легко роботи ти не знайдеш з ним (саме як Python Backend Engineer). І ще є Go. Якщо гугЕл його не «прикриє» як деякі свої інші проекти, то це також нішевий, але варіант.

Сергій Цимбалюк 15.10.2024 23:08

але для бекенду він дуже нішевий

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

Mr M

Mr M 16.10.2024 15:51

Та ну, не сказав би. Якщо треба щось написати швидко скоріше візьмуть ноду. На ній швидше можна підняти простенький сервіс + вона більше для цього підходить. Для екомерсу більше беруть пхп і правильно роблять. Пайтон якщо і пхають кудись де треба швидко то хіба що через його універсальність та на щось з упором на дані.

Oleg Skalozub Golang dev 16.10.2024 17:56

екомерсу більше беруть пхп і правильно роблять

чому?

Mr M

Sergey Lysak T/T Lead 16.10.2024 20:44

тому що экомерс це було практичне перше що почали писати всі, на чому було, коли веб став поширеним.
і виявилось — на php його найшвидше писати.

Зараз можна з такою ж швидкістю і на пітоні, і на ноді, але напрацювань на php дуже багато, — щоб «наздогнати»

Taras Terletsky Python Backend Engineer в SoftServe 18.10.2024 13:51

Можна ще вчити Python, але для бекенду він дуже нішевий

Найсмішніший коментар тижня.
Відомі світові продукти як Instagram, Venmo, Spotify, Reddit, Netflix та купу Cybersec-компаній покинули чат.

Mr M

Anatolii Olesh Python developer 20.10.2024 23:28

ще кажуть такі гіганти як Djinni ну і Threads також не проти удава

Trip Trip 20.10.2024 23:42

Netflix

Там же Scala для всього хайлоад чи я щось плутаю?

Pavlo Vuiko Senior Node.js Engineer в EPAM 21.10.2024 00:17

Python дійсно нішевий) зі слів мого колеги Python інженера, ця мова програмування почала займати нішу PHP, тобто коли треба щось зробити дуже швидко і по шаблону, це якщо говорити про веб-розробку, також Python дуже погано скейлиться. Ви дійсно вважаєте, що переважна кількість коду вказаних компаній написана на Python?

Taras Terletsky Python Backend Engineer в SoftServe 21.10.2024 01:37

Python дійсно нішевий) зі слів мого колеги Python інженера, ця мова програмування почала займати нішу PHP,

Повірте, це не більше, чим ваша фантазія. А вашому колезі треба трішки «погуглити» англомовний гугл і почитати, в яких продуктах використовується пайтон в тому чи іншому виді (де весь бекенд на пайтоні, де частково, а де лише якийсь ML).

Ви дійсно вважаєте, що переважна кількість коду вказаних компаній написана на Python?

Мені не треба вважати, ця інформація доступна публічно.
Наприклад, Reddit написаний на Django:
1) support.reddithelp.com/...What-is-Reddit-written-in
2) www.aaronsw.com/weblog/rewritingreddit

Instagram — Python: instagram-engineering.com/...rict-modules-c0bb9245c834

Instagram Server is a several-million-line Python monolith, and it moves quickly: hundreds of commits each day, deployed to production every few minutes.

І так далі. Ви собі навіть не уявляєте, скільки бекенд-продуктів в тому ж Cisco (та будь яких інших мережевих та сайберсек компаніях) написані на Python та приносять компанії мільярди $ ревеню. Навіть той же YouTube після купівлі Гуглом переписали на пайтон (хоча зараз там всюди просувають і переписують де можуть на Go).

Pavlo Vuiko

Dmitry 15.10.2024 20:45

которую вы лучше всего знаете.
Хорошие backendы можно писать и на java и на js, на golang и на rust
и даже ruby и python выступят отлично ... ключевой критерий — компетентности команды

Олександр Шпак Oarsman в Self Employed 15.10.2024 19:59

Краща мова та, яку ти зможеш найшвидше вивчити та почати набиратися практичного досвіду. На вакансії та зарплатну вилку дивитися не треба, це вже потім. Back-end це не тільки про мову програмування, паттерни, фреймворки, це ще й про інфраструктуру, оточення, процеси, бази даних, сервіси, тощо. Останнє буде універсальним для всіх мов програмування.

Просто Анон 15.10.2024 19:44

Все залежить від того хто питає.
Починай з Pascal ABС

Qaraimam 15.10.2024 18:27

Яка мова програмування найкраща для Back-end?

Ну конечно же Go. Что за вопрос вообще, ответ на который всем очевиден, ты не троль ли случайно?

Владислав Соколенко Senior PHP Developer 15.10.2024 17:06

Цікаве питання. Це як ніби спочатку обрати викрутку, шуруповерт або молоток, навчитись ним працювати, а потім думати чи подобається і що з цим можна зробити. Ну і обирати по пораді і легкості навчання. ))

Blitz Senior .net Developer / Architect 15.10.2024 15:43

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

Ярослав Характерник Golang Developer в DocHQ 15.10.2024 15:42

Go та Rust.

Для швидкої розробки — це Go, для високої швидкодії — Rust.

Вам також потрібно враховувати сферу, в якій ви хочете розвиватися.

Дуже багато банків зараз обирають Go — знаю про це, бо досліджую вакансії з Go, щоб сформувати список компаній, де використовується Go.
Багато технологічних гігантів обирають Rust для своїх високонавантажених сервісів, як-от Cloudflare та Discord. Знаю про це, бо також формую список компаній, де використовується Rust.

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 15:56

На жаль це не ліквідний вибір для бекенду у 90+% випадків. Дуже дорогі та рідкісні розробники, сирувата екосистема, повільний час компіляції, в основному бідна документація бібліотек, простіше розбиратися через Source Code. Rust гарний для якогось low latancy та дуже хайлоадного беку, а таке рідко потрібно, зазвичай важливіше швидше вийти в прод і потратити менше грошей, ну і щоб працювало ± оптимально, тут з цим умовний Node.js справиться набагато краще

на жаль вірогідність знайти роботу на Rust саме на бекенд не дуже висока, бо у більшості випадків це не має сенсу. Кажу з власного досвіду

Vic Programmer 15.10.2024 16:31

Це далеко не єдині проблеми обох технологій власне тому із вакансіями не дуже і TIOBE та інщі індеси показують позиції нижче TOP-5. Навіть Visual Basic та Delphi — по суті «мертві» технологіх можуть бути вище. Прямий конкурент обох — D взагалі на 40-й позиції.
Треба дивитись на маркетингові можливості Mozilla Foundation з продвиження, та взагалі на команію яка продвигає певну технологію. З Go — тут усе ясно, це Google тобто переспективи доволі вискокі, а лімітації можуть і пофіксити зокрема додати ексепшени, та повноцінні потоки наприклад. (ні у Rust, не у D таких непотрібних лімітацій нема).
Щодо спеціфики українького ринку — теж тут не в програмістах, а в бізнесі справа. Чи піде на цей технологічний стек бізнес ? Відповідно і будуть вакансії. Галерний бізнес дуже любить технології з невеликим порогом входу типу frontend або mobile, бо відносно легко було шукати клієнтів — аля фріланс, їх повний інтренет кому треба морда сайта якась або мобільна апка для якогось online бізнесу. При цьому не треба довгого порогоу входу з мінімум року стажування джуніора, як у : С#, Java чи С++ на ті же бекенд чи Embedded. Під такі технології, це складні для отримання клієнти. Ті же авто концерни чи інвеститаціні банки дуже рідко підписують контракти із невеликими фірмами, а там діють гігінти з Індії типу TATA чи Acenture і взагалі концерни віддають перевагу побудові власних ІТ команд, передаючи на аутсорс не так багато — бо ситуація з Nokia та Apple дуже багато навчила з цього плану бізнес.
Головна маржинальність аусторса чи аутстафа як відомо з мідлів. Ну а король усіх шхун та шлюпок — безумвоно LAMP — PHP, стек.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 16:38

як на мене Go досить популярний, він знайшов свою нішу на бекенді, є свої приколи, але вони в основному субʼєктивні

Vic

Сергій Цимбалюк 15.10.2024 20:12

Дядьку прокинтеся, зараз не 2010-й рік.

Vic

Vic Programmer 15.10.2024 22:03

А що так сильно змінилось з 2010 крім — прогрессу відеокарт та GPU та усього, що з цим пов’язано як то крипта та AI і прогрессу облачних технологій, як особливо контейнерізації : Docker, Kubernetes (і тут справді Go lang)? Go lang тоді вже був, рік — ми в Native відділку не те дивились із дати виходу. Там же самі Роб Пайк та Кен Томпсон — розібрались, зрощуміли — що не то пальто. Трое навіть в Google влаштувались з тих хто дивився. Реально стало впроваджуватись по троху він став після Java 9, та судьбової тяжби з Oracle.
А якщо взяти попередні роки від 1980 до 2010, а особливо проміжок від 1995 до 2007, то там мало не кожен рік мінялось мало не усе. Почав вчити якусь Java ME наприклад під : Motorola, Simens та Nokia. Через рік — воно вже нікому не треба, вже Symbian та MeGoo. Через пів року — iPhone та Android. І наймають на роботу — вже люди молодші за тебе, коли тобі самому 25 і токсять, намагаються будь що завалити на співбесіді. Потім я таке читав навіть у метрів, як то Джоел Спольскі — тільки про «компанії зі словом Java в назві», і про це книга Мура : «В стередіні Торнадо» обьязкова в купі MBA програм.
2. На сьогодні — прогресс очевидно в Китаї, доки ще на частково імпортованих технологіях.

Сергій Цимбалюк 15.10.2024 22:51

Зараз 2024-й рік. Уже ніхто не знає, що таке Symbian, не треба тут писати полотна.
Кому ви що хочете довести? Можна в трьох словах?

Vic

Сергій Цимбалюк 15.10.2024 16:47

Дуже багато банків зараз обирають Go

«Багато» це хто саме?

Ярослав Характерник Golang Developer в DocHQ 15.10.2024 16:57

Є фільтр FinTech:

Й ще трохи:

Сергій Цимбалюк 15.10.2024 20:15

Не густо. Комбінації Python/Go, Java/Go говорять самі за себе.

Є фільтр FinTech

Сайтом неможливо користуватись, якщо чесно (відкривав з мобіли).

Ярослав Характерник Golang Developer в DocHQ 15.10.2024 20:48

Для мене ці комбінації означають розробку нового функціоналу на Go

У сайту поки відсутня мобільна версія, але коли буде більше користувачів, то виділю бюджет на її розробку

Vic Programmer 15.10.2024 21:47

У вас в переліку — мінімальний мід+ з 4+ роки досвіду. В переліку principal позиції, які шанси у джуніора без досвіду влаштуватись на таке ? OP задавав питання початківця.

Сергій Цимбалюк 15.10.2024 16:55

Rust

Ми все ще про веб говоримо?
Навіщо агітувати за технологію не пояснюючи при цьому, для чого вона застосовується?
Така агітація тільки шкодить, показуючи неадекватність спільноти.

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 18:50

Ви так говорите, ніби бекенд на Rust писати не можна, цілком собі можна, але зазвичай більше профіту буде від Node.js, Go, C#, Java

Vic Programmer 15.10.2024 22:14

Навіщо агітувати за технологію не пояснюючи при цьому, для чого вона застосовується?

Пане, вони усі застосовуться просто для одного і того самого — в 85% там звичайнісенький CRUD з REST API. Може колись і десь — буде якась кастомна логіка, наприклад згенерувати PDF якись з описом ліків, чи інвойсом. Знайти наіближчі магазини і інтегруватись із картами і т.д. і т.п.

Сергій Цимбалюк 15.10.2024 22:44

Rust для CRUD?

Vic

Vic Programmer 16.10.2024 09:45

Ніби щось нове ?
Axum medium.com/...ng-axum-sqlx-d7e50b3cd130
Rocket github.com/...cket-sample/tree/main/src
На Node дуже схоже, звісно від скажімо Spring Boot із Hibernate — треба і часу в три рази більше для написання і виграш в перформансі сумнівний, буде сильно залежати від кваліфікацї програміста. В усіх бекендах головним ботлнеком фактично в 90% випадків є база данних (і NoSQL не панация, ще гірше буває ніж SQL особливо коли готувати його не вміють).
А от коли треба буде генерувати PDF — то в Java ви підете і візьмете Apache PDFBox з прикладами. А на Rust будете рити інтернет за піонерскими поробками, потім зробите на PoDoFo наприклад на С++, та прилінкуєте через С-шне API.
У ряді випідків виграш по пам’яті може бути і дуже суттєвим, знову таки усе сильно буде залежати від кваліфікації програміста. А не усякому бізнесу треба такі експеременти, та зоопарки технологій.

Serhii 16.10.2024 12:38

Rust офігенний для CRUD
— мінімум їботні з борроу чекером і лайфтаймами
— нормальна серіалізація, на відміну від плюсів
— задовільна робота з бд (я використовував sqlx)

Девелопер експірієнс вище Node.Js, але нижче с#
Мікросекундний час відповіді на прості запити (на три порядка швидше шарпа)

www.meme-arsenal.com/...a890947d502a990bbe682.jpg

Dmitriy Mozgovoy JavaScript / NodeJS Developer 15.10.2024 17:15

Go та Rust.

Сергей Макаров 15.10.2024 15:40

C#

Ilona Stepanyshyna Community Manager в ErgoServ 15.10.2024 15:02

Ruby ;)

Ops 15.10.2024 14:45

Rust

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 15:04

На жаль це не ліквідний вибір для бекенду у 90+% випадків. Дуже дорогі та рідкісні розробники, сирувата екосистема, повільний час компіляції, в основному бідна документація бібліотек, простіше розбиратися через Source Code. Rust гарний для якогось low latancy та дуже хайлоадного беку, а таке рідко потрібно, зазвичай важливіше швидше вийти в прод і потратити менше грошей, ну і щоб працювало ± оптимально, тут з цим умовний Node.js справиться набагато краще

Ops

Азаза Заазааз 15.10.2024 12:43

будь-яку, прям яку хочеш, а працювати все одно будеш з жабаскріптом.

Andrii Sevastianov 15.10.2024 12:30

Найкраща, не дуже важка, щоб легко знайти роботу... Haskell, PHP, Java?

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 14:03

З Haskell можна знайти роботу, ви серйозно?

Азаза Заазааз 15.10.2024 14:34

Угу, але з індусами, бо чогось саме індійські проекти люблять хаскель. Це якась регіональна особливість, як з OCaml у франції.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 14:42

Ага ну звучить не дуже) як на мене, Haskell це чисто мова для пет проєктів, яку всього пару ентузіастів використовують і дуже голосно хвалять один одного оплесками) ще й її чиста функіональність послуги їй не робить

Vic Programmer 15.10.2024 14:47

У нас просто майже нема чого на ньому писати. Такого бізнесу в країні майже немає. Хоча підозрюю десь там у Space X або NASA, або якомусь Dou Jones — може бути і must have.

Pavlo Vuiko

Andrii Sevastianov 15.10.2024 14:53

Спільноти розробників немає, той же backed писати можна.

Vic

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 14:55

Так а що писати на цій мові окрім пет проєктів? Мова яка максимально неефективно використовує пам’ять через постійне копіювання просто заради ідіотської ідеї. Мова (як і багато функціональних мов) яка вимагає танці з бубном у вигляді монад, щоб просто щось дістати із зовнішнього світу, типу в БД сходити. Ще оця «послідовність обчислень не має значення», а коли треба, щоб мала, то он твій бубен) + як на мене дуже важко читається

Vic

Andrii Sevastianov 15.10.2024 16:03

Ну... Завдяки типізації та оптимізації, швидкість часто порівнювальна з C++. Не кажучи про можливість автоматичного розпаралелюванню коду. А звідки там копіювання, якщо немає змінних? Теоретично навіть операційну систему можна написати, є приклад.

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

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 16:16

А звідки там копіювання, якщо немає змінних?

У сенсі? В Haskell є змінні, мають дані ж десь зберігатися.

Завдяки типізації та оптимізації, швидкість часто порівнювальна з C++

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

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

Щодо автоматичного розпаралелювання, я б не сказав, що це кіллер фіча, в Go та Rust теж так можна.

Теоретично навіть операційну систему можна написати, є приклад

От проблема Haskell в тому, що майже все там теоретично, зазвичай ніхто в прод тягнути його не хоче і цікавий він лише ентузіастам, на жаль чи на щастя

Монади це досить потужна концепція, яка робить код простіше

Ну не знаю) як на мене код простіший коли ти просто береш і пишеш якусь логіку, без загортання в хитрі конструкції, для того щоб воно просто запрацювало. Але якщо говорити про монади по типу Result та Option в Rust, то це дійсно класна штука

Andrii Sevastianov 16.10.2024 17:32

В Haskell є змінні

В Haskell немає змінних. Тому в Haskell немає циклів, бо якщо викрестили нескінченні цикли, то умова завжди залежить від змінних.

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

Ну... state монада, reader монада... Взагалі правила оптимізації досить прості, у більшості випадків у компілятора достатньо інформації оптимізувати та модифікувати по місту. Haskell дуже конкурентоспроможний порівняно з C, і за деякими бенчмарками він швидший. Але так, треба розуміти як це працює під капотом. Посилання .

в Go та Rust теж так можна.

Не можна, бо сайд-ефекти. Кожен раз, коли функція отримує два аргументи, кожен з них ми можемо обчислювати паралельно. Але у випадку Go це не так, нам треба паралелити код вручну. Rust кращий кандидат, але я не знаю, як там написати однопоточний код, який би сам компілятор розбив та виконував у багатьох потоках.

зазвичай ніхто в прод тягнути його не хоче

Не хочу, або сильно тупий, щоб розібратися, або... Це людський фактор, який дуже суб’єтивний. У цілому в принципі у фінтекі Haskell є, але в Україні спілки немає, то ніхто й не шукає.

Ну не знаю) як на мене код простіший коли ти просто береш і пишеш якусь логіку, без загортання в хитрі конструкції, для того щоб воно просто запрацювало.

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

Але якщо говорити про монади по типу Result та Option в Rust, то це дійсно класна штука

Це апликативний функтор, найпростіший приклад монади.

Pavlo Vuiko

Vic Programmer 15.10.2024 16:18

Там зараз прийдуть математики, які різною статистикою займаються — та бізнес рулами і подібним та стануть нам — програмістам доводити з такими самими аргументами про беззаперечні переваги функциональщіни в тій чи іншій формі від : Haskel до Scala. І що наші улюблені мови як то : C, C++, JavaScript, Java, C# - це мазохізм і Стокгольмський синдром. А от Matlab, Haskel, OCaml, R — це саме воно, при чому із до мопдобою може дійти дискусія, що краще.
Приблизний консенсус лише з Python з одного боку, та Perl з іншого.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 16:24

як на мене, якщо говорити про чисту функціональщину в сфері саме бекенд розробки, то це звʼязування себе кайданами просто заради ідеї, а не якогось реального профіту

Vic

Andrii Sevastianov 16.10.2024 19:06

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

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 19:27

Чесно, я не пробував, я зі сторони бачу, що це якась дикуха, перевчатися писати код по іншому, танці з бубном для того, щоб зробити елементарні речі, заради сумнівного виграшу і оплесків адептів функіональщини) Я надаю перевагу мульти-парадигменному підходу, який дозволяє використовувати краще зі всіх світів

Andrii Sevastianov 16.10.2024 20:33

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

Ну... все життя писав код з goto, навіщо мені перевчатися? Все життя писав на Pascal, навіщо мені ООП? Навіщо мені лямбди, коли я писав без них?

Так, є підхід, що поки мені цього не треба, я не використовую. А коли нікуди не дітися, то треба розібратися. Але моя мотивація імперативщика була у тому, що мені було просто цікаво. А коли розібрався, то зрозумів, що 20 років досвіду у розробці були марним витрачанням часу, бо є монади.

Я надаю перевагу мульти-парадигменному підходу, який дозволяє використовувати краще зі всіх світів

Проблема у тому, що не дозволяє. Парадигма це обмеження, яке ти добровільно береш на себе щоб досягнути певних цілей. Наприклад, відмовляєшся від goto щоб отримати структурний код. Або коли у тебе немає змінних, то ти пишеш однопоточний код, а компілятор робить його багатопоточним. Або ти використовуєш ADT та виключно структурно рекурсивні виклики, ти автоматично отримуєш доказ того, то функція виконається за обмежений час та не крешнеться.

Мультипарадигма це повія, яка дає всім.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 20:41

Ну... все життя писав код з goto, навіщо мені перевчатися? Все життя писав на Pascal, навіщо мені ООП? Навіщо мені лямбди, коли я писав без них?

Ця цитата гарно б підходила при порівнянні чогось значно гіршого і чогось значно кращого. Особисто для мене функціональщина це точно не той підхід який на голову вище за ту ж мульти-парадигму

Парадигма це обмеження, яке ти добровільно береш на себе щоб досягнути певних цілей

Так ось, коли ми замикаємося на одній парадигмі, то обмежень білше, ніж коли ми використоваєм мульти-парадигму, таким чином перекриваючи мінуси кожної парадигми плюсами з іншої

Або ти використовуєш ADT та виключно структурно рекурсивні виклики, ти автоматично отримуєш доказ того, то функція виконається за обмежений час та не крешнеться.

Щось мені підказує, що цього важко досягти якщо у нас є в цій функції взаємодія з зовнішнім світом

Мультипарадигма це повія, яка дає всім.

І виходять від неї дуже задоволеними 😂😂😂

Азаза Заазааз 15.10.2024 21:15

Наші математики використовують класичний набір C, FORTRAN, зараз уже Python. Чого, бо суперкомп’ютер з інституту кібернетики. Matlab і R їм користуються інженери, ну власне це і є продукти для розробки, моделювання, веріфікації. Haskel і OCaml це чистокровні академічні мови, які затягнули в прод, невідомо нащо, але затянули, вони якось існують, але ні туди, ні сюди. Але якщо з них обирати, я б обрав OCaml.

Vic

Andrii Sevastianov 16.10.2024 19:07

Це обчислювальна математика більше. OCalm скоріше потрібен у зв’язку з CoQ, що дає верифікацію.

Andriy andriy 15.10.2024 15:21

десь там у Space X або NASA, або якомусь Dou Jones — може бути і must have.

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

Vic

Vic Programmer 15.10.2024 16:10

Так на современный Java 8+ код посмотрите — stream monade погоняет. Замечу некороторые инсайты проскакивают, что там кроме классики есть фрагменты которые тоже надо сапортить.

Andriy andriy

Andrii Sevastianov 15.10.2024 14:50

Ну... Якщо подивитися на cabal, то там є майже усе дуже високої якості. А спільнота в сотню раз менше за Python. Тому писати можна, але... нікому.

Pavlo Vuiko

Азаза Заазааз 15.10.2024 14:58

Її не треба просто в прод тягнути, наукова дослідницька мова, то хай і залишається в науці. Хочеш функціональщини в проді ~~візьми джаваскріпт~~ скалу, кложуре чи шось таке.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 15:08

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

Andrii Sevastianov 15.10.2024 16:05

Науково дослідницькі це Agda, Idris. Haskell як на мене дуже практичний, плюс майже усе потрібне є у cabal

Andrii Sevastianov 15.10.2024 14:48

Найкраща Haskell, не дуже важка PHP, роботу зайти — Java. Це просто взаємовиключні вимоги.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 15:14

тут я не погоджуся майже з жодним вашим пунктом, про Haskell написав вище. Java — роботу на ній не знайдеш, якщо ти джун, дуже велика конкуренція, недавно колега у мене був джун, то йому простіше вийшло знайти роботу на Rust, ніж на Java. Щодо PHP, він дійсно не важкий, але я щось сумніваюся, що вийде знайти роботу яка не клепання сайтиків з CMS-ками, чи якесь легасі, можливо помиляюся

Karina Kosenko PHP developer в IT Craft 15.10.2024 15:21

На PHP досі стартують нові проекти (і я не про сайти на CMS зараз).

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 15:26

і як сучасний PHP себе почуває? Бачив він став досить схожим на Typescript по фічах і самому коді.
Так і залишається, що все робиться лише синхронно в межах обробки одного запиту? Маю на увазі, чи можна, наприклад, одночасно зробити кілька запитів у мережу чи БД і почекати поки вони всі паралельно відпрацюють?
А його деплоять зараз якось по новому, типу через Docker? Чи так само код інтерпретує Apache Web Server?

Andrii Sereda PHP developer в Digicode 15.10.2024 15:49

Додали трохи перформансу і синтаксичного цукру. Щодо асинхроннсті все як було (тобто її нема) хіба що через костилі типу ReactPHP. Деплой можна зробити як душа забажає Docker і тд.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 15:50

зрозуміло, дякую за відповідь)

Andrii Sereda

Melnyczenko Mel 15.10.2024 16:14

Додали типізацію і купу синтаксичного цукру, стало прям дуже вдобно. Порівняно з версіями а-ля 2017ий рік — перфоманс ЗНАЧНО виріс

Кілька запитів в базу — хз, не вивчав питання, але кілька паралельних HTTP запитів — можна, юзав буквально нещодавно

Деплой через Docker — можна і через docker, можна і через Kubernates. В цілому, в нормальних компаніях будують CI/CD який тільки забажаєш, з автотестами та автодеплоєм. Часи мануального git pull на проді — уже минули

Apache2 уже своє майже віджив, в основному юзається nginx + php-fpm

Pavlo Vuiko

Oleg Skalozub Golang dev 15.10.2024 16:47

Додали типізацію і купу синтаксичного цукру

Обережно з цукром, від нього діабет буває

Кілька запитів в базу — хз, не вивчав питання, але кілька паралельних HTTP запитів — можна, юзав буквально нещодавно

скільки воркерів запустите стільки паралельніх запитів і можна робити, це ж скрипт

Владислав Соколенко Senior PHP Developer 15.10.2024 16:53

Та можна ще форками погратись і зібрати відповіді. Але тут обережно треба гратись.

Роман 16.10.2024 03:11

форки мертва тема та й не працювали ніколи в веб-контекстах, тільки в cli

Владислав Соколенко

Роман 16.10.2024 03:09

Мова саме про асинхронну обробку в межах 1-го скрипта/реквесту, а не про воркери.

Асинхронна обробка на системних викликах / всяких мережевих штуках в PHP доступна дуже давно, з тих пір як з’явився stream_select/socket_select, що може десь 4.3.

З якогось моменту там з’явився ще й nonblocking режим, що дозволяє скрипту ще й щось робити поки чекаєте реквестів.

тож http реквести так, досить легко можна так запускати паралельно, рішень купа стандартних, в тому ж guzzle приклади в доках, воно на всяких там пулах/promiseах.

(ReactPHP тут треба майже виключно щоб красиво реалізувати момент «робити щось ще», якщо ви тупо будете чекати поки всі реквести не виконаються все одно то воно не треба).

Доводилось роки 4 тому на диво таким сумніваючимся щодо асинхронних можливостей пхп понаписати воркер систему що лонг-поллила з 1-го процессу дуже велику кількість AWS SQS черг та менеджила створення воркерів з них з 1-го процессу

Моментами «робити щось ще поки лонг-политься купа черг процес» тут було
— підтримка пулу лонг-поллів
— створення воркерів
— обробка відпрацювання воркерів — асинхронний delete messageів відпрацьованих воркерів, вивід stdout/stderr від відпрацювавших дочірніх процесів
— обробка gracefull termination по отриманню SIGINT/SIGTERM через pcntl_async_signals

Так, результат на виході на диво працював супер-надійно та не травив пам’ять.https://dou.ua/lenta/news/hetmantsev-taxes-and-bad-decisions/?from=sbcomments

Звісно треба розуміти що оте саме «робити щось ще поки відпрацьовуються реквести» в пхп повністю однопоточно буде, тобто не дістане навіть до тредів python з GIL.

З реквестами в базу все гірше, Doctrine суто однопоточна.
Є рішення для того щоб raw sql поганяти багатопоточно, та юз-кейсів не зустрічав щоб це треба було на беку ліпити, замість наприклад фронту сходити в декілька ендпоінтів паралельно.

Andrii Sevastianov 15.10.2024 16:07

Ну ок, на чому простіше знайти роботу окреме питання. Я це питання не моніторю.

А про Haskell я зрозумів, що ви його не знаєте. Так, він потребує більше зусиль для розуміння потужних абстракцій.

Pavlo Vuiko

Serge Loboda Senior Software Developer в Access Softek, Inc. 15.10.2024 12:09

Англійська.

юнит тест 15.10.2024 14:52

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

Serge Loboda

Qaraimam 15.10.2024 18:31

Зачем, могут працювать с ухилянтами себе спокойно. Там условия демократичнее во всех отношениях, и никакого B2-C1 не нужно.

Karina Kosenko PHP developer в IT Craft 15.10.2024 12:04

Головне, PHP не беріть, бо він скоро помре xD

Serhii Kosyi Software developer в eBogholderen.dk and Revisor1.dk 15.10.2024 13:07

Так мені радили на початку 2000-х

Sergey Grigoryev 15.10.2024 14:12

Точно, його вже більше 20 років як вбили просунуті ColdFusion & ASP.Net

Ivan Havryshko Senior Software Engineer в TriNet 15.10.2024 23:25

ASP.Net

до речі, C# і Asp.Net Core — набагато краща для бекенду ніж PHP.
Щоб помер PHP — треба просто переписати вордпрес і всі плагіни на C# :)

Sergey Grigoryev

Олександр Шпак Oarsman в Self Employed 15.10.2024 23:54

треба просто переписати вордпрес і всі плагіни на C# :)

Просто задайте запитання, чому досі це ніхто не зробив ;)

Ivan Havryshko Senior Software Engineer в TriNet 17.10.2024 18:00

тому що це був жарт :)

Олександр Шпак Oarsman в Self Employed 17.10.2024 18:09

В кожному жарті є трохи жартів... ;)

Slavik Savko 17.10.2024 13:00

Щоб помер PHP — треба просто переписати вордпрес і всі плагіни на C# :)

So I want to get it solved and I will be able to get it solved. And I’d like to do it before I get to the White House after I’m president-elect.

Alex Tcy 16.10.2024 13:14

Ох єй, того похапе ще моїм онукам вистачить, все ніяк не помре ))

no name three 18.10.2024 15:26

Почав писати на Ruby 10 років тому, вже тоді помирав, але шось так і не помер

Evgeniy Dubskiy Magento Developer в Eltrino 19.10.2024 20:09

це типу жарт з 90х? він тільки стає кращим з версії в версію, помре він тільки тоді коли зникне «інтернет» у всьому світі)))

Yurii Bratko PHP Developer в AUTODOC 21.10.2024 10:51

Підтримую)

Seven Berg 01.11.2024 16:28

Сколько проектов сейчас на пыхе начинают делать? Magento уже все?

Witness 01.11.2024 17:19

остается одной из ведущих е-каммерс платформ. называется Adobe Commerce

Seven Berg

Seven Berg 01.11.2024 17:27

Это новый проект его в этом году начали?

Witness

Witness 01.11.2024 17:29

Адоби купил магенту несколько лет назад, переименовал и теперь продает и развивает под своим брендом. Ответ был на вторую часть вопрос про «Магенто»

Seven Berg

Seven Berg 01.11.2024 18:12

Понял, просто у них вроде в раньшее время офис был в Киеве, если не ошибаюсь, и каждый год проводили Magento Conference(классная конференция была!), а потом раз и пропали.

Witness

Karina Kosenko PHP developer в IT Craft 02.11.2024 10:21

Ну, нинішній проект на пихі ми зарелізили два роки тому. Місяць тому спілкувалась з давніми колегами, які працюють на різних українських продуктах, написаних на пхп — їхні проекти почали писатись від кількох місяців до 6 років тому.
Щодо Мадженти не в курсі, ніколи серйозно з нею не працювала, але в неї і ніша своя специфічна. А от Лара з Симфою живіші всіх живих. Навіть тут на ДОУ за останній місяць чи два люди писали про свої відносно нові проекти на Ларі.

Seven Berg

Seven Berg 02.11.2024 20:18

Почему не нужно начинать новые проекты на пыхе ответил выше. Единственно с чем соглашусь, что много сайтов на ней понаписано, поэтому их нужно поддерживать!

Denys Bidiuk General QA Engineer (Java) в Large systemically important bank (NDA) 15.10.2024 11:39

Питання із розряду: а яка автівка краща, чи який смартфон)

Vic Programmer 15.10.2024 12:04

Ну задля цьго же і двиляться же різні обзори, читають журнали і звертаються до експертів, типу Джеремі Клакрксона. Ті роблять якісь крітерії об’єктивної оцінки та виставляють рейтинги — щоб читатчь чи зритель, який спочатку не має повної експертизи робив висновки.
В цілому — можемо написати.

Denys Bidiuk

Denys Bidiuk General QA Engineer (Java) в Large systemically important bank (NDA) 15.10.2024 12:19

Та я трохи інше мав на увазі)
Якби була б одна найкраща автівка, купували б лише її, а інші би не купували.

Якби була одна найкраща мова програмування — використовували б тільки її, і інших би не було.

Vic

Vic Programmer 15.10.2024 14:19

Купують те на що є попит, а він різний в різних умовах. І як бачимо виробники підганяють під потреби клієнта. Наприклад в США з авто — найбільші продажі мають пікапи, потрібна тачка по маленьких містечках та на селі де бізнес сільське господарство та якись ремонт, будівництво, маленькі магазини і т.д. Такий собі PHP авто світу.
В українському ІТ відверто перегріли ринок Frontend та JavaScript на загал, бо було відносно просто подати жопочаси — був західний клієнт. Станом на зараз більшість IT спеціальностей на +/- одному і тому самому рівні. Тисяч вакансій на Frontend — більше нема. А от пропозиція подекуди шалена.

Denys Bidiuk

Oleg Antoshkiv Backend Developer в ELEKS 15.10.2024 15:43

У США пікапи — це скоріше хайп, бо їх купують і ті, хто живе в місті, більшість власників пікапів возять щось в кузові раз на рік або ніколи. З мовами програмування схожа ситуація.

Vic

Oleg Kotok Software Engineer в VELOMAT Messelektronik GmbH 15.10.2024 13:23

ну так iPhone i Tesla, якщо в умовах України — БТР + Старлінк

Denys Bidiuk

Vic Programmer 15.10.2024 16:07

О мажори — і старлінк і БТР одразу. Коли у нормальних пацанів — музейний Дехтярьов Піхотний, зразка 1927 чи взагалі Кулемет Максима і лопата.

Oleg Kotok

Melnyczenko Mel 15.10.2024 11:38

Якщо вам працювати, а не ви*обуватися якоюсь псевдо-елітарністю (як ті ж любителі Go) — то відкриваєте той же Djinni, та фільтруєте вакансії по мові

От прямо зараз, PHP — 265
Python — 185
Java — 160

От вам і топ. Як є бажання погратись з «модними» Golang, Rust, Ruby — welcome, тільки там в 10 разів менше вакансій (наприклад, Ruby — 18)

Vitalii D Frontend Engineer в Tide.co 15.10.2024 11:45

Вангую що вакансій без досвіду на go, rust взагалі немає

Melnyczenko Mel 15.10.2024 12:30

Ну це як С++. Досвідчений сішник може гребти лопатою, тільки
1) попробуй ще отримай той досвід
2) знайди ту вакансію-єдинорога

Vitalii D

Misha Losyk Node.js Developer в Relevant Software 15.10.2024 11:47

Окей, тільки:
— Java. Кандидати 1303, вакансії 160.
— Go. Кандидати 243, вакансії 55.

Oleh Onufryk Senior Software Engineer в boemm.eu 15.10.2024 12:11

— Java. Кандидати 1303, вакансії 160.

а скільки серед тих 1303 достойних кандидатів?

Misha Losyk

Oleg Skalozub Golang dev 15.10.2024 14:18

стільки, скільки отримають офер. А скільки достойних з

243

Oleh Onufryk

Romko 15.10.2024 11:56

відкриваєте той же Djinni, та фільтруєте вакансії по мові
От прямо зараз, PHP — 265
Python — 185
Java — 160

Такий підхід не завжди правильний: важливо ще враховувати, скільки потрібно нових спеціалістів у певному напрямі, бо може бути так, що є хай під триста вакансій, але з них майже всі — рівня сіньйор / мідл, тоді як в іншому — вакансій сумарно вдвічі менше, але набагато більше — початкового рівня; або ж, припустимо, мова програмування повільно вмирає, але на ній написано купу легасі коду — і відповідно чимало вакансій. Тому, вважаю, варто підійти до питання більш всесторонньо, вивчаючи тенденції.
P.S. За жодну конкретно мову не агітую, бо давно не цікавився тенденціями на ринку: маю свій напрям — і в ньому розвиваюсь. Але згадалась ситуація друга, який років 5 тому добре як для початківця вивчив Java, бо побачив на ній багато вакансій, але ніхто на ній початківців не хотів; довго шукав роботу по Java, і в кінці його взяли на роботу з зовсім іншою мовою, яку навчили з нуля. І він мені порадив: вчи іншу мову, бо там буде знайти роботу майже нереально. Я перестав вчити Java, взявся за JS, і зі знайденням першої роботи не було проблем. Правда, то було у старому-доброму 2021, а зараз тенденції зовсім інші.

Vic Programmer 15.10.2024 12:07

Поміттє — менше вакансій, це часто і менша пропозиція на ринку. Скажімо на Node — теж під 200 вакансій, але і відгуків на джуніора так само під 500. Тоді як скажімо на Go — може бути 7-8 і теоретично якщо прикласти зусиль, пройти 10-20 співбесід, можна оримати першу роботу в ІТ.
Безумовно поріг вхорду в Go, Java, Python а тим більше Rust — на три голови вищій, ніж в PHP. Відповідно — якщо вам треба робота, бажано через два три місяці — а не рік, півртора т.е. від Go із Rust звісно краще триматись подалі, а краще штудіровать пих, а ще краще бігом шукати ментора який потім дасть рекомендації наймаючому менеджеру, бо саме так воно і працює — соціалні зв’язки. З клієнтами і т.д. — аосолютно те саме. Часто клієнт вибере зовсім не найкращого спеціаліста — але інтроверта, а компанію я зякою можна десь або бухнути — або якись спорт, квадроцикли волейбол і т.д. Аби воно робилось прийнятно, бо свій настрій люди часто цінять більше за будь що.

Melnyczenko Mel 15.10.2024 12:35

Відповідно — якщо вам треба робота, бажано через два три місяці — а не рік, півртора

Маю думку, що люди які питають «яку мову вивчити» — ідуть в ІТ саме за грошима і роботою по-швидше. Бо ентузіасти і так знають, яка мова/стек їм подобається

Vic

Vic Programmer 15.10.2024 13:25

Для того щоб щось «подобалось» компанії виробники та донатери тех стеків прикладають величезну маркетингові зусилля. Та на той же R або Erlang наприклад вам буде не так вже і просто зібрати команду.
Станом на зараз усі в курсі що за тим же : PHP — стоїть META (Facebook), Java — цілий конгломерат : Oracle, Amazon, IBM, VMware і т.д. та і Google які пішли через діалект — Kotlin.
JavaScript і діалекти (TypeScript, Coffescript, Darth і т.д.) — знову конгломерат : Mozilla (Nescape), Google , Microsoft, Arbnb і и д.
C#/.NET — Microsoft
І так далі — на ці тех стеки на ринку є спеціалісти і так сталось не само по собі, це в першу чергу бізнес, бізнес засобів розробки. IDE, навчальні матеріали, книги, тематичні конференції, хакатони і т.п.

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 13:28

Microsoft зараз вкладається в TypeScript чи не більше, ніж у .NET

Vic

Vic Programmer 15.10.2024 13:52

TypeScript — на Node, це побочний продукт. Сучасний Frontend, одним із найбільших технічних ринків — дуже сильно захоплюється саме TypeScript.
Сама ідея Node — це мати ту саму Agile кросс функціональну команду, в якій нема ботлнеків і усі можуть робити і Frontend і Backend і Mobile як воно і було раніше. Та так так стало не вигідно і відверто — доволі складно через об’єми робіт та навичок на одну людину. Та індустрія пішла в масове виробництво — Веніціанску Галеру із розділенням праці. Тобто в чергову привнести бізнес модель Генрі Форда в ІТ, не дивлячись на усі провальні намагання того самого ще з 60-х років минулого століття, з IBM і т.д. Насправді воно працює — але масштабується по іншому, малими командами, короткими ітераціями і т.д.
Маємо ситуацію — коли IT курси массово пішли в підготовку саме Node і ринок переповнений пропозицією, JavaScript та Manual QA . Звісно реально вартувало би — PHP та C# та Java. Так само DevOps/Claud Ops — де попит вище пропозиції.

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 14:01

Галера має сенс, коли є певні обсяги відносно одноманітних проєктів або можна просто продавати час за гроші. Якщо у тебе двіж і потрібно робити тут і зараз, то мати спільну кодову базу для бека і фронта та людей, які можуть зробити фічу від початку до кінця, — це набагато краще для бізнесу, хоча може здаватися дорожчим. Ну і зрозуміло, що на цьому етапі ти навряд чи будеш наймати джунів/мідлів. Тому уявна переповненість ринку пропозицією тобі не дуже допоможе.

Зрозуміло, що це масштабується лише до певного моменту, але якщо цей момент настав, то зазвичай можна вже ‘заливати’ проблеми грошима.

Vic

Vic Programmer 15.10.2024 14:10

Це краще для скажімо малих, середньо малих бізнесів. Node — відносно проблематичний стек, як і PHP. В обох стеках часто доходить що проблеми з перформансом оптимізації починають робити через С++ розширеня. JavaScript — це далеко не : Modern C++, Go чи Rust та навіть і не Java та C#, приблизно те саме по перформансу що і Python та PHP.
Коли починаються проблеми із performance на продакшені, бо воно не витримує навантаження — простих методів не знаходиться. Реально доходить до реплатформінгів.
Так само проблеми з безпекою, традиційна біда чистих інтерпретаторів і т.д.

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 14:15

V8 вже досить давно дуже близький до native performance на реальних задачах. А для ML/inference навіть у браузерах вже є ONNX з нативною підтримкою GPU.

Vic

Vic Programmer 15.10.2024 14:23

На папері в синтетичних тестах — може і так. В житті — буває дуже погано і клієнт каже переписати наприклад на Spring. Варіанти підтюнити через C++ ексеншени, наприклад — часто відкидають. Насправді накладні розходи JavaScript — доволі суттєві. Мова зовсім для іншого задумувалась, конкретно як скріпт в браузері.

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 14:30

Коли в житті буває дуже погано, зазвичай це не від мови залежить :) І переписування на Spring допомагає не через Spring, а через саме переписування :) Тобто це можна було зробити і на TS, просто відразу за актуальними вимогами, а не намагатися виправити ‘ітеративно складений код’ :)

Vic

Vic Programmer 15.10.2024 22:37

Коли в житті буває дуже погано, зазвичай це не від мови залежить :)

Звісно відпрофілювати і написати на С++ критичні участки можна (і насправді в тихоря воно і було написано, бо цікаво ж йпта), та кажу же керівникі рахують бабки і кажуть — пишіть на Java, не треба нам різних ізвратів та зопарків технологій на проекті в стилі Facebook.

Dmitriy Mozgovoy JavaScript / NodeJS Developer 15.10.2024 18:03

Мова зовсім для іншого задумувалась, конкретно як скріпт в браузері.

Яка різниця як вона задумувалася 30 років назад? Мова це просто декларація AST, яке вона відношення має до конкретної імплементації VM? Мова буде мати ті ж самі обмеження в продуктивності що і інші з динамічною типізацією, гарбедж колектором та JIT компіляцією. Це можна оптимізовувати скільки завгодно, але все ж воно не може зрівнятися з кодом з явними низкорівневими інструкціями, де не треба робити зайвих припущень та оптимізацій.
Та і що з того перфомансу платформи, якщо реальний код обмазаний 100500 шарами абстракцій фреймворків, а користувацький код м’яко кажучи далекий від оптимізованого- там знайдеться куча місць на всіх рівнях для оптимізацій, поки можна реально впертися в перформанс самої VM.

Vic

Vic Programmer 15.10.2024 23:01

Мова буде мати ті ж самі обмеження в продуктивності що і інші з динамічною типізацією, гарбедж колектором та JIT компіляцією

Ні це не так. Згоден усі бенчмарки це не 100% крітерій особливо коли є питання коли ріpні з рештою порівнються алгоритми тим не менше це один з крітерієв оцінки.
Порівняємо

Lua різниця по деяким три рази на корсить JavaScipt programming-language-benchmarks.vercel.app/lua-vs-javascript
Python — рзіниця в безкінечність на корсить JavaScipt programming-language-benchmarks.vercel.app/python-vs-javascript Perl те саме

Тепер візьмемо байткодні машини

Java навпаки 2 кратна перевага programming-language-benchmarks.vercel.app/java-vs-javascript
C# приблизно так само programming-language-benchmarks.vercel.app/csharp-vs-javascript

Але найцікавіше, це компіляція в натив

С та C++ — перевага від 2 до 6 разів
programming-language-benchmarks.vercel.app/c-vs-javascript
programming-language-benchmarks.vercel.app/cpp-vs-javascript
Rust — від 2 до 5 разів programming-language-benchmarks.vercel.app/rust-vs-javascript
А от D та Go Lang прогають JavaScript, подекуди в двічі
programming-language-benchmarks.vercel.app/d-vs-javascript
programming-language-benchmarks.vercel.app/go-vs-javascript
Swift так само виявився повільнішим programming-language-benchmarks.vercel.app/swift-vs-javascript

Звісно реальні задачі суттєво відрізняються. Наприклад Docker чи Kubernetes буде важкувато написати на JavaScript цілком. А от FireFox на дуже велкий процент написаний саме на JavaScript, крім Rust-ту та С++.

Dmitriy Mozgovoy JavaScript / NodeJS Developer 16.10.2024 00:46

Ні це не так.

Як не так? :) Ви ж не будете стверджувати що, мови з динамічною типізацією, GC та JIT буде продуктивніше мов, де цього немає, а все виділення та звільнення пам’яті відбуваються явно, де нема оптимізації-деоптимізації через динамічні типи, і де прямі інструкції під цільову платформу, замість VM?
Ви ж підтверджуєте бенчмарками — чуда не сталось і JIT не обійшла нативні і так VM JS штука досить продуктивна серед інших VM.
Ну і взагалі ті бенчмарки кривенькі, бо як я розумію вони міряють час виконання всього скрипту разом з запуском ноди, вже не кажучи що нема попереднього прогріву функцій, хоча може через опції запуску зафорсили.
Зазвичай в якості бекенду нас цікавить час виконання заоптимізованого прогрітого коду, а не час витрачений на запуск ноди і внутрішню оптимізацію гарячих функцій оптимізаційним компілятором.

Vic

Vic Programmer 16.10.2024 02:31

Дивіться ми йдемо в дискусію, яка набере на пару статей лише обзорів усіх плюсів та усіх мінусів, а також до мільйона холіварів. Одна тема використання V8 пам’яті — як в Node та і в Chrome, це предмет великого аналізу — та історичних справок періоду браузерних війн та браузерних бенчмарків під які тюнили алгоритми зокрема і збірки сміття, щоб бути швидше за SpyderMonkey та Chakra в тестах. (В моїх двох випадках обробки справді великих масивів інформації, де мікросервіси на Node довелось переписувати — головна проблема була якраз пам’ять. Її не вистачало на POD-ах, а дорожчі коштували скирту бабла на тиждень).
В цілому то цим наповнений увесь інтернет, багато розумних конференцій статей і т.д.
Можна підти в розуміння про тематики більшості CRUD які стоять на бекенд серверах, де вийде, що власне навіть байткод інтерпретація — то таке собі, вміє тюнитись під цільову платформу само профілюватись — на ділі займається переключенням контексту проміж потоками та ботелнечить на блокованих IO в JDBC, навіть як API зроблено на асинхронних сокетах, не блокуючий IO, бінарні — avro, grpc усе по феншую і т.д. І пара кривих select-ів в базу, погані індекси і т.д. робить погано усьому кластеру. Або ще краще — коли Neo4 , Dynamo DB або Cassandra — перетворюється на жахіття команди, і з нього випилють усе що можна, та перекидають на PostgreeSQL чи Oracle.

Andy W 16.10.2024 04:06

А от D та Go Lang прогають JavaScript, подекуди в двічі
programming-language-benchmarks.vercel.app/d-vs-javascript
programming-language-benchmarks.vercel.app/go-vs-javascript

Відкриваємо лінки:
D проти JS — JS виграв 14 з 37 тестів
Go проти JS — JS виграв 4 з 37 тестів

Уж програли — так програли, всім би так

Vic

Vic Programmer 16.10.2024 10:34

Ну так я звісно накинув, у відповідь бо флейм же пішов :) Холівар же класичний.
Синтетика усіх бенчмарків — наше усе. Там якщо більш детально дивитись, на одній конфі розбирали — що JS банально робить те для чого був зроблений — викликає нативний код, при чому навіть не С-шений, а асемблерний.
Так само були бенчмарки де багато років найкрутішою мовою був PHP, в реалії він працював просто із задіянням усіх ядер процесора на сервері, тоді як бенчмарки з інших мови працювали на одному ядрі.
Ну і вишенька на торті як на мене була коли хлопці та дівчата з Intel розбирали один бенчмарк, де OpenCL робив в п’ять разів OpenMP по швидкості. При чому це працювало на процесорі, а не на відеокарті. Почали розбиратись — виявилось там два різних алгоритма порівнювалось. Переписали OpenMP — виявилось різниця в районі статистичної похибки.
Як я вже помітив — на голому JavaScript ви всеодно не зможете написати скажімо : Kubernetes, Docker або FireFox . Купа незручностей, починаючи хочаби від відсутності integer типів данних. На Go та Rust теж прийдеться прилінковувати С-шний код, принаймні робити обгортки над системним API (що дуже велика частина кодової бази того же Docker чи runc). FireFox — теж має суттєво С++ коду в движку.

Andy W

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 14:19

Ну і WASM, якщо хочеться хардкору... І писати можна хоч на C++.

Vic

Vic Programmer 15.10.2024 14:26

Де факто ні на чому іншому крім С++ та emscripten — production ready WASM станом на зараз не написати. Хоча можна мало не на усьому : Go, Rust та той же TypeScript — можна напряму компілювати в байткод. Але ніхто так не робить особливо для бекенду.

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 14:28

Отут на рахунок Node.js ви дуже помиляєтеся, як тех стек може бути проблемним, якщо JS має ледь не найбільшу екосистему з third-party бібліотек, яка продовжує дуже швидко розвиватися? Щодо перформасну в Node.js ви теж помиляєтеся, у Node.js порівняно високий перформанс, значно вищий ніж у Python та PHP, десь на рівні з Java, але більш економно до RAM. Просто треба мати трошки більший кругозір в екосистемі ніж Express.js, Socket.io та іншого шлаку, де все зроблено з думкою «аби працювало», альтернативи, наприклад, це Fastify (+його екгсистема) та uWebscockets.js. Node.js дійсно погано підходить для CPU інтенсів апок, от лише тут треба буде користуватися FFE з C++ чи Rust, але все таки тут справа в підбору інструменту для рішення задачі), якщо у вас в коді Ноди багато FFE, тут схоже, що ваш вибір вирішувати поставлену задачу з Node.js був не дуже оптимальним. Звісно Node.js це не сільвер булет, як і будь що, але Нода з більшістю задач дуже якісно справляється

Vic

Vic Programmer 15.10.2024 14:42

Ну помиляюсь не помиляюсь — я конкретно із цим стикнувся, при чому не одноразово. Node не витягнув навантаження на production через поганий ART та шалене використання пам’яті, через що довелось платити більше за послуги AWS та GCP. Було виставлено купу кешів і т.д. Співвідношення ціна якість — виявилась не рентабельною і робили реплатформінг. Та для низки проектів — без великих навантажень, усе пройшло нормально. Щодо швидкості розробки — тут +/- як на мене, що скажімо Next.JS що Spring Framework. Трошки різний синтаксис — а так одне і те саме.
Коротше кожний тягне в своє болото з одного боку. З іншого — професіонали відрізняються не стільки інструментами, скільки результатами.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 14:59

А якого роду це була апка, якщо не секрет, щось типу файлового сервера, що перехід на Spring допоміг? І який у вас був тех стек? Якщо в тех стеку був Express.js то це був банально некомпетентний вибір (без образ) з самого початку який вистрілив в ногу, не зважаючи на конкретику самої апки

Vic

Олександр Шпак Oarsman в Self Employed 15.10.2024 15:33

Fastify не кращий... Що там зараз топ-лібою для обслуговування http/ws запитів вважається?

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 15:39

Емм, ви серйозно? Якщо брати сухий бенчмарк, то Fastify в 3.5 разів, чи навіть більше швидший, + вся його екосистема націлена на швидкість, оптимальність і якість роботи. На одному з моїх реальних проєктів переключення адаптеру NestJS з Express на Fastify дав буст 40% перформансу + заміна логера з Winston на Pino (знову ж таки від творців Fastify) дало ще +40% перформансу. Ну і Fastify ще можна забустити з uWebSockets.js, це дуже просто робиться. Fastify+uWS якраз буде топ рішенням на Ноді, якщо не рахувати щось ульра-експерементальне написане з використанням того ж uWebSockets.js

Олександр Шпак Oarsman в Self Employed 16.10.2024 13:11

Швидкість мене турбує в останню чергу, перед нодою можна поставити будь-який інший вебсервер та забути про половину проблем. Тут більше з боку того як це все розвивати та підтримувати. Без сліз на плагіни дивитися не можна, документація наче й виглядає обширною, але швидко дати відповідь на запитання, які ти зазвичай ставиш при налаштуванні веб-сервера, ти не можеш. Конфігурування в коді — це ще той треш. А швидко працює — то вже бонус.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 13:23

Це не добре, що швидкість вас турбує в останню чергу, оскільки це може значно економити ресурси інфраструктури. А що не так з плагінами? У Fastify теж обширна екосистема, яка по функціоналу не поступається Express.js, але на відмінну від останнього зроблена з думкою як це зробити оптимально, а не тяп-ляп працює, от і добре. Що ви маєте на увазі під «Конфігурація в коді»? Окрім того, обидві бібліотеки є досить «худенькими» тобто по факту це просто роутер і набір міддлвар (хуків у випадку Fastify) і все, все інше контролюється власне розробниками, які тут проблеми з розширенням і підтримкою? Можете назвати реальні переваги Express.js над Fastify окрім того, що перше вам просто звичніше?

Олександр Шпак Oarsman в Self Employed 16.10.2024 14:46

Це не добре, що швидкість вас турбує в останню чергу, оскільки це може значно економити ресурси інфраструктури.

Передвчасна оптимізація — один з найстрашніших гріхів розробника. ;) Мене мало турбує швидкість, тому що в мене вариативність рішень велика. Завжди треба дивитися на умови задачі, потім вже підбирати відповідний інструмент.

А що не так з плагінами?

Візьмемо як приклад @fastify/static. Він тупо незручний. Робив локалізацію статичних файлів, з рероутом, без сліз та милиць це не вирішилося.

Що ви маєте на увазі під «Конфігурація в коді»?

Ось це


server.get('/ping', opts, async (request, reply) => {
  return { pong: 'it worked!' }
})

Можете назвати реальні переваги Express.js над Fastify окрім того, що перше вам просто звичніше?

Я взагалі вже не памʼятаю, коли я востаннє користувався Express.js. Все тільки Fastify. Але дедалі менше. Простіше підняти сервер на пітоні, ніж на ноді.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 15:15

Передвчасна оптимізація — один з найстрашніших гріхів розробника. ;)

Перепрошую, але таке враження, ніби ви не розумієте суті цієї цитати, а суть в ній у тому, що оптимізація зазвичай шкодить чистоті коду, тому треба спочатку думати про чистий код, а потім про оптимізацію. Що власне в кейсі Express vs Fastify взагалі не тему, бо використання Fastify не шкодить клін коду, це просто ліба, яка нічим не поступається Express і ще й набагато краще написана.

Візьмемо як приклад @fastify/static. Він тупо незручний. Робив локалізацію статичних файлів, з рероутом, без сліз та милиць це не вирішилося.

Використоувати Node.js для статичних файлів це вже його неправильне використання) Для такого є S3 і йому подібні. Node.js взагалі з файлами погано працює, це його слабкість.

Ось це

Щодо коду, а яка в цьому проблема? Навпаки Fastify з коробки дає те, що Express не вміє, наприклад можна схему задати для валідації і генерації Swagger. Ну і власне інші налаштування певного роуту, типу на вашу думку причіпити до роуту мідлвару, це краще?

Простіше підняти сервер на пітоні, ніж на ноді.

Невже вам на стільки складно підняти сервер на ноді, що ви аж зрівнюєте його з Python? Це хіба складно?

```
import fastify from «fastify»;

const app = fastify();

app.get("/«, async (req, res) => {
return { hello: «hello» };
});

await app.listen({ host: «0.0.0.0», port: 3000 });
```

Олександр Шпак Oarsman в Self Employed 16.10.2024 19:39

а суть в ній у тому, що оптимізація зазвичай шкодить чистоті коду, тому треба спочатку думати про чистий код, а потім про оптимізацію.

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

Використоувати Node.js для статичних файлів це вже його неправильне використання

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

Node.js взагалі з файлами погано працює, це його слабкість.

Не помічав такого. Хоча й не було задач на низький рівень роботи з файловою системою.

Щодо коду, а яка в цьому проблема?

Декларативний стиль краще підходить для конфігурування налаштувань, ніж імперативний. Ви не можете так просто взяти шмат конфіга та розшарити його з іншим проектом. Сусідній сервіс не зможе так просто прочитати конфіг з вашого коду, бо треба прикручувати синтаксичний аналізатор. Будь-яка зміна вимагає коміту та деплою всього проекту.

Ну і власне інші налаштування певного роуту, типу на вашу думку причіпити до роуту мідлвару, це краще?

Дивлячись яка задача. Інколи це набагато краще, тому що контроль за певними процесами перекладається на інфраструктуру та девопсів. Як я вже зазначав, статику нода сервить в неприродній спосіб на мою думку.

Це хіба складно?

Порівняйте з python3 -m http.server

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 20:27

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

Ну так а корінь цього який? Чому не можна написати одразу гарно? А відповідь на це питання я озвучив вище

Немає правильного чи неправильного використання

Ви серйозно зараз? Якщо використовувати інструмент для того що у нього погано виходить, що це як не неправильне використання?

Фастіфай розроблявся під специфічні задачі, це видно по його інтерфейсу.

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

Декларативний стиль краще підходить для конфігурування налаштувань, ніж імперативний.

Де ви бачите в оголошені конфігу роуту імперативний підхід? От де? Імперативний підхід це в першу чергу підхід до написання логіки, де логіка в конфізі?

Ви не можете так просто взяти шмат конфіга та розшарити його з іншим проектом

Якщо не виходить перевикористоувати код між проєктами, це справа зовсім не у фремворку, а тому як ви пишете код

Сусідній сервіс не зможе так просто прочитати конфіг з вашого коду, бо треба прикручувати синтаксичний аналізатор. Будь-яка зміна вимагає коміту та деплою всього проекту.

Перепрошую, я взагалі не розумію про що ви тут говорите, який ще синтаксичний аналізатор? Нащо? Ви про service-to-service комунікацію? Чи про те що один сервіс читає код іншого проєкту?

Не помічав такого. Хоча й не було задач на низький рівень роботи з файловою системою.

Та до чого тут низький рівень, Node.js погано працює з файлами, тому що він асинхронний, робота з файлами, це зазвичай робота з великими обʼємами даних, з чим краще справляються синхронні мови по типу Java

Дивлячись яка задача. Інколи це набагато краще, тому що контроль за певними процесами перекладається на інфраструктуру та девопсів. Як я вже зазначав, статику нода сервить в неприродній спосіб на мою думку.

Яким чином задачу конфігу роуту, наприклад оголошення схеми вхідних і вихідних даних, ви перекладаєте на девопса і інфраструктуру за допомогою мідлвари? Природньо чи не природньо тут напевно субʼєктивне поняття, але те що Node.js погано підходить, щоб сервити статику це обʼєктивний факт.

Порівняйте з python3 -m http.server

не бачу сильної різниці, якщо чесно

Олександр Шпак Oarsman в Self Employed 16.10.2024 21:50

Ви серйозно зараз? Якщо використовувати інструмент для того що у нього погано виходить, що це як не неправильне використання?

Правильно чи неправильно — це субʼєктивна річ. Якщо ваш код досяг мети, поставлених цілей, то як він може бути неправильним? Задачі бувають різними, є такі, які вимагають ретельного планування, продумування, реалізації, а є «реакт-реакт і в продакшин». В одному випадку недоцільне використання інструментів, які не підходять задачі, призведе до підвищення витрат, а в другому це абсолютно нормальна практика прототипування.

Де ви бачите в оголошені конфігу роуту імперативний підхід?

Ось тут:

server.get('/ping', opts, async (request, reply) => {
  return { pong: 'it worked!' }
})

Ви тут наказуєте інстансу server виконати метод get з певними параметрами, а також ви одразу мапите функцію-хендлер для цього. Порівняйте це з конфігами апача чи енжинекса.

Ви про service-to-service комунікацію? Чи про те що один сервіс читає код іншого проєкту?

Задача — два сервіси читають одні й ті самі роути. Розкажіть, як би ви це реалізовували. Один сервіс на node.js, інший на python.

Та до чого тут низький рівень, Node.js погано працює з файлами, тому що він асинхронний, робота з файлами, це зазвичай робота з великими обʼємами даних, з чим краще справляються синхронні мови по типу Java

Java підтримує асинхронність та може читати файли рівно так само як й JS. Великі обʼєми зазвичай буферізуються та стрімляться, але це не залежить від мови програмування. Сучасні OS та файлові системи дозволяють читати в асинхронному режимі будь-який файл.

Яким чином задачу конфігу роуту, наприклад оголошення схеми вхідних і вихідних даних, ви перекладаєте на девопса і інфраструктуру за допомогою мідлвари?

Ви не розділяєте ендпойнт (декларацію роута) та хендлер. Але це не єдиний спосіб побудови архітектури веб-сервісу. Ви можете зробити класичний варіант «webserver + cgi» та мати можливість керувати певними роутами окремо від свого сервісу, обслуговувати статику, мультимовність, шифрування, тощо.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 22:04

Правильно чи неправильно — це субʼєктивна річ.

Як на мене часто досить обʼєктивна, але якщо ви вирішили вирішувати задачу неоптимально, це вже ваша справа

Ви тут наказуєте інстансу server виконати метод get з певними параметрами, а також ви одразу мапите функцію-хендлер для цього. Порівняйте це з конфігами апача чи енжинекса.

Так заждіть, практично те саме треба робити майже в будь-якій мові програмування на якій пишеться бекенд, на конфігах Apache чи Nginx ви апку не напишите

Задача — два сервіси читають одні й ті самі роути. Розкажіть, як би ви це реалізовували. Один сервіс на node.js, інший на python.

Як варіант я б з сервіса в який ходять згенерував Swagger доку для роутів (з тієї самої JSON схеми в конфігу роута) а потім для сервісів які викликають попередній сервіс згенерував би API клієнт з Swagger доки, це якщо говорити про HTTP, ще як варіант можна комунікувати через якийсь PubSub

Java підтримує асинхронність та може читати файли рівно так само як й JS. Великі обʼєми зазвичай буферізуються та стрімляться, але це не залежить від мови програмування. Сучасні OS та файлові системи дозволяють читати в асинхронному режимі будь-який файл.

Java то може, але для обробки файлів асинхронщина погано підходить, синхронна Java справиться з цією задачею краще ніж асинхронна

Ви не розділяєте ендпойнт (декларацію роута) та хендлер. Але це не єдиний спосіб побудови архітектури веб-сервісу. Ви можете зробити класичний варіант «webserver + cgi» та мати можливість керувати певними роутами окремо від свого сервісу, обслуговувати статику, мультимовність, шифрування, тощо.

Так чим тут заважає конфіг роуту в Fastify? Він не відповідає за жодне з перелічених речей, шифрування це справа проксі серверу; статика, мультимовність це задача хендлеру

Олександр Шпак Oarsman в Self Employed 16.10.2024 23:32

Як на мене часто досить обʼєктивна, але якщо ви вирішили вирішувати задачу неоптимально, це вже ваша справа

Для того, щоб визначити оптимальність, треба спочатку задекларувати критерії тієї самої оптимальності. Власна думка не є таким критерієм.

Так заждіть, практично те саме треба робити майже в будь-якій мові програмування на якій пишеться бекенд, на конфігах Apache чи Nginx ви апку не напишите

Підхід webserver+cgi не вимагає наявності роутів, бо там обробником є файл/скрипт.

Як варіант я б з сервіса в який ходять згенерував Swagger доку для роутів

Це працює тільки для тих роутів, які наявні в публічному API, для статики Swagger вам не допоможе.

Java то може, але для обробки файлів асинхронщина погано підходить

Це більше схоже на упередження.

Так чим тут заважає конфіг роуту в Fastify?

Я вже казав, він написаний в імперативному стилі на мові JS.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 17.10.2024 09:28

Для того, щоб визначити оптимальність, треба спочатку задекларувати критерії тієї самої оптимальності. Власна думка не є таким критерієм.

Коли в технології є свої сильні сторони і слабкі, але використовувати технологію у тому де вона саме слабка це для вас не є критерієм, то я вже не знаю що сказати

Підхід webserver+cgi не вимагає наявності роутів, бо там обробником є файл/скрипт.

Як це не вимагає? Вам з тих роутів, що ви оголосили в Ngingx/Apache конфізі, треба редіректити на роути, які ви оголосили в апці.

Це працює тільки для тих роутів, які наявні в публічному API, для статики Swagger вам не допоможе.

А що заважає згенерувати свагер доку, але не робити її публчною?

Я вже казав, він написаний в імперативному стилі на мові JS.

Як конфіг може бути написаний в імперативному стилі, от як? Імперативний стиль стосується написання логіки, де в Plain JS обʼєкті логіка?

Олександр Шпак Oarsman в Self Employed 17.10.2024 13:09

Коли в технології є свої сильні сторони і слабкі, але використовувати технологію у тому де вона саме слабка це для вас не є критерієм, то я вже не знаю що сказати

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

Вам дають задачу, наприклад, побудувати простий API для того, щоб зберігати файли в файловій системі. Це PoC, треба просто перевірити, чи буде зручно працювати з таким підходом в майбутньому. Ви що, будете ретельно прикручувати minio, будувати цілу низку рішень, щоб підтримувати буферізацію, мультичанкове завантаження, паралельну обробку, обкладете це все тестами, моніторингами, чи просто наколупаєте щось лівою ногою, аби працювало? Яке, на вашу думку, рішення буде ефективним, перше, чи друге?

Як це не вимагає? Вам з тих роутів, що ви оголосили в Ngingx/Apache конфізі, треба редіректити на роути, які ви оголосили в апці.

Не треба. Я вже казав, що хендлером в даному випадку виступає файл, який лежить в певній директорії, яка співпадає з шляхом в url. Все тупо, як двері (не без своїх недоліків, звісно ж, але на грані геніального навіть).

А що заважає згенерувати свагер доку, але не робити її публчною?

На обробку статики?

Як конфіг може бути написаний в імперативному стилі, от як?


const cfg = new Config()
cfg.set("/", { handler: core.main })

Ось так.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 17.10.2024 13:29

Це PoC, треба просто перевірити,

Вас зараз перекидає вже на PoC, хоча до того ми говорили за продуку. Для PoC звісно згодиться, а якщо для продукту, то треба думати головою, щоб потім не треба було платити купу грошей за інфраструктуру, підтримку чи переробку. Time to Market це мега важливо, але іноді просто включивши голову і порівняти альтернативи можна практично не пожертвувати Time to Market, але при цьому отримати апку яка буде нормально працювати роки, а то і десятиліття і не приносити головного болю.

Не треба. Я вже казав, що хендлером в даному випадку виступає файл, який лежить в певній директорії, яка співпадає з шляхом в url. Все тупо, як двері (не без своїх недоліків, звісно ж, але на грані геніального навіть).

Так стоп, ми тут говорили про роздачу файлів через Node.js апку, і ви доводили, що це нормально, тепер ви розповідаєте, про підхід без Node.js апки для цієї задачі. Підхід без Node.js для цієї задачі мені більше подобається, але до того ви наполегливо розповідали, про те що з Node.js тут все ок.

На обробку статики?

Ви змусили весь час мене думати про роздачу статики з Node.js апки, там так можна було б зробити, тепер ви перемкнулися на роздачу статики без її участі

Ось так.

Так а у чому проблема декларативності тут? Ми цілком собі декларативно оголошуємо, що у нас є певний роут з певним HTTP методом, певним Path, і певним хендлером, імперативщина буде вже в середині самого хендлеру. Як по вашому в бекенд апці, мовою програмування можна оголосити роут більш декларативніше? Якщо що, конфіги Nginx це не бекенд апка)

Олександр Шпак Oarsman в Self Employed 17.10.2024 13:43

Вас зараз перекидає вже на PoC

Це я приклад.

Так стоп, ми тут говорили про роздачу файлів через Node.js апку

Перечитайте наше попереднє обговорення.

але до того ви наполегливо розповідали, про те що з Node.js тут все ок.

Ви не сильно вірно зрозуміли мої слова.

Ви змусили весь час мене думати про роздачу статики з Node.js апки,

Ні, ви самостійно обмежили контекст розмови. Ми розмовляли про обробку статики нодою. Вона зроблена незручно на мою думку, але проблема не в тому, що нода асинхронна чи ще щось, просто Фастіфай не сильно пристосований для таких типів задач архітектурно, тому важко в ньому зробити це нормально. Ми говорили про те, що недолік ноди як вебсервера в імперативному способі декларувати роутів, що є інші варіанти як це можна зробити більш ефективно. Я не розумію, чому ви постійно урізали скоуп розмови до обробки нодою статики

Так а у чому проблема декларативності тут?

В тому, що це майже неможливо шарити в мікросерверній архітектурі для всіх варіантів. Сваггер звісно ж може допомогти, але це не буде працювати для всіх типів задач.

Імперативщина буде вже в середині самого хендлеру

Декларація роута виконана в імперативному стилі. Надані команди на створення конфігураційного файлу. Саме це є основною ознакою імперативного стилю.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 17.10.2024 14:07

Перечитайте наше попереднє обговорення.

Обговорення було про те, що була апка написана на Node.js, яка працювала з файлами і працювала погано, потім цю апку переписали на Java і все стало набагато краще, тому що Node.js погано справляється з роботою з файлами, а Java — добре, ще я казав, що також частою причиною поганої роботи Ноди є використання Express.js коли існує краща альтернатива у вигляді Fastify. Ви в свою чергу почали розповідати, що у Ноди взагалі немає ніяких проблем з обробкою файлів, просто вам не зручно з цим працювати, і що Fastify це гірше, або не краще за Express, а потім перемкнулися, що сервите файли через конфіг Nginx/Apache, що вже власне краще підходить для цієї задачі.
Моя думка була про те, щоб донести, що Node.js погано працює з файлами, зовсім не через незручність API якоїсь бібліотеки, і тут навіть пробувати не треба робити з допомогою Ноди цю задачу, бо вона не підходить, а також я хотів донести, що нема сенсу сварити технологію за те що вона погано справляється з задачею яку не повинна взагалі робити, окрім якихось крайніх випадків, коли продуктивність не важлива, але знову ж таки контекст в тому, що для тієї апки продуктивність була важлива.

В тому, що це майже неможливо шарити в мікросерверній архітектурі для всіх варіантів. Сваггер звісно ж може допомогти, але це не буде працювати для всіх типів задач.

Свагер допоможе у більшості задач, якщо у нас є комунікація через HTTP між мікросервісними апками, звісно допоможе не для всіх випадків, наприклад коли є файловий сервер з Nginx, чи якась асинхронна комунікація, взагалі біди в комунікації це проблема самої мікросервісної архітектури і те як ця комунікація імплементована на рівні коду, що написали програмісти, а не системного коду бібліотек певної мови програмування

Декларація роута виконана в імперативному стилі. Надані команди на створення конфігураційного файлу. Саме це є основною ознакою імперативного стилю.

Декларація роута виконана в настільки декларативному стилі, на скільки дозволяє синтаксис мови програмування

Олександр Шпак Oarsman в Self Employed 17.10.2024 16:14

і що Fastify це гірше, або не краще за Express

Це невірно, ніколи такого не стверджував.

а потім перемкнулися, що сервите файли через конфіг Nginx/Apache, що вже власне краще підходить для цієї задачі.

Теж невірно.

Декларація роута виконана в настільки декларативному стилі, на скільки дозволяє синтаксис мови програмування

Декларація може бути написана будь-якою мовою та не залежить від синтаксису взагалі. Ви можете робити це в JSON, yaml, xml, або інших форматах, можете власний вигадати навіть.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 18.10.2024 19:40

Декларація може бути написана будь-якою мовою та не залежить від синтаксису взагалі. Ви можете робити це в JSON, yaml, xml, або інших форматах, можете власний вигадати навіть.

Апку на JSON, yaml, xml ви також зможете написати?

Це невірно, ніколи такого не стверджував.

окей, тоді що ви хотілки донести всім тим що сказали вище?

Олександр Шпак Oarsman в Self Employed 18.10.2024 21:15

Апку на JSON, yaml, xml ви також зможете написати?

Я — так. В цьому немає ніяких проблем.

окей, тоді що ви хотілки донести всім тим що сказали вище?

Все, що я хотів сказати, я вже сказав. В мене немає ніяких підтекстів в тих постах, що вже були мною сказані. Розглядайте їх як окремі вислови, уважно стежте за цитатами, які я додавав до кожної думки, щоб зберегти контекст.

Pavlo Vuiko

Oleksandr Bereziuk Solution Architect в Vitality Group Inc 17.10.2024 19:18

а якщо для продукту, то треба думати головою, щоб потім не треба було платити купу грошей за інфраструктуру, підтримку чи переробку.

Давайте повернемось у реальне життя — неможливо все продумати все ідеально на 100 відсотків уперед. У будь-якої реальної відносно великої системи, навіть яка ще у розробці, є неоптимальні складові частини, з різних причин.

Передчасна оптимізація — це, наприклад, коли фокусуються на покращенні другорядних та/або рідко викликаємих компонентів за рахунок функціоналу в цілому. В результаті, щось на кшталт,
«ми витратили тиждень та покращили час відповіді для 5 API endpoints з 5 секунд до 500 мілісекунд. Правда, ці endpoints використовуються 2 рази на тиждень, но зато вони ідеальні»

Pavlo Vuiko

Vic Programmer 17.10.2024 23:02

Хто не вірить Олександру — може прочитати мало не те саме один в один, наприклад у Томаса Кайта, або у Кріса Касперкі, ну і звісно в оригиналі у Дональда Кнута

«Premature optimization is the root of all evil.»
― Donald Ervin Knuth, The Art of Computer Programming, Volume 1

Інша справа — що різні автори потім пишуть, що робити коли система не тримає навантаження вже по факту.
Amazon, наприклад переробляв усю архітектуру в нуль, шість — разів поспіль. Те що зараз відомо як мікросервіси відповідно і AWS — що описано наприклад у Кріса Річардсона — це і є Amazon V 6.
Як на мене — передчасна оптимізація, це зазвичай симптом — а не сама проблема. Сама проблема зазвичай полягає в Bottom Up підході до розробки, постфактум проектуванні — що в свою чергу йде вже від улюбленого 80% індустрії підходу до організації праці. "чікі-чікі і в продакшн".https://en.wikipedia.org/wiki/Capability_Maturity_Model

Oleksandr Bereziuk

Олександр Шпак Oarsman в Self Employed 17.10.2024 23:38

Сама проблема зазвичай полягає в Bottom Up підході до розробки, постфактум проектуванні

Люто плюсую! В сучасній розробці, особливо в вебдеві, популярним підходом є обирання інструментарія перед тим, як розроблена вся методологія розробки продукту. А потім, через рік-два, коли почнуть лізти перші проблеми, буде прийматися геніальне рішення переписувати все з нуля. І так п’ять разів поспіль...

Vic

Andrii Sevastianov 16.10.2024 20:34

Передвчасна оптимізація

От тільки було б добре розуміти, коли вона передчасна, а коли ні...

Коли це окрема функція, яку можна в будь який момент переписати це одне. А якщо вибір вплине на весь проект, який треба буде повністю переписати, це зовсім інше.

Олександр Шпак Oarsman в Self Employed 16.10.2024 21:58

Йдіть від зворотнього. Оптимізація — це покращення коду з метою отримання більш оптимального результату для певних умов. Наприклад, оптимізація коду для прискорення компіляції, або використання памʼяті, або швидкодії, або для підтримки мультипоточності, мультиядерності, кращої пропускної спроможності, або більших рівнів абстракцій. Зʼявилися нові типи навіть, як то оптимізація під проходження тестів, логування, моніториннгу або взагалі під IDE.

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

Andrii Sevastianov 16.10.2024 22:38

Для мене оптимізація це й створення коду з нуля з оглядом на певні вимоги.

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

Ну... я такого не бачив у своєму житті.

Олександр Шпак Oarsman в Self Employed 16.10.2024 23:23

Може тому що коло спілкування трохи інше? ;)

Vic Programmer 16.10.2024 03:25

Обробка великих масивів данних, конкретно каталоги товарів в обох випадках. Крім зміни технології — там і архітектура та алгоритми як на мене були кривими, тобто пішли в підхід грубої сили в обхід лімітацій можливостей бекофісних систем (тобто зажали бабки на ERP якщо чесно, а там питання ліцензій взагалі на мільйони). Про як воно допомогло, або ні сказати не можу — бо мене там не стало в обох випадках, та і я там був «проїздом». Але так — сидів тюнив, навіть щось вийшло із переробкою пірсингу обмінного файлу в нативному ексткншені — та це завернули клієнти. І затюнив код який робив транзакції на Neo4j — це вже завернули наш. Зокрема один CTO прямим текстом сказав, що не хочу зоопарку технологій у себе і він не знається на С++ тому не хоче в це лісти.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 11:31

Ну ось, тут Node.js не дуже годиться для такого, як і впринципі будь що асинхронне, тому тут була справа в неоптимальності вибору технології з самого початку. Node.js (як і інші асинхронні технології) добре справляється із задачами де треба обробити багато досить простих запитів, коли запити важкі, то їх обробка блокує івент луп. Тут в таких задачах Java може обігнати навіть асинхронний Rust

Vic

Vic Programmer 16.10.2024 11:52

В Java — як універсальній прикладній мові, є усі технології асинхроніки, нещодавно і файбери як в Node знову завезли. В С++ теж вже чотири роки корутини в стандарті.
Тут же взагалі була інша проблематика, вона в обох випадках стосувалась пам’яті якої не вистачала на стандарних POD, а це розширення пам’яті було дуже дорогим. Нормально підтюнити GC не вдалось. І так, сміття генерував просто яваскріптний код проекту який обробляв текстові JSON та YAML файли, та лазив по базах данних.
Оця стаття наприклад пояснює в чому проблематика blog.risingstack.com/...de-js-garbage-collection
Там також є посилання на blog.risingstack.com/...a-memory-leak-in-node-js де пояснються не найкращій GC відомий як Mark and Sweep. Він дуже довго був і у Java та теж був тотальною проблемою. До того же для V8 він підтюнений під швидкість, тобто зазвичай генерує багато вільного сміття, це робить той же Chrome швидше за інші браузери, але жере пам’ять.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 13:17

У сенсі в Java є технології асинхроонки? Вона ж не так взагалі працює, там кожен запит обробляється окремим потоком, який або спавниться, або береться з пулу. Знову ж таки, мені здається, що тут конкретно для вашої задачі Java краще підходила із самого початку, але це не означає, що Java буде вигравати у Node.js у всіх випадках. Не знав що у Java тепер новий GC, але разом з тим, я чув одну цікаву філософію Java розробників, що вони зазвичай надають перевагу старішим версіям Java на противагу новим, чи це не правда?

Vic

Oleksii Nedashkivskyi AI/ML Tech Lead 16.10.2024 14:37

Я не знаю, з ким Ви спілкувались чи це такий тролінг, але асинхронка у Java зявилась ще у 2002 (NIO), а фреймворки Netty 2004, Jetty 2006. Звичайно, якщо сайт візитка на 1.5 користувачів, то перфомансом можна не паритись.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 15:00

цікаво, ніколи не чув щоб в Java таким користувалися, знаю що Spring точно працює саме як я вказав, що один запит це один окремий потік

Oleksii Nedashkivskyi

Oleksii Nedashkivskyi AI/ML Tech Lead 16.10.2024 15:07

Одну й ту саму функціональність можна порізному зробити. З приводу Spring, цитата : docs.spring.io/...eference/web/webflux.html “It is fully non-blocking, supports Reactive Streams back pressure, and runs on such servers as Netty, Undertow, and Servlet containers.”

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 15:24

ага, дякую, не знав що Java і так вміє

Oleksii Nedashkivskyi

Serhii D Software Developer 18.10.2024 00:23

в java 21 зарелізили віртуальні потоки, це ті самі корутини, але вони мають такий самий інтерфейс як стандартні потоки, тобто буквально весь написаний блокуючий код може перейти на віртуальні потоки і стати фактично асинхронним, і не треба взагалі ніяких async await, чи then та catch

Pavlo Vuiko

Vic Programmer 17.10.2024 23:30

Якщо брати JEE — Jakarta EE — то специфікація Java Servlet 3.0 — від December 2009. Тобто в один рік з виходом першої Node.

що тут конкретно для вашої задачі Java краще підходила із самого початку

А написати повністю асинхронні сокети — можна було вже в Java 1.4 з коробки. Що паравда NIO — перший по факту працював по декуди ще гірше за синхронні сокети (по факту через проблеми моделі пам’яті самої Java та використання через це усіма трюка із недокументованим sun.misk.Unsafe коли його прибрали в Java 9 це зломало величезну кількість бібліотек), тому зробили Netty та з рештою Nio2
Щодо файберів, як власне і пулів потоків відтермінованих контіюейшенів, паралельний виконань, потоко специфічних змінних і т.д. — то в Java це усе є звісно і давно.
2. IMHO — в обох випадках то було політичне рішення, SA на стороні замовника не схотів навіть розбиратись в чому проблема по суті. В дргому випадку він же був одночасто і продуктом за сумісністю. Так само був випадок коли продукт був колишнім фронтенером до цього і ганяв різних вендорів усе що було не на Node — переписувати на Node. Тобто в цьому і була проблема — треба писати і фіксити проблеми так швидко, щоб менеджмент та замовники не кликали сторонніх людей з’ясовувати в чому проблема. І тут місце технології — не останнє.
А ще краще бути лицем яке приймає рішення — тобто, хто контролює ресурси. Бо там як ти скажеш — так і буде.

Pavlo Vuiko

Dmitriy Mozgovoy JavaScript / NodeJS Developer 15.10.2024 17:08

Так само проблеми з безпекою, традиційна біда чистих інтерпретаторів і т.д.

І хто з них там «чистий інтерпретатор» і які це «проблеми з безпекою»? Це мови з прямим управлінням пам’яттю безпечніші чи в чому та безпека?

Vic

Vic Programmer 16.10.2024 01:45

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

Serhii D Software Developer 18.10.2024 00:26

це ти про eval() ?

Vic

Vic Programmer 18.10.2024 02:44

Це загальна проблема інтерпретаторів. В старому PHP там до елементарного доходило, коли в коді новачка можна було в стоці пароля ввести || == 1. Ну тобто так звана простота входу в мову має і свої недоліки.
Станом на зараз вважається, що повністю безпечних інтерпретаторів на стороні сервера бути не може.
З іншого боку коли пристрій програмується, тобто здатний виконувати програмний код, а не жорстку логіку — то завжди є можливість знайти бекдор і виконати той код який треба. Тобто завжди треба робити відповідне тестування, позаяк ми назагал використовуєм науковий метод у розробці.
Щодо Node, то там проблем є www.google.com/...lient=mobile-gws-wiz-serp в цілому типово для будь якого бекенду.

Serhii D

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 01:58

Це загальна проблема інтерпретаторів

Це якісь фантазії яким років 20. Ніхто не користується функціями генерації коду в рантаймі, тим більше не на бекенді і не для обробки користувацького вводу чи як ви там це собі уявляйте щоб туди щось можна було заінжектити. Якщо десь воно залишилось, то для метапрограмування в якихось нішевих бібліотеках. В мовах з ручним управлінням пам’яттю набагато більше потенційних дірок які дозволять виконати RCE через криву роботу з нею.

Vic

Олександр Шпак Oarsman в Self Employed 19.10.2024 11:36

Це якісь фантазії яким років 20. Ніхто не користується функціями генерації коду в рантаймі, тим більше не на бекенді і не для обробки користувацького вводу чи як ви там це собі уявляйте щоб туди щось можна було заінжектити.

Остання zero-day вразливість Firefox була в ... CSS (CVE-2024-9936: Undefined behavior in selection node cache). З можливістю виконувати будь-який код на стороні клієнта. Вразливість була через особливості C++ та роботі компілятора. А ви кажете проблема надумана...
А самий сік був з вразливістю фавіконок в Chrome, коли можна було виконувати код в root-space браузера.

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 16:18

Вразливість була через особливості C++ та роботі компілятора.

І яке це має відношення до JS там проблемність інтерпретаторів?

А ви кажете проблема надумана...

Хіба С++ це інтерпретатор? Я кажу що мови з прямими інструкціями та ручним управлінням пам’яттю потенційно біль вразливі, чим з VM і GC, бо ще більше векторів атаки з можливістю підсунути код на виконання через баги розробника. В JS його ніяк не підсунути без інджекта в eval чи new Function, то ж він більш безпечніший.

Олександр Шпак Oarsman в Self Employed 19.10.2024 18:28

І яке це має відношення до JS там проблемність інтерпретаторів?

Інтерпретатор написаний на чомусь?

Хіба С++ це інтерпретатор?

Ні, але на ньому написано інтерпретатор. Вразливість з CSS — це прямо суперяскравий приклад. Сутність там така, шляхом створення певної послідовності декларацій та помилки, яку допустили розробники в коді процессора CSS, можливий виклик стороннього коду через невидаленний вказівник. Так, CSS не імперативна мова програмування, а декларативна. Але її треба якось інтерпретувати та перетворити на результат. Помилка була не в самому інтерпретаторі, як він це все обробляє, а в похідному коді інтерпретатора, як воно організовано на рівень нижче та було потім скомпільовано в бінарник. Ніякого eval там не відбувається, там все куди нижче по рівню.

Dmitriy Mozgovoy JavaScript / NodeJS Developer 19.10.2024 20:34

Інтерпретатор написаний на чомусь?

Так не на JS же. Чи будемо косяки на всіх рівнях аж до ОС, драйверів і мікрокоду ЦП записувати до проблеми інтерпретаторів?

Помилка була не в самому інтерпретаторі, як він це все обробляє, а в похідному коді інтерпретатора, як воно організовано на рівень нижче та було потім скомпільовано в бінарник. Ніякого eval там не відбувається, там все куди нижче по рівню.

Ну так чудово. Це рівень нижче, це не рівень мови і самої VM. Це проблема того що там наляпали на С++, про що і говорилось. Тут інтерпретатори не при чому. Будь які дані які приходять зовні можуть мати вразливість при обробці багнутим кодом, і в мовах з ручним управлянням пам’яттю криві вказівники, вихід за границі і не затерті дані часті причини, яких нема по дизайну в мовах з автоматичним виділенням пам’яті, автоініціалізацією і без реальних вказівників.

Bohdan Shulha Founder в MakeADir 15.10.2024 15:02

А в чому проблема йти на роботу за грошима? :)

Азаза Заазааз 15.10.2024 15:46

бо в нашому улюбленому трохи забагато інфантильному айті ком’юніті є відчуття власної елітарності, що це не для плебса. Що для того, щоб стати програмістом треба народитись програмістом. Залітати в сферу заради бабла це моветон, кажуть спеціалісти які за рік міняють по 5-6 компаній на +300$ :)

Bohdan Shulha

Vic Programmer 16.10.2024 02:55

Ви тут трохи перетнули. Та будьмо відверті — інженери теж соціальний прошарок в який потрапляють, бо не потрапили наприклад в фінансисти, юристи, урядовці і т.д. чи не зорганізували власний бізнес. «Для душі» пишуть PET проект, а для бабла — те за — що замовник платитиме і яка робота є на ринку, щоб в неї вкатитись, бо і конкуренція шалена. Та і в самому ІТ — теж усі поділяються на слої, є архітектори CTO та старші менеджери, є засновники та С level. І більшість з них — років з 10+ емігрувало за кордон, на релокейт. А є рядові гребці — які до пенсії будуть гести на чому їм начальство скаже і розгрібати чуже та своє лайно в коді, та конкурувати з молодими, щоб не лейофнули.

Oleg Antoshkiv Backend Developer в ELEKS 15.10.2024 16:00

Як колишній ентузіаст, вважаю, що мова програмування має подобатися саме тобі, і якщо ти будеш добре нею володіти — завжди знайдеш роботу. Не потрібно робити те, що тобі не подобається, бо швидко вигориш.
Моя суб’єктивна думка: для бекенду має бути статично типізована мова, бо на великому ентерпрайз проекті можна здуріти, намагаючись зрозуміти логіку роботи, без знання типів аргументів і результатів функцій.

Dmytro Bondarenko 15.10.2024 12:13

це як ганятись за біткоіном, коли усі інші вже встигли зняти вершки.

Melnyczenko Mel 15.10.2024 12:32

Так це про IT в цілому, а не тільки про PHP. Зараз джуни за першу роботу бʼються на ножах

Dmytro Bondarenko

Vic Programmer 15.10.2024 14:04

Це глобально, у цілому західному, тобто про американському ІТ — рецесія. Інвестори забрали гроші — та пішли в мілтеч повально. Були масові лейофи, включно із FAANG. Станом на зараз — американська економіка по усім показникам вийшла з крутого піке, не в останню чергу через оборонні замовлення та ажиотажний попит на зброю та боєприпаси на усій планеті. З покращенням ситуації в США та західній Європі, як бачимо і вакансій побільшало — бо українській ринок в край вузький. З власними продуктами — в нас і взагалі погано, їх дуже мало.

Азаза Заазааз 15.10.2024 15:50

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

Vic Programmer 16.10.2024 03:06

Знайдіть не те — що посаду ІТ-шника на заводі, знайдіть блін живий завод в якому ще є обладнання, а тим більше цифрове. Спробуйте влаштуватись інженером будь якої іншої спеціалізації. Коротше — це офтопік.

Азаза Заазааз 17.10.2024 12:57

Ну ти м’яко кажучи не компетентний в питаннях заводів в Україні, їх тут дуже багато, навіть з втраченим сходом, і кожен з них потребує інженерів з автоматизації, ті самі програмісти. І в тебе навіть вибір великий, іти на іноземне підприємство той же кромберг, рейнметаль, бат і їм подібні. Або на українські той же Візар, Антонов, група Богдан, МДФ, КЗОТ ще декілька сотень підприємств різних форм і направлень, і всюди треба інженери, багато інженерів, бо там сидять старі пердуни які побачивши ПЛК Siemens починають хреститись, бо там букви німецькі. Те саме з енергетикою, потрібні автоматизатори і на РЕСи, потрібні автоматизатори на облгази, водоканали всюди потрібні, і вся автоматизація пов’язана з тим щоб програмувати. А джуну яка різниця де він буде отримувати досвід, на якійсь галері за 600 баксів, чи на заводі за ті самі 600 баксів.

Vic

Andrew Levytskyi Full-stack developer в NDA 17.10.2024 23:54

Так, повністю згодний. PHP прекрасна мова, особливо з 8ї версії

Олександр Шпак Oarsman в Self Employed 18.10.2024 00:10

Не полінувався, пішов подивитися, що там нового в PHP8.

echo match (8.0) {
  '8.0' => "Oh no!",
  8.0 => "This is what I expected",
};

Це дуже крута конструкція. Без жартів. Хоча в JS можна намутити щось схоже, але це прямо дуже прикольно.

Це вже по класиці...

$country = $session?->user?->getAddress()?->country;

Нормально, розвивається мова.

Andrew Levytskyi

Ivan Havryshko Senior Software Engineer в TriNet 18.10.2024 07:41

Ще б дженеріків додали — була б джава на мінімалках :)

Олександр Шпак Oarsman в Self Employed 18.10.2024 08:43

ПоХаПє вже це має з народження ;)

юнит тест 18.10.2024 09:29

echo match (8.0)

хорошо что я спрыгнул с этого дерьма, снова эти игры с нестрогой типизацией, от нее куча проблем только, она еще была актуальна для говносайтов много лет назад, где в функцию что угодно можно было передавать и спокойно делать ’8.0′ + 8.0 или int(’8.0′) + 8.0

Олександр Мощенко 18.10.2024 09:44

так в прикладі ж навпаки строга.

php > var_dump('8.0' === 8.0);
bool(false)
php > var_dump(8 === 8.0);
bool(false)

юнит тест 18.10.2024 11:56

var_dump(8 == 7.9999999999999999118);
var_dump('8.0' == 8.0);
var_dump('8.0' == 8);

на все говорит bool(true) :D

Олександр Мощенко 18.10.2024 11:59

так не жалій `=`
ти ж сам явно кажеш «а порівняй їх як небуть і скажи чи рівні між собою»

Олександр Шпак Oarsman в Self Employed 18.10.2024 12:21

Не як небудь. Там порівняння йде відповідно то правил приведення типів. ;) Вивчити їх не складає ніяких проблем. Той, хто навчився використовувати приведення типів на свою користь, той назавжди буде страждати в інших мовах програмування, де є строга типізація.

Олександр Мощенко 18.10.2024 12:28

ну під «як небуть» я й мав на увазі «порівняй там як сам знаєш».
правила приведення можуть бути місцями неочевидні вапщє і навіть не здогадуєшся, що треба звіритися з документацією.

мені запам’ятався випадок коли я ділив ціле і очікував нормальний float, ну бо це, здавалося б, логічно. А насправді не так. І хоч воно і написано в документації, але ж часто такі «очевидні» речі пропускаєш. А тоді думаєш «чому моя синусоїда звучить як хто зна шо??».

a77@wrk:~> python2 -c 'print 8/3'
2
a77@wrk:~> python3 -c 'print(8/3)'
2.6666666666666665

Олександр Шпак Oarsman в Self Employed 18.10.2024 16:03

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

Треба намагатися не правила запамʼятовувати, а логіку, на яку спиралися розробники під час створення цих правил.
Хоча повністю підтримую, що приклад, наведенний вище не очевидний від слова зовсім. Але ж це пітоніо... там своя атмосфера..

Олександр Мощенко 18.10.2024 16:35

«грати синусоїду» я в жабі намагався, на андроїді. там жет int/int = int.
Приклад на пітоні навів бо не осилив швиденько jshell поставити (

Serhii D Software Developer 18.10.2024 19:09

це не тільки python, багато мов саме так і поводяться, починаючи від c і до java

Олександр Шпак Oarsman в Self Employed 18.10.2024 11:16

снова эти игры с нестрогой типизацией, от нее куча проблем только

Немає проблем з нестрогою типізацією, є проблема з програмістами, які не змогли знайти переваги такого підходу. ;)

юнит тест 18.10.2024 11:42

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

Олександр Шпак Oarsman в Self Employed 18.10.2024 12:30

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

Булшиту немає. Є доволі прості алгоритми, як це розрулювати. Атомік типи в JS зберігаються без обʼєктів обгорток над ними, тобто в таблиці змінних буде те саме лежати, що й в якійсь джаві — тип та пойнтер на значення десь в памʼяті. Коли треба трохи «магії», наприклад "abc".length, тоді вже динамічно створюється обгортка для виклику методу класу певного типу, який знає, що йому робити з атомік значенням. Але навіть тут можна трохи зхитрувати та зробити клас String сінглтоном (хоча не факт, що це забустить перформанс).

Konstantin Strukov 18.10.2024 13:47

Код в мовах з нестрогою типізацією писати набагато швидше та він локанічніший

Можливо. Але власне написати код — це мізерна частина його (коду) життєвого циклу, я не дуже розумію в чому кайф зекономити мізер часу на початку завдяки магічним приведенням типів та лаконічності, щоб потім роками дебажити та фіксити те щастячко.

Олександр Шпак Oarsman в Self Employed 18.10.2024 18:49

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

Цей стереотип виникає в основному через те, що люди, які роками тренували мозок мислити категоріями строгої типізації, намагаються приміняти аналогічні патерни в розробці до абсолютно іншої парадигми програмування. В них, звісно ж, нічого не виходить та вони страждають.

Що Java, що C# змушують думати категоріями структур даних, класами. А в JavaScript це скоріше недетермінований потік даних. Перше ж бажання джавіста чи сішарпника — будь який недетермінований потік даних треба привести до строго детермінованого, бо так простіше. Але недетерміновані потоки даних так не обробляються. Це простіше робити в функціональному стилі, набором функцій-обробників приводити до потрібного результату.

Коли ти розумієш різницю між підходами, то твої функції мають іншу структуру, вони більш універсальні та зазвичай параметри можуть бути перевантаженими. Також сильно рятують fail safe та fault tolerant підходи, коли помилка є частиною нормально потоку виконання, а не виключенням.

Коли ми просумуємо всі ці підходи, то виявиться, що архітектурно проект мусить будуватися по абсолютно іншій схемі. Структура функцій та методів теж мусить бути трохи відозміненою, та зазвичай вона складається з наступних кроків:

Визначення станів, які фукнція не може обробити. Наприклад, null є нормальним значенням, а от undefined вже ні.
Вихід, якщо вхідні параметри не підходять. Якщо використовується chaining, то повертаються вхідні параметри
Приведення типів до інших, наприклад, атомік значення можуть конвертуватися в масив, щоб потім пройтися в циклі
Робота з відомими типами даних
Повернення результату

При такому підході функція стає «бінарною» по роботі, вона або щось робить, або не робить. Для розширення кількості типів даних, які підтримує функція, треба просто їх додати в кроки приведення типів, або просто описати, що робити з новим типом даних.

Тут все впирається в те, якими категоріями мислить розробник.

Konstantin Strukov

Serhii D Software Developer 18.10.2024 19:29

Писати такий брєд з таким розумним виглядом ще треба постаратися.

Просто дозволь усім функціям приймати все що завгодно, і в кожній такій функції перевіряй, чи значення null, чи взагалі це те, що потрібно, чи це скаляр, чи вектор. Оскільки кожна функція приймає що завгодно, результати можуть бути різними, і їх також доведеться додатково обробляти.

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

Це ще є не говорю, що функціональне підхід ніяк не повʼязаний з тим чи є типи чи нема.

Олександр Шпак Oarsman в Self Employed 18.10.2024 21:38

Писати такий брєд з таким розумним виглядом ще треба постаратися.

Зазвичай людям, які щось не розуміють, слова інших людей будуть завжди здаватися маячнею. Завжди. Так влаштована наша фізіологія та робота мозку.

Просто дозволь усім функціям приймати все що завгодно

Хто сказав всім? Але відкинемо це уточнення. Так, давайте дозволимо. Ви хоч раз будували продукт, який базується на такій архітектурі? Я впевнений, що ні. Тому для вас це звучить як дичина, як щось антинатуральне, проти всіх канонів. Але, спробуйте написати хоч раз в якості експерименту такий код. Я впевнений, що тоді ваше життя вже не буде таким, як раніше.

Оскільки кожна функція приймає що завгодно, результати можуть бути різними, і їх також доведеться додатково обробляти.

А в чому тут проблема? У вас є функції f4(f3(f2(f2()))), що краще записати як f1() > f2() > f3() > f4(), тобто ланцюг. Всі функції мають однаковий вхідний інтерфейс, вони в якості параметрів можуть приймати одну й ту саму структуру даних. На виході можуть повертати модифікований результат. Якщо ви побудуєте таку архітектуру, то ви зможете вільно переставляти функції в ланцюгу, не переймаючися тим, зламається щось чи ні. Так, результат буде різним, але тут вже залежить від задачі. Думаєте я це вигадав та це моя власна ідеологія? Ні, їй вже років за 50 точно. Це так званий *nix way, коли ти маєш багато утиліт, які повʼязані між собою однаковим API, з яких ти можеш швидко побудувати щось більш функціональне шляхом поєднання в ланцюг спеціалізованих утиліт.

Замість того, щоб перевірити один раз дані на валідність і консистентність

Валідність можна перевірити тільки по типу, але не по значенню. Консистентність даних важлива тільки на момент роботи з нею. Ви намагаєтеся все стандартизувати та описати в статичних структурах даних, це ваш тип мислення, навʼязаний мовою програмування. В реальному житті взагалі немає таких вимог, щоб все було обовʼязково каталогізовано, структуровано, організовано. Простий приклад, який я навожу постійно — задача з годуванням кота. В реальному світі дуже рідко кота годують. Він автономний та їсть сам. З іншими субʼєктами комунікує через систему сигналів. В різний випадках сигнали різні.

Це ще є не говорю, що функціональне підхід ніяк не повʼязаний з тим чи є типи чи нема.

Ви що саме вкладаєте в термін «функціональний підхід»?

Serhii D

Serhii D Software Developer 18.10.2024 13:50

Писати може і швидше, тільки він одноразовий виходить. Про лаконічність тема не дуже розкрита.

Олександр Шпак Oarsman в Self Employed 18.10.2024 18:50

Багаторазовий, якщо перестати з JS робити Java

Serhii D

юнит тест 18.10.2024 19:29

тип та пойнтер на значення десь в памʼяті.

ну правильно, чтоб не передавать значение по стеку или в регистре (интегер) мы загружаем работой GC и поинтерами на кучу, потом неудивительно что в джаве GC молотит CPU как бешеный

Олександр Шпак Oarsman в Self Employed 18.10.2024 21:39

Мова була про JS

Serhii D Software Developer 18.10.2024 19:32

Атомік типи в JS зберігаються без обʼєктів обгорток над ними

В джаві скалярні значення також лежать в стеку без всяких обгорток.

Andrii Sevastianov 18.10.2024 13:07

Поэтому шахматный движок писать на PHP не надо. А в реале если за этим идёт SQL запрос к базе, то... какая разница? Тут вопрос удобства.

Юрий Левин Software Engineer 18.10.2024 13:25

Фіг з ним з Go, якому вже без малого 15 років, а Ruby то хоч що тут робить? Діду, ти коли на останній раз з галери на сушу ходив?

no name three 18.10.2024 16:48

Ну Го 15 років, але він стрільнув не одразу, і його (в нас як мінімум) використовуть якщо треба прям перформанс видати, але так нішево.

Ruby «помирає» вже 10 років, але по факту він теж став нішевим. В Україні 2% ринку. наче, дійсно непопулярний, але по світу нормально все з ним. Років 10 тому падала його доля, але після цього стабілізувався, і не думаю що кудись дінеться у наступні 10 років.

Я думаю якщо core каманди ruby i ruby on rails підуть у FIRE , і ніхто не підхопить адекватно, тоді буде хана.

Нічого поганого в нішевих мовах немає. І взагалі інженер (особливо бекенд) має знати декілька мов як на мене. Хоча б для кращого розуміння підходів і плюсів/мінусів різних мов

Юрий Левин

Misha Losyk Node.js Developer в Relevant Software 15.10.2024 11:33

Все залежить від критеріїв, за якими ви обиратимете. Якби я був на вашому місці, моїми пріоритетами були б (в порядку важливості):
1. Попит на локальному ринку праці. Можливість отримати роботу через півроку чи рік. Можна на Djinni подивитися коефіцієнти: скільки відправлено відгуків/отримано пропозицій etc.
2. Глобальний тренд. Наскільки популярна технологія чи мова, чи активно вона розвивається, відгуки в спільноті.
3. Особисті вподобання щодо мови.

Які мови/технології я б не розглядав:
• Нішеві або ті, що ще не закріпилися на ринку.
• Технології, які здебільшого обслуговують легасі проєкти, і на яких рідко починають нові.

Якщо конкретизувати, то, напевно, варто звернути увагу на: C#, Go, Node.js/TS, Python.

Sviatoslav Ronskyi Tech Lead в Yael Acceptic 15.10.2024 11:33

Я б радив спочатку задуматися на доменом, а потім мовою. Коли зрозумієте що саме Ви хочете писати, список мов може скоротитися.

Dmitry O 10.11.2024 03:35

Можливо, авторові на даному етапі байдуже, який там буде домен.
А ось мені, з багаторічним досвідом, саме це вже стало дуже важливо.

Sviatoslav Ronskyi

Dmytro Bondarenko 15.10.2024 11:25

Будь яка, окрім Java/Python/Go/Swift/objC/PHP

Andrii Simakov TL/BSE 15.10.2024 11:54

Чувак, це не Mezha, ти помилився ресурсом.

Dmytro Bondarenko

Dmytro Bondarenko 15.10.2024 11:58

Я тобі не чувак, сонце. І ні, це ти помилився.

Andrii Simakov

Andrii Simakov TL/BSE 15.10.2024 11:58

Після лайна на Межі ти ніхто взагалі.

Dmytro Bondarenko

Dmytro Bondarenko 15.10.2024 12:01

Не ний, чувааак.
Розкажи, краще, як там курси? Роботу вже знайшов? Подобаєцца те, чим займаєшся?
«Нравіцца, не нравіцца....» <3 ;)

Andrii Simakov

Anton Front-end Developer 15.10.2024 11:23

Та мова, за яку добре платять і роботу знайти не важко.
Сьогодні це PHP, JS, Python, C#, Java, Go (в порядку популярності).
Ну так так і подобатись вона вам повинна, цікаво повинно бути. Хоча, чому вона повинна подобатись, вона ж не ваша дівчина? Але не від мови все залежить. А від рук і досвіду. Бо робота програміста — це не 100% написання коду. Та і взагалі, з часом розумієш, чим менше коду пишеш, тим краще для усіх. Роботодавцю в кінцевому підсумку начхати на мову, аби гроші приносило і менше паритись треба було, і пошвидше можна було фічі імплементувати, людей в команду знайти.

переходьте на фронт-енд, там таких питань не виникає)
хоча ні, там будемо розводити холі вар за фреймворки.

Азаза Заазааз 15.10.2024 12:46

Так там всього три штуки, реакт який всюди, vue який класний, ну і ангуляр як бідний родич.

Anton

Melnyczenko Mel 15.10.2024 12:54

І Svelte, про який кричать на кожному форумі, тільки в реальних проектах він на*уй нікому не треба 😆

Slavik Savko 15.10.2024 11:18

Зайшов щоб почитати срач де кожен відстоює свій крутий і неповторний стек. Але ніт. З цим закидоном такого не буде
Це ж треба у 2024му році таке — «Аналізувати не хочу, читати лінь...» Але що швидко вивчити і щоб одразу хоп та дали роботу.

Бартоломео Россі 16.10.2024 03:58

Покоління тіктоків і TL;DRів, шож

Олександр Мощенко 16.10.2024 09:19

покоління тлдрів і тіктоків це два різних покоління.

Бартоломео Россі

Бартоломео Россі 16.10.2024 09:25

Чи таких різних?

Олександр Мощенко 16.10.2024 10:02

тлдр — про блоги.
А коли масово прийшов тікток про блоги вже забули.
імхо, звісно ж.

Бартоломео Россі

Alex Tcy 16.10.2024 18:44

Вас багато, кожен щось та скаде стосовно свого досвіду. І вже це можно проаналізувати і зробити якісь висновки ))

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 10:35

Якщо відповідати більш-менш об’єктивно, то тут в залежності яка мова вам більше подобається, тому було б краще кожне з них по-троху спробувати, не існує найкращої мови, у кожної є свої плюси і мінуси, десь їх більше, десь менше. Якщо вподобання на даний момент не дуже принципові, то можна банально глянути на яку мову більше вакансій і рейтинг ЗП. У Node.js наприклад найбільше вакансій і досить високі рейти ЗП. Також по ідеї не помилитеся, якщо оберете Go чи C#

Trip Trip 15.10.2024 11:06

Також по ідеї не помилитеся, якщо оберете Go чи C#, все рівно всюди жопа.

/fxd
Ех, а були часи в 2021 коли у джави та с# по 450+ вакансій було, тоді ще обговорювали «зайчиків» які на 2-3 галери одразу працювали=)

Pavlo Vuiko

Валентин Коваль JS Developer в LeanSquad 15.10.2024 10:28

Коли я навчався в університеті на 1 курсі то казали, шо Visual Basic 6.
На 2 курсі, сказали, шо то всьо фігня і самий крутий С++.
На 3 і 4 курсі, виявилося, шо нас обманули знову і бестОфЗеБест це С# + Asp.Net
А на Магістратурі, вже казали шо світ змінився і треба все забуть, шо ми вчили раніше та постігать дзен у JavaScript.

Я б сказав, шо краще, але ми так до бекенду і не дішли)

Пропоную Вам Пітон. Хлопці з Джинні навалювали, шо воно бествей.

Dmytro Bondarenko 15.10.2024 12:11

Часи ідуть, а плюсовики як отримували багато грошей, так і продовжують отримувати :)
Що у часи vb6, що сьогодні.

Валентин Коваль

Alex Perchatochnikov Zultys Inc 30.10.2024 17:47

Так C++ и сегодня так самый крутой.

Валентин Коваль

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 09:50

Все залежить від того, що ви хочете робити.

Якщо йти в галеру/велику компанію на 100500 людей — то Java/Python/Go/.NET/<що завгодно, адже різного легасі на чому завгодно вистачить ще на 100 років>.

Якщо вам потрібен драйв і двіж, то 100% TypeScript, адже нікому не потрібні чисто бекендери, яких кожен раз повинні підтримувати фронтендери. Тож треба хоча б трохи розумітись на UI, і тут TS дуже впевнено перемагає.

Pavlo Vuiko Senior Node.js Engineer в EPAM 15.10.2024 10:43

Я не погоджуюся з вами, що чисті бекендери нікому не потрібні, точніше якщо говорити про суто бекенд, то тут треба ще знати Cloud та DevOps, а не лише як код самої апки писати. На фулл-стеків наче дійсно більше вакансій, але ЗП менші ніж у «чистих бекендерів з клаудом»

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 10:51

джун девопс на клауді це дуже дорого :)))

Pavlo Vuiko

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 11:55

Людина шукає перший досвід, а ви їй закидаєте скіли, яких вона без нормального робочого середовища ніколи не навчиться. Ніхто ‘мамчиного девопса’ нікуди не візьме без комерційного досвіду. Ну і навіть у DevOps той же CDK на TypeScript працює дуже непогано, якщо не заморочуватися ‘vendor lock-in’ та іншим непотрібом

Pavlo Vuiko

Роман 16.10.2024 03:25

> треба ще знати Cloud та DevOps

на рівні девелоперу знати всяку оркестрацію контейнеризацію щоб могти в цій екосистемі варитись, докерфайли там писати, маніфести куберівські, знати як подебажити в кубері свої косяки якщо на енв є доступ і т.п. це ну ніяк не той девопс що ви прямо фуллстак дев + девопс

Поклацати трохи якісь клауд ГУІ для дебагу/драфту, але в іншому швидше досвід роботи з SDK всяких сервісів того клауду теж досить наживне й навряд чи зробить супер погоду.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 16.10.2024 11:36

Трохи більше) сучасному бекенд розробнику, або як вже часто кажуть Cloud Інженеру треба вміти розгорнути свою апку в інфраструктурі, налаштувати CI, а може і CD, а також розбиратися в налаштуваннях і нюансах Клауд Сервісів, а не просто SDK користуватися. Це звісно не повна заміна бекендерів і девопсів в одній людині, але суть, що бекендер не повинен бути безпомічним без допомоги дяді девопса. Повертаючись ще до Full stack, то це дійсно один з варіантів розвитку, але не єдиний

Роман

Taras Terletsky Python Backend Engineer в SoftServe 18.10.2024 14:17

Backend Engineer та Cloud Engineer різні типи професій. Як DevOps та CloudOps.

Pavlo Vuiko

Pavlo Vuiko Senior Node.js Engineer в EPAM 18.10.2024 19:29

я б сказав, що Cloud Engineer це наступна стадія еволюції Backend Engineer

Сергій Цимбалюк 15.10.2024 09:31

лінь читати

А вчити цю мову як збираєтесь?
Зараз вам якусь аудіокнигу по Хаскелю пошукаю...

Andrey Tkachenko Підкорювач API в MacPaw 15.10.2024 09:30

Якщо коротко та лінь читати — яка на данний момент найкраща мова програмування для Backend-у, така щоб не супер тяжка у вивченні, але й щоб можна було знайти роботу?

PHP / Laravel і будете при $

все інше від сатани)
lets go...

Сергій Цимбалюк 15.10.2024 09:34

PHP

при $

З яких це пір за PHP почали платити?

Andrey Tkachenko

Melnyczenko Mel 15.10.2024 11:33

Якщо вірити статистиці доу, то медіана для сеньор php — 4200. На джинні прямо зараз є 100+ вакансій PHP із зарплатою 4+. Так це зараз просіли, бо війна + криза

до війни знайти вакансію на PHP Senior і зп 5+ було на ізі

Азаза Заазааз 15.10.2024 12:50

З PHP працюють по іншому, так ти можеш влаштуватись на галеру там на 3-4к, але ж прикол пхп в тому, що викладуєш на OLX шось тіпа робимо сайти під ключ, знаходиш дядька Степана якому на сто треба класний сайт-візитка, і береш за це тисяч 20 гривень, а ці шабашки можна клепати в будь-яких кількостях аби клієнтів знайшов.

Melnyczenko Mel 15.10.2024 12:56

Та фу, сайти-візитки дядькам Степанам клепати — це не про PHP, це вже рівень Вордпресу (так, я знаю що він на PHP), Мадженти, Друпала, та іншого шлаку. В таких конторах (їх пафосно називають «Веб-студія») зазвичай зарплати плюс-мінус 1к

А, ну і це вже Full-Stack, на чистому бекенді навіть сайт-візитку не склепаєш)

Азаза Заазааз 15.10.2024 13:15

Ніхто не заставляє тебе іти в контору, зроби свою.

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 13:31

І витрачай 90% часу на пошук дядька Степана, а не на код :)

Азаза Заазааз 15.10.2024 13:33

Так на галері ти 90% витрачаєш на те щоб пошту почитати і з різними людьми в міти побалакати, там теж код не пишеш.

Vsevolod Lobko Problem Solver (if you don't have problems yet, it's easy to fix) 15.10.2024 13:35

І незалежно від ефективності цієї ‘діяльності’ отримаєш свої 3 копійчини, а дядько Степан сам не знайдеться і копійчин не заплатить :) Тому це дуже різні ситуації :)

Karina Kosenko PHP developer в IT Craft 15.10.2024 14:12

Але на галері ці активності оплачуються))