The new sudo-rs is being developed by Trifecta Tech Foundation (TTF), which is a “nonprofit organization that creates secure, open-source building blocks for infrastructure software.” In a recent blog, the organization spoke about “memory-safe sudo” (which is sudo-rs).
less is more" approach: some features of the original sudo will not be implemented in sudo-rs if they serve only highly niche use cases. The maintainers continue their collaboration with Todd Miller, the incumbent sudo maintainer for over thirty years,
Смузихлёбы ниасилили feature-parity, но лезут туда, куда их не просили.
Здравствуйте, so5team, Вы писали:
S>А может и гранта вообще нет.
Тогда зачем на этот проект менять sudo? Максимум, добавить альтернативу. Оно конечно можно сказать, что никто никому ничего не должен, но это уже какой-то тренд выходит.
Re[11]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, dsorokin, Вы писали:
S>>Еще один момент: мне не нравятся некоторые принятые решения. Например, то, что сделали с deducing this. Или предлагаемый сейчас синтаксис для рефлексии с оператором "баян" (т.е. [:|||:]). ИМХО, у кого-то в комитете нет ни чувства стиля, ни чувства меры.
D>О, я вот за этим поездом не поспел. Про оператор "баяна" еще не в курсе.
Вот здесь можно насладиться этим зрелищем и, заодно, увидеть каким будет "современный C++" через пару-тройку лет:
Здравствуйте, so5team, Вы писали:
S>Тебе то какой дело? S>На своем ноуте больше не можешь запускать sudo с каким-то экзотическим ключиком?
У sudo не так уж много ключиков, сейчас проверил: 30 штук всего. Можно было бы и постараться реализовать все, а не делать за других выводы, что потребности в колбасе в ключах нет. Тем более, это не с нуля реализовывать, всегда можно посмотреть как на Си написано. А если некоторые вещи из-за особенностей rust настолько нельзя просто так переписать с Си, что приходится какие-то фичи оставить нереализованными, то возникают вопросы к пригодности раста как системного.
Re: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>И хвала всевышнему, куча народа имеет возможность зарабатывать на жизнь программизмом не заботясь о вопросах управления памятью и пр. Вопрос в том, что делать с другими задачами, где нужна не только скорость, но и предсказуемость, и контроль за потреблением ресурсов. С простым ответом: не использовать там языки с GC. Так происходит на протяжении полувека, и так же будет происходить и дальше.
Попытаюсь немного убавить градус вашей дискуссии.
А что ты думаешь об эрланге? Я прочитал пару книг по нему и еще по эликсиру. Выглядит очень и очень интересно (я тут запоздал лет на 15). Они заявляют о "мягком режиме реального времени" в языке со сборкой мусора. Ты ведь увлекался ФП. Какие мысли по эрлангу? Понимаю, что язык нишевый и узкоспециализированный.
И кстати, заодно. А что ты думаешь о современных тенденциях в проектировании C++? Не слишком усложняют язык? Я видел многих, кто его использует, максимум, как С++11 с мелкими элементами из C++17, не более. Не отпугивает, что С++ все усложняют и усложняют? К чему это может привести? Не пора ли провести ревизию?
Re[15]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, 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>MSO -- это Microsoft Office? S>Если так, то хотелось бы пруфов, поскольку в сети валялся доклад разработчиков из MS о том, что там кодовая база на С++ с мохнатых годов, которая была адаптирована в том числе и под Web.
В новостях в 2020 ещё было, что оставят только веб версию для всего — и "десктоп" будет обёртка над веб.
S>Когда приносишь со съемки 1000-1500-2000 фото, то даже десктопный Lightroom слишком тормозной для первичной выбраковки. А если еще умельцы, вроде тебя, его внутрь Хрома засунут, то вааще ахтунг будет.
М.б. вопрос к криворуким разработчикам десктопного Lightroom?
S>>>И это еще речь не зашла о тяжелых вычислениях, встраиваемых системах и реальном времени. Аё>>Вычисления бегают в WASM , WebGPU.
S>На кластерах из тысяч вычислительных нод?
Нейросетки компьютерного зрения бегают в WASM , WebGPU в т.ч. на смартфоне. Это что я лично прикрутил (примотал изолентой ) в веб ui.
S>И тут бы пруфов, что Си ещё лучше. Куча эбедеда уже разрабатывается на C++
Упоротыми. S> а местами уже и на Rust.
И это печально.
S>>>В общем, в своей современной реальности я не вижу где и как TypeScript может заменить С++. Аё>>Ты строчишь посты в веб на рсдн.
S>Через браузер написанный на C++ использующим виртуальную машину JS-а, написанную на С++, в KDE, написанном на C++, в Linux-е, ядро которого написано на GNU-диалекте Си.
Кстати о KDE Которое тормозное тупо потому, что C++.
S>Да, мне очень сложно представить все это хозяйство на TypeScript.
Жирный десктопный UI прекрасно бегает в веб. Если ты неосилил- то вопросы к тебе.
S>Так клиентов для подобных вещей и раньше не особо на C++ разрабатывали. Это как бы и не ниша для C++.
Проблема доя C++ разработчиков — это нишевый язык. Ну, ппомимо того, что из него сделали ужас.
Аё>>Я считаю, что пусть растаманы пишут новые прилаги, а не пытаются переписать старые работающие, да ещё и на хуже качество.
S>Так ты примеры приведешь что такого в sudo-rs "поломали", что мешает тебе жить?
Ты по кругу ходишь. Я указал- неосилили feature parity.
Re[18]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Sinclair, Вы писали:
S>>Возможно, нужно было бы пойти по ссылками и прочитать хотя бы поверхносные описания? S>Возможно. Но я читаю форум в прямом порядке, а не задом наперёд.
Тогда непонятно как можно было пропустить ссылки, которые шли до того, как вы решили высказать свое веское (нет) мнение.
S>>Ну просто шикарное подтверждение тезиса о скорости и других преимуществах GC. Браво! S>Нет. К скорости это имеет косвенное отношение. Мы обсуждаем расход памяти, за который критикуют GC.
Вы -- может быть.
Конкретно же было сказано следующее: "Чтобы GC не тормозил, ему нужно от 4 раз больше ОП, чем в случае с ручным управлением памятью"
Т.е. для достижения высокой скорости GC нужно больше памяти. Одно с другим тесно увязано.
S>И тут начинается интересное:
Простите, не интересно. Ваше мнение, как одного из евангелистов .NET-а в прошлом, не интересно особенно.
Re: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Артём, Вы писали:
Аё>Смузихлёбы ниасилили feature-parity, но лезут туда, куда их не просили.
Аё>Не можешь ##ать- не мучай ###у.
Тёмчик собака лает, караван идет.
В кои-то веки появилась реальная вменяемая альтернатива ламповой сишечке для системного программирования. И мало того, эту альтернативу начинают реально применять в том же Linux-е. Но безмозглые горлопаны, кодящие на вебчик на TypeScript-е, почему-то встрепенулись и зубоскалят.
Тебе то какой дело?
На своем ноуте больше не можешь запускать sudo с каким-то экзотическим ключиком?
Re[5]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Michael7, Вы писали:
M>Тогда зачем на этот проект менять sudo?
Чтобы выбросить Си-шное говно наследие пораньше?
M>Максимум, добавить альтернативу.
Может обратиться к первоисточнику:
Canonical has promised to keep the original sudo in the archive repositories, so that anyone who wants to roll back to plain old sudo will be able to do so without much hassle.
Re[4]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Да и вообще писал ли ты на чистом Си что-то сложнее HelloWorld-а?
Писал часть модуля для продакшена- платформо-зависимый нативный кусочек, который вызывался из ооп-го апплета. Правил код прошивки девайса
Аё>>С++ был прекрасен на заре (Си с классами + шаблоны), пока из него не наворотили всемогутора-из-костылей.
S>Тёмчик опять затрындел о том, в чем не разбирается.
Я писал на плюсах- тогда никто не жаловался, даже наоборот.
S>a) это не ответ на вопрос о том, какого этого самого тебе до переписывания sudo на Rust?
Мне не нравится, когда неосиляторы лезут своими кривыми грязными ручонками и ломают то, что уже работает. Отрезают фичи по ниасилили, глючит больше == ломают. Пусть напишут что-то полезное своё, там поговорим о хорошечти инструмента Rust
S>b) к какому такому слову твой пример о том, что вы там что-то на TypeScript переписали, если речь о Rust-а и системщине?
К тому Ъ что если уж взялся переписывать — не изговняй, а сделай ещё лучше и фичастее, чем легаси. А иначе кривые ручки прочь.
Аё>>А что делал ты- поддерживал суровое легаси на вышедшем из массового употребления языке?
S>В очередной раз ткнул Тёмчика в то, что он Тёмчик.
Здравствуйте, Kluev, Вы писали:
S>>Звучит как приговор для чистого Си.
K>И для Си в том числе.
Ну вот Си и закапывают, в том числе и посредством Rust-а.
S>>У вас уже есть статистика, подтверждающая, что с приходом ИИ в проектах на чистом Си стало меньше багов и уязвимостей. Ведь есть же, да?
K>А куда вы так спешите?
Я не спешу, просто интересно, на чем делать проекты пока это щастливое будущее с заглавной буквы Ща еще не наступило. И так, чтобы не "собирать корки по утрам".
K>Очевидно же что в конечном итоге победит язык который сможет как можно больше переложить на ИИ наиболее эффективным способом.
Вам, может быть, и очевидно. Впрочем, альтернативно одаренным много чего очевидно, плохо только, когда вы субстанцию из своей головы на просторы интернета выплескиваете. Тот же ИИ как раз на ваших испражнениях и обучается, что не позволяет так уж сильно на него надеятся.
K>Руст и прочие языки в которых программист вынужден управлять временем жизни каждой переменной уже не нужны.
Да, да. Языки с GC уже лет семьдесят доказывают, что еще чуть чуть и они перестанут тормозить.
Только вот сюрприз, в тех же С++, Rust и Ada не нужно управлять временем жизни каждой переменной вручную. Но зачем тов.Kluev об этом задумываться, если можно просто очередную порцию бреда высрать на публику.
Re[6]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>>>Да и вообще писал ли ты на чистом Си что-то сложнее HelloWorld-а? Аё>>Писал часть модуля для продакшена- платформо-зависимый нативный кусочек, который вызывался из ооп-го апплета. Правил код прошивки девайса
S>Т.е. не писал.
Перечитай ещё раз написанное мной. Потом ещё раз, внимательно.
Аё>>>>С++ был прекрасен на заре (Си с классами + шаблоны), пока из него не наворотили всемогутора-из-костылей.
S>>>Тёмчик опять затрындел о том, в чем не разбирается. Аё>>Я писал на плюсах- тогда никто не жаловался, даже наоборот.
S>Судить о современном С++ на основании хз какого опыта 20-летней давности, ну такое себе. Тёмчик еще раз доказал, что он Тёмчик.
Ну так "современный C++" это всемогутор мз костылей.
S>>>a) это не ответ на вопрос о том, какого этого самого тебе до переписывания sudo на Rust? Аё>>Мне не нравится, когда неосиляторы лезут своими кривыми грязными ручонками и ломают то, что уже работает.
S>На твоей работе это как-то сказалось?
Что ты докопался до моей работы? Да я пользуюсь sudo, причём не только по работе.
S>В самом sudo они что-то поломали?
Да, они поломали часть фич.
S>Эти ребята делают свой sudo-rs и другие ребята думают, что sudo-rs дает им больший коэффициент спокойного сна.
Лишь бы следующим шагом не подменили нормалтный судо на калечный.
Аё>>Отрезают фичи по ниасилили
S>Что из того, что они "ниасилили" сказывается на твоей работе?
Мне, как польщователю линух со стажем, не нравится что лезут кривыми ручонками неосиляторы
Аё>>глючит больше == ломают
S>Что в sudo-rs глючит?
Фичи, которые это криворукие смузихлёбы ниасиоили === поломали.
Re[6]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Ну вот Си и закапывают, в том числе и посредством Rust-а.
Все до ИИ языки закопают со временем. Как паровые машины. И руст одним из первых.
S>Я не спешу, просто интересно, на чем делать проекты пока это щастливое будущее с заглавной буквы Ща еще не наступило. И так, чтобы не "собирать корки по утрам".
Вам совет дать или это вопрос риторический?
K>>Очевидно же что в конечном итоге победит язык который сможет как можно больше переложить на ИИ наиболее эффективным способом.
S>Вам, может быть, и очевидно. Впрочем, альтернативно одаренным много чего очевидно, плохо только, когда вы субстанцию из своей головы на просторы интернета выплескиваете. Тот же ИИ как раз на ваших испражнениях и обучается, что не позволяет так уж сильно на него надеятся.
Кто вам мешает обучать на своих?
K>>Руст и прочие языки в которых программист вынужден управлять временем жизни каждой переменной уже не нужны.
S>Да, да. Языки с GC уже лет семьдесят доказывают, что еще чуть чуть и они перестанут тормозить.
Это все узколобое сектантство. Во многих задачах языки с GC уже быстрее языков с ручным управлением.
S>Только вот сюрприз, в тех же С++, Rust и Ada не нужно управлять временем жизни каждой переменной вручную. Но зачем тов.Kluev об этом задумываться, если можно просто очередную порцию бреда высрать на публику.
Эти сказки вы рассказывайте восторженным неофитам. С++ вам дает только голенький указатель, а управляете вы им с помощью костылей из stl которая частью языка не является.
Re[8]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>Все до ИИ языки закопают со временем.
S>"Это все узколобое сектантство." (c) некто Kluev
Это прогноз.
S>У вас кто-то спрашивал совета? И даже в более общем смысле: вашего мнения здесь кто-то спрашивал? Это вы зачем-то здесь объявились со своим ИИ-мессианством.
А вашего кто спрашивал? не видел чтобы вас кто-то звал в тред.
K>>Это все узколобое сектантство. Во многих задачах языки с GC уже быстрее языков с ручным управлением.
S>И хвала всевышнему, куча народа имеет возможность зарабатывать на жизнь программизмом не заботясь о вопросах управления памятью и пр. Вопрос в том, что делать с другими задачами, где нужна не только скорость, но и предсказуемость, и контроль за потреблением ресурсов. С простым ответом: не использовать там языки с GC. Так происходит на протяжении полувека, и так же будет происходить и дальше.
Это ваше большое заблуждение, что GC сделали ради упрощения языка специально для неосиляторов. Без GC и JIT не будет работать компонентная модель, не будут работать некоторые lock free алогритмы основанные на том, что простое присваивание позволяет забыть указатель (В с++ не реализуемо) и другие вещи. Многие вещи которые можно сделать например на C# в языке C++ просто не реализуемы.
S>>>Только вот сюрприз, в тех же С++, Rust и Ada не нужно управлять временем жизни каждой переменной вручную. Но зачем тов.Kluev об этом задумываться, если можно просто очередную порцию бреда высрать на публику.
S>Для неасиляторов вопрос: покажите мне здесь хоть один голенький указатель. Ну и ручное управление памятью заодно. S>
#include <iostream>
S>}
К любой переменной вашего примера примените оператор & и у вас будет голый указатель. Более того сам язык другие и не поддерживает.
K>> а управляете вы им с помощью костылей из stl которая частью языка не является.
S>У стандарта C++ на этот счет прямо противоположное мнение.
стандарт языка С++ определяет сам язык и стандартную библиотеку. Очевидно же, что стандартная библиотека частью языка не является. Компилятор за исключением классов type_info, std::initializer_list<T>, std::exception вобще не знает о ее существовании.
Re[12]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
S>>>Еще раз вопрос: покажите здесь хоть один голенький указатель и управление памятью.
K>>Так вот же они родимые: K>>
std::cout << "A::f()" << std::endl;
K>>Или по вашему const char[] не голенький указатель?
S>Нет, это const char[7].
Это и есть голенький указатель на строку в сегменте данных.
S>>>А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
Естесвенно. Если рассмотреть эту программу в целом то мы обязательно найдем ручной самописный код в деструкторе или еще где который вручную освобождает память. Какая разница кем это написано вами или авторами стандартной библиотеки? Чтобы не было ручного управления памятью вам нужно использовать только статическую или автоматическую память. Но вы используете iostream, а он выделяет динамическую память как минимум на буффер:
> ucrtbased.dll!free(void * block) Line 19 C++
msvcp140d.dll!std::_Crt_new_delete::operator delete(void * _Ptr) Line 47 C++
msvcp140d.dll!std::locale::`scalar deleting destructor'(unsigned int) C++
msvcp140d.dll!std::basic_streambuf<wchar_t,std::char_traits<wchar_t>>::~basic_streambuf<wchar_t,std::char_traits<wchar_t>>() Line 68 C++
msvcp140d.dll!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>>::~basic_filebuf<wchar_t,std::char_traits<wchar_t>>() Line 183 C++
msvcp140d.dll!std::`dynamic atexit destructor for 'wfout''() C++
ucrtbased.dll!_execute_onexit_table::__l2::<lambda>() Line 206 C++
ucrtbased.dll!__crt_seh_guarded_call<int>::operator()<void <lambda>(void),int <lambda>(void) &,void <lambda>(void)>(__acrt_lock_and_call::__l2::void <lambda>(void) && setup, _execute_onexit_table::__l2::int <lambda>(void) & action, __acrt_lock_and_call::__l2::void <lambda>(void) && cleanup) Line 204 C++
ucrtbased.dll!__acrt_lock_and_call<int <lambda>(void)>(const __acrt_lock_id lock_id, _execute_onexit_table::__l2::int <lambda>(void) && action) Line 980 C++
ucrtbased.dll!_execute_onexit_table(_onexit_table_t * table) Line 231 C++
msvcp140d.dll!__scrt_dllmain_uninitialize_c() Line 398 C++
msvcp140d.dll!dllmain_crt_process_detach(const bool is_terminating) Line 182 C++
msvcp140d.dll!dllmain_crt_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 220 C++
msvcp140d.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 293 C++
msvcp140d.dll!_DllMainCRTStartup(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 335 C++
ntdll.dll!00007ffefd7e9a1d() Unknown
ntdll.dll!00007ffefd82f1ca() Unknown
ntdll.dll!00007ffefd82ef7d() Unknown
kernel32.dll!00007ffefd6de3eb() Unknown
ucrtbased.dll!exit_or_terminate_process(const unsigned int return_code) Line 144 C++
ucrtbased.dll!common_exit(const int return_code, const _crt_exit_cleanup_mode cleanup_mode, const _crt_exit_return_mode return_mode) Line 282 C++
ucrtbased.dll!exit(int return_code) Line 294 C++
ConsolePP.exe!__scrt_common_main_seh() Line 295 C++
ConsolePP.exe!__scrt_common_main() Line 331 C++
ConsolePP.exe!mainCRTStartup(void * __formal) Line 17 C++
S>>>Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
K>>Естественно что библиотека не является частью языка
S>Именно поэтому она описана в стандарте языка, ясно-понятно.
То что библиотека где-то описана не делает ее языком. просто потому, что это разные вещи по определению.
Re[14]: #огда коту нечего делать- он пишет sudo на Rust
S>>>Нет, это const char[7]. K>>Это и есть голенький указатель на строку в сегменте данных.
S>Когда кажется, что вы уже достигли дна, то вы старательно начинаете копать.
S>Давайте вам поможем взять новую глубину и возьмем простой пример на C#: S>
S>Полагаете, использованный здесь строковый литерал не будет затем использован как "голенький указатель на строку в сегменте данных"? S>Может он где-то в libastral окажется?
Здесь строковый литерал превратится в объект string и управлять временем жизни этого обьекта программисту не придется.
Т.е. этот char[7] может спокойно принадлежать к любому классу памяти. И после этого вы не утверждаете, что это не голенький указатель? Может быть он не голый в терминологии С++ т.к. имеет модификаторы const и т.п но вы должны понимать что собеседники совершенно не обязаны знать нюансы плюсовой терминологии.
K>>Какая разница кем это написано вами или авторами стандартной библиотеки?
S>Громадная.
И в чем громадная? стандартная библиотека это такой же ручной самописный код котороый может содержать баги и например не освобождать память где требуется вызывая утечку памяти. 100%-й гарантии нет.
S>Так как вы любите пробивать дно, то попробуйте рассказать, как сделать средствами языка std::launder, например. S>Или std::source_location. S>Или как компилятору не знать про std::memory_order. S>Или как компилятор узнает, что std::malloc начинает life-time для объекта.
когда средствами языка нельзя будет сделать например vector тогда обращайтесь. то что нельзя сделать средствами языка является частью языка по определению, а то что делается средствами языка — отдельная библиотечная функциональность которая языком не является. В компиляторах даже опция есть. собирать программу без стандартных библиотек.
Re[10]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Я вынужден согласиться с той точкой зрения, что если С++ не устраивает, то спокойно можно выбрать другой современный (или не очень) язык. Хороший выбор среди управляемых языков с GC: C#, Java, Kotlin, Go + Scala/OCaml/Haskell
Java это новый COBOL- это legacy, которые везде в бизнес-приложениях. Почему ты не упомянул Typescript? Ведь можно сколько угодно отпираться, но веб это де-факто UI уже лет 15 как, когда не хочешь геморрой с поддержкой зоопарка платформ. По производительности- хром подтянулся и железо подтянулось.
Re[11]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Артём, Вы писали:
S>>Я вынужден согласиться с той точкой зрения, что если С++ не устраивает, то спокойно можно выбрать другой современный (или не очень) язык. Хороший выбор среди управляемых языков с GC: C#, Java, Kotlin, Go + Scala/OCaml/Haskell
Аё>Java это новый COBOL- это legacy, которые везде в бизнес-приложениях. Почему ты не упомянул Typescript? Ведь можно сколько угодно отпираться, но веб это де-факто UI уже лет 15 как, когда не хочешь геморрой с поддержкой зоопарка платформ. По производительности- хром подтянулся и железо подтянулось.
Вроде бы обсуждаются языки для взрослых людей и серьёзных применений, а не нишевые приколы для смузихлёбов-формошлёпов
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>Здесь строковый литерал превратится в объект string и управлять временем жизни этого обьекта программисту не придется.
S>Покажите мне, где в моем примере на C++ программисту нужно управлять временем жизни задействованных в коде литералов.
У вас в примере все переменные статические и автоматические. То что язык управляет статической-автоматической памятью это не удивительно. Есть ли в природе языки которые этого не делают? А все остальное в С++ делается ручкам, да язык вызывает деструктор если объект уходит из область видимости, но подчищать динамическую память в деструкторах нужно ручками. И тут абсолютно никакой разницы какие руки это написали. ваши или те кто писал стандартную библиотеку.
K>>И в чем громадная?
S>Хотя бы в том, что часть стандартной библиотеки может быть написана на совсем другом языке.
И что это меняет?
S>Разговорчивый вы мой, ни одно из ваших словесных испражнений не может перебить того факта, что есть официальный стандарт языка C++, в котором описана и его стандартная библиотека. И нет официальных документов, которые бы описывали язык C++ отдельно как некий язык, частью которого не была бы STL.
S>Продолжите и дальше демонстрировать свое альтернативное восприятие реальности?
По вашим словам библиотека — это язык потому, что так написано якобы в какой-то бумажке. Что могу сказать? Живите с этим дальше.
Re[10]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, 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 функциональность на шарпе с совершенно недостижимой на с++ производительностью.
Re[11]: #огда коту нечего делать- он пишет sudo на Rust
Перевод данной конкретной системы на Swift, по оценке разработчиков, позволил добиться 50-процентной экономии вычислительных ресурсов, снижения потребления памяти на 90% и 40-процентного повышения пропускной способности.
K>Думаю если задаться целью можно написать lock free функциональность на шарпе с совершенно недостижимой на с++ производительностью.
Дурень думкой богатеет.
Re[14]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, 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. Если найдете, то дайте цитату, плз.
То что вы здесь раскидываетесь оскорблениями это уже признак интеллектуального фиаско. Что в общем-то неудивительно т.к. С++ принципиально новыми возможностями не прирастает, а больше по синтаксическим кракозябрам специализируется.
Re[16]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, 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 года Страуструпу потребовалось чтобы умишком пораскинуть.
Re[12]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Может приведешь пример C++ного проекта, который было бы оправдано переписать на Typescript? (или не переписать, а сделать его аналог)
MSO- переписали на веб.
S>Пользоваться переписанным на TypeScript-е и Web-технологиях Lightroom/CaptureOne могу пожелать только тебе, в наказание за мегатонны вылитой на RSDN тупизны.
Ну вот ты сам привёл ещё пример.
S>И это еще речь не зашла о тяжелых вычислениях, встраиваемых системах и реальном времени.
Вычисления бегают в WASM , WebGPU.
Встройки и RT- да, но там C ещё лучше. Я далеко от железок и ты тоже.
S>В общем, в своей современной реальности я не вижу где и как TypeScript может заменить С++.
Ты строчишь посты в веб на рсдн. Сложно представить? Интернет банк- только веб, никто не будет устанавливать прилагу на десктоп ради этого.
У C++ есть ещё ниши, их там тестит вот Rust например. Я считаю, что пусть растаманы пишут новые прилаги, а не пытаются переписать старые работающие, да ещё и на хуже качество.
Re[15]: #огда коту нечего делать- он пишет sudo на Rust
K>Это не факты а их подтасовка. Какой-то отдельно взятый проект неизвестно как написанный. Мало что ли их сдохло на всех языках программирования?
Возможно, 80% экономии памяти бы дало переписывание с Java на Java.
Если, к примеру, взять махровое легаси, написанное для Java 1.2, где банальный разбор HTTP-запроса состоит из постоянных копирований строк с перевыделениями, и переписать на современную версию с zero-allocation парсерами примитивных типов, то примерно так и получится.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Возможно, нужно было бы пойти по ссылками и прочитать хотя бы поверхносные описания?
Возможно. Но я читаю форум в прямом порядке, а не задом наперёд.
S>Ну просто шикарное подтверждение тезиса о скорости и других преимуществах GC. Браво!
Нет. К скорости это имеет косвенное отношение. Мы обсуждаем расход памяти, за который критикуют GC.
И тут начинается интересное:
1. Если мы говорим об одинаковых алгоритмах, то детерминистическая финализация начинает сливать GC в "общем" случае. Потому что общий случай — это дорогой thread-safe аллокатор с поиском свободного места и небесплатный деаллокатор. Да, я в курсе, что высококвалифицированный разработчик, идентифицировав такую проблему, может её нивелировать при помощи custom arena-based allocator, но это как раз и есть "вручную следить за временем жизни каждой ссылки".
2. Если мы говорим о том, что где-то можно заменить алгоритмы с динамическим выделением памяти на стековое выделение, то в современном управляемом мире у нас опять же два подхода — escape analysis (Java) и Value-типы (.Net). Можно пытаться критиковать первый за ненадёжность, а второй — за "рукопашность", но с точки зрения прикладного разработчика примерно оба хороши. В том смысле, что о вопросах вроде "делать ли мне вот этот тип struct или class" задумывается разработчик платформы. А прикладник просто берёт, что дают, и едет. Не принимая решения в каждой точке, то ли делать auto pF = new F(42) try {} finally {free pF}, то ли просто auto f = F(42);. Потому что "и так и так правильно". S>Оказывается, чтобы было быстро и не ресурсоемко, требуется zero-allocation парсеры. Вот прям раскрытие GC во всей красе.
3. Zero allocation не имеет никакого отношения к GC. Это вопрос алгоритмики. Просто исторически так сложилось, что C/C++ программисты мыслят о строках в категориях "указатель на массив символов". Поэтому примерно любая, даже высокоуровневая библиотека ездит на тех же примитивах. Ну, вот например: https://learn.microsoft.com/en-us/cpp/atl-mfc-shared/reference/coledatetime-class?view=msvc-170#parsedatetime
(это, кстати, к вопросу "откуда в программе на C++ возьмутся сырые указатели")
Так вот — если я буду парсить заголовки HTTP при помощи даже такой библиотеки, мне придётся обеспечить наличие \0 в нужном месте. Прямолинейный идиоматический способ тут — использовать что-то вроде CString::Mid, который — ай!ой! — вызывает точно такую же аллокацию, как и банальная Java (только медленную, см. выше).
Для того, чтобы это починить, я буду либо писать хитрый код, который на ходу вставляет \0 вместо \r (и нести ответственность за разрушение исходной строки), либо возьму напишу версию ParseDateTime, которая умеет вместо поисков \0 принимать nCount (или, ещё лучше, какой-то вариант span<char>).
Внезапно, это именно то, что делают Java и .Net. То есть получается, что нет никакой разницы между ручной и автоматической сборкой мусора — в обоих подходах можно написать одинаково неудачный код (и одинаково удачный).
Ну, а дальше начинает стрелять то, что код с аллокацией, несмотря на дешёвую аллокацию, получает штраф к производительности второго порядка малости из-за увеличения частоты GC.
S>Такими темпами места для языков с ручным управлением памятью точно не останется.
Ну, примерно так оно и есть. Если в "старых" подходах идиоматические решения на дотнет/джава потребляли память и тормозили, что стимулировало разработчиков вздыхать и переходить в неуютный мир Manual Memory Management, то сейчас ситуация плавно улучшается. Часть выигрыша достаётся бесплатно — благодаря улучшению существующих библиотечных функций. Часть требуют переработки исходного кода (например, переход от string.Substring к ReadOnlySpan<byte>.Slice). Но в любом случае ниша для "давайте потратим x100 ресурсов на выпиливание на С++ чтобы получить +6% перформанса и -15% памяти" постепенно сокращается.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, scf, Вы писали:
S>>На своем ноуте больше не можешь запускать sudo с каким-то экзотическим ключиком?
scf>Люди-то может и переживут, а огромное количество уже написанных скриптов?
Если огромное количество скриптов использует некий экзотический ключ/фичу, то это уже не экзотический ключ/фича.
И, если это действительно будет критично, то новую реализацию допилят.
Re[3]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Michael7, Вы писали:
M>У sudo не так уж много ключиков, сейчас проверил: 30 штук всего. Можно было бы и постараться реализовать все, а не делать за других выводы, что потребности в колбасе в ключах нет. Тем более, это не с нуля реализовывать, всегда можно посмотреть как на Си написано. А если некоторые вещи из-за особенностей rust настолько нельзя просто так переписать с Си, что приходится какие-то фичи оставить нереализованными, то возникают вопросы к пригодности раста как системного.
Или вопрос в том, кто будет платить за реализацию ключей, которые не нужны в 95% случаев.
Типа есть грант на N денег, в рамках этого гранта можно реализовать 90% фич старого sudo.
А может и гранта вообще нет.
Re[3]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, scf, Вы писали:
S>>На своем ноуте больше не можешь запускать sudo с каким-то экзотическим ключиком?
scf>Люди-то может и переживут, а огромное количество уже написанных скриптов?
Ничего-ничего. В кои-то веки найдётся работа и для системщиков, а не только для реализации идиотской бизнес-логики по запросам идиотов в идиотской среде no-code.
Re: #огда коту нечего делать- он пишет sudo на Rust
У sudo главная проблема — шизанутый язык sudoers и глючный парсер. Я неоднократно натыкался, что применение ключа NOPASSWD мистически зависит от порядка записей в секции, от добавления/удаления фиктивных и т.п.
И вообще он писался во времена, когда это сообщество только начинало понимать, зачем нужен хороший стиль кода, тестируемость по частям и прочие хорошие известные сейчас традиции. Читать его код — просто ужасно. Есть, конечно, примеры и похуже, но не так много.
Так что кто там чего не осилил — вопрос, мягко говоря, спорный;\
И вот тут наличие написанной полностью с нуля альтернативы очень помогает — тем, что в ней проблем было меньше. На C никто такого не собрался написать, а если делают на Rust — хорошо, пусть будет на Rust. Заодно, может, новых идей породят. Я поддерживаю.
The God is real, unless declared integer.
Re[2]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>В кои-то веки появилась реальная вменяемая альтернатива ламповой сишечке для системного программирования. И мало того, эту альтернативу начинают реально применять в том же Linux-е.
Ну почему же. Go вырос до приличного на несколько лет раньше.
Systemd, например, следовало изначально писать именно на нём.
И проблемы у обоих примерно одинаковы (толстый бинарь и запрет на некоторые привычные приёмы вроде иерархии классов — но для их ниш это обычно несущественный минус).
Мне параллельность разработки нравится.
Вот что ещё следовало бы на него перенести в первую очередь — это openssh. Текущий ужасен и глючен.
The God is real, unless declared integer.
Re[2]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, netch80, Вы писали:
N>У sudo главная проблема — шизанутый язык sudoers и глючный парсер.
Ну так пофиксить / переписать парсер неужели так сложно, если это действительно кому-то важно?
N>Так что кто там чего не осилил — вопрос, мягко говоря, спорный;\
Смузихлёбы ниасилили feature parity.
N>И вот тут наличие написанной полностью с нуля альтернативы очень помогает — тем, что в ней проблем было меньше.
Вот эта вот тенденция бесит честно говоря. "X — говно, поэтому мы напишем свой Mir" — Canonical, 2010 год. Обосрались. Потом типа ладно, не будем вы##ываться, поддержим Wayland. Но и Wayland только к 2025г почти не глючит, надо же — даже невидия осилила выпустить драйвер с поддержкой его.
N> На C никто такого не собрался написать, а если делают на Rust — хорошо, пусть будет на Rust.
Да пусть пишут хоть на бейсике — если фичи не отламываются, а только улучшаются, это же хорошо! Я против рукожопов — неосиляторов, которые свои кривые поделия пытаются пропихнуть, где их не просили.
Re[2]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Тёмчик собака лает, караван идет.
Да, смузихлёбы тянут свои кривые ручонки к чистому Си.
S>В кои-то веки появилась реальная вменяемая альтернатива ламповой сишечке для системного программирования. И мало того, эту альтернативу начинают реально применять в том же Linux-е. Но безмозглые горлопаны, кодящие на вебчик на TypeScript-е, почему-то встрепенулись и зубоскалят.
Си прекрасен. С++ был прекрасен на заре (Си с классами + шаблоны), пока из него не наворотили всемогутора-из-костылей.
S>Тебе то какой дело? S>На своем ноуте больше не можешь запускать sudo с каким-то экзотическим ключиком?
Мы переписали вебчик с ActionScript (вынужденно) на Typescript с полным feature parity и ещё насыпали дофига новых фичей. Так к слову. А что делал ты- поддерживал суровое легаси на вышедшем из массового употребления языке?
Re[3]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Артём, Вы писали:
S>>Тёмчик собака лает, караван идет. Аё>Да, смузихлёбы тянут свои кривые ручонки к чистому Си.
Хде? Может ты путаешь тех смузихлёбов, которые пишут новые стандарты Си и добавляют туда _Generic и пр. с теми смузихлёбами, которые хотят писать системщину на чем-то более вменяемом, чем чистый Си?
S>>В кои-то веки появилась реальная вменяемая альтернатива ламповой сишечке для системного программирования. И мало того, эту альтернативу начинают реально применять в том же Linux-е. Но безмозглые горлопаны, кодящие на вебчик на TypeScript-е, почему-то встрепенулись и зубоскалят.
Аё>Си прекрасен.
Так чтож ты на нем не пишешь?
Да и вообще писал ли ты на чистом Си что-то сложнее HelloWorld-а?
Аё>С++ был прекрасен на заре (Си с классами + шаблоны), пока из него не наворотили всемогутора-из-костылей.
Тёмчик опять затрындел о том, в чем не разбирается.
S>>Тебе то какой дело? S>>На своем ноуте больше не можешь запускать sudo с каким-то экзотическим ключиком? Аё>Мы переписали вебчик с ActionScript (вынужденно) на Typescript с полным feature parity и ещё насыпали дофига новых фичей.
Прекрасно. Только:
a) это не ответ на вопрос о том, какого этого самого тебе до переписывания sudo на Rust?
b) к какому такому слову твой пример о том, что вы там что-то на TypeScript переписали, если речь о Rust-а и системщине?
Аё>А что делал ты- поддерживал суровое легаси на вышедшем из массового употребления языке?
В очередной раз ткнул Тёмчика в то, что он Тёмчик.
Re[2]: #огда коту нечего делать- он пишет sudo на Rust
Результат инерции в индустрии. Свернули не туда, но какое-то время еще будем ехать пока не остановится.
S>В кои-то веки появилась реальная вменяемая альтернатива ламповой сишечке для системного программирования. И мало того, эту альтернативу начинают реально применять в том же Linux-е. Но безмозглые горлопаны, кодящие на вебчик на TypeScript-е, почему-то встрепенулись и зубоскалят.
Она еще толком не появилась, а уже устарела. В ИИ эпоху язык с микроменеджментом вокруг каждого пук-сереньк обречен. Уже сейчас многие вещи пишут на С и доказывают этот код отдельными инструментами. Это и есть образ будущего. Простой язык без микроменеджмента в каждом операторе и поддержкой доказательств с помощью ИИ. А руст это игрушка до первого серьезного рефакторинга, после которого обычно происходит очистка от ржавчины.
Re[5]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Артём, Вы писали:
S>>Да и вообще писал ли ты на чистом Си что-то сложнее HelloWorld-а? Аё>Писал часть модуля для продакшена- платформо-зависимый нативный кусочек, который вызывался из ооп-го апплета. Правил код прошивки девайса
Т.е. не писал.
Аё>>>С++ был прекрасен на заре (Си с классами + шаблоны), пока из него не наворотили всемогутора-из-костылей.
S>>Тёмчик опять затрындел о том, в чем не разбирается. Аё>Я писал на плюсах- тогда никто не жаловался, даже наоборот.
Таким как ты еще 200 лет назад точный диагноз поставили: "Сужденья черпают из забытых газет: Времен очаковских и покоренья Крыма."
Судить о современном С++ на основании хз какого опыта 20-летней давности, ну такое себе. Тёмчик еще раз доказал, что он Тёмчик.
S>>a) это не ответ на вопрос о том, какого этого самого тебе до переписывания sudo на Rust? Аё>Мне не нравится, когда неосиляторы лезут своими кривыми грязными ручонками и ломают то, что уже работает.
На твоей работе это как-то сказалось?
В самом sudo они что-то поломали?
Эти ребята делают свой sudo-rs и другие ребята думают, что sudo-rs дает им больший коэффициент спокойного сна.
Аё>Отрезают фичи по ниасилили
Что из того, что они "ниасилили" сказывается на твоей работе?
Аё>глючит больше == ломают
Что в sudo-rs глючит?
Re[3]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>В ИИ эпоху язык с микроменеджментом вокруг каждого пук-сереньк обречен.
S>Звучит как приговор для чистого Си.
И для Си в том числе.
K>>Простой язык без микроменеджмента в каждом операторе и поддержкой доказательств с помощью ИИ.
S>У вас уже есть статистика, подтверждающая, что с приходом ИИ в проектах на чистом Си стало меньше багов и уязвимостей. Ведь есть же, да?
А куда вы так спешите? Языки очень инерционные, в С++ уже сколько лет с умишком собираются чтобы рефлексию добавить? ИИ появился всего пару лет назад, люди еще не успели собраться с мыслями.
Очевидно же что в конечном итоге победит язык который сможет как можно больше переложить на ИИ наиболее эффективным способом.
Руст и прочие языки в которых программист вынужден управлять временем жизни каждой переменной уже не нужны. Они еще будут куда-то двигаться по инерции, но по факту это мертворожденные технологии.
Re[7]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Артём, Вы писали:
S>>>>Да и вообще писал ли ты на чистом Си что-то сложнее HelloWorld-а? Аё>>>Писал часть модуля для продакшена- платформо-зависимый нативный кусочек, который вызывался из ооп-го апплета. Правил код прошивки девайса
S>>Т.е. не писал. Аё>Перечитай ещё раз написанное мной. Потом ещё раз, внимательно.
Прочитал. Там написано, что опыта разработки чего-то серьезнее HelloWorld-а на чистом Си у тебя нет.
S>>Судить о современном С++ на основании хз какого опыта 20-летней давности, ну такое себе. Тёмчик еще раз доказал, что он Тёмчик. Аё>Ну так "современный C++" это всемогутор мз костылей.
Ну так и Тёмчик все тот же Тёмчик.
А тем, кому не шашечки, а ехать, просто пользуются современным C++ и делают на нем то, что раньше было невозможно.
S>>На твоей работе это как-то сказалось? Аё>Что ты докопался до моей работы? Да я пользуюсь sudo, причём не только по работе.
Так говори предметнее.
S>>В самом sudo они что-то поломали? Аё>Да, они поломали часть фич.
Что из того, что они поломали, тебе нужно?
S>>Что в sudo-rs глючит? Аё>Фичи, которые это криворукие смузихлёбы ниасиоили === поломали.
Глючит -- это когда работает неправильно. А когда что-то выбросили, это уж точно не "глючит".
Можно было бы попросить тебя не тупить и не подменять понятия, но ты же Тёмчик.
Re[7]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>Все до ИИ языки закопают со временем.
"Это все узколобое сектантство." (c) некто Kluev
S>>Я не спешу, просто интересно, на чем делать проекты пока это щастливое будущее с заглавной буквы Ща еще не наступило. И так, чтобы не "собирать корки по утрам".
K>Вам совет дать или это вопрос риторический?
У вас кто-то спрашивал совета? И даже в более общем смысле: вашего мнения здесь кто-то спрашивал? Это вы зачем-то здесь объявились со своим ИИ-мессианством.
K>>>Руст и прочие языки в которых программист вынужден управлять временем жизни каждой переменной уже не нужны.
S>>Да, да. Языки с GC уже лет семьдесят доказывают, что еще чуть чуть и они перестанут тормозить.
K>Это все узколобое сектантство. Во многих задачах языки с GC уже быстрее языков с ручным управлением.
И хвала всевышнему, куча народа имеет возможность зарабатывать на жизнь программизмом не заботясь о вопросах управления памятью и пр. Вопрос в том, что делать с другими задачами, где нужна не только скорость, но и предсказуемость, и контроль за потреблением ресурсов. С простым ответом: не использовать там языки с GC. Так происходит на протяжении полувека, и так же будет происходить и дальше.
S>>Только вот сюрприз, в тех же С++, Rust и Ada не нужно управлять временем жизни каждой переменной вручную. Но зачем тов.Kluev об этом задумываться, если можно просто очередную порцию бреда высрать на публику.
K>Эти сказки вы рассказывайте восторженным неофитам. С++ вам дает только голенький указатель,
Для неасиляторов вопрос: покажите мне здесь хоть один голенький указатель. Ну и ручное управление памятью заодно.
#include <iostream>
class A {
public:
void f() { std::cout << "A::f()" << std::endl; }
};
class B {
public:
void f() { std::cout << "B::f()" << std::endl; }
};
class C {
A _a;
B _b;
public:
void f() {
std::cout << "C::f()" << std::endl;
_a.f();
_b.f();
}
};
int main()
{
C c;
c.f();
}
K> а управляете вы им с помощью костылей из stl которая частью языка не является.
У стандарта C++ на этот счет прямо противоположное мнение.
Re[9]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
S>>У вас кто-то спрашивал совета? И даже в более общем смысле: вашего мнения здесь кто-то спрашивал? Это вы зачем-то здесь объявились со своим ИИ-мессианством.
K>А вашего кто спрашивал? не видел чтобы вас кто-то звал в тред.
Так я и не спрашиваю дать ли кому-то совет. А пытаюсь выяснить у ТСа что именно так поломали в sudo-rs, что отразилось на ТСе. И какое вообще ТС-у дело до того, на каком языке sudo реализован.
S>>И хвала всевышнему, куча народа имеет возможность зарабатывать на жизнь программизмом не заботясь о вопросах управления памятью и пр. Вопрос в том, что делать с другими задачами, где нужна не только скорость, но и предсказуемость, и контроль за потреблением ресурсов. С простым ответом: не использовать там языки с GC. Так происходит на протяжении полувека, и так же будет происходить и дальше.
K>Это ваше большое заблуждение, что GC сделали ради упрощения языка специально для неосиляторов.
А теперь, пожалуйста, найдите в моих словах что-либо о ниасиляторстве.
S>>Для неасиляторов вопрос: покажите мне здесь хоть один голенький указатель. Ну и ручное управление памятью заодно.
K>К любой переменной вашего примера примените оператор & и у вас будет голый указатель.
Еще раз вопрос: покажите здесь хоть один голенький указатель и управление памятью.
А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
K>>> а управляете вы им с помощью костылей из stl которая частью языка не является.
S>>У стандарта C++ на этот счет прямо противоположное мнение.
K>стандарт языка С++ определяет сам язык и стандартную библиотеку. Очевидно же, что стандартная библиотека частью языка не является.
Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
Re[10]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
K>>К любой переменной вашего примера примените оператор & и у вас будет голый указатель.
S>Еще раз вопрос: покажите здесь хоть один голенький указатель и управление памятью.
Так вот же они родимые:
std::cout << "A::f()" << std::endl;
Или по вашему const char[] не голенький указатель?
S>А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
А деструктор вам компилятор написал? В деструкторе вы и управляете временем жизни, решая как и каким способом удалять обьект. Так что без ручного управления никуда.
K>>>> а управляете вы им с помощью костылей из stl которая частью языка не является.
S>>>У стандарта C++ на этот счет прямо противоположное мнение.
K>>стандарт языка С++ определяет сам язык и стандартную библиотеку. Очевидно же, что стандартная библиотека частью языка не является.
S>Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
Естественно что библиотека не является частью языка т.к. написана на нем самом. То что нельзя редуцировать используя другие конструкции языка это и есть язык.
Re[11]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
S>>Еще раз вопрос: покажите здесь хоть один голенький указатель и управление памятью.
K>Так вот же они родимые: K>
std::cout << "A::f()" << std::endl;
K>Или по вашему const char[] не голенький указатель?
Нет, это const char[7].
S>>А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
K>А деструктор вам компилятор написал?
Да.
K>В деструкторе вы и управляете временем жизни, решая как и каким способом удалять обьект.
Покажите пальцем, а то программа есть, а ручного управления нет.
S>>Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
K>Естественно что библиотека не является частью языка
Именно поэтому она описана в стандарте языка, ясно-понятно.
Re[13]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>>>Так вот же они родимые: K>>>
std::cout << "A::f()" << std::endl;
K>>>Или по вашему const char[] не голенький указатель?
S>>Нет, это const char[7]. K>Это и есть голенький указатель на строку в сегменте данных.
Когда кажется, что вы уже достигли дна, то вы старательно начинаете копать.
Давайте вам поможем взять новую глубину и возьмем простой пример на C#:
using System;
public class HelloWorld
{
public static void Main(string[] args)
{
Console.WriteLine ("Hello, World");
}
}
Полагаете, использованный здесь строковый литерал не будет затем использован как "голенький указатель на строку в сегменте данных"?
Может он где-то в libastral окажется?
S>>>>А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
K>Естесвенно. Если рассмотреть эту программу в целом то мы обязательно найдем ручной самописный код в деструкторе
У вас вся программа в целом перед глазами. Ну найдите ручной самописный код в деструкторе.
K>Какая разница кем это написано вами или авторами стандартной библиотеки?
Громадная.
S>>>>Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
K>>>Естественно что библиотека не является частью языка
S>>Именно поэтому она описана в стандарте языка, ясно-понятно.
K>То что библиотека где-то описана не делает ее языком. просто потому, что это разные вещи по определению.
А я и не утверждал, что "библиотека есть язык". Всего лишь говорю, что существующие стандарты C++ недвусмысленно опровергают ваш высер тезис:
stl которая частью языка не является
Так как вы любите пробивать дно, то попробуйте рассказать, как сделать средствами языка std::launder, например.
Или std::source_location.
Или как компилятору не знать про std::memory_order.
Или как компилятор узнает, что std::malloc начинает life-time для объекта.
Re[15]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>Здесь строковый литерал превратится в объект string и управлять временем жизни этого обьекта программисту не придется.
Покажите мне, где в моем примере на C++ программисту нужно управлять временем жизни задействованных в коде литералов.
Ответьте номально хотя бы на один из поставленных ранее вопросов, продемонстрируйте, наконец, подтверждение вашим словам "программист вынужден управлять временем жизни каждой переменной".
K>>>Какая разница кем это написано вами или авторами стандартной библиотеки?
S>>Громадная.
K>И в чем громадная?
Хотя бы в том, что часть стандартной библиотеки может быть написана на совсем другом языке.
K>когда средствами языка нельзя будет сделать например vector тогда обращайтесь. то что нельзя сделать средствами языка является частью языка по определению, а то что делается средствами языка — отдельная библиотечная функциональность которая языком не является. В компиляторах даже опция есть. собирать программу без стандартных библиотек.
Бла-бла-бла-бла.
Разговорчивый вы мой, ни одно из ваших словесных испражнений не может перебить того факта, что есть официальный стандарт языка C++, в котором описана и его стандартная библиотека. И нет официальных документов, которые бы описывали язык C++ отдельно как некий язык, частью которого не была бы STL.
Продолжите и дальше демонстрировать свое альтернативное восприятие реальности?
Re[9]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, dsorokin, Вы писали:
D>А что ты думаешь об эрланге?
Интересный нишевый язык. ИМХО, диссертация Джо Армстронга, в которой он описывал свой подход к разработке ПО в присутствии программных ошибок, обязательна к прочтению. Хотя бы для знакомства с принципом fail-fast. Еще неплохо бы прочитать историю Erlang-а от него же для History of Programming Languages.
D>Ты ведь увлекался ФП.
Не особо. Скажем так, попробовал познакомится когда вокруг ФП начинался хайп во второй половине 2000-х. Но не то, чтобы как-то сильно преуспел.
D>Какие мысли по эрлангу?
Наверное, он очень хорош там, где может применяться. Но меня смущает то, что он динамический. Таки чем дальше, тем больше ценю статическую типизацию. Плюс чисто по синтаксису мне больше симпатичен Elixir.
D>И кстати, заодно. А что ты думаешь о современных тенденциях в проектировании C++?
Неоднократно говорил в разных местах и повторю еще раз: у меня есть ощущение, что раньше С++ проектировали люди, гораздо более умные, чем я, но так, чтобы С++ могли пользоваться даже такие как я. Сейчас же C++ развивают люди, гораздо более умные, чем я, но они делают это самих себя. А проблема в том, что они недостаточно умны для этого.
Как говорится, сделать сложно не сложно, сложно сделать просто. Вот сделать просто и не получается.
Другое дело, а можно ли вообще как-то иначе, если поддерживать хорошую совместимость с предыдущими стандартами и в условиях широкой диверсификации языка/библиотек... Т.е. может быть я ругаю, а лучше в принципе не сделать.
D>Не слишком усложняют язык?
Мне не очень понятно, как обучать абсолютных новичков современному C++.
Я-то ладно, потихоньку новое осваиваю. Медленно, со скрипом, но у меня хотя бы есть роскошь делать это итерационно, по чуть-чуть.
А вот как взять вчерашнего PHP-шника или Python-иста, которые может быть когда-то Си видели краем глаза во студенчестве, и обучить современному С++ с шаблонами, концептами и пр. Вот это загадка.
Еще один момент: мне не нравятся некоторые принятые решения. Например, то, что сделали с deducing this. Или предлагаемый сейчас синтаксис для рефлексии с оператором "баян" (т.е. [:|||:]). ИМХО, у кого-то в комитете нет ни чувства стиля, ни чувства меры.
D>Я видел многих, кто его использует, максимум, как С++11 с мелкими элементами из C++17, не более.
Тут есть еще и такой парадокс, что в реальности нужно оглядываться на то, какой стандарт и в какой степени поддерживается компилятором. ИМХО, сейчас делать что-то реально кросс-платформенное на C++20 все еще стремно, на C++17 гораздо безопаснее, а на C++14 еще безопаснее.
Т.е. вроде как на бумаге у нас, у С++ников, есть уже и C++23. На практике же многие ограничены С++17, а некоторые и более древними стандартами.
D>Не отпугивает, что С++ все усложняют и усложняют?
И еще один парадокс: C++ становится все сложнее, а пользоваться им -- все проще.
Прошу заметить, я не говорю, что С++ становится безопаснее. Но вот писать на C++ с каждым новым стандартом становится все проще и приятнее. И делать удается то, что раньше казалось фантастикой.
Наблюдение из практики: когда приходится возвращаться со свежих стандартов на более старые (скажем, после С++20 вернуться на C++17, или после C++17 вернуться на C++14), то начинается ломка от того, что ставшие привычными вещи оказываются недоступны. Например, в C++17 нет operator<=>, а в C++14 нет structured binding.
D>К чему это может привести?
ХЗ, не хочу пытаться предсказать будущее.
D>Не пора ли провести ревизию?
Я вынужден согласиться с той точкой зрения, что если С++ не устраивает, то спокойно можно выбрать другой современный (или не очень) язык. Хороший выбор среди управляемых языков с GC: C#, Java, Kotlin, Go + Scala/OCaml/Haskell для любителей хардкора. Даже среди нативных языков без GC к экзотической Ada уже добавился хайповый Rust.
Мне бы хотелось видеть какой-то cpp2 (вроде того, что делает Саттер): новый язык на тех же идеях и с таким близким синтаксисом, который бы позволял слегка переделать существующие C++ные исходники. Но это был бы именно что другой язык, без попытки сохранить обратную совместимость.
Нужен ли он -- отдельный вопрос. Судя по Carbon-у от Google, кому-то что-то подобное нужно.
Re[9]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>Без GC и JIT не будет работать компонентная модель, не будут работать некоторые lock free алогритмы основанные на том, что простое присваивание позволяет забыть указатель (В с++ не реализуемо) и другие вещи.
Тут стало интересно
K>Многие вещи которые можно сделать например на C# в языке C++ просто не реализуемы.
Здравствуйте, Kluev, Вы писали:
K>А деструктор вам компилятор написал? В деструкторе вы и управляете временем жизни, решая как и каким способом удалять обьект. Так что без ручного управления никуда.
Здравствуйте, Kluev, Вы писали:
K>И в чем громадная? стандартная библиотека это такой же ручной самописный код котороый может содержать баги и например не освобождать память где требуется вызывая утечку памяти. 100%-й гарантии нет.
Весь C# — это тоже акой же ручной самописный код котороый может содержать баги и например не освобождать память где требуется вызывая утечку памяти. 100%-й гарантии нет.
K>когда средствами языка нельзя будет сделать например vector тогда обращайтесь. то что нельзя сделать средствами языка является частью языка по определению, а то что делается средствами языка — отдельная библиотечная функциональность которая языком не является.
Здравствуйте, Артём, Вы писали:
S>>Я вынужден согласиться с той точкой зрения, что если С++ не устраивает, то спокойно можно выбрать другой современный (или не очень) язык. Хороший выбор среди управляемых языков с GC: C#, Java, Kotlin, Go + Scala/OCaml/Haskell
Аё>Java это новый COBOL- это legacy, которые везде в бизнес-приложениях. Почему ты не упомянул Typescript?
Может приведешь пример C++ного проекта, который было бы оправдано переписать на Typescript? (или не переписать, а сделать его аналог)
Например, я могу рассматривать переписывание LibreOffice на C#, Envoy на Go или Erlang/Elixir, LLVM на OCaml, Chromium или Clickhouse на Rust.
Тут хотя бы предмет для разговора есть.
Где здесь место для TypeScript-а --
Пользоваться переписанным на TypeScript-е и Web-технологиях Lightroom/CaptureOne могу пожелать только тебе, в наказание за мегатонны вылитой на RSDN тупизны.
И это еще речь не зашла о тяжелых вычислениях, встраиваемых системах и реальном времени.
В общем, в своей современной реальности я не вижу где и как TypeScript может заменить С++.
Re[10]: #огда коту нечего делать- он пишет 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? А ведь был очень крутой монстр. Да потому, что появились персоналки, где он был просто не нужен. А с современными старыми языками пока такого сценария не предвидится.
Re[17]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>>>Здесь строковый литерал превратится в объект string и управлять временем жизни этого обьекта программисту не придется.
S>>Покажите мне, где в моем примере на C++ программисту нужно управлять временем жизни задействованных в коде литералов.
K>У вас в примере все переменные статические и автоматические.
Что опровергает ваш исходный тезис: "программист вынужден управлять временем жизни каждой переменной"
Не вынужден, не каждой.
K>но подчищать динамическую память в деструкторах нужно ручками
Давно уже нет. Где-то с того момента, как в язык добавили шаблоны.
K>>>И в чем громадная?
S>>Хотя бы в том, что часть стандартной библиотеки может быть написана на совсем другом языке.
K>И что это меняет?
Чуть меньше, чем все.
S>>Разговорчивый вы мой, ни одно из ваших словесных испражнений не может перебить того факта, что есть официальный стандарт языка C++, в котором описана и его стандартная библиотека. И нет официальных документов, которые бы описывали язык C++ отдельно как некий язык, частью которого не была бы STL.
S>>Продолжите и дальше демонстрировать свое альтернативное восприятие реальности?
K>По вашим словам библиотека — это язык потому
Нет. Вынужден еще раз констатировать то, что вы не умеете читать. Полагаю, что в силу реверсивного интеллектуального развития.
По моим словам стандартная библиотека является частью языка, потому что она описана в стандарте языка.
Я нигде не утверждал, что "библиотека -- это язык".
Re[18]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Что опровергает ваш исходный тезис: "программист вынужден управлять временем жизни каждой переменной" S>Не вынужден, не каждой.
Вобщем-то так и есть чтобы вы не говорили. Программист располагает переменные в трех классах памяти, соответственно определяет время жизни. Если объект создается динамически вы выбираете для него подходящую обертку shared_ptr, unique_ptr и т.д чем это не управление временем жизни?
K>>но подчищать динамическую память в деструкторах нужно ручками
S>Давно уже нет. Где-то с того момента, как в язык добавили шаблоны.
с этого места поподробнее
K>>>>И в чем громадная?
S>>>Хотя бы в том, что часть стандартной библиотеки может быть написана на совсем другом языке.
K>>И что это меняет?
S>Чуть меньше, чем все.
А по факту ровным счетом ничего. Какая разница на чем написан код если он написан руками?
S>Нет. Вынужден еще раз констатировать то, что вы не умеете читать. Полагаю, что в силу реверсивного интеллектуального развития.
S>По моим словам стандартная библиотека является частью языка, потому что она описана в стандарте языка. S>Я нигде не утверждал, что "библиотека -- это язык".
А по моим словам не является. Потому что я опираюсь на определения языка и библиотеки. А не на тот факт что язык и библиотеку в одной бумажке описали.
Re[12]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, 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>Дурень думкой богатеет.
А чем богатеет токсичное сообщество мелкобукв обиженных на научно технический прогресс?
Re[19]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>Вобщем-то так и есть чтобы вы не говорили. Программист располагает переменные в трех классах памяти, соответственно определяет время жизни. Если объект создается динамически вы выбираете для него подходящую обертку shared_ptr, unique_ptr и т.д чем это не управление временем жизни?
Попробуйте обратить ваши слова на любой язык с GC и получите тоже самое, с поправкой на то, что классов памяти окажется поменьше.
Т.е. в очередной раз херня с вашей стороны.
K>А по факту ровным счетом ничего.
Кроме того факта, то для каких-то языков нельзя написать стандартную библиотеку средствами самого языка.
K>Какая разница на чем написан код если он написан руками?
Попробуйте обратить ваши слова на любой язык с GC...
K>А по моим словам не является.
Ну говорите, говорите. На заборах тоже много чего пишут.
K>Потому что я опираюсь на определения языка и библиотеки.
Во-первых, хз какие определения.
Во-вторых, вы не смогли объяснить работу некоторых средств стандартной библиотеки (того же std::launder) на базе возможностей языка.
Т.е., очередные пуки в лужу по всем направлениям.
K>А не на тот факт что язык и библиотеку в одной бумажке описали.
Да оно понятно, что когда реверсивный ителлект и альтернативное восприятие реальности, то на существование международного стандарта того, что называется "язык программирования C++" можно и болт положить.
Re[13]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
S>>Это уже давно было доказано экспериментально. S>>Чтобы GC не тормозил, ему нужно от 4 раз больше ОП, чем в случае с ручным управлением памятью.
K>Этим вы можете только восторженных неофитов впечатлить.
Неофиты из Apple (ссылку на которых я давал) очень впечатлились от того факта, что у них Java с GC потребляла почти на порядок больше памяти, чем Swift без GC. Но не смотря на то, что факты упрямая вещь, г.Kluev тоже не лыком шит, у него своя реальность, с розовыми очками, через которые видно лишь то, что ему удобно.
K>А по факту в системах с неперемещаемой памятью она может фрагментироваться настолько, что свободной памяти полно, а массивчик разместить негде. На 64 бит это конечно малоактуально, а на 32-х исчерпание адресного пространства из-за фрагментации было серьезной проблемой.
До тех пор пока в проекты не затаскивали jemalloc, tcmalloc, mimalloc или какой-то заточенный под задачу кастомный аллокатор.
А с учетом того, что в языках без GC много объектов живет тупо на стеке и не требует аллокаций/деаллокаций, то все еще менее страшно.
K>А чем богатеет токсичное сообщество мелкобукв обиженных на научно технический прогресс?
Было бы интересно узнать из каких слов следует "обиженных на научно-технический прогресс", но вы ведь в очередной раз с конкретикой отморозитесь, как это уже случалось в данном разговоре неоднократно.
Можете поискать где бы я ругал GC или доказывал, что ручное управление памятью однозначно лучше, чем GC. Если найдете, то дайте цитату, плз.
Re[16]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Marty, Вы писали:
M>Весь C# — это тоже акой же ручной самописный код котороый может содержать баги и например не освобождать память где требуется вызывая утечку памяти. 100%-й гарантии нет.
можно я тоже в демагогию поиграю
ОС тоже ручной самописный код с багами
процессор тоже не боги сделали
WBR, Igor Evgrafov
Re[19]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, 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 программы на С++ стараются писать с ней.
Re[17]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>В паскале модули появились в 1987 году.
Всего-то через 17 лет после появления самого Паскаля. И кого это сейчас волнует?
В Java дженерики появились через восемь или девять лет после выхода Java 1.0. И кого это сейчас волнует?
K>Всего 33 года Страуструпу потребовалось чтобы умишком пораскинуть.
"То что вы здесь раскидываетесь оскорблениями это уже признак интеллектуального фиаско." (с) г.Kluev
Re[13]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, 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 "поломали", что мешает тебе жить?
Re[15]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Артём, Вы писали:
S>>Да, мне очень сложно представить все это хозяйство на TypeScript. Аё>Жирный десктопный UI прекрасно бегает в веб. Если ты неосилил- то вопросы к тебе.
Тёма, вот ты, наверное, мне и нужен!
А как заставить код на C# и F# работать в браузере?
А тут Авалонию использую. Когда перевожу в браузерную версию, Web Assembly | Avalonia Docs, то фигня какая-то получается. Во-первых, медленно, что браузер спрашивает, а не прибить ли поток (у меня там рисовалка + расчеты). Во-вторых, и это самое главное, наружу торчит весь байт-код, что очень и очень нехорошо.
Вот, что ты как специалист посоветуешь, чтобы мне существующую кодовую базу, которую я написал на С# и F# за много-много лет, перенести в веб? Ломаю голову, и ничего умного придумать не могу
Здравствуйте, Артём, Вы писали:
S>>MSO -- это Microsoft Office? S>>Если так, то хотелось бы пруфов, поскольку в сети валялся доклад разработчиков из MS о том, что там кодовая база на С++ с мохнатых годов, которая была адаптирована в том числе и под Web. Аё>В новостях в 2020 ещё было, что оставят только веб версию для всего — и "десктоп" будет обёртка над веб.
Так Web-версия базировалась на древнем коде на C++.
S>>Когда приносишь со съемки 1000-1500-2000 фото, то даже десктопный Lightroom слишком тормозной для первичной выбраковки. А если еще умельцы, вроде тебя, его внутрь Хрома засунут, то вааще ахтунг будет. Аё>М.б. вопрос к криворуким разработчикам десктопного Lightroom?
Покажи продукт лучше. Да еще и написанный не на нативных языках.
S>>>>И это еще речь не зашла о тяжелых вычислениях, встраиваемых системах и реальном времени. Аё>>>Вычисления бегают в WASM , WebGPU.
S>>На кластерах из тысяч вычислительных нод? Аё>Нейросетки компьютерного зрения бегают в WASM , WebGPU в т.ч. на смартфоне. Это что я лично прикрутил (примотал изолентой ) в веб ui.
И где здесь кластера из тысяч вычислительных нод? А да, ты же тупой Тёмчик, который не может даже прочитать вопрос. Сорри, запамятовал.
S>>Да, мне очень сложно представить все это хозяйство на TypeScript. Аё>Жирный десктопный UI прекрасно бегает в веб. Если ты неосилил- то вопросы к тебе.
Судя потому, что нет браузера на TypeScript, нет KDE на TypeScript, нет производительных VM для JS на TypeScript, ниасилил не только лишь я.
S>>Так клиентов для подобных вещей и раньше не особо на C++ разрабатывали. Это как бы и не ниша для C++. Аё>Проблема доя C++ разработчиков — это нишевый язык.
Это не проблема.
S>>Так ты примеры приведешь что такого в sudo-rs "поломали", что мешает тебе жить? Аё>Ты по кругу ходишь. Я указал- неосилили feature parity.
Это потому, что ты туп настолько, что не можешь ответить на простой вопрос.
Так что еще одна попытка, чтобы еще раз продемонстрировать общественности твою тупизну: какие такие фичи в sudo-rs "поломали", что тебе это мешает?
Re[16]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Sinclair, Вы писали:
K>>Это не факты а их подтасовка. Какой-то отдельно взятый проект неизвестно как написанный. Мало что ли их сдохло на всех языках программирования? S>Возможно, 80% экономии памяти бы дало переписывание с Java на Java.
Возможно, нужно было бы пойти по ссылками и прочитать хотя бы поверхносные описания?
S>Если, к примеру, взять махровое легаси, написанное для Java 1.2, где банальный разбор HTTP-запроса состоит из постоянных копирований строк с перевыделениями, и переписать на современную версию с zero-allocation парсерами примитивных типов, то примерно так и получится.
Ну просто шикарное подтверждение тезиса о скорости и других преимуществах GC. Браво!
Оказывается, чтобы было быстро и не ресурсоемко, требуется zero-allocation парсеры. Вот прям раскрытие GC во всей красе.
Такими темпами места для языков с ручным управлением памятью точно не останется.
Re[18]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>В паскале модули появились в 1987 году.
S>Всего-то через 17 лет после появления самого Паскаля. И кого это сейчас волнует?
Сами модули впервые появились в 1975 в модуле, а паскалевские заимствованы из модула-2 1978 т.е. 9 лет на внедрение. Сумасшедшие темпы по меркам С++ с учетом того что в С++ каких-то своих оригинальный идей вобщем-то и нет. Легендарные шаблоны это тоже не страуструповское ноу-хау. Впервые параметрические типы появились в ML (1973 год) за 15 лет добрались до С++. Да что там говорить даже элементарные баги исправляются раз в 20 лет. Тот же iostream который в исходном виде полностью бесполезен, стал хоть как-то полезен с появлением quoted спустя всего каких-то 18 лет.
S>В Java дженерики появились через восемь или девять лет после выхода Java 1.0. И кого это сейчас волнует?
Сумасшедшая скорость по плюсовым меркам.
K>>Всего 33 года Страуструпу потребовалось чтобы умишком пораскинуть.
S>"То что вы здесь раскидываетесь оскорблениями это уже признак интеллектуального фиаско." (с) г.Kluev
Я не оскорбляю, а констатирую. Страуструп внедряет с такой скоростью, что как будто он собрался жить вечно. И программистов похоже тоже считает бессмертными.
Re[19]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>>>В паскале модули появились в 1987 году.
S>>Всего-то через 17 лет после появления самого Паскаля. И кого это сейчас волнует?
K>Сами модули впервые появились в 1975 в модуле, а паскалевские заимствованы из модула-2 1978
Тем не менее, от появления витовского Паскаля и внедрения модулей в очередной версии Turbo Pascal прошло полтора десятка лет.
Волнует ли это сейчас кого-то?
Нет.
K>Впервые параметрические типы появились в ML (1973 год) за 15 лет добрались до С++.
С учетом того, что С++ появился в 1985-ом, а шаблоны в нем -- в районе 1991-го, то озвученные вами 15 лет -- это вообще как?
S>>В Java дженерики появились через восемь или девять лет после выхода Java 1.0. И кого это сейчас волнует?
K>Сумасшедшая скорость по плюсовым меркам.
Для персонажей с реверсивным умственным развитием: "впервые параметрические типы появились в ML (1973 год)" + в С++, с косплея которого Java начиналась, шаблоны были к 1995-ому году уже 5 лет минимум. Но в Java из завезли в 2003 или 2004.
И кого это сейчас волнует? Да никого от слова совсем.
K>Страуструп внедряет
Вот интересно: это реверсивное умственное развитие, или же альтернативное восприятие реальности заставляет вас говорить, что Страуструп что-то внедряет?
Ставлю и на одно, и на другое сразу.
Для г.Kluev-а и ему подобных: С++ с начала 1990-х развивается комитетом. Перекладывать на Страуструпа то, что происходит с языком после начала работы комитета -- это, по меньшей мере, расписываться в незнании простых вещей.
Здравствуйте, dsorokin, Вы писали:
D>Вот, что ты как специалист посоветуешь, чтобы мне существующую кодовую базу, которую я написал на С# и F# за много-много лет, перенести в веб? Ломаю голову, и ничего умного придумать не могу
Я не специалист в wasm ни разу .
Хз. Возможно, придётся вручную отделить код многопоточки в отдельные скрипты (или отдельные wasm). Для браузера WebWorker- это как отдельное приложение без доступа к DOM, близкая аналогия- как если приложение крутит другое, консольное, в фоне и обменивается собщениями через cin-cout.
У WebWorker вначале подписываешься на сообщения от хоста. Хост подписывается на сообщения от web worker. Я делал обёртку на хосте, которая регистрировала что на что отвечает. Естественно, что любой обсчёт на хосте должен успеть между 2 кадрамм- поэтому ни в коем случае ничего с циклами не считать. Просто заворачиваешь посылку отправляешь в web worker- как если бы отправлял на бек.
Собирать wasm мне не довелось Там, где opencv забыла пометить метод в экспорт в wasm- скопипастил код из исходника C++ в код Typescript, благо метод небольшой, на производительности не сказалось.
Re[17]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Артём, Вы писали:
Аё>Я не специалист в wasm ни разу .
Аё>Хз. Возможно, придётся вручную отделить код многопоточки в отдельные скрипты (или отдельные wasm). Для браузера WebWorker- это как отдельное приложение без доступа к DOM, близкая аналогия- как если приложение крутит другое, консольное, в фоне и обменивается собщениями через cin-cout. Аё>У WebWorker вначале подписываешься на сообщения от хоста. Хост подписывается на сообщения от web worker. Я делал обёртку на хосте, которая регистрировала что на что отвечает. Естественно, что любой обсчёт на хосте должен успеть между 2 кадрамм- поэтому ни в коем случае ничего с циклами не считать. Просто заворачиваешь посылку отправляешь в web worker- как если бы отправлял на бек.
Аё>Собирать wasm мне не довелось Там, где opencv забыла пометить метод в экспорт в wasm- скопипастил код из исходника C++ в код Typescript, благо метод небольшой, на производительности не сказалось.
Что многопоточный wasm сам по себе, а однопоточный dom тоже сам по себе — это я в курсе. Значит, с .NET в контексте blazor ты не сталкивался.
Сейчас у меня две печали по этому вопросу. Может быть, кто-то сталкивался.
Во-первых, после обфускатора Obfuscar в веб-браузере не грузится клиентский код. Возможно, что дело в самом обфускаторе. Вчера попадались ссылки, где для этого используют другие обфускаторы. И вроде как может заработать.
Во-вторых, даже без AOT мое веб-клиентское приложение раздувается до мегабайт 70. С AOT — где-то до 100 мегабайт. Да я так замучаюсь платить хостеру за трафик! Причем, в чистом виде инсталятор десктопной версии с WPF у меня весит всего-то мегабайт 11, а это у меня самая навороченная и производительная версия.
Круто, конечно, когда программу не нужно устанавливать, что она может сразу загрузиться и запуститься. Однако возникает большой вопрос в целесообразности идти этим путем
Re[18]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, dsorokin, Вы писали:
D>Значит, с .NET в контексте blazor ты не сталкивался.
Нет. Я религиозно противник пончика , я за кросс платформу
D>Во-вторых, даже без AOT мое веб-клиентское приложение раздувается до мегабайт 70. С AOT — где-то до 100 мегабайт.
Вот вот
D> инсталятор десктопной версии с WPF у меня весит всего-то мегабайт 11, а это у меня самая навороченная и производительная версия.
Наш продукт примерно до 6.5 мег раздулся с годами (фронт на ангуларе). И ещё 12мег — 2 нейросетки, но они подкружаются только когда фича активна. Естественно, бек- другая история там может под терабайт статических данных.
D>Круто, конечно, когда программу не нужно устанавливать, что она может сразу загрузиться и запуститься. Однако возникает большой вопрос в целесообразности идти этим путем
Меньше мозгоправства с релизами. Обратная сторона- нет доступа к API устройства.