Программирование постоянно развивается, а с ним и языки программирования, которые используются разработчиками. Чтобы быть успешным в мире IT, важно выбрать актуальный и востребованный язык программирования для изучения. Мы решили провести голосование, чтобы выяснить, какие языки программирования считаются самыми актуальными и популярными, а какие самыми неактуальными среди представленных в 2023 году по версии пользователей Habr.
1. Python
Python — язык программирования общего назначения с простым синтаксисом, что делает его идеальным для начинающих. Востребован в разработке веб‑приложений, научных исследований, машинного обучения и искусственного интеллекта. Благодаря богатой экосистеме библиотек и инструментов, Python продолжает удерживать позиции лидера.
2. JavaScript
JavaScript остается основным языком для веб‑разработки, отвечая за интерактивность и динамичность сайтов. С развитием фреймворков и библиотек, таких как React, Angular и Vue.js, JavaScript стал неотъемлемой частью современной веб‑разработки.
3. Java
Java занимает особое место среди языков программирования благодаря своей платформенной независимости и масштабируемости. Широко используется для разработки Android‑приложений и корпоративных систем. Обучение Java открывает доступ к широкому спектру возможностей в разных отраслях.
4. C#
C# разрабатывался Microsoft как часть платформы .NET и считается одним из самых универсальных языков программирования. Применяется для создания десктопных, веб‑ и мобильных приложений, а также игр на платформе Unity.
5. Kotlin
Kotlin — современный язык программирования, разработанный JetBrains, который быстро набирает популярность благодаря своей совместимости с Java и удобству использования. Google официально поддерживает Kotlin для разработки Android‑приложений, что делает его востребованным языком среди мобильных разработчиков.
6. Swift
Swift — язык программирования, разработанный Apple для создания нативных приложений на платформах iOS, macOS, watchOS и tvOS. Быстрый и безопасный, Swift стал ключевым инструментом для разработчиков Apple и отличным выбором для тех, кто хочет заниматься разработкой мобильных приложений.
7. Go
Go, или Golang, — это язык программирования, созданный в Google для решения проблем масштабируемости и эффективности. Он легок в изучении, быстр и надежен, что делает его популярным для создания высокопроизводительных систем, таких как облачные сервисы и сетевые приложения.
8. Rust
Rust — язык программирования, разработанный Mozilla с акцентом на безопасность и производительность. Благодаря своим уникальным механизмам управления памятью и подходу к параллелизму, Rust привлекает внимание разработчиков и становится привлекательным языком для изучения.
9. TypeScript
TypeScript — это надстройка над JavaScript, разработанная Microsoft для улучшения статической типизации и масштабируемости кода. TypeScript позволяет обнаружить ошибки на этапе написания кода, что повышает качество и надежность разрабатываемых приложений. Интеграция с популярными фреймворками делает TypeScript востребованным языком среди веб‑разработчиков.
10. Ruby
Ruby – еще один язык программирования общего назначения, известный своим выразительным и читаемым синтаксисом. Основным преимуществом Ruby является фреймворк Ruby on Rails, который значительно упрощает разработку веб-приложений и делает Ruby актуальным для веб-разработчиков.
Почему участие в голосовании за самые популярные языки программирования в 2023 важно?
Участие в голосовании поможет определить актуальные тенденции в области программирования и даст представление о том, на какие языки программирования стоит обратить внимание. Ваши голоса помогут другим разработчикам и новичкам в IT‑индустрии определиться с выбором языка программирования для изучения и развития своей карьеры. По истечению недели мы отредактируем список статьи с топ-10 языками программирования для изучения в 2023 основываясь на результатах голосования.
Не забудьте продолжать изучать новые технологии и следить за тенденциями рынка, чтобы всегда оставаться в курсе последних разработок и сохранять свою конкурентоспособность. Удачи вам в освоении актуальных языков программирования в 2023 году и в развитии вашей карьеры в IT!
Комментарии (221)
dark_ruby
00.00.0000 00:00+9логотип для раста у вас не правильный, тот что у вас от игры, а не от я.п.
SergeyTatevosyan
00.00.0000 00:00+16Зря вы так про VBA, он очень даже актуален в некоторых компаниях :D
ReadOnlySadUser
00.00.0000 00:00+10Я бы так сказал, если бы тут на хабре тусовались представители профессий, которые 90% времени сидят в excel, думаю оценки для этого языка улетели бы просто в космос :)
wolfy_str
00.00.0000 00:00Java лучший. Правда на собесах замотают) Жаль что уступил не только питону.
evgenyk
00.00.0000 00:00+4Toolchain у него неудобная и слишком болтливый.
ris58h
00.00.0000 00:00+1Toolchain у него неудобная
По сравнению с чем?
и слишком болтливый.
Это что значит?
evgenyk
00.00.0000 00:00+5С питоном, ясное дело, с чемпионом.
Болтливый, значит нужно больше написать текста для получения того же результата.
iskateli
00.00.0000 00:00+8"Болтливый, значит нужно больше написать текста для получения того же результата."
зато прозрачно и понятно всё, а то в некоторых языках настолько высокий уровень абстракции, что непонятно, как оно там под капотом работает и при каких условиях, приходится в голове держать многое
Homyakin
00.00.0000 00:00+3Кому болтливый в минус, кому в плюс. Лично мне читать джавовый код намного приятнее как раз из-за его многословности.
domix32
00.00.0000 00:00+3Видимо именно поэтому продвинутые IDE схлопывают все паблик стейтик джава точка ланг точка обджект ру точка тиньков ангшенс точка аф джава точка ланг точка буллин джава в заголовке.
wolfy_str
00.00.0000 00:00+1что такое Toolchain?
evgenyk
00.00.0000 00:00Это комплекс инструментов, для того, чтобы писать программы и запускать и отлаживать код.
vedenin1980
00.00.0000 00:00+1А какие претензии у вас к Intellij Idea? И в чем там разница с каким-нибудь Intellij PyCharm? Или вы говорите о встроенный командных утилитах вроде javac? Но кто их использует на реальном большом проекте?
comdivuz
00.00.0000 00:00+1Претензии не к idea а отсутствия как такового встроенного тулинга. Если не работаете с новым поколением языков типа go где всё типовые вопросы а-ля тестирование, пакетныйменеджер, профилирование, авто форматирование, линтинг, покрытие, кодогенерация и прочее идёт из коробки и очень простое, то вам сложно понять что не так с Java или C++. Настройка авто сборки того же голанга пара простых команд в makefile. Адекватная же сборка на gradle, npm, CMake, это уйма копипасты или тайных знаний и привлечения всякого набора внешних средств.
wolfy_str
00.00.0000 00:00-1да. Зато это требует специалистов, а значит будет работа) А когда отваливается версия компилятора это нечто. Поначалу такое было, потом как то прошло. Не правильно выбранная версия проекта это полбеды, это ерунда, а когда слетали внутренние настройки. Обычно программы притераются и уже не ломаются так :) У меня такое с любым новым софтом. Да, мне сама IDEA не особо нравится на английском и куча настроек, а не комбайн как MS Visual Studio (и есть на русском). Да, только студио использовал для обучения, а джаву для работы. Потому спустя пару лет среда для меня чёрные ящик, ну не совсем, но отчасти. Я не против английского, но можно было прикрутить русские скрины, тем более разработчики русские. Я имею ввиду разработчики среды. Если бы работал на зарубежного заказчика, жил бы в Европе, Америке или Австралии тогда да, притензии к английскому софту обсурдны, но для России лучше качественно переведённая среда, так как утопаешь в настройках, но спустя даже годы не можешь всё запомнить, тебе это не особо нужно, а мозг отказывается в этом разрабираться. А они знаете что сделали? Просто ушли из-за санкций. К санкциям у меня неоднозначное отношение, где то поддерживаю, где то нет, но тут просто решил что мне ничего не мешает пользоваться кракнутой юльтимейт версией IDEA тем более это делается за пару минут.
Сейчас у меня основная притензия - куча зависимостей, которые не дружат друг с другом, иногда конфликтуют, иногда (редко) ломается сама среда, починить её сложно, так как она сама по себе довольно сложная. И практически всегда пакеты перекрывают друг друга, то есть лишние зависимости будут.
vedenin1980
00.00.0000 00:00+7а отсутствия как такового встроенного тулинга.
Это не баг, это фича. Изначально, jvm разрабатывали множество разных компаний и сейчас есть десяток альтернативных реализаций jvm полностью проходящих необходимые тесты по спецификации каждой версии.
То есть, у java сознательно в ядро языка вносили лишь самое важное, а многие вещи специально оставили для реализации другими компаниями (например, работу с базой данной или создание микросервисов/Rest). Идея оказалось хорошей, потому что так получались лучшие инструменты, чем если бы был один стандартный способ.
MountainGoat
00.00.0000 00:00-1Вот к этому и претензия. Приходишь в другой проект - а там другой инструментарий для тех же самых целей. Ещё и платный то и дело. Потому что стандартный метод многих не устраивает.
vedenin1980
00.00.0000 00:00+4Потому что стандартный метод многих не устраивает.
В Java специально так сделали — если бы был один стандартный метод, другие методы просто не возникли бы. А за десятки лет выяснилось бы что стандартный метод плох, но все кололись, но использовали его бы. Особенность open source философии Java — только самые важные вещи должны быть в самом языке, чтобы его легко могли реализовывать разные вендоры. А все остальное (jpa, jree, spring, ide, системы сборки) — максимум спецификации и интерфейсы для стандаризации. Это позволяет конкурировать разным проектам и выживать наиболее популярным. Именно поэтому java сильна инфраструкторой.
Приходишь в другой проект — а там другой инструментарий для тех же самых целей.
Давно не видел нигде ничего кроме Idea, сборки maven/gradle и т.п.
Ещё и платный то и дело.И что? Это головная боль работодателя, если он не готов заплатить 200$ в год за инструментарий, то и зарплату он вам посторается зажать.
wolfy_str
00.00.0000 00:00вообще то не единым pyCharm'ом. Сам я не питонист, но удивился какой простой интерфейс у встроенного редактора, colab. https://colab.research.google.com/ Каждая ячейка это отдельная программа, при том ячейки последовательно инициализируются, можно сохранять. Очень классный инструмент
aPiks
00.00.0000 00:00Зато поддерживать его и через 5 лет можно, а не один раз написал и молиться, чтоб там ничего не сломалось, пока другой команде сервис не уйдёт.
mymailru
00.00.0000 00:00автор, а добавьте плиз Паскаль (Lazarus и Delphi) и еще zero Coding - (blueprint Unreal Engine и аналоги в Unity и других игровых движках и проектах)
zarytskiy Автор
00.00.0000 00:00done
longclaps
00.00.0000 00:00+6Языка программирования с названием Lazarus не существует.
Lazarus - это IDE для паскаля, так же как и Delphi.
geher
00.00.0000 00:00+2Языка lazarus, действительно, не существует. Это графическая IDE для FPC (который, в свою очередь, вроде умеет и Object Pascal, и Delphi). А вот с Delphi не все так просто. Это не только IDE, но и язык программирования, несколько отличающийся как от классического паскаля, так и от экзотического Object Pascal. Одни считают его диалектом паскаля. Другие - самостоятельным языком.
iskateli
00.00.0000 00:00+2Julia ещё добавьте пожалуйста, часто в ML проектах, моделировании и научных расчётах используется. А Clojure чего кстати забыли? ни одного языка семейства Lisp
hatman
00.00.0000 00:00+14
Даже смешно, как низко рейтят PHP, когда это сейчас самый популярный язык для корпоративных стартапов в РФ вместе с GO.
SerJook
00.00.0000 00:00+1Популярность это хорошо, но как насчет удовольствия программиста от использования языка? Это тоже немаловажно. Согласитесь, язык корявый.
treppilk
00.00.0000 00:00+19Не соглашусь, язык удобный. Был корявым лет 5 назад. Уже версия 8.2 вышла. Посмотрите, насколько далеко шагнул язык
s207883
00.00.0000 00:00-9Я посмотрел, выпал в осадок, когда как фичу представляли возможность указать, что метод возвращает только true/false/null. Если это не пробивает дно, то, как минимум, его царапает.
s207883
00.00.0000 00:00+5Откуда инфа? Готов поверить, что корпораты будут за Java, либо что-то модное и стильное, но пыха?
init0
00.00.0000 00:00У вас извращенное понимание того, что выбирает крупный бизнес. Не " что-то модное и стильное ", это вам к различного рода стартаперам и другим любителям смузи, корпорации берут то, что проверено годами и имеет качественную поддежку, да, конечно Java (Spring итп), но и Symfony с Laravel не далеко ушли.
s207883
00.00.0000 00:00Я примерно в таком и работаю и вижу, что выбирают либо java/c#, либо берут что-то древнее и допиливают под себя, либо стильное и модное.
У нас так в одной группе собрались команды на ts, c#, java, prolog и ещё одна команда выбирает на какой язык перейти(не помню на чем пишут), из питона и c#.
Так и получается, что либо стильное, либо старое, либо стандартное. Может быть где-то и пхп есть, но не у нас.
tommyangelo27
00.00.0000 00:00На прологе и С# под веб пишут?
MiraclePtr
00.00.0000 00:00А в чем проблема с C# под веб? Это так-то одно из его самых сильных и часто используемых применений.
tommyangelo27
00.00.0000 00:00+1Проблем нет, просто сравнивать php, который про веб-разработку в 99,9% случаев, имхо стоит с типично-веб языками. У C# сфера применения значительно шире (опять же, насколько я знаю).
Допускаю, что неправ.
Rinat111
00.00.0000 00:00+3Fortran язык математиков. Если вы с ним не столкнулись, то изучать всё таки не стоит.
salkvus
00.00.0000 00:00+2Добавьте, плиз, Haskell, OCaml, Racket
zarytskiy Автор
00.00.0000 00:00Добавил
lil_master
00.00.0000 00:00Почему такая предвзятость к языку программирования Dart, что его нет в списке?
Неужели ABAP мощнее и популярнее?
Dart - отличный язык, Flutter - отличный фреймворк, и очень удобные инструменты для разработки.
Добавьте пожалуйста Dart в список.
AnthonyMikh
00.00.0000 00:00Почему такая предвзятость к языку программирования Dart, что его нет в списке?
А для чего он используется, кроме Flutter?
slsktnkv
00.00.0000 00:00+1Оказывается, C&C++ любят больше всех (кроме питона). Может, стоило их разделить?
anka007
00.00.0000 00:00Во первых у них есть свои области применения, где заменить их никак не получается (только точечно, с большим количеством ограничений). Во вторых их можно сравнить с латынью для медиков: до свободного владения учить не обязательно, но как минимум читать код и писать простейшие программы уметь надо.
TrueBers
00.00.0000 00:00Что это за области такие, где нельзя заменить Си? На полке в музее?
Flux
00.00.0000 00:00+12Вы написали эту шутку за 300 пользуясь ОС ядро которой написано на С, отправили в сеть с помощью протокола реализованного на С, а на конечных устройствах эти бесполезные буквы были отрендерены библиотекой написанной на С с помощью драйвера написанного на С.
MiraclePtr
00.00.0000 00:00+8Но все что вы описали совершенно не свидетельствует о том факте, что при написании подобного софта C невозможно заменить ни на что - даже хотя бы на тот же Rust (не без unsafe, но это не важно).
То, что пока во всем этом главенствует C, во многом идёт от того, что 30-40 лет назад, когда оно все начиналось, приемлемых альтернатив ещё не существовало, а сегодня, естественно, никто просто так это выкидывать не будет, поэтому продолжают использовать. Хотя в том же чисто Сишном ядре Linux недавно разрешили писать драйвера на том же Rust :)
comdivuz
00.00.0000 00:00Но опрос то проведён здесь и сейчас и много где C++ незаменим, например в геймдеве серьёзном. Понимаете некоторые вещи не заменимы не потому что ничего нет что выполнило бы их функцию, а потому что никто и не пытается их менять,
TrueBers
00.00.0000 00:00+2незаменим, например в геймдеве серьёзном
Например? Очень хотелось бы услышать, что есть такого в С++ особенного для геймдева?
domix32
00.00.0000 00:00+1Две крупнейших платформы для разработки игр (Unreal и Unity), и ещё кучка платформ поменьше (Godot и иже с ними) и всякие корпоративные платформы типа Havoc, CryEngine и пр.. Остальные пока ещё getting there и пока ещё не имеет успешных примеров аналогичного уровня.
TrueBers
00.00.0000 00:00+2То, что это появилось в те времена, когда не было альтернатив, не говорит о том, что эти языки до сих пор незаменимы.
Да, изучение нового требует ресурсов: времени, средств, остановки маховика инетрности и изменения направления парадигм мышления. Я с этим ни сколько не спорю, я спорю с конкретными формулировками этой ветки коментариев вида "С++ незаменим", "невозможно игры писать на чём-то ещё", "кроме Си и С++ ничего не нужно" и подобными риториками прошлого тысячелетия, когда был один язык, один компилятор и непреодолимое чувство творчества.
Aldrog
00.00.0000 00:00Я бы сформулировал по-другому: пока не наблюдается языков, готовых заменить C и C++. Rust пока ещё слишком молодой и непопулярный, чтобы можно было уверенно сказать, что он их способен заменить, а прочие языки либо ещё мельче, либо обладают особенностями вроде сборщика мусора, не дающими заменить C/C++ в ряде областей.
MiraclePtr
00.00.0000 00:00Эм... Нет. В русском языке "незаменимые" - это именно что когда вообще нет альтернатив, выполняющих ту же функцию со сравнимыми характеристиками = невозможно заменить.
НЕЗАМЕНИМЫЙ — НЕЗАМЕНИМЫЙ, ничем незаменяемый, незаместимый, невозместимый, невознаграждаемый чем иным, не могущий быть заменен. Толковый словарь Даля В.И.
nuclight
00.00.0000 00:00-3Rust (не без unsafe, но это не важно).
Это важно. Без unsafe от Rust нет никакого смысла, особенно в перечисленных областях типа ядер ОС.
MiraclePtr
00.00.0000 00:00+2— Си не заменить ничем!
— Можно заменить его на Rust
— Нет, Rust обязательно должен быть без unsafe! Нельзя заменить!!!1
С чего должен то? Чем вам unsafe мешает? Он неотъемлемая часть языка и сделан как раз для таких случаев, следовательно, язык очень даже пригоден для подобных юзкейсов.
Это как если бы кто-то сказал, что на Си невозможно писать ядра ОС и работать с железом. Потому что для этого нужны указатели, а мы решили Си должен быть без указателей :)
evgenyk
00.00.0000 00:00Без указателей Си, это уже не Си.
MiraclePtr
00.00.0000 00:00Unsafe - это часть Rust, следовательно, без unsafe Rust это уже не Rust :)
nuclight
00.00.0000 00:00-1С того, что он без safe лишается главной идеи, а значит, становится бессмысленным. Это, действительно, как если бы выкинуть из Си указатели (между прочим, проекты с таким кодом даже существуют).
MiraclePtr
00.00.0000 00:00Не лишается. Ниже уже привели примеры, как даже в unsafe-режиме язык по-прежнему предоставляет больше проверок, гарантий и удобств чем тот же Си.
К тому же, не обязательно писать весь код как unsafe. Хорошей практикой будет использовать unsafe только там, где без него совсем никак, а все остальное писать safe, благо с интероперабельностью в данном случае проблем нет. И итоговый результат будет гораздо лучше.
kovserg
00.00.0000 00:00-1язык по-прежнему предоставляет больше проверок, гарантий
Еще бы эти гарантии чем-то помогали https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust пока только сплошной пиар изо всех щелей. Видимо не хотят хомячки есть кактус.
TrueBers
00.00.0000 00:00+3Перечисленные вами факты -- исключительно историческое наследие.
Я это написал, ответив на фразу "заменить их никак не получается". Вот мне и интересно, у кого не получается? У комментатора? У тех, кто не пробовал? Инертность, "трушность"? Так это тогда не проблема языка, а проблема тех, у кого не получается.
Кто осилил закопать это гавно мамонта, у тех более чем получается. Ни один адекватный человек сейчас не начнёт новый проект на Си, если только не религиозный фанатик.Всё, что осталось хорошего от Си, так это его универсальный ABI, который, кстати, тоже сложился в "стандарт" де-факто сугубо исторически. Остальное давно уже можно безболезненно закопать.
mapron
00.00.0000 00:00Подождите а в чем проблема новый проект на Си начинать? Огромное количество библиотек и готовых инструментов. Можно быстро связать например SDL и ffmpeg. на Rust мало того что новый язык изучать, но еще и разбираться как сторонние библиотеки подключить чтобы компилятор был доволен, на что не каждый согласится. Плюс если вы пишете на Rust обертки над С библиотеками - по сути разработчику проекта надо уже знать ДВА языка, а не один, более простой (С). Не то что все это непреодолимые препятствия (и наоборот, человека который согласится вот это все решить расковырять и объединить - я всецело уважаю!), но не каждый разработчик будет настолько отважен. Я вот лично сколько раз пробую за последние 2 года окунуться в Rust - постоянно зависаю с интеграционными работами.
Про закопать боюсь никакой лопаты и полвека не хватит, чтобы миллиарды строк кода на С закопать) никуда он от нас не денится, еще нашим внукам останется.
TrueBers
00.00.0000 00:00+4еще и разбираться как сторонние библиотеки подключить чтобы компилятор был доволен
У раста ffi-библиотеки любой сложности из коробки собираются и линкуются, ни с чем не нужно разбираться. Сам, когда несколько лет назад учил язык на низкоуровневом хобби-проекте, без проблем и бубнов встроил огромные проекты: язык Dart с его фреймворком Flutter. Сейчас же, с опытом, обернуть либу, для которой внезапно нет готового пакета, занимает пару часов.
никуда он от нас не денится, еще нашим внукам останется
В плане чтения кода на Си, я согласен, он будет жить ещё очень долго, но писать на нём уже мало кто решается.
Взять тот же Гугл, Майкрософт, Фейсбук, Cloudflare, Amazon. Откройте их крайние репозитории, начатые в течение последних 3 лет. Ни ОС, ни драйверов, ни системных утилит, ни реализаций стека протоколов, почти никто из них не начинал писать на Си.
Зато референсные реализации того же WASM, WebGPU написаны на Раст. Ядро HTTP3, протоколы QUIC и WireGuard у Cloudflare реализованы на Раст. В Андроиде на Rust написаны стек Bluetooth, NFC, HAL, гипервизор. Новая гугловская KataOS полностью написана на Раст, включая ядро и драйверы, а в Fuchsia половина кода на нём уже. Майкрософт усиленно пилит биндинги для Windows SDK под Раст.Не знаю, может быть я это замечаю только потому, что я плотно занимаюсь языком уже несколько лет, но по-моему тренды довольно показательны.
постоянно зависаю с интеграционными работами
Странно, по-моему мнению, тулчейн и экосистема Раста -- лучшее, с чем приходилось работать за всю кодерскую жизнь.
mapron
00.00.0000 00:00+4У раста ffi-библиотеки любой сложности из коробки собираются и линкуются, ни с чем не нужно разбираться
ну видимо я с каким-то другим растом работаю :)
> по-моему тренды довольно показательны.мне кажется это эффект наблюдателя какой-то вы именно на это хотите обращать внимание и замечаете. я вот сейчас по работе ковыряю опенсорсный проект на Си который стартанул несколько месяцев назад от силы. А что-то новых проектов на Rust я не замечал (опять же не значит что их нет)
shagonru
00.00.0000 00:00+1Замечать новые проекты на Rust (и не только) весьма просто - достаточно в Github Explore в раздел Trending заходить время от времени, там что-нибудь да встретится. И новые проекты там есть, которые получают интерес сообщества, и старые, взлетевшие после апдейтов. В основном вижу там что-то на Python(привет бум всяких Stable Diffusion, Anything-With-ChatGPT и тд, чуть новость - всё забито этим), что-нибудь из существующих Java-проектов (новых вот убей не помню), обвязки на C/C++, облачные тулы стабильно на Go, какая-нибудь очередная CMS или новый UI на JS/TS, ну и проекты на Rust.
Trending основан не на интересах смотрящего, а на интересах сообщества, так что эффект наблюдателя там не сработает. Вкупе с листами гитхабовскими, помогает расширять кругозор.mapron
00.00.0000 00:00+1https://github.com/trending/rust?since=weekly суммарно 2923
https://github.com/trending/c?since=weekly суммарно 3558
https://github.com/trending/c++?since=weekly суммарно 4186
Окей, довольно объективно. Rust "застаривают" весьма активно. Но я бы не сказал что и старичок Си мертв по такому критерию.
Опять же втупую из этих чисел нельзя никакие выводы делать - я например не дурачок и прекрасно понимаю что а) разработчиков на Rust поголовно раз в 10 меньше чем С и С++ б) разработчики на C куда менее вероятно активничают на гитхабе (по крайней мере все кого я сам знаю лично дикие противники опенсорса, они туда даже и не зайдут)Был неправ, немного заблуждался по активности в Rust, буду иметь в виду. По "актуальности" С пока останусь с прежним мнением.
TrueBers
00.00.0000 00:00+1https://github.com/trending/rust?since=weekly суммарно 2923
https://github.com/trending/c?since=weekly суммарно 3558
https://github.com/trending/c++?since=weekly суммарно 4186
Это довольно абсолютные цифры. Мне кажется, не стоит их учитывать в отрыве от зрелости языка. Раст более-менее стабилизировался и получил популярность только к 2018-й версии, а это всего лишь 5 лет. Менее 5-ти лет стало достаточно для того, чтобы инертные топовые мировые гиганты, которые один надоедливый, всех бесящий баг могут фиксить годами, внезапно увидели в Расте потенциал и массово начали на нём писать свои проекты. Только эти факты дорогого стоят, чтобы судить об успешности технологии.
Гугл в конце 22-го года проводил исследование. С внедрением Раста количество уязвимостей упало на 25%, количество падений из-за повреждения памяти -- на 70%! А это десятки миллионов долларов в их масштабах. И сэкономленные нервы пользователям.
ReadOnlySadUser
00.00.0000 00:00+2Расскажите это embedded-разработчикам :) Они долго будут смеяться про "никто не начнет новый проект на Си" :)
А ещё люди пишут и ещё тыщу лет будут писать модули ядра Linux на Си, просто потому, что это в 100 раз удобнее, чем на Rust.
Free_ze
00.00.0000 00:00+3просто потому, что это в 100 раз удобнее, чем на Rust.
Синдром утёнка никто не отменял)
ReadOnlySadUser
00.00.0000 00:00И это тоже, но не всегда утёнок неправ. Иногда утёнок и правда с первого раза видит свою маму) И вот когда я смотрю на embedded и Си, создаётся у меня ощущение, что здесь всё правильно и хорошо)
Я просто не вижу особо смысла пихать Rust в embedded. Те, проблемы, которые он решает там ваще не возникают зачастую (хотя embedded очень разный бывает, тут уж да). А даже если и возникают, то один фиг со всех сторон придется обмазываться unsafe-ами.
Можно попробовать аргументировать, что вот за обмажемся "unsafe-ами", напишем safe обертки и заживём, но в embedded, не особо-то много логики, которую реально можно так обмазать. Все эти абстракции будут регулярно протекать.
Free_ze
00.00.0000 00:00+1Те, проблемы, которые он решает там ваще не возникают зачастую
Такой embedded подгребет последним, да. Но внедрение поддержки Rust в QNX, к примеру, уже анонсировали в этом году. То есть сегодня вы не видите смысла менять С, как умолчательное решение, а лет через 10-15 лет, когда вокруг будет армия растоманов, переползающих из других областей, все может выглядеть уже не так однозначно: "Зачем брать C, если Rust умеет все то же самое и даже больше?".
domix32
00.00.0000 00:00Там ещё и у FreeBSD оказывается тоже что-то есть по ржавой экосистеме.
domix32
00.00.0000 00:00+2В документации по FreeBSD есть секция, рассказывающая как писать модули ядра на Rust. То есть кто-то сделал похожую работу для ядра FreeBSD, которую делал для ядра линкукс Охеда
nuclight
00.00.0000 00:00Вовсе не факт. Всё может сложиться абсолютно наоборот - мода на Rust пройдет, и лет через 10-15 будут спрашивать "Rust? это что-то типа Delphi?"
Free_ze
00.00.0000 00:00Разумеется) Речь была о том, что не мгновенный набор популярности языка зависит не только от самого языка.
taishi-sama
00.00.0000 00:00+1Delphi убила в первую очередь жадность и медлительность компании-разработчика, а не технические причины. Хотя наличие конкурента в виде C#, который тоже позволяет создавать графический интерфейс под Windows одной ногой закрытыми глазами, тоже помогло смерти Делфи
anka007
00.00.0000 00:00+1Embedded тоже бывает очень разного уровня. Кто-то и питоновский скрипт, запущеный на малинке и дергающий датчик назовет embedded. Есть не слишком дорогие МК на армах, куда даже JVM умудряются впихнуть. А есть какой нибудь batteryless, где даже чистый Си ассемблером для оптимизации разбавляют.
iShrimp
00.00.0000 00:00+4Сфера Embedded - это как машина времени, которая словно переносит вас на 20 лет назад...
anka007
00.00.0000 00:00+1Нет. Просто предметная область предполагает ограниченость вычислительных ресурсов, а за первые десятилетия вынужденной ограничености этих самых ресурсов был найден компромис между человеком и машиной в виде Си и С++. А за последние десятилетия еще и добавился большой пласт legacy в виде библиотек и стандартов де-факто. Слишком глубоко и широко находится С/С++. Заменить на что-то другое будет слишком дорого стоить для всей инфраструктуры.
nuclight
00.00.0000 00:00-1Ни один адекватный человек сейчас не начнёт новый проект на Си
Чего? Это либо толстый троллинг, либо полное непонимание современного положения дел, хотя бы на TIOBE посмотреть. И могут, и начинают, и это адекватнее того же Rust'а.
Flux
00.00.0000 00:00+3Ни один адекватный человек сейчас не начнёт новый проект на Си, если только не религиозный фанатик.
При всем уважении, прочитав ваши комменты я пришел к выводу что религиозный фанатик тут как раз вы, учитывая то как у вас горит седалище от одного упоминания сишки и как неистово вы фапаете на раст.
Извините, но называть неадекватами профессионалов лишь за то что они используют инструмент который вам не нравится - довольно быдланское поведение.
TrueBers
00.00.0000 00:00+1неистово вы фапаете на раст
Не поверите, но за всю жизнь написал всё же больше кода на Си и С++, нежели на Расте.
называть неадекватами профессионалов лишь за то что они используют инструмент который вам не нравится
Да мне ваще параллельно на то, что кому нравится. И Си, и Плюсы, и Раст сам использую по мере надобности без лишних слов. А говорю лишь об упёртости и не желании смотреть в будущее, страхе смерти своего лампового Сишечки. Раст -- это же страшно, это для зумеров, его читать невозможно, а писать так вообще -- руки отсохнут!
Примерно как сравнить людей, кто боится летать самолётом и ездит поездом, убеждая всех вокруг, какие опасные и дорогие самолёты.
Да, оба будут в одной и той же точке рано или поздно. Оба достигнут цели, но тот, кто летел на самолёте ещё успеет погулять, поспать, поработать, пока второй ещё катится по рельсам своего комфорта и стабильности, ковыряясь в дебагере, где у него там чего случилось.Я искренне хочу услышать от людей, кто серьёзно взялся за Раст и с уверенностью может сказать, что технология гавно и не подходит для его задачи. Очень хотел бы посмотреть я на эту задачу и этих "профессионалов". Но обратных же примеров куча. Подавляющее большинство тех, кто взялся за Раст, теперь за уши от него не оттянуть =)
А уж право решать, кто тут быдло, оставлю вам, простите.
ibnteo
00.00.0000 00:00В микроконтроллерах сложно заменить на что-то другое.
TrueBers
00.00.0000 00:00+2
UFO_01
00.00.0000 00:00Только кто этим будет пользоваться в промышленной разработке, уже много раз слышал про javascript и micro python для микроконтроллеров, и это в ту же степь, подойдёт только самоделкиным или тем, кто к embedded не имеет никакого отношения, и надо быстренько запилить проект под какие-то нужды не вдаваясь в суть дела. Я думаю, С из разработки встроенных систем выдавят ещё очень нескоро
anka007
00.00.0000 00:00Ну вот есть два джуниора-студента. Один выучил Rust, но С не знает, другой С, но о Rust только слышал. Кто быстрее найдет работу в области эмбедед или геймдеве? На мой субъективный взгляд доучить синтаксис и особенности rust поверх С/С++ вопрос нескольких недель практики. Если умеешь нормально писать на С, то код на rust будет сложно испортить. Понять зачем что-то делается так, а не иначе в С/С++ после rust - совсем другой уровень сложности. Однако без этого понимания С/С++ исчезает понимание многих вещей в гововых библиотеках и опыте предыдущего поколения разработчиков. Насколько уверены в гениальности джуниор-студентов, чтобы доверить им изобретать очередной велосипед на rust?
MiraclePtr
00.00.0000 00:00+5Если умеешь нормально писать на С, то код на rust будет сложно испортить.
Это только потому что компилятор Rust за откровенную хрень бьёт по рукам и отказывается компилировать до тех пор пока программист не сделает нормально. Совсем испортить не получится, но фигни наделать можно (как говорится, "Программист на Фортране может писать на Фортране на любом языке").
А вот с C++ веселее, когда Сишники набегают в C++-проект и начинают писать там как привыкли, то нередко на результат без слез не взглянешь, можно лицо фейспалмами разбить.
domix32
00.00.0000 00:00+2Ох уж эти мифические джуниоры на расте. Ну ни в жизнь не поверю, что найдется хотя бы один студент, который начал бы с раст и не трогал ничего кроме. Я думаю, что Rust как первый язык - очень плохая идея, как минимум из-за его высокого порога вхождения, что определённо демотивирует многих новичков. И если внезапно такой студент появился, то думается, что он вполне способен осилить и геймдев и встроенку и что угодно ещё. Причём с большим пониманием, почему так.
UFO_01
00.00.0000 00:00Я работаю в embedded, и 90% любого проекта, связанного с контроллерами, пишется на С, даже С++ файлы используются разве чтобы стек lwip поднять или немного облегчить себе жизнь, скажем, сделав класс для парсинга текстовых команд.
BareDreamer
00.00.0000 00:00+2Rust в принципе может использоваться вместо C и C++
nuclight
00.00.0000 00:00-2Не может. Напишите мне код на Rust, без unsafe, реализующий участие узла в четырех двусвязных списках сразу - типичная задача в ядре.
Free_ze
00.00.0000 00:00+1Чем же вам unsafe не угодил? Даже в этом режиме большинство проверок продолжают работать.
nuclight
00.00.0000 00:00-1Ну потому что всякий смысл Rust в нём теряется, и получается просто неудобный C++. Если уж unsafe, проще Си и брать.
Free_ze
00.00.0000 00:00+1Не теряется) По ссылочке выше есть информация о том, что на самом деле делает unsafe. То есть, если вдруг понадобился один-единственный сырой указатель, то небезопасным может быть только он, а все остальное вокруг может быть на безопасных ссылках, обмазанных лайфтаймами и прочим. У сей нет возможности опционально включать безопасный режим, а в расте точечно делать ансейв - легко.
неудобный C++
С точки зрения новичка C++ - это антоним удобства. Но влившему в него годы времени и усилий будет обидно с ним расставаться, а что-то новое будет вызывать отторжение
и раздражение.проще Си и брать
А в чем простота, ключевое слово писать не надо?
nuclight
00.00.0000 00:00-1Это стандартный ответ религиозных фанатиков Rust, не умеющих посмотреть на объективную реальность и практичность.
> С точки зрения новичка C++ - это антоним удобства.
Именно на это и был намек - будет еще неудобнее.А в чем простота, ключевое слово писать не надо?
В том, что не нужно тащить в голове весь багаж Rust (как не нужно и багаж C++), и можно сосредоточиться на предметной области. Размер багажа примерно определяется BNF языка плюс необходимых ей концептов.
Поясню с более философского уровня - есть прогресс, а есть регресс. Прогресс хорошо, регресс плохо.
Есть сложность предметной области, а есть - accidental complexity.
Если мы снижаем вторую - это хорошо, и это прогресс, а не регресс.Так вот, языки типа C++ и Rust - повышают accidental complexity, не давая ничего _существенного_ взамен. Нет, сказки про безопасность рассказывать не надо, это не подтверждается измерениями.
AnthonyMikh
00.00.0000 00:00+3Нет, сказки про безопасность рассказывать не надо, это не подтверждается измерениями.
Memory Safe Languages in Android 13
There are approximately 1.5 million total lines of Rust code in AOSP… To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
As the amount of new memory-unsafe code entering Android has decreased, so too has the number of memory safety vulnerabilities. From 2019 to 2022 it has dropped from 76% down to 35% of Android’s total vulnerabilities. 2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities.
TrueBers
00.00.0000 00:00+3Размер багажа примерно определяется BNF языка
А весь багаж вариаций UB из С++ тоже входит в BNF? :D
Free_ze
00.00.0000 00:00+2будет еще неудобнее
Приведите пример, а то звучит, как стандартный ответ религиозных фанатиков С)
В том, что не нужно тащить в голове весь багаж Rust
Эм… тащить? Либо владеете инструментом, либо нет. Когда его знаете — уже ничего за собой не тащите, это набор инструментов, облегчающих жизнь. Rust сложнее, чем C, но проще C++, при том обеспечивает некоторые преимущества.
можно сосредоточиться на предметной области
Можно сосредоточиться на рутине своего инструмента, вроде ручного управления памятью и отлаживания доступа к висячим указателям)
Размер багажа примерно определяется BNF языка плюс необходимых ей концептов.
С прост синтаксически, но концептов по борбе с отстреливанием ног в нем достаточно. И вот их как раз придется "тащить" в код каждый раз.
сказки про безопасность рассказывать не надо, это не подтверждается измерениями
Списки багов по текущей памяти, дата рейсам и уязвимостей через выход за границу буфера у различного софта более, чем красноречивы.
domix32
00.00.0000 00:00А есть конкретный пример?
nuclight
00.00.0000 00:00domix32
00.00.0000 00:00+1Пока не увидел чего-то криминального и требующего unsafe. Veclist кажется осилит справиться с тем что используется в структуре. Можно конечно и с честными списками заморочиться, но вроде не особо нужно. На Си оно так выглядит из-за отсутвия Vec и генериков.
WASD1
00.00.0000 00:00Ну вроде ситуация, когда объект надо хранить в 2х коллекциях не супер частая, но и не очень уж редкая.
Есть какое-нибудь best practics на Rust как это делать?
- разумеется объект должен быть мутабельным
- желательно чтобы это скэйлилось на N коллекций.
(разумеется "как-то" я могу придумать, но начинают лезть не очень хорошие trade-off).
И вот такие вопросы (ну просто они регулярно всплывают "что будет если") меня останавливают от того, чтобы Rust тянуть в prod.domix32
00.00.0000 00:00Для одномерных структур - Vec, VecDeque и LinkedList есть. Для примера выше, где перекладывают из одного списка в другой этого хватит. Если хочется связывать списки друг с другом, то можно обмазывать хранимый тип в Cell / Box. Можно свои листы написать. Для линуксового ядра подозреваю что-то отдельное изобрели. Есть варианты работы с графовыми структурами, если хочется устроить совсем адок с указателями во все стороны.
И вот такие вопросы
Москва не сразу строилась. Но и про прагматизм забывать не стоит. Там ещё и людей, которые потом поддерживать ржавый код будет в дефиците. Знакомый как-то так какой-то внутреннюю утилиту на своей работе из-за этого переписывал на С++, правда там какой-то другой язык был. Скалисты по тому же принципу без работы ходят- своё болото в родной кампании осточертело, а нового болота ещё никто не сделал.
AnthonyMikh
00.00.0000 00:00реализующий участие узла в четырех двусвязных списках сразу
Но, простите, зачем? Нет, серьёзно.
IMnEpaTOP
00.00.0000 00:00+7Идём на hh.ru и видим количество вакансий разработчиков:
Swift: 670
Kotlin: 1164
C#: 2680
PHP: 3335
Java: 4362
Python: 5284
JS: 6768
1C: 11002
Вопрос - почему 1С нет в опросе и посте? Актуальность, объективно, выше условного Delphi.
programmerjava
00.00.0000 00:00потому что в целом это вакансии на какого-нибудь завскладом, бухгалтера... и многое другое, но не программирования. в выдаче все смешалось видимо
IMnEpaTOP
00.00.0000 00:00+4Нет, это именно "программист 1С". Если брать вообще все вакансии, в т.ч. не связанные с программированием, то на hh их будет на порядок больше: 143282
vedenin1980
00.00.0000 00:001) 1С никому за пределами СНГ не интересен, то есть глобально в мире доля 1С будет исчезающе малой. Соотвественно, как только мы рассматриваем глобальный рынок и возможности релокации — 1С не может быть хорошим выбором,
2) По той же причине, по которой нет программистов на SQL, Html и Excel. "программист 1С" это скорее отдельная профессия, как верстальщики, бизнес-аналитики и т.п.
Вообще, за границей есть разделения "Software Developer"/ "Software Engeener" / "IT consultant". Вот инженеры, настраивающие условные SAP и т.п. системы, это скорее последние два, чем первая профессия. Это не значит, что они хуже, просто это совсем другая профессия.elfukado
00.00.0000 00:00+6Может вы себе представляете консультанта 1с, который обновит платформу, поможет настроить отчёт бухгалтеру в небольшой фирме, где просто купил/продал и ничего сложного.
У нас, например, очень много тонкостей в работе и 1с занимается именно программист, который пишет и изменяет код по запросам руководства. Не вижу никакой разницы с другими программистами, работающими в больших проектах. Он точно так же может написать простенький скрипт или целый интерфейс со всей логикой его работы.
IMnEpaTOP
00.00.0000 00:00+21) Ок, рассматривайте возможность релокации. Но в РФ и СНГ много-много десятков миллионов населения - все они не релоцируются. И работать/получать услуги не перестанут. Значит всегда будет спрос на этом рынке и всегда будут программисты, которые здесь готовы и хотят жить. Почему их интересы (актуальность для них языка и платформы) должны игнорироваться?
2) Matlab, Fortran, R, VBA, Blueprint тоже языки-инструменты очень узкой направленности. Это им не помешало встать в опрос. 1С чем хуже, тем что его здесь делают?
AlexGorky
00.00.0000 00:00+31) 1С никому за пределами СНГ не интересен, то есть глобально в мире доля 1С будет исчезающе малой. Соотвественно, как только мы рассматриваем глобальный рынок и возможности релокации — 1С не может быть хорошим выбором,
Я не собираюсь релоцироваться. Мало того, на 1С я зарабатываю достойные деньги, которые не смогу заработать на VBA, который в списке почему-то есть.
Странный рейтинг для РФ, ИМХО.
Flywood
00.00.0000 00:00+11) 1С нужен за пределами СНГ. Украина с 2018 года выходит из СНГ, членом которого она не была. Но все никак оуончательно не выйдет.
2) "SQL, Html и Excel" - не языки программирования, по этому и программистов нет )))
SaemonZixel
00.00.0000 00:00+3@zarytskiy, пожалуйста добавьте Smalltalk. Это достаточно живой язык. Есть активно развивающиеся бесплатные реализации (например Squeak/Pharo), так и платные (например Cincom VisualWorks). Для создания моделей систем и экспериментов в программировании он хорошо подходит.
А Lazarus пожалуйста уберите. Это не язык программирования, а IDE для разработки на Object Pascal.
Ещё стоит добавить Erlang. Это тоже живой развивающийся язык со своей узкой нишей.
И странно почему написано Assembly, а не Assembler. Я чего-то не знаю, отстал от жизни?
Коль добавили Powershell, то наверное стоит добавить и Bash-скрипт. Который очень популярен в Unix среде.
vasyash
00.00.0000 00:00Assembler это транслятор в машинный код. А Assembly это язык. Не зря же говорят, язык ассемблера)
nuclight
00.00.0000 00:00Только он не bash, а shell.
А про Smalltalk интересно... эти бесплатные реализации дружат с Си-либами?
Uint32
00.00.0000 00:00А про Smalltalk интересно... эти бесплатные реализации дружат с Си-либами?
Использовал VM GNU Smalltalk из C++. Правда, давно это было ...
SaemonZixel
00.00.0000 00:00+1Да дружат. У Squeak/Pharo есть пакет FFI, внутри которого есть примеры использования. На wiki.squeak.org есть инструкция и простой пример.
Cincom VisualWorks Smalltalk существует в бесплатном некоммерческом варианте. По функционалу такой же как и в коммерческий вариант. И у него вроде как с этим делом даже лучше. Есть пакет DLLCC и подробная документация в формате pdf в составе дистрибутива.
StjarnornasFred
00.00.0000 00:00+9Лучший язык программирования - это как лучший дистрибутив Linux. Или лучший стиль боевого искусства. Или лучший тип кузова автомобилей. Его в такой постановке вопроса не существует - он может быть лучшим для чего-то (т. е. с узкой точки зрения), либо лучшим для кого-то (т. е. по принципу нравится - не нравится). В обобщённом случае - все хороши.
danial72
00.00.0000 00:00+1@zarytskiy, добавьте dart пжлст
domix32
00.00.0000 00:00+1В список неактуальных.
danial72
00.00.0000 00:00разве он не актуален ?
domix32
00.00.0000 00:00Скорее неактуален, чем актуален. Пользовательскую базу так толком и не успел нарастить и уступил позиции в пользу TypeScript. Хотя в ковидные времена были какие-то попытки воскресить развитие языка, но оно вроде даже в недрах породившего его гугла так и не нашёл широкого распространения, уступив тому же Go. Энтузиасты ещё есть и даже на хабре иногда всплывают, но это скорее нишевая забава вроде Haxe. Кампания, которая долгое время писала на Dart и писала про это на хабр тоже в итоге решила пересесть на кажется тот же TS, главным образом потому что им почти в соло приходилось тянуть экосистему. Это уже наверное год 19 или раньше.
svr_91
00.00.0000 00:00+9Чтобы быть успешным в мире IT, важно выбрать актуальный и востребованный язык программирования для изучения
Если вы не вайтишник, которому надо прям здесь и сейчас, а например студент, у которого есть достаточно времени, чтобы изучить предметную область, то не так важно, с какого языка начинать учиться. Хоть с паскаля. Вероятность того, что после учебы вы будете программировать на томже языке, что и во время учебы, невелика. Все равно в какой-то момент язык придется сменить
aceofspades88
00.00.0000 00:00объяните плз такой отрыв пайтона, кроме того что он служит пакетным менеджером для датасайнтистов что на нем сейчас пишут и зачем?
Joysi
00.00.0000 00:00Как скриптовый, например. Считать и распарсить файл, забрать/закинуть в/из СУБД + API данные + вывести их в excel/xml. Можно скриптить в файле, можно в Jupyter notebook + выводить диаграммы и т.п. Удобно и порог вхождений небольшой.
MiraclePtr
00.00.0000 00:00+1Датасайнс и аналитика, всевозможная автоматизация рутины (например, генерация тестовых данных, скрипты сборки), симуляторы всяких API и железок, веб-сервисв и веб-сайты (бэкенд), десктопный софт.
micronull
00.00.0000 00:00+1В machine learning очень много пайтона.
Люди занимающиеся наукой и исследованиями используют пайтон.
Вообще очень универсальный язык с огромным набором всевозможных библиотек.
rssdev10
00.00.0000 00:00+1Люди занимающиеся наукой и исследованиями используют пайтон.
Сейчас уже есть возможность почти безболезненно от него отказаться в этой области. Джулийный мир развивается довольно активно.domix32
00.00.0000 00:00уже есть порты всяких NumPy/PyTorch и прочих числодробилок с похожим API?
rssdev10
00.00.0000 00:00NumPy в Julia точно не нужна, поскольку векторные операции - часть её синтаксиса. А оптимизация циклов же выполняется компилятором. Касаемо "портов" - вообще-то она разработана именно под математику и научные вычисления. И тащить в неё библиотеки с чужим синтаксисом - не факт, что нужно. Но если очень надо, можно и PyCall вызвать. В целом, код на Julia будет компактнее, чем Python, поэтому тащить из него API библиотек как есть - это создавать ненужные надстройки.
Вместо PyTorch можно использовать родную Flux.jl, либо оптимизированную ONNXRuntime.domix32
00.00.0000 00:00Проблема, что для того чтобы пересадить людей с Питона на Джулию надо как минимум иметь понятный API, который мапился бы примерно 1 к 1. Я понимаю, что R и Julia заточены под подобные юзкейсы, но существует ли это в виде некой экосистемы - вопрос открытый. Ну и естественно, нужно больше туториалов про решение таких задач на Julia, а ещё лучше кейсы от крупных кампаний, которые занимаются чем-то таким. Я тут маленько сбоку, поэтому не интересовался что там с новостями по теме и как развивается сообщество языка.
API библиотек как есть - это создавать ненужные надстройки.
Ну, это бабушка надвое сказала, на самом деле. Когда-то и у питона urllib был библиотекой, поверх которой крафтили ещё библиотеки. Кому-то дефолтного API достаточно, кто-то хочет абстракции попроще.
rssdev10
00.00.0000 00:00Проблема, что для того чтобы пересадить людей с Питона на Джулию
Первый же вопрос - а нужно ли это делать?...
Структура ЯП в области DS/ML/научные исследования - это довольно тёмный вопрос. Не надо думать, что все тут знают и используют Python. Стоит ли переносить на что-то проекты с R? Не факт. С Matlab? Если только по санкционным или лицензионно/экономическим причинам. Переносить готовые проекты с них на Python? Это вряд ли.
В бизнес-задачах по аналитике и прогнозированию устойчивый тренд - машинное обучение без программирования. Всякие Amazon SageMaker Canvas и пр. Тут никакой ЯП не нужен. Всё визуально через формочки.
В нише научных исследований, где занимаются статистической обработкой результатов, нужны "типовые калькуляторы", а не язык программирования как таковой. И даже если какой-нибудь Python используется, то на минимально уровне для решения вполне типовых задач, решение которых выглядит примерно одинаково везде. С одинаковыми же именами функций стандартных библиотек. Безразлично какой ЯП.
Ниша, где требуется создание новых методов анализа информации и новых алгоритмов (биоинформатика, математика) - это вообще не ниша Python, хотя его и пытаются навязывать. Если кто-то здесь говорит, что он пишет на чистом Python, почти наверное, недоговаривает, что по факту пишет на каком-нибудь C++, а на Python изредка приделывает обёртки. И, как раз, здесь и есть ниша Julia с её основным аргументом - один язык для всего и без проблем с производительностью (как в части скорости написания кода, так и в части исполнения кода).
С другой стороны, любой ЯП живёт только до тех пор, пока есть люди, готовые им пользоваться. И тут мы знаем и пример с Коболом, на котором до сих пор работают некоторые программы и до сих пор требуются программисты для поддержки (потому как те кто писал код уже буквально вымерли). И пример с Паскалем, на котором совсем недавно в наших университетах учили абсолютно всех, но последние лет 20 он крайне мало кому был нужен.
При этом, за 10-20 лет рельеф ЯП и библиотек меняется довольно сильно. Проектов создаётся много. Но много ли из них выживает 3-5 лет, даже если нахватали звёзд на github? Исследовательские проекты, часто, вообще пишут под одну публикацию. Год спустя проект никому не нужен. Поддерживать старый код не надо.
Да и программисты - не вечны. За 20 лет трудовой деятельности мало кто остаётся программистом и продолжает поддерживать старый код. Ну а молодёжь после университетов вообще без проблем переучится на что угодно реально востребованное, и совместимость библиотек 1 в 1 им тоже не нужна.
PS: перенос библиотек с сохранением интерфейсов один в один возможен только на близких языках. Перенос же библиотеки на ЯП с другими концептами, но 100% сохранением интерфейса - это потенциально неэффективный по исполнению или визуально громоздкий код.
AAngstrom
00.00.0000 00:00+1Очень непросто взять и отказаться от чего-то. В научных вычислениях тренд последних 20-ти лет -- это ядро на C/C++ или Fortran, обёрнутое в Python. Казалось бы, давайте всё это выкинем и начнём всё писать на Julia. Но тут возникает много нюансов:
Релизная версия Джулии вышла только в 2018-м (если правильно помню). До этого были версии 0.x.y.z. Начинать серьёзный проект на бета-версии языка -- мягко говоря рискованное решение, если только вы не сидите в одном здании с главными разработчиками языка.
Время жизни серьёзных числодробильных программ -- десятки лет. Люди, вносящие свой вклад в разработку -- это, в основном, студенты и постдоки, которые меняются каждые 4-5 лет. В особенности для пост-дока важно включаться в работу как можно быстрее, потому что ему нужно наклепать статей за 1-2 года, иначе можно вылететь из академии вообще. А теперь возникает связанный с этим вопрос: какова вероятность того, что вновь пришедший пост-док разбирается на хорошем уровне в Julia? Вероятность того, что человек имеет опыт разработки в C++/Fortran/Python, близка к 100 %, если кандидат писал диссер, связанный с разработкой численных методов.
В догонку к п. 1 и 2: все проекты, начатые, условно, до 2018-го года, уже основаны на C++/Fortran/Python. Никто, в здравом уме и памяти, не будет это переписывать всё это на другом языке просто, потому что так красивше.
Мне самому весьма импонирует Julia (хотя я на нём ни строчки кода не написал) потому что это первая за долгие годы свежая платформа, заточенная на вычматы, в отличие от многих других новомодных языков. Но понадобится ещё очень много времени, чтобы этот язык начал играть заметную роль в научных вычислениях.
evgenyk
00.00.0000 00:00+2Ну например что я делаю на пайтоне:
1) Большой бэкенд на работе. Весь бэкенд на пайтоне. Как машинной обучение, так и API.2) Для себя. Более сложные скрипты, которые неудобно писать на Bash.
3) Для себя. Простенькие веб интерфейсы.
4) Для себя. Простые программки для Распбери.
5) Для себя. Пробую Kiwy, хочу делать простенькие программки для Android.
Ну и вообще, питон сейчас работает почти на всем, что шевелится, не Си, конечно, но все-таки.
StjarnornasFred
00.00.0000 00:00Универсальный и везде применяется. Один раз выучил - и пиши хоть игры для телефонов, хоть вирусы, хоть нейросети, хоть просто автоматизацию по мелочи. "Можно перейти на", а можно и не переходить.
aceofspades88
00.00.0000 00:00ну шуруп тоже можно молотком забить) в целом вопрос был именно про профессиональную разработку
Bessnov
00.00.0000 00:00А что подразумевается под словом лучший?
Например,С++ лучший язык для обработки данных и "машин лёнинга"?
Fortran лучший язык для написания драйверов и управления контроллерами SCADA систем?
;)
domix32
00.00.0000 00:00+1Забавно, что в списках есть всякие Erlang/Ocaml/Elixir, но нет F#. И всяких сишных альтернатив пожалели а ля V или Zig.
jkelly
00.00.0000 00:00Все еще не понимаю почему Go и Rust существуют. В смысле, посмотрите на их синтаксис...
wolfy_str
00.00.0000 00:00а что с ними не так? Просто когда работаешь со своим языком особо нет времени изучать другие
Free_ze
00.00.0000 00:00+2Так посмотрите на Python, а он вообще в топе)
evgenyk
00.00.0000 00:00Python был хорош, но набежала толпа и превращает его изо всех сил в C++/Java.
domix32
00.00.0000 00:00То есть хотеть скорости от языка это такой смертный грех? Всякие 10к rps из коробки, а не из танцев с бубнами и общением с Си.
evgenyk
00.00.0000 00:00Вы про что? Я больше о синтаксисе и посказках типов. Прироста скорости они не дают никакого.
Что касается желания скорости от интерпретируемого языка, то как мне кажется оно несколько неуместно, да и не особо нужна скорость Си в 95% случаев, ИМХО. Гораздо важнее скорость написания. А на 5% есть библиотеки, Си и Cython.
Совсем не скоростью исполнения взял питон.
domix32
00.00.0000 00:00В плюсоджаву оно превращается именно по причине не очень высокой производительности и сложности в отладке. Там в планах использовать эти самые тайп хинты в том числе и для JIT и прочей компиляции. Всякие линтинги на основе хинтов народ уже довольно длительное время пилит.
evgenyk
00.00.0000 00:00Я лично думаю, что они не получат скорости плюсов и джавы и одновременно убьют лучшие черты питона.
А в чем проблемы с отладкой?domix32
00.00.0000 00:00def sum(a, b): return a+b sum(1,2) sum("asd","qwe") sum((1,2,3),(3,2,1))Если кратко - то вот такие перегрузки очень больно отлаживать не зная ни входных ни принимающих типов. Хинтинги уменьшают скоуп проблемы до перегрузок с конкретными типами. Как-то так и взлетел TypeScript, который по большей части тот же JS только с более строгими типами.
evgenyk
00.00.0000 00:00Зачем такое писать?
Но если напишете, такое работает по умолчанию в питоне. Если попытаетесь сложить разные типы, питон ругнется и выдаст стек, из которого вы легко найдете, где ошибка.
Вы с Джаваскпирт не перепутали? В питоне по умолчанию строгие типы.domix32
00.00.0000 00:00Так типы-то одинаковые и они прекрасно складываются. Но когда у тебя разношёрстный пайплайн может случаться логическая ошибка и тогда будет складываться не то, что хотелось складывать. Пример естественно сильно упрощён.
Пример немножко посложнее - представьте фабрику потоков - сетевые, файловые, интерпроцессорные и пр. Всё естественно асинхронно. Все данные стекаются в общий синк на дальнейшую обработку. Но вот незадача - в бухгалтерии что-то перепутали и сетевой поток скормили в нтерфейс файлового и теперь половина байт в другом порядке идёт. Как ловить виновника? Как избежать повторения подобных ошибок? Ответ простой - типизировать это. В таком случае на этапе проверки типов будет ошибка, что в файловый интерфейс пытаются скормить нефайловый поток.
evgenyk
00.00.0000 00:00У меня такие ошибки ловятся на этапе тестирования. Тесты все равно нужны.
Но что-то мне Ваш пример кажется не совсем жизненным.
Ну и ломается одна из главных идей питона, что такое проверяется в рантайме.
Согласитесь все-таки, Вы хотите сломать существующий питон, в его самых главных фишках и сделать из него что-то среднее между С++ и JAVA, только с синтаксисом похожим на питон и его базой разрабочиков и пользователей. Не нужно так делать.
Хотите язык с типизацией как у C++ или JAVA, берите их или что-то новое, полно такого, с такой же типизацией, а нам оставьте язык со строгой и утиной типизацией.Добавил: Пока-что на работе мне не смогли привести ни одного внятного примера, когда внедряемый подход с типами помог поймать ошибку. А мусора он добавляет очень много.
evgenyk
00.00.0000 00:00Добавил 2: В Вашем римере с пайплайном для JS будут проблемы, он преобразует типы и сложит их незаметно для разработчика. А питон просто честно упадет, что от него и требуется. За что его и любим. Ранний крэш, это великолепно.
evgenyk
00.00.0000 00:00>>> def sum(a, b): return a+b ... >>> sum(1,"a") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 1, in sum TypeError: unsupported operand type(s) for +: 'int' and 'str' >>>Так как у Вас, и не должно крэшится, там с типами все в порядке.
domix32
00.00.0000 00:00Так и речь изначально про ситуации, когда с кодом без хинтов всё в порядке, то есть код вполне валидный, запускается и работает, до тех пор пока данные идут корректные. Но содержит неявные баги, которые проявятся где-нибудь дальше по пайплайну. То есть ты хотел складывать инты, а тебе случайно прилетело два кортежа с числами, которые функция также неглядя сложила и отправила дальше. Какой-то следующий обработчик наткнётся и покрашится на том месте, где он попытался работать с неподходящим типом. Искать такие ошибки, особенно в асинхронных контекстах может быть очень нетривиальной задачей. Мой же пример сильно упрощён и его отладка естественно займет 2 секунды.
evgenyk
00.00.0000 00:00Как-то у меня случайно ничего не прилетает. А там, где есть такая возможность, пишем валидаторы.
Там, гда есть возможность прилета не того, типа полей формы, с типами все равно нужно писать кастомные валидаторы, как правило.
domix32
00.00.0000 00:00Я на самом деле от питона ничего не хочу. Я его использую редко да и то в основном в виде калькулятора или какой-нибудь веб-паук побыстроляну оформить. Остальной народ, который не использует его в числодробилках типа нейронок/ML использует его в качестве веб серверов, и конкретно в этом месте у питона начинается немало проблем из-за разношёрстности пользовательского ввода и невысокой производительности. Именно в этом случае как раз и начинается неприятная свистопляска, которую безболезненнее решать с типами. Можно конечно выкинуть питон и пересесть на java или .net какой, но если у тебя кодовой базе лет 5, то сколько будет тот перевод происходить?
Ну и естественно в идеальном мире люди пишут тесты, пишут требования и никогда не меняют требования, потому что случился рост пользователей. Если у вас и без типов всё прекрасно, то могу только порадоваться за вас.
AAngstrom
00.00.0000 00:00Не очень понятно, в чём проблема в подсказках типа. Они до сих пор были опциональны и, скорее всего, таковыми и останутся в Python3. Не нравится -- не используйте.
eugenk
00.00.0000 00:00+1Жаба forever !!! Для меня это просто спасение, а не язык. Дело в том, что я предпочитаю линукс. А большинство моих заказчиков-работодателей работает под виндой. Поэтому средства разработки/управления для своих электронных игрушек пишу на яве. Большинство моих проектов это некая смесь явы и верилога, с вкраплениями С. Почему не питон ??? Во-первых не люблю динамическую типизацию, даже суперстрогую. Во-вторых идея структурирования кода отступами, кажется мне худшим из того что было в IT со времён ламповых динозавров. Поэтому жаба, жаба и ещё раз java ! Плюс scala, которая легко компилируется в джаваскрипт, если надо делать GUI (GUI последние года три я делаю только браузерным). Из системных языков - С. С очень небольшим и осторожным использованием С++, там где он во-первых реально помогает, во-вторых предсказуем и безопасен. Дело в том что чистый С обладает "прозрачностью". Т.е. глядя на код, довольно легко понять, во что он будет развернут, и сколько это будет стоить. С++ этим свойством не обладает. И операция разыменования какого-нибудь умного указателя, легко может потребовать доступа в интернет. Это не страшно, если приложение предназначено для бухгалтера или геймера. А если оно управляет коробкой скоростей автомобиля ??? А на С(С++) я пишу в основном для электроники, причем порой управляющей чем-то реальным, и иногда опасным. С++ мне кажется непригодным для этого. Слишком абстрактен и слишком многое позволяет. Rust - пока играюсь на десктопе, компилируя и дизассемблируя. Увы, ещё слишком плохо его понимаю, чтобы рискнуть применить для реального железа. Хотя язык очень интересный. Вот примерно так. Прошу прощения, если кого-то ненароком обидел, и прошу не пинать ногами, если с чьей-то точки зрения сморозил глупость.
PrinceKorwin
00.00.0000 00:00V язык не смотрели? Судя по вашему комментарию он вам должен зайти хорошо.
eugenk
00.00.0000 00:00Нет, честно говоря даже не слыхал о таком ! Надо будет погуглить. Спасибо за наводку !
P.S. Нашел. https://github.com/medvednikov . Пишут во всяком случае интересно. Наверно и правда мне понравится. И приятно что автор соотечественник. Будет забавно, что расширения исходников придется как-то переименовывать, чтобы не путать с верилогом :)))
PrinceKorwin
00.00.0000 00:00Если понравится было бы интересно от вас почитать статью про этот язык :)
eugenk
00.00.0000 00:00+1Ну это наверно чуть позже. Всё никак не могу дописать серию статей про свой процессор для проектов на FPGA. Кстати возможно средства разработки для него напишу на V. Сейчас оно у меня на java. Интересно будет сравнить.
eugenk
00.00.0000 00:00Забавно что для языка такого типа есть REPL. Ядра для юпитера как я понял пока нет, но раз есть REPL, без проблем можно будет накатить самому. Удивительно что сам автор до сих пор этого не сделал. Юпитер просто обожаю. Вобщем спасибо за наводку, действительно очень интересная штуковина. Пока есть немного свободного времени, буду разбираться.
По-русски: https://proglib.io/p/v-znachit-yazyk-programmirovaniya-2020-02-23 и https://koplenov.github.io/vpage/
AnthonyMikh
00.00.0000 00:00V — это проект, созданный для того, чтобы собирать донаты под обещания выкатить идеальный язык, которые никогда не будут сдержаны.
eugenk
00.00.0000 00:00Ну я бы не сказал. Активность сооба довольно высокая.
AnthonyMikh
00.00.0000 00:00Высокая активность != нормальная разработка
eugenk
00.00.0000 00:00Спорить не буду. По первому впечатлению проект мне показался интересным. Возможно через какое-то время напишу здесь статью по результатам тест-драйва в небольшом, но и не совсем тривиальном проекте (ассемблер, симулятор, IDE для моего процессора). Сейчас это сделано на яве, пора писать новую версию. Самому интересно сравнить. Пока на языке не напишешь что-то более не менее реальное, рассуждать о нём можно только умозрительно.
no404error
00.00.0000 00:00Исходя из пропаганды различных курсов в "этих их интернетах", все делится на две категории: "как срубить бабла если мозгов дофига" и "как срубить бабла если оппыта нет нефига".
И обе порочны.
Во-первых, откуда потенциальному пользователю курсов знать свои реальные возможности? И, во-вторых, рубить бабло в любом случае не выйдет, точка. Максимум что по факту выйдет - дикая "дрочка" и упоротое забивание еще не состоявшейся репутации под плинтус.
А тут сразу возникает законное "почему?" Потому, что натренировать на написание примитивов, скриптов, шаблонов... это легко. Труднее научить думать над кодом до написания кода. И тут, опять же, сразу проходит разделение между языками. Натренировать "на минималке" проще на чем-то, что более или менее можно назвать интерпретатором или на чем-то подобном. В итоге имеем 100500 питон-профессионалов с сертификатами третьего уровня десятой степени университета шестого кантона Ниуэ.
В контексте человеческого развития... Прошел курсы - поздравляю, тебя научили складывать слово МАМА из кубиков. Хочешь получать 100 000 в месяц? Молодец, только каждый месяц сумма будет падать, поскольку бэкграунд тебя не отпустит.
А осознание наступит либо с досираком на кассе, либо с очередным заданием, когда попросят сложить МАМА из Ж, О, П и А.
PTM
vba.... в некоторых местах без него никуда