Обновления компиляторов C, C+, Fortran

Ответ «Да», но вам очень хочется прикопаться к столбу.

Так и надо было ответить «да», а не флудеть.

пердолиться

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

Язык без экосистемы/тулинга никому не нужен. См. D.

Зачем не смотреть на D, если есть куча языков, прекрасно живущих без пм. Не говоря о том, что твой Раст с ПМ тут вообще оффтопик.

Если либ 2009 и заказчик, в том числе в другом государстве, предполагает работу по закрытым каналам, то тебе и так придётся пердолиться, только не факт, что меньше.

есть куча языков, прекрасно живущих без пм

Какие из них входят хотя бы в топ 20-30 по популярности?

Если либ 2009 и заказчик, в том числе в другом государстве, предполагает работу по закрытым каналам, то тебе и так придётся пердолиться, только не факт, что меньше.

И что это меняет? Мне либы на по почте пришлют или как?

Все популярные и входят, особенно в области HPC.

И что это меняет? Мне либы на по почте пришлют или как?

Догадаешься, не маленький.

Не из репозитория же с проектами в стадии альфа их качать.

Вы на Марсе компиляете?

Я не понял, под «ПМ» вы понимали пакетный менеджер, а не паттерн-матчинг?

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

А уж при наличии интернета и ведении проекта на чём-то вроде github всякие third party зависимости можно тянуть без каких-то пакетных менеджеров, что давно все и делают, при необходимости.

А когда еще у заказчика толпа девопсов есть, которым делать нехрен — они на дженкенсе накручивают пайплайн для непременного скачивания и пересборки всех зависимостей с гитхаба, из-за которых воркеры дженкинса умирают страшной смертью под нагрузкой из падучих скриптов и кукбуков... и потом еще девопсы сносят проэкт ради которого все, потому что... запиленный разработчиками в обход ихней CI-мафии конфиг «не соотвествтует нейминг конвеншену» :) Из-за чего толпа девопсов посылается менеджером проекта лесом и сборки релизов идут с подкроватного хостинга с за 5 минут поднятого дженкинса на компе разработчика с предсобранными «раз и навсегда» (на время разработки) зависимостями, чтоб каждый минорный апдейт зависимостей не крэшил биржевые серваки в продакшене, которым нафиг не уперлись минорные апдейты ненужно :)

Это уже из разряда «шило в жопе»

Сириус бузинес. Вопросов нет.

что давно все и делают, при необходимости.

Только не говорите субмодули.

Осталось понять зачем их создают по три штуки в год.

Кто в 16 лет не мечтал запилить свой язык программирования, который наконец-то позволит писать всё и сразу, у того нет сердца. А кто и в 40 лет продолжает этим заниматься — у того нет мозгов.

Опять максимализм?

хуже, это лурк

Build-сервера Debian собирают все пакеты исключительно offline.

Осталось понять зачем их создают по три штуки в год.

Как минимум из очевидных причин можно перечислить:

• потому, что могут;
• потому, что подросло поколение, взращенное на npm, pip, rubygems и подобных вещах. Которое не может представить себе мира без централизованного хранилища пакетов для их любимого языка;
• потому, что есть мнение, что нужно снизить порог входа в C++ и одной из таких возможностей является менеджер зависимостей, позволяющий собрать нужные библиотеки буквально по щелчку;
• потому, что при всем многообразии решаемых на C++ задач и при всем многообразии условий, в которых это происходит, у любого менеджера зависимостей обнаруживается фатальный недостаток, для устранения которого создается альтернативный менеджер зависимостей…

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

• собственное хранилище использованных зависимостей. Чтобы разворачивание проекта на новой машине у разработчика не зависело от того, заблокирован ли github каким-нибудь *надзором или блокирует ли сам github пользователей из какого-либо географического региона. А так же не зависеть от эмоциональных порывов разработчиков сторонних библиотек, которые могут всё и всех послать и удалить свое творение к херам;
• возможность просто и самостоятельно подменить «ванильную» версию зависимости на собственную пропатченную версию (либо на версию, которая еще не была официально опубликована авторами зависимости).

Ну и как-то польза от централизованного репозитория зависимостей в таких условиях становится весьма условно. Т.е. начинающему C++разработчику Васе Пупкину такой репозиторий позволит быстренько собрать какой-нибудь HelloWorld. Но вот тем, кто пишет софт за деньги, приходится держать собственные инстансы Conan-а, собственные форки vcpkg или еще что-нибудь в таком роде.

А чем плох vcpkg?

Кто в 16 лет не мечтал запилить свой язык программирования, который наконец-то позволит писать всё и сразу, у того нет сердца.

Шила в заднице.

Ну вот cargo это всё умеет.

И как умения cargo помогают решать проблемы C++?

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

Это каких проблем, например?

Например, разрабатывать код, который должен будет собираться как новыми компиляторами, так и компиляторами 7-8-9-… летней давности. В том числе и умеющим работать с разными версиями зависимостей.

Разные версии зависимостей в карго подтягивать нетрудно, conditional compilation в расте сделана не хуже чем в крестах.

С первой проблемой согласен.

Еще примеры?

Вы с какой целью интересуетесь?

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

Тогда мне было бы неплохо убедиться, что вы сами понимаете о чем вам говорят. Судя вот по этому:

Разные версии зависимостей в карго подтягивать нетрудно

Вы не понимаете. Так какой для меня смысл продолжать?

Из желания услышать новые аргументы против раста.

Нет цели высказать аргументы против Rust-а. Если у вас есть возможность и желание использовать Rust – используйте на здоровье.

Тут речь о том, что рецепты, которые, как думают адепты Rust-а, хорошо работают для Rust-а, вовсе не обязательно должны подходить для C++.

не понимаете

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

Нет цели высказать аргументы против Rust-а

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

речь о том

Вот именно, речь была о том. Однако я вас спросил о другом, не так ли?

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

Нет. Речь о том, что вы делаете софтину X, которая зависит от библиотек Y и Z. И пользователь Ваня собирает вашу софтину на своей платформе, где Y и Z одной версии, а пользователь Федя – на своей платформе, где Y и Z другой версии. А вашей софтине нужно в момент компиляции (или в момент настройки системы сборки) понять, какие именно версии Y и Z доступны здесь и сейчас. И что с этим сделать.

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

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

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

Ну и я нахожу непродуктивным, когда в обсуждение проблем C++ приходят любители других языков и отвлекают от обсуждения проблем C++.

Такая детская реакция на критику. Эпичненько.

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

Вот кстати, пара проектов на D из области гидродинамики:

• EbbCFG пилится одиночкой более пяти лет
• Eilmer уже посерьезнее проект, активно развивается в одном европейском университете больше четырех лет

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

Они просто троллят по-моему :)

А вашей софтине нужно в момент компиляции (или в момент настройки системы сборки) понять, какие именно версии Y и Z доступны здесь и сейчас. И что с этим сделать.

В расте нет динамической линковки. Поэтому и проблемы такой нет.

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

В общем решаем проблему, которой нет.

когда в обсуждение проблем C++ приходят любители других языков и отвлекают от обсуждения проблем C++.

Первым сюда пришёл любитель D и начал орать про ужасный раст. Но виноваты конечно растоманы. /0

потому что куда больше либ написано на сишечке или плюсах

Очень спорное заявление. Очень многих повседневных либ для плюсов тупо нет. А каждый раз писать врапперы для сишки - влом. А потом оказывается что ваш код не собирается MSVC или apple clang, ибо у них вечно какие-то странные реализации стандарта. В общем городская легенда, не более.

Уж чего-чего, а критики от вас никогда не было.

Я не критиковал D. Я задавал вполне конкретные вопросы лично вам. Раст я вообще не упоминал.

В расте нет динамической линковки.

Вот это поворот!

Первым сюда пришёл любитель D и начал орать про ужасный раст

Такая детская реакция на критику

nuff said

Почему это вас удивляет?

А как же --crate-type=lib в противовес --crate-type=staticlib?

Ну и вообще:https://doc.rust-lang.org/1.9.0/book/advanced-linking.html

У Rust нет стабильного ABI. Поэтому это просто заглушки. Да, генерировать дин. либы он может, но их никто не использует.

PS: правильный флаг --crate-type=dylib

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

у меня нет слов.

Похоже это тренд в современных языках, та же засада с Go…

В расте нет динамической линковки. Поэтому и проблемы такой нет. В общем решаем проблему, которой нет.

Я уже и забыл насколько сильно ваше скудоумие помноженное на совершенно убогий (даже в сравнении с моим никаким) кругозором искажает ваше восприятие реальности… :(

Упомянутая мной проблема не имеет отношения к типу линковки. И вполне себе проявляется и на статических либах, и даже на header-only.

Для многих платформ это так

https://golang.org/doc/go1.5#compiler

For the amd64 architecture only, the compiler has a new option, -dynlink, that assists dynamic linking by supporting references to Go symbols defined in external shared libraries.

А что плохого в таком подходе? Безусловно, он не лишен недостатков, но и достоинств у него немало.

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

Почему вам нравится показывать выставлять себя безграмотным и непоследовательным?

Такая детская реакция на критику. Эпичненько.

Уж чего-чего, а критики от вас никогда не было.

Я не критиковал D.

Вы в следующем своем же посту противоречите самому себе. Или вы хотите сказать, что критиковали меня?? Спрашивая меня, есть ли на D парсер true type, вы критиковали меня? Что за ерунду вы написали?

Первым сюда пришёл любитель D и начал орать про ужасный раст.

Во-вторых потом сюда пришел любитель Раста и стал орать про ужасный D. А виноваты дишники. Это - вашими словами. А во-первых, придержите свою лексику, эмоции в другом месте проявляйте.

Язык без экосистемы/тулинга никому не нужен

Маня, бегом побежала показывать экосистему/тулинг в говнорасте

А что плохого в таком подходе?

Можно посмотреть дискуссию в каментах к https://stackoverflow.com/a/56771892/2170527

Или вы хотите сказать, что критиковали меня?

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

Да, мне смутило ваше высказывание об удобстве биндингов в D. И я попросил вас объяснить в чём конкретно это выражается (уже не первый раз, кстати). Но так ничего конкретного не услышал. Вместо D тут мог быть любой другой язык. Роли это не меняет.

эмоции в другом месте проявляйте

Но истерику закатил не я…

Упомянутая мной проблема не имеет отношения к типу линковки.

Тогда и проблемы нет, ибо cargo build и всё. Но вы можете продолжать язвить.

Проиллюстрирую:

• Обновления компиляторов C, C+, Fortran
• Обратите внимание на D. «Он продуктивен как Питон, но быстр как С++.»
• В чём это выражается?
• «А в Расте в угоду безопасности было принесено все.» И не буду я «беседовать с хейтерами». Бе-бе-бе!

Ну вот как это ещё назвать?