Офер за 1 день в команду BetterMe (Frontend Hiring, JavaScript/React/Redux)
×Закрыть

Обговорення рейтингу мов програмування 2021

У цьому топіку обговорюємо рейтинг мов програмування 2021.

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

👍НравитсяПонравилось4
В избранноеВ избранном0
LinkedIn

Похожие топики

Лучшие комментарии пропустить

Як і в попередні роки, більшість респондентів (83%) хоче вивчати нову мову самостійно, за допомогою книжок і документації, 4% будуть шукати допомогу в колег (вражаюча інтровертність), а 12% використовуватимуть традиційний підхід — з допомогою професійних викладачів (курсів або індивідуальних занять).

З якого це моменту традиційним способом по вивченню чогось в програмуванні стали курси? Думаю тут традиційним підхідом треба вважиати «вивчати <що завгодно> самостійно», що в принципі і демострується в цьому рейтингу із року в рік.

Я б це назвав швидше «Рейтинг мов, потрібних для українського аутсорсу».

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

да просто какой то аутсосный бред, который идет вразрез всем рейтингам, которые только возможны:
www.tiobe.com/tiobe-index
pypl.github.io/PYPL.html
spectrum.ieee.org/...​rogramming-languages-2020

особенно смешно про JS, которая по IEEE делит 5-6 место с R )))

У кожної країни свої вподобання чи всі країни мають однакові вимоги до ІТ спеціалістів?

Да, все страны имеют одинаковые требования, хотя деление на страны это какая то шизофрения...

Ви зустрічали в Україні проекти на Cobol?

В Україні вакансій Visual Basic більше ніж JavaScript? Чи може проектів більше? (якщо дивитись світовий рейтинг Tiobe)

Да в любом банке, вон Райфайзен ищет

Experience in integration and middleware technologies (e.g. Tuxedo, WebSphere Message Broker, MQ)
Knowledge of Cobol, Pro*Cobol is an asset

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

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

Для прикладу у популярних магазинів: списки товарів, які рекламують на головній, для кожної країни свої унікальні.
Сайти з навчальними курсами теж пропонують різні ціни для різних країн.
Тарифи у стрімінгових сервісів теж для кожної країни свої.

Це хіба що московити думають про «один народ» і таке інше.

Те, що ти запостив, звісно в розріз не йде, коли на одному сайті C найпопулярніша мова, на іншому пітон. Сі блін. Пітон, мля :)

Як це мило, що C і 1С в першому рейтингу поруч.

Таке враження що данні коригувалися і добре коригувалися... Одним з перших відсилав анкету, але в графіках мене точно немає:
Мені 50 років, основна мова Java, додаткові Scala Clojure, 30 років досвід в ІТ, 12 в Java...

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

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

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

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

Для того, що б пояснити що не так, почну з іншого боку — а нащо цей рейтинг?
Вочевидь, цей рейтнг потрібен всім для планування власного розвитку.
Початківці шукатимуть — з чого почати.
Інші дивитимуться — а щоб ще підівчити, чому більше приділяти уваги тощо...

І от тут на сьогодні мова програмування не говорить ні про що...

Перший суттєвий рівень — це екосистема.
Фокус в тім, що багато екосистем просто не сумістні...
Наприклад, коли я шукаю людину для Java екосистеми, то досвід .NET екосистеми буде мінусом і навпаки... І мова тут ніяк не на першому місці — шукаючи Java розробника, я радо візьму Scala розробника, варіант навпаки теж можливий, хоча вже менш ймовірний...

Другий рівень — сегмент на кшталт enterprise/desktop/web/mobile/bigdata/cloud/microservices etc...
Погодьтесь, що enterprise java software engineer зовсім інше ніж java web developer.
А от для bigdata/cloud/microservices — тобто стеку data engineer — важливіше не мова програмування, скільки досвід з фреймворками на кшталт Hadoop/Spark/Kafka/Solace/Storm/Akka/Spring Cloud etc...

...і ще багато багато рівнів...

Звісно, що складно...
Але і мови програмування зараз лише інструмент роботи з технологіями... і от дійсно де треба рейтингу... :) Рейтинг технологій, які використовуються...

Хмм, max: 55, схоже дійсно щось з тим графіком.
```
r <- boxplot(Age ~ NowLanguage, data=x, las=2, outline=FALSE)
```
— оутлайнери викинуло. Да — треба буде в інтерпретації це сказати

Сори за оффтопик. А как этот красивый график называется правильно? Который показывает динамику по нескольким параметрам одновременно?

А можете пример сказать (?), а то я не могу сейчас сообразить какой

Якою мовою пишете для роботи зараз (2012–2021 рр.)
Якби ви зараз починали комерційний проєкт і у вас була свобода вибору
и т.п.

Я его в R генерил как barplot с опцией beside=TRUE, Игорь из набора столбиков линию сделал. А если у него специальное название .... даже не уверен

barplot не похож. блин как тут скриншот вставить?!
там несколько line графиков на одном...

Не совсем. Они цветом отличаются (выросло/упало значение), они по высоте (по значениям) выровнены. Короче, я тупо код себе скопипастил. Спасибо разработчикам DOU за идею ;)

Чому ви постійно ігнорите в аналітичних статтях ABAP? На ньому ж працює весь світовий крупний бізнес: банки, аеропорти, ретейлінг, промисловість. Додайте, будьласка, його до аналітики наступного разу, він точно буде не на останньому місці.

Он там появится если какое-то количество людей его туда впишет. По SAP ABAP было 3 анкеты (31-е место. Для сравнения у Elixir — 17)

Сделайте пожалуйста графики динамики внутри «Мови програмування з розбивкою за сферами використання», имхо это довольно важно. Мне как back-end C# девелоперу мало интересна общая динамика моего языка, но внутри back-end and desktop было бы полезна.

мы только в этом году начали собирать разбивку по сфере использования => первая динамика появится через год

>>>...зниження частки Python: можливо, використання Data Science дійшло до точки насичення...
Моє припущення, що велика частина роботи з AI та DS оминає Україну через брак необхідних фахівців
Data Science тільки починає свій розвиток

Навпаки... Це цей рейтинг по цій темі чипляє лише студентів...

Україна сьогодні — топ один в розробці, тож і ці теми досить потужно робляться...
Особливо напрямки Native Language Processing та Media Recognition — і зовсім не факт що там буде використовуватися Python — є багато варіантів на Java, Scala, R, Clojure
...і де це використовується? Потужні фінансові системи (мені не знайома жодна потужна система, котру б не робили українці!), сервіси та соціальні мережі... І коли в твоєму контракті стоїть обмеження на поширення інформації о клієнті та проекті... Це ніяк не попаде в такий рейтинг...

Из года в год Котлин и школота неразлучны

На Android дуже популярний

Потому что IDEA проплачивает всем кто готов микрофон облизывать. Но мы то понимаем что это сахар.

Цукор чи ні, якщо людям зручніше з ним, нехай користуються. TypeScript теж цукор над JavaScript, але з ним реально зручніше працювати.

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

Го скалу конечно обошол, но на этом похоже все — чуда не случилось.

Прикольно, що 45% джаваскриптистів не хочуть писати свій наступний проєкт на JS. А шо ж таке?

45% проституток не хоче трахатися з наступним клієнтом. А хто ж питатиме.

Потому что они будут писать его на тайскрипте, делов то

Я б це назвав швидше «Рейтинг мов, потрібних для українського аутсорсу».

Якщо поклацати вкладками діаграми «Мови програмування з розбивкою за сферами використання», то інформація про те, в якій сфері які мови програмування здебільшого застосовуються, як на мене, справедлива не лише для українського аутсорсу, а і взагалі. Принаймні для системного програмування та IoT мати на першому та другому місці C та C++ цілком логічно.

Наш аутсорс это какая-то замкнутая система? Или все таки подмножество западного айти?

Скорше, рейтинг мов, котрим навчають курси навчання мов програмування....

Спасибо, что добавили Elixir

В кінці року Dart випередить або наблизиться впритул до Kotlin :)

Погодите, я думаю, что сравнивать применение C++ и TypeScript, как впрочем, JavaScript не совсем корректно. Никто в здравом уме не будет писать back-end на С++. Разве что, системные сервера, которым нужен пифоманс по обмену (только Microsoft пытался когда-то сделать что-то на подобии ATL Server, не прижилось...). У них область пересечения стремится у нулю.
Если было сделано сравнение по доменам, front-end, back-end, mobile, где какой язык лидирует и почему. Как пример:
Back-end: Java, C#, Go, Python, Scala, JavaScript (ситай NodeJS).
Хотя, собственно, и так понятно, что в мире аутсорса правит бал JavaScript, Java, С#, Go, Python.
Читай — web development.
И это понятно, почему.

Так табличка под «Мови програмування з розбивкою за сферами використання». вроде то и есть — нажимаешь вверху на «область» а внизу появляется список языков

Сори, да, есть такой раздел. Скорее всего проскочил скролом :) Вопрос снимается.
Но про С++ и TypeScript — все же, я думаю, что не совсем корректное сравнение.

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

как только он скажет, какой его на данный момент праймери язык, с высокой долей вероятности, зная наш аутсорс мир, и, исходя из раздела анализа областей применения языков программирования, скажете в какой области он ведет разработку :)

Никто в здравом уме не будет писать back-end на С++.

Бачив таке. Те, що на Java я робив за пару днів, вони місяцями інтегрували. Може С+±ники криворукі, але зробити новий рест сервіс, або інтегрувати веб-сервіс для них було вершиною майстерності.

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

Просто там спрінга нема, бібліотек нема — нічого нема.

спринга точно нет. остальное все есть. валом

Ну ты можешь показать кусок кода, который имплементит микросервис на С++?

Саме через такі проекти і складається враження, що с++ це якийсь космос

я взял первую ссылку в поиске

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

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

Космос-не космос, але все ж мова програмування, в якій ооп то є, то нема, в залежності від . чи ->, це якось трохи зайве в наші дні.

можна тут детальніше? це як?

Це хтось не подужав вказівники і намагається змішати це з ооп, яке до цього не має жодного відношення.

Тоді може хтось, хто подужав, розкаже мені мені навіщо в плюсах є змінні об’єктів класів в стеку з value семантикою присвоєння, коли об’єкт «деградує» до базового типу ? З точки зору концепції ооп, а не «багатих можливостей».

По нынешним временам Spring не панацея. При большом желании можно обойтись без него. Нынешний стандарт EJB это позволяет, тем более при наличии JAX-RX, JAX-P, JAX-B.
Нынешние Java разработчики в больше степени превращаются в пользователей Spring.
А чтобы обойтись без Spring достаточно найти простой контейнер IoC. Они есть.

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

Я ж не спорю, что тут про С++ :) я тут немного в другую сторону коммент написал, сознательно. Также для меня все равно как-то странно звучит про написание web сервисов на С++. Это очень мощный системный язык. И да, я соглашусь, с утверждением, что вообще сложно представить написание на нем микросервисов.

Ми в Keepit успішно пишем вебсервіси на C++ і навіть на Common Lisp. Приходьте — все розкажем-покажем ;)

Ми в Keepit успішно пишем вебсервіси [...] навіть на Common Lisp

Ох ні*** ж собі. Мосьє знає толк в ізвратах.

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

Та не скажи ... тулінг же набагато слабший. Кількість спеціалістів менша. Готових бібліотек ЗНАЧНО менше.

Можна приклад сервісу саме на Common Lisp’і?

А що конкретно не так з тулінгом? Парсити/генерувати json/xml і доступатися до бази, то не космічні технології. Писати бізнес логіку на ліспі — взагалі казка. Конкретно в нас саме бізнес логіка + частина апішки на ліспі.

Писати бізнес логіку на ліспі — взагалі казка.

Писать веб-сервиcы/бизнес-логику на "сях"/"плюсах" это понятно — для этого много чего есть и в этом есть смысл (производительность, развитый инструментарий, наличие большого количeства спецов на рынке).

Но Лисп... В чём преимущество, в сравнении с теми же "сями"/"плюсами"?

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

...ну..если так посмотреть, есть LISP для Java экосистемы...
...и называется он Clojure...
...и многое на нем написано крутого, например Apache Storm.
Более того — он может «напрямую» использоваться в проектах Java экосистемы... реально, делаете его импорт и прямо в класе пишете на нем... :)

Что же касается самого Common LISP — то очень много систем уровня SAP пишется на нем... самый извесный/популярный из которых AutoCAD (надеюсь, представляете область преминения??? AutoCAD — все машиностроение, PCAD — вся радиоелектроника, ArchiCAD — вся архитектура и строительство...)

Почему так удобно?
В свое время как альтернатива языкам алгоритмического программирования рассматривались языки логического програмирования. Собственно такими тогда считались LISP и Prolog. Теперь плюс Haspel и вариации...

Например. в свое время на Prolog мы писали систему решения диффиренциальных уровнений в общем виде...
...собственно и сейчачс все AI и DS на них...

Просто python используется для AI adoption — хотя эти писатели считают что они пишут именно AI... :)

если честно, то я допускаю интеграцию C++/C кода в Java через JNI (чтобы действительно «узкие» места ускорить), но так чтобы все веб-сервисы писать на С++, за всю практику слышу впервые. Вероятно, что в том у вас может быть потребность.

...а вебсервису не все равно на чем он отписан?

Вот в онлайн гейм индустрии практически все сервиса пишутся на с++...
...хотя «более правильные» пишут на Haskel или Common Lisp — а потом делают порты в разные стороны, включая мобильные варианты...

Тут проблема немного в другом. Многие считают что на с++ приложение будет намного быстрее работать. Вот тут пришлось практически поучаствовать в споре --- я написал версию парсера FIX протокола на Java, который был быстрее чем с++, правда пришлось использовать unSafe pakage

Java априори не может работать быстрее С++. Только если уж каким-то образом вы как-то избегали работы GC (я не помню, где я читал, но часто вызываемые части кода Java компилируются, на Android вообще есть понятие холодный старт, когда весь код приложения компилируется в нативный при первом запуске). Быстрее С++ может работать, как я уже упоминал в комментариях к другой статье, С или Asm. Кто-то утверждал, что еще и Rust — тут спорить не берусь, я не изучал этот язык.
На предмет того, на чем написан веб-сервис, строго говоря, значения не имеет. Вопрос несколько в другой плоскости. Издержки на его разработку плюс то железо и энваронмент, где это будет работать. Потому как ни крути, но чтобы написать класс на С++ занимает больше времени, чем на Java/Scala/Kotlin/Swift.

Java априори не может работать быстрее С++. Только если уж каким-то образом вы как-то избегали работы GC

Да? Но как-то Hadoop и многие большие комбайны, включая базы данных, пишут в java-экосистеме...

вот в собеседовании на Java один вопрос имеет два противоположніх ответа для тех, кто ниже сениора, и тех кто сениор плюс...

—что можешь рассказать про GC?

Для мидлов и ниже ответ: — предоставляем все делать ему...
Для сениоров и выше при таком ответе будет — до свиданья! Вашего уровня для нас не хватает...

..тюнинг GC как минимум.... а в 9-й уже появился целый интерфейс, который позволяет писать свой GC.. ...и это минимум...
...интерпрайзные решения на своих ООООчень быстрых и тонко настраиваимых JVM...

...но там где нужны высокопроизводительные решения — используется unsafe
Собственно, когда я делал парсер FIX протокола, я его и использовал.

У нас приходит готовый пакет, который помещается в память.
Имея ссылку на него. я определяю область памяти от и до где оно находится...
Так как в пакете FIX нужные данные находятся в полне фиксиованом месте,
я просто даю команду — данные с такого адреса по такой переписать в такой-то адрес и назвать это таким образом... Когда понятно, что нужно получить, в каком формате — все очень быстро...

Это все unsafe. И он находится под капотом многих высокопроизводительных решений.

Но и это совсем еще не все.
Мы не зря говорим что Java сейчас — это экосистема.

Да, пишу код на Java — но фактически inline, прямо в коде, могу использовать Scala, Clojure, Kotlin, Groovy, Jython, JRuby --- там, где это оптимальнее...

Например, когда идет вариант рекурсий, Clojure в сто раз быстрее всех вариантов на С/С++
А варианты типа АККА конечно лучше писать на Scala...

Почему для начинающих программистов Java медленный?
Для них Java — это Spring.

А что такое Spring? — это «лентяйка» для быстрого написания проектов.
Вот например, у нас на JHipster вы за пол час напишете ЛЮБОЙ проект уровня ниже энтерпрайз.

Но... Spring Framework
...использует Reflection — и это очень ресурсоемкий по определению пакет.
...использует Hibernate — и это тоже фреймворк, который не ставил себе задачей производительность...
...использует еще много чего,что облегчает написание, но отнють не оптимизирует работу приложения...

..хотя, например, Spring с версией на Scala и в реактивном варианте (с использованием Netty), взует большинство фреймворков...

На самом деле, да, Spring — это, как вы выразились — лентяйка. Но давайте посмотрим, а почему появился Spring? Который изначально это был IoC фреймворк, на который позже накрутили все остальное. Что IoC использует, вы и без меня знаете — Reflection, что априори не может быть быстрым. Появился в противовес неповоротливому первому EJB.
С помощью нынешнего EJB тоже можно разрабатывать Java приложения и без Spring. Но все равно какой-то IoC надо будет взять.
А чем не нравится Hibernate?
Он вам дает сразу переключиться на предметную область и вперед. Без него куча рутинного кода будет.
По GC — в 80% вам особо и не надо будет конфигурить и мудрить с GC. Да, есть интерфейсы, которые вы будете применять, чтобы избежать избыточного выделения памяти, так называемый Garbage-free код. Но в общем и целом в Java не так много инструментов для манипулирования GC.
На счет Spring+Scala — зачем?
Есть Scala + AKKA. Все остальное накручивается.

а почему появился Spring? Который изначально это был IoC фреймворк, на который позже накрутили все остальное.
Появился в противовес неповоротливому первому EJB.

Да, но больше формально.
Давайте вспомним... :)

Очень не плохо пошел J2EE. Но... что всех стало доставать? Тысяча пустых классов и мильйон путых интерфейсов, но которые should be.
С другой стороны, хорошо пошли Persistence и Hibernate и на них начали делать не только абстракцию работы с БД, но и практически все. И это — чувствовалось — что тоже не правильно.

И вот тут появляется Spring как развитие Persistence, придумывает POJO, и пробует полностью реализовать все фичи тогдашней J2EE.
Но таких фреймворков тогда было много. Я тогда, допустим, пробовал очень неплохой ServerLet фреймворк. И не это привлекло внимание всех к Spring.

Spring ввел «магию соглашений» — теперь каждая ентити с минимум определений получила методы «определенніе по соглашению» — типа findById, findByNameAndValues...
И после «жестко формального» написания этого в интерпрайз... это была магия.
И да, мало кто тогда оценил что эта «лентяйка» на тяжелом Reflection...

IoC — да, но то было уже в Persistence и, что интересно, как и сейчас, все четыре варианта поддерживались. И что интересно,рекомендовалось не DI, а DL (dependency loading) что логично — оно должно было вписаться в интерпрайз, где во всю использовался JNDI... Но эти же варианты давал Persistence и он вот для этого выглядел предпочтительнее! :)

и вот — к нашей теме — победила «лентяйка» и у многих JAVA стала ассоциироваться с ней, что, по сути, не правильно...

Но давайте проанализируем, в чем популярность Node.js? ...думается не в том, что на нем можно полностью сделать back-end, а в npm и yarn генераторах — которые есть таже самая «лентяйка»! ...на нашем проэкте JHipster мы соединили обе «лентяйки» — и получилось реально круто. Но — в лучших традициях Agile — один спринт делаем рабочим весь проект, а потом двадцать спринтов его рефакторим до нужной производительности! :) ...и не факт, что после рефакторинга там останется Reflection, единственнім языком будет Java и т.д.

На счет Spring+Scala — зачем?
Есть Scala + AKKA. Все остальное накручивается.

Во — вот тут уже интереснее!
Давайте вспомним, что на момент выхода Spring 5, его категорически «взувал» Play2.
и его scala версия была быстрее его java версии.
Реактивный Spring выровнял ситуацию и его scala версия тоже получилась быстрее...
Akka... она очень не плохо туда интегрируется, особенно в Spring Cloud...

И таки да, сам по себе Akka framework — вещь быстрая и крутая.
Но... тут уже другая проблема. :)

Почему Java? ...почему корпорациям она интереснее???

Один из основных идеологических принципов идеологии Java — максимальная читабельность и доступность кода. Именно это обеспечивает низкую «планку вхождения».
Новый программист на проекте тратит минимум времени на onboarding.

И вот тут Akka — как и сама Scala — имеет проблемы.
Scala имеет свою четкую идеологию и эта идеология абсолютно не поддерживает принцип «максимальной читабельности». А потому и «планка вхождения» высока.
Как и тюнинг, который стает «значительно дороже»...

Spring на Scala — очевидный компромисс.
Во-первых, Spring и так многое использует по принципу «черного ящика».
Во-вторых, Scala стримы с правильным матчингом — это совсем другое чем Java стримы и ооочень красиво интегрируется с JPA. И это красиво интегрируется в корпоративные решения со специфичными JNDI и EJB! :)

Тут реально получается анекдот! :)

— Давайте мы сделаем вам проект на Scala!
— Нет, для нас это дорого...
— А может на Clojure?
— Вы что, смеетесь?
— Ну тогда на чем? На Java, на Spring?
— Да да — именно так!
— Хорошо, делаем на Spring!
— И чтобы все работало очень быстро!
— Ну, тогда мы добавим немного Scala и Clojure...
— Ладно. Но главное — вписаться в строки...

Вот правильно, ключевой момент — «лентяйка». Уже давно все как-то привыкли к шаблонам во фреймворках, но мало кто вообще копает в глубину, чтобы разобраться с инструментом. А потому вот так и получается... Как получается, главное продать. Ибо это больше уже бизнес, чем инженерная и творческая работа. И это как раз проблема, которая встает в полный рост.
Второй момент — Scala. Это своего рода стык ООП и функционального программирования. Ничего не мешает писать на Scala в духе ООП, но как раз со степенью освоения инструмента, программист больше уже уйдет в сторону функционального программирования (по крайней мере должен). Как когда-то писали на С++ в стиле С. Ибо мало кто понимал, что такое ООП — MFC тому подтверждение.

чтобы написать класс на С++ занимает больше времени, чем на Java/Scala/Kotlin/Swift.

нет

с автогенерацией разницы ни какой нет

написать

!=

автогенерацией

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

это одно и то же

(рукалитсо)

Значит вы не подумали про конструкторы копирования и мувебл, о которых, как разработчик на других ООП языках и думать даже не придётся. Так что — таки да. Больше времени на С++ занимает.

Значит вы не подумали

подумали. дефолтная имплементация, эниван?

других ООП языках и думать даже не придётся

догадайся почему

Про дефолтную имплементацию — подумать все равно придется.
А в случае, если не подойдет — ответ тем более очевиден.
На счет почему — спасибо, что подсказали. А то мне неведомо :) Я великолепно осведомлен о работе с памятью в С/C++ (с применением даже Win API).
На счет memory leaks — можно добиться даже в Java.
Но мне больше на самом деле нравится, как сделано управление памятью в Objective-C/Swift.

Про дефолтную имплементацию — подумать все равно придется.

ага. подойдет или нет.
в большинстве случаев подходит
если не подходит, то для этого есть причины. другие языки просто не дают подобной гибкости

так в других языках — именно это и был один из поинтов решения. За что во многих из них пришлось заплатить пифоманс.

Напомнило мне как Страустрап объяснял почему в С++ модель памяти такая сложная (по сравнению с Java Memory Model) — потому что если бы там было простое поведение (что-то типа JMM), то эффективная реализация JVM на стандартном C++. была бы невозможна.

Вы считаете модель памяти на С++ сложной?
А на счет JVM — то, если мне не изменяет память — написана она на С.

Вот цитата из „Thriving in a Crowded and Changing World: C++ 2006–2020” (полный текст есть на www.stroustrup.com/...​n-p5-p-bfc9cd4—final.pdf )

Initially, I think that most of the committee members underestimated the problem. We knew
that Java had a good memory model [Pugh 2004] and hoped to adopt that. I was highly amused to
find that representatives from Intel and IBM effectively vetoed that idea by pointing out that by
adopting the Java memory model for C++ we would slow down all JVMs by a factor of at least two.
Consequently, to preserve the performance of Java, we had to adopt a far more complex model for
C++. Ironically and predictably, C++ was then criticized for having a more complicated memory
model than Java

Сложная — просто больше. Из того что помню — в дополнение к sequential_memory_order есть relaxed_memory_order, отдельно интерфейсы fence и atomic итд...

нет у с++ никакой модели памяти. модель памяти есть у ОС, на которой крутится приложение. еще есть заменяемый хип менеджер

нет у с++ никакой модели памяти

ОМГ, быстро в школу доучиваться!

Проблемы с восприятием написаного? Дислексия? Модель памяти в плюсах есть, особенно после внедрения туда многопоточности и атомиков.

почему ты все время сам с собой разговариваешь?

Так было когда-то очень давно. В С++11 ввели набор стандартных интерфейсов и описали семантику гарантий для атомарных операций и барьеров. Это и называют С++ memory model.

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

Это как-бы min(гарантии модели hardware), что бы можно было писать на стандартном С++ и поведение было одинаково на любом железе. Интересно, что когда NVidia выпустила железку с другой моделью памяти, то в С++20 проапдейтили memory model (ослабив гарантии ’happens-before’), вместо того что-бы заставлять компиляторы вставлять барьеры

>нет у c++ никакой модели памяти

en.cppreference.com/...​cpp/language/memory_model

Також у Вільямса, у якого цілий розділ про модель пам’яті C++.

ну ок, до с++11 не было нечта под названием «модель памяти»

я написал версию парсера FIX протокола на Java, который был быстрее чем с++, правда пришлось использовать unSafe pakage

который был небось написан на плюсах
так возникают нездоровые сенсации ©

Сам термин «аутсорс» сейсас не коректен...

Вот мы, например, DXC/Luxoft... 145 тысяч програмистов.
Топ 10 по мировому рейингу... Многие наши клиенты меньше чем мы.
Но кто мы?

Клиенты передают нам определенные направления работы\разработки и т.д.
Лет двадцать назад это называлось «outsource»...
Сейчас это называется «предоставление сервиса...»
и это правильное название, так как никому в голову не приходит банк называть «оутсорс компанией» потому что они вместо вас берегут деньги вашей фирмы... :)
И этот сервис — исследования, разработки и поддержки — наш продукт.

...ну ...сравните — какая-то компания сделала «свой продукт» и у них допустим 100 тысяч клиентов.
И Вы их гордо называете «продуктовая компания».

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

..сейчас, во времена Информационного Общества, все есть сервиса. И есть четкие критерии оценки ЛЮБОГО сервиса — TOS, SLA и так далее... Вот для наших вариантов, например, критично что это — SaaS, PaaS, IaaS или чтото еще...

...и давайте в этом контексте смотреть фирму, которая на колене — на какой-то там Jumla или Wordpress — штампует сайты и гордо себя называют продуктовой компанией, на которой работают сениор Wordpress программисты... :) :) :)

Аутсорс від продуктової компанії відрізняється бізнес моделью. Аутсорс заробляє як ви казали від кількості «сервісів» наданих. Продукт заробляє від своїх клієнтів.

Для продукту важливо швидко і дуже якісно (якщо буде зроблено погано, то буде важко заробляти на продукті гроші)

Для аутсорсу важливо щоб було не смертельно повільно і не принципово на скільки якісно (чим довше робиться проект тим компанії вигідніше, якщо зроблено не дуже, то клієнт буде більше платити за підтримку)

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

Ну не має зараз оутсорса... забудьте!

В теперішньому світі — ВСЕ Є СЕРВІС. І це основа Інформаційного Суспільства в якому ми живемо.
Зараз і продаж хліба — це сервіс по доставці певної кількості, певної якості в певне місце (наприклад, магазин)...

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

І у нас так само КЛІЕНТИ. Просто у вас клієнт — Вася Пупкін, а у нас клієнт Citi Group з десятками філій по всім країнам світу та т.п.

От зараз я клієнт мого підрозділу і моєї команди — інший світовий банк (на жаль не можу писати який) і ми для нього робимо сервіс по міграції певної їх системи на IBM WebSphere WAS 9.0
І коли було треба — прийшли люди з IBM та мігрували WAS 6 -> 9.
І коли було треба — прийшли люди з Microsoft та мігрують з 2003 ADAM —> 2016 AD LDS

То що — по вашому — IBM та Microsoft — оутсорсінгові компанії...

Для аутсорсу важливо щоб було не смертельно повільно і не принципово на скільки якісно (чим довше робиться проект тим компанії вигідніше, якщо зроблено не дуже, то клієнт буде більше платити за підтримку)

— цього давно вже немає. Більшість хто так думав — прогорів.

Сервіс орієнтовний підхід. Кожний сервіс має свій чіткий TOS, свій чіткий SLA...
І вигідніше більше сервісів, ніж змінювати SLA

Тут гарно було б показати цю генезу на слайдах, але — на жаль — пряма публікація заборонена...
Якщо буде цікаво подробніше — раджу подивитися на dxc.com — там багато розписано з тенденцій куди що йде... Саму ж логіку я описав...

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

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

Прикоад із індустрії перевезення речей. Коли будете переїжджати порівняйте як швидко працюють вантажники в компанії яка бере оплату за відстань переїзду (отримає гроші не залежно від того скільки пішло часу) і компанію яка бере гроші за витрачений час. Повірте перші працюють набагато швидше.

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

ваш роботодавець отримує гроші ЗА розробку програмного забезпечення

Зовсім ні! Ви про що??? Який код? ..таке враження що Ви мислете категоріями шаражки з п’яти програмістів....

Сервіс з розробки, надання та супроводження екслюзивних РІШЕНЬ для потреб клієнта.
На корпоративному ринку з серьозними компаніями зараз нікого не цікавить «розробка програмного забезпечення». Це ж як — Ви там шось розробили, втюлили нам — а ми далі масти з цим голову???

Це як фінансова система. Оце Ви домовилися з банком про те, що ваші робітники отримають зарплатні картки — на певних спеціальних умовах для вашої фірми, тощо. То по вашому — Visa тепер оутсорс вашої бухгалтерії???

Розумієте, реалії Інформаційного Суспільства зовсім інші ніж реалії Індустріального Суспільства.

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

Але ми вже давно живемо в Інформаційному Суспільстві.
І тут все є сервіс. ВСЕ.

Ви не купуєте мобілку. Ви купуєте певний сервіс. (Привіт мобілки ща 1 гривню! :) )
Ви не купуте автівку. Ви купуте певний сервіс. (Гарний тут приклад — Тесла, де помінявши прошивку Ви реально тримуєте нову машину — більше швидкість, потужність, тощо...)

Ви колись купляли роутер Cisco? Вартісь заліза у вартості сервісу максимум відсотків з десять...

І стоп. Топ один фірма світу — Amazon. Що вони продають??? Сервіс.
І ми, DXC, як топ десять фірма світу, так само продаємо СЕРВІС.

Звісно, свій сервіс Ви можете називати як завгодно.
Але це буде сервісом і правильно поінформований клієнт вимагатиме від вас всіх тих формальних параметрів, які характеризуть сервіс.
Першим чином це TOS (Type of Service) та SLA (Service layer agreement)

Цікаво що TOS вийшло з царини мережових технологій:
мінімальна ціна, гарантована доставка, максимальна доступність, інтерактив.
Хоча потім це було гарно доповнено Amazon:
PaaS, IaaS, SaaS та т.п.

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

Більш того.
От є open source. І є багато фірм, котрі його продають.
Як вони його продають? Вони продають сервіс!

А великі гравці? Всі великі гравці продають сервіс.
Microsoft, Google, Apple, Oracle, Red Hat --- всі мають «subscribe» продаж. Тобто продаж «підписки» на сервіс...

Звісно, Україна розколота на дві країни — сучасну та старовинну.
Сучасна є успішною, сучасна є Інформаційним Суспільством та Економікою Знань.
Старовинна є лузерською, старовинна застрягла в Індустріальному Суспільстві.

І доки в вашій голові мислення Індустріального Світу, доти цей розкол рватиме країну на частини...
Будьмо успішні! :)

Написано красиво, подробно, но, опять же, есть буквально пара ключевых отличий:

1) продуктовая контора изучает потребности рынка, за взятые в долг деньги, рискуют, создают прототип и в случае успешного нахождения своей ниши — навязывают свой сервис и своё видение рынку.
2) настоящая продуктовая контора не аутсорсит разработку своих ноу-хау. Соответственно, её работники работают долго и не конкрируют вниз по цене своего «сервиса». Если сервис «не идёт» на рынке, то они просто банкротятся и уходят с рынка.

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

Я лучше поработаю в небольшой продуктовой компании, чем в бодишопе под названием Люксофт. Нашелся фанатик компании, который тут отстаивает её, мол не аутсорс, не Бодишоп, да-да. Устроился к ним в компанию, в проект, а самого Люксофта почти не было, все ресурсы уходили в сеть или ПО клиента.

Тяжело быть слугой двух господ. ...любой разработчик .NET — он в первую очередь разработчик Microsoft. И в этом есть своя логика, многолетняя отточеная селекционная работа корпорации. Для разработчика .NET (по личному опыту) существует два варианта решения — решение от Microsoft и ...еще лучшее решение от Microsoft.

И, конечно, я абсолютно не удивлен что .NET разработчик не нашел в себя в корпорации, требующей гибкого и креативного подхода, которой есть на сегодня DXC/Luxoft.

Фанат своей компании, как я говорил. Тебе за это руководство премию начисляет? Я не только .net разработчик, я ещё и по Angular. С вами общаться дальше не о чем. Точка.

1) продуктовая контора изучает потребности рынка, за взятые в долг деньги, рискуют, создают прототип и в случае успешного нахождения своей ниши — навязывают свой сервис и своё видение рынку.

Найдите разницу:
«Сервис ориентированая компания» изучает потребности рынка (а как без этого???), за взятые в долг деньги (деньги всега берутся в долг, даже когда в долг берется у вышестоящего холдинга — деньги всегда нужно возращать), создают прототип (который иногда называют «golden source») и в случае нахождения своей ниши (собственно ниша — это потребность, которая не охвачена в нужной мере каким либо сервисом) — навязывает свой сервис и свое видение (то есть — свое решение) рынку (который конечно бывает разный — так, для одниз рынок — это «пользователи Фейсбук», для других — «подразделения определенного банка», а для третих «ОТП рынок межбанковской торговли»)....

2) настоящая продуктовая контора не аутсорсит разработку своих ноу-хау. Соответственно, её работники работают долго и не конкрируют вниз по цене своего «сервиса». Если сервис «не идёт» на рынке, то они просто банкротятся и уходят с рынка.

..весьма спорно.

не аутсорсит разработку своих ноу-хау.

Двадцать пять лет назад — может быть...
В теперешнем сервес ориентированом мире... Вы уверены? :)
Разработчики используют IDE — это уже половина разработки проведена фирмой, которая выпустила IDE.
Используете что-то не написаное вами «from scratch» — это уже часть разработки взяла на себя или опен соурс коммюнити, или разработчик базы данных, или ...много или.
PaaS, IaaS, SaaS — Вы что, собираетесь это все сами?

работники работают долго

Современный подход, родом из Силиконовой Долины — разработчик работает на проекте от трех до пяти лет. Если работает долше — ему крайне не просто потом найти новый проект, так как все считают что он остановился в развитии.

не конкрируют вниз

Это точно совковый подход.
Вам дают платежку на газ и «не конкурируют вниз» сами с собой...
Даже «НафтоГаз» уже придумал тут кейсы! :)

Если сервис «не идёт» на рынке, то они просто банкротятся и уходят с рынка

— это принцип старт-апов. И все всегда начинается именно как старт-ап...

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

Тут точно нужно вспомнить анекдот:
— Какие грибы можно есть?
— Грибы можно есть все. Но некоторые только один раз.

Нет риска — но и маржа ничтожна

Контроль рисков — одна из основ «правильного бизнеса».
А где рисков больше — ...милиардные убытки некоторых корпораций тому хороший ответ.

Но и тут «совковый подход». В глазах дяди Васи сторожа «усі крадії, бо звідки в них гроші?».
Ага, «там на верху делают делюгу, а нам тут откинули...»
Или «мы делаем чесную продуктовую компанию, которая не идет на „договоренности за деньги“ с крупными игроками...»

...хм... конечно это иногда и имеет место быть, но снова — всего лишь от недостаточного качества правоохранительного сервиса, который — мы верим — таки с каждым днем улучшается... :) Да и теневые сервиса — тоже сервиса...

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

Во... вот это подход индустриального мира...
И, вполне реально, что так бы и оставалось, если бы не пришли времена Информационного общества.

Сравните.
Для индустриального мира (все товар):
— Наш товар лучше вашего, так как он дешевле.
Подразумевается что товар-то одинаковый, только дешевле.
Конечно, не говорится о качестве товара, не говориться о условиях поставки, не говорится о том, что нужно будет потом и т.д.
Конечно, можно все записать в договоре, но ...непоинформированого клиента легко обмануть, забыв про некоторые «тонкие моменты, известные специалистам».

Это как в конкуренции интернет провайдеров, когда говортся про «сто мегабитный интернет дешевле некуда» ...и умалчивается что сто мегабит только до роутера провайдера, CIR — гарантированая полоса — 25%, большая задержка и т.д.

Для информационного мира (все сервис, поинформированый клиент)
— Наш сервис лучше вашего!
...а дальше четко конкретные формализованые кретерии сервиса, про которые точно знает поинформированый клиент (или гугль его знает...) :)

Но это еще далеко не все.
Потребности поинформированого клиента всегда возрастают.
Красиво это описывается на примере рынка видео продукции.

Двадцать лет назад большинство телеканалов областного уровня могли себе позволить снимать на VHS и давать в ефир обычный PAL.

Сейчас норма full HD и довольно высокое качество самого контента. ...люди другого бы уже не восприняли, потому что привыкли...

...но стоп. С другой стороны, милионы снятого на мобильный с минимальным качесвом контента на YouTube...

Почему?
Двадцать лет назад это был товар.
Который ...«пипл хавал».

Сейчас это сервис. Сервис с четким TOS (Type of Service) и, как следствие, вполне конкретное, соответствующее типу сервиса, ожидаемое качество сервиса.
И если сервис — телеканал или ютюб-видеоролик, то и ожидаемоке качество соответствует данному типу сервиса. Хотя оба сервиса — вариант сервиса по видео...

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

— всі крадуть, бо звідки в них гроші?!
— ну як, дядя Вася, бізнес!
— знаємо той бізнес! Федько поїхав до того міста у хфірму, пів року попрацював — приїхав взад — грошей нема, самі кредити...
— ну так там треба фахівців може?
— які фахівці? Оце Дуська п’ятьдесєть років на бураках відпрацювала, а як голова свій заводик побудував, то вона вже «не спеціаліст!»... ...а понабирав молодь... чому? Бо я тобі скажу так — вони йому половину зарплатні віддають — ось він іх і бере! ...а ти спеціалісти...
Всі злодії, всі крадуть!

Ну где-то так.
И повторюсь.

Теперешняя Украина расколота надвое.
Одна Украина считает что «Все хорошо!».
Вторая Украина считает что «Все плохо!».

ИТ бизнес ну никак не относиться ко второй части Украины.
И позитивный подход — один из базовых soft skills который should be.

Недавно была история.
Участвую как тим лид на RMI интервью...
Девочка QA говорит:
— Вот Вы так красиво про Luxoft рассказываете, а я тут читала... некоторым не понравилось на вашей фирме...
— Ну это логично. Те, кому не нравилось, ушли. Остались те, кому тут нравится...
И всегда же лучше работать в позитивной атмосфере!

Якщо дивитись світові огляди по мовам, то тайпскрипт там не згадують в п’ятірці навіть))

От якби ви дали лінк на ці «світові огляди», ваші слова не були б порожніми.

Браузер-> гугл -> top 5 program languages.
Не дякуйте.

А ще можна глянути на рейтинг від гітхабу.
Сподіваюсь, що мої «порожні» посилання не потрібні)

Ви мабуть плутаєте абсолютні цифри популярності із динамікою популярності.

Дякую, що виправили речення. Бо поняття динамічної популярності я таки не знаю, і це правда. Але назва статті говорить про рейтинг мов вцілому.
Якщо про динаміку популярності, тоді питань немає)

Первый график — популярность по использованию — в нем TypeScript на 6 месте

Але, наскільки я бачу, це графік використання в Україні

... о чем говорит второй абзац статьи: «Представляємо результати щорічного опитування щодо мов програмування. Цього разу зібрали 7211 анкет, 92% респондентів перебувають в Україні. Поїхали.»

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

— як дізнатись, що розробник пише на TS?
— він сам тобі розповість

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

В общем, надо переходить на Python и TypeScript.

Як і в попередні роки, більшість респондентів (83%) хоче вивчати нову мову самостійно, за допомогою книжок і документації, 4% будуть шукати допомогу в колег (вражаюча інтровертність), а 12% використовуватимуть традиційний підхід — з допомогою професійних викладачів (курсів або індивідуальних занять).

З якого це моменту традиційним способом по вивченню чогось в програмуванні стали курси? Думаю тут традиційним підхідом треба вважиати «вивчати <що завгодно> самостійно», що в принципі і демострується в цьому рейтингу із року в рік.

Погоджуюсь. Особливо раніше, років 10-15 назад, навіть якщо ти закінчив технічний ВУЗ, для ІТ-галузі це дуже мало чим допомагало, треба було усе самому вивчати по інтернету.

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

Це логічно. Маючи 30 років в ІТ та вже практично 15 в Java, окрім роботи, мушу постійно приймати участь в опен-соурс пректах (наприклад JHipster, TensorFlow, ...декотрі проекти JBoss коммюніті) для того, щоб «лишатися на передовій»...

А що викладач курсів? В нього там шось склалося в голові. Він вважає що то є правильне...
А Світ давно вже пійшов вперед...

Звісно, багато залежить від людини. Так, мій бувший тім лід — Джошуа Річардсон, котрий зараз викладає у Стенфорті, — таки лишається на передовій... Але то більше спілкування з такими (спільними) друзями як Мартин Фаувлер, Роберт Мартин та іншіми...

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

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

Ше одне.

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

У різних фірм ріний підхід. В нас, наприклад, одним з шости обов’язкових принципів роботи програміста записано комунікабельність --- і на тренінгах приводяться приклади коли людина не встигла вчасно зробити свій таск, але допомогла іншим — і вона молодець...

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

...тож, тут потрібен компроміс...

Щоб розбавити... історія з реального життя — середина 90-х, FIDO концеренція...

Людина запитує — «А чи можна в цей слот ставити такий-то процессор».
Йде відповідь — «Можна».
...За певний час людина пише — «Вставив, проц згорів!»
Йде відповідь — «Виходить що ніззззя...»

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

Не тямлю цих стереотипів про інтровертів.

Лідер по динаміці — однозначно TypeScript. Це не може не тішити реальних пацанів.

Для реальних пацанів вже є свій діалект YoptaScript

Фу, мейд ін раша... То реальні пацани, але тільки у себе на районі.

Фух, оказывается гопники тут и там разные... Будьте аккуратны с продуктами Jetbrains, и т.д.

Будьте аккуратны с продуктами Jetbrains,

Не використовую це гівніще, хоча у мене є можливість використовувати їхні продукти ліцензовано і безкоштовно. Для розробника, що пише на TypeScript, з головою вистачає VS Code, причому ця IDE об’єктивно краще розуміє TypeScript.

А в нього є життя за межами ангуляра, щоб на ньому прямо так «писали» ?

Повно! Навіть свідки Реакту на нього переходять.

Кількість скачувань Angular — майже 2.5 млн. на тиждень, а кількість скачувань TypeScript — 17.5 млн. на тиждень.

Є веб-сервери написані з нуля на ньому, наприклад, NestJS, його скачують вже більше 500 тис. на тиждень. Fastify хоча і написаний на JavaScript, але має TypeScript типи, його теж скачують майже 200 тис. за тиждень.

А ще на ньому написано VS Code і плагіни до нього...

Подписаться на комментарии