Stack Overflow опубликовал рейтинг любимых у разработчиков языков программирования — на первом месте Rust Статьи редакции

Для рейтинга опросили 83 тысячи специалистов.

  • Один из крупнейших форумов для разработчиков Stack Overflow опубликовал ежегодное исследование рынка ИТ. В нём составил рейтинг языков программирования, с которыми разработчикам больше всего нравится работать. Кроме Rust в пятёрке любимых языков — Clojure, TypeScript, Elixir и Julia. Python — на шестом месте, JavaScript — на пятнадцатом.
Десять языков программирования, с которыми разработчикам приятнее всего работать Stack Overflow
  • Rust возглавил список Stack Overflow и в 2020 году. Среди плюсов разработчики называют безопасность работы с памятью и производительность.
  • Лидерами антирейтинга стали COBOL, VBA и Matlab.
Языки программирования с наименьшим количеством положительных оценок Stack Overflow
  • Среди облачных платформ на первом месте — Amazon Web Services, на втором — Google Cloud Platform, на третьем — Microsoft Azure.
  • В исследовании также есть рейтинг зарплат в ИТ и другие показатели. По данным опроса 43,8 тысячи респондентов, больше всего зарабатывают управленцы (медианная зарплата в год $96 тысяч), senior-разработчики ($94 тысячи в год) и SRE-инженеры ($84,3 тысячи в год).
Уровень зарплат в ИТ и стаж работы специалистов Stack Overflow
0
255 комментариев
Написать комментарий...
Denis Kiselev

Язык программирования Node.js. Хм. При этом - JavaScript отдельно. И TypeScript выше. Хм.

Ответить
Развернуть ветку
Антон Семенов

Да потому что рейтинг не про языки а про Топики. А редакция vc.ru недавно закончила курс от ЛохБокса что даже в пагинацию коментов не могут

Ответить
Развернуть ветку
symbix

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

Ни разу не видел хоть сколь-либо удобной реализации.

Ответить
Развернуть ветку
Антон Семенов

Я про бэкенд говорю. У vc.ru идет 1 запрос на ВСЕ комментарии. Среднее время ответа 20 секунд если комментариев 900. А если их будет 10000? Простая пагинация и банально ограничение респонса это какие-то очевидные вещи для младенцев. А vc.ru не умеет

Ответить
Развернуть ветку
symbix

Когда со своего начального уровня знаний кажется, что что-то сделать просто, сделает остановиться и продумать все детали. Потому что тут всё не так просто. Бэкенд должен позволять реализовать логику фронтенда, а вот она совершенно не очевидна.

При древовидных комментариях банальный лимит-офсет ничего не даст. Например, из 10000 комментариев 9000 могут быть ответами на первый ответ на первый ответ на первый ответ на первый ответ на первый комментарий. Да и по какому полю order? По materialized path? И отрезать ветку посередине в случайном месте? И подгружать по скроллу? С таким подходом будет более-менее окей для первого прочтения комментариев, но при ведении дискуссии придется скроллить и в итоге все равно грузить всё подряд, ждать каждый раз загрузки по мере прокрутки, пока докрутишь до своей ветки - это не юзабилити, а задница. Или по первому уровню с оконной функцией? Что тогда делать, если большинство комментариев не на первом уровне, или вырожденный ранее приведенный пример? Куча вопросов.

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

А ещё предлагаю подумать над тем, как тогда будет устроена VC-шная кнопка перемещения по новым комментариям. И как можно сделать более-менее эффективное кэширование с полноценной инвалидацией и приемлемым соотношением hit/miss.

Я уверен, что подобная дискуссия у разработчиков движка VC была, все эти проблемы были озвучены, и в итоге менеджер разумно решил - да хер с ним, грузи всё сразу.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Stavr Ognev

Использовать noSQL?
Хотите настоящей уличной магии - посмотрите скролл чата Дискорда с историей лет в 8.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Stavr Ognev

Ну так я про это и написал. Думаю, тут как раз классическая (ещё и "бесплатная)" СУБД используется.
P.S. Никто не пишет коммерческие проекты с прицелом на рост "через много лет". Дыры в стартовой архитектуре латаются уже у идущего на полных парах судна.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Степан И.
Думаю, тут как раз классическая (ещё и "бесплатная)" СУБД используется.

OpenSource != бесплатно.
Платные типа Oracle используются в банках.
Остальные открытые (как вы говорите "бесплатные") идут с платной поддержкой.
Сейчас нет тормозных баз, есть кривые запросы, кривой код, само построение базы и архитектура.

Ответить
Развернуть ветку
Stavr Ognev
 OpenSource != бесплатно.

Зато есть менеджеры проектов, которые среди OSrc-решений выбирают не платную поддерживаемую версию, а именно что бесплатную "community". А потом ещё на сопровождение её либо "да своих людей обучим, как два пальца", либо ищут на вакансию сотрудника с ценником в 2 раза ниже рынка.

Ответить
Развернуть ветку
252 комментария
Раскрывать всегда