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

Пройшов на 3 кінцівки, особисто мені не траплялися прям критичні баги, чи софт локи, що доводилося б фіксити модами, найнеприємніша було це застрягання NPC у вхідних дверях у хаб, що доводилося оббігати, також спавн NPC там де вони не повинні це робити, ну і ще фрізи і шейдери дещо підбішували. На 4-ту кінцівку планую перепроходити з самого початку, поки зробив паузу, бо треба роботу робити) ну і хочу спершу дочекатися хоча б анонсу що собою будуть являти DLC, чи це продовження сюжету, чи це якісь великі сайдквести, додаткові закінчення чи може ще щось. Ну і дійсно хотілось би пограти у ту версію гри куди повернуть вирізаний контент)

Так, знаю що uWebSockets.js вміє робити кластер на воркер тредах, до речі тепер він це вміє робити і на MacOS, не впевнений щодо Windows. Штука то прикольна з однієї сторони, а з іншої у нас та сама проблема що з node:cluster чи PM2, що у нас скейлинг всередині контейнеру, а не поза ним і те що у нас один тред який відповідає за лоад балансинг буде навантажений більше за інші треди.

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

Так, бачив ultimate-express, крута штука дійсно беквард компатібл з Express, навідміну від hyper-express, можливо вона дійсно зробить Express Great Again

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

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

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

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

Python дійсно нішевий) зі слів мого колеги Python інженера, ця мова програмування почала займати нішу PHP, тобто коли треба щось зробити дуже швидко і по шаблону, це якщо говорити про веб-розробку, також Python дуже погано скейлиться. Ви дійсно вважаєте, що переважна кількість коду вказаних компаній написана на Python?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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