D, Go и Rust, взлетит ли что-нибудь?

получим очередной раст

Вот именно. Из Си нечего выкидывать, если мы хотим, чтобы он остался Си. А добавить есть что - см. Cyclon или хотя бы Ivy. Даже, смешно сказать, sparse.

«Прогресс» отупляет и вынуждает не думать, а полагаться на этот самый «прогресс», нет?

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

Неправда, там далеко не все из крестов

Там много что оттуда. Но вообще сам используемый тобой термин оттуда. И там он действительно работает. В rust пока нет.

Например borrow checker там из cyclone

Не назвал бы это абстракцией.

Более того далеко не все абстракции в крестах zero weigth, например исключения.

За исключения не надо платить, если ты их неиспользуешь. А аналоги, сделанные вручную не будут быстрее. Значит zero weight, в любом значении.

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

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

сделать человеческие модули

Возможно, сделают. От clang'овцев было предложение в стандарт.

неявного преобразования типов — только хардкор

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

уродливого switch с его fallthrough

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

Выкинуть по максимуму все фичи, создающие UB

Например? С подробностями желательно.

стандартизировать implementation defined

Так он введён по причине сложности одинаковой реализации на разных платформах. Это позволяет генерировать более эффективный код. Или я не прав? Давай тоже на примере рассмотрим.

За исключения не надо платить, если ты их неиспользуешь.

Пешы исчо!

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

А что он не так написал? Если ты throw нигде не дергаешь, try catch не пользуешь, то за что платить? остаются только исключения от всяких new. но если у тебя new начало исключения кидать, то есть вариант, что обработка тебе там нужна только на самом верхнем уровне, чтоб в лог выругаться и умереть.

Был (или еще есть) eastl, где исключения можно было вообще выключить.

Мне как-то показывали, как в этом говне адресная арифметика выглядит.

Ииии что тебе не понравилось? `offset` вместо операторов `+` и `-`? Меньшее количество неявных приведений типов? Или необходимость явного `unsafe`? Все это я вижу как улучшения по сравнению с Си.

fn main() {
    let items = [1u8, 2, 3, 4];
    let ptr = &items[1] as *const u8;
    unsafe {
        println!("{}", *ptr);
        println!("{}", *ptr.offset(-1));
        println!("{}", *ptr.offset(1));
        println!("{}", *ptr.offset(2));
    }
}

2
1
3
4

(http://is.gd/CzMHzG)

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

НЕНУЖНО

Было бы круто увидеть более подробный ответ, почему ржавчина не является ответом на «что еще можно добавить в си?». «Мне как-то показывали, как в этом говне адресная арифметика выглядит» - вообще ничего не объясняет. Мало ли, кто тебе что показал.

НЕ ВЫСТРЕЛИТ

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

безопасность указателей

Не нужно, потому что без адресной арифметики невозможна куча трюков.

Одно исключает другое? Кто, в случае ржавчины, запрещает заниматься насилованием указателей в явных unsafe-блоках?

Я писал, что далеко не все легковесное. Аргумент по типу не хочешь, не используй, никак не отменяет тяжеловесности, ваш КО.

http://goo.gl/OAb3BP

Я писал. В том числе и софт с -fno-exceptions.

Так раскрой тему-то.

я бы хотел там зависимые типы видеть

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

Значит ты просто неверно использовал термины. Спрошу прямо ты имел в виду «light-weight abstraction» или «zero-overhead principle»?

Даже если ты имел в виду первое, то исключения вполне соответствуют, поскольку руками ты той же самой функциональности вряд ли добьешься более оптимальным способом.

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

Это совсем другой механизм.

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

Swift взлетит, а это говно максимум всплывет.

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

Go уже взлетел

Ещё нет

Как раз сейчас его изучаю, после сиплюсплюс это просто глоток свежего воздуха.

Ничего не умеющий язык как глоток свежего воздуха? Хм. Что ж ты делал на плюсах? И зачем, ведь go тормозит, не позволяет управлять памятью, не умеет шаблоны(что так же сказывается на производительности). Думаю, ты и до того мог спокойно писать на java/scala или Питоне.

Там просто синтаксический сахар.

Go - язык для практиков, а не для меряния features.

пока go не умеет в такую же совместимость с С как плюсы, то взлетает он только во влажных снах индусов.

Go - язык для практиков, а не для меряния features.

Ну так и C++ тоже. У Go и правда скудные возможности. Он правда медленнее. Он правда не дает такого контроля. Он правда не содержит средств обобщения кода в статике(таких как шаблоны или хотя бы дженерики, т.к. интерфейсы привносят неизбежный оверхед). И т.д. и т.п.

Вот и получается, что если кто-то сумел переползти с C++ на Go, то ему и раньше C++ был не нужен.

то ему и раньше C++ был не нужен.

конечно, C++ много, где не нужен, но выбора то не было, а теперь есть.

садиться ли уже сейчас за изучение одного из убийц Си/C++, чтобы через 5 лет не оказаться на обочине индустрии, или же все продолжит идти в старом русле с незначительными вливаниями новшеств?

И то, и другое. Серебряных пуль не существует. Тот же D программисту имеет смысл потыкать хотя бы для саморазвития (я, увы, пока сам своему совету не последовал). С другой стороны C++ продолжает развиваться.

«Убийства» в молниеносном смысле слова не будет. Тот же Фортран сходил на обочину несколько десятков лет, и до сих пор для него можно найти компиляторы под актуальные платформы. Так что don't panic.

Сволочизм текущего момента в другом. Сейчас традиционное программирование сужается как таковое. Всё норовят переделать на веб, даже вещи типа фотошопа, где это вроде бы не очень рационально. Соответственно самыми актуальными языками становятся JS, PHP, Ruby и прочая скриптовщина. Я совсем недавно тут писал, что с книжками творится. Если так пойдёт дальше, Си и C++, а равно и D останутся только для написания ОС, драйверов, веб-сервера и браузера...

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

В остальных отношениях прекрасный язык.

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

Rust тыкал? Как по мне гораздо прекраснее Си (в перспективе, когда допилят) в той же нише.

В остальных отношениях прекрасный язык.

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

а именно писал новые - так, чтобы пришлось запиливать пару-тройку контейнерных классов?

Но зачем? Ведь есть готовые библиотечные? Пусть и не в libc, но есть же ж.

Но зачем?

жизнь это боль.

а именно писал новые - так, чтобы пришлось запиливать пару-тройку контейнерных классов?

Но зачем? Ведь есть готовые библиотечные?

Есть. Тот же linux/list.h - готовый библиотечный список. Если после его использования кто-то назовет Си «прекрасным языком» и будет сетовать на то, что не хватает модулей - ну... даже не знаю, что сказать.

Вот тоже интересно: все те, кто называет си идеальным языком, утверждает что там есть всё что нужно... Что они на нем пишут? И какие еще языки знают?

Отдельно интересно, что за новый модный язык «сишка». Судя по отзывам, что-то очень крутое.

Опиши-ка какой-нибудь кейс из собственной практики, в котором правильно настроенный ГЦ помешал бы эффективности твоей программы.

Пара тысяч клиентов сосёт live-видеопоток, и тут ГЦ «ой та подожите подожите хлопцы».

конечно, C++ много, где не нужен, но выбора то не было, а теперь есть.

Почему не было? Столько языков есть. Чем они хуже go? Java, C#, Scala, Python, Ruby, да хоть Ocaml.

при этом соответсвует принципу zero weight abstraction.

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

конечно, C++ много, где не нужен, но выбора то не было, а теперь есть.

Бред какой-то. Если возможности и особенности C++ были не нужны, то можно было взять любой другой язык по вкусу и по задаче. Выбора не было(и до сих пор нет) там, где особенности крестов нужны. Go не является альтернативой. Rust может такой альтернативой стать.

Я писал не так давно. Главное не заниматься «лишними» обобщениями и решать свою задачу. Тогда нормально можно делать. Но вообще я больше за C++. Ещё scala норм, но ниша другая.

Не аффектит производительность, то и значит. Исключения аффектят, аргумент, что их можно не использовать - просто детский: а в замен-то что?

конечно, C++ много, где не нужен, но выбора то не было, а теперь есть.

Был выбор. Я и сам далеко не всегда использовал C++. Но на Go как-то не вижу смысл переходить с C++. Скорее с питона=)

Сказ про то, как 50k строк переписали с C++ на Go:

https://togototo.wordpress.com/2015/03/07/fulfilling-a-pikedream-the-ups-of-d...

Исключения аффектят

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

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

Это не детский аргумент, а т.н. «принцип нулевой стоимости», занимающий одно из центральных мест в С++.

а в замен-то что?

То, что было до введения исключений - коды возврата. Решение rust мало чем от них отличается, к сожалению. Кроме разве что более удобного синтаксиса.

Пара тысяч клиентов сосёт live-видеопоток, и тут ГЦ «ой та подожите подожите хлопцы».

А почему ты думаешь, что ГЦ

- будет блокировать сессии клиентов;

- заблокирует все соединения разом;

- заблокирует их на заметное глазу время?

Более того, откуда в случае сосания live-видеопотока возьмется ацкое количество недолгоживущих объектов (и следовательно необходимость в частом ГЦ)?

А ради чего заниматься этими вопросами, если наличие GC в этой задаче вообще не нужно и ручной/полуавтоматческой работы с памятью вполне достаточно?

В языке, претендующем на замену C++, сборщик должен быть в виде библиотеки и опциональным.

Я писал не так давно

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

Тогда нормально можно делать

Нормально можно сделать на всем.

коды возврата. Решение rust мало чем от них отличается

Решение Rust отличается от кодов возврата принципиально. Ты просто не можешь случайно использовать код возврата в роли значения и, при минимально разумном конструировании API, ты не можешь использовать неинициализированно возвращаемое значение.

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

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

auto pipeline = input.get_message_stream() | filter(selector) | sort() | remove_duplicates(predicate);

Или такие вещи, по-вашему, нужно записывать вот так:

auto r1 = start_construct_pipeline(input.get_message_stream());
if( r1.error )
  return;

auto r2 = r1.pipeline.add_stage(selector);
if( r2.error )
  return;

auto r3 = r1.pipeline.add_stage(sort());
if( r3.error )
  return;
...

?

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

Идиомы Maybe / Either ?