скорее:
«Любой язык без той херни которая мне не нужна:»
(клочок туалетной бумаги)
Лично меня как С++ разраба факт появления новых фич не беспокоит. Меня больше беспокоят случаи торопливого добавления фич. Которые по итогу оказываются непродуманными. std::filesystem, модули, да много таких примеров.
Ну как сказать, у меня вот обширный опыт на С++, хелоуворлды на rust с циклами и арифметикой без проблем, но как только попытался что-то более сложное — наследования нет, виртуальных методов нет, вместо коллбеков и каррирования — делай вася агрегирование доп. классов с методами и тд и тп.
Эксперименты с Java/C# чет у меня такого дискомфорта не вызывали, там все плюс минус такое же имеется (ну иногда многословнее, а иногда и поудобнее).
Изучать я Rust однозначно буду и дальше. Но больна.
Ну так существующие пользователи и не будут покупать новую версию если их все устраивает. Как продавать снова и снова (в идеале для бизнеса по подписке) продукт который «просто работает»?
Конечно надо делать редизайны и вносить баги, чтобы оправдать платную поддержку :D
Как программисту на С++ мне это слушать как страшную сказку приходится) Сочувствую Go-разработчикам. Не, строгость это хорошо. Это одобряю. Но вот этот вот AddUint32Uint32 ужасно же.
Как разработчик на С++ я тоже в это не верю. Возможно автор комментария про какие-то узкие кейсы по типу sort() который на C работает с void* и не может оптимизировать под конкретные типы и все такое. Но если не читерить с кейсами
«вот мы на С++ сделали шаблонный код, а на С такое руками писать утомительно поэтому сделаем тупо и неоптимально» — то не вижу причины с чего бы на С++ коду быть быстрее.
С++ эффективнее чем С, да. В выразительности, в скорости написания чего-то большого что надо поддерживать долго и толпой мало связанных меж собой разработчиков, я думаю множество средств где в поддержке он у С может выиграть.
А вот касаемо эффективности кода, ну чет такое. Слабо верится. Только в частностях.
Этот пример с дженериками достаточно очевидный и показательный чтобы отметить в целом всю несостоятельность и глупость дизайна Go. Поэтому используется такая фраза как «этим всё сказано».
Ваш капитан очевидность.
Ну спасибо что хоть кто-то уделил минутку внимания чтобы объяснить что там сказано)
Про то что изначально в Go не было планов на дженерики я тоже наслышан. Просто мне почему-то показалось что корневой комментарий пытался оспорить постулаты статьи этим «всё сказано», а так он еще больше поддерживает.
А, еще видимо я слово «только» не в том значении прочитал.
Я прочитал предложение как "… статья конечно хороша, но вот только в Go уже есть дженерики с марта"
а по факту коммент был похоже
«плюсую статье, все по делу. одно лишь факт (»только") что в марте ЭТОГО года добавили..." далее по тексту.
Возможно из-за этого и был тупняк.
Мы чет по кругу ходим. Можете придерживаться нейтрального тона?
Давайте сначала. Я C++ разработчик. GP я вполне себе на каком-то уровне уменю в этом языке.
Я читал новость о том что в Go добавили generic-и, выглядит как что-то (на совсем поверхностный взгляд незнакомого с Go) позволяющее работать в GP парадигме. Насколько это соответствует мощи шаблонов С++ — не берусь сказать. Возможно, не соответствует. В любом случае что
а) в Go все нормально сейчас с GP
б) или в Go добавили generics но их сильно мало
я все еще не понимаю, как эта информация что их уже добавили в этом году соотносится с «этим все сказано», с какой частью статьи это коррелирует.
Про то что там за борьба была 12 лет — не в курсе, и статья про парадигму уж точно ее не раскрывает.
Для тех кто не работал с Go, а что все сказано? Прошу кэпа на помощь. То что изначально авторы языка говорили дженериков и шаблонов не будет, а теперь сдались? Типа он уже никакой не минималистичный и простой? Или типа вот только в марте добавили, поэтому все посты про то что в Go нет нормальных возможностей уже надо закапывать? Я не особо понимаю как это конфликтует с оригинальной статьёй.
Я тоже сразу вспомнил Полухина, когда открыл эту статью)
Но широко использовать его подход для сотен классов не получится. Оптимизировать один два класса так, да, можно.
По сути C++20 Modules должны делать FastPimpl за нас.
Получается примерно какая штука, во время сборки модуля у вас будет
class Render
{
private:
SomeLinuxType m_one;
AnotherLinuxType m_two;
};
грубо и приближенно, при импорте этого модуля (если никто не экспортирует классы) юзер получит некое подобие
class Render
{
private:
byte m_one[sizeof(SomeLinuxType)];
byte m_two[sizeof(AnotherLinuxType )];
};
Т.е. пользователю класса не нужно подлючать в хедер определения типов полей (что зачастую основной повод для Pimpl).
Плюсы:
1. no indirection. разместил на стеке, никакой динамической аллокации. можно фигачить переменные с глобальным лайфтаймом, и прочие плюшки. Компилятор видит типы приватных полей ( в отличие от программиста!) и может делать всякие инлайновые доступы внутри SomeLinuxType того же.
Минусы:
1. Нужна поддержка C++20 Modules. Нужна поддержка и в компиляторе и в билд системе. Нужна ХОРОШАЯ поддержка, без багов (т.е. если компилятор таки будет делать экспорт определений из модуля, это опять же не вариант).
2. При изменении SomeLinuxType, необходима перекомпиляция интерфейса модуля Render, а значит и всего пользовательского кода который использует Render. Если вы хотите изменять код и не иметь пересборки зависимостей — не годится.
3. вытекает из предыдущего, нет ABI stability. Добавили поле в SomeLinuxType? получите изменение sizeof(Render). (у решения автора статьи его тоже нет, впрочем)
Ну чет да, я вот QtC под Windows собираю: clone / cmake / ninja, все, непонятно зачем кросскомпиляция :)
Visual studio компилятор в Community бесплатный (я думаю сборка Qt вполне соответствует Community лицензии)
Согласен, сразу после вашего коммента вспомнился фильм «Пианист». Где тоже люди все говорили «ну да, нас вот тут собрали, повязки выдали, стеной огородили, в поезд везут в другой город, НАВЕРНОЕ ХОТЯ БЫ ДАДУТ РАБОТУ», я конечно не говорю что наше правительство будет прям физически в камерах истреблять своих граждан, но предполагать что о нас заботятся — верх наивности.
Да я уже на второй разок перечитал и кажется понял что за расхождения у вас были. нефиг было мне влазить, все нормально и так)
слова «вина» и «ответственность» и «право взыскания» — вот это все как бы стоит определять)
согласен с вашей позицией по whatsabout-изму.
p.s. если что, в международном праве сущность наказания как нарушения чего-либо особо и не предусмотрена) если заводить речь про санкции, то это вещь которую все могут делать не зависимо от «вины» там или «преступлений» или «кто там что прав и что нарушил».
«Любой язык без той херни которая мне не нужна:»
(клочок туалетной бумаги)
Лично меня как С++ разраба факт появления новых фич не беспокоит. Меня больше беспокоят случаи торопливого добавления фич. Которые по итогу оказываются непродуманными. std::filesystem, модули, да много таких примеров.
Эксперименты с Java/C# чет у меня такого дискомфорта не вызывали, там все плюс минус такое же имеется (ну иногда многословнее, а иногда и поудобнее).
Изучать я Rust однозначно буду и дальше. Но больна.
Конечно надо делать редизайны и вносить баги, чтобы оправдать платную поддержку :D
«вот мы на С++ сделали шаблонный код, а на С такое руками писать утомительно поэтому сделаем тупо и неоптимально» — то не вижу причины с чего бы на С++ коду быть быстрее.
С++ эффективнее чем С, да. В выразительности, в скорости написания чего-то большого что надо поддерживать долго и толпой мало связанных меж собой разработчиков, я думаю множество средств где в поддержке он у С может выиграть.
А вот касаемо эффективности кода, ну чет такое. Слабо верится. Только в частностях.
Ну спасибо что хоть кто-то уделил минутку внимания чтобы объяснить что там сказано)
Про то что изначально в Go не было планов на дженерики я тоже наслышан. Просто мне почему-то показалось что корневой комментарий пытался оспорить постулаты статьи этим «всё сказано», а так он еще больше поддерживает.
А, еще видимо я слово «только» не в том значении прочитал.
Я прочитал предложение как "… статья конечно хороша, но вот только в Go уже есть дженерики с марта"
а по факту коммент был похоже
«плюсую статье, все по делу. одно лишь факт (»только") что в марте ЭТОГО года добавили..." далее по тексту.
Возможно из-за этого и был тупняк.
Всем извините, можете минусить мой тупизм дальше)
Давайте сначала. Я C++ разработчик. GP я вполне себе на каком-то уровне уменю в этом языке.
Я читал новость о том что в Go добавили generic-и, выглядит как что-то (на совсем поверхностный взгляд незнакомого с Go) позволяющее работать в GP парадигме. Насколько это соответствует мощи шаблонов С++ — не берусь сказать. Возможно, не соответствует. В любом случае что
а) в Go все нормально сейчас с GP
б) или в Go добавили generics но их сильно мало
я все еще не понимаю, как эта информация что их уже добавили в этом году соотносится с «этим все сказано», с какой частью статьи это коррелирует.
Про то что там за борьба была 12 лет — не в курсе, и статья про парадигму уж точно ее не раскрывает.
Но широко использовать его подход для сотен классов не получится. Оптимизировать один два класса так, да, можно.
По сути C++20 Modules должны делать FastPimpl за нас.
www.reddit.com/r/cpp_questions/comments/rz9yxi/do_c20_modules_make_the_pimpl_idiom_irrelevant
Получается примерно какая штука, во время сборки модуля у вас будет
грубо и приближенно, при импорте этого модуля (если никто не экспортирует классы) юзер получит некое подобие
Т.е. пользователю класса не нужно подлючать в хедер определения типов полей (что зачастую основной повод для Pimpl).
Плюсы:
1. no indirection. разместил на стеке, никакой динамической аллокации. можно фигачить переменные с глобальным лайфтаймом, и прочие плюшки. Компилятор видит типы приватных полей ( в отличие от программиста!) и может делать всякие инлайновые доступы внутри SomeLinuxType того же.
Минусы:
1. Нужна поддержка C++20 Modules. Нужна поддержка и в компиляторе и в билд системе. Нужна ХОРОШАЯ поддержка, без багов (т.е. если компилятор таки будет делать экспорт определений из модуля, это опять же не вариант).
2. При изменении SomeLinuxType, необходима перекомпиляция интерфейса модуля Render, а значит и всего пользовательского кода который использует Render. Если вы хотите изменять код и не иметь пересборки зависимостей — не годится.
3. вытекает из предыдущего, нет ABI stability. Добавили поле в SomeLinuxType? получите изменение sizeof(Render). (у решения автора статьи его тоже нет, впрочем)
Visual studio компилятор в Community бесплатный (я думаю сборка Qt вполне соответствует Community лицензии)
en.cppreference.com/w/cpp/utility/from_chars
эта функция сразу знает размер, никакой лишней работы.
слова «вина» и «ответственность» и «право взыскания» — вот это все как бы стоит определять)
согласен с вашей позицией по whatsabout-изму.
p.s. если что, в международном праве сущность наказания как нарушения чего-либо особо и не предусмотрена) если заводить речь про санкции, то это вещь которую все могут делать не зависимо от «вины» там или «преступлений» или «кто там что прав и что нарушил».