Собсно как был, так и остался С. Предлагаю тред закрыть.

ats! (с предыдущим комментатором согласен)

системного программирования [..] C++, D, Rust, Go

None of those. C. /thread

C был, есть и будет, Уровень повыше (как бы системный, но не уровень ядра/ос) - Go. D - труп, Rust - труп из будущего, C++ - будет жить еще долго.

«Зачем нам системное программирование? Лучше нам водить хороводы!» почти (ц)

Хотелось бы, чтобы таким языком стал Rust.

Личное мнение: D - не впечатлил. Ну да, кое-что получше, чем в плюсах, кое-что хуже. При этом, отказаться от ГЦ не так-то просто. Ну да, формально это возможно, но при этом многое отваливается, ну и нафиг такое нужно. Опять же, (со стороны кажется), что либы в этом плане сложнее писать - в смысле решение юзать ГЦ или нет будет «торчать наружу» (используем классы или только структуры). В том же С++ это решается на уровне объектов, а не типов.

Gо никогда всерьёз не щупал, но опять же ГЦ, да и «фич не хватает». Чем он некоторых цепляет - ума не приложу. Хотя я, конечно, смотрю больше с точки зрения этакого «энтузиаста программирования». То есть можно и сырые технологии пощупать и фич хочется. «Бизнес», вероятно, другие требования предъявляет. Ну или многим важна простота в ущерб возможностям.

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

Предлагаю пофлеймить и высказать свои прогнозы какой из языков в будущем будет самым популярным для системного программирования и почему: C++, D, Rust, Go или какой-то иной?

Делаю ставку на простой бескрестовый Си.

Но всей душой хотел бы, чтобы Си и С++, наконец, издохли. И нишу их занял бы Rust.

C и C++

C

Языком системного программирования останется C. А вот для всего прочего будут применятся всякие Rust'ы, Ruby и прочее.

Что угодно, лишь бы C закопали.

закопают только вместе с нынешними архитектурами железа

C. Если повезет, то D, но вряд ли. Go игрушка для хипстеров, устаревший уже в момент своего создания, Rust темная лошадка, пока непонятно ваще, что за язык.

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

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

Haskell и функциональщина вообще.

если железо останится преждним то абстрактная машина С и поэтому язык С

если процы станут «256» массово конкурентными исполнителями и mmu станут очень очень мелько гранулированными(что совсем не вероятно в отличчи от поворота закона мура от увеличения частот к увеличению числа ядер) то Golang может ибо он как ни странно по духу ближе к С изначальному чем нонешних стандартов С и тем более в нём(golang) ещё не накопилось(молодой пока) вагон компромиссов совместимости(но уже начали копиться)

golang может если процы в быту 100ядерные будут.

Я вот подумал, а нафига тебе скобки, твой поток мыслей без знаков препинания выглядит ещё эпичнее )

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

JavaScript, /thread

(и (lisp (только lisp)))

Пусть всё останется как есть, а все эти новые поделки вымрут.

Пусть всё останется как есть, а все эти новые поделки вымрут.

Новые поделки не от хорошей жизни рождаются.

Объектно-ориентированный ассемблер.

Вангую - победит питон.

Объектно-ориентированный ассемблер.

Borland Turbo Assembler?

Да. Или Microsoft Visual Assembler#

Предлагаю пофлеймить и высказать свои прогнозы

Ты помнишь первый закон Ньютона?
Так он работает не только в механике.
На данный момент я не вижу никаких причин для изменения пропорций и применений языков.
Считаю, что в ближайшие 3-4 года изменений не будет.

C. Был. Есть. Будет.

а вот и не смешно

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

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

Ведро можно написать только на очень ограниченном количестве языков. Среди них: C, C/C++ (!), Rust, ATS, Haskell (с уточнениями), что-нибудь паскалеобразное.

Зачем появились кресты, когда уже была сишка? Зачем появилась сишка, когда уже был алгол? Зачем появился алгол, когда уже был фортран?

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

С

Ты его, верно, с масмом перепутал. Не помню в тасме объектов.

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

Надо, надо твёрдый дать ответ:

Расту и си — Да! Да! Да!

плюсам и голангам — Нет! Нет! Нет!

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

Применительно к Rust — более дешевую и быструю разработку более надежных программ.

Ты его, верно, с масмом перепутал. Не помню в тасме объектов.

Не, именно в tasm и были объекты.

C. Был. Есть. Будет.

Звучит как приговор и проклятие одновременно. Почему-то вспомнился заплесневевший ленин в мавзолее.

За счёт чего на расте разработка становится дешевле и быстрее, а программы надёжнее?

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

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

А ведь точно, вспомнил.

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

За счёт чего на расте программы надёжнее?

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

За счёт чего на расте разработка становится быстрее

Меньше багов => меньше времени уйдет на стабилизацию и багфикс => разработка завершится раньше.

За счёт чего на расте разработка становится дешевле

За счет более высокоуровневых, чем в Си, примитивов. Трейты, замыкания, pattern matching.

golang тоже ( ну если (а оно возможно) вытащить на уровень пользователя компилятором управление мусорщиком)

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

симула тормозила

Звучит как очевидный факт.

что программа в принципе не может сделать segfault

раст тьюринг с оракулом???

Симула тормозит — пиши на сишечке же

раст тьюринг с оракулом???

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

PS Начинаешь осознавать, какой никчемный динозавр этот ваш Go? :D