Мне современный С++ напоминает старую проститутку которая решила снова выйти на панель и нанесла на себя все виды косметики которые только продавались.
Здравствуйте, BlackEric, Вы писали:
BE>Получается пора его изучать, хотя бы для возможности читать исходники системного софта?
Заинтересовался вопросом...
Почитал, поизучал, поставил компилятор, написал несколько тестовых примеров.
Потом еще раз почитал.
Вывод такой.
Для системного — очень даже может быть.
Но как замена C#, Java и тд — тупизм чистейшей воды.
С тем же примерно успехом можно на чистый С перейти.
А жаль, мне очень понравилось что идентификаторы пишутся так как я люблю — с "_" для разделения слов.
Здравствуйте, vl690001x2, Вы писали:
V>Но как замена C#, Java и тд — тупизм чистейшей воды. V>С тем же примерно успехом можно на чистый С перейти.
Я бы сказал, что трудности есть, но это не такая безумная идея, как кажется на первый взгляд. Мы примерно так Rust и используем.
Есть вещи, которые позволяют Rust быть более высокоуровневым, чем Java (более мощная система типов, макросы).
Разница с C -- небо и земля, не согласен с таким сравнением. Я бы даже сказал, с C++ нельзя сравнивать -- с C++ будет трудно и опасно писать промышленный код после, скажем, буткампа и 2х недель JavaScript или сразу после ВУЗа. А Rust -- можно (говорю с позиции опыта), хотя свои сложности, конечно, есть.
Здравствуйте, Иван Дубров, Вы писали:
ИД>Разница с C -- небо и земля, не согласен с таким сравнением. Я бы даже сказал, с C++ нельзя сравнивать -- с C++ будет трудно и опасно писать промышленный код после, скажем, буткампа и 2х недель JavaScript или сразу после ВУЗа. А Rust -- можно (говорю с позиции опыта), хотя свои сложности, конечно, есть.
С C++ густо обвешанным санитайзерами сравнивать очень даже можно, та же хрень, по большому счету, но меньше с системой типов мудохаться. Если уж совсем неофит, то можно и попроще инструменты брать типа Go, там даже самый тепой безопасен и оперативно профит приносит.
Здравствуйте, kaa.python, Вы писали:
KP>С C++ густо обвешанным санитайзерами сравнивать очень даже можно, та же хрень, по большому счету, но меньше с системой типов мудохаться. Если уж совсем неофит, то можно и попроще инструменты брать типа Go, там даже самый тепой безопасен и оперативно профит приносит.
Какого осознавать, что ты пишешь на бейсике? Скучно же.
Здравствуйте, Nuzhny, Вы писали:
N>Какого осознавать, что ты пишешь на бейсике? Скучно же.
Я этот этап давно прошел. Интересно — это сделать легко поддерживаемое, расширяемое решение в срок и с ожидаемым качеством. И вот в таком случае конкурентов у Go почти нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Микрософту винда то уже не особо нужна, особенно десктопная, и ее потихоньку задвигают. Так что чем меньше она будет жрать ресурсов, тем лучше.
Капец? Ну наконец-то!
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Nuzhny, Вы писали:
BE>>Я, наверное, чего-то не понимаю, но лучше бы они сделали нативный компилятор шарпа.
N>Сборка мусора для системного языка недопустима.
Вовсе нет. Идеально было бы, если можно было бы в критическом пути использовать некую специальную аллокацию, с ручным управлением памятью, а в остальных местах — GC. Ну скажи мне, зачем нужно ручное управление памятью при разборке конфигов, возне с SSL-сертификатами, управлении логами и т.п.? А это, между прочем, изрядный кусок кода. Собственно, доля кода, где GC вредит, будет в тепичном проекте — процентов 10-20.
Пайк, если кто не в курсе, из числа тех ребят, которые в интервале между вымиранием динозавров и вымиранием мамонтов сделали UNIX. Тогда все крутили пальцем у виска, и говорили, что нормальные люди пишут операционные системы на ассемблере, а ни как уж на Сях и прочих алголах-фортранах. На что авторы юникса отвечали, что Си, он по производительности и потреблению ресурсов практически, как ассемблер. И это было ложью, потому что сишнте компиляторы тех времен проигрывали ассемблеру раза в два.
Я к тому, что Пайк тот еще говорун. Его слова надо с осторожностью воспринимать. Но он очень хорош, как дизайнер языков программирования.
N>Какого осознавать, что ты пишешь на бейсике? Скучно же.
Здравствуйте, L.K., Вы писали:
LK>Как я понимаю, взлетает не Rust, а Verona.
LK>тынц
Там довольно интересный момент есть:
Как указывает ZDnet со ссылкой на Мэтта Миллера, специалиста Microsoft по безопасности, около 70% всех уязвимостей, которые были обнаружены в продуктах Microsoft в последние годы, были связаны с ошибками управления памятью.
Интересен он в первую очередь тем, что из этих 70% уязвимостей основная масса приходится на код-в-стиле-Си (массивы, управление памятью, форматирование и т.д.), который находится в файле с расширением cpp. Но да, конечно, тут C++ виноват
Здравствуйте, kaa.python, Вы писали:
KP>С C++ густо обвешанным санитайзерами сравнивать очень даже можно, та же хрень, по большому счету, но меньше с системой типов мудохаться.
Для меня вопрос стоит очень просто. По моему опыту, включая некоторый опыт C++, я бы не расчитывал, что команда начинающих разработчиков (под руководством более опытных) сможет на нём писать достаточно большую систему без внимательного анализа каждого изменения.
Доказать не могу, т.к такого опыта с C++ в масштабе у меня нет, просто такое ощущение. Я вроде как сам не дурак, но помню мои "эксперименты" с попыткой оседлать move семантику -- код, который выглядел, ну как любой другой код на C++, падал с какими-то ошибками. Ну чо-то там где-то не туда передвинул, наверное, может, случайно ссылку получил на объект на стеке вместо перемещения и вернулся из функции. Не знаю. Шаблоны были.
И дело не в том, что опытные товарищи там прям баги какие-то нашли бы (скорее всего, я чего-то глупое сделал, да), а в том, что в Rust покажешь направление -- менее опытные разработчики выкопают канаву -- и если она скомпилировалась, то и падать не будет (понятно, что бывают и переполнения стека и так далее).
А если взять библиотеки, которые cargo вытащит и соберет без всякий приседаний (CMake... уффф...), то вообще песня. Надо че-нить распараллелить, например, ускорить запуск? rayon, пара строк кода и система типов обеспечит правильную синхронизацию (ну или укажет, где сломается). CLI? clap+structopt, типизированные структуры из параметров командной строки. И так далее.
Много библиотек, конечно, не хватает ещё, например, вся "взрослая" XML инфраструктура отсутствует (XML Schema, XPath).
Здравствуйте, Иван Дубров, Вы писали:
ИД>Доказать не могу, т.к такого опыта с C++ в масштабе у меня нет, просто такое ощущение. Я вроде как сам не дурак, но помню мои "эксперименты" с попыткой оседлать move семантику -- код, который выглядел, ну как любой другой код на C++, падал с какими-то ошибками. Ну чо-то там где-то не туда передвинул, наверное, может, случайно ссылку получил на объект на стеке вместо перемещения и вернулся из функции. Не знаю. Шаблоны были.
Так на C++ можно писать без шаблонов и уж тем более move-семантики. Полагаю, что основная масса проектов так и сделана по сей день
ИД>И дело не в том, что опытные товарищи там прям баги какие-то нашли бы (скорее всего, я чего-то глупое сделал, да), а в том, что в Rust покажешь направление -- менее опытные разработчики выкопают канаву -- и если она скомпилировалась, то и падать не будет (понятно, что бывают и переполнения стека и так далее).
А при таком варианте реально встает вопрос – а зачем все эти приседания? Чем-то GC плох? Java/Go – ну ведь явно можно быстрее будет ту же систему написать, если нет необходимости удовлетворять компилятор.
ИД>А если взять библиотеки, которые cargo вытащит и соберет без всякий приседаний (CMake... уффф...), то вообще песня. Надо че-нить распараллелить, например, ускорить запуск? rayon, пара строк кода и система типов обеспечит правильную синхронизацию (ну или укажет, где сломается). CLI? clap+structopt, типизированные структуры из параметров командной строки. И так далее.
Да, тут я на 100% согласен – CMake это та еще адища.
ИД>Много библиотек, конечно, не хватает ещё, например, вся "взрослая" XML инфраструктура отсутствует (XML Schema, XPath).
Но ведь и нормальный манеджер пакетов и зрелый набор библиотек есть в Java/Go/C#. Это я к тому, что если уж говорить про Rust, то, наверное, для тех случаев когда каждая миллисекунда на счету, но описываемый случай явно не такой.
Здравствуйте, so5team, Вы писали:
S>Интересно, а можно где-то посмотреть на примеры простого, легко поддерживаемого и расширяемого кода на Go?
Ну, как ты понимаешь, показать код который был у нас я не могу, тут придется просто поверить на слово, что было проще, легче и понятнее чем в случае с C++... но вполне можно глянуть в какой-нибудь активный проект и, при желании, найти там как подтверждение моим словам, так и что-то не читабельное и сказать что я вру
Здравствуйте, kaa.python, Вы писали:
KP>Но ведь и нормальный манеджер пакетов и зрелый набор библиотек есть в Java/Go/C#. Это я к тому, что если уж говорить про Rust, то, наверное, для тех случаев когда каждая миллисекунда на счету, но описываемый случай явно не такой.
Да, если перевести разговор в русло "почему не Java/Go/C#", то у меня нет хорошего ответа. Я первое время за Java агитировал.
Мне кажется, что Rust нам позволит делать интересные штуки, но я слишком люблю Rust, чтобы адекватно оценивать . Посмотрим, как пойдёт.
