Да, в Украине это хайповая тема. Недавняя отмена НДС на импорт очень способствует. Теперь ждём роста конкуренции среди логистики и падения средней цены оборудования для электростанций с 500$ до 300$ за киловатт. По моей улице каждый месяц (в сезон) новые инсталляции панелей.
Воду можно конденсировать (фильм Дюна, как пример).
Воду можно опреснять при бесконечно дешевой электроэнергии.
Воду можно замкнуть в системе производства еды, и незначительно восполнять по мере потерь.
По поводу ЭЭ.
Существуют места на планете где есть огромный избыток ветра, геотермальной энергии, солнца или приливных сил.
Зачастую земля (или вода) в этих районах наименее заселена.
Там можно концентрированно делать стационарные или плавающие гигафабрики еды. Там же, по причине низкой плотности населения, проще защищать инлеллектуальную собственность.
Раньше это были «зеленые», экология и субсидии, а теперь это тупо экономика — вкладывать бабло в возобновляемые источники и электромобили тупо выгодней, чем в газ/нефть и т.д. А деньги, как известно, делают деньги и поэтому будет экспонента
К сожалению есть ненулевая вероятность того, что денег на обслуживание безкарбоновой экономики потребуется меньше. Гораздо меньше.
Сложнее станет получение сопоставимого дохода от сеньоража.
Отпадут огромная доля геологоразведки, георадаров, оборудования для бурения, RnD в бурение, трубопроводы и трубопроводные заводы, танкеры, бензовозы, двс, глушители, топливные фильтры, заправки, угольные шахты, огромная доля ЖД перевозок, инвестиции и акции во всё это и многое другое что с ним связано и обслуживает эту сферу.
В оптимистичном сценарии весь этот капитал перетекает в другие сферы, строительство, медицина, космос, память DDR18 и многое другое и экономика работает как и раньше. Товары станут на треть или две трети дешевле, тк это доля топлива для логистики.
Все денежные потоки направятся на сферы не связанные с топливом, удешевятся кредиты для них, что ещё больше удешевит товары для людей.
В пессимистичном сценарии идет кризис похожий на «Великую депрессию», только теперь пузырём будет не сельское хозяйство южных штатов и железные дороги северных, а нефтяной пузырь и всё что с ним связано. В пессимистичном сценарии при слишком позднем переходе на возобновляемую и перерабатываемую экономику, этот переход может оказаться слишком тяжелым и неподъемным для локальных инвесторов многих стран.
Вождение — это не страшно. А вот органическое сельское хозяйство, где лазерные турели с распознаванием образов могут испепелять и\или компостировать колорадских жуков, и параллельно обеспечивать охрану периметра. Где посевной материал становится коммерческой тайной крупнейших корпораций, и может произойти так, что клубни картофеля или топинамбура банально негде уже взять. Где технологии уже не требуют подвода воды и электроэнергии. Уже мозг рисует определённые фантазии.
У нас на проекте лет 5 назад купили для ДНК исследований. Около 90+ потоков и 1 ТБ памяти.
По опыту могу сказать что 1ТБ уже не кажется чем то экстаординарным в этой сфере, всё равно приходится оптимизировать структуры данных что бы меньше было оверхеда и фрагментации.
На роадмапе у нас уже стоят числодробилки на десятки петабайтов исходных данных, сколько там понадобится памяти — боятся даже подумать.
Мне как разработчику, безумно радует прогресс, который я вижу последние 2 года. Переход на PCI 4, DDR4\5\HBM\HMC, NVME массивы дисков, процессоры с десятками ядер, увеличение пропускной способности памяти и размера кэша процессора. Всё это даст огромный толчек биотэку и облегчит разработку софта в нём.
В этом году в Европе происходят сейсмические тренды в фотовольтаике. Падающие цены на оборудование и дешевизна капитала стимулируют установки солнечных электростанций. По текущим оценкам рынок вырос почти вдвое (80%, 20+GW), и имеется, например, дефицит инверторов, что весьма неожиданно.
По Киеву, знаю со слов производителей геошурупов, они работают почти полностью на фотовольтаику. А у производителей перфорированных ЛСТК заказы со стороны электростанций расписаны на год вперёд.
По моей статистике, вопросы про назначение и преимущества\недостатки контейнеров std::map и std::deque ставят в затруднительное положение даже разработчиков с многолетним стажем в C++.
TMP — Шаблонное метапрограммирование
CV — const volatile (qualifiers)
ABI — упомянута но не раскрыта
LTO — оптимизация линковки
PCH — pre compiled header
PGO — оптимизация по результатам профайлинга
SEH\VEH — обработчики исключений (win)
VLA — фича из C но употрбляется и в С++ контексте
Да, основной мотиваций UFC в с++ Саттер как раз называет автодополнение в IDE (discoverability), о котором я писал.
Но если его примут, все алгоритмы всё еще принимают итератор первым элементом, или executionPolicy. Поэтому, без STL 2.0, выгода сомнительна иначе будет ещё одна тысяча новых перегрузок.
В тоже время концепты потенциально обещают discoverability, тк уже есть какой никакой но критерий для фильтрации аргументов, и увода внимания с UFC на задний план.
Я думаю, UFC имеет шанс только после reflection, тк Саттер все свои маркетинговые силы бросил в этом направлении.
Компилятору без разницы, что там — str.split() или split(str), машинный код будет одинаков. А человеку удобнее и понятнее str.split()
А где проходит граница что помещать в класс, а что не помещать?
Весь STL был основан на принципах SR и DI, ещё до того как эти принципы были сформулированы.
Если поместить в std::string порождающие паттерны как типичный split, то дело на этом не закончится. Будут те кто недоволен отсутсвием членов класса: toLower() toUpper() toUtf() toAnsi() toLatin() readFromFile() bitBlt() getKerningsPairs() regExSearch() find() boyer_moore_find() replace(). А так же будут недовольные тем, что split`а нет во всех остальных контейнерах и писать обобщённый код — стало невозможно.
Сплит элементарно делается через std::find, я чуть ниже привёл пример. Вместо функтора можно использовать outiterator, будет похоже на Qt, но теряется гибкость и производительность в некоторых сценариях где создание временной строки не требуется.
я хочу написать str.split(delimiter), это абсолютно естественно.
Наблюдая за своими учениками, я в принципе понял почему C++ не любят те кто имеет опыт с других языков.
Типичный программист нажимая точечку в своей IDE ожидает выпадающего списка того, что можно сделать со строкой.
Что же он видит в С++? А ровным счетом ничего, со строкой ничего нельзя сделать, с вектором, листом… только положить элемент да и достать. Ни сплита, ни ввода вывода, ни поиска, ни конвертаций, ничего. Тут он делает умозаключение что библиотека в С++ нефункциональная и переключается на другой язык.
Но в С++ алгоритмы и контейнеры не связаны. В любой алгоритм можно подставить любую сущность, и мы имеем комбинаторный взрыв того, что мы можем сделать.
Например идиоматическая реализация split которой я учу:
template <typename Iter, typename Sep, typename F >
void split( Iter first, Iter last, const Sep& t, F f )
{
while ( true )
{
auto found = std::find( first, last, t );
f( first,found );
if ( found == end )
break;
first=++found;
}
}
Хороший студент её пишет без гугла за 5 минут, надо знать только что существует группа алгоритмов std::find. И в результате имеем функцию которая может посплитить что угодно что имеет итераторы (строки\контейнеры\стримы\корутины), а в качестве разделителя может быть как один элемент так и группа. А так как она принимает лямбду, то мы никак не ограничены тем, куда и как сериализовывать кусочки, а так же не создаём тысячи мелки объектов на куче. При небольшом (5%) изменении этой функции, мы можем получить вариант который будет векторизироваться или распараллеливаться. Или же можем получить сплит, работающий на этапе компиляции.
Всего лишь одна функция, но она показывает поистине впечатляющие возможности. 8 строк кода благодаря которым можно расплитить что угодно, и почти как угодно, и мы никак не ограничены типом результата. Поэтому мало знать С++, нужно понимать идеи которые стоят за этим языком.
Он рвёт в клочья в определенном наборе задач, но слишком сильно удорожает разработку «in general».
Да дороже. Сейчас чаще получается рейты у плюсовиков выше, а доступность дешёвых ниже. Но ведь это не проблема языка, а резко возросший спрос рынка. Вот, например, в Киеве зашло около 10 крупных проектов, и спылесосили они всё что было доступно аж до уровня 4000usd по зарплате.
Понятное дело, что многие сферы, включая эмбеддед, перешли на более доступные альтернативы, и писать формочки/мобильные приложения/казуалки готовы на чем угодно только не С++. Шесть лет назад ситуация была сильно противоположная, думаю развитие языка дало сильный стимул рынку.
Не понятно почему Embedded лучше на C. C++ в чем — то уступает? Если это размер бинарника, то с отключенным rtti + exceptions отличия не должны быть существенно заметны для идентичного кода. В тоже время гораздо больше возможностей, огромная библиотека и выразительные конструкции которых нет в C. Яркий пример constexpr массивы которых порой очень не хватает и многие пишут кодогенераторы (частотные фильтры, флэш таблицы тригонометрии и прочее подобное).
Если это не совсем экстремальный эмбеддед с сотнями байт памяти, а что то уже за 5$ (cpu+ram), то там уже можно ставить boot to Qt и иметь вполне достойный инструментарий.
Не понятно почему многопоточное нельзя удобно писать на C++. Применяя правильные паттерны и абстракции я ни разу за 5 лет (Серверное ПО 100+ процессорных ядер) не столкнулся о проблемах о которых спрашивают на собеседованиях( deadlocks, race conditions, false sharing, memory barriers и пр). Более функционального и более удобного апи для векторизации и распараллеливания и многопоточности чем в с++ вообще мало где есть.
Опять же непонятно, почему прототипировать лучше на каком то языке, отличном от того, на котором будет разработка продукта. Поддерживать 2 и более кодовых базы в согласованном состоянии это невероятно сложно даже в рамках одного языка программирования. Даже если это 2к строк канонического+сайнтифик R\perl\python с 60% изменений, но которые дифф не может вообще никак сопоставить — это ад, и порой проще запортировать заново.
Таким образом я не вижу для каких задач С++ подходил бы лучше чем C#/Java, Си/Rust, TypeScript, python.
А если мыслить категориями не задач, а рыночными нишами?
Сколько на этой неделе можно нанять разработчиков на Rust?
Какой процент разработчиков на python готовы писать и отвечать за написанное в многопоточной среде?
Сколько можно найти C# девелоперов с многолетним опытом в эмбеддед и линукс?
Так или иначе рыночные ниши фрагментировались както, библиотеки в предметных областях написались в определенных исторических условиях, специалисты выучились и набрались опыта. Решать задачи нестандартными методами\языками\специалистами из других областей можно, но дорого.
Фича языка от этого никуда не денется.
Да, в C++ есть многое, что не нравится многим другим.
И ктото, возможно, считает также что авторы UB или aliasing`а или Elvis operator`а должны быть к том же котле.
Особенно есть множество фич которые можно использовать во вред или неправильно. Но это не повод обижать авторов какой то фичи, а повод задуматься о причине по которой она появилась в языке.
Так же все эти фичи делают C++ таким какой он есть, не похожем на все остальные.
А ещё отдельный котёл в аду должен быть предусмотрен для того, кто решил, что возможность опускания имён параметров в объявлении функций — это нормально.
А если это tag dispatch?
Там не принято именовать фейковые аргументы. Варнинги одна из причин.
Воду можно опреснять при бесконечно дешевой электроэнергии.
Воду можно замкнуть в системе производства еды, и незначительно восполнять по мере потерь.
По поводу ЭЭ.
Существуют места на планете где есть огромный избыток ветра, геотермальной энергии, солнца или приливных сил.
Зачастую земля (или вода) в этих районах наименее заселена.
Там можно концентрированно делать стационарные или плавающие гигафабрики еды. Там же, по причине низкой плотности населения, проще защищать инлеллектуальную собственность.
К сожалению есть ненулевая вероятность того, что денег на обслуживание безкарбоновой экономики потребуется меньше. Гораздо меньше.
Сложнее станет получение сопоставимого дохода от сеньоража.
Отпадут огромная доля геологоразведки, георадаров, оборудования для бурения, RnD в бурение, трубопроводы и трубопроводные заводы, танкеры, бензовозы, двс, глушители, топливные фильтры, заправки, угольные шахты, огромная доля ЖД перевозок, инвестиции и акции во всё это и многое другое что с ним связано и обслуживает эту сферу.
В оптимистичном сценарии весь этот капитал перетекает в другие сферы, строительство, медицина, космос, память DDR18 и многое другое и экономика работает как и раньше. Товары станут на треть или две трети дешевле, тк это доля топлива для логистики.
Все денежные потоки направятся на сферы не связанные с топливом, удешевятся кредиты для них, что ещё больше удешевит товары для людей.
В пессимистичном сценарии идет кризис похожий на «Великую депрессию», только теперь пузырём будет не сельское хозяйство южных штатов и железные дороги северных, а нефтяной пузырь и всё что с ним связано. В пессимистичном сценарии при слишком позднем переходе на возобновляемую и перерабатываемую экономику, этот переход может оказаться слишком тяжелым и неподъемным для локальных инвесторов многих стран.
По опыту могу сказать что 1ТБ уже не кажется чем то экстаординарным в этой сфере, всё равно приходится оптимизировать структуры данных что бы меньше было оверхеда и фрагментации.
На роадмапе у нас уже стоят числодробилки на десятки петабайтов исходных данных, сколько там понадобится памяти — боятся даже подумать.
Мне как разработчику, безумно радует прогресс, который я вижу последние 2 года. Переход на PCI 4, DDR4\5\HBM\HMC, NVME массивы дисков, процессоры с десятками ядер, увеличение пропускной способности памяти и размера кэша процессора. Всё это даст огромный толчек биотэку и облегчит разработку софта в нём.
По Киеву, знаю со слов производителей геошурупов, они работают почти полностью на фотовольтаику. А у производителей перфорированных ЛСТК заказы со стороны электростанций расписаны на год вперёд.
CV — const volatile (qualifiers)
ABI — упомянута но не раскрыта
LTO — оптимизация линковки
PCH — pre compiled header
PGO — оптимизация по результатам профайлинга
SEH\VEH — обработчики исключений (win)
VLA — фича из C но употрбляется и в С++ контексте
Но если его примут, все алгоритмы всё еще принимают итератор первым элементом, или executionPolicy. Поэтому, без STL 2.0, выгода сомнительна иначе будет ещё одна тысяча новых перегрузок.
В тоже время концепты потенциально обещают discoverability, тк уже есть какой никакой но критерий для фильтрации аргументов, и увода внимания с UFC на задний план.
Я думаю, UFC имеет шанс только после reflection, тк Саттер все свои маркетинговые силы бросил в этом направлении.
А где проходит граница что помещать в класс, а что не помещать?
Весь STL был основан на принципах SR и DI, ещё до того как эти принципы были сформулированы.
Если поместить в std::string порождающие паттерны как типичный split, то дело на этом не закончится. Будут те кто недоволен отсутсвием членов класса: toLower() toUpper() toUtf() toAnsi() toLatin() readFromFile() bitBlt() getKerningsPairs() regExSearch() find() boyer_moore_find() replace(). А так же будут недовольные тем, что split`а нет во всех остальных контейнерах и писать обобщённый код — стало невозможно.
Наблюдая за своими учениками, я в принципе понял почему C++ не любят те кто имеет опыт с других языков.
Типичный программист нажимая точечку в своей IDE ожидает выпадающего списка того, что можно сделать со строкой.
Что же он видит в С++? А ровным счетом ничего, со строкой ничего нельзя сделать, с вектором, листом… только положить элемент да и достать. Ни сплита, ни ввода вывода, ни поиска, ни конвертаций, ничего. Тут он делает умозаключение что библиотека в С++ нефункциональная и переключается на другой язык.
Но в С++ алгоритмы и контейнеры не связаны. В любой алгоритм можно подставить любую сущность, и мы имеем комбинаторный взрыв того, что мы можем сделать.
Например идиоматическая реализация split которой я учу:
Хороший студент её пишет без гугла за 5 минут, надо знать только что существует группа алгоритмов std::find. И в результате имеем функцию которая может посплитить что угодно что имеет итераторы (строки\контейнеры\стримы\корутины), а в качестве разделителя может быть как один элемент так и группа. А так как она принимает лямбду, то мы никак не ограничены тем, куда и как сериализовывать кусочки, а так же не создаём тысячи мелки объектов на куче. При небольшом (5%) изменении этой функции, мы можем получить вариант который будет векторизироваться или распараллеливаться. Или же можем получить сплит, работающий на этапе компиляции.
Всего лишь одна функция, но она показывает поистине впечатляющие возможности. 8 строк кода благодаря которым можно расплитить что угодно, и почти как угодно, и мы никак не ограничены типом результата. Поэтому мало знать С++, нужно понимать идеи которые стоят за этим языком.
Да дороже. Сейчас чаще получается рейты у плюсовиков выше, а доступность дешёвых ниже. Но ведь это не проблема языка, а резко возросший спрос рынка. Вот, например, в Киеве зашло около 10 крупных проектов, и спылесосили они всё что было доступно аж до уровня 4000usd по зарплате.
Понятное дело, что многие сферы, включая эмбеддед, перешли на более доступные альтернативы, и писать формочки/мобильные приложения/казуалки готовы на чем угодно только не С++. Шесть лет назад ситуация была сильно противоположная, думаю развитие языка дало сильный стимул рынку.
Если это не совсем экстремальный эмбеддед с сотнями байт памяти, а что то уже за 5$ (cpu+ram), то там уже можно ставить boot to Qt и иметь вполне достойный инструментарий.
Не понятно почему многопоточное нельзя удобно писать на C++. Применяя правильные паттерны и абстракции я ни разу за 5 лет (Серверное ПО 100+ процессорных ядер) не столкнулся о проблемах о которых спрашивают на собеседованиях( deadlocks, race conditions, false sharing, memory barriers и пр). Более функционального и более удобного апи для векторизации и распараллеливания и многопоточности чем в с++ вообще мало где есть.
Опять же непонятно, почему прототипировать лучше на каком то языке, отличном от того, на котором будет разработка продукта. Поддерживать 2 и более кодовых базы в согласованном состоянии это невероятно сложно даже в рамках одного языка программирования. Даже если это 2к строк канонического+сайнтифик R\perl\python с 60% изменений, но которые дифф не может вообще никак сопоставить — это ад, и порой проще запортировать заново.
А если мыслить категориями не задач, а рыночными нишами?
Сколько на этой неделе можно нанять разработчиков на Rust?
Какой процент разработчиков на python готовы писать и отвечать за написанное в многопоточной среде?
Сколько можно найти C# девелоперов с многолетним опытом в эмбеддед и линукс?
Так или иначе рыночные ниши фрагментировались както, библиотеки в предметных областях написались в определенных исторических условиях, специалисты выучились и набрались опыта. Решать задачи нестандартными методами\языками\специалистами из других областей можно, но дорого.
Главное не тащить это в публичный интерфейс!
Да, в C++ есть многое, что не нравится многим другим.
И ктото, возможно, считает также что авторы UB или aliasing`а или Elvis operator`а должны быть к том же котле.
Особенно есть множество фич которые можно использовать во вред или неправильно. Но это не повод обижать авторов какой то фичи, а повод задуматься о причине по которой она появилась в языке.
Так же все эти фичи делают C++ таким какой он есть, не похожем на все остальные.
А если это tag dispatch?
Там не принято именовать фейковые аргументы. Варнинги одна из причин.