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

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

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

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

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

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

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

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

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

екомерсу більше беруть пхп і правильно роблять

чому?

Додали типізацію і купу синтаксичного цукру

Обережно з цукром, від нього діабет буває

Кілька запитів в базу — хз, не вивчав питання, але кілька паралельних HTTP запитів — можна, юзав буквально нещодавно

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

стільки, скільки отримають офер. А скільки достойних з

243

ви погано прочитали мй комент, перечетайте ще раз.

дякую, що не мікросервіси

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

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

Laravel + InertiaJS + Vue

Співчуваю, коли стукне рочків 5 проекту, напишіть, будь ласка, як у вас справи.

Якщо у вас є невелика команда, то щось краще, ніж Laravel + InertiaJS (/ LiveWire), сьогодні вкрай складно знайти, якщо не брати до уваги Rails + Hotwire.

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

я вам пропоную уважно вивчати інформацию, тоді не доведеться зайви раз погоджуватись)

Особливо ту інформацию на яку ви посилаєтесь!

UPD. а, таки нє, знайшов отакий список: github.com/...​o?tab=readme-ov-file#json

Якщо подивитись цей список, то можна переконатися в тому, що це пакети які додають додаткову функціональність, ми жеж в ІТ всі знайомі з англійською, так?

Я не є професіоналом в nodejs, я з ним мало стикався, але коли робив дослідження на що вартує перейти з пихі, то nodejs був кандидатом, який відпав.

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

декілька місяців мігрував

Я мігрував декілька сервісів версії го зразка 2018 до 2023 за пару днів, можу помилятися, але мені здається, що моя технологія ну трохи більше зекономила грошей замовнику ніж ваша)

Якщо ліба реалізує цей PSR — її можна взяти, і легко замінити

Ви погано знайомі з принципом інтерфейсів в го)

Наскільки мені відомо, там навіть щоб JSON розпарсити

Дуже погано відомо)

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

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

P.S. а гроші на ПЖ можна і просто так скинути

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

Я зіштовкхнувся з цією проблемою на пхп у 2015-2016. У 2018 я вже позбувся пхп

2016 — це php 7.1. Між 7.1 та сучасним 8.3 величезна різниця. І laravel за ці роки дуже еволюціонував

От в цьому і річ, тепер я хочу подивитися як ви підтягнете версію 2016-2018 року до сучасної. ПС я згадував, що чим довше це відкладати тим проблемніше це буде, але я впевнений трохи більше ніж повністтю, що існуєть пректи, які продовжують розробляти на старих версіях.

Маячня. Проект на якому я працюю зародився менше 5 років тому. І саме на ларавелі. Зараз успішно заробляєм кілодоллари, при тому що в команді всього 4 девелопера

Що саме маячня? Яким боком мій комент не відповідає 2-3 роки уже були profitable? Якщо в проекті великі інвестиції і люди чекають девідентів і вихід на IPO, то це може тривати і 10 років і більше, яле якщо бізнес працює, то за 5 років він точно не закриється лише тому що став profitable, а буде і надалі розвиватися

4 девелопера

Я бачив проет, який живе 5 років на fierbase, має 3 лями користувачів і від початку до сьогоднішного дня його сапортила 1 людина, що далі? Як ваш випадок вирішує Backward compatibility? Здається коментар про

2016 — це php 7.1. Між 7.1 та сучасним 8.3 величезна різниця.

Лише підтверджує мої слова.
Я зараз працюю на проекті якому 8 років, тут близько 50 сервісів, всі вони мають актуально версію мови Go, хоча деяким сервісам вже більше 5 років

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

нагадую за

Якщо ви мені скините посилання де я сказав, що всім треба переходити на Go, то за кожне таке посилання я скидаю 10к на ПЖ, якщо ви такого не знайдете, то скидає ви 100к на ПЖ, домовились?

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

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

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

ПС Чекаю посилання на квітанцію оплати в ПЖ, або місця де я вказав, що всим треба переходити на го.

якщо ваш підхід

і через 2 максимум 3 роки звалити з проекту/злити клієнта

то повністю погоджуюсь

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

1. Є офіційні рекомендації і є паради. Якщо ви берете Symfony, отримуєте відповідні рекомендації хорошої практики, якщо Laravel то mvc і eloquent, з можливими порадами хорошої практики. Якщо до мене на співбесіду приходить людина то я очікую що як минимум офіційні рекомендації вона знає, поради — опціонально, і якщо особливого вибору у вас не має, то парадам доведеться навчити самостійно.

2. Якщо ви мені скините посилання де я сказав, що всім треба переходити на Go, то за кожне таке посилання я скидаю 10к на ПЖ, якщо ви такого не знайдете, то скидає ви 100к на ПЖ, домовились?

пиха і рубі це мови одного цільового призначення — сервер, більше, здебільшого, на них нічого не роблять. Python, C# - чудові мови багатоцільового вжитку, js — не чудова мова багатоцільового вжитку.

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

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

З бібліотеками в го теж мяко кажучи не дуже теж

купа бібліотек в го від китайців

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

субективно для MVP SaaS-чику де якісь там данні/формочки/білінг і біз логіка GoLang в його стані зараз не дуже вибір

імхо, робити повноцінний моноліт — це не дуже для реального MVP, про що я вже згадував, але ну камон, ви будете в через 2-3 роки переписувати моноліт? Лоу код рішення, так, я буду переносити на моноліт, коли все стабілізується по функціоналу

Ок винесемо через 2-3 роки щось повільне в окремий сервіс на іншій мові(наприклад), але навіщо зайвий раз підвищувати гетерогенність?

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

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

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