DNF будет переписан на языке C

Существуют исследования, доказывающие обратное.

Существуют реально работающие системы, написанные на C, где нет никакого типо-маразма, которые доказывали свою работоспособность и полезность на протяжении десятков лет :-) А какая польза от упомянутых тобой исследований? :-)

Гораздо более строгой. И на порядок более выразительной.

Да. Но тем не менее, там до сих пор нельзя сделать банальное

auto do_shit(auto x, auto y) {...}

и можно будет только в C++17. Ну или через расширения GCC. Хотя облажаться с типами в плюсах конечно гораздо сложнее.

я писала разные проекты, в том числе *очень* большие. всё писалось на плюсах и С. от прошивок, системных модулей и дров до сетевого софта для серверов и федеральных систем защищённого обмена данными. проблем не вижу. также в этих проектах люди писали гуй, всякое там общение с БД и многие другие вещи на плюсах и тоже вроде никто не страдал.
я видела другие языки. но результаты компиляции с этих языков слишком тормозные, чтобы писать на них что-то работающее в более-менее реальном времени. просто есть разные задачи. для обучения студентов и питон сойдёт, но для серьёзных проектов - увы, нет.

Существуют реально работающие системы, написанные на C, где нет никакого типо-маразма, которые доказывали свою работоспособность

Вот просто открой Git ядра и посмотри количество багов в духе «мы опять вышли за границу массива» и «обожемой мы обосрались с указателем». Я только вчера очередной NULL pointer dereference в XFS поймал.

Я про стоимость разработки упомянул не просто так.

Вот просто открой Git ядра и посмотри количество багов в духе «мы опять вышли за границу массива»

И причем тут типы? Они помешают тебе выйти за границу массива?

Гораздо более строгой.

Строгость может быть признаком маразма :-)

И на порядок более выразительной.

Бугага :-)

А ну-ка, что означает вот этот код:

fut.wait_for(250ms);

тем не менее, там до сих пор нельзя сделать банальное

auto do_shit(auto x, auto y) {...}

Да и хрен с ним, честно. Есть параметризуемые типы, можно сделать свои ADT, проверки типов тоже есть - по сравнению с Си, это щастье.

Строгость может быть признаком маразма :-)

Постоянная улыбка тоже.

Ой, блин, забыл *врукопашную* вбить: «using namespace std::literals»

...и забывчивость. Впрочем, компилятор напомнит.

А ну-ка, что означает вот этот код:
fut.wait_for(250ms);

Ждет не больше чем 250мс, пока асинхронно вычислиться значение.

Ой, блин, забыл *врукопашную* вбить: «using namespace std::literals», чтобы оно приобрело семантический смысл :-)

Это тебя суфикс смущает? Это как обычная функция, и ее ес-но тоже надо откуда-то брать. Нашел к чему придраться.

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

следует ли использовать C++11

а что, не следует?

Примечательность по крайней мере начала треда в том, что всем похоже срать что эта штука будет делать

Невероятно - в новости, посвященной переписыванию на Си, идет спор о том, на что нужно переписывать.

следует ли использовать C++11

а что, не следует?

Следует, следует.

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

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

http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0123r1.pdf

В стандарте пока нету ничего такого, потому пишут свои костыли

Ты — статистическая погрешность :)

Правильно, пистон давно пора закопать

И причем тут типы? Они помешают тебе выйти за границу массива?

Вместе с непрямым доступом к памяти - да.

java.lang.String. В Java не видел других строк ни в одной библиотеке

Кому оно нахрен ненужно нужно когда есть apt-get. Да и пофиг на чем оно будет написано. rpm -i (или как оно там) отменили?

Ждет не больше чем 250мс, пока асинхронно вычислиться значение.

Правильный ответ - «всё, что угодно, в зависимости от контекста» :-)

Это тебя суфикс смущает? Это как обычная функция, и ее ес-но тоже надо откуда-то брать. Нашел к чему придраться.

Нет, меня смущает то, что в языке с «выразительной системой типов» нужно *вручную* подсовывать в единицу трансляции «using namespace std::literals», чтобы компилятор понял, какой смысл имеет суффикс «ms»! :-) И, кстати, ежели у тебя вот так:

namespace My {
namespace std {
namespace literals {

void f() {
  using namespace std;

  // ...
  g(250ms);
}

}
}
}

Всё-таки не всем нужно более менее реальное время, зачастую важнее скорость разработки и легкость поддержки.Вы пишете софт с жесткими требованиями к времени отклика, да для вас C++ это рациональное решение. Но пакетный менеджер, стандартное мобильное приложение, плеер, редактор и т.п вещи не требуют реал-тайма. Они требуют долгой поддержки и активного внедрения фич. И это могут быть вполне себе серьёзные проекты, таки как IDEA, например, или Akka. Или Django.

Я не против написания софта на крестах или си, нет. Я против использования инструментов не по назначению и высказываний в духе питон не годится для серьёзных проектов.

есть многолетняя мировая практика применения С. С компилится на любой железяке и работает быстро и эффективно

А еще программы на Си отличаются высокой безопасностью. Heartbleed не даст соврать.

Нет, меня смущает то, что в языке с «выразительной системой типов» нужно *вручную* подсовывать в единицу трансляции «using namespace std::literals», чтобы компилятор понял, какой смысл имеет суффикс «ms»! :-)

А как ему ещё об этом узнать? Из астрала?

то «using namespace std» будет означать, прежде всего, My::std::literals :-)

«using namespace std::literals» будет означать ... :-)

А как ему ещё об этом узнать? Из астрала?

Это не должно быть моей проблемой :-) Если я использовал std::async и std::future, то «ms» должен означать «миллисекунды», а не «то что я подсуну через using namespace ...» :-)

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

Я про то же. Я когда-то вручную вычищал за емаксом зависимости. Ругался аки сапожник.

До этого не замечал, что apt плохо чистит за собой.

Это не должно быть моей проблемой :-) Если я использовал std::async и std::future, то «ms» должен означать «миллисекунды», а не «то что я подсуну через using namespace ...» :-)

Эээ... А если я использую библиотеку для работы с другой хреновиной, где ms означает мертвых сурков?

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

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

Там же вроде какая-то политота с запихиванием его в какой-то другой проект по неясным причинам, а там С, а соблюдать консистентность языка для более легкого привлечения людей и интеграции модулей - благо. Просто чтобы начать проект, то надо 1) написать между модулями какой-то common.h 2) придумать кодстиль 3) придумать lint 4) придумать как модули будут взаимодействовать. Если языков программирования несколько, то это становится головной болью. Просто хочу обратить внимание что они не просто переписуют с нефиг делать. Вот непонятно зачем они такой re-org делают

Правильный ответ - «всё, что угодно, в зависимости от контекста» :-)

Хорошо, а что делает код:

let file = File::open( "file.txt" );

Открывает файл? Нет, все что угодно.

Нет, меня смущает то, что в языке с «выразительной системой типов» нужно *вручную* подсовывать в единицу трансляции «using namespace std::literals», чтобы компилятор понял, какой смысл имеет суффикс «ms»! :-)

Еще раз повторяю, суффикс ничем принципиально не отличается от функции, и было бы в корне неверно давать ему другое поведение. И никто тебе не мешает вытянуть только один суфикс через using, или все через using namespace std::literals::chrono_literals.

Heartbleed создали эксперты мирового уровня, получше чем 95%, а то и 100% участников этого треда.

Эээ... А если я использую библиотеку для работы с другой хреновиной, где ms означает мертвых сурков?

Тогда «ms» да будет определено в «другой хреновине» :-) Я же хочу просто использовать стандартные компоненты и смысл «ms» для каждого из них должен быть однозначным для них и для меня :-)

Всё-таки не всем нужно более менее реальное время

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

Открывает файл? Нет, все что угодно.

Верно :-)

Еще раз повторяю, суффикс ничем принципиально не отличается от функции, и было бы в корне неверно давать ему другое поведение. И никто тебе не мешает вытянуть только один суфикс через using, или все через using namespace std::literals::chrono_literals.

Ещё раз повторяю, аппарат типов в цепепе не выразительный, а костыльный :-) Какие-то функции, какие-то нэймспэйсы, суффиксы, когда мне просто нужно сказать «жди 250 мс» :-) Лол :-)

Ещё раз повторяю, аппарат типов в цепепе не выразительный, а костыльный :-) Какие-то функции, какие-то нэймспэйсы, суффиксы, когда мне просто нужно сказать «жди 250 мс» :-) Лол :-)

Окай, в С++ надо писать так:

using namespace std::literals::chrono_literals;
    
1h + 100ms;

Покажи пример правильного языка, где можно сделать проще?

давайте вы будете говорить только за себя

Не всем, означает не всем. А не никому.

это шелуха, которая действительно поверхностна и некритична

Ну да. куда уж этой шелухе до дров, перемешивающих пару байт местами.

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

Повторю вопрос. На какой архитектуре у вас не работал dnf или portage?

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

Вам хочется аналогий? Их есть у меня: ножи (боевые) носят в ножнах, на мечах и саблях есть рукоятки и гарды, на оружии есть предохранители. А в Си нет ничего.

Си - это инструмент. а уж как вы его примените - не проблема разработчиков Си.

У главного разработчика Си проблему уже давно нет.

Много критических систем, если они дейсвительно большие, являются очень многомодульными приложениями. Например один сервис - 100 машин, другой - 500, третий - 1000. В одном кластере. Вижу вдоль и впоперек реализацию числодробилок, low-level сервисов на С++, но координаторы процессов могут иметь большую свободу в выборе инструментом. Например на Python пишется

distributed_fs.Copy(src, dst)

Это производит вызов RPC в сервер, он может транзакционно общаться с сервером метаданных ФС, он вызовет контроллер. Контроллер передаст работу 1000 worker процессам, которые считают и перенесут 3 петабайта данных из кластера в кластер параллельно, peer-2-peer. Там из примут другие workers, запишут, сделают все перезапуски в случае падения машин и ответят контроллеру о успехе. Он вернет ответ в Python код.

Я думаю вы видите что в данной схеме тяжелой работой занимаются только workers. Любой overhead, который вы упомянули размыт по этой системе и 99.99999% работы делают workers. Являются они важнее, критичнее, или сложнее? Нет, они обычно совсем простые. Они - часть системы, которой нужны все части для работы. А сложность в контроллерах, в метаданных. Workers могут быть на С++ для экономии памяти в cgroups контейнере, так как работают на тысячах машин. Остальное можно писать на чем угодно, лишь бы оно имело большие возможности по написанию надежного кода.

Это можно реализовать на Scala. Будет выглядеть так же. Только там еще много чего можно реализовать

Это можно реализовать на Scala

Мне нужен код, а не «можно реализовать». Реализовать можно и ООП на С.

За кодом на одеск. Больше ничего не нужно? Я помогаю тебе искать самому потом в правильном месте.

Вам хочется аналогий? Их есть у меня

Есть безопасные бритвы, а есть ножи. Бритвами пользуются парни в стрингах а ножами воины :)

Скорее всего ты не осилил (отключение) важности рекомендованных зависимостей.

И причем тут типы? Они помешают тебе выйти за границу массива?

ВНЕЗАПНО! Гугли про refined types.

OMG!

Даааа, плееру ни нужен риалтайм. Лучше аудиоплеер на html5 который отжирает пару ядер и гиг ОЗУ. А можно использовать deadbeef или вообще mpd - их вообще не видно и не слышно(в плане ресурсов).

пакетный менеджер

Спасибо. Уже есть portage на питоне, который тупит дольше, чем gcc собирает прогу. А компиляция C++ намного более сложная задача, чем расчет зависимостей.

стандартное мобильное приложение

а потом делают мобилки с 8-ю ядрами и 4Гб озу что бы это говно не висло.

редактор

Редактор чего? Фотошоп на жабе - очень смешно получилось бы. Люди на плюсах не могут нормальную производительность получить (inkscape гипер-тормоз), что говорить о более медленных языках.

IDEA

Это которая тугая что ппц и жрет всю свободную озу? Последний раз, когда я запускал CLion, он 5-10 сек искал использование метода в проекте на 10к строк.

зачастую важнее скорость разработки и легкость поддержки

Кому важнее? Рукожопым разрабам или пользователям?

Покажи пример правильного языка, где можно сделать проще?

Лол :-) Ты даже не понял, о чём речь :-) Пожалуйста:

(add (h 1) (ms 100))

Уже есть portage на питоне, который тупит дольше, чем gcc собирает прогу.

Чем больше времени проходит, тем больше я уверяюсь в том, что это не проблема питона. Это проблема криворуких мудаков и плохих алгоритмов.