Здравствуйте, Артём, Вы писали:

Аё>C++ leads to really really bad design choices. You invariably start using
Аё>the "nice" library features of the language like STL and Boost and other
Аё>total and utter crap, that may "help" you program, but causes:

Аё> — infinite amounts of pain when they don't work (and anybody who tells me
Аё> that STL and especially Boost are stable and portable is just so full
Аё> of BS that it's not even funny)

Эта цитата разбиралась 100500 раз вплоть до буквы, и размахивать ею в очередной раз, как эксгибиционист своим органом, уже настолько неприлично, что просто смешно.
И она безумно старая — это уже сколько, 20 лет прошло? Язык с тех времён изменился чуть менее, чем полностью.
А ещё смешнее, что Артёмка размахивает даже не своим органом, а муляжом Торвальдса

На самом деле C++ очень хорош именно тем, что его можно использовать до разного уровня. Можно включать исключения, можно не включать. Можно использовать STL, можно не использовать. Можно разрешать исключения, можно не разрешать.
Но даже пространства имён и привязка функций к классам/структурам — уже достаточная причина, чтобы начать его использовать в достаточно большом проекте.
У гугла C++ другой, чем у нас в текущем проекте, а оба — чем в моём прошлом проекте.
Но тем не менее они все C++.

Аё> — inefficient abstracted programming models where two years down the road
Аё> you notice that some abstraction wasn't very efficient, but now all
Аё> your code depends on all the nice object models around it, and you
Аё> cannot fix it without rewriting your app.

И никто не заставляет такое использовать в реале.

Аё>In other words, the only way to do good, efficient, and system-level and
Аё>portable C++ ends up to limit yourself to all the things that are
Аё>basically available in C.

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

Аё>And limiting your project to C means that people
Аё>don't screw that up, and also means that you get a lot of programmers that
Аё>do actually understand low-level issues and don't screw things up with any
Аё>idiotic "object model" crap.

И ничего в ней нет идиотского. Она используется точно так же и в C, только неявно.

Аё> — the whole C++ exception handling thing is fundamentally broken. It's
Аё> _especially_ broken for kernels.
Аё> — any compiler or language that likes to hide things like memory
Аё> allocations behind your back just isn't a good choice for a kernel.

Потому что ему не приходит в голову, что память можно резервировать.

Аё> — you can write object-oriented code (useful for filesystems etc) in C,
Аё> _without_ the crap that is C++.

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

Аё>Сейчас, конечно, набежит so5steam и продолжит песню о "производительности" C++.

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

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Артём, Вы писали:

Аё>>Цитата Линуса Торвальлса (создателя ядра линукс и git)

CC>А ты внутрь гита то сам заглядывал? Там такое макаронное месиво что просто атас.
CC>Rants этого ниасилятора попросту не интересны. Ну не шмог он, и теперь пыжится, выдавая нужду за добродетель.

1. От кода Торвальдса в Git почти ничего не осталось.
2. Вполне там нормальный код как для C. Я бы стиль отрихтовал, конечно, но и так неплохо.

Здравствуйте, SkyDance, Вы писали:

SD>Сдается мне, Торвальдс не столько огорчен безумием в С++, сколько тем, что придется впустую продолбать год(ы) на изучение кишочков этих С++ стандартов,

При знании C, отличия C++ на уровне, пригодном для ядра, учатся за два дня с перекурами.

SD> дебагом всей этой ненужной сложности и т.п..

А основные грабли, на которые будут наступать в этом случае, общие с C.

Здравствуйте, SkyDance, Вы писали:

SD>Открою страшную тайну. Большиство языков по сути одинаковы. Разве что функциональщина vs императивщина чутка вырывает мозг. Но поняв оба класса языков, дальше уже совершенно неважно.

Ну подойди с таким подходом, например, к Idris.

SD>И платят не за С++ или Rust. А за умение выполнить задачу.

Наверху (заказчик бизнес-задачи) — да. А дальше вниз — за язык в существенной мере. После того, как он выбран.

SD> С помощью подходящего инструмента. Так что все языки высокооплачиваемы (английский, КМК, самый высокооплачиваемый, на данный момент).

Ну попробуй найти высокооплачиваемую работу на Turbo Pascal.

Здравствуйте, netch80, Вы писали:

N>И она безумно старая — это уже сколько, 20 лет прошло?

Если я правильно понимаю, то Тёмчик процитировал два письма Торвальдса. Первое от 2007-го, второе от 2004-го.

http://harmful.cat-v.org/software/c++/linus

Аё>> — any compiler or language that likes to hide things like memory
Аё>> allocations behind your back just isn't a good choice for a kernel.

N>Потому что ему не приходит в голову, что память можно резервировать.

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

void some_func(std::string v) {
  std::cout << std::format( "I just call to say: {}", v ) << std::endl;
}

some_func("Hello, World!");

Да, в общем-то, многие начинающие C++ники (особенно переходящие в C++ после многих лет на языках типа Java/C# или Python/Ruby) не сразу начинают понимать, что "Hello, World!" -- это всего лишь const char[14], а не std::string.

Все это и изучается, и обходится. Но это требует "впустую продолбать год(ы) на изучение кишочков этих С++ стандартов". Толи дело чистая ламповая Сишечка, там изучать особо-то и нечего, продалбывать годы можно прямо на "дебаг", не отвлекаясь понапрасну.

Здравствуйте, SkyDance, Вы писали:

N>>Это странно. Я видел только такое. Чаще проблема в качестве контроля со стороны лидов, и крайне редко — в его невозможности.

SD>Возможно, специфика структуры incentives у определенных компаний. Когда основная масса бонусов идет за "time to market". В таком варианте любой контроль качества обходится фразой "весь мир насилья мы разрушим зарелизим вот эту фичу, и потом зарефакторим, отчистим от мусора, сделаем нормальный API, добавим тесты". Практика показывает, что "а потом" обычно не наступает.

Да. Если в компании даётся хотя бы 10% времени на зачистку от долга, написание тестов и т.п., это уже удовлетворительно. И надо форсировать полосу времени с максимально высокого уровня.

Но это мы ушли в сторону.

SD> Разве что находятся герои, самоотверженно бросающиеся на амбразуру. Но они быстро сгорают, ибо в награду вместо финансовой благодарности получают низкий рейтинг в performance review, потому что "трижды обрушил систему, убирая неиспользуемый код, который играл важную роль для разогрева процессора с целью последующей прожарки сосисок на нем".

Такого вживую я, к счастью, ещё не видел. Хотя слышал.

Здравствуйте, so5team, Вы писали:

N>>И она безумно старая — это уже сколько, 20 лет прошло?

S>Если я правильно понимаю, то Тёмчик процитировал два письма Торвальдса. Первое от 2007-го, второе от 2004-го.

15. Не сильно много разницы, и точно до вступления C++11 в реальную жизнь.

N>>Потому что ему не приходит в голову, что память можно резервировать.

S>Тем не менее, в его словах есть доля правды, особенно если за C++ берутся новички. Т.к. они не подозревают что может скрываться за:

При том жёстком контроле за кодом, что есть в ядре Linux, такое не должно проходить (ну кроме особых мест).
И этот контроль можно обеспечить формированием стандартной библиотеки (которая уже есть, но мне непонятно, почему ядро компилируется в hosted).

S>Все это и изучается, и обходится. Но это требует "впустую продолбать год(ы) на изучение кишочков этих С++ стандартов". Толи дело чистая ламповая Сишечка, там изучать особо-то и нечего, продалбывать годы можно прямо на "дебаг", не отвлекаясь понапрасну.

Да не нужны годы на изучение.
Установить freestanding сборку с нужными ограничениями — раз плюнуть. Но он вначале посрался со всеми авторами компиляторов, так что слушать не будут, а теперь никто и не захочет туда идти.

Здравствуйте, SkyDance, Вы писали:

SD>OpenMP — это не библиотека, а "стандарт", суть список функций API.

Это и библиотека, и набор API, и директивы компилятора. Библиотека libomp у Интела написана на С/С++, у llvm также. У Майкрософта она какой-то древнючей версии и не развивается, про gcc не в курсе.

Здравствуйте, SkyDance, Вы писали:

SD>Сдается мне, Торвальдс не столько огорчен безумием в С++, сколько тем, что придется впустую продолбать год(ы) на изучение кишочков этих С++ стандартов, дебагом всей этой ненужной сложности и т.п..


То, что ты написал, это хоть и является правдой, но Линус написал другое, а именно- что C++ фундаментально сломан, и топят за него либо bigot-ы, либо говнокодеры. Я с 100% уверенностью могу отнести Крейтора к первой группе, по косвенным признакам как неприятие STL. Т.е. плюсный проект, да еще и в ядре- это как лакмусовая бумажка, что проект дизайнился неадекватом. Собственно, одну такую яркую личность в этой ветке мы и наблюдаем.

N>Ну подойди с таким подходом, например, к Idris.

Haskell, ocaml, Idris — это все тот самый второй класс, функциональщина. После многих лет императивщины поначалу их сложно понять, но потом начинаешь видеть стройность концепций и легко перепрыгиваешь между языками этого класса.

N>Наверху (заказчик бизнес-задачи) — да. А дальше вниз — за язык в существенной мере. После того, как он выбран.

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

N>Ну попробуй найти высокооплачиваемую работу на Turbo Pascal.

Неужели я недостаточно ясно выразил мысль: языки все похожи и примерно одинаковы. Поэтому нужно не "работу на языке". А выбор языка под задачу. У С++ своя ниша и свои задачи. Притом не очень широкая в силу избытка сложности.

S> Толи дело чистая ламповая Сишечка, там изучать особо-то и нечего, продалбывать годы можно прямо на "дебаг", не отвлекаясь понапрасну.

А почему нужно продалбывать годы на дебаг? Тесты писать не научились?
В случае с С++, да, leaky abstraction, поэтому надо знать _И_ кишки С++, и как работает С. Сложность на пустом месте.

Здравствуйте, netch80, Вы писали:

N>На самом деле C++ очень хорош именно тем, что его можно использовать до разного уровня. Можно включать исключения, можно не включать. Можно использовать STL, можно не использовать. Можно разрешать исключения, можно не разрешать.
N>Но даже пространства имён и привязка функций к классам/структурам — уже достаточная причина, чтобы начать его использовать в достаточно большом проекте.
N>У гугла C++ другой, чем у нас в текущем проекте, а оба — чем в моём прошлом проекте.
N>Но тем не менее они все C++.

Эти дебилы сишники даже vtbl руками делают. Ну, то есть до идеи они таки дошли, а вот использовать инструмент, который всё корректно сам сделает — мозгов уже не хватает

Здравствуйте, SkyDance, Вы писали:

N>>Ну подойди с таким подходом, например, к Idris.

SD>Haskell, ocaml, Idris — это все тот самый второй класс, функциональщина. После многих лет императивщины поначалу их сложно понять, но потом начинаешь видеть стройность концепций и легко перепрыгиваешь между языками этого класса.

Ты серьёзно всё, что в нём видишь, это "функциональщина"?

N>>Наверху (заказчик бизнес-задачи) — да. А дальше вниз — за язык в существенной мере. После того, как он выбран.

SD>Выбор языка не обязательно случается раз и навеки. Более того, оный выбор зачастую идет не от свойств и качеств языка, а от всяких случайностей — например, от того, что за чашечкой чая кто-то услышал про "дешевых С++ разработчиков" и "невозможно найти знатока Rust".

"Зачастую" — это 3% или 5% случаев?

N>>Ну попробуй найти высокооплачиваемую работу на Turbo Pascal.

SD>Неужели я недостаточно ясно выразил мысль: языки все похожи и примерно одинаковы.

Цитирую:

SD>> Так что все языки высокооплачиваемы

По-моему, достаточно ясно

SD> Поэтому нужно не "работу на языке". А выбор языка под задачу. У С++ своя ниша и свои задачи. Притом не очень широкая в силу избытка сложности.

Сложности задач, а не языка.

Здравствуйте, SkyDance, Вы писали:

S>> Толи дело чистая ламповая Сишечка, там изучать особо-то и нечего, продалбывать годы можно прямо на "дебаг", не отвлекаясь понапрасну.

SD>А почему нужно продалбывать годы на дебаг?

Потому что писать надежно на Си могут не только лишь все.

А в самом языке нет (насколько я помню) никаких возможностей облегчить себе жизнь и повысить надежность кода. В отличии от.

SD>Тесты писать не научились?

Применительно к C++ вы в этот тезис почему-то не верите.

SD>В случае с С++, да, leaky abstraction, поэтому надо знать _И_ кишки С++, и как работает С.

Как бы нет. Знать как работает Си не нужно.

SD>Сложность на пустом месте.

Сложность да. Но не на пустом месте. Отсюда, собственно, и сложность.

N>Ты серьёзно всё, что в нём видишь, это "функциональщина"?

Я серьезно вижу это как один из сложнейших моментов перехода для "сеньор-девелоперов" что провели годы изучая C++, Java или C#. Переходить между C++/Java очень просто. Переходить между Haskell/OCaml/Idris, посложнее, но лишь немногим. Тогда как переходить между C++ и Haskell — это... не для слабых! Поэтому я и выделил два класса, императивные и функциональные. Дальше можно до хрипоты спорить и изобретать разные концепции, но это уже будут детали.
Касаемо Idris, type-driven лично я бы рекомендовал на Haskell, хотя бы в силу реальной применимости данного языка в production. Код на Idris я в production не видел. Если кто-то может подсказать, где он реально используется (а значит, имеет практический смысл его изучить подробнее), буду благодарен.

N>"Зачастую" — это 3% или 5% случаев?

Ха. Зачастую — это как бы не 95% случаев. Когда "я знал только Python, поэтому DropBox/Instagram/... на нем и написан". Не так-то просто найти менее подходящий для бэкенда язык

N>Цитирую:
SD>>> Так что все языки высокооплачиваемы

Фигурная резьба по цитатам, само собой, приведет к такому эффекту. Суть моего посыла в том, что надо искать не C++ или Idris, а задачи — и выбирать инструмент, который под эти задачи подходит. Даже если это PHP. Разве что насчет Perl я не уверен
Можно заменить цитату на "все языки низкооплачиваемы", суть та же — платят не за язык, а за решение задач. Решать задачи HFT можно не только на С++, равно как и не только HFT можно делать на С++.

N>Сложности задач, а не языка.

Неа, в данном случае, именно сложность языка как инструмента. Возникшая из-за кучи legacy и organic growth. Дизайн языка с нуля был бы куда более цельным. И менее сложным. А значит, более производительным в плане скорости разработки.

Здравствуйте, SkyDance, Вы писали:

SD>Дизайн языка с нуля был бы куда более цельным. И менее сложным. А значит, более производительным в плане скорости разработки.

Тут мы приходим к Go- офигенскому языку от автора C, который не захотел тратить годы на разбирание кишочков C++, и при этом с офигенскими фичами как duck typing interface и CSP. жаба с крестиками тихо плачет в сторонке.

Аё>Тут мы приходим к Go- офигенскому языку от автора C, который не захотел тратить годы на разбирание кишочков C++, и при этом с офигенскими фичами как duck typing interface и CSP. жаба с крестиками тихо плачет в сторонке.

У Go тоже четко очерченая ниша — бэкенды/сервисы. Основной плюс Го — за ним стоит сильная инженерная команда. Причем большая команда. И многие вещи делаются без оглядки на совместимость (ибо для конкретных нужд).

Иными словами, в отличие от С++, который больше про добровольное участие, в Го вливаются огромные деньги. Ибо понятно, зачем. Но в этом же и проблема: если в Гугл появится новый политик, который поменяет направление денежных потоков, будущее языка уже не будет столь безоблачным.

PS: но сам рантайм прикольный. Если здесь на форуме есть кто-то, работающий над этим рантаймом, черканите весточку — интересно обсудить некоторые идеи.

Здравствуйте, SkyDance, Вы писали:

SD>У Go тоже четко очерченая ниша — бэкенды/сервисы. Основной плюс Го — за ним стоит сильная инженерная команда. Причем большая команда.

Да, с микросервисами на жабе, завернутыми в докер, есть небольшая проблема- дорого обходятся в инстансах EC2. Есть подозрение, что то же самое на Go в разы скромнее в аппетитах к размеру EC2.

Аё>Да, с микросервисами на жабе, завернутыми в докер, есть небольшая проблема- дорого обходятся в инстансах EC2. Есть подозрение, что то же самое на Go в разы скромнее в аппетитах к размеру EC2.

Это вообще не проблема для подавляющего большинства юзеров. Проблема скорее в том, что Java тоже немолода, и тоже не свободна от legacy/organic growth. Поэтому пилить конкретно сервисы проще на том инструменте, который был под то заточен с самого начала, а не на Java, который позиционируется как универсальный язык.

Здравствуйте, Артём, Вы писали:

Аё>То, что ты написал, это хоть и является правдой, но Линус написал другое, а именно- что C++ фундаментально сломан
Нет, Артёмка, это не С++ фундаментально сломан, это у пЫнгвина моск закостенел давно.

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