#огда коту нечего делать- он пишет sudo на Rust - Компьютерные священные войны

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

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

D>>А что ты думаешь об эрланге?

S>Интересный нишевый язык. ИМХО, диссертация Джо Армстронга, в которой он описывал свой подход к разработке ПО в присутствии программных ошибок, обязательна к прочтению. Хотя бы для знакомства с принципом fail-fast. Еще неплохо бы прочитать историю Erlang-а от него же для History of Programming Languages.

Спасибо за ответы! Я у Джо Армстронга книгу прочитал по эрлангу. Очень интересная книга. Видно, как человек был воодушевлен своей разработкой. Прямо весь горел идеями.

D>>Какие мысли по эрлангу?

S>Наверное, он очень хорош там, где может применяться. Но меня смущает то, что он динамический. Таки чем дальше, тем больше ценю статическую типизацию. Плюс чисто по синтаксису мне больше симпатичен Elixir.

Я так понимаю, динамическая типизация важна по двум причинам: (1) удобно для передачи и обработки сообщений; (2) а главное, что можно динамически обновлять код.

Может быть, я знаком далеко не со всеми основными языками, но динамическое обновление возможно в коммон-лиспе, смолтоке и эрланге, причем все три — динамические. Причем, в эрланге к этому очень серьезно подошли, сделав обновление кода двухэтапным с четким описанием, как перейти сразу на обновленную версию (через вызов функции по квалифицированному имени).

Так что, здесь динамика важна.

А у эликсира я пока не увидел особых преимуществ перед эрлангом. Может быть, только макросы. Но это тоже бабка надвое сказала.

Пробовал немного писать на обоих языках. Оба приятны. Мне понравилось и там, и там.

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

S>Как говорится, сделать сложно не сложно, сложно сделать просто. Вот сделать просто и не получается.

Ранний C++ был хорош по сравнению с конкурентами своего времени! Это да. Выглядело тогда очень круто.

S>Другое дело, а можно ли вообще как-то иначе, если поддерживать хорошую совместимость с предыдущими стандартами и в условиях широкой диверсификации языка/библиотек... Т.е. может быть я ругаю, а лучше в принципе не сделать.

Груз совместимости. У меня есть ощущение, что современные тенденции в программировании немного расходятся с тем, какой фундамент был заложен в С++. Сложно было предусмотреть все при проектировании языка. Это нормально.

S>Мне не очень понятно, как обучать абсолютных новичков современному C++.
S>Я-то ладно, потихоньку новое осваиваю. Медленно, со скрипом, но у меня хотя бы есть роскошь делать это итерационно, по чуть-чуть.
S>А вот как взять вчерашнего PHP-шника или Python-иста, которые может быть когда-то Си видели краем глаза во студенчестве, и обучить современному С++ с шаблонами, концептами и пр. Вот это загадка.

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

Да и по-моему наблюдению сейчас люди меньше стремятся к новым знаниям. Больше потребляют контент из интернета. Это касается даже программистов. Вместо прочтения книг ищут видосики в интернете, где им якобы все объяснят и покажут. Хотя мне кажется, что программирование — это больше про индивидуальную самостоятельную работу, про постоянные тренировки, про чтение книг.

S>Еще один момент: мне не нравятся некоторые принятые решения. Например, то, что сделали с deducing this. Или предлагаемый сейчас синтаксис для рефлексии с оператором "баян" (т.е. [:|||:]). ИМХО, у кого-то в комитете нет ни чувства стиля, ни чувства меры.

О, я вот за этим поездом не поспел. Про оператор "баяна" еще не в курсе.

S>И еще один парадокс: C++ становится все сложнее, а пользоваться им -- все проще.
S>Прошу заметить, я не говорю, что С++ становится безопаснее. Но вот писать на C++ с каждым новым стандартом становится все проще и приятнее. И делать удается то, что раньше казалось фантастикой.

S>Наблюдение из практики: когда приходится возвращаться со свежих стандартов на более старые (скажем, после С++20 вернуться на C++17, или после C++17 вернуться на C++14), то начинается ломка от того, что ставшие привычными вещи оказываются недоступны. Например, в C++17 нет operator<=>, а в C++14 нет structured binding.

Готов согласиться при условии очень избирательного использования новых фич.

S>Я вынужден согласиться с той точкой зрения, что если С++ не устраивает, то спокойно можно выбрать другой современный (или не очень) язык. Хороший выбор среди управляемых языков с GC: C#, Java, Kotlin, Go + Scala/OCaml/Haskell для любителей хардкора. Даже среди нативных языков без GC к экзотической Ada уже добавился хайповый Rust.

S>Мне бы хотелось видеть какой-то cpp2 (вроде того, что делает Саттер): новый язык на тех же идеях и с таким близким синтаксисом, который бы позволял слегка переделать существующие C++ные исходники. Но это был бы именно что другой язык, без попытки сохранить обратную совместимость.

S>Нужен ли он -- отдельный вопрос. Судя по Carbon-у от Google, кому-то что-то подобное нужно.

В телеграмме мне понравилось одно изречение, что сейчас написано так много кода на С++, C# и Java, что эти языки еще скоро никуда не денутся. Поэтому новым языкам очень трудно будет пробиться, сколь бы хороши они ни были.

В качестве контр-примера привели только Kotlin и Go, которые проталкивает Google. Без Google, возможно, что у них ничего бы не получилось.

Грустно, но похоже на правду.

От себя добавлю. Почему ушел ПЛ/1? А ведь был очень крутой монстр. Да потому, что появились персоналки, где он был просто не нужен. А с современными старыми языками пока такого сценария не предвидится.

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

S>>Еще один момент: мне не нравятся некоторые принятые решения. Например, то, что сделали с deducing this. Или предлагаемый сейчас синтаксис для рефлексии с оператором "баян" (т.е. [:|||:]). ИМХО, у кого-то в комитете нет ни чувства стиля, ни чувства меры.

D>О, я вот за этим поездом не поспел. Про оператор "баяна" еще не в курсе.

Вот здесь можно насладиться этим зрелищем и, заодно, увидеть каким будет "современный C++" через пару-тройку лет:

для затравки -- https://brevzin.github.io/c++/2025/05/02/soa/
для полного погружения

-- https://brevzin.github.io/c++/2025/06/09/reflection-ts/

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

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

K>>Здесь строковый литерал превратится в объект string и управлять временем жизни этого обьекта программисту не придется.

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

У вас в примере все переменные статические и автоматические. То что язык управляет статической-автоматической памятью это не удивительно. Есть ли в природе языки которые этого не делают? А все остальное в С++ делается ручкам, да язык вызывает деструктор если объект уходит из область видимости, но подчищать динамическую память в деструкторах нужно ручками. И тут абсолютно никакой разницы какие руки это написали. ваши или те кто писал стандартную библиотеку.

K>>И в чем громадная?

S>Хотя бы в том, что часть стандартной библиотеки может быть написана на совсем другом языке.

И что это меняет?

S>Разговорчивый вы мой, ни одно из ваших словесных испражнений не может перебить того факта, что есть официальный стандарт языка C++, в котором описана и его стандартная библиотека. И нет официальных документов, которые бы описывали язык C++ отдельно как некий язык, частью которого не была бы STL.

S>Продолжите и дальше демонстрировать свое альтернативное восприятие реальности?

По вашим словам библиотека — это язык потому, что так написано якобы в какой-то бумажке. Что могу сказать? Живите с этим дальше.

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

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

K>>Без GC и JIT не будет работать компонентная модель, не будут работать некоторые lock free алогритмы основанные на том, что простое присваивание позволяет забыть указатель (В с++ не реализуемо) и другие вещи.

M>Тут стало интересно

K>>Многие вещи которые можно сделать например на C# в языке C++ просто не реализуемы.

M>А вот тут стало очень интересно

Язык С++ несмотря на большое количество всеразличной функциональности на самом деле беден как церковная мышь. В сравнении с С# у С++ в плюсах только множественное наследование и более развитая система шаблонов провосходящая дженерики. Дальше начинается полный швах. Рефлексии нет, кодогенерации на лету нет, интерфейсов нет, JIT и GC нет. Естественно что решить задачи которые опираются на рефлексию, JIT и GC в С++ не будет никакой возможности в силу отсутствия в С++ данной функциональности. При этом практически все что можно сделать на С++ можно спокойно сделать на С#
Возьмите такую простую вещь как динамическая библиотеки. Создавать их на С++ не имеет никакого смысла т.к. Линковаться вы сможете только к той версии dll/so с которой собиралась программа. В противном случае поедет порядок виртуальных функций в vtbl размеры классов, их layout и т.п. Фактически при загрузке dll работает только линкер, а для того чтобы учесть изменения в новой версии dll необходимо чтобы еще работал компилятор. В шарпе же динамические библиотеки себя прекрасно чувствуют т.к. при их загрузке работает компилятор. Именно по этому попытка создать на С++ сложный программный комплекс с возможностью добавления сторонних решений в 100% случаев заканчивается обосрамсом. Знаю ситуации когда люди наскакавшиcь на граблях с С++ переписывали АПИ своих комплексов с С++ на голый плоский С.

И здесь мы еще слышим регулярный плач ярославны что якобы GC торомзит. При том что выделение памяти в GC происходит на порядок быстрее чем в куче, память в GC почти всегда дефрагментирована и как я уже говорил указатель можно просто забыть (присвоить null или другой обьект), что сильно упрощает и ускоряет работу многопоточных lock free программ. В С++ такое не прокатит, объект нужно будет удалить, а значит придется сделать лишний CAS. Думаю если задаться целью можно написать lock free функциональность на шарпе с совершенно недостижимой на с++ производительностью.

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

K>>>Здесь строковый литерал превратится в объект string и управлять временем жизни этого обьекта программисту не придется.

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

K>У вас в примере все переменные статические и автоматические.

Что опровергает ваш исходный тезис: "программист вынужден управлять временем жизни каждой переменной"
Не вынужден, не каждой.

K>но подчищать динамическую память в деструкторах нужно ручками

Давно уже нет. Где-то с того момента, как в язык добавили шаблоны.

K>>>И в чем громадная?

S>>Хотя бы в том, что часть стандартной библиотеки может быть написана на совсем другом языке.

K>И что это меняет?

Чуть меньше, чем все.

S>>Разговорчивый вы мой, ни одно из ваших словесных испражнений не может перебить того факта, что есть официальный стандарт языка C++, в котором описана и его стандартная библиотека. И нет официальных документов, которые бы описывали язык C++ отдельно как некий язык, частью которого не была бы STL.

S>>Продолжите и дальше демонстрировать свое альтернативное восприятие реальности?

K>По вашим словам библиотека — это язык потому

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

По моим словам стандартная библиотека является частью языка, потому что она описана в стандарте языка.
Я нигде не утверждал, что "библиотека -- это язык".

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

K>И здесь мы еще слышим регулярный плач ярославны что якобы GC торомзит.

Это уже давно было доказано экспериментально.
Чтобы GC не тормозил, ему нужно от 4 раз больше ОП, чем в случае с ручным управлением памятью.

Из свежего: https://www.cnews.ru/news/top/2025-06-05_apple_otkazyvaetsya_ot_java_v_polzu

Перевод данной конкретной системы на Swift, по оценке разработчиков, позволил добиться 50-процентной экономии вычислительных ресурсов, снижения потребления памяти на 90% и 40-процентного повышения пропускной способности.

K>Думаю если задаться целью можно написать lock free функциональность на шарпе с совершенно недостижимой на с++ производительностью.

Дурень думкой богатеет.

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

S>Что опровергает ваш исходный тезис: "программист вынужден управлять временем жизни каждой переменной"
S>Не вынужден, не каждой.

Вобщем-то так и есть чтобы вы не говорили. Программист располагает переменные в трех классах памяти, соответственно определяет время жизни. Если объект создается динамически вы выбираете для него подходящую обертку shared_ptr, unique_ptr и т.д чем это не управление временем жизни?

K>>но подчищать динамическую память в деструкторах нужно ручками

S>Давно уже нет. Где-то с того момента, как в язык добавили шаблоны.

с этого места поподробнее

K>>>>И в чем громадная?

S>>>Хотя бы в том, что часть стандартной библиотеки может быть написана на совсем другом языке.

K>>И что это меняет?

S>Чуть меньше, чем все.

А по факту ровным счетом ничего. Какая разница на чем написан код если он написан руками?

S>Нет. Вынужден еще раз констатировать то, что вы не умеете читать. Полагаю, что в силу реверсивного интеллектуального развития.

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

А по моим словам не является. Потому что я опираюсь на определения языка и библиотеки. А не на тот факт что язык и библиотеку в одной бумажке описали.

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

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

K>>И здесь мы еще слышим регулярный плач ярославны что якобы GC торомзит.

S>Это уже давно было доказано экспериментально.
S>Чтобы GC не тормозил, ему нужно от 4 раз больше ОП, чем в случае с ручным управлением памятью.

Этим вы можете только восторженных неофитов впечатлить. А по факту в системах с неперемещаемой памятью она может фрагментироваться настолько, что свободной памяти полно, а массивчик разместить негде. На 64 бит это конечно малоактуально, а на 32-х исчерпание адресного пространства из-за фрагментации было серьезной проблемой.

S>Из свежего: https://www.cnews.ru/news/top/2025-06-05_apple_otkazyvaetsya_ot_java_v_polzu
S>

Перевод данной конкретной системы на Swift, по оценке разработчиков, позволил добиться 50-процентной экономии вычислительных ресурсов, снижения потребления памяти на 90% и 40-процентного повышения пропускной способности.

Ключевые слова здесь перевод данной конкретной системы.

K>>Думаю если задаться целью можно написать lock free функциональность на шарпе с совершенно недостижимой на с++ производительностью.

S>Дурень думкой богатеет.

А чем богатеет токсичное сообщество мелкобукв обиженных на научно технический прогресс?

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

K>Вобщем-то так и есть чтобы вы не говорили. Программист располагает переменные в трех классах памяти, соответственно определяет время жизни. Если объект создается динамически вы выбираете для него подходящую обертку shared_ptr, unique_ptr и т.д чем это не управление временем жизни?

Попробуйте обратить ваши слова на любой язык с GC и получите тоже самое, с поправкой на то, что классов памяти окажется поменьше.

Т.е. в очередной раз херня с вашей стороны.

K>А по факту ровным счетом ничего.

Кроме того факта, то для каких-то языков нельзя написать стандартную библиотеку средствами самого языка.

K>Какая разница на чем написан код если он написан руками?

Попробуйте обратить ваши слова на любой язык с GC...

K>А по моим словам не является.

Ну говорите, говорите. На заборах тоже много чего пишут.

K>Потому что я опираюсь на определения языка и библиотеки.

Во-первых, хз какие определения.

Во-вторых, вы не смогли объяснить работу некоторых средств стандартной библиотеки (того же std::launder) на базе возможностей языка.

Т.е., очередные пуки в лужу по всем направлениям.

K>А не на тот факт что язык и библиотеку в одной бумажке описали.

Да оно понятно, что когда реверсивный ителлект и альтернативное восприятие реальности, то на существование международного стандарта того, что называется "язык программирования C++" можно и болт положить.

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

S>>Это уже давно было доказано экспериментально.
S>>Чтобы GC не тормозил, ему нужно от 4 раз больше ОП, чем в случае с ручным управлением памятью.

K>Этим вы можете только восторженных неофитов впечатлить.

Неофиты из Apple (ссылку на которых я давал) очень впечатлились от того факта, что у них Java с GC потребляла почти на порядок больше памяти, чем Swift без GC. Но не смотря на то, что факты упрямая вещь, г.Kluev тоже не лыком шит, у него своя реальность, с розовыми очками, через которые видно лишь то, что ему удобно.

K>А по факту в системах с неперемещаемой памятью она может фрагментироваться настолько, что свободной памяти полно, а массивчик разместить негде. На 64 бит это конечно малоактуально, а на 32-х исчерпание адресного пространства из-за фрагментации было серьезной проблемой.

До тех пор пока в проекты не затаскивали jemalloc, tcmalloc, mimalloc или какой-то заточенный под задачу кастомный аллокатор.
А с учетом того, что в языках без GC много объектов живет тупо на стеке и не требует аллокаций/деаллокаций, то все еще менее страшно.

K>А чем богатеет токсичное сообщество мелкобукв обиженных на научно технический прогресс?

Было бы интересно узнать из каких слов следует "обиженных на научно-технический прогресс", но вы ведь в очередной раз с конкретикой отморозитесь, как это уже случалось в данном разговоре неоднократно.

Можете поискать где бы я ругал GC или доказывал, что ручное управление памятью однозначно лучше, чем GC. Если найдете, то дайте цитату, плз.

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

M>Весь C# — это тоже акой же ручной самописный код котороый может содержать баги и например не освобождать память где требуется вызывая утечку памяти. 100%-й гарантии нет.

можно я тоже в демагогию поиграю

ОС тоже ручной самописный код с багами
процессор тоже не боги сделали

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

K>Вобщем-то так и есть чтобы вы не говорили. Программист располагает переменные в трех классах памяти, соответственно определяет время жизни. Если объект создается динамически вы выбираете для него подходящую обертку shared_ptr, unique_ptr и т.д чем это не управление временем жизни?

Так-то это про что угодно можно сказать. В C# программист выбирает между struct или class, а также должен изучать как устроен и работает GC. Плохо написанный код на C# падает с ошибками памяти — сто раз видел. Получается, что в C# программист управляет временем жизни либо вручную, либо также вручную, но через особый инструмент — GC.

K>А по моим словам не является. Потому что я опираюсь на определения языка и библиотеки. А не на тот факт что язык и библиотеку в одной бумажке описали.

Слушай, operator new — это часть языка. Реализован он с использованием STL чуть менее чем везде. Тот факт, что С++ такой вот гибкий и внём практически всё можно заменить, перегрузить или переписать не заменяет того, что 99.99% программ используют stl даже не прямо, а косвенно через тот же operator new и другое. Всё, язык эволюционировал, stl — это не просто примочка сбоку, которую можно так просто заменить или не использовать. Покажи мне лучше более менее большую программу, которая смогла его избежать. Даже bare metal программы на С++ стараются писать с ней.

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

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

S>>>Это уже давно было доказано экспериментально.
S>>>Чтобы GC не тормозил, ему нужно от 4 раз больше ОП, чем в случае с ручным управлением памятью.

K>>Этим вы можете только восторженных неофитов впечатлить.

S>Неофиты из Apple (ссылку на которых я давал) очень впечатлились от того факта, что у них Java с GC потребляла почти на порядок больше памяти, чем Swift без GC. Но не смотря на то, что факты упрямая вещь, г.Kluev тоже не лыком шит, у него своя реальность, с розовыми очками, через которые видно лишь то, что ему удобно.

Это не факты а их подтасовка. Какой-то отдельно взятый проект неизвестно как написанный. Мало что ли их сдохло на всех языках программирования?

K>>А по факту в системах с неперемещаемой памятью она может фрагментироваться настолько, что свободной памяти полно, а массивчик разместить негде. На 64 бит это конечно малоактуально, а на 32-х исчерпание адресного пространства из-за фрагментации было серьезной проблемой.

S>До тех пор пока в проекты не затаскивали jemalloc, tcmalloc, mimalloc или какой-то заточенный под задачу кастомный аллокатор.
S>А с учетом того, что в языках без GC много объектов живет тупо на стеке и не требует аллокаций/деаллокаций, то все еще менее страшно.

Эта проблема не решается заменой аллокатора. Гарантированное решение — это перемещение памяти, только в С++ для этого придется всю программу перекроить, а в C# дефрагментация работает из коробки.

K>>А чем богатеет токсичное сообщество мелкобукв обиженных на научно технический прогресс?

S>Было бы интересно узнать из каких слов следует "обиженных на научно-технический прогресс", но вы ведь в очередной раз с конкретикой отморозитесь, как это уже случалось в данном разговоре неоднократно.

S>Можете поискать где бы я ругал GC или доказывал, что ручное управление памятью однозначно лучше, чем GC. Если найдете, то дайте цитату, плз.

То что вы здесь раскидываетесь оскорблениями это уже признак интеллектуального фиаско. Что в общем-то неудивительно т.к. С++ принципиально новыми возможностями не прирастает, а больше по синтаксическим кракозябрам специализируется.

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

S>>Неофиты из Apple (ссылку на которых я давал) очень впечатлились от того факта, что у них Java с GC потребляла почти на порядок больше памяти, чем Swift без GC. Но не смотря на то, что факты упрямая вещь, г.Kluev тоже не лыком шит, у него своя реальность, с розовыми очками, через которые видно лишь то, что ему удобно.

K>Это не факты а их подтасовка. Какой-то отдельно взятый проект неизвестно как написанный. Мало что ли их сдохло на всех языках программирования?

Ну почитайте, здесь подробнее: https://habr.com/ru/articles/915130/
Конечно, же, вы бы сделали бы все гораздо лучше. Ага. Все профильные форумы набиты профессионалами высшей пробы.

K>Эта проблема не решается заменой аллокатора.

Вам виднее, конечно же.

S>>Было бы интересно узнать из каких слов следует "обиженных на научно-технический прогресс", но вы ведь в очередной раз с конкретикой отморозитесь, как это уже случалось в данном разговоре неоднократно.

S>>Можете поискать где бы я ругал GC или доказывал, что ручное управление памятью однозначно лучше, чем GC. Если найдете, то дайте цитату, плз.

K>То что вы здесь раскидываетесь оскорблениями это уже признак интеллектуального фиаско.

Т.е. привести какое-то доказательство вы в очередной раз не смогли?

Ожидаемо.

Зачастую человеку, который ведет себя как идиот, проще прямо сказать, что он идиот.

K>Что в общем-то неудивительно т.к. С++ принципиально новыми возможностями не прирастает, а больше по синтаксическим кракозябрам специализируется.

Когда-то C++у пеняли на отсутствие модулей. Модули уже в языке.
Когда-то C++у пеняли на отсутствие короутин. Stackless короутины уже в языке.
Когда-то C++у пеняли на то, что его шаблоны -- это всего лишь макросы на стероидах. Концепты, переводящие С++ые шаблоны на новый уровень, уже в языке.
Когда-то C++у пеняли на отсутствие контрактов. Контракты уже вошли в C++26.
С++у продолжают пенять на отсутствие рефлексии. Рефлексию стараются завезти в C++26.
С++у продолжают пенять на отсутствие паттерн-матчинга. Есть шансы получить его в C++29.

Язык за последние 4-5 лет развивается так, что только успевай осваивать новое. Но когда ты г.Kluev с реверсивным интеллектом и альтернативным взглядом на мир, то да, C++ принципиально новыми возможностями не прирастает от слова никак.

Упорства в борьбе с реальностью вам не занимать.

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

S>Зачастую человеку, который ведет себя как идиот, проще прямо сказать, что он идиот.

K>>Что в общем-то неудивительно т.к. С++ принципиально новыми возможностями не прирастает, а больше по синтаксическим кракозябрам специализируется.

S>Когда-то C++у пеняли на отсутствие модулей. Модули уже в языке.
S>Когда-то C++у пеняли на отсутствие короутин. Stackless короутины уже в языке.
S>Когда-то C++у пеняли на то, что его шаблоны -- это всего лишь макросы на стероидах. Концепты, переводящие С++ые шаблоны на новый уровень, уже в языке.
S>Когда-то C++у пеняли на отсутствие контрактов. Контракты уже вошли в C++26.
S>С++у продолжают пенять на отсутствие рефлексии. Рефлексию стараются завезти в C++26.
S>С++у продолжают пенять на отсутствие паттерн-матчинга. Есть шансы получить его в C++29.

S>Язык за последние 4-5 лет развивается так, что только успевай осваивать новое. Но когда ты г.Kluev с реверсивным интеллектом и альтернативным взглядом на мир, то да, C++ принципиально новыми возможностями не прирастает от слова никак.

S>Упорства в борьбе с реальностью вам не занимать.

Это просто смешно читать честно говоря. В паскале модули появились в 1987 году. Всего 33 года Страуструпу потребовалось чтобы умишком пораскинуть.

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

S>Может приведешь пример C++ного проекта, который было бы оправдано переписать на Typescript? (или не переписать, а сделать его аналог)
MSO- переписали на веб.

S>Пользоваться переписанным на TypeScript-е и Web-технологиях Lightroom/CaptureOne могу пожелать только тебе, в наказание за мегатонны вылитой на RSDN тупизны.
Ну вот ты сам привёл ещё пример.

S>И это еще речь не зашла о тяжелых вычислениях, встраиваемых системах и реальном времени.
Вычисления бегают в WASM , WebGPU.
Встройки и RT- да, но там C ещё лучше. Я далеко от железок и ты тоже.

S>В общем, в своей современной реальности я не вижу где и как TypeScript может заменить С++.
Ты строчишь посты в веб на рсдн. Сложно представить? Интернет банк- только веб, никто не будет устанавливать прилагу на десктоп ради этого.

У C++ есть ещё ниши, их там тестит вот Rust например. Я считаю, что пусть растаманы пишут новые прилаги, а не пытаются переписать старые работающие, да ещё и на хуже качество.

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

K>В паскале модули появились в 1987 году.

Всего-то через 17 лет после появления самого Паскаля. И кого это сейчас волнует?

В Java дженерики появились через восемь или девять лет после выхода Java 1.0. И кого это сейчас волнует?

K>Всего 33 года Страуструпу потребовалось чтобы умишком пораскинуть.

"То что вы здесь раскидываетесь оскорблениями это уже признак интеллектуального фиаско." (с) г.Kluev

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

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

S>>Может приведешь пример C++ного проекта, который было бы оправдано переписать на Typescript? (или не переписать, а сделать его аналог)
Аё>MSO- переписали на веб.

MSO -- это Microsoft Office?
Если так, то хотелось бы пруфов, поскольку в сети валялся доклад разработчиков из MS о том, что там кодовая база на С++ с мохнатых годов, которая была адаптирована в том числе и под Web.

S>>Пользоваться переписанным на TypeScript-е и Web-технологиях Lightroom/CaptureOne могу пожелать только тебе, в наказание за мегатонны вылитой на RSDN тупизны.
Аё>Ну вот ты сам привёл ещё пример.

Да чтоб ты всю жизнь пользовался Web-приложениями для обработки фото.
Когда приносишь со съемки 1000-1500-2000 фото, то даже десктопный Lightroom слишком тормозной для первичной выбраковки. А если еще умельцы, вроде тебя, его внутрь Хрома засунут, то вааще ахтунг будет.

S>>И это еще речь не зашла о тяжелых вычислениях, встраиваемых системах и реальном времени.
Аё>Вычисления бегают в WASM , WebGPU.

На кластерах из тысяч вычислительных нод?

Аё>Встройки и RT- да, но там C ещё лучше.

И тут бы пруфов, что Си ещё лучше. Куча эбедеда уже разрабатывается на C++, а местами уже и на Rust. Статьи на эту тему регулярно попадаются.

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

Через браузер написанный на C++ использующим виртуальную машину JS-а, написанную на С++, в KDE, написанном на C++, в Linux-е, ядро которого написано на GNU-диалекте Си.

Аё>Сложно представить?

Да, мне очень сложно представить все это хозяйство на TypeScript.

Аё>Интернет банк- только веб, никто не будет устанавливать прилагу на десктоп ради этого.

Так клиентов для подобных вещей и раньше не особо на C++ разрабатывали. Это как бы и не ниша для C++.

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

Так ты примеры приведешь что такого в sudo-rs "поломали", что мешает тебе жить?

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	18.06.25 02:37
Оценка:

От:	so5team	https://stiffstream.com
Дата:	18.06.25 03:41
Оценка:

	От:	dsorokin
	Дата:	18.06.25 03:53
	Оценка:

От:	so5team	https://stiffstream.com
Дата:	18.06.25 04:00
Оценка:	2 (2)

	От:	Kluev
	Дата:	18.06.25 05:00
	Оценка:

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	18.06.25 11:37
Оценка:

От:	Артём	жж
Дата:	19.06.25 03:02
Оценка: