Несмотря на мой статус и очевидную предвзятость как одного из создателей D, я постараюсь отвечать откровенно; Я следовал путям Go и Rust, и я абсолютно точно знаю, где стирают грязное белье в D. Я поощряю людей на аналогичных позициях в сообществах Rust и Go чтобы и они делились своим мнением. Так вот.
Для начала, где то в вопросе должен фигурировать и C++. Должен ли он быть заменен вместе с С, или же он один из кандидатов на замещение С, но в любом случае С++ это ключевой элемент уравнения. Это ближайший язык к С и очевидный шаг вперед. Учитывая возраст С++, я в дальнейшем полагаю в этом вопросе что С++ вместе с С является целью для замены.
Каждый язык имеет ряд фундаментальных преимуществ (я называю их «преимуществом на порядок», далее «10х-бонус», поскольку они квалифицируются в высшую лигу относительно типичных подходов), и ряд проблем. Будущее этих языков и их успех в вытеснении С, зависит от того, как они стратегически задействуют свои 10х-бонусы и как преодолеют свои проблемы.
Очевидно это демонстрация моего собственного дома, так что я знаю, куда надо ходить, чтобы подобающим образом показать только то, что нужно и скрыть грязные закутки. Я также могу рассказать про D больше, чем про оставшуюся пару, по той простой причине, что я знаю его гораздо лучше. Говоря с грубой прямолинейностью, основными проблемами D являются:
Также были конечно, и другие неприятности, но они либо являлись следствием вышеперечисленных, либо имели гораздо меньшие последствия.
10х-бонусы для D я полагаю следующими (еще раз, когда я говорю в 10 раз, это разговорное «лучше на порядок»):
Я должен подчеркнуть, что это исключительно мое мнение, тем не менее стоящее вашего внимания. Проблемы Go в следующем:
Go 10х-бонусы в моем восприятии следующие:
Позвольте мне снова напомнить, что это только мое мнение. Я думаю, что Rust сталкивается с некоторыми интересными проблемами:
Rust’овские 10х-бонусы такие:
Способен ли один из этих языков либо постепенно заменить Си, Си++, либо оба языка в существующих программных системах, и станут ли эти языки приоритетными для проектов, которые сегодня по умолчанию выбирают Си или Си++ — все зависит от способности этих языков использовать свои преимущества и находить творческие решения своих соответствующих проблем.
Прим.переводчика.
Извините за старую статью, просто она мне попалась при завершении своей серии о надежном программировании, и показалась достаточно забавной для цитирования. В Рунете же перевода, да и собственно полноценного обсуждения не нашлось.
Для начала, где то в вопросе должен фигурировать и C++. Должен ли он быть заменен вместе с С, или же он один из кандидатов на замещение С, но в любом случае С++ это ключевой элемент уравнения. Это ближайший язык к С и очевидный шаг вперед. Учитывая возраст С++, я в дальнейшем полагаю в этом вопросе что С++ вместе с С является целью для замены.
Каждый язык имеет ряд фундаментальных преимуществ (я называю их «преимуществом на порядок», далее «10х-бонус», поскольку они квалифицируются в высшую лигу относительно типичных подходов), и ряд проблем. Будущее этих языков и их успех в вытеснении С, зависит от того, как они стратегически задействуют свои 10х-бонусы и как преодолеют свои проблемы.
Позвольте мне для начала разделаться с D
Очевидно это демонстрация моего собственного дома, так что я знаю, куда надо ходить, чтобы подобающим образом показать только то, что нужно и скрыть грязные закутки. Я также могу рассказать про D больше, чем про оставшуюся пару, по той простой причине, что я знаю его гораздо лучше. Говоря с грубой прямолинейностью, основными проблемами D являются:
- Плохой прием публикой после многих лет номинального существования. Долгожители комьюнити могут раскритиковать такое заявление (D в его текущей форме относительно молод, популярность растет, итд). Но такое отношение сохраняется и влияет на дальнейший рост популярности и это факт. В итоге менеджеры и инженеры скептически относятся к популяризации языка, который был неудачником так долго. Более того, время работает против D до тех пор, пока не будет очевидного прироста популярности.
- Печальная история в связи D со сборкой мусора (GC). GC великое изобретение, но решение его использовать в D мгновенно изолировало его от основной целевой аудитории – программистов на С и С++. Для них линия партии выглядела так «Не хотите GC? Не проблема! Можете также использовать D с RAII или с ручным управлением!». Несмотря на то, что в целом это верно, такой подход был практически бесполезным из-за отсутствия поддержки такого стандартной библиотекой, что означало для предполагаемого пользователя оказаться раздетым до трусов и начинать с создания базовой инфраструктуры. Даже для тех, кто не возражал против GC, качество его реализации было довольно невзрачным. В общем можно сказать, что D получил все недостатки GC, но не воспользовался преимуществами.
- Исторические сложившееся отсутствие визионеров. Лишенный корпоративной поддержки, D вело вперед сообщество, в котором проще найти проницательного инженера, нежели проектного управленца или харизматичного лидера. В течение долгого времени успешность попыток D в продвижении и саморекламе имела отрицательный результат. Первый документ о планировании датирован 1 января 2015, а следующая итерация (Vision/2015H2 — D Wiki) вышла на четыре месяца позже запланированного, что является прекрасным примером самоиронии с точки зрения планирования
Также были конечно, и другие неприятности, но они либо являлись следствием вышеперечисленных, либо имели гораздо меньшие последствия.
10х-бонусы для D я полагаю следующими (еще раз, когда я говорю в 10 раз, это разговорное «лучше на порядок»):
- В 10х компиляция быстрее чем С++ для сравнимого кода. Эту дыру нельзя принципиально закрыть в С++, и запредельно сложно перепрыгнуть в любых других языках. (Go компилируется чуть быстрее D, но результирующий код медленнее) Опыт использования системного языка, который так быстро компилирует в быстрый код, является преобразующим старые практики и очень перспективным. В комбинации с мощностью абстракций в D это, по сути, делает D хорошим выбором для написания высокооптимизированного кода по той простой причине, что экспериментирование обходится дешево.
- В 10х быстрее скриптовых языков со сравнимыми удобствами. D хорошо подходит для удобного скриптования повседневных задач. Цикл компиляции/запуска остается таким же быстрым, а выгода в скорости грандиозна. Также нет проблемы «уперлись в пределы» — если скрипт становится большим, в D всегда хватает языковых средств и модульности. Есть, конечно, и ложка дегтя, например в Python’е гораздо больше готовых библиотек. Но 10х-бонус тут фундаментален – системные языки не имеют столько синтаксического сахара, а скриптовые безнадежно отстают в скорости.
- В 10х проще интегрироваться с С и С++, чем любой другой язык. D использует такие же структуры в памяти, что и С и С++; и строит свои поверх них, но чтение нижележащих слоев остается бесплатным в плане скорости. Стандартная библиотека С полностью доступна без всяких штрафов — ни в плане скорости, ни в синтаксическом, и хотя еще нужны некоторые доработки для аналогичной простоты в плане библиотеки С++, многие С библиотеки уже доступны (https://github.com/D-Programming...). Можно заявить буквально, что ни один другой язык не сможет достигнуть такого уровня интеграции.
- В 10х раз лучше любого другого системного языка в дженериках и метапрограмировании. В D статическая интроспекция, вычисления на этапе компиляции (CTFE) и основанная на mixin (примесях) генерация кода составляют коктейль Молотова, который весьма затруднительно корректно смешать в других языках, ни в новых ни в выживших; в этой игре Go настолько не в себе, что даже не сечет фишку; C++17 безнадежно заблудился в темном лесу; а Rust только пытается лепетать.
Вперед к Go
Я должен подчеркнуть, что это исключительно мое мнение, тем не менее стоящее вашего внимания. Проблемы Go в следующем:
- Фундаментальное замедление по причине косвенных вызовов и сборщика мусора (GC). Практически ни одно существенное приложение на Go нельзя написать, не прибегая к косвенным вызовам и GC, которые являются центровой функциональностью. Это основные препятствия для производительности ядра Go. Ответ команды Go был в основном тактическим – например улучшить работу GC. Однако, маловероятно победить в челлендже по замене С тактически.
- Политика. Линия партии в Go непропорционально сильна и жестка по ряду вопросов, как маленьких, так и больших. Один из примеров больших проблем — подход к дженерикам был настолько бессмысленным и беспощадным, что сделал дженерики словом на букву «Г»; вся тема превратилась в кровавые слезы, препятствуя любым попыткам наладить конструктивный диалог. Я думаю, что политизация технических вопросов в долгосрочной перспективе является крайне пагубной моделью, и я надеюсь, что Go найдет способ исправить это.
- Простота хуже воровства. Пойти очень просто (игра слов. Go — ходить, прим.перев) – есть даже анекдоты по этому поводу. Однако со временем это становится проблематичным; Код на Go безнадежно пешеходный — Go-кодеры ловят себя на том, что снова и снова пишут одни и те же вещи с точки зрения муравья, потому что Go не может абстрагировать даже самые простые понятия или алгоритмы. Понятия, которые еще не реализованы библиотеками интеграции, сложно реализовать. Наблюдается негативная реакция со стороны программистов, которые использовали Go для одного проекта и больше не хотят использовать его снова. Было бы неплохо, если бы Go сделал жизнь лучше для постоянных клиентов.
Go 10х-бонусы в моем восприятии следующие:
- 10x в скилле Стратегия. После краткого периода, когда Go позиционировался как системный язык, было решено позиционировать его для сетевых сервисов. Это было великолепным маркетинговым шагом, который использовал сильные стороны команды Go (одни из лучших инженеров в мире по сетевым сервисам). Это очень горячий рынок и Go просто стал глотком свежего воздуха для мира, в котором прежде доминировала Java EE со своим бюрократизмом и медленные скриптовые языки. Теперь Go – основной игрок в этой области и его будет трудно подвинуть.
- 10x в скилле Инженерия. Go за собой имеет крепкую команду инженеров, и это основной фактор влияния на качество языка и в частности на сетевую библиотеку и тулсет. До сих пор хороший инжиниринг вполне компенсировал слабосильность языка.
- 10x в скилле Брэндинг. Многие из нас готовы признать, что главный мотиватор использования Go – это связи с Google. Это придает ему авторитет профессионализма, качества и стабильности. Конечно, брэнд это не все, но это уже делает Go достойным языком; он не должен быть фантастически хорош. Брэнд сделает остальное.
Последний, но не менее важный, Rust
Позвольте мне снова напомнить, что это только мое мнение. Я думаю, что Rust сталкивается с некоторыми интересными проблемами:
- Дисгармоничная личность. После чтения некоторого количества кода на Rust возникают анекдоты типа «Чувак пропускал дни кача ног», иллюстрируемых комиксами с людьми с перекачанным торсом но ногами-спичками (прим.перев. По-русски, «Колосс на глиняных ногах», но неточно) Rust ставит на первое место точное и безопасное управление памятью и представляет это центром мира. Внезапно, это редко является проблемной областью, что приводит к тому, что большая доля планирования и кодирования уделяется, по сути, канцелярской работе (которую языки с GC автоматизируют не глядя). Безопасное, предопределенное переиспользование памяти — серьезная задача, но не единственная, или как минимум не самая важная в программе. В итоге Rust тратит непропорциональное количество ресурсов языкового дизайна только на это. Было бы интересно посмотреть, насколько Rust разбухнет ради других аспектов языка; единственный вариант это расширение языка, но вопрос в том, насколько абстракции смогут помочь с неприятной необходимостью контролировать ресурсы на всех уровнях.
- Чуждый синтаксис. Синтаксис Rust’а отличный [от всех], но нет очевидного преимущества в такой экзотичности. Это раздражает людей, пришедших из языков семейства Algol’а, которым приходится иметь дело еще и с кардинально другим синтаксисом, помимо необходимости ручного ведения всей бухгалтерии с ресурсами.
Rust’овские 10х-бонусы такие:
- В 10х раз лучшие теоретики. Из этой тройки, только у Rust есть теоретики мирового уровня в разработке языков программирования в обойме. Это можно заметить по точности технического описания языка и в глубине технического подхода.
- В 10х раз больше безопасности, чем в других системных языках. Безусловно это должно быть здесь, мы можем только подискутировать о стоимости такого подхода.
- В 10х раз лучший PR (пиар, реклама, прим.пер.) Был довольно долгий период, когда Rust был у сообщества любимицей, которая не могла ошибаться: для любой проблемы Rust уже либо имел решение, либо должен был получить его с выходом 1.0. Реальность выхода 1.0 прервала этот медовый месяц и отметилась (в моих измерениях и ожиданиях) резким снижением общего интереса, хотя эти факторы имеют тенденцию к пролонгации. Плюс, в конечном итоге, Rust — это приличный язык с реальными достижениями, и он хорошо спозиционирован, чтобы превратить этот затяжной хайп в стабильный рынок.
Вкратце
Способен ли один из этих языков либо постепенно заменить Си, Си++, либо оба языка в существующих программных системах, и станут ли эти языки приоритетными для проектов, которые сегодня по умолчанию выбирают Си или Си++ — все зависит от способности этих языков использовать свои преимущества и находить творческие решения своих соответствующих проблем.
Прим.переводчика.
Извините за старую статью, просто она мне попалась при завершении своей серии о надежном программировании, и показалась достаточно забавной для цитирования. В Рунете же перевода, да и собственно полноценного обсуждения не нашлось.
noize
is facing — это совершенно точно не лицом к лицу
QtRoS
Это далеко не самый худший перевод, тут хотя бы смысл понятен, поскольку "столкнулся" достаточно близко к "лицом к лицу".
Zalechi
Вариации:
1. На мой взгляд Rust встретил некоторые вызовы.
2. Я считаю Rust столкнулся с определенными вызовами.
PsyHaSTe
"Слицовался" тогда стоит перевести.
firegurafiku
Я бы сказал, это необравданный буквализм: нет никакой необходимости вставлять лицо в перевод «is facing», как нет необходимости упоминать бога при переводе «bless you». Но этот перевод в целом получился очень буквальным.
Справедливости ради, текст сам по себе не самый простой, в лоб не переводится. Из любопытства я попробовал перевести первые три абзаца, получилось не сразу и с элементами отсебятины.
Хотя моя предвзятость в этом вопросе очевидна, я постараюсь ответить на него откровенно. Несмотря на статус одного из создателей D, я пристально слежу за присходящим с Go и Rust, и я определённо знаю многие неприглядные вещи о D. Было бы неплохо, если бы люди на аналогичных позициях в сообществах Rust и Go тоже высказали бы здесь свои мнения. Итак, начнём.
Перво-наперво, в формулировку вопроса нужно добавить C++. Причём, куда бы вы его ни поставили — в пару к C или в компанию к предполагаемым кандидатам на его замену — без C++ уравнение будет неполным: [из рассматриваемых,] это язык, ближайший к C, и очевидный шаг вперёд от него. Принимая во внимание [почтенный] возраст C++, я буду полагать, что автор вопроса хочет найти замену не только для C, но и для C++.
Каждый из рассматриваемых языков в чём-то фундаментально лучше конкурентов (ниже я так и буду говорить: «на порядок», потому что это действительно так как минимум для некоторых количественных показателей) и в чём-то значительно им уступает. Поэтому и будущее этих языков, и их [возможный] успех в вытеснении С, зависит от того, как они смогут распорядиться своими фундаментальными преимуществами и как они смогут обойти свои слабые стороны.
osmanpasha
Наткнулся в самом начале на "Я следовал путям Go и Rust", плюнул, ушел читать оригинал, а там "I follow Go and Rust", т.е. просто "Я слежу за Go и Rust"
sbnur
Nous y verrons
kITerE
Еще одно (неожиданное для меня) мнение от ребят из Microsoft Security Response Center: Why Rust for safe systems programming.
epishman
Не первый раз прилетают разведпризнаки, что Майкрософт любит Раст, возможно не только платонически ;)
Siemargl Автор
Да, и тоже пока присматриваются.
Возможно, подключатся и помогут.Их похоже, не устраивает . Это из предыдущей статьи в их блоге.
Кстати, статьи интересные, подкидываю идею Растерам про перевод.
BlessMaster
Как сказать "присматриваются".
Например, один из локомотивов асинхронного Rust — Actix — творение рук одного из сотрудников Microsoft: есть сведения, что очень даже активно используется ин-продакшн. Есть и другие примеры.
inv2004
вдвойне приятно, когда заявляние подкреплены пруфами/линками.
PsyHaSTe
Спроси у Николая в чате, он с пруфами тебе покажет.
Сервисная часть ажуры у майкрософта на актиксе основывается.
inv2004
Было бы отлично, если бы ты, как раст-евангелист, показал эти ссылки всем, а не посылал каждого на ними в чат (какой из всех?) к Николаю.
PsyHaSTe
Я в свое время в мейн растовом чате с ним обсуждал это, искать чтобы что-то доказать тебе мне лень. Поэтому я и говорю, если тебе интересно — спроси, можешь сюда потом выложить все, что узнал, если хочется.
Если не хочется — ну значит нет. Быть посыльным чтобы что-то доказать мне не интересно. И да, я не раст-евангелист. Я вот сейчас на скалу устраиваюсь, к примеру. Я скорее противник бесполезной траты человеческих ресурсов на то, что может сделать компилятор.
fafhrd91
Я главный разработчик actix. Активно использую раст и actix в azure iot. Хотя пруфы показать не смогу
inv2004
Это здорово, так как я и сам использую actix. Но, если я правильно вижу, вы писали что это был тестовый проект, или он уже поменял статус?, что, в любом случае, тоже хорошо.
fafhrd91
Тестовый проект уже работает. Сейчас работаю над большим проектом.
Chamie
Я думал, это иллюстрирующая шутка, как про Росгвардию…
xander27
А разве всякие HeartBleed и EternalBlue, не были вызываны как раз ошибками в управлению памятью?
erty
А на чём бизнес больше теряет, на хардблидах или на том, что не успевает за конкурентами?
Сколько бы не хайпали за безопасность, в реальности она не несёт в себе столько потерь, сколько прибыли дают фигак-фигак аджайлы. Sad but true.
BlessMaster
Одна из ниш, где Rust уверенно завоёвывает себе место под солнцем — HFT. Как раз по причине того, что нужно максимум скорости, при этом действительно надёжно и без эзотерических багов как в C/С++. Ибо бизнес в случае чего теряет столько, что мало не покажется. До последнего времени здесь доминировала Java.
siziyman
Там вроде как раз на плюсах частенько пишут, нет?
BlessMaster
Конечно пишут. А куда деваться?
Тот случай когда действительно такты процессора считают.
Но я как минимум знаю компании, где от плюсов именно отказались и зареклись.
И вот Rust теперь предлагает эту плюсовую скорость без компромиссов с надёжностью. Его осторожно пробуют и находят лучшей заменой. Разумеется, жизнь сложная штука: не везде и не все, подобное было бы странно утверждать. Природа поощряет разнообразие :-)
inv2004
Я знаю пример, где HFT переехал с плюсов на java, но вот с явы, и все очень довольны насколько жизнь упростилась, а вот на Rust это дальше переезжать как-то не торопится.
littorio
Я как раз рядовой HFT'шник, и когда наша компания перешла на Яву — это было странным, вокруг все писали на плюсах. Лет через 5 мы вернулись обратно на плюсы, и я не очень понимаю, чем современные плюсы хуже. Ошибки с памятью встречаются весьма редко, скорость работы софта выше (что очень важно). Многие трюки с шаблонами в Яве сделать сложно, язык там зачастую более многословный. Ну окей, контейнеров разных в Яве больше конечно, в т.ч. и потокобезопасных.
Где Ява лучше — так это в скорости разработки. IDE подсказывают, упрощают чтение и поиск кода. Ну и модульность — подсунуть нужный jar'ик это не всю плюсовую тряхомудию пересобрать. Но если это даётся ценой лишних us… то извините.
Rust не трогал… но вот этот комментарий (ссылка) очень заинтересовал. У нас без шаблонов никуда, если в Расте с этим плохо — то беда. Модель памяти там пытался найти (по диагонали) — тоже пока как-то не впечатлило.
Кстати, как у Раста со скоростью разработки? Можно, как в Яве, залезть в кучу незнакомого кода и за десяток кликов в IDE прочитать и понять сложную иерархию вызовов? Fuzzy-поиск по имени типа? Подсказки вида — что может делать этот объект (с всплывающим аналогом JavaDoc'а)?
mayorovp
Шаблоны в Rust есть, в Rust нет переменного количества параметров в шаблоне и нет констант в качестве параметра шаблона.
Модель памяти же в Rust простая: вы можете владеть объектом, исключительно заимствовать его для чтения-записи, или неисключительно заимствовать его для чтения. А дальше — работают стандартные контейнеры и примитивы синхронизации.
ozkriff
Есть надежда в обозримом будущем (этом году или начале следующего?) получить — работающая в ночнике реализация есть, до стабилизации не так уж и много осталось работы: https://github.com/rust-lang/rust/issues/44580
PsyHaSTe
Откуда в расте возьмется переменное количество параметров шаблона, если там нет шаблона?
mayorovp
Шаблоны, дженерики — в данном контексте это не важно.
PsyHaSTe
Varlist types и константы конечно могут и там и там быть, но у майкрософта не одна статья написана , почему важно их различать. Даже если в контексте обсуждения это не особо роляет, сама фраза про "шаблоны в расте" может человека пустить по ложному следу.
PsyHaSTe
Как говорили ребята из биокада, у нас нет времени запускать обработку на несколько часов на тысяче серверов чтобы в итоге увидеть "undefined is not a function" или "SIGSEGV".
Не говоря про то, что корректность зачастую дается бесплатно. Я вроде писал про это недавно.
bevice
Поэтому ребята из биокада запускают туже обработку на сутки и недели, на десятках тысяч серверов, и вместо SIGSEGV видят unhandled exception, зато с GC
PsyHaSTe
Нет, не видят. Потому что у ребят эррор-хендлинг на эффектах с АДТ построен, где нельзя взять и забыть обработать ошибку.
Но писать приходится больше, да. Ту же обработку писать надо.
0xd34df00d
Я не знаю, как там у них, но в х-ле делать ошибки в
IOна АДТ не принято, например.PsyHaSTe
Ошибки так и так принято в Either заворачивать. Как дальше с этим работать — МТЛ ли, фримонада ли, уже дело десятое.
0xd34df00d
IO (Either Err Res)таки considered harmful (и, по моему опыту, дизайн тупо на экзепшонах в той мелкой части вашего кода, которая сама по себе живёт вIO, оказывается чище и разумнее).PsyHaSTe
А чем плохо-то? Какой смысл писать IO, если ошибка (намного более существенный эффект нежели ио собственно) оказывается спрятанной?
0xd34df00d
Тем, что экзепшоны вам тоже придётся обрабатывать. Ваш тред могут прибить, какая-нибудь нижележащая библиотека для работы с HTTP/постгресом/ФС может кинуть экзепшон (потому что IO, да и протягивать все возможные ошибки от всех возможных источников по всему стеку — ну такое), и так далее.
Вот, положим, пишу я скрейпер какого-нибудь сайта. У парсера страниц там, действительно, будет тип вроде
parsePage :: (MonadError ParseError m, MonadReader ParseEnv m) => BS.ByteString -> m ParsedPage(на самом деле чуть сложнее, но не суть). Там это удобно, там это оправдано: я сразу в типе показываю, какие эффекты имеет мой парсер.Но если я пишу уже вызывающий это IO-код, который склеивает всё вместе, то там либо ошибка сразу развернётся, запишется в лог и всё (и тогда в IO-коде выше по стеку её обрабатывать не надо вообще, она уже обработана, ничего лучше вы не сделаете), либо просто кинется как экзепшон выше, чтобы Самый Главный Код, не знаю, попробовал ещё раз через минуту.
То есть, я признаю, что есть некоторая ценность в типе вроде
IO (Either Err Res)в том смысле, что он показывает, что ошибки видаErrточно ожидать стоит. Но дело в том, что:IOв любом случае (благо это легко, в 99% прикладного кода взялbracket, и этого достаточно),PsyHaSTe
Но ведь можно написать IO Maybe Res, чем он лучше Either? Или любой другой враппер. Емнип трансформеры именно для того и придумали, чтобы можно было использовать любую вложенность и не прятать всё в IO ()
JPEG
Так для того тулинг и развивают, чтобы в продакшн и быстрее и безопаснее. Однажды Раст (или кто-то похожий) перешагнет планку «достаточно просто» и мы забудем, как было до него. Мне папа однажды отдал все свои чистые перфокарты, который до этого лежали в важно шкафчике.
Ryppka
Вроде, я это несколько лет назад читал на английском. А в отношении «лицом к лицу» — то можно и лицом к лицу, не хватает сказуемого: что именно Rust вытворяет лицом к лицу с весьма интересными проблемами. Например — сталкивается.
А так перевод норм.
Siemargl Автор
Ок, пишите замечания в личку, буду править, пока карма позволяет.
А по мне так перевод вышел корявым =)
jevius
Ответ на вопрос в заголовке: никакой не имеет. /thread
PsyHaSTe
Не понимаю, почему люди так хотят сидеть на С до скончания веков. Такое ощущение, что тут есть что-то из разряда "я мучился, теперь и вы помучайтесь", с нежеланием выкидывать свой опыт проблем, которые новые языки решают из коробки.
saterenko
А почему люди должны менять C на что-то другое? Мучится? Вы много мучались на C? Это стереотип, главный аргумент апологетов других языков… Какие проблемы есть в C, которые решают другие языки?
По моему опыту, независимо от языка, подавляющая часть времени уходит на реализацию бизнес-логики, на отладку и поиск логических ошибок…
gecube
Си не способствует реализации бизнес-логики. Он как бы слишком низкоуровневый. Как пример — почем взлетел Питон? Потому что в его "стандартной" комплектации есть модули для решения любых задач и он позволяет практически не отвлекаться на особенности языка при реализации именно бизнес-логики.
saterenko
Приведите, пожалуйста, пару примеров, которые показывают, что C не способствует, а тот же Python способствует реализации бизнес-логики.
gecube
Все настолько очевидно, что даже приводить не хочется. Ну, ок, если очень хочется. Типичная задача для бизнеса — взять данные из какого-то REST API, преобразовать, обогатить, отсортировать в каком-то порядке. Python — можно уложиться с модулями типа requests в 1000 строчек кода. Сколько будет на Си? Какова будет сложность поддержки и развития кода? Сколько там будет "глупых" ошибок с выделением памяти?
saterenko
Взять из REST API — это не бизнес-логика, это библиотечная функция. На C запрос по HTTP с помошью библиотечной функции из libcurl займёт десяток строк, написать в первый раз — 5-10 минут, но у меня давно есть обёртка, т.е. один вызов одной функции…
Какой смысл вы вкладываете в «преобразовать, обогатить, отсортировать в каком-то порядке» я не знаю, не могу как-то откомментировать… 1000 тоже не говорит ни о чём, сколько займёт на C не могу сказать…
Сложность поддержки и развития кода зависит от архитектуры проекта, качества кода, от того, на сколько стандартны используемые библиотеки, алгоритмы и т.п. В гораздо меньшей степени это зависит от языка.
Количество «глупых» ошибок с выделением памяти зависит, опять таки, от архитектуры и качества кода. Я использую собственные менеджеры памяти, которые написал лет 15 назад… В текущем проекте, написанном «с нуля», за более чем 2 года, у меня была одна утечка, которая была обнаружена и исправлена на этапе тестов. И раза 3-4, опять таки на этапе тестов, были падения в корку из-за использования освобождённых указателей, все они были быстро исправлены…
Но эти проблемы не касаются бизнес-логики, они касаются «скелета» приложения. Бизнес-логика «наращивается» на этот скелет, она оперирует отлаженными структурами скелета… У меня не было проблем с памятью в бизнес-логике…
Так как вы не привели конкретного примера, я приведу парочку.
Если у вас простая логика, например, получить какой-то набор данных в JSON, пройтись по ним, посчитать какие-то агрегаты, на C это займёт не сильно больше времени чем на Python, так же обращение к REST API по HTTP в несколько строк (с проверкой на ошибки), так же парсинг JSON в несколько строк, чуть более сложное итерирование (на плюсах так же легко как в Python), чуть более сложная работа с ассоциативным массивом (на плюсах не сложнее). Ну займёт это, условно, 15-20 минут вместо 10 минут на Python, не критично. Но такие задачи у меня встречаются крайне редко… Обычно что-то посложнее…
Например, у вас есть база 100М пользователей, надо выбрать всех пользователей, соответствующих заданным критериям (от 7 до 15 критериев). И хорошо бы уложиться в 100мс. И тут ни какие готовые структуры не помогут. Как на C, так и на Python придётся думать над архитектурой, исследовать и тестировать разные варианты, библиотеки, а потом уже написать решение и отладить его… Времени займёт примерно одинаково…
gecube
А потом выясняется, что в этом условном cURL условная уязвимость типа https://imagetragick.com/
/к самому cURL у меня претензий практически нет… хотя иногда проскакивает/
и да, и нет. С одной стороны — тот же Питон прекрасно подходит для прототипирования и написания чего-то типа CRUD'ов. С другой — что-то серьезное на нем написать та еще морока. Именно из-за особенностей самого языка. Действительно, начиная с какого-то уровня сложности ты больше упираешься не в язык, а в библиотеки.
Ошибка выжившего. Выявленные ошибки — устраненные ошибки. А сколько не выявлено?
тоже отличная иллюстрация — строим свои велосипеды ((((
вот с этим категорически не согласен. На С (не С++!) это будет ад и морока. А еще оно может поплыть в любой момент времени, когда входные параметры изменятся. На С++ это будет скорее всего нечитабельная и неподдерживаемая магия на шаблонах. И время компиляции в космос.
saterenko
Давайте вспомним уязвимости процессоров, и всё равно, си у вас или пайтон… Да и для пайтона CVE-шек хватает…
В других языках их нет? Я надеюсь, что более 19К проверок в юнит-тестах и порядка 10 000 rps на проект говорят о том, что критичных ошибок нет :)
Велосипедистом можно назвать почти любого программиста, потому как практически всё уже написано, бери и используй… Мой менеджер памяти — это фреймворк, библиотека, позволяющая мне работать эффективнее и не писать лишний код. Да и решает проблему с ошибками, потому как давно отлажено.
Ни одна база не решит эту задачу, может ClickHouse позволит решить её за разумное время, но не за 100мс. Локальными средствами она вполне решаема, но время на разработку почти не будет зависеть от языка.
Какой у вас опыт на си и на плюсах? Да, работа на си с JSON будет менее приятная, чем на плюсах или пайтоне, но не ад… На плюсах ничего сложного. Вот, к примеру, чтение конфига:
Вот пример вспомогательной функции:
Код на пайтоне, с проверкой наличия переменной и его типа, займёт не сильно меньше места.
Время полной сборки проекта на 100К строк 1 минута 45 сек. Но сборка инкрементальная, в реальной работе сборка обычно занимает 5-10 сек…
Gorthauer87
И один
#[derive(Deserialize)]на расте.0xd34df00d
Примерно 15 лет.
Работать с жсоном, REST и так далее больно. На моём любимом хаскеле приятнее и эффективнее (а так как это язык компилируемый, и с достаточно качественным компилятором — эффективно ещё и в рантайме).
Я как представлю себе, что это всё писать надо, так становится грустно и пальцы сводит.
Впрочем, при мыслях о питоне тоже пальцы сводит.
saterenko
Ну, вопрос по опыту я не вам задавал :)
Я думаю, не совсем корректно сравнивать си и хаскель в задаче парсинга JSON, таки разные парадигмы, а задача парсинга JSON должна очень элегантно решаться функциональным языком, как мне кажется. Завидую вам по-хорошему, у меня не хватает времени серьёзно взяться за хаскель, весь мой опыт в функциональных языках — это пролог в начале 90-х и эрланг в начале 00-вых…
На плюсах есть rapidjson, с которым я не испытываю ни какой боли… На голом си всё не так хорошо, но много с JSON-ом работать не приходилось, сделал сериализацию/десериализацию и забыл…
Ну у каждого своя аллергия… У меня вон на алкоголь вылезла, а дома Glenmorangie The Nectar d'Or стоит, вот это обидно, да :)
0xd34df00d
Да там в большинстве случаев даже решать ничего не надо. Структуру данных описал с именами полей, соответствующими полям в жсоне,
deriving (Generic, Aeson.FromJSON)написал, и всё.О, я его года два назад ковырял последний раз. Там была какая-то совершенно уродливая документация, никакая обработка ошибок и что-то ещё. Короче, мне было больно.
Вот nlohmann_чётотам неплохо, да.
vedenin1980
Сомнительно, но представим, что так. Одинаково, ли стоит хороший разрботчик на С и Python? Достаточно ли много разработчиков на С на рынке, чтобы быстро сделать хорошую команду? Можно, ли взять любого толкого студента изучившего синтаксис и дать ему делать простые вещи на С не боясь, что он что-то сломает?
В любом случае, бизнесу придется заплатить за разработку одинакового продукта больше на С, чем на Python. Зачем? Ну вот обясните, мне как бизнесмену, почему я должен отдать лишние десятки тысяч $ только потому что внутри будет другой язык?
Вы написали, а та команда, которая нужно сделать проект с нуля на С? Это ведь не честное сравнение, на любом языке можно написать такой фреймворк, где вообще большая часть типовых задач будет решаться настройкой параметров в вебинтерфейсе. Вот вы потратили время на свой велосипедный «менеджер памяти», это уже косвенные издержки на разработку текущих проектов. А если вы уйдете, вы уверены, что другие разработчки в команде смогут поддерживать и развивать ваш велосипед так же легко?
gecube
Мне кажется, что вообще о честности говорить странно. Что в общем, что в частном (в применении к коллеге).
И еще меня все-таки очень интересует не происходит ли подмены С vs C++ в нашем споре.
saterenko
Стоит денег не язык, стоит опыт и умение решать проблемы. Студенты-кодеры буду косячить на любых языках примерно одинаково. Т.е. если у вас цель заплатить 2-3 раза, то можно «взять любого толкого студента изучившего синтаксис». Если вы хотите решить задачу, вам должно быть всё равно на каком языке она решается (исключая экзотику). И вы, как бизнесмен, должны это понимать…
Я говорю о решении реальных задач на языке специалистом, а не о решении задач студентом, без опыта работы. Давайте тогда уберём из языков стандартные библиотеки, закроем доступ в интернет и будем сравнивать ))))
gecube
Тем не менее — стоимость разработки на разных языках будет разная (иначе почему сайты на ассемблере не пишут?). И мастерство профессионала как раз и состоит в подборе правильного инструментария.
saterenko
Я считаю, что стоимость разработки разными разработчиками (командами) будет разная, а не на разных языках. Время разработки на том или ином языке сильно зависит от того, что и кем разрабатываться, т.е. зависит от специфики проекта и опыта разработчика.
Сайты не пишутся на ассемблере потому, что это неэффективно, «стрельба из пушки по воробьям»… Но местами ассемблер незаменим, например, при git-компиляции…
PsyHaSTe
"Ни одна техника не спасет от всех багов, поэтому давайте пользоваться тем что работало в 80х" (с)
В том-то и дело, что не будут косячить одинаково. К примеру на условном хаскеле вы никогда не получите доступа по неправильному указателю, потому что их тупо нет.
0xd34df00d
Как вы думаете, сколько UB у вас в коде на С?
А то я тут вчера пытался кое-что написать, и мне в очередной раз припекло. Ну там, кусочек памяти заммапить и проинтерпретировать как
int, условно говоря.saterenko
Что такое UB? И что вы хотели этим сказать?
gecube
Вы не знаете что такое UB? Очень жаль....
mayorovp
Undefined behavior. Неопределенное поведение. Если кратко — ситуация, которая не должна возникать во время работы программы, а если возникнет — то компилятор за дальнейшее поведение программы ответственности не несет.
Странно слышать от вроде как опытного сишника, что он не знает расшифровку этой аббревиатуры...
saterenko
Я знаю, что такое Undefined behavior, но за аббревиатурой не признал, бывает… Спасибо, что пояснили…
0xd34df00d
Дяденька, а вы точно сишник?
А сказать я хотел, что опыта в плюсах у меня вроде немало, но вот писать код, который будет выполняться (а не метапрограммы там всякие) мне что-то всё более стрёмно.
Вот, к слову, в С встречается паттерн
Как думаете, это валидный C++-код? Обратная совместимость ведь, да?
mayorovp
А какие новые проблемы могут тут в С++ возникнуть, кроме той что malloc устарела?
0xd34df00d
Лайфтайм объекта (не в смысле ООП, а в смысле стандарта) не начался. Надо placement new сделать в выделенный кусок памяти, например.
Умный чувак Richard Smith описал это всё лучше меня: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0593r3.html
saterenko
Точно, на всю голову ))))
Скажем так, я с проблемами в таких местах не сталкивался, но понимаю, что компиляторы в некоторых случаях могут перемудрить… И эту «мудрость» можно искать ой как долго… Я стараюсь в плюсах не выделять память под классы (структуры) через маллоки…
BlessMaster
Проблема, в общем-то, не в том, что компиляторы "мудрят", а в самом дизайне системы с пунктом "человек не должен ошибаться". Если человек что-то пишет, компилятор обязан предполагать, что человек — всё точно продумал и знает, что делает. Этот подход исключительно плохо работает из-за того, что человек невероятно склонен совершать ошибки. И чем сложнее система, тем человеку сложнее удержать в голове все её особенности, а значит вероятность ошибок растёт с развитием возможностей этой системы.
KanuTaH
Тока тут такой момент — в C не требуется делать (Foo*). А ошибка при компиляции типа «cannot convert void* to Foo*» как бы намекнет писателю, что он уже не на C пишет и надо бы заменить malloc на new. Обратной совместимостью тут и не пахнет, а то, что погромист решил заткнуть дырку через по сути reinterpret_cast — ну, сам виноват. В расте такие же погромисты будут подобные дырки через unsafe затыкать.
0xd34df00d
Это уже частности. Давайте смотреть абсолютно формально: вышеприведённый код является корректным кодом на С (ну с точностью до
structтам передFoo), но не является корректным кодом на C++, no diagnostic required.А вообще я в предыдущем комментарии не зря про
mmapговорил. Его вы на что замените?KanuTaH
Я к тому, что «обратная совместимость» тут не при чем, и ее тут нет. Компилируемость достигается через добавление reinterpret_cast, который говорит компилятору «я погромист, я лучше знаю, делай, как сказано». Он для этого и предназначен.
0xd34df00d
Именно.
Но количество кода, которое так что-то считывает из сокета, или из файла, или ещё откуда, меня немножко печалит. Или пугает, хз.
Ryppka
На счет корректности в C не уверен на 100% — там выравнивание может не сойтись. К сожалению требования к выравниванию — не часть типа.
KanuTaH
malloc() обычно реализован так, что возвращаемый им указатель корректно выравнен для любого built-in type на целевой архитектуре. Это не проблема.
Ryppka
Это-то да, но добавьте __attribute__((aligned(16)) — и упс(
KanuTaH
Если вы любите всякие искусственные выравнивания на 16 байт в куче, то просто не используйте malloc. Используйте aligned_alloc и иже с ним. Но обычно все-таки этого не требуется, а требуется просто не трапнуться при доступе к int/long по невыравненному указателю. malloc с этим справляется искаропки.
Ryppka
Я прекрасно понимаю, что код conformant. И работает практически всегда. Но даже в подобном коде можно легко спрятать ошибку.
vedenin1980
Стоимость разработчиков, время разработки и отладки. Если бизнесу нужен некоторый продукт определенного качества, ему будет непонятно за что платить цену в несколько раз выше. Понятно, что если без максимальной производительности в этом продукте никуда, то цена в 2-3 раза больше обоснована, если продукт одинаковый, то возьмут более «дешевый» и «быстрый» язык. Все что угодно можно сделать и на ассемблере, просто сильно дороже.
saterenko
Вот статья по зарплатам разработчиков за 2018 год habr.com/ru/company/moikrug/blog/420391. Средняя зарплата Go-ика 130К, C-ика 100К, Rust- нет, но подозреваю, что их зарплаты будут ближе к 130К, чем к 100К. Как видно, другие языки, указанные в статье, не решают проблему стоимости. Более того, средняя зарплата Python-ниста 100К, как у сишника, а PHP-ика 90К, на 10% меньше чем в сишника… В 2-3 раза — это зарплата в 30-50К, в приведённой статье нет таких зарплат.
Время разработки и отладки зависит от архитектуры и бизнес-логики. REST API проще написать на Go, не в 2-3 раза, но проще. Что-то более-менее сложное потребует сопоставимых усилий… У нас в компании есть два похожих, сопоставимых по сложности проекта, я пишу на плюсах, коллега на Go, скорости решения задач сопоставимы.
Интерфейсы и некритичные по скорости скрипты, кстати, я пишу на PHP. Простые скрипты, типа пойди в ClickHouse, получи данные, агрегируй их и положи в MySQL, думаю, можно написать в 2-3 раза быстрее чем на плюсах. Но если логика становится сложной, этот выигрыш сходит на нет, большая часть времени уходит на написание и отладку логики… Для меня плюс PHP в том, что я могу за 10 секунд вставить var_dump в любое место скрипта и посмотреть результат, в плюсами это займёт больше времени, надо компилировать код.
DaylightIsBurning
saterenko
«Возможно» — это не в 2-3 раза, как писал vedenin1980 так ведь?
Прошу прощения, но я не знаю, что такое «прикладной проект». Может быстрее будет на пайтоне, может на плюсах, а может быстрее будет на эрланге…
gecube
Я соглашусь, что у каждого языка своя ниша и условный проект на Питоне можно заколотить как прототип БЫСТРО и ДЕШЕВО, но потом стоимость его поддержки резко взлетает в космос. Хотя можете привести пример openstack, который на Питоне чуть более, чем полностью, и вроде даже дышит… Поэтому обсуждать виртуальные "усредненные" проекты, наверное, бессмысленно. Ну, и есть некоторая когнитивная сложность.
К тому же, интересно, но по ощущениям крестовики получают больше всех. Хотя нет. Джависты (скалисты) тоже на уровне. А Сишники — о каких именно мы говорим? Их же много разных — от системщиков до ембеддеров. А еще мойкруг точно не может быть верным срезом рынка, т.к. мне достоверно известно, что "вкусные" и "интересные" вакансии распространяются только внутри профильных сообществ. Это примерно как с арендой квартир или покупкой б/у машин. Некоторые висят годами, потому что дорого и есть изъян (бабушкин ремонт, неудобное расположение и т.п.), а реально ценные предложения улетают как горячие пирожки (т.к. спрос превышает предложение).
saterenko
Моя мысль была в том, что ни один язык не обладает магией или серебрянной пулей, позволяющий существенно ускорить разработку. Скорость разработки, стоимость поддержки в большей степени зависит от разработчика, а не от языка. Я о реальной разработке, а не о REST API на Python или в машинных кодах…
Мне кажется, ещё немного и вы со мной согласитесь :)
PsyHaSTe
Конечно имеет. Например ГЦ это вполне такая серебрянная пуля. Платите прозиовдительностью, получаете продуктивность. Гц придумали уже давно. Чуть позже придумали вон те же линейные типы, где не надо жертвовать производительностью ради корректности. Получили в некотором смысле тот же гц, но без ранатйм оверхеда. Это не ускоряет разработку?
saterenko
Нет, не ускоряет.
PsyHaSTe
Тогда советую определиться в терминах, что такое "ускорение разработки". Потому что как только мы введем метрики вроде "написать тотальный рест апи (не считая боттома)" на одном языке и на другом, и замерим время, которое нам для этого понадобилось, то сразу будет видно, кто лукавит, говоря что разницы нет.
saterenko
Выше я уже выссказывал своё мнение по этому поводу и высказывал весьма пространно.
0xd34df00d
А чего не считая боттома? Дайте завтипам и проверке тотальности развернуться!
PsyHaSTe
Проблему "тут у нас оказывается null", проблему "обязать компилятор обрабатывать неуспешый вызов функции", "обязательные бесплатные проверки выхода за границы", ну и все в таком духе.
Посмотрите на CVE майкрософта про винду. Или линуса про линукс. Вот все это.
Хотя всегда можно сказать, что ни майкрософт, ни сообщество линукса писать на си не умеют.
saterenko
Я с такими проблемами не сталкивался. Но меня заинтересовали «обязательные бесплатные проверки выхода за границы», можете поделиться, как это можно сделать?
PsyHaSTe
Ну вот здесь. вкратце: https://habr.com/ru/post/460989/#comment_20433889 .
Итераторы есть во многих языках, но только в расте они не то, что бесплатные, а за счет элиминации проверок даже быстрее ручных циклов почти всегда. В тех же джавах/сишарпах приходится платить за вызов лямбды на каждый элемент цикла, компилятор там не такой умный.
saterenko
В том комментарии не указанно как именно делаются проверки выхода за границы без проверки.
PsyHaSTe
Компилятор знает, что итераторы никогда не выходят за границы, и в релизе их не проверяет, всё просто ведь.
saterenko
Это частный случай, когда условия известны на момент компиляции. Сишные компиляторы умеют оптимизировать подобное.
PsyHaSTe
Не совсем так. Вот вы написали цепочку
xs.map().order_by().then_by().filter().collect()— проверок не будет. Потому что компилятор видет, в что в любой момент времени i < n.0xd34df00d
Зависимыми типами, например.
А именно, например, функция доступа к элементу массива одним из аргументов просит доказательство того, что индекс корректен. Если вы можете статически на этапе компиляции это доказательство построить, то проверка для вас окажется бесплатной. Более того, даже если данные приходят, например, в рантайме, и статически ничего про них сказать нельзя, то проверку вы можете сделать ровно один раз, а потом таскать с собой результат этой проверки (propositions as types, proofs as terms, вот это всё).
Alexey2005
В современном мире во главу угла ставится реиспользование кода. Велосипедостроение уже лет пять как считается дурным тоном, поэтому современный ЯП должен обладать мощным набором инструментов для быстрой сборки кода из готовых кусочков.
Если функцию в 10 строк можно написать за 5 минут, то среда должна позволять так заворачивать и публиковать эту функцию, чтобы её можно было загрузить и добавить со всеми зависимостями к вашему проекту не более чем за 3 минуты, и чтобы при этом ничего не сломалось.
В случае же C на реиспользование кода уходит столько времени, что проще оказывается написать код заново, чем добавить к проекту уже готовый. Собственно, издержки добавления готового кода тут столь велики, что добавлять имеет смысл только достаточно крупные библиотеки.
В мире С в принципе не может существовать ничего подобного npm-пакетам, слишком уж трудно изолируются куски кода и слишком легко «уплыть» программе после добавления такого пакета, особенно если у него в свою очередь есть пачка зависимостей.
saterenko
Я не завидую вашему опыту в Си, да и вообще в разработке… У меня нет ни каких проблем в повторном использовании кода как сторонних библиотек, так и своих… И задачи у меня нестандартные и интересные, они не решатся подобием npm-пакетов.
gecube
npm тоже, к сожалению, не идеал. Ибо реиспользование атомарных кусочков типа leftpad приводит к dependency hell.
DSolodukhin
Вставлю свои пять копеек. По началу это действительно раздражает, кажется, что компилятор к тебе придирается, и вместо того, чтобы решать задачу, ты воюешь с придирками компилятора. Но потом, ты понимаешь, что во-первых, он прав, а во-вторых, пока ты исправляешь эти «мелкие придирки», ты фактически переделываешь архитектуру приложения на более красивую и правильную. Т.е. эти ошибки работы с памятью, по большей части из-за неправильных подходов, и чтобы их исправить, приходится их менять.
Мне в расте нравится именно это, он _заставляет_ меня думать об архитектуре моего решения.
Siemargl Автор
Это да. Но жалуются на то, что _приходится менять_ архитектуру решения под язык.
DSolodukhin
И это правильно. Иначе, как говорится, программист на фортране может написать программу на фортране на любом языке.
agalakhov
Я сначала тоже жаловался. Потом понял, что язык все-таки прав, и что архитектура, которую "не хочется менять", на самом деле была шизофренична. То, что приходится делать из-за borrow checker, намного логичнее первоначальной идеи. Независимо от языка.
scg
На моей памяти сишечку уже хоронят лет 20-ть. Кстати, создавать новый язык с целью вытеснить старый — так себе мотивация.
vedenin1980
Ну, Java и C# именно с этой мотивацией были созданы…
scg
Не уверен. С# точно задумывался как убийца Java, когда Microsoft и Sun разругались. У меня до сих пор хранится артефакт: MS Visual Java++ 1.0, как символ того, что Microsoft на первых порах поддерживал Яву, как технологию. Но потом что-то пошло не так и версии 2.0 мы не увидели.
vedenin1980
Ну Microsoft и J# пилил. Просто, как я понимаю, Microsoft сильно тянул одяло на себя и тогда очень недолюбливал Линукс как ОС, если бы не поругались кросплатформенности Java не было бы, скорее всего.
Java создавалось именно, как более просто и надежный C++, для прикладных задач бизнеса. Я еще помню эпоху прикладного энтерпрайзного C++, зарождения Java (да, я настолько древний) и жалобы программистов С++ «добавили новый код, ломается код в далеком модуле вообще никак не связанный с новым и потом неделями ищем почему.» Ошибки при работе с памятью в С++ давали очень сложно находимые артефакты, но относительно быстрого и удобного Си подобного языка не было.
scg
Оно таким стало. Но именно в те времена, когда все начиналось, Java рассматривалась и как Embedded решение, например, для управления стиральными машинами. Я, например, писал на Java апплеты для сайтов, но это тоже не взлетело. А вот Enterprise пошел очень хорошо.
vedenin1980
Почему не взлетело? Взлетело. Был момент, и на девайсами миллионами ставили, и апплеты на каждом втором сайте были. Просто со времением заменилась другими технологиями (Flash, JavaScript и т.п.).
Тогда С и С++ были главными языками чуть ли не в каждой нише, даже сервисы и сайт на них делали, Java сразу создавалась как улучшенно-упрощенная версия С++, просто никто не расчитывал, что она так взлетит, поэтому сначала искали разные узкие ниши.
gecube
Учитывая количество Легаси на си — да, его хоронить рано
Но писать в здравом уме что-то новое — не, спасибо. Иначе действительно будешь в аду и постоянно править постоянно всплывающие cve
scg
Ну, значит я не в здравом уме :) Работа с памятью в Си требует некоторой аккуратности — это правда. Но такая же аккуратность требуется и при программировании на других языках. Вам спрятали память в некоторую абстракцию на уровне языка (на мой взгляд, сильно ограничив при этом), но мест, чтобы накосячить все-равно остается предостаточно. Проблем с безопасностью меньше не становится.
gecube
Я согласен с Вами, что косяков в логике програм и на языках с управляемой памятью достаточно. Но зачем плодить возможности для создания проблем на ровном месте? В Си основная беда, что все ложится на плечи программиста, компилятор никак не страхует его.
siziyman
bevice
Вы еще забываете, что цена этой "безопасности" — вычислительные ресурсы. Вот мы и пришли к тому, что сегодня офисный пакет делает тоже самое, что и 15 лет назад, при этом потребляя в тысячи раз больше ресурсов.
Ну и имеем еще поколение разработчиков, которые даже близко не понимают, как работает компьютер. Посчитайте, сколько слоев абстракции в современном приложении, а потом, для понимания того, почему "безопасность" в кавычках умножьте на то, что все эти слои делали совершенно разные люди, с разными целями, смешивали вместе — те, кто не знает, что внутри, а верхушку писали вчерашние студенты, которые хеллоуворлд уже освоили, но тысячи страниц документации фреймворков еще не прочитали.
PsyHaSTe
Это миф
И неверное следствие.
Перефразированный сократ, 400 лет до н.э.
Насчет абстракций — не могу высказться лучше, чем товарищ 1Tiger1 https://habr.com/ru/post/442112/comments/?mobile=no#comment_19821382
Whuthering
Странное заявление, учитывая, что современные MS Office, OpenOffice/LibreOffice, Softmaker Office и WPS, точно так же написаны на C++, который в вопросе абстракций над памятью ушел не так уж и далеко от C.
eduard93
Ну хорошо, пусть будут electron приложения в качестве примера.
bevice
Еще чуть-чуть и для того, чтобы отредактировать текстовый файл потребуется десятки ядер и несколько десятков гб оперативной памяти. Зато разработчику не нужно будет вообще думать
bevice
Это 20 лет назад плюсы не далеко ушли, а сейчас на чистом stdlib никто ничего не пишет, за основу берутся фреймворки, в которых уже из коробки наверчено.
mayorovp
Простите, но в каком именно месте Rust жертвует вычислительными ресурсами в пользу безопасности?
Gorthauer87
Проверки границ в доступах к элементам массивов?
PsyHaSTe
Проверки в релизе оптимизируются же :dunno:
Чтобы сразу ответить на вопрос каким образом: в расте ручные циклы почти не используются, а есть итераторы, в частнести ExactSizeIterator, который передает длину через всю цепочку комбинаторов. Так вот, у них никаких проверок границ нет, и вся безопасность дается бесплатно.
Gorthauer87
С итераторами разумеется, но как оптимизировать произвольный доступ?
PsyHaSTe
Тоже можно, если доказать.
Но обычно не нужно. Я не помню, когда последний раз писал for, всегда комбинаторы над всей коллекцией.
mayorovp
Динамическое программирование вы тоже будете через итераторы делать?
PsyHaSTe
Динамическое программирование отлично работает индуктивно, а значит и на итераторах.
Не говоря про то, что мне после окончания универа например ни разу не пришлось писать что-то подобное. Среднестатистическая задача требует взять колелкцию, посортировать, погруппировать, и выдать результат. В редких случаях в редких местах можно встретить необходимость А* сделать или что-то похожее.
scg
Никто сейчас не пишет сайты на C/C++, так? И что, взломов, утечек персональных данных, да и просто, падений не существует? Да, язык скроет криворукость программиста в одном месте, но оно тут же вылезет в другом. Утечка памяти и переполнение буферов достаточно известные проблемы, чтобы опытный программист никогда их не допускал. И если ребята из Microsoft с завидным упорством размещают входные буферы с стеке а потом удивляются, что их PRC опять взломали, так это проблемы с подбором персонала, а не с языком.
gecube
к сожалению, это не так. Либо попросту нет опытных программистов, либо все-таки в любом коде есть ошибки. И хорошо, если это не ошибки управления памятью.
(поясню, что утечки я видел даже в драйверах, которые писали вроде бы неглупые люди)
scg
Есть ошибки. И многие их делают. И вы не сможете придумать язык, который бы не позволил программисту эти ошибки не делать.
PsyHaSTe
Попробуйте в хаскеле получить ошибку многопоточной мутабельности разделенного ресурса.
siziyman
Внезапно, языки с сборщиком мусора и реализованной на уровне рантайма/языка проверкой доступа к элементам массива именно это и делают (ну да, утечки так устраняются не все, но много).
scg
Они еще и ресурсы едят. И память фрагментируют. А еще не всегда можно оперативно провести чистку мусора если памяти потребуется внезапно много. Даже статью в свое время видел о том, как эффективно управлять памятью в Яве, притом, что она вроде управляет ей сама.
siziyman
Внезапно, у всего есть недостатки, но эти языки сделали ровно то, что, как вы сказали, «вы не сможете придумать». Эти языки устранили некоторые классы ошибок целиком.
scg
Так я не это имел в виду. Я имел в виду вообще все ошибки. Если вы придумаете язык, который не позволяет делать вообще никаких ошибок то внезапно окажется, что на нем в принципе ничего нельзя сделать. Любая такая защита от ошибок это еще и ограничение.
khim
На любом языке вы сможете сделать машину Тьюринга, поверх неё C++-машину, а поверх неё — любые ошибки, какие захотите.
Потому непонятно — о чём вы, собственно, говорите вообще.
scg
Дискуссия ушла совсем в другую сторону. Понимаете, фразой про языки программирования без ошибок я агрументировал свои предыдущае высказывания, сведя некую гипотетическую ситуацию к абсурдной. Это не самостоятельное высказывание.
PsyHaSTe
Поэтому есть языки с разумными ограничениями. Почти все бекенд разработчики согласны, что ограничение "передавать можно только строку" или "только число" это хорошее ограничение, которое помогает жить.
freecoder_xx
Ну вот в Rust есть механизм отслеживания времен жизни ссылок на стадии компиляции. То есть получить висящую ссылку в принципе невозможно. Гонки данных — также невозможны, как и разыменование нулевого указателя, двойное освобождение памяти и пр. (речь про safe Rust)
Так что тут вроде как язык как раз и не позволяет программисту делать таких ошибок.
scg
Статический анализ не способен отследить перемещения ссылок для объектов которых еще не существует на момент компиляции. Вернее может, но в простых случаях. В системном программировании работа с адресами — это не тяжелое наследие архитектуры PDP (как я читал в одной статье на Хабре), а насущная необходимость. Вам нужны не просто физические адреса DMA буферов но и возможность производить над ними математические действия. Ссылки такие вещи не позволяют. Или позволяют, но с костылями.
Про гонки данных — я ничего не могу сказать. Каким образом Rust их избегает? Добавляет блоки на все глобальные переменные или как-то анализирует создание потоков и какие из них совместно с потоками используются?
А вот с нулевыми указателями, двойными освобождениями и прочая — вопрос предельно простой. Дело в том, что это не проблема парадигмы программирования. Просто в какой-то момент у вас в программе появляются не те данные. Вы либо, не туда записали. Или туда, но не то. Либо, ошиблись в вычислении индекса и прочитали не оттуда. Те же самые ошибки у вас будут и в любом другом языке. И вместо SIGFAULT вы получите некорректный результат.
inv2004
doc.rust-lang.org/nomicon/races.html
scg
Прям жирным шрифтом выделено: However Rust does not prevent general race conditions. Я не разбираюсь в синтаксисе Rust'а, но очень похоже на то, что вы должны явно указать на операцию, которая будет атомарной.
BlessMaster
Гонки бывают разные.
Гонки данных — лишь частный случай.
Rust не может исключить те же dead-lock'и на мьютексах, например. Но Rust не позволит просто так взять и забыть освободить мьютекс. И Rust не позволит иметь ссылку на данные, защищённые мьютексом, после его освобождения.
Ryppka
Rust вроде запрещает гонки данных при обращении через ссылки: правила заимствования не дают. Т.е. по сути запрещен мутабельный алиасинг. Предотвращение гонок между потоками только за счет типов аргументов: библиотеки написаны так, что ссылки, уходящие в другой поток, должны быть потоко-безопасны.
Как я понимаю, можно извратиться и обойти, но зачем?
BlessMaster
Некорректный результат мы получим там, где ошиблись, а не в произвольном месте программы. Вообще никто не обещает, что будет SEGFAULT, а не некорректные значения в месте, где в программе нет ошибок. Получить SEGFAULT, а не мусор в работе корректно алгоритма очень далеко от причины этого мусора — это в каком-то смысле даже удача.
scg
Результат обычно получают в конце, на то он и результат. То что он некорректный вы еще можете и не обнаружить сразу, так как проявится он в продакшене и при особых условиях. И вам все-равно придется искать место, которое к нему приводит. Так же как и мне. И отладка будет нисколько не проще.
BlessMaster
Нет, результат — можно отследить как он был вычислен.
UB, приведшее к невидимой поломке кода, не проявляющейся в отладочной сборке — сильно сложнее обнаружить.
scg
Это неправда. У вас flow программы может иметь миллион итераций. Сбой произойдет на 800000-й. Отладчик вам не поможет: условный breakpoint сильно замедляет работу. Остаются только логи. Но добавление лога только в одном месте дает вам миллион строчек. А ведь это место еще нужно найти.
BlessMaster
Ок, не все ошибки легко ловимы.
Но мы сравниваем "при прочих равных", когда ошибка в конкретном месте, которое можно разными способами дебажить и тестировать, и когда ошибка возникает в таком же месте, но по каким-то стихийным причинам и при определённом схождении звёзд, которые вы будете в этом месте искать до того момента, как поймёте, что ошибки на самом деле здесь нет.
scg
Я довольно часто занимаюсь поиском подобных багов. Так вот, ситуации, когда портится стек случаются крайне редко. В 99,9% случаев достаточно посмотреть через gdb на чем свалилась программа, чтобы достаточно быстро определить проблему. Так что не все так страшно. А утечек памяти мне вообще ни разу не приходилось отлавливать.
gecube
а я впиливался, в такое, например
https://bugzilla.redhat.com/show_bug.cgi?id=560650
https://www.fclose.com/linux-kernels/53048/scsi-megaraid_sas-fix-memory-leak-if-sgl-has-zero-length-entries-linux-3-10-4/
BlessMaster
Статический анализ при наличии соответствующих деклараций может гарантировать исключительность ссылок или их иммутабельность. Там, где он не может гарантировать — Вы не сможете использовать бесплатный механизм заимствования в таком виде, и Вам придётся использовать "платные" механизмы доступа/синхронизации в runtime. Цена "платных" механизмов тоже может существенно различаться и у программиста есть выбор. Но это совершенно не значит, что, если в каком-то месте пришлось задействовать runtime, то его придётся использовать везде, как в языках с GC. Механизм заимствований продолжает приносить пользу для всего кода между обращениями к runtime-механизмам.
На самом деле это действительно мощный инструмент, использующий систему типов для исключения большого класса ошибок, которые достаточно трудоёмко отлаживать.
Whuthering
А еще вы упомянули про взломы интернет-ресурсов, но забыли отметить, что наиболее шумное и массовое событие из этой области за последнее время было связано, внезапно, с heartbleed в реализации библиотеки написанной на Си :)
Ryppka
Хм, а я думал, что heartblead наполовину хайп, как проблема 2000 года. Принципиально лечится.
А вот аппаратные дыры из-за спекулятивного выполнения…
mayorovp
Лечится-то оно лечится, но вылечить вовремя не успели. В отличии от проблемы 2000 года.
Ryppka
И..? Мир рухнул?
gecube
Мы этого пока не знаем, т.к. находимся в одной из альтернативных реальностей, в которой возможно, что мир и не рухнул )
gotozero
Вы так смело пишите «криворукие программисты». Аж диву даешься. Вам 15 лет? Как можно быть настолько уверенным в собственной непогрешимости.
Люди делали, делают и будут делать ошибки.
Я вас лично конечно не знаю, но знаю очень крутых ребят. И даже они очень сильно временами косячат.
Конечно если у вас 200 строк кода на Си может это не страшно, но это смешно такое такое читать, когда накоплена такая огромная статистика.
Это все-равно что сейчас заявить: «что я не пристегиваюсь ремнем безопасности, потому что я аккуратно вожу. А вокруг криворукие водители.»
scg
Нет, а вам?
Вы простите, за контектсом беседы следили или среагировали на ключевое слово «криворукие» и поспешили оставить свой гневный коментарий?
PsyHaSTe
Почему вам не хочется писать на языке, который иногда в наивной версии выдает производительность лучше, чем у си, и при этом решает весь класс ваших проблем?
Основной плюс у того же раста в том, что вы сколь угодно сложный и опасный код на указателях можете спрятать за фасад, наружу выставить простой и понятный интерфейс, который никогда не сломается, и в случае каких-либо изотерических проблем смотреть придется 15 строчек кода помеченных
unsafe, а не весь проект.Опасности при работе с системными ресурсами эмбедом на самом деле намного меньше, чем некоторые думают. Просто почему-то люди решили, что это норма.
gecube
Поддержу. Среда выполнения стандартного сервера куда более "дикая", чем какой-то микроконтроллер, где, во-первых, работает закрытый перечень программ, а, во-вторых, общение с МК производится по вполне конкретным декларированным интерфейсам, а не так, что кто-то может влезть сбоку-припеку в Вашу программу.
Ryppka
Да вы прямо в условиях дикого запада программируете…
vics001
C не похоронят, а С++ могут. C++ могут через С ABI и новые модули написать уже на чем угодно…
А если учесть, что С наконец-то начал развиваться и туда подвезут простых и полезных фишек.
Ryppka
Да что-то не слишком. С расширениями, столь необходимыми для встраиваемых систем (и не только) уже сколько тянут…
Victor_D
По моему субъективному мнению, вряд ли кто-то в ближайшее время сможет заменить С, поскольку у всех вышеперечисленных языков пока недостаточно фундаментальных преимуществ, чтобы оправдать стоимость замены.
amarao
Можно посмотреть на ваш код на расте? Или каким образом вы определяете наличие или отсутствие фундаментальных преимуществ языка?
lorc
Чистый С сейчас имеет смысл использовать только в системных штуках. Там, где нет места GC, там где программисту нужно делать небезопасные операции с памятью, там, где часто отсутствует стандартная библиотека. В таких задачах С заменить нечем.
Во случая прикладного софта есть замена лучше — начиная от С++ и заканчивая каким-нибудь Elm.
И да, раздражает что автор поста путает C и C++. Ну да, у них похожий синтаксис. Но это два разных языка с совершенном разными плюсами и минусами.
Free_ze
Автор оригинального поста — это Александреску, на минуточку) И в посте он четко разграничивает С и С++:
Таких задач и областей исчезающе мало на фоне того, где сейчас используется си (и может быть заменен).
lorc
Ага, а потом пишет в плюсы D то, что он компилируется быстрее С++. Хотя, сравнивать стоило бы все же с С.
И вообще, судя по
Автор таки не видит большой разницы, если предлагает заменить их скопом. Ну это как если бы я писал статью о языке-убийце R и Erlang. Какая вообще связь между ними?
Может у меня профдеформация, конечно. Просто я работаю в embedded. Тут периодически возникают новые проекты на C. А что, в прикладных задачах тоже появляется новый софт написанный на чистом С?
Я сейчас специально говорю про новые проекты, а не про legacy, ибо там все понятно — на чем писали, то и поддерживаем. Хотя, тот же гугл сделал усилие и перевел кучу своих android HAL с С на С++.
Free_ze
С++ он нарёк приемником С, у которого синтаксис и семантика явно богаче, а идеология наиболее близкая. Хотя он мог бы написать это в преимущества D, но предпочел привлечь к более честному сравнению С++.
Ну, навскидку: OpenCV, Nginx, Blender. У меня сложилось впечатление, что в прикладном софте, связанном с вычислениями, C и C++ идут очень близко по популярности.
ЗЫ Но я согласен, что заголовок желтоват, в статье есть свои условности.
lorc
OpenCV уже 13 лет. Nginx — 15 лет, Blender — вообще старожил. Ему 21 год. Я же спрашивал про новый софт. Ну хотя бы за последних 5 лет?
Free_ze
C++ — 36 лет, какая же разница? По статистике того же гитхаба они болтаются на уровне погрешности.
lorc
Разговор был о том, что C — сейчас язык для очень узкой ниши — системного программирования и embedded. Но в этом узкой нише его заменить и нечем. Ни один из трех языков описанных в этом посте для этого совершенно не подходит.
В качестве подтверждения своим словам я привел тот факт, что новых прикладных программ на С больше не пишут.
Поэтому я не понимаю при чем тут ваше замечание о том, что С++ исполнилось 36 лет.
Free_ze
Разговор был о том, что автор совершенно неправ в своих суждениях.
Почему вдруг? Многие системные задачи вполне решаются на том же C++.
Сильное заявление. Например.
Язык, очевидно, старше, чем все названные приложения. Тем более, был на волне популярности в момент их создания. Более того, некоторые из них частично написаны на C++, но лишь частично.
Поэтому я не понимаю вашего сопротивления, мистер Андерсон.
lorc
Без исключений (а значит и без STL) это получается какое-то подмножество С++. Типа «С с классами». Хотя, гугль именно на таком и пишет и им вроде нормально…
Сильное заявление.Ну вы сами посмотрите на эти проекты. Там кроме tynissh нет ничего живого и/или стоящего.
Ладно, я скажу по другому — в прикладных проектах заменять С не нужно, потому что его там уже и так заменили. В системном программировании его заменить трудно и/или невозможно. Хотя да, эксперименты типа той же google fuschia или ms singularity есть.
Free_ze
С++ — это язык с широкими возможностями, это нормально, что кто-то не пользуется исключениями, кто-то — шаблонами и т.п. Но RAII никуда от этого не пропадает, а это, кмк, его киллер-фича.
По поводу последней — это уж совсем странно, но почему бы и не Rust? Mozilla постепенно пересаживает FF на него, а браузеры — чем не системное программирование?)
lorc
Системное программирование — это скорее «написать драйвер сетевой карты» при чем с нюансами вроде «порядок записи в регистры имеет значение, хотя компилятор и не видит разницы» или «работать, принимая во внимание что часть кода прямо сейчас не находится в памяти» или «прочитать значение из этой ячейки памяти один и только один раз».
Браузер — это прикладной код.
Free_ze
Зависит от точки зрения на абстракции. Под ним ведь исполняются программы на JS, плагины и прочая клиентская светотень — прикладные программы для браузера.
lorc
Ну браузер я могу написать хоть на Java. А вот realtime OS с поддержкой SMP — не могу.
Free_ze
Эти вещи не являются определяющими для системного программирования.
0xd34df00d
Почему без STL? Кто мешает пользоваться алгоритмами (всякие там
std::find_if,std::any_of), вещами типаstd::invokeи трейтами, скажем?А ещё с констекспрами, темплейтами и прочими ништяками.
Ryppka
С frestanding C++ пока не все хорошо, к сожалению.
0xd34df00d
В каком смысле? Ничего из вышеперечисленного вообще не опирается на поддержку рантайма.
rogoz
В en.cppreference.com/w/cpp/freestanding (вроде инфа там на основе стандарта) нет <algorithm> (std::find_if, std::any_of) и <functional> (std::invoke). Значит опирается на поддержку рантайма и в freestanding работать не будет. Вот <type_traits> есть, да.
0xd34df00d
Нет, значит, не описываются эти хедеры. В упомянутых вами (и мной) вещах просто нет ничего, что требовало бы поддержки рантайма (и что мешало бы мне взять, например, crossdev и собрать тулчейн для сборки плюсокода под какой-нибудь attiny со всеми
find_if,max_elementиinvoke).Приводить freestanding в качестве обоснования того, какой код можно писать без экзепшонов — странно как-то.
Ryppka
Вы пробовали компилировать с отключенными исключениями?
0xd34df00d
Да. Конкретно под аттини я собирался с
-fno-rtti -fno-exceptionsили чем-то подобным.Ryppka
И всем-всем перечисленным пользовались?
0xd34df00d
Всего-всего ещё тогда не было, но вот
find_ifи каким-нибудьlower_boundилиinner_product— да.Посмотрите, что делает
max_elementилиinvoke. Чему там требовать исключения?Ryppka
Ну, я это не на пустом месте взял.
В CppCast было интервью как раз по этому поводу. Давно было и лень искать, кто говорил. Но там достаточно аргументированно описывались проблемы сделать algorithm и некоторые другие куски библиотеки пригодными для freestanding. Кстати, большинство ограничений назывались искусственными и надуманными.
Так что Вам повезло.
0xd34df00d
Фиг знает. Я открыл algorithm и не увидел сходу никаких проблем сделать этак 95% этого доступным во freestanding.
Мне было бы интересно услышать их аргументы, почему там могут возникнуть какие-то проблемы.
rogoz
Ну так считают не только вы: www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0829r4.html
Но это c++20 или с++23, если прокатит. В c++17 freestanding по стандарту как в ссылке, что я кидал. Кстати, -ffreestanding отдельная опция и она не зависима от -fno-rtti -fno-exceptions. Если вы собирали только с -fno-rtti -fno-exceptions, значит там была достаточно полная реализация стандартной библиотеки.
Ryppka
Дык поищите на cppcast.com, там содержание выпусков описано, наверное можно текстовым поиском по freestanding. ) Ну или что Вам стоит на TMP со SFINAE поисковую программу накидать?))
khim
Вроде как бы о новых проектах речь шла, разве нет?
Что не мешало иметься определённому проценту «тупонечников», заявлявших, что C++ — это от лукавого. И как раз примерно лет 10 назал начался постепенный переход на C++ (GCC перешёл в 2012м, что, в общем, стало началом конца этой эпохи).
Free_ze
Забавно, репозиторий датирован концом 2015го. ОК, возможно, пример неудачный. Но наверняка что-то, да найдется.
khim
Что-нибудь, конечно, найдётся. Вопрос в количестве.
freecoder_xx
Rust почему не подходит?
khim
Ну например потому, что там до сих пор нет возможности банально сделать ассемблерную вставку. И нет возможности обращаться к строктурам из ассемблерных файлов напрямую, так как их формат — не фиксирован…
Какое, нафиг, системное программирование и embedded в таких раскаладах?
А так-то да, в перспективе — всё возможно.
freecoder_xx
#[repr(C)]— это не решает?khim
Слишком много костылей. Если вы посмотрите на низкоуровневый код на C/C++, то обнаружите, что архитектурно-зависимого кода там крохи.
То есть «на спор» на rust можно писать низкоуровневый код — но это дико неудобно.
PsyHaSTe
В чем неудобство-то? Нужно один атрибут на структуры повесить? Не говоря про то, что сама проблема надумана. Все равно что сказать "джава плохой язык, потому что в отличие от С++ нельзя унаследоваться от двух классов", или "Хачкель плохой язык, там переменные иммутабельные, что вообще можно полезного сделать с одними константами?" и так далее.
khim
in/outсделать.mayorovp
И как же это в других языках решается?
freecoder_xx
Ну, ночные сборки Rust все-таки что-то могут в
asm.khim
Вы всерьёз собираетесь базировать что-то серьёзное на ночных сборках?
Они уже лет 5, наверное, обсуждают — стоит ли стабилизировать то, что в ночных сборках или выкинуть всё и сделать как-то совсем по другому.
lorc
Rust наверное подходит лучше всего. Или не подходит меньше всего. Правда, половина кода будет с пометкой unsafe…
BlessMaster
Это далеко не так. Большая часть кода вполне хорошо себя чувствует в безопасном подмножестве.
Unsafes in Redox
PsyHaSTe
Я как-то замерял, вся стандартная библиотека содержит несколько десятков
unsafe. Вся! То есть вся работа с файлами/сокетами/вот этим всем, на всех поддерживаемых таргетов это жалкая горстка ансейфов. Как по мне, это успех.inv2004
Потому, что ещё недавно нельзя было неуспешную аллокацию обработать.
PsyHaSTe
Но сейчас-то можно? Причем уже больше года емнип.
inv2004
Да что уж там, надо было написать что больше 100 лет.
Open: github.com/rust-lang/rust/issues/48043,
и то просто в коллекции вставили где нашли, т.е. что какая-то библиотека это прокинет — околонулевые.
PsyHaSTe
По каким критериям? Я помню писал на том же расте код без аллокаций и стандартной библиотеки, bare metal так сказать.
ErmIg
OpenCv написан практически полностью на С++. От С там остался легаси API от OpenCV-1.0.
Free_ze
Да, вы правы, всего 5%, если верить метрикам гитхаба.
PsyHaSTe
opencv с сишки давно переписали. Я вот хотел в раст завести, однако C API полностью задеприкейчино, и мне пришлось врапперы ручками писать. Не очень похоже не чистое си. Про остальное не скажу, но подозреваю что там похожая история.
Free_ze
habr.com/en/post/460989/#comment_20433077
darkAlert
я и гитхаб утверждаем что он написан на С++. На Си перестали писать с opencv2 (а уже 4 версия)
Free_ze
habr.com/en/post/460989/#comment_20433077
vintage
А собственно D чем не подходит?
math_coder
Он не присособлен к существованию без GC. То есть писать без GC на нём можно, но неприятно и неудобно.
vintage
То есть C вообще без стандартной библиотеки вам использовать норм, а D без части стандартной библиотеки, зависящей от GC, — нет?
math_coder
Да, потому что это разные языки, и что для C — "норм", то для D — неприятность и неудобство.
vintage
Вы либо крестик снимите, либо трусы наденьте.
khim
Посмотреть код на rust нельзя… и именно это и является центральной проблемой.
Очень мало вещей сегодня создаются с нуля — а без этого очень тяжело заменить C.
Когда и как взлетел C? Когда люди перешли со всякиз Multics'ов и OS/360 на Unix.
Где C был изначально и на нём было написано вообще всё.
И то же самое — случилось при переходе с DOS на Windows.
Сейчас — такого перехода не предвидится. Шансы у какого-либо языка могут появиться если какую-либо нишу этот язык займёт изначально… но туда никто как раз не копает.
Какая-нибудь Fuchsia по-прежнему написана не на Rust или D, но на C/C++. Так что если даже она, вдруг, взлетит — никакого перехода на Go или Dart не будет.
epishman
До выхода фуксии может не дожить сам дарт…
freecoder_xx
А кто запрещает? Я вот постоянно читаю исходники библиотек на Rust )
PsyHaSTe
Хм, а все ли так просто?..
KanuTaH
Ну да, у Фуксии есть SDK для Rust. Но берем например ядро фуксии — zircon:
Ой. А как насчет C/C++?
Вот как-то так.
vdonich
Да ладно… Достаточно много кода на Rust в Фуксии.
KanuTaH
:) 5025 файлов .rs, из них 3777 — в third_party/rust_crates (банальная support library для поддержки штанов раста), остальное — в основном в рамках SDK (Fuchsia SDK имеет и Rust-интерфейс, в числе прочих). Основная масса фуксии написана на C и C++, в цирконе так и вообще ни строчки на расте нет.
vdonich
За что минус, неясно.
Во-первых, её еще пишут. А во-вторых, Циркон — не вся Фуксия.
С тем же успехом можно утверждать, что Фуксия написана на Дарте и рассуждать о его успехах над Rust и Go.
KanuTaH
Ну вот ваш комментарий как раз и выглядит примерно как подобное утверждение. «Есть SDK-интерфейс к Rust» != «написан на Rust».
vdonich
«Достаточно много кода на Rust» ? «написан на Rust». Первое я сказал и придерживаюсь, второго я не говорил и в общем-то не согласен.
Я лишь возразил на категоричное утверждение, что «Fuchsia написана на C/C++», что имхо не совсем корректно.
khim
Скажем во многих дистрибутивах Linux есть куча кода на Python и Vala, но сказать, что они написаны на Python или Vala нельзя ибо это всё — необязательные компоненты.
А вот без C (и, в более новых версиях, C++) — вы не обойдётесь.
WRP
И плюсом насколько проще выучить С и начать с ним работать.
Несопоставимо с D.
PsyHaSTe
И насколько? Чтобы сегфолтов ни одного в программе не было, уб там...
LazyTalent
работает — не трогай
evocatus
Каждый из трёх достоин заменить C/C++ в своей сфере. Go был бы хорош для всяких сетевых вещей и простых утилит (типа GNU); D, кажется, больше всего подходит для замены C++; Rust уже создал себе репутацию языка, подходящего для критичных к корректности и информационной безопасности задач.
Но!
Если все 3 языка будут делить пирог уходящего C, то мы потеряем одно очень важное преимущество C, о котором почему-то в статье не упомянуто:
C — это lingua franca. Его знают очень очень много людей, компиляторы есть по все мыслимые и немыслимые платформы, и т.д.
worldmind
) вы употребили сочетание lingua franca не задумавшись что теперь уже не язык франков является lingua franca для мира, всё меняется.
IkaR49
Тот же rust сидит на llvm, так что он уже много где собирается и исполняется. Про Go и D ничего не скажу, ибо не знаю.
dbelka
Go тоже сидит на llvm, насколько я помню, как и swift.
khim
Swift — да, Go — нет. У него всё своё. Есть версия поверх GCC, но ей мало кто пользуется.
NeoCode
Для D есть версия на своем бэкэнде (основная), есть gcc и есть llvm.
androidovshchik
По-моему, это не аргумент. Поколения программистов меняются, хоть и медленно. Думаю это вопрос времени
PsyHaSTe
Иметь инструмент под задачу всегда лучше, чем пытаться пилить дерево и стричь волосы одной и той же бензопилой.
DaylightIsBurning
Далее говорит Кэп:
Не всё так просто. Баланс между универсальностью и специализацией инструментов — дело тонкое.
Распространённые (но не обязательные) недостатки специализированных инструментов: необходимость их изучать, необходимость создавать для них отдельную инфраструктуру, сложность интеграции с внешней по отношению к ним средой.
В этом контексте у универсальных систем есть один (но большой) потенциальный недостаток: сабоптимальность выполнения специализированных задач. При этом компромиссы между этими недостатками в реальных инструментах нелинейны. Хороший универсальный инструмент вполне может очень мало жертвовать (или совсем не жертвовать) удобством в широком перечне специализированных задач и при этом не обладать недостатками специализированных инструментов. А хороший специализированный инструмент может быть легок для изучения и пригоден для интеграции. Очевидным способом скрестить ужа с ежом являются Domain-specific language extensions типа LINQ или просто библиотек для линейной алгебры под C++. Таким образом можно дополнить универсальный язык для удобного применения в узкоспециализированных задачах и в значительной мере сохранить преимущества универсальности.
dbelka
Вот уж действительно, внезапно.
Сколько проблем с безопасностью было из-за этого, сколько эпичных фейлов.
Тут уже упоминали статью из блога Microsoft, в которой говориться:
Даже если это редко является проблемой, то сама проблема может иметь очень большие масштабы.
Так себе проблема, конечно :-/
DaylightIsBurning
Эти большие масштабы появляются почти исключительно тогда, когда программа используется в огромных масштабах, типа openssl или веб-сервис какого-то из гигантов-триллионников. Огромное количество программ создается для узкого применения в изолированных средах, где безопасность обеспечивается механизмом неуловимого Джо. Вероятно, такого Джо-кода намного больше чем того, что чувствителен к уязвимостям.
freecoder_xx
В перспективе Rust имеет шанс заменить собой Java и съесть львиную долю "пирога" C и C++.
alan008
А причём тут Java? C, Rust и Go — языки системного программирования, а Java — прикладного.
freecoder_xx
Просто делюсь опытом и своими наблюдениями. Rust лезет в нишу Java, хотя никто его туда не позиционирует сознательно. Это само так происходит. Потому что в большой прикладной системе становится важна безопасность и производительность. А также жесткий контроль типов, который осуществляет компилятор. И даже то, что в крайнем случае можно написать небольшой
unsafe-участок кода в критическом месте.siziyman
Где и в какую нишу Java он лезет? Можно не штучные примеры, а вот так, чтобы прям тренд был виден?
freecoder_xx
В промышленное веб-программирование. Естественно, большего, чем единичные примеры, я вам предоставить не смогу. У меня есть только "мой личный тренд", то что я вижу и с чем работаю со своей колокольни. Если бы был кем-то зафиксированный документально тренд, то это было бы уже не предположение, а свершившийся факт.
siziyman
Ну в единичных случаях туда и Си с плюсами лезут, про тренды я бы не говорил, исходя из этого.
Ну и да, тренд «его становится больше» ни в коем разе не значил бы «оно вытеснит Java» как свершившийся факт, конечно же.
freecoder_xx
"Иммеет шанс" было написано в исходном сообщении )
alan008
Может тогда вы о Java Script говорите, а не о Java? В Java жесткая типизация как раз (в отличие от Java Script).
freecoder_xx
Именно про Java. В ней не достаточно "жесткая" типизация: любая переменная может иметь своим значением как объект определенного класса, так и объект типа null, например.
vedenin1980
Тем кому это важно, на замен возьмут котлин или скалу. Прозводительность именно языка в веб-приложениях редко критична, вы скорее упретесь в сеть, базу данных, кол-во портов и соединений и т.п. Получается он сможет заменить достаточно небольшой класс приложений, где именно требуется максимальная производительность.
BlessMaster
Тут палка о двух концах. Сначала язык даёт возможность, которую иногда куда-то применяют, но не зная зачем она в большинстве случаев, потому что до этого самой возможности не было, не сложилось практики. Потом народ изучает, как эту возможность использовать во благо монетизации и с этого момента она становится исключительно востребованной, и без неё никуда.
Маленький лайфхак: с быстрым клиентом из базы данных можно выжать гараздо больше. Некорректно говорить, что всё упирается в базу данных, если всё упирается в дорогие локи из-за неоправданно долго живущих транзакций.
vedenin1980
А вы реально считали чем вызываны локи? Что-то у меня есть подозрение, что скорость передачи запроса по сети до базы и обратно будет на порядки выше, чем скорость выполнения кода на почти любом языке программирования (ну если код написан правильно), не говоря уже о возможности перенести бизнес логику критичных транзакций на сам сервер в виде хранимых процедур. Вот из-за ошибки в работе с базой данных можно потерять намного-намного больше времени.
BlessMaster
Время работы скрипта между несколькими запросами — порядка десятков миллисекунд (спасибо высокоуровневым ORM решающим уйму вопросов небесплатными абстракциями "просто для удобства").
Время работы скомпилированного кода на Rust с теми же запросами — порядка нескольких миллисекунд.
Этой разницы на порядок в скорости завершения транзакций достаточно, чтобы базе вообще нужно было гораздо меньше вовлекать механизм блокировок.
Хранимые процедуры — да, полезный компромис, но он сложнее в поддержке и имеет немало ограничений. Сам встроенный язык хранимых процедур — не так богат по возможностям. Если приходится думать о таких оптимизациях, база — уже бутылочное горлышко, и нагружать её исполнением интерпретируемого кода — не всегда подходящее решение. Если же это компилируемый код — мы вернулись к выгодам от компилируемого эффективного языка в среднем звене (клиент базы) и как следствие коротких транзакций, в противовес сложности обновления и поддержки хранимых процедур в самой базе и проблеме бутылочного горлышка.
Я не буду спорить с тем, что в предложенном Вами подходе есть рациональное зерно и я сам бы так поступал во многих случаях. Но это скорее вопрос целесообразности и обстоятельств в каждом конкретном случае.
Ошибку, всё-же, можно обнаружить и исправить. Скорость же работы клиента — это скорее фундаментальное ограничение, исправить которое будет очень дорого.
vedenin1980
Так кто же вас заставляет использовать ORM? Ну вот насколько будет отличаться время скомпилированного кода на Java с теми же запросами (select/update) прямо один в один как в Rust'e? Или в Rust'e есть какая-то магия (за счет чего)?
Ни в одном языке, насколько я знаю, использование ORM жестко не зашито на уровень базового синтаксиса, достаточно просто не использовать ORM в критических случаях (практически любая ORM позволяет просто взять и написать обычные select'ы и uodate'ы). Это не фундаментальное ограничение, фундаментальное ограничение это насколько абсолютно одинаковый код на Rust быстрее точно такого же кода на условной Java. B скорее всего разница будет вообще не заметной на фоне потерь на сетевые соединения с базой данных.
freecoder_xx
Разница будет. Я как-то делал замеры простых алгоритмов, и Rust был у меня в 4 раза быстрее Java.
PsyHaSTe
Парадок блаба он такой. Программист всегда думает на блабе, и блаба для его задач всегда хватает, и языки с б0льшей выразительностью он воспринимает как "странные", потому что и на его можно написать любую программу.
vedenin1980
Скоре люди ленивы. Если программист всю жизнь писал на блаба, он, если будет вынужден поменять язык, с большой вероятностью выберет макисмально похожий на блаба в той же экосистеме, чтобы минимально переучиваться. Бизнес тоже не любит резких поворотов и выкидывания старого кода и полной замены разработчиков. Поэтому у JVM языка значительно больше шансов заменить Java.
snuk182
Java — особый случай. Она достала многих ее поклонников своей дикой консервативностью, пока соседние языки радовались появлению то замыканий, то кортежей, то еще разным вкусняшкам. Можно сказать, в непростое время конца двухтысячных ей очень повезло выжить во время языкового взрыва, чисто благодаря сотням финтех- и энтерпрайз-легаси, которые в свое время рождались чуть ли не с физической болью.
vedenin1980
Это не только баг, но и фича. Бизнес сам по себе дико консервативен и ему консервативность Java очень зашла (увереность, что и в следующей мажорной версии языка будет собираться та двадцатилетняя древняя система, которую уже никто толком не понимает, — стоит дорого).
snuk182
Ну это только в теории. На практике бизнес сидит до сих пор на версии лохматого года, под которую был изначально написан, потому что фреймворки активно используют недокументированные или специфические фичи, которые в следующих версиях оказываются выпилены, переделаны, задепрекейчены, и так далее.
vedenin1980
На практике я видел переходы очень древних систем бизнеса с почти миллиардными оборотами (в долларах) последовательно с первых версий Java до Java 8.
В случае Java enterprise фреймворки обычно очень трепетно относятся к обратной совместимости. Не всегда это спасает, но кол-во переделок под новые версии относительно невелико. ИМХО.
snuk182
Когда очень прижмет. Например, не удается набрать народ, после фразы "у нас четвертая джава и глассфиш", и чуваки внезапно понимают.
vedenin1980
Да, потому что
zenkov
Никакой. Когда Си начнёт сдавать позиции просто отпадёт надобность и в нём самом и в его заменах.
freecoder_xx
Как мне кажется, Rust делает неплохую попутку стать языком общего назначения: и для системных вещей, и для достаточно высокоуровневых прикладных. Правда, тут есть опасность ни там ни там в итоге не закрепиться, но интересна сама тенденция (она, думаю, есть, иначе не лезли бы всякие Python в embedded).
То есть борьба идет не за место языка C, а за место основного языка общего назначения, КМК.
PsyHaSTe
Если си начнет сдавать позиции без замены, это будет означать, что софт ломается, но на новое его не переписывают. Похоже на крах цивилизации, в общем.
iago
Странно видеть плюс
в статье про замену С/C++.
NeoCode
Тут многое можно написать… на целую статью)
Но если кратко, то Rust кажется очень сложным и с кривоватым синтаксисом (как-то вот тяжело воспринимается код, не знаю почему). Go — простой, красивый, но кажется что слишком мало языковых концепций (нет метапрограмминга, исключений...). D создавался как замена С++, сам язык интересный, но кажется что под конец начались те же проблемы что и у С++.
Что меня неприятно удивило в D, так это то что там нет namespace. Модульность, основанная на файловой системе, мне очень не нравится.
siziyman
Синтаксис, если это не брейнфак — не беда.
Метапрограммирование в системном языке — очень хороший способ стрелять себе в ноги и скорее костыль, который встроили в архитектуру, чем что-то хорошее. Но Го — погано задизайненный для конца нулевых язык, да.
NeoCode
Метапрограммирование как в С++ — да. А если его сделать грамотно, с полной поддержкой со стороны среды разработки — то нет. Грамотно ИМХО пока никто не сделал.
Вообще же любое программирование это в каком-то смысле «мета», если только это не программирование в машинных кодах:)
siziyman
Полная поддержка со стороны среды разработки потому и трудноосуществима, что это метапрограммирование.
NeoCode
Смотря какая среда разработки. Если как сейчас — то да.
А если прямо в IDE можно выделить какой-то метакод мышью и запустить на исполнение, и он тут же выполнится в отдельном окне, и по нему можно походить метаотладчиком, а с помощью REPL-подобного инструмента подать на него входные данные и тут же посмотреть результаты кодогенарации, и добавить проверку результатов метакомпиляции в автоматические тесты…
Но таких сред, насколько я знаю, пока не сушествует.
siziyman
Какой кошмар. Как хорошо, что такого нигде нет.
Вы понимаете, что такой тулинг разрабатывать будет ещё сложнее, чем сам язык? И баги в этом ещё отлавливать, брр.
И метапрограммирование на то и мета-, что вы, компилируя у себя, можете быть лишены возможности воспроизвести возможные, но только в другом окружении условия. Тут хоть заREPLайся.
NeoCode
Так и без «мета» то же самое. Я лишен возможности воспроизвести условия многочисленных пользователей моей программы. Но я могу подать на вход некоторые тестовые данные, интересные для меня — и увидеть результат, в том числе и пройти алгоритм по шагам в визуальном отладчике. Чем метапрограммирование хуже?
Да если бы сделали нормальную объектную модель кода и прикрутили бы хоть javascript, это было бы уж всяко лучше чем многоэтажные шаблоны С++ с многоэтажными же сообщениями об ошибках компиляции.
BlessMaster
Сложностью. Взрывообразным ростом сложности. Специфика IDE в том, что она, в отличие от компилятора, должна большую часть своего времени работать с некорректным кодом, как-то догадываясь, что там программист сейчас наживо пишет. При этом помогать программисту нужно с кодом до преобразования, как-то предполагая, что будет в результате преобразования при том, что точного совпадения с правилами преобразования прямо сейчас нет. И это действительно нетривиальная задача по сравнению с "поработать обозревателем преобразований в готовом корректном коде", а тем более, подсказывать исходя из проработанной модели языка, где всё на своих местах.
Собственно, для Rust сейчас эту задачу пытаются решать в IntelliJ и Ferrous Systems. Но уже очевидно, что она — не всегда (или исключительно непросто) решаема.
NeoCode
Я имею в виду не автокомплит, а особый режим «отладки метапрограмм». То есть программист спокойно пишет программу, затем что-то нажимает и происходит частичная компиляция — метапрограмма компилируется в какую-то промежуточную форму, и если эта частичная компиляция прошла успешно, то можно выполнять следующую часть — смотреть как она работает на образцах кода. Все это — отдельный режим, не имеющий отношения ни к вводу кода, ни к основной компиляции.
siziyman
И каждый раз, когда вы это делаете, вам нужно на всякий случай переиндексировать в IDE сам проект практически целиком, потому что вы не знаете, что изменилось, а что нет, и как вам надо перестраивать иерархии зависимостей, классов, вызовов…
В общем, с тем же успехом можно сделать скрипт, который gcc -E будет запускать и открывать аутпут в новом окне IDE.
BlessMaster
Не то, чтобы, совсем целиком, модульность, если она есть, спасает. Но да, малейшие изменения кодогенератора цепляют крупные куски кода. Особенно, если этот генератор генерирует другие генераторы :-)
siziyman
Модульность спасает, но кажется, что затраты на определение границ изменения (особенно если эти изменения технически затронули интерфейсы, «экспортируемые» наружу и отдаваемые в другие модули) могут быть таковы, что станет дешевле целиком юнит с ненулевым диффом проиндексировать. А потом перепроверить все его вызовы в другом коде, чтобы посмотреть, не сломалось ли что.
BlessMaster
Согласен, это более простой случай — если программа успешно собирается, то с ней уже можно как-то работать. IntelliJ строит виртуальное AST и работает с ним, в том числе, и для упомянутого автокомплита, так же как позволяет и полностью развернуть сгенерированный макросами код (без этого вообще очень многое не работало, поскольку в библиотеках Rust очень много сгенерированного кода).
Однако это пока совершенно не касается процедурных макросов. Хотя для Rust и есть практически официальный интерпретатор, который уже используется для некоторых задач в компиляторе, вроде вычисления значений константных функций. Полагаю, со временем, по мере развития, он будет более плотно использоваться.
Всё это в каком-то виде будет переиспользовано и в RLS 2.0, поскольку он в значительной мере пишется с оглядкой на опыт, получаемый с IntelliJ, но я плохо представляю, как с этим будут взаимодействовать другие IDE.
0xd34df00d
А просто не надо преобразовывать имеющийся код, достаточно уметь генерировать новый.
littorio
Я к самому инопланетному семейству языков в мире только-только начал присматриваться, могу ошибаться, но вы не поверите — таки есть (wiki: Racket). И IDE есть (DrRacket), с отладчиком макросов. Правда, оно (имхо) потому и есть, что синтаксис "стопка скобочек" предельно простой.
PsyHaSTe
Вот что-то, а синтаксис го совершенно ужасный. А уж если посмотреть на предполагаемый синтасис генериков то вообще ужас.
А у раста что? Типы через двоеточие как во всех не си-подобных языках: тайпскрипт, если берем самое мейнстримное. Генерики обозначаются как и все через угловые скобки. Ну добавляется еще генерик-параметры времени жизни, которые решили через апостроф обозначать. Ну и ладно.
В общем-то конец нововведений по сравнению с плюсами. Какие-то вещи вроде деконструкции в паттерн матчинге вроде интуитивные вещи, всё лучше, чем ифами обмазываться.
khim
На самом деле вот уж на синтаксис пенять — это последнее дело. Исходники sh'елла видели? Когда C только появился многим его синтаксис казался ужасным — даже среди разработчиков Unix!
А потом — ничего, привыкли. Сейчас даже какую-то красоту в нём находят…
snuk182
Синтаксис это ничто.
Вот когда, наигравшись, захочется решить парочку задач из жизни, уровня сложности чуть выше физзбаза, Rust нанесет свой главный удар — практически ни один из общепринятых паттернов проектирования в нем не работает, ввиду фундаментального запрета на халатное отношение к памяти. С одной стороны это порождает неожиданные конструкции типа HashMap Entry API, с другой стороны, побившись об углы, начинаешь понимать — такая многословность целиком оправдана заботой о безопасности доступа к данным. К тому же в 99% случаев все проверки происходят только при компиляции, в итоге выдавая бинарник, свободный от этого всего.
gecube
Как будто в Джава нет многословности? Многие на это жалуются, но скорее это благо.
snuk182
В Java многословность олдскульная, еще из времен, когда люди не понимали современные языковые конструкции (замыкания, дженерики, цепочки ленивых запросов к коллекциям), в итоге условный пользователь C# тратил одну строку на то, что в Java приходилось писать полотнами, но с большей вероятностью напартачить.
Alexey2005
Главная проблема C++ называется «хм, ну оно же компилируется на МОЕЙ машине!». Угу, а у всех остальных ваш код, загруженный с github'а, почему-то не хочет собираться без недели шаманства. Особенно если у них другая ОС.
Представим, что вы пишете кроссплатформенное приложение, которое надо собрать под Windows, Linux, Android и ещё неплохо бы под WebAssembly до кучи. При этом у тех, кто работает с кодом, тоже может быть любая ОС.
Проблема более-менее решается только установкой системы контейнеров, в каждом из которых развёрнуто нужное окружение. Один контейнер — один выходной бинарник. Мне одному кажется, что это ни хрена не кроссплатформенность? Если для каждой платформы всё равно приходится держать и компилировать своё окружение, свой набор библиотек, и даже значительная часть кода меняется в зависимости от платформы (все эти блоки #define/#ifdef).
С языком попросту неприятно работать, ибо непропорционально много усилий уходит на обеспечение сборки проекта.
littorio
НЯП, оно компилируется сложно не благодаря разным ОС/компиляторам (хотя не без этого, да), сколько благодаря отсутствию модулей и, соответственно, репозиториев.
Но в этой области работа ведётся. Стенания вида "дайте же нам, наконец, модули!", кстати, одни из самых частых комментариев во всех новостях о будущих версиях стандарта. Просто они с этим затянули, да (как я понимаю, отчасти благодаря конкуренции крупных компаний — драйверов развития языка). Но, думаю, допилят — уж больно спрос высок. Ну и потом, как водится, 3-5 лет на вымывание всех инклюдов из свежих версий софта.
gecube
Это комплексная проблема — это верно.
Только она не решается просто введением системы модулей. Правильно — просто отказаться от обратной совместимости и заставить все актуальные модули переписать заново (скорее всего эта работа характеризуется конечной сложностью, в отличии от поддержки костылей и всех существующих стандартов и их модификаций). Но раз так, то это не С++20+ получается, а нечто другое, на что комитет по стандартизации тупо не пойдет.
0xd34df00d
А что конкретно вы ожидаете от модулей в C++?
khim
«Протечек». Наиболее частый источник проблемы класса «а оно компилируется у меня, но ни у кого больше» — это «забытые»
includeы (впрочем забытые это ещё цветочки, вот конфликтующие — это ягодки).Модули, собственно, решают ровно эту проблему. Вот только чтобы получить от них выигрыш нужно потратить несколько лет и перейти от
includeов к модулям везде… и вот тут не факт, что с C++20 получится. Посмотрим…0xd34df00d
С вами-то это мы уже обсуждали. Мне же ещё интересна статистика и ожидания других людей.
littorio
Ну, отсутствие необходимости настраивать списки дефолтных инклюд-папок и библиотек при линковке. Идеал, наверное, что-то ява-мейвеноподобное — чтобы при сборке само все зависимости подсасывало. Это если в тему исходного комментария, "не могу легко собрать чужой проект".
Плюс ускорение компиляции, упрощение и стандартизация структуры инклюдов. А то у нас почему-то с постоянной периодичностью появляются товарищи, которые инклюдят куски кода (иногда прямо посреди класса).
0xd34df00d
Ну, даже с препроцессором сегодня можно писать (с каким-нибудь правильно написанным cmake) такие проекты, которые нормально собираются. Модули же никак не помешают делать несобирабельные вещи.
Этого не будет.
Ну, я не вижу принципиальной разницы, писать мне
#include <util/oral/types.h>или#import util.oral.types. А вы?kvghabr
Си заменит какой-нибудь «транспайллер в си и обратно» типа «v language» (но не обязательно он).
Чтоб это был си-код на выходе, причем еще до стадии бинарника (чтобы можно было легко добавить легаси), но с возможностью писать удобно/безопасно/модно/молодежно и т.п.
Gorthauer87
Типа Vala? Блин даже плюсы начиналось именно так, но С не заменили
kvghabr
Но зато плюсы взлетели, хоть в итоге и не туда. Правда плюсы — это не совсем транспайлер, а просто бинарно совместимый код. Нужен все таки транспайлер.
Но принцип-то оправдан. Берешь все самое модное и делаешь транспайлер в си и крайне желательно, чтоб еще и обратно.
Наблюдаю сейчас за V — надеюсь взлетит.
PsyHaSTe
Ну вот есть ллвм, и си в него можно, и любой другой язык. Только ничего это особо не дает. Условно говоря если язык не разрешает null-значений, то сишную функцию которая может вернуть null из этого языка просто так не вызвать.
snuk182
Вы описали Nim.
Elfet
Есть ещё вот такой вот язык: Kit(https://www.kitlang.org )
Очень интересный, хоть и молодной. Похож на nim только лучше.
lega
Чем лучше?
Elfet
https://blog.kitlang.org/2019/03/15/why-i-created-kit/
Psionic
Ну и кто из софтверных гигантов готов перевести свои продукты на один язык из этой тройци, тем самым списав «в утиль» кучу наработок, специалистов и опыта ведения проектов? А также готовность бегать по свеженьким граблям и заново изобретать то что в С/С++ уже было готово и отлажено? И да у D/Rust (про Go не знаю) нет готовой корпоративной Enterprise — среды уровня Eclipse или Visual Studio, приходится по челябински сурово скачивать консольный компилятор, а потом болтами и электросваркой прикручивать туда сторонний отладчик и IDE, что родит кучу специфических cpaчиков про которые говорить не стоит.
Kirhgoff
Вы ошибаетесь. Про D не знаю, но для Rust есть CLion — потрясающий IDE. Умеет кучу рефакторингов делать, отладка, тесты, умные подсказки и ворнинги. Я пока что не встречал того, что я бы хотел сделать и он не умел, правда у меня за спиной только один большой проект на Rust, который я написал для себя.
Gorthauer87
Derive макросы он пока не очень умеет
PsyHaSTe
Microsoft этим занимается.
Во-первых это не так.
Во-вторых в утиль иногда переписывают и так. У меня в одной конторе один проект 3 раза переписывали, сначала на плюсах, потом на жабе, потом на шарпах. По разным причинам.
Psionic
Нет так, что вы 50-ти летнего тех-лида за учебник языка и доку к компилятору посадите, да еще будете терпеть пока он этим всем овладеет? Откажетесь от кучи внутренних фраймверков/библиотек потому что они на С/С++ (хотя костыльная линковка и костыли с вызовами могут помочь, но то не айс), ну менеджеры которые не будут знать как быть со всем этим на проекте.
PsyHaSTe
Думаю, даже на этом сайте хватает 50летних лидов которые дадут вам фору в современных языках и фреймворках.
Я писал враппер и дальше работал на языке который мне больше подходил под задачу.
tangro
Из всего этого право на жизнь имеет только Rust.
D был «перспективным языком» два десятилетия — и нифига не взлетел. Уже и не взлетит.
Go чётко замкнулся в области «нам тут надо быстренько CRUD наваять, ну и чтоб на всяк случай был запас по горизонтальному масштабированию». Там он и останется навсегда.
Что же касается Rust — очень интересно смотреть как Mozilla переписывает на нём Firefox. Сначала их проект Quantum, потом — WebRender. У ребят реально получается. Код пишется, баги фиксятся, мемори-ликов и крашей нет, производительность настолько близка к чистому С, что нет смысла даже и мерять. Их опыт показывает, что любое прикладное ПО на С/С++ написать на Rust будет быстрее и надёжнее. С системным программированием сложнее, нужен кто-то, кто не побоится на нём написать какой-то компонент ядра ОС или драйвер. И мне кажется, что это будет Microsoft. Им очень не хватает такого языка в их экосистеме.
JekaMas
Почему-то вокруг меня проекты по bd, распределенным системам на go. Я где-то не там?
PsyHaSTe
Скорее всего в озоне.
JekaMas
Не. В Озоне половина товарищей по Лазаде. Ну еще в Авито, Алибабе, Мейл, Сбертехе…
menstenebris
Для желающих узнать направления в которых движется Rust оставляю подборку
arewegameyet.com
arewelearningyet.com
areweguiyet.com
arewewebyet.org
areweasyncyet.rs
docs.rust-embedded.org/faq.html
Так же оставлю здесь ссылку на общий бенчмарк веб фреймворков.
www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=query
darkAlert
я хоть убейте не понимаю, как на современных С++ 11/14/17 можно испытывать проблемы с ручным управлением памятью.
gecube
Я полностью согласен, что это ДРУГОЙ язык, чем С++ изначальный, но по недоразумению он называется так же. И по недоразумению тащит багаж обратной совместимости, который позволяет писать говно-код (т.к. за это по рукам никто не надает). И вообще такое ощущение, что разработка самого языка С++ — стихийная, беспорядочная, из серии "а чего бы еще в стандарт запихать". И синтаксис бррр… И тулинг из 80-х. Но это мое личное мнение ) Как говорится, чтобы создать новый мир, надо старый разрушить до основания (читай — сделать новый язык с нуля, с учетом ошибок предыдущих).
MooNDeaR
Забавное утверждение :D Достаточно открыть блог PVS Studio чтобы убедиться в том, что 90% всех проблем в коде на С++ порождены проблемами работой с памятью)
gecube
Либо опечатками из-за отсутствия лаконичности в синтаксисе. Коллега выше там сниппет по обработке json приводил и очевидно, что чем больше кода, тем больше вероятность получить в нем описку-опечатку.
littorio
А блог PVS Studio в этой ситуации имеет смысл открывать вообще? Они же публично анализируют РАБОТАЮЩИЕ продукты, условно беспроблемные. Если бы вы багтрекер чей-нибудь предложили открыть — другое дело. Только там на классы "ошибок программиста", вроде, не делят. Пока, хе-хе.
gecube
А чего? Отличная идея. Запустить машинное обучение, пускай анализирует коды и подсказывает есть ли ошибка в этом фрагменте )
uvelichitel
Автор оценивает языки с точки зрения архитектора языка, каковым и является.
Для меня, как для пользователя языка, очень IMHO, 10x+:
gecube
Я бы усомнился в этом. Она сносная. Не более. Зеленые потоки реально привнесли новый вкус в разработку. Но нужно четко понимать их ограничения, иначе легко устроить дедлоки.
0xd34df00d
Непонятно, что они привнесли, если они уже давно были много где.
uvelichitel
А где они были в синтаксисе а не в библиотеках? Дело даже не в том что потоки зеленые, это аспект реализации. Если появятся 100500 ядерные процессоры то хватит и системных потоков. Достоинство Go в том, что потоки и каналы сообщений между ними в core syntax.
Например конструкцию select (гордость Go) не представляется возможным реализовать на уровне библиотек.
0xd34df00d
А зачем в синтаксисе? Зачем это должно быть в ядре чуть ли не грамматики языка? Не, понятно, если в языке нифига примитивов нет для построения соответствующих библиотек, то иначе и не получится, но я не назвал бы достоинством языка.
Можно взять waitAny, например. Можно передать ей список async'ов, и получится точно тот же select, только лучше, потому что теперь с аргументом select'а можно оперировать так же, как с любыми другими списками.
vintage
select элементарно реализуется на комбинации while и switch.