Comments 224
vba.... в некоторых местах без него никуда
логотип для раста у вас не правильный, тот что у вас от игры, а не от я.п.
Зря вы так про VBA, он очень даже актуален в некоторых компаниях :D
Java лучший. Правда на собесах замотают) Жаль что уступил не только питону.
Toolchain у него неудобная и слишком болтливый.
Toolchain у него неудобная
По сравнению с чем?
и слишком болтливый.
Это что значит?
С питоном, ясное дело, с чемпионом.
Болтливый, значит нужно больше написать текста для получения того же результата.
"Болтливый, значит нужно больше написать текста для получения того же результата."
зато прозрачно и понятно всё, а то в некоторых языках настолько высокий уровень абстракции, что непонятно, как оно там под капотом работает и при каких условиях, приходится в голове держать многое
Тогда правильнее сказать - многословный.
Ну это примерно как "слышь, ты" и "не будете ли так любезны".
Первое - короче. Второе - ну, приятнее слышать.
Кому болтливый в минус, кому в плюс. Лично мне читать джавовый код намного приятнее как раз из-за его многословности.
что такое Toolchain?
Это комплекс инструментов, для того, чтобы писать программы и запускать и отлаживать код.
А какие претензии у вас к Intellij Idea? И в чем там разница с каким-нибудь Intellij PyCharm? Или вы говорите о встроенный командных утилитах вроде javac? Но кто их использует на реальном большом проекте?
Речь, в первую очередь, о конфигурации проекта и управлении зависимостями. То есть условный gradle (или что там актуально) для джавы, и PyPA для питона.
Претензии не к idea а отсутствия как такового встроенного тулинга. Если не работаете с новым поколением языков типа go где всё типовые вопросы а-ля тестирование, пакетныйменеджер, профилирование, авто форматирование, линтинг, покрытие, кодогенерация и прочее идёт из коробки и очень простое, то вам сложно понять что не так с Java или C++. Настройка авто сборки того же голанга пара простых команд в makefile. Адекватная же сборка на gradle, npm, CMake, это уйма копипасты или тайных знаний и привлечения всякого набора внешних средств.
да. Зато это требует специалистов, а значит будет работа) А когда отваливается версия компилятора это нечто. Поначалу такое было, потом как то прошло. Не правильно выбранная версия проекта это полбеды, это ерунда, а когда слетали внутренние настройки. Обычно программы притераются и уже не ломаются так :) У меня такое с любым новым софтом. Да, мне сама IDEA не особо нравится на английском и куча настроек, а не комбайн как MS Visual Studio (и есть на русском). Да, только студио использовал для обучения, а джаву для работы. Потому спустя пару лет среда для меня чёрные ящик, ну не совсем, но отчасти. Я не против английского, но можно было прикрутить русские скрины, тем более разработчики русские. Я имею ввиду разработчики среды. Если бы работал на зарубежного заказчика, жил бы в Европе, Америке или Австралии тогда да, притензии к английскому софту обсурдны, но для России лучше качественно переведённая среда, так как утопаешь в настройках, но спустя даже годы не можешь всё запомнить, тебе это не особо нужно, а мозг отказывается в этом разрабираться. А они знаете что сделали? Просто ушли из-за санкций. К санкциям у меня неоднозначное отношение, где то поддерживаю, где то нет, но тут просто решил что мне ничего не мешает пользоваться кракнутой юльтимейт версией IDEA тем более это делается за пару минут.
Сейчас у меня основная притензия - куча зависимостей, которые не дружат друг с другом, иногда конфликтуют, иногда (редко) ломается сама среда, починить её сложно, так как она сама по себе довольно сложная. И практически всегда пакеты перекрывают друг друга, то есть лишние зависимости будут.
а отсутствия как такового встроенного тулинга.
Это не баг, это фича. Изначально, jvm разрабатывали множество разных компаний и сейчас есть десяток альтернативных реализаций jvm полностью проходящих необходимые тесты по спецификации каждой версии.
То есть, у java сознательно в ядро языка вносили лишь самое важное, а многие вещи специально оставили для реализации другими компаниями (например, работу с базой данной или создание микросервисов/Rest). Идея оказалось хорошей, потому что так получались лучшие инструменты, чем если бы был один стандартный способ.
Вот к этому и претензия. Приходишь в другой проект - а там другой инструментарий для тех же самых целей. Ещё и платный то и дело. Потому что стандартный метод многих не устраивает.
Потому что стандартный метод многих не устраивает.
В Java специально так сделали — если бы был один стандартный метод, другие методы просто не возникли бы. А за десятки лет выяснилось бы что стандартный метод плох, но все кололись, но использовали его бы. Особенность open source философии Java — только самые важные вещи должны быть в самом языке, чтобы его легко могли реализовывать разные вендоры. А все остальное (jpa, jree, spring, ide, системы сборки) — максимум спецификации и интерфейсы для стандаризации. Это позволяет конкурировать разным проектам и выживать наиболее популярным. Именно поэтому java сильна инфраструкторой.
Приходишь в другой проект — а там другой инструментарий для тех же самых целей.
Давно не видел нигде ничего кроме Idea, сборки maven/gradle и т.п.
Ещё и платный то и дело.
И что? Это головная боль работодателя, если он не готов заплатить 200$ в год за инструментарий, то и зарплату он вам посторается зажать.
вообще то не единым pyCharm'ом. Сам я не питонист, но удивился какой простой интерфейс у встроенного редактора, colab. https://colab.research.google.com/ Каждая ячейка это отдельная программа, при том ячейки последовательно инициализируются, можно сохранять. Очень классный инструмент
Зато поддерживать его и через 5 лет можно, а не один раз написал и молиться, чтоб там ничего не сломалось, пока другой команде сервис не уйдёт.
Когда-то вроде были соревнования на краткость кода на Perl
Он вполне обоснованно уступает рынок Kotlin-у. Такой консервативности как у Java я не вижу ни у одного другого современного языка. Корутины уже практически все современные языки реализовали, а Java так до сих пор впаривает разрабам CompletableFuture да сторонние реактивные библиотеки.
Из Андроида и Вэб-а Java уже почти полностью выгнали. Как я понимаю, только на бэкенде он еще остается усилиями ну уж очень консервативных команд. Это те, кто мне отвечал, что Java лучше Kotlin и что они еще 20 лет будут на Java 8 сидеть.
автор, а добавьте плиз Паскаль (Lazarus и Delphi) и еще zero Coding - (blueprint Unreal Engine и аналоги в Unity и других игровых движках и проектах)
done
Языка программирования с названием Lazarus не существует.
Lazarus - это IDE для паскаля, так же как и Delphi.
Языка lazarus, действительно, не существует. Это графическая IDE для FPC (который, в свою очередь, вроде умеет и Object Pascal, и Delphi). А вот с Delphi не все так просто. Это не только IDE, но и язык программирования, несколько отличающийся как от классического паскаля, так и от экзотического Object Pascal. Одни считают его диалектом паскаля. Другие - самостоятельным языком.
Julia ещё добавьте пожалуйста, часто в ML проектах, моделировании и научных расчётах используется. А Clojure чего кстати забыли? ни одного языка семейства Lisp
Даже смешно, как низко рейтят PHP, когда это сейчас самый популярный язык для корпоративных стартапов в РФ вместе с GO.
Популярность это хорошо, но как насчет удовольствия программиста от использования языка? Это тоже немаловажно. Согласитесь, язык корявый.
Откуда инфа? Готов поверить, что корпораты будут за Java, либо что-то модное и стильное, но пыха?
У вас извращенное понимание того, что выбирает крупный бизнес. Не " что-то модное и стильное ", это вам к различного рода стартаперам и другим любителям смузи, корпорации берут то, что проверено годами и имеет качественную поддежку, да, конечно Java (Spring итп), но и Symfony с Laravel не далеко ушли.
Я примерно в таком и работаю и вижу, что выбирают либо java/c#, либо берут что-то древнее и допиливают под себя, либо стильное и модное.
У нас так в одной группе собрались команды на ts, c#, java, prolog и ещё одна команда выбирает на какой язык перейти(не помню на чем пишут), из питона и c#.
Так и получается, что либо стильное, либо старое, либо стандартное. Может быть где-то и пхп есть, но не у нас.
Fortran язык математиков. Если вы с ним не столкнулись, то изучать всё таки не стоит.
Добавьте, плиз, Haskell, OCaml, Racket
Оказывается, C&C++ любят больше всех (кроме питона). Может, стоило их разделить?
Во первых у них есть свои области применения, где заменить их никак не получается (только точечно, с большим количеством ограничений). Во вторых их можно сравнить с латынью для медиков: до свободного владения учить не обязательно, но как минимум читать код и писать простейшие программы уметь надо.
Что это за области такие, где нельзя заменить Си? На полке в музее?
Вы написали эту шутку за 300 пользуясь ОС ядро которой написано на С, отправили в сеть с помощью протокола реализованного на С, а на конечных устройствах эти бесполезные буквы были отрендерены библиотекой написанной на С с помощью драйвера написанного на С.
Но опрос то проведён здесь и сейчас и много где C++ незаменим, например в геймдеве серьёзном. Понимаете некоторые вещи не заменимы не потому что ничего нет что выполнило бы их функцию, а потому что никто и не пытается их менять,
незаменим, например в геймдеве серьёзном
Например? Очень хотелось бы услышать, что есть такого в С++ особенного для геймдева?
Две крупнейших платформы для разработки игр (Unreal и Unity), и ещё кучка платформ поменьше (Godot и иже с ними) и всякие корпоративные платформы типа Havoc, CryEngine и пр.. Остальные пока ещё getting there и пока ещё не имеет успешных примеров аналогичного уровня.
То, что это появилось в те времена, когда не было альтернатив, не говорит о том, что эти языки до сих пор незаменимы.
Да, изучение нового требует ресурсов: времени, средств, остановки маховика инетрности и изменения направления парадигм мышления. Я с этим ни сколько не спорю, я спорю с конкретными формулировками этой ветки коментариев вида "С++ незаменим", "невозможно игры писать на чём-то ещё", "кроме Си и С++ ничего не нужно" и подобными риториками прошлого тысячелетия, когда был один язык, один компилятор и непреодолимое чувство творчества.
Я бы сформулировал по-другому: пока не наблюдается языков, готовых заменить C и C++. Rust пока ещё слишком молодой и непопулярный, чтобы можно было уверенно сказать, что он их способен заменить, а прочие языки либо ещё мельче, либо обладают особенностями вроде сборщика мусора, не дающими заменить C/C++ в ряде областей.
Rust (не без unsafe, но это не важно).
Это важно. Без unsafe от Rust нет никакого смысла, особенно в перечисленных областях типа ядер ОС.
Без указателей Си, это уже не Си.
С того, что он без safe лишается главной идеи, а значит, становится бессмысленным. Это, действительно, как если бы выкинуть из Си указатели (между прочим, проекты с таким кодом даже существуют).
язык по-прежнему предоставляет больше проверок, гарантий
Еще бы эти гарантии чем-то помогали https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust пока только сплошной пиар изо всех щелей. Видимо не хотят хомячки есть кактус.
Перечисленные вами факты -- исключительно историческое наследие.
Я это написал, ответив на фразу "заменить их никак не получается". Вот мне и интересно, у кого не получается? У комментатора? У тех, кто не пробовал? Инертность, "трушность"? Так это тогда не проблема языка, а проблема тех, у кого не получается.
Кто осилил закопать это гавно мамонта, у тех более чем получается. Ни один адекватный человек сейчас не начнёт новый проект на Си, если только не религиозный фанатик.
Всё, что осталось хорошего от Си, так это его универсальный ABI, который, кстати, тоже сложился в "стандарт" де-факто сугубо исторически. Остальное давно уже можно безболезненно закопать.
Подождите а в чем проблема новый проект на Си начинать? Огромное количество библиотек и готовых инструментов. Можно быстро связать например SDL и ffmpeg. на Rust мало того что новый язык изучать, но еще и разбираться как сторонние библиотеки подключить чтобы компилятор был доволен, на что не каждый согласится. Плюс если вы пишете на Rust обертки над С библиотеками - по сути разработчику проекта надо уже знать ДВА языка, а не один, более простой (С). Не то что все это непреодолимые препятствия (и наоборот, человека который согласится вот это все решить расковырять и объединить - я всецело уважаю!), но не каждый разработчик будет настолько отважен. Я вот лично сколько раз пробую за последние 2 года окунуться в Rust - постоянно зависаю с интеграционными работами.
Про закопать боюсь никакой лопаты и полвека не хватит, чтобы миллиарды строк кода на С закопать) никуда он от нас не денится, еще нашим внукам останется.
еще и разбираться как сторонние библиотеки подключить чтобы компилятор был доволен
У раста ffi-библиотеки любой сложности из коробки собираются и линкуются, ни с чем не нужно разбираться. Сам, когда несколько лет назад учил язык на низкоуровневом хобби-проекте, без проблем и бубнов встроил огромные проекты: язык Dart с его фреймворком Flutter. Сейчас же, с опытом, обернуть либу, для которой внезапно нет готового пакета, занимает пару часов.
никуда он от нас не денится, еще нашим внукам останется
В плане чтения кода на Си, я согласен, он будет жить ещё очень долго, но писать на нём уже мало кто решается.
Взять тот же Гугл, Майкрософт, Фейсбук, Cloudflare, Amazon. Откройте их крайние репозитории, начатые в течение последних 3 лет. Ни ОС, ни драйверов, ни системных утилит, ни реализаций стека протоколов, почти никто из них не начинал писать на Си.
Зато референсные реализации того же WASM, WebGPU написаны на Раст. Ядро HTTP3, протоколы QUIC и WireGuard у Cloudflare реализованы на Раст. В Андроиде на Rust написаны стек Bluetooth, NFC, HAL, гипервизор. Новая гугловская KataOS полностью написана на Раст, включая ядро и драйверы, а в Fuchsia половина кода на нём уже. Майкрософт усиленно пилит биндинги для Windows SDK под Раст.
Не знаю, может быть я это замечаю только потому, что я плотно занимаюсь языком уже несколько лет, но по-моему тренды довольно показательны.
постоянно зависаю с интеграционными работами
Странно, по-моему мнению, тулчейн и экосистема Раста -- лучшее, с чем приходилось работать за всю кодерскую жизнь.
У раста ffi-библиотеки любой сложности из коробки собираются и линкуются, ни с чем не нужно разбираться
ну видимо я с каким-то другим растом работаю :)
> по-моему тренды довольно показательны.
мне кажется это эффект наблюдателя какой-то вы именно на это хотите обращать внимание и замечаете. я вот сейчас по работе ковыряю опенсорсный проект на Си который стартанул несколько месяцев назад от силы. А что-то новых проектов на Rust я не замечал (опять же не значит что их нет)
Замечать новые проекты на Rust (и не только) весьма просто - достаточно в Github Explore в раздел Trending заходить время от времени, там что-нибудь да встретится. И новые проекты там есть, которые получают интерес сообщества, и старые, взлетевшие после апдейтов. В основном вижу там что-то на Python(привет бум всяких Stable Diffusion, Anything-With-ChatGPT и тд, чуть новость - всё забито этим), что-нибудь из существующих Java-проектов (новых вот убей не помню), обвязки на C/C++, облачные тулы стабильно на Go, какая-нибудь очередная CMS или новый UI на JS/TS, ну и проекты на Rust.
Trending основан не на интересах смотрящего, а на интересах сообщества, так что эффект наблюдателя там не сработает. Вкупе с листами гитхабовскими, помогает расширять кругозор.
https://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, буду иметь в виду. По "актуальности" С пока останусь с прежним мнением.
https://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%! А это десятки миллионов долларов в их масштабах. И сэкономленные нервы пользователям.
Расскажите это embedded-разработчикам :) Они долго будут смеяться про "никто не начнет новый проект на Си" :)
А ещё люди пишут и ещё тыщу лет будут писать модули ядра Linux на Си, просто потому, что это в 100 раз удобнее, чем на Rust.
просто потому, что это в 100 раз удобнее, чем на Rust.
Синдром утёнка никто не отменял)
И это тоже, но не всегда утёнок неправ. Иногда утёнок и правда с первого раза видит свою маму) И вот когда я смотрю на embedded и Си, создаётся у меня ощущение, что здесь всё правильно и хорошо)
Я просто не вижу особо смысла пихать Rust в embedded. Те, проблемы, которые он решает там ваще не возникают зачастую (хотя embedded очень разный бывает, тут уж да). А даже если и возникают, то один фиг со всех сторон придется обмазываться unsafe-ами.
Можно попробовать аргументировать, что вот за обмажемся "unsafe-ами", напишем safe обертки и заживём, но в embedded, не особо-то много логики, которую реально можно так обмазать. Все эти абстракции будут регулярно протекать.
Те, проблемы, которые он решает там ваще не возникают зачастую
Такой embedded подгребет последним, да. Но внедрение поддержки Rust в QNX, к примеру, уже анонсировали в этом году. То есть сегодня вы не видите смысла менять С, как умолчательное решение, а лет через 10-15 лет, когда вокруг будет армия растоманов, переползающих из других областей, все может выглядеть уже не так однозначно: "Зачем брать C, если Rust умеет все то же самое и даже больше?".
Там ещё и у FreeBSD оказывается тоже что-то есть по ржавой экосистеме.
Что?
В документации по FreeBSD есть секция, рассказывающая как писать модули ядра на Rust. То есть кто-то сделал похожую работу для ядра FreeBSD, которую делал для ядра линкукс Охеда
Вовсе не факт. Всё может сложиться абсолютно наоборот - мода на Rust пройдет, и лет через 10-15 будут спрашивать "Rust? это что-то типа Delphi?"
Разумеется) Речь была о том, что не мгновенный набор популярности языка зависит не только от самого языка.
Delphi убила в первую очередь жадность и медлительность компании-разработчика, а не технические причины. Хотя наличие конкурента в виде C#, который тоже позволяет создавать графический интерфейс под Windows одной ногой закрытыми глазами, тоже помогло смерти Делфи
Embedded тоже бывает очень разного уровня. Кто-то и питоновский скрипт, запущеный на малинке и дергающий датчик назовет embedded. Есть не слишком дорогие МК на армах, куда даже JVM умудряются впихнуть. А есть какой нибудь batteryless, где даже чистый Си ассемблером для оптимизации разбавляют.
Сфера Embedded - это как машина времени, которая словно переносит вас на 20 лет назад...
Нет. Просто предметная область предполагает ограниченость вычислительных ресурсов, а за первые десятилетия вынужденной ограничености этих самых ресурсов был найден компромис между человеком и машиной в виде Си и С++. А за последние десятилетия еще и добавился большой пласт legacy в виде библиотек и стандартов де-факто. Слишком глубоко и широко находится С/С++. Заменить на что-то другое будет слишком дорого стоить для всей инфраструктуры.
Между прочим, 20 лет назад в большинстве сфер IT было куда лучше...
Ни один адекватный человек сейчас не начнёт новый проект на Си
Чего? Это либо толстый троллинг, либо полное непонимание современного положения дел, хотя бы на TIOBE посмотреть. И могут, и начинают, и это адекватнее того же Rust'а.
Ни один адекватный человек сейчас не начнёт новый проект на Си, если только не религиозный фанатик.
При всем уважении, прочитав ваши комменты я пришел к выводу что религиозный фанатик тут как раз вы, учитывая то как у вас горит седалище от одного упоминания сишки и как неистово вы фапаете на раст.
Извините, но называть неадекватами профессионалов лишь за то что они используют инструмент который вам не нравится - довольно быдланское поведение.
неистово вы фапаете на раст
Не поверите, но за всю жизнь написал всё же больше кода на Си и С++, нежели на Расте.
называть неадекватами профессионалов лишь за то что они используют инструмент который вам не нравится
Да мне ваще параллельно на то, что кому нравится. И Си, и Плюсы, и Раст сам использую по мере надобности без лишних слов. А говорю лишь об упёртости и не желании смотреть в будущее, страхе смерти своего лампового Сишечки. Раст -- это же страшно, это для зумеров, его читать невозможно, а писать так вообще -- руки отсохнут!
Примерно как сравнить людей, кто боится летать самолётом и ездит поездом, убеждая всех вокруг, какие опасные и дорогие самолёты.
Да, оба будут в одной и той же точке рано или поздно. Оба достигнут цели, но тот, кто летел на самолёте ещё успеет погулять, поспать, поработать, пока второй ещё катится по рельсам своего комфорта и стабильности, ковыряясь в дебагере, где у него там чего случилось.
Я искренне хочу услышать от людей, кто серьёзно взялся за Раст и с уверенностью может сказать, что технология гавно и не подходит для его задачи. Очень хотел бы посмотреть я на эту задачу и этих "профессионалов". Но обратных же примеров куча. Подавляющее большинство тех, кто взялся за Раст, теперь за уши от него не оттянуть =)
А уж право решать, кто тут быдло, оставлю вам, простите.
Спасибо! Без С никуда)
В микроконтроллерах сложно заменить на что-то другое.
Что уже есть rust для 8051?
Только кто этим будет пользоваться в промышленной разработке, уже много раз слышал про javascript и micro python для микроконтроллеров, и это в ту же степь, подойдёт только самоделкиным или тем, кто к embedded не имеет никакого отношения, и надо быстренько запилить проект под какие-то нужды не вдаваясь в суть дела. Я думаю, С из разработки встроенных систем выдавят ещё очень нескоро
Ну вот есть два джуниора-студента. Один выучил Rust, но С не знает, другой С, но о Rust только слышал. Кто быстрее найдет работу в области эмбедед или геймдеве? На мой субъективный взгляд доучить синтаксис и особенности rust поверх С/С++ вопрос нескольких недель практики. Если умеешь нормально писать на С, то код на rust будет сложно испортить. Понять зачем что-то делается так, а не иначе в С/С++ после rust - совсем другой уровень сложности. Однако без этого понимания С/С++ исчезает понимание многих вещей в гововых библиотеках и опыте предыдущего поколения разработчиков. Насколько уверены в гениальности джуниор-студентов, чтобы доверить им изобретать очередной велосипед на rust?
Ох уж эти мифические джуниоры на расте. Ну ни в жизнь не поверю, что найдется хотя бы один студент, который начал бы с раст и не трогал ничего кроме. Я думаю, что Rust как первый язык - очень плохая идея, как минимум из-за его высокого порога вхождения, что определённо демотивирует многих новичков. И если внезапно такой студент появился, то думается, что он вполне способен осилить и геймдев и встроенку и что угодно ещё. Причём с большим пониманием, почему так.
Я работаю в embedded, и 90% любого проекта, связанного с контроллерами, пишется на С, даже С++ файлы используются разве чтобы стек lwip поднять или немного облегчить себе жизнь, скажем, сделав класс для парсинга текстовых команд.
@slsktnkv написал "разделить" (это значит отдельно голосовать за С отдельно за С++) а не заменить.
Rust в принципе может использоваться вместо C и C++
А бывают мидл разработчки на rust без знания С/С++?
Не может. Напишите мне код на Rust, без unsafe, реализующий участие узла в четырех двусвязных списках сразу - типичная задача в ядре.
Чем же вам unsafe не угодил? Даже в этом режиме большинство проверок продолжают работать.
Ну потому что всякий смысл Rust в нём теряется, и получается просто неудобный C++. Если уж unsafe, проще Си и брать.
Не теряется) По ссылочке выше есть информация о том, что на самом деле делает unsafe. То есть, если вдруг понадобился один-единственный сырой указатель, то небезопасным может быть только он, а все остальное вокруг может быть на безопасных ссылках, обмазанных лайфтаймами и прочим. У сей нет возможности опционально включать безопасный режим, а в расте точечно делать ансейв - легко.
неудобный C++
С точки зрения новичка C++ - это антоним удобства. Но влившему в него годы времени и усилий будет обидно с ним расставаться, а что-то новое будет вызывать отторжение и раздражение.
проще Си и брать
А в чем простота, ключевое слово писать не надо?
Это стандартный ответ религиозных фанатиков Rust, не умеющих посмотреть на объективную реальность и практичность.
> С точки зрения новичка C++ - это антоним удобства.
Именно на это и был намек - будет еще неудобнее.
А в чем простота, ключевое слово писать не надо?
В том, что не нужно тащить в голове весь багаж Rust (как не нужно и багаж C++), и можно сосредоточиться на предметной области. Размер багажа примерно определяется BNF языка плюс необходимых ей концептов.
Поясню с более философского уровня - есть прогресс, а есть регресс. Прогресс хорошо, регресс плохо.
Есть сложность предметной области, а есть - accidental complexity.
Если мы снижаем вторую - это хорошо, и это прогресс, а не регресс.
Так вот, языки типа C++ и Rust - повышают accidental complexity, не давая ничего _существенного_ взамен. Нет, сказки про безопасность рассказывать не надо, это не подтверждается измерениями.
Нет, сказки про безопасность рассказывать не надо, это не подтверждается измерениями.
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.
Размер багажа примерно определяется BNF языка
А весь багаж вариаций UB из С++ тоже входит в BNF? :D
будет еще неудобнее
Приведите пример, а то звучит, как стандартный ответ религиозных фанатиков С)
В том, что не нужно тащить в голове весь багаж Rust
Эм… тащить? Либо владеете инструментом, либо нет. Когда его знаете — уже ничего за собой не тащите, это набор инструментов, облегчающих жизнь. Rust сложнее, чем C, но проще C++, при том обеспечивает некоторые преимущества.
можно сосредоточиться на предметной области
Можно сосредоточиться на рутине своего инструмента, вроде ручного управления памятью и отлаживания доступа к висячим указателям)
Размер багажа примерно определяется BNF языка плюс необходимых ей концептов.
С прост синтаксически, но концептов по борбе с отстреливанием ног в нем достаточно. И вот их как раз придется "тащить" в код каждый раз.
сказки про безопасность рассказывать не надо, это не подтверждается измерениями
Списки багов по текущей памяти, дата рейсам и уязвимостей через выход за границу буфера у различного софта более, чем красноречивы.
А есть конкретный пример?
Пока не увидел чего-то криминального и требующего unsafe. Veclist кажется осилит справиться с тем что используется в структуре. Можно конечно и с честными списками заморочиться, но вроде не особо нужно. На Си оно так выглядит из-за отсутвия Vec и генериков.
Ну вроде ситуация, когда объект надо хранить в 2х коллекциях не супер частая, но и не очень уж редкая.
Есть какое-нибудь best practics на Rust как это делать?
- разумеется объект должен быть мутабельным
- желательно чтобы это скэйлилось на N коллекций.
(разумеется "как-то" я могу придумать, но начинают лезть не очень хорошие trade-off).
И вот такие вопросы (ну просто они регулярно всплывают "что будет если") меня останавливают от того, чтобы Rust тянуть в prod.
Для одномерных структур - Vec, VecDeque и LinkedList есть. Для примера выше, где перекладывают из одного списка в другой этого хватит. Если хочется связывать списки друг с другом, то можно обмазывать хранимый тип в Cell / Box. Можно свои листы написать. Для линуксового ядра подозреваю что-то отдельное изобрели. Есть варианты работы с графовыми структурами, если хочется устроить совсем адок с указателями во все стороны.
И вот такие вопросы
Москва не сразу строилась. Но и про прагматизм забывать не стоит. Там ещё и людей, которые потом поддерживать ржавый код будет в дефиците. Знакомый как-то так какой-то внутреннюю утилиту на своей работе из-за этого переписывал на С++, правда там какой-то другой язык был. Скалисты по тому же принципу без работы ходят- своё болото в родной кампании осточертело, а нового болота ещё никто не сделал.
Есть ещё TMIR-OSDev, где можно подсмотреть какие-нибудь необходимые структурки.
реализующий участие узла в четырех двусвязных списках сразу
Но, простите, зачем? Нет, серьёзно.
Идём на hh.ru и видим количество вакансий разработчиков:
Swift: 670
Kotlin: 1164
C#: 2680
PHP: 3335
Java: 4362
Python: 5284
JS: 6768
1C: 11002
Вопрос - почему 1С нет в опросе и посте? Актуальность, объективно, выше условного Delphi.
потому что в целом это вакансии на какого-нибудь завскладом, бухгалтера... и многое другое, но не программирования. в выдаче все смешалось видимо
Нет, это именно "программист 1С". Если брать вообще все вакансии, в т.ч. не связанные с программированием, то на hh их будет на порядок больше: 143282
1) 1С никому за пределами СНГ не интересен, то есть глобально в мире доля 1С будет исчезающе малой. Соотвественно, как только мы рассматриваем глобальный рынок и возможности релокации — 1С не может быть хорошим выбором,
2) По той же причине, по которой нет программистов на SQL, Html и Excel. "программист 1С" это скорее отдельная профессия, как верстальщики, бизнес-аналитики и т.п.
Вообще, за границей есть разделения "Software Developer"/ "Software Engeener" / "IT consultant". Вот инженеры, настраивающие условные SAP и т.п. системы, это скорее последние два, чем первая профессия. Это не значит, что они хуже, просто это совсем другая профессия.
Может вы себе представляете консультанта 1с, который обновит платформу, поможет настроить отчёт бухгалтеру в небольшой фирме, где просто купил/продал и ничего сложного.
У нас, например, очень много тонкостей в работе и 1с занимается именно программист, который пишет и изменяет код по запросам руководства. Не вижу никакой разницы с другими программистами, работающими в больших проектах. Он точно так же может написать простенький скрипт или целый интерфейс со всей логикой его работы.
1) Ок, рассматривайте возможность релокации. Но в РФ и СНГ много-много десятков миллионов населения - все они не релоцируются. И работать/получать услуги не перестанут. Значит всегда будет спрос на этом рынке и всегда будут программисты, которые здесь готовы и хотят жить. Почему их интересы (актуальность для них языка и платформы) должны игнорироваться?
2) Matlab, Fortran, R, VBA, Blueprint тоже языки-инструменты очень узкой направленности. Это им не помешало встать в опрос. 1С чем хуже, тем что его здесь делают?
1) 1С никому за пределами СНГ не интересен, то есть глобально в мире доля 1С будет исчезающе малой. Соотвественно, как только мы рассматриваем глобальный рынок и возможности релокации — 1С не может быть хорошим выбором,
Я не собираюсь релоцироваться. Мало того, на 1С я зарабатываю достойные деньги, которые не смогу заработать на VBA, который в списке почему-то есть.
Странный рейтинг для РФ, ИМХО.
1) 1С нужен за пределами СНГ. Украина с 2018 года выходит из СНГ, членом которого она не была. Но все никак оуончательно не выйдет.
2) "SQL, Html и Excel" - не языки программирования, по этому и программистов нет )))
Если еще по алфавиту упорядочить, 1С будет первый ))
Нет Lua...
zarytskiy, добавьте Clojure и Elixir, пожалуйста
Python гибкий )
@zarytskiy, пожалуйста добавьте Smalltalk. Это достаточно живой язык. Есть активно развивающиеся бесплатные реализации (например Squeak/Pharo), так и платные (например Cincom VisualWorks). Для создания моделей систем и экспериментов в программировании он хорошо подходит.
А Lazarus пожалуйста уберите. Это не язык программирования, а IDE для разработки на Object Pascal.
Ещё стоит добавить Erlang. Это тоже живой развивающийся язык со своей узкой нишей.
И странно почему написано Assembly, а не Assembler. Я чего-то не знаю, отстал от жизни?
Коль добавили Powershell, то наверное стоит добавить и Bash-скрипт. Который очень популярен в Unix среде.
Assembler это транслятор в машинный код. А Assembly это язык. Не зря же говорят, язык ассемблера)
Только он не bash, а shell.
А про Smalltalk интересно... эти бесплатные реализации дружат с Си-либами?
А про Smalltalk интересно... эти бесплатные реализации дружат с Си-либами?
Использовал VM GNU Smalltalk из C++. Правда, давно это было ...
Да дружат. У Squeak/Pharo есть пакет FFI, внутри которого есть примеры использования. На wiki.squeak.org есть инструкция и простой пример.
Cincom VisualWorks Smalltalk существует в бесплатном некоммерческом варианте. По функционалу такой же как и в коммерческий вариант. И у него вроде как с этим делом даже лучше. Есть пакет DLLCC и подробная документация в формате pdf в составе дистрибутива.
а как же html? (если что, шучу)
Лучший язык программирования - это как лучший дистрибутив Linux. Или лучший стиль боевого искусства. Или лучший тип кузова автомобилей. Его в такой постановке вопроса не существует - он может быть лучшим для чего-то (т. е. с узкой точки зрения), либо лучшим для кого-то (т. е. по принципу нравится - не нравится). В обобщённом случае - все хороши.
@zarytskiy, добавьте dart пжлст
В список неактуальных.
разве он не актуален ?
Скорее неактуален, чем актуален. Пользовательскую базу так толком и не успел нарастить и уступил позиции в пользу TypeScript. Хотя в ковидные времена были какие-то попытки воскресить развитие языка, но оно вроде даже в недрах породившего его гугла так и не нашёл широкого распространения, уступив тому же Go. Энтузиасты ещё есть и даже на хабре иногда всплывают, но это скорее нишевая забава вроде Haxe. Кампания, которая долгое время писала на Dart и писала про это на хабр тоже в итоге решила пересесть на кажется тот же TS, главным образом потому что им почти в соло приходилось тянуть экосистему. Это уже наверное год 19 или раньше.
Чтобы быть успешным в мире IT, важно выбрать актуальный и востребованный язык программирования для изучения
Если вы не вайтишник, которому надо прям здесь и сейчас, а например студент, у которого есть достаточно времени, чтобы изучить предметную область, то не так важно, с какого языка начинать учиться. Хоть с паскаля. Вероятность того, что после учебы вы будете программировать на томже языке, что и во время учебы, невелика. Все равно в какой-то момент язык придется сменить
объяните плз такой отрыв пайтона, кроме того что он служит пакетным менеджером для датасайнтистов что на нем сейчас пишут и зачем?
Как скриптовый, например. Считать и распарсить файл, забрать/закинуть в/из СУБД + API данные + вывести их в excel/xml. Можно скриптить в файле, можно в Jupyter notebook + выводить диаграммы и т.п. Удобно и порог вхождений небольшой.
В machine learning очень много пайтона.
Люди занимающиеся наукой и исследованиями используют пайтон.
Вообще очень универсальный язык с огромным набором всевозможных библиотек.
Люди занимающиеся наукой и исследованиями используют пайтон.
Сейчас уже есть возможность почти безболезненно от него отказаться в этой области. Джулийный мир развивается довольно активно.
уже есть порты всяких NumPy/PyTorch и прочих числодробилок с похожим API?
NumPy в Julia точно не нужна, поскольку векторные операции - часть её синтаксиса. А оптимизация циклов же выполняется компилятором. Касаемо "портов" - вообще-то она разработана именно под математику и научные вычисления. И тащить в неё библиотеки с чужим синтаксисом - не факт, что нужно. Но если очень надо, можно и PyCall вызвать. В целом, код на Julia будет компактнее, чем Python, поэтому тащить из него API библиотек как есть - это создавать ненужные надстройки.
Вместо PyTorch можно использовать родную Flux.jl, либо оптимизированную ONNXRuntime.
Проблема, что для того чтобы пересадить людей с Питона на Джулию надо как минимум иметь понятный API, который мапился бы примерно 1 к 1. Я понимаю, что R и Julia заточены под подобные юзкейсы, но существует ли это в виде некой экосистемы - вопрос открытый. Ну и естественно, нужно больше туториалов про решение таких задач на Julia, а ещё лучше кейсы от крупных кампаний, которые занимаются чем-то таким. Я тут маленько сбоку, поэтому не интересовался что там с новостями по теме и как развивается сообщество языка.
API библиотек как есть - это создавать ненужные надстройки.
Ну, это бабушка надвое сказала, на самом деле. Когда-то и у питона urllib был библиотекой, поверх которой крафтили ещё библиотеки. Кому-то дефолтного API достаточно, кто-то хочет абстракции попроще.
Проблема, что для того чтобы пересадить людей с Питона на Джулию
Первый же вопрос - а нужно ли это делать?...
Структура ЯП в области 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% сохранением интерфейса - это потенциально неэффективный по исполнению или визуально громоздкий код.
Очень непросто взять и отказаться от чего-то. В научных вычислениях тренд последних 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 (хотя я на нём ни строчки кода не написал) потому что это первая за долгие годы свежая платформа, заточенная на вычматы, в отличие от многих других новомодных языков. Но понадобится ещё очень много времени, чтобы этот язык начал играть заметную роль в научных вычислениях.
Ну например что я делаю на пайтоне:
1) Большой бэкенд на работе. Весь бэкенд на пайтоне. Как машинной обучение, так и API.
2) Для себя. Более сложные скрипты, которые неудобно писать на Bash.
3) Для себя. Простенькие веб интерфейсы.
4) Для себя. Простые программки для Распбери.
5) Для себя. Пробую Kiwy, хочу делать простенькие программки для Android.
Ну и вообще, питон сейчас работает почти на всем, что шевелится, не Си, конечно, но все-таки.
Это следствие хайпа на machine learning. Миллионы мух не могут ошибаться.
Универсальный и везде применяется. Один раз выучил - и пиши хоть игры для телефонов, хоть вирусы, хоть нейросети, хоть просто автоматизацию по мелочи. "Можно перейти на", а можно и не переходить.
А что подразумевается под словом лучший?
Например,
С++ лучший язык для обработки данных и "машин лёнинга"?
Fortran лучший язык для написания драйверов и управления контроллерами SCADA систем?
;)
Где ABAP? Среди неактуальных он самый актуальный
Val
Забавно, что в списках есть всякие Erlang/Ocaml/Elixir, но нет F#. И всяких сишных альтернатив пожалели а ля V или Zig.
Cobol в неактуальные закиньте плиз...
Отдельно доставляет как Rust в обоих списках занимает лидирующие места :)
Все еще не понимаю почему Go и Rust существуют. В смысле, посмотрите на их синтаксис...
а что с ними не так? Просто когда работаешь со своим языком особо нет времени изучать другие
Так посмотрите на Python, а он вообще в топе)
Python был хорош, но набежала толпа и превращает его изо всех сил в C++/Java.
То есть хотеть скорости от языка это такой смертный грех? Всякие 10к rps из коробки, а не из танцев с бубнами и общением с Си.
Вы про что? Я больше о синтаксисе и посказках типов. Прироста скорости они не дают никакого.
Что касается желания скорости от интерпретируемого языка, то как мне кажется оно несколько неуместно, да и не особо нужна скорость Си в 95% случаев, ИМХО. Гораздо важнее скорость написания. А на 5% есть библиотеки, Си и Cython.
Совсем не скоростью исполнения взял питон.
В плюсоджаву оно превращается именно по причине не очень высокой производительности и сложности в отладке. Там в планах использовать эти самые тайп хинты в том числе и для JIT и прочей компиляции. Всякие линтинги на основе хинтов народ уже довольно длительное время пилит.
Я лично думаю, что они не получат скорости плюсов и джавы и одновременно убьют лучшие черты питона.
А в чем проблемы с отладкой?
def sum(a, b):
return a+b
sum(1,2)
sum("asd","qwe")
sum((1,2,3),(3,2,1))Если кратко - то вот такие перегрузки очень больно отлаживать не зная ни входных ни принимающих типов. Хинтинги уменьшают скоуп проблемы до перегрузок с конкретными типами. Как-то так и взлетел TypeScript, который по большей части тот же JS только с более строгими типами.
Зачем такое писать?
Но если напишете, такое работает по умолчанию в питоне. Если попытаетесь сложить разные типы, питон ругнется и выдаст стек, из которого вы легко найдете, где ошибка.
Вы с Джаваскпирт не перепутали? В питоне по умолчанию строгие типы.
Так типы-то одинаковые и они прекрасно складываются. Но когда у тебя разношёрстный пайплайн может случаться логическая ошибка и тогда будет складываться не то, что хотелось складывать. Пример естественно сильно упрощён.
Пример немножко посложнее - представьте фабрику потоков - сетевые, файловые, интерпроцессорные и пр. Всё естественно асинхронно. Все данные стекаются в общий синк на дальнейшую обработку. Но вот незадача - в бухгалтерии что-то перепутали и сетевой поток скормили в нтерфейс файлового и теперь половина байт в другом порядке идёт. Как ловить виновника? Как избежать повторения подобных ошибок? Ответ простой - типизировать это. В таком случае на этапе проверки типов будет ошибка, что в файловый интерфейс пытаются скормить нефайловый поток.
У меня такие ошибки ловятся на этапе тестирования. Тесты все равно нужны.
Но что-то мне Ваш пример кажется не совсем жизненным.
Ну и ломается одна из главных идей питона, что такое проверяется в рантайме.
Согласитесь все-таки, Вы хотите сломать существующий питон, в его самых главных фишках и сделать из него что-то среднее между С++ и JAVA, только с синтаксисом похожим на питон и его базой разрабочиков и пользователей. Не нужно так делать.
Хотите язык с типизацией как у C++ или JAVA, берите их или что-то новое, полно такого, с такой же типизацией, а нам оставьте язык со строгой и утиной типизацией.
Добавил: Пока-что на работе мне не смогли привести ни одного внятного примера, когда внедряемый подход с типами помог поймать ошибку. А мусора он добавляет очень много.
Добавил 2: В Вашем римере с пайплайном для JS будут проблемы, он преобразует типы и сложит их незаметно для разработчика. А питон просто честно упадет, что от него и требуется. За что его и любим. Ранний крэш, это великолепно.
Чяднт, что у меня ничего не крашится?
>>> 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'
>>>
Так как у Вас, и не должно крэшится, там с типами все в порядке.
Так и речь изначально про ситуации, когда с кодом без хинтов всё в порядке, то есть код вполне валидный, запускается и работает, до тех пор пока данные идут корректные. Но содержит неявные баги, которые проявятся где-нибудь дальше по пайплайну. То есть ты хотел складывать инты, а тебе случайно прилетело два кортежа с числами, которые функция также неглядя сложила и отправила дальше. Какой-то следующий обработчик наткнётся и покрашится на том месте, где он попытался работать с неподходящим типом. Искать такие ошибки, особенно в асинхронных контекстах может быть очень нетривиальной задачей. Мой же пример сильно упрощён и его отладка естественно займет 2 секунды.
Я на самом деле от питона ничего не хочу. Я его использую редко да и то в основном в виде калькулятора или какой-нибудь веб-паук побыстроляну оформить. Остальной народ, который не использует его в числодробилках типа нейронок/ML использует его в качестве веб серверов, и конкретно в этом месте у питона начинается немало проблем из-за разношёрстности пользовательского ввода и невысокой производительности. Именно в этом случае как раз и начинается неприятная свистопляска, которую безболезненнее решать с типами. Можно конечно выкинуть питон и пересесть на java или .net какой, но если у тебя кодовой базе лет 5, то сколько будет тот перевод происходить?
Ну и естественно в идеальном мире люди пишут тесты, пишут требования и никогда не меняют требования, потому что случился рост пользователей. Если у вас и без типов всё прекрасно, то могу только порадоваться за вас.
Не очень понятно, в чём проблема в подсказках типа. Они до сих пор были опциональны и, скорее всего, таковыми и останутся в Python3. Не нравится -- не используйте.
То ли дело perl...
Жаба forever !!! Для меня это просто спасение, а не язык. Дело в том, что я предпочитаю линукс. А большинство моих заказчиков-работодателей работает под виндой. Поэтому средства разработки/управления для своих электронных игрушек пишу на яве. Большинство моих проектов это некая смесь явы и верилога, с вкраплениями С. Почему не питон ??? Во-первых не люблю динамическую типизацию, даже суперстрогую. Во-вторых идея структурирования кода отступами, кажется мне худшим из того что было в IT со времён ламповых динозавров. Поэтому жаба, жаба и ещё раз java ! Плюс scala, которая легко компилируется в джаваскрипт, если надо делать GUI (GUI последние года три я делаю только браузерным). Из системных языков - С. С очень небольшим и осторожным использованием С++, там где он во-первых реально помогает, во-вторых предсказуем и безопасен. Дело в том что чистый С обладает "прозрачностью". Т.е. глядя на код, довольно легко понять, во что он будет развернут, и сколько это будет стоить. С++ этим свойством не обладает. И операция разыменования какого-нибудь умного указателя, легко может потребовать доступа в интернет. Это не страшно, если приложение предназначено для бухгалтера или геймера. А если оно управляет коробкой скоростей автомобиля ??? А на С(С++) я пишу в основном для электроники, причем порой управляющей чем-то реальным, и иногда опасным. С++ мне кажется непригодным для этого. Слишком абстрактен и слишком многое позволяет. Rust - пока играюсь на десктопе, компилируя и дизассемблируя. Увы, ещё слишком плохо его понимаю, чтобы рискнуть применить для реального железа. Хотя язык очень интересный. Вот примерно так. Прошу прощения, если кого-то ненароком обидел, и прошу не пинать ногами, если с чьей-то точки зрения сморозил глупость.
V язык не смотрели? Судя по вашему комментарию он вам должен зайти хорошо.
Нет, честно говоря даже не слыхал о таком ! Надо будет погуглить. Спасибо за наводку !
P.S. Нашел. https://github.com/medvednikov . Пишут во всяком случае интересно. Наверно и правда мне понравится. И приятно что автор соотечественник. Будет забавно, что расширения исходников придется как-то переименовывать, чтобы не путать с верилогом :)))
Забавно что для языка такого типа есть REPL. Ядра для юпитера как я понял пока нет, но раз есть REPL, без проблем можно будет накатить самому. Удивительно что сам автор до сих пор этого не сделал. Юпитер просто обожаю. Вобщем спасибо за наводку, действительно очень интересная штуковина. Пока есть немного свободного времени, буду разбираться.
По-русски: https://proglib.io/p/v-znachit-yazyk-programmirovaniya-2020-02-23 и https://koplenov.github.io/vpage/
V — это проект, созданный для того, чтобы собирать донаты под обещания выкатить идеальный язык, которые никогда не будут сдержаны.
Ну я бы не сказал. Активность сооба довольно высокая.
Высокая активность != нормальная разработка
Спорить не буду. По первому впечатлению проект мне показался интересным. Возможно через какое-то время напишу здесь статью по результатам тест-драйва в небольшом, но и не совсем тривиальном проекте (ассемблер, симулятор, IDE для моего процессора). Сейчас это сделано на яве, пора писать новую версию. Самому интересно сравнить. Пока на языке не напишешь что-то более не менее реальное, рассуждать о нём можно только умозрительно.
Dart нет в списке...
Пыха ван лав
Весьма интересно, возьму на заметку.
Php всегда будет языком программирования который стоит изучать!
Исходя из пропаганды различных курсов в "этих их интернетах", все делится на две категории: "как срубить бабла если мозгов дофига" и "как срубить бабла если оппыта нет нефига".
И обе порочны.
Во-первых, откуда потенциальному пользователю курсов знать свои реальные возможности? И, во-вторых, рубить бабло в любом случае не выйдет, точка. Максимум что по факту выйдет - дикая "дрочка" и упоротое забивание еще не состоявшейся репутации под плинтус.
А тут сразу возникает законное "почему?" Потому, что натренировать на написание примитивов, скриптов, шаблонов... это легко. Труднее научить думать над кодом до написания кода. И тут, опять же, сразу проходит разделение между языками. Натренировать "на минималке" проще на чем-то, что более или менее можно назвать интерпретатором или на чем-то подобном. В итоге имеем 100500 питон-профессионалов с сертификатами третьего уровня десятой степени университета шестого кантона Ниуэ.
В контексте человеческого развития... Прошел курсы - поздравляю, тебя научили складывать слово МАМА из кубиков. Хочешь получать 100 000 в месяц? Молодец, только каждый месяц сумма будет падать, поскольку бэкграунд тебя не отпустит.
А осознание наступит либо с досираком на кассе, либо с очередным заданием, когда попросят сложить МАМА из Ж, О, П и А.
Не хватает Кобола и Excel )
Лучшие языки программирования для изучения в 2023 году | Голосование