Зараз багато зусиль спрямовано саме на корекцію помилок і спроби зробити ‘справжні’ кубіти з того, що є :))

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

Реально існуючі девайси від IBM, Google та інших реально мають близько 100 «noisy qubits» і вже багато років обіцяють тисячі кубітів, але через 10 років :))

У D-Wave понад 5000 «кубітів», але це зовсім інша технологія і зовсім інші підходи. Це фактично клітинки, які перерозподіляють енергію між собою за певними правилами, специфічними для конкретної задачі, і намагаються досягти оптимального для цієї задачі розподілу. Наприклад, розрахувати рівень чи швидкість потоку води на складному рельєфі, або опір матеріалів та подібні речі. З певної точки зору вони навіть більш корисні для реальних інженерних задач, але для криптографії їх використати дуже важко.

arxiv.org/abs/1706.06752
Quantum resource estimates for computing elliptic curve discrete logarithms

arxiv.org/pdf/quant-ph/0301141
Shor’s discrete logarithm quantum algorithm for elliptic curves

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

A 160 bit elliptic curve cryptographic key could be broken
on a quantum computer using around 1000 qubits while factoring the
security-wise equivalent 1024 bit RSA modulus would require about 2000
qubits

Коли в житті буває дуже погано, зазвичай це не від мови залежить :) І переписування на Spring допомагає не через Spring, а через саме переписування :) Тобто це можна було зробити і на TS, просто відразу за актуальними вимогами, а не намагатися виправити ‘ітеративно складений код’ :)

Ну і WASM, якщо хочеться хардкору... І писати можна хоч на C++.

V8 вже досить давно дуже близький до native performance на реальних задачах. А для ML/inference навіть у браузерах вже є ONNX з нативною підтримкою GPU.

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

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

І незалежно від ефективності цієї ‘діяльності’ отримаєш свої 3 копійчини, а дядько Степан сам не знайдеться і копійчин не заплатить :) Тому це дуже різні ситуації :)

І витрачай 90% часу на пошук дядька Степана, а не на код :)

Microsoft зараз вкладається в TypeScript чи не більше, ніж у .NET

Людина шукає перший досвід, а ви їй закидаєте скіли, яких вона без нормального робочого середовища ніколи не навчиться. Ніхто ‘мамчиного девопса’ нікуди не візьме без комерційного досвіду. Ну і навіть у DevOps той же CDK на TypeScript працює дуже непогано, якщо не заморочуватися ‘vendor lock-in’ та іншим непотрібом

джун девопс на клауді це дуже дорого :)))

Все залежить від того, що ви хочете робити.

Якщо йти в галеру/велику компанію на 100500 людей — то Java/Python/Go/.NET/<що завгодно, адже різного легасі на чому завгодно вистачить ще на 100 років>.

Якщо вам потрібен драйв і двіж, то 100% TypeScript, адже нікому не потрібні чисто бекендери, яких кожен раз повинні підтримувати фронтендери. Тож треба хоча б трохи розумітись на UI, і тут TS дуже впевнено перемагає.

В чому ця різниця? :)) Бойлерплейту у human-to-human навіть більше, ніж в коді :)

Ваш код, написаний в IDE, на 90% складається з символів автокомпліту...

Ну, тому що «просто генеріки», коли все інше яскраво anti-OOP’шне, не дуже допоможуть :)

Це все запланована диверсія :))

They do not eat gophers, so we are ok :)

10 товарів, які ви будете міняти самі, можна і в код захардкодити JSON-файликом :)

Для 10 позицій — беріть те, на чому вам швидше працювати :) Коли перший чемодан грошей заробите — переробите краще