Чи залишається .NET недооціненим у 2026 році?
Натрапила на Reddit на обговорення про те, чи залишається .NET недооціненим. Там пишуть, що екосистема зараз класна, але нові проєкти та стартапи все одно за звичкою тягнуть на Node або Python. Дотнет там нібито остаточно закріпився виключно як інструмент для великого ентерпрайзу. Плюс скаржаться, що деякі опенсорс бібліотеки зараз переходять на платні ліцензії.
Але у нас в розділі Робота по запиту .NET висить зараз 145 активних вакансій. Тобто на нашому ринку технологію явно не уникають і вона дуже навіть жива.
Цікаво послухати тих, хто зараз вариться в .NET. Розкажіть, над якими проєктами працюєте? Це переважно важкий ентерпрайз і аутсорс, чи все ж є свіжі продуктові історії?
86 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівЗакину непопулярное мнение: ASP.NET MVC убило будущее платформы .NET.
Microsoft всегда доминировала в закрытых экосистемах, умышленно усложненных для повышения порога входа и порога выхода. Эти экосистемы естественным образом изолировали себя от влияния open source, что повышало стоимость разработчиков и делала платформу более привлекательной для разрабочтиков.
ASP.NET Web Forms и ASP.NET AJAX (UpdatePanel) были отличными примерами: экосистемы полностью отличающимися от того как работали опен сорсные веб сервера и веб фреймворки, хрен пойми как работают внутри и снаружы, запутанные, сложно заставить работать в нетривиальных случаях. Несовместимые ни с чем другим и не портируемые никуда.
ASP.NET MVC все это убило. Во-первых, с открытым исходным кодом (все могли посмотреть и понять что там внутри ничего нет). На них легко перейти и с них так же легко спрыгнуть. Оно привлекло массу людей, котоыре сидят на опен сорсе и протягивают открыте стандарты, делают интеграцию с другими опенсорсными продуктами, вместо посторяния вертикальной закрытой экосистемы с платными библиотеками.
В итоге имеем что имеем, дотнетнчик ценится меньше чем питонист или гофер, а сама платформа вместо того чтоб выглядеть неприступным замком для избранных специалистов превратилась в один из двадцати фреймворков для разработки бекендов для SPA.
Джава та дотнет це в першу чергу моноліти в ентерпрайзах, там де ці платформу були найсильнішими, статична типізація та гарне ооп щоб писати тони абстракцій і бути кращим ніж мови із динамічною типізацією котрі просто жахливі в таком випадку, рантайм що спрощував роботу із памятью і надава перевагу над с++. тобто посередині — і доволі швидко без лоу левел хардкору і не совсім динамічно щоб тримати жорсткий контроль при дуже великій кількості абстракій.
Також рядом продавани завжди втюхували до моноліту апп і моноліт базу — з дохера проців, дуже швидку але дуже дорогу...
Тепер із мікросервісами+клауд із дуже легким горизонтальним скейлінгом можна клепати на пітон ноді купу апок і відносно невеличку базу із нею і через кубер та клауд скейлити то все, так треба трохи подумати не дупою про івеншуал консістенсі та сага...але тепер кожен джабо скриптер може писати ентерарпайз системи, ось тепер динамічність та простота дають можливість писати сервіс, переписати знову його, а джава та дотнет вже немають таких переваг, і тепер живуть за рахунок старих доживаючих монолітів которі переписують на клауд та мікросервіси.
Так технічно що джава що дотнет звісно дають можливість писати не одну велику купу моноліту а декілька маленьких але вже немає привязки до стеку, як це було раніше, різні відділи тепер можуть хоч на пхп писати свої сервіси чи на го, не потрібно купляти дорогущий скл сервер, он у монгу напхав і похер, чи в космос дб...усим пофіг.
Вообще UpdatePanel было с десяток, одну из них написал я сам. Самый известный из OpenSource назывался MagicAjax
Недооцінені не стільки .net, скільки .Net-чиці ;) Бо від них вимагають додатково знання Angular/React-у, клаудів, купи баз даних, девопсу, ШІ. І все це у під прикриттям «шукаємо .net дева»;)
Все так, вакансии правда не в стартапы
Для .NET довольно сложно найти именно remote вакансии worldwide.
А пам’ятаєте, як ви Delphi хейтили? От тепер не ображайтесь.
Цікаво що техлідом в обох проектів Delphi та C# є одна і та сама людина Аннерс Хайльсберг
он же и typescript дизайнил
вот наделал делов
Не те щоб особисто усе робив, окрім PolyPascal та Turbo Pascal — це усе таки головний архітектор розробок Сhief Architect PolySoftware потім Borland, а потім Microsoft. Що цікаво компілятори з Pascal, Аннерс написав прямо на асемблері — що звісно багато в чому заслуга самої мови розробленої так щоби можна було так робити як і розширення теорії з розробки мов програмування та компіляторів, тобто Ніклауса Вірта. Аннерс компонує ідеї професора вже десятиліттями дуже успішно комерційно. Ідеї закладені в : Pascal, Modula2 та Oberon проглядаються на протязі усіх лінійок продуктів.
У .net-а було кілька проблем:1-3
1. Відсутність кроссплатформенності
2. Закритість
3. Оверхед (не можна швидко почати розробку, треба створити солюшн, проект, і все описане в уродливих xml файлах які без IDE менеджити неможливо
4. Слабеньке опенсоурс комьюніті із-за
Тому народ використовував пітон, ноду, зараз тайпскрипт.
Майкрософт згодом це пофіксив в тій чи іншій мірі, і в тих задачах де зараз використовують той же тайпскрипт, дотнет/C# справився би не гірше, но, вже пізно. Індустрія зробила свій вибір і немає смислу світчитись — надто багато тулзів і надто велика екосистема щоб світчитись на відносно голий .net.
Тому пітон та нода взлетіли.
пітон взлетів тому що знайшов свою нішу і не конкурує з .net — вони використовуються для інших задач
нода взлетіла тому що дозволила армії фронт ендщикам писати бекенд, а потім сам же майкрософт з тайпскриптом взагалі легалізували її для серйозних задач
Звалив з цього тонучого корабля і не жалкую
Куди?
У Python/Go
Где вы видите недооцененность?
Google AI search:
Developer Usage: Approximately 25.2% of software developers worldwide use .NET (5+).
Enterprise Adoption: Over 30% of enterprise web applications globally are built using ASP.NET.
Web Presence: Around 34.2% of all websites and web apps run on the .NET framework.
Fortune 500: More than 55% of Fortune 500 companies rely on .NET for their software development
65% приложений, которые хостятся в Azure используют .NET полностью или в некоторых своих компонентах
Технологии 25 лет, живет, жива и еще столько же проживет легко
xD
А в aws/gcp скільки?)
В .NET просто ДУЖЕ погані маркетологи.
Він гарно оновляється, реально хороший перфоманс, заставляє писати якісний код, кросплатформенний.
Але стартапи виберуть повільніші Python / Node.js, бо вони більше на слуху.
І для більшості C#/.Net це щось із 2008 де тільки desktop app і заточеність під windows. А це — вже давно не так.
IMHO.
Гірші ніж у Python / Node.js? ;) Може все ж таки не в маркетологах і не в бюджеті на маркетинг справа?
оце 100% Я вже років 4 як на дот нет — і це дуже потужна і зручна штука!
Я працював і працюю на проєктах, де ми майже все реалізуємо на .net. Зараз маю на проєкті і старе запукане монолітне легасі і купу нових сервісів/функцій. Все, що є, крутимо на AWS. Є деякі проєкти на Node.js і Python, також SPA на Vue. Але все нове під .net пишемо. Я вважаю, що треба обирати технологію під задачу. Знаю купу нових фінансових продуктів, які пишуть на .net.
ну дотнет (точніше C#) живе і процвітає в геймдеві, але думаю серед людей далеких від нього існує досі думка що дотнет == мікрософт, хоча це дуже давно не так і спокійно можна займатись розробкою на лінукс чи макос
З лінуксом і mac os виникали проблемки через ліби які лише для вінди. А загалом, ще пробував писати декстоп застосунок на NET MAUI для mac os. Загалом ок, але тільки для чогось простого. Колись клацав мобайл апку на Xamarin, оце було прям боляче. MAUI набагато приємніший вийшов.
у мене бекенд розробка на .net, роблю все на маку — і за іронією проблем навіть менше ніж на вінді)))
Мені доводиться інколи стрибати з маку на ноут на вінді. Маю легасі на фреймворку + є деякі тули яких не вистачає в VS code.
Це було актуально десь10-7 років тому коли не всі ліби портували. Останній раз в мене був віндовий север 9 років тому, далі всі проекти на лінуксовому докері. Десктоп навіть хз ніколи не писав.
у майкрософта вже давно немає такої поганої репутації, тут швидше думка дотнет == ентерпрайз, оверхед, для старпьорів, немодно.
Це все так і є.
Двадцять років просидів в дотнеті, але останніх пару років бачу що треба світчитись в python+node+react.
До нет поки що користуэться попитом, але це в основному легасі ентерпрайз. І то, це переважно старі та великі проективні з купою індусів.
я також планую добавити пайтон в резюме, оскільки кількість вакансій .net падає і вимоги стають неадекватні
Нічого дивного, навіть як фанат .net я бачу непривабливість microsoft як постачальника.
+ мені взагалі складно згадати, що нового зробила Microsoft за останні 5 років. Програли AI?
Як це нічого нового?
А копайлот додали до віжуал студії, це що, не розвиток?
А так да, можливість запускати ноду чи пайтон прямо с докер контейнера без отих усих білдів та іншого вбиває усю ту кросплатформеність дотнету, до якої так довго йшли.
Не кажучи вже про бурхливий розвиток того самого АІ, де вся розробка та купа бібліотек виключно на пайтоні. Чи тайпскріпт, на якому можна робити і бекенд, і фронтенд.
що вам заважає білдити і ранити дотнет апп в одному й тому ж докерфайлі?
Эээ, нууу typescript, vscode, github copilot — це все основні інструменти в АІ екоситемі — основна мова, основна IDE, один із основних агентів
.net має підтримку і ліби для роботи з ai проектами
Найперше — треба подалі від гучних заяв триматися.
От наприклад проект на .net
github.com/...hnitiumSoftware/DnsServer
Проект розпочатий в 2016 році і це opensourceю.
Щось нове і стартап (так щоб за це платили) знайти важче
Ентерпрайз непогано платить за .net
Ріхтер вибач, ми все проїблали!
Так, класна книжка була.
А срачів скільки було через те що рантайм компіляція неефективна і воно скоро все здохне, бо повільне в порівнянні з сіплюплюс.
Але, що цікаво, в результаті еволюції дійшли до того, що аплікацію навіть компілювати не треба, а можно прям скриптом запускати. І багатопоточність можна зробити в одному потоці ( привіт нода)
І всіх все влаштовує.
— це щоб максимальна кількість ядер простоювала до кращих часів і не зношувалася? 🤣
Я, як дотнетчик, розумію ваш сарказм.
Почитайте якось, як нічого буде робити, як зроблена багатопоточність в ноді.
Для мене там було багато відкриттів.
В Node.js це не зовсім багатопоточність у класичному розумінні.
Тобто це не «багато потоків одночасно виконують код», а трохи інша модель зі своїми плюсами й обмеженнями.
В .net екосистемі теж є експерименти з цим:
github.com/...et/runtimelab/issues/2057
Може додадуть)
прочитати про те чого там немає? в ноді основа це event loop + неблокуючий I/O. якщо закинути CPU-heavy задачу, просто заблокуєш event loop і все інше стане. так, під капотом є пул потоків, але він використовується для I/O, а не для того, щоб твій JS реально крутився паралельно. так, ноду скейлять через кілька процесів, але це ж не багатопоточність :)
Але як тоді хайлоад на мільйони запитів працює?
хайлоад на мільйони запитів якраз і працює за рахунок того, що більшість цих запитів це I/O, а не CPU. в ноді один event loop може тримати тисячі одночасних зєднань, бо він їх не обробляє постійно, а просто чекає подій: прийшов запит => відправив у БД/мережу => пішов далі. поки йде очікування, він обробляє інші.
тобто виходить не паралельне виконання коду, а ефективне мультиплексування I/O :)
плюс ніхто не запускає один інстанс ноди:
— кілька окремих процесів на сервер (по ядрах)
— кілька серверів за балансером
я до речі з нодою не працюю і не хотів би)
Пишу OSS проєкт на ноді — автономний агент, близько 10к рядків коду, segfault та oom по кілька разів на день
Node.js Is Bad Ass Rock Star Tech
Вірно буде сказати ноду скейлять через декілька інстансів ))) Бо дефакто підіймають декілька інстансів додатка і так юазають багатопоточні процесори.
прям вайб з апаратних преривань на одноядерному CPU
Таких несинтетичних задач на беку немає, а якби щось знайшлося, то нічого не заважає час від часу явно давати івентлупу прокрутитися. Це якщо не делегувати задачу в інший процес, чи тред.
Ну і що значить паралельно? Код магічним чином не стає паралельним. Породити дофіга системних тредів та чекати синхронізації між ними на кожен чих? В ноді вже оптимальна модель багатопотоковості як для бека і їй та системна багатопоточність взагалі не потрібна і навіть шкідлива.
на «беку» бувають різноманітні задачі і в тому числі CPU heavy. стандартний варіант якщо така задача прилітає ріквестом, закинути її в чергу для обробки окремим сервісом, а клієнту просто одразу віддається згенерована айдішка задачі.
на мою думку на співбесіді така відповідь виглядала б як ред флаг. якщо у тебе є CPU heavy задача, яка блокує event loop, то її треба виносити з нього.
коли різні ріквести виконуються в одну одиницю часу. в ноді це досягається через окремі процеси (ну або через worker threads). такий підхід має більший оверхед у порівнянні з thread pool в джаві чи .net
до речі щодо worker threads, то в принципі оце вона і є багатопоточність в ноді. тому формально, це не зовсім правильно казати, що немає багатопоточності. але це всеодно механізм, який має значний оверхед, бо кожен воркер це окреме ізольоване середовище виконання, heap, event loop...
звідки взялося «дофіга тредів»? вже давно ніхто не створює новий тред на кожен запит. є різні моделі конкаренсі. у ноди своя модель і вище якраз писав, що нода тримає високі нагрузки. загалом початкова тема була не про те, що нода погана чи не скейлиться, а про те, що в ній немає нативної багатопоточності. ніхто вашу ноду не ображає, релакс)
Хотілося б приклад, що такого синхронного на JS ви там в процесі ноди ганяли
Це ви розповідаєте скоріше про long-running tasks, а не cpu-heavy. cpu-heavy в тому контексті, про який ви сказали на початку, це та синхронна задача, код якої блокує івентлуп процесу на час, який є неприйнятним, щоб вписуватись в максимально допустимий рівень затримки обслуговування інших запитів. Це не про довгі таски з IO.
Скоріше ред флаг того, що людина не послідовна в своїх міркуваннях, бо ви почали з того, що однопоточність ноди це серйозне обмеження, бо
Ну а я стверджую що не стане, бо в будь-якій синхронній задачі (якщо ви її таки знайдете) написаній на JS можна давати прокрутится івентлупу, що збереже відгук на інші IO. Тому тут навіть на рівні одного потоку цього обмеження фактично нема. Делегування ми тут не чіпаємо, бо це вже про архітектуру.
І в чому ж? Скільки тих процесів ноди на сервері щоб «копія ноди» в кожному була оверхедом? Нащо вам спільний heap, якщо нема ніякого смислу розмазувати обробку запиту по декількох тредах, бо в реальності немає вільних ядер, так як навантаження балансується зовні процесу, а переключення контексту і всілякі міжпотокові синхронізації для доступу до спільних даних — це вже оверхед, який не має смислу для виконання ізольованих запитів. Самий продуктивний варіант обробки запитів це по максимуму, на скільки можливо, його обробити в одному треді і ця концепція чудово кладеться на бекенд. Ну і один процес з мультитредами це безпекова неізольованість і ризик крашу всім процесом і різні підходи до скейлінгу на локальній машині і на кластері. Як би це був не бекенд, а скажімо якийсь відеокодек чи щось подібне, то так концепт багатопотоковості у ноді вже б був серйозною проблемою. Звичайно, там є API типу SharedArrayBuffer доступний для потоків, але це не буде те саме що в джаві з системними потоками і API синхронізації.
вище чітко написав, що я не використовую ноду) решту ви так сам уважно читали?)
ні, мова була саме про cpu-heavy. нижче декілька прикладів задач, де при high load go lang чи .net справляться значно краще. чому/наскільки краще і чи це потрібно у конкретному випадку — це вам домашнє завдання)
— обробка зображень та відео
— RSA-підпис та масова генерація JWT
— складна агрегація даних у памяті
— парсинг та трансформація (особливо якщо то щось відносно жирненьке)
— та і загалом highload message processing, де на кожене повідомлення треба десеріалізація, валідація та маршрутизація, коли кожна мілісекунда CPU має значення.
сорі, але на решту відповідати не буду, бо відчуваю, що це надто затягнеться)
Давайте ще раз- ви стверджували що через cpu-heavy у вас блокувався би event-loop в ноді і це недолік платформи. Тобто в цьому контексті cpu-heavy це синхронна атомарна операція, через яку івенлуп не може дійти до стадії опитування, через що всі інші IO задачі фактично би блокувалися. Все що ви навели це не атомарна синхронна задача, а просто пакетна обробка.
Приклад синтетичної синхронної операції це розрахунок Фібоначі з десятків мільйонів «в лоб», яку все рівно можна написати асинхронно, тому блокування лупу не буде. Суть ноди в написанні алгоритмів асинхронно. Ви, як я відчуваю, пропонуєте наляпати синхронно алгоритм, щоб тоді казати, що мультитредова плафторма краще справиться з іншими конкурентними запитами, чим однотредова нода.
Це вся поверхня планети в одному зображенні з роздільною здатністю піксель на квадратний дециметр?
Ви те відео прямо в ноді декодуєте чи через IO і ffmpeg? А якби і в ноді, то теоретично воно б оброблялося стрімом, а не синхронним блокуючим алгоритмом, тобто івенлуп не блокувався.
це RSA мільйонної біності? «Массова генерація», це знову не атомарна операція, а просто пакетна обробка, крім того сама криптографія використовує внутрішній пул потоків ноди.
Це все в гіршому випадку десятки мікросекунд синхронного коду до виклику будь якої асинхронної операції з макротаскою в т.ч IO, тому блокування лупу знову не буде.
Це точно, бо чули дзвін та не знали де він 😁
це якась нездатність розуміти) чи бажання перекрутити. очевидно в якому контексті сказано про блокування event loop як крайній приклад. домашнє завдання провалено. варто підівчитися перед тим як писати чергові перли :)
Ще одна спроба з гачка зірватися 😁
А ну ж розкажіть в якому ще контексті було вами сказано, що так як нода однопоточна і cpu-heavy заблокує івентлуп, ноду скейлять через декілька процесів [як костиль] «але це ж не багатопоточність» ?
таке враження, що гачок у вас десь застряг)
спрощу вам домашнє завдання, щось максимально просте, бо якщо вас більш абстракно питати, то вас кудись несе) якщо і тут ви не справитесь, то треба підівчити основи.
cервіс приймає http post запити (json~1 KB), виконує валідацію та записує дані в чергу.
характер запиту (на 1 request):
json parse (~1 KB): ~25—40 μs CPU
валідація: ~15—25 μs CPU
серіалізація + enqueue: ~10—20 μs CPU
разом CPU: ~50—80 μs на запит
питання:
— оціни максимальну пропускну здатність одного інстансу для ноди і го
— при якому rps нода почне порушувати p95 < 50 ms і чому?
— скільки інстансів потрібно для 100k rps у кожному випадку?
— оціни різницю у споживанні памяті при 50k concurrent connections
— чому при rps > 50k go дає кращу пропускну здатність і latency, або аргументовано запереч)
Божечки, вже Го приплили 😁 Ви зробили просте і таке ж помилкове твердження що cpu-heavy блокує івентлуп в Ноді, і це обходиться [тільки] скейлінгом процесів. Тепер намагаєтесь виїхати на питаннях порівняння продуктивності Go та Node. Здавалось би яке відношення має інша платформа до принципу роботи івентлупа і написання коду з cpu-heavy для ноди, але ні- давайте будемо порівнювати продуктивність та використання пам’яті в ГО та Ноді.
Це геніально. Порівнювати один інстанс динамічно типізованої скриптової платформи з JIT компілятором з компільованою типізованою мультитредовою мовою, хоч і теж з GC але ж типізованим, це взагалі сильно. І головне, взагалі немає ніякого відношення до початкової теми.
завдання з тріском провалене.
також варто читати уважніше. про го згадував ще раніше, а не лише зараз, бо це приклад іншої конкаренсі моделі, яка для cpu heavy більше підходить.
Не зовсім так, бо пан Тейлор чітко означив обмеження «кожна мілісекунда CPU має значення», а ось тут вже вивільнення event loop та розбивка обробки на етапи, між якими, власне, буде вивільнятися event loop для інших задач — може не вписатися в мілісекундні обмеження.
Інша справа, що такі жорсткі обмеження доволі специфічні і існують лише в деяких напрямках (наприклад, HFT чи ad bidding). Так ніхто начебто і не казав, що та сама Нода — це інструмент, який ідеально підходить під такі задачі.
Ну так ми ж це все одно не контролюємо, якщо в коді є асинхронний виклик, а все там наведене в того пана типу обробки зображень це вже мінімум IO до файлової системи, а сама обробка одного файлу навряд чи займає якийсь помітний час. Якщо мова про оверхед при розбитті синхронного коду на чанки і прокрутка лупу, то тут вже ми можемо практично самі контролювати скільки часу ми можемо приділити виконанню синхронної задачі «без розриву» щоб максимально швидко її закінчити в залежності на скільки допустима затримка опитування. Але ж і розбивати задачу в 1мс щоб прокрутився луп немає смислу. Все одно ж це вже фактично черга запитів- може ми в умовну 1мс вкладемося для поточного запиту, тільки наступний такий же важливий запит все одно вже чекає в черзі і для нього з точки зору запиту вже час пішов, а якщо там важливі затримки між операціями всередині запиту то ми ж втрачаємо контроль на як тільки з’являється асинхронна операція. Так що ці питання це до архітектури і балансирів, щоб сервіс не був перевантажений і латенсі не вилізав, хоча дива все одно не станеться.
тай нашо ота вам багатопоточніст? Он пітоністи працюють собі з інтерпритованою мовою ( привіт бейсік) та не скаржаться на GIL сильно. А якщо скаржаться то Гвідо каже — а нашо вам багато потоків ?
Так молоде покоління не осіліло наслідвування, сторогу типізацію і багато поточніть. Обрало мови де можна просто гвінячити простині коду із логікою додатку, а далі нехай девопсі ібуться скейлити тю шляпу.
Python має строгу типізацію, наслідування і багатопоточність, аргумент втопку
Типізацію як джава скрипт через тайп скрпит? ))) Багатопоточність і в ноді є, дууууже давно, навіть браузері воркери були більше 10 років назад і шо далі? )))
Коли це все зявилось у пітоні і скільки калік його юзає в проді?
Так шо в топку твою типізацію і багато поточність )))
Ти хоч знаєш що таке строга типізація ? Відкрию таємницю, це коли ти не можеш додати число до стрінги і у тебе вальнеться помилка. І порівняти типізацію пітона з жсом (де слабка типізація) це просто топ 👍. І да, ще одна велика таємниця все це вже дуже давно відловлюється тайп чекерами які є стандартом індустріі. Скільки років пройшло а дотнетчики далі свого болота не бачать
Ладно не строга а статична. Єнівей це шляпа, сенс в тому щоб воно працювало іще до того як ти почнеш це пхати в коміт, на стадії білда. В будь якому випадку це вже все пізно зумери зробили свій вибір.
Кхем кхем automapper ......
А що зним? Аааа це ж те що писалось вище — зумери не відрізняют ентерпрайзний бойлерплейт від мови та платформи, і що дотнет так само дозволяє говнячити чік чік і в прод солюшения як і на пітоні.
Чи то проблема не віку а просто рівень інженерії коли далі копіпасти туторіалів та написання тікетів під діктовку ліда так і не осилили.
Особисто автомапер юзав бо зна коли років тому, а скрс паттер ліпив колись бо був откий тугенький як ти тім лід, котрий вважав що треба тягнути увесь бойлерплейт що терба і не треба.
Так ти ж тут писав що у нас тут під час компіляції гарантій дофіга чи вже не дофіга ?
Ти зараз хочеш змішати статичну компіляцію і не розуміння бойлерплейтів? Ти взагалі хоч якесь маєш відношення до програмування? Чи просто вайбкодер баріста? ))))
є state of art бібліотека у світі дотнету під назвою automapper яка під капотом юзає купу рефлексії яка виконується під час запуску апки, так само з mediatr і іншими популярними лібами. Розглядати платформу без екосистеми — це як дивитися на сферичного коня у вакуумі, в принципі нічого нового коли тобі продають дотнет з слоганами а ля «у нас будь-яка мова компілюється в IL» коли в реальності у тебе навіть сам майрософт забив на свій ж F# і він потихеньку загниває. Але ж проблема у паганому пітоні який не дає тобі гарну плашку «build successful» ну та, логіка небарісти
Коментар порушує правила спільноти і видалений модераторами.
Лол, пішла апеляція до віку 😆 поспішаю тебе розчарувати у мене 7 років досвіду у дотнеті
Зате на єдиній ± матурній лібі з меседж басом вже присунули платну ліцензію і або плати або роби свій форк
І всі ці 7 років не не міг написати мапер для проекту? Чи зрозуміти як він працює? Чи я стала ліба за гроші то ти свічнувся в пітоністи бо там знайшов автомапер а в дотнеті не знайшов? Блін чел не неси маячню, автомапери проблема тільки для розумово відсталих крудошльопів.
Вони взагалі далеко не всюди потрібні. Я їх юзав джуном коли потрібно було по биріку накидати апі сервер. Взагалі це найтупіше що буває в програмуванні. Може ти 7 років унтіази мив в айти офісі? ))))
Та нє, свічнувся бо зп дотнетчиків стали як у мийників туалету, зате яке чсв у цих мийників
Не осилива мапер на дотнеті, так і запишемо )))
Тут кожний другий в житті не написав жодної програми (якщо лаби в універі не враховувати), що ж ви від них хочете?
В цілому багато поточність для уеб додатків не потрібна програмісту але рантайм її насправді дуже активно юзає, там за допомогою ТПЛ ліби і асінк евейту максильно спростили та заховали за синтаксичним цукром та рантаймом від неокрепших мізків молодого покоління...Для десктопу то маст хев щоб писати асинхронний юай. Але знову всі обирають ублюдочний електрон бо він кросплатформ. Писати нативні десктоп додатки то дорого виходить а запит на перформанс невеликий, профейсійні додатки звісно рідко юзають електрон і пишуть нативні але це там де є бюджети і кліенти котрі готові платити за таку дорого розробку.
З підключенням, вже є free threaded python і JIT компіляція
Що вони дійсно є, казатимемо з виходом 3.16. Зараз рано.
вже є у проді й рекомендовано до використання чи це просто у стадіі — ну потестуймо й побачимо що воно таке ?
У стадії «через рік-півтора вже будуть по дефолту увімкнені»
ну от тоді пан мені й напише «з підключенням» а до того — немає ні JIT ні фри тредінг у пітоні. може тоді я свою думку зміню на іншу
Ну взагалі навіть із GIL декілька ядер норм так собі використовуються при обчисленнях. Бо всі мат ліби відпускають GIL коли виконують обчислення.
Скаржаться. Так скаржаться що аж код почали писати. В 3.14 GIL вже можна вимкнути.
Тейлор має рацію — івент луп на одному потоці працює погано якщо є багато обчислень. А в пітоні — дуже погано.
C#/go модель івент лупа яка виконує таски на тред пулі набагато ефективніша.