Стандарт C++20 утверждён

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

Другое дело в том, каков размер этого остатка.

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

Тот же Go спустя 5 лет после выхода Go 1.0 был куда как более востребованным.

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

Эта возможность и в C++ есть. Только вот подавляющему большинству нужно код клепать. Здесь и сейчас. А не язык развивать.

Так что если от названия «Rust» возбуждения не случается, а нужен практичный инструмент для текущих задачь, то C++ вполне себе еще конкурентоспособен.

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

Вот-вот. Это совсем не значит, что нужно закопать другие языки и перейти всем на Rust.

Ну тут народ вроде как высказывался, что надо закапывать то, что не С++….

А если ты готов писать на С++20 сейчас, то что тебе мешает сразу поставить раст и забыть как страшный сон про совместимость с С++98 и С?

Как по мне, так это похоже все-таки на попытку закопать именно С++. Но не просто его закопать, а непременно взять ему на замену Rust.

Ну можно писать на свифте или даже на го. А лучше на хаскеле. Лишь бы подальше от крестов.

Ну можно писать на свифте или даже на го. А лучше на хаскеле. Лишь бы подальше от крестов.

Можно писать на чем угодно, а можно просто трепаться и быть балаболом.

Тем не менее в соседнем мониторе у меня открыт кутекреатор, в котором строчится код на С++ (в перерывах между постами).

Лишь бы подальше от крестов.

Заставляют писать не крестах?

С++20 страдает

Пока он страдает от отсутствия реализаций: в gcc c++2a, например, основан на промежуточных черновиках, которые уже успели поменяться и сами gcc предупреждали в документации, что не гарантируется совместимость с конечным вариантом. Не говоря о том, что была реализована лишь малая часть новшеств. Но ждать действительно пару лет придётся пока всё-всё запихнут.

Кстати, по поводу стандартов С++, посоветуйте плиз бекпорт стля С++14 на С++11. Самое главное, чтоб optional там был, причем совместимый (чтобы либы, его узающие, компилились под С++11 без правок).

чтоб optional там был

optional начиная с C++17

Ну есть либа котороая проверяет наличие хедера optional и видит что он есть в режиме С++11, в то время как внутри ничего нет. И облом

Ищите вот у этого товарища: https://github.com/martinmoene

В частности, смотрите на optional-lite, variant-lite, expected-lite.

Странный форум.
Говорят о Си, C++, спорятся, ругают друг друга, а возникает задача и все УЧИТЕЛИ «сдуваются».

Владимир

С задачами – в jobs

С задачами – в jobs

Вообщем то вы правы.
Но речь шла не о задачах студентов, … и …

Владимир

у голэнг различима по истории волновость промоушенна на дистанции ужо 12(почти) лет - это например видно по литературе в частности

и не удивительно что модель распространения голэнг похожа на распространение С на дистанции 1975-1984(и далее)

ваще социальная история у программировании присутствует в полный рост

И как такое подсунуть при компиляции либы? -Dnonstd=std чтоле?

Ой, простите, я думал, что вы хоть что-то в C++ понимаете. А раз нет, то спросите кого-нибудь, кто готов тратить свое время на ваше обучение.

Тоесть по-вашему я должен был предложить чтото вроде

namespace std
{
using namespace nonstd;
}

Вот только куда это пинать в чужой либе? В принципе я конечно нарушаю порядок вещей когда интегрирую либу в свой проект, чтоб не было геморроя с зависимостями. Но может есть какой кошерный способ разрулить подобные траблы?

Не прошло и 30 лет как появилимь модули и трансформации коллекций! Наконец-то можно начинать программировать на C++!

Не прошло и 30 лет как появилимь модули

В Паскале модули были с рождения. Почему только сейчас привезли модули в C++?

Судя по тому, что несколько лет подряд на StackOverflow Rust признавался как самый любимый (или самый желанный?) язык программирования

Да фигня это. Это из-за глупых фанатов этого недоязычка, которые не заняты реальным делом, кроме пропаганды, а поэтому они могут успешно влияеть на попадание в топ по числу камментов и взаимных лайков/плюсов/апов друг другу.

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

В Паскале модули были с рождения

Нет

ИМХО, C++ники не правильно оценивают то, с какой стороны Rust заходит в индустрию. Многие C++ники (в том числе и я в недавнем прошлом) думают, что Rust должен заменять C++ в проектах, которые уже пишутся на C или C++. Или что Rust должен использоваться сишниками/плюсовиками при написании нового кода вместо C++.

А на самом деле в Rust переходят всякие питонисты, рубисты и прочие хипсте^W джаваскриптеры. Т.е. люди, которые небезопасных языков никогда в жизни не видели и с нативными языками никогда дел не имели, сидели писали свои тормозные поделия на Python/Ruby/JS/Perl и горя не знали. Но вот те, кто эксплуатирует этот замечательный софт стали задавать вопросы: а почему нам нужно 100 серверов, а не 10? Или почему у вас Python-овский код работает сутки, а у конкурентов всего 2 часа?

И оказалось, что с динамически-типизированной скриптоты нужно куда-то перелазить.

Ну не на чистый же Си, и уж тем более не на C++. А вот на всякие Go с Rust-ами – самое то.

И вот вся эта публика, выросшая в удобных и безопасных экосистемах рубей и питонов, никогда в сторону C++ не посмотрит. Что, в общем-то, объяснимо.

А вот в сторону Rust-а как раз и смотрит. В том числе и потому, что модно-молодежно. Хотя больше из-за скорости, безопасности и ориентированной на современных разработчиков экосистемы.

И вот вся эта публика, выросшая в удобных и безопасных экосистемах рубей и питонов, никогда в сторону C++ не посмотрит.
А вот в сторону Rust-а как раз и смотрит.

Я честно говоря в этом сомневаюсь. Я искренне не понимаю, как человек, который не привык управлять памятью и не различает стек от кучи, вдруг перейдет на Раст, где нужно еще и лайфтайм понимать, и скоупы и прочее. У меня другое наблюдение - люди, который выбрали Питон за простоту и продуктивность на Раст не перейдут в принципе. Так как Раст противоречит этим определениям. Хотя бы потому, что заставляет человека задумываться о вещах, о которых раньше питонист и не задумывался.

Я честно говоря в этом сомневаюсь.

Тем не менее время от времени статьи типа вот такой на глаза попадаются:

https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

https://www.rust-lang.org/static/pdfs/Rust-Tilde-Whitepaper.pdf

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

Да ну, люди в здравом рассудке из си++ никогда в раст не пойдут

Звучит как попытка самооправдания :)

Да они изначально не тот язык выбрали. Забавно, что по второй ссылке первой причиной для перехода на Раст был личный интерес разработчиков, которые считают, что использование Раста улучшит их навыки в новой для них области:

Engineers have a sense that Rust genuinely improves their marketable skills in an area that is very different from what they're already good at.

Стильно, модно, молодежно.

Сейчас у плюсов кривая обучения в худшем положении чем у Раста из-за того, что в плюсах многие вещи исторически сложились без какой-либо системы и их нужно тупо запоминать. В Расте хоть и сложнее теория, но она более логичная и там нужно запоминать правила. Однако вы совершенно правы в том, что проблемы в плюсах это проблемы более зрелого языка, который должен совмещать и легаси, и новое. И интересно будет посмотреть, как Раст справится с этой проблемой, если дойдет вообще до этой стадии. По факту Раст точно также находится в начале неизвестного пути как и С++ когда-то, и точно также будет набивать шишки, и точно также возникнет конфликт между поддержкой старого кода и использованием новых фич. И тогда сложность вхождения в Раст будет уже другой.

Да почему не перейдут, перейдут. Только не в таких масшатабах, как позиционируется адептами Раста, а только там, где использование Раста оправдано.

И интересно будет посмотреть, как Раст справится с этой проблемой, если дойдет вообще до этой стадии.

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

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

Вот ХЗ, насколько все это достоверно, мне как-то приходится иметь дело с кодом, который эксплутируется и развивается годами, даже десятилетиями.

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

Js очень много чего ложит на проблемы и пытается выполнить код при любом раскладе, так что без понимания лайфтаймов его лучше не трогать - работать вряд ли будет, как задумано. Так что я с Вами не согласен, что для скриптоты понятия лайфтаймов и скоупов это что-то сложное, тем более для тех-же js-макак, у которых есть var и let, различающиеся именно в лайфтаймах и скоупах

развилось целое направление разработки софта, в котором само понятие легаси слабоприменимо

Есть такое

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

Такая же история

Я думаю, что и тот, и другой тип софта были всегда и будут. Но по моему мнению писать на Расте код «на выкинуть» это сурово, это больше удел скриптовых языков. А Раст все-таки больше ориентирован на проекты с большим сроком жизни.

Тут спорить не буду. А как у них с пониманием стека и кучи? Реально интересуюсь потому что я видел людей и на си/плюсах, которые смутно разбираются во всех этих понятиях. Главное что код работает. И он действительно работает. Хоть и полное уг.

у раста ооп какое-то сомнительное. с плюсами даже рядом не стоит.

Если ты всё это пишешь всерьез, то не надо, пожалуйста. И так уже давно живет стереотип, что у крестокодеров нулевой кругозор и бесконечная упертость.

Ну надо же как-то оправдать многолетние «инвестиции в осиливание цэпэпэ» :)

Если в качестве унифицированной системы управления сборкой будет CMake, то ну нахер такую унификацию.

+1

ну а что если тут кругозор не причём. Ибо познав лучшее на всякую шелуху уже не потянет.

А как у них с пониманием стека и кучи?

Вот это не знаю

Хоть и полное уг.

new на каждый чих?

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

Раст в случае этой проблемы в более выгодном положении, все-таки опыт C++ и других языков со сложной эволюцией учитывается. Поэтому несовместимые изменения выносятся в большие версии (или эпохи) на данный момент их две ‘rust 2015’ и ‘rust 2018’. При этом на уровне крейта можно задавать версию, и просто собирать старый код старой версией и при этом совместно использовать с новым кодом с новой версией. Подробнее тут https://habr.com/ru/post/432564/ В общем в теории все неплохо, на практике надо будет смотреть.

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

Как будто каждый релиз ломает совместимость, такого уже давно нет.

А Си++-сники заняты реальными делами и им не до холиваров.

Более холиварных чем Си++-сники еще поискать надо.

C vs Pascal
C++ vs Java
C++ vs Delphi
C++ vs VB
C++ vs C#
C++ vs Rust
C++ vs функциональщина
C++ vs скриптота

Как будто каждый релиз ломает совместимость, такого уже давно нет.

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

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

Жень, я с тобой еще на rsdn фронтах с немерлистами воевал :), что-то ты сильно по стариковски себя в последнее время ведешь :)
По теме можешь не давя авторитетом рассказать об остальных проблемах? Я как-то не вижу у руста больших технических проблем с совместимостью и возможностью использовать в больших проектах по сравнению с С++.

По теме можешь не давя авторитетом рассказать об остальных проблемах?

Основная проблема частных обновлений – это невозможность просто так откатиться на относительно старые версии компиляторов. Т.е. вышел Rust 1.40, адаптировали к нему кодовую базу, а когда возникла необходимость запустить её же на Rust, скажем, 1.35, то может прийти маленький пушной зверек.

Но, поскольку на Rust-е больших и долгоиграющих, широкоиспользуемых проектов нет, то это пока никого не парит.

Тогда как в C++ разработчикам каких-нибудь optional-lite или variant-lite приходится поддерживать работоспособность даже на старых компиляторах. И есть возможность в рамках, скажем, C++11, более-менее спокойно переключаться с GCC 9 до GCC 5, а то и до GCC 4.8.

Основная проблема частных обновлений – это невозможность просто так откатиться на относительно старые версии компиляторов. Т.е. вышел Rust 1.40, адаптировали к нему кодовую базу, а когда возникла необходимость запустить её же на Rust, скажем, 1.35, то может прийти маленький пушной зверек.

Как-то не вижу разницы в этом с C++. Например, не так давно мы перешли с С++98 аж сразу на С++17, на средненьком таком (~300K Loc) проекте, с заменой boost на std. И вот всего через год постепенной плавной замены, мы уже обратно никак откатится не сможем.

Но, поскольку на Rust-е больших и долгоиграющих, широкоиспользуемых проектов нет, то это пока никого не парит.

Хоть и их очень мало, но такие проекты уже есть, хотя бы и у самой моззилы. Но дело не только в этом, компилятор то единственный и смысла идти на старые версии фактически (в отличии от C++) нет.

Тогда как в C++ разработчикам каких-нибудь optional-lite или variant-lite приходится поддерживать работоспособность даже на старых компиляторах. И есть возможность в рамках, скажем, C++11, более-менее спокойно переключаться с GCC 9 до GCC 5, а то и до GCC 4.8.

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