Язык D включен в коллекцию компиляторов GNU (gcc 9)

В этом как раз и минус сигнатур функций в Расте, что они излишне детализированы.

А не надо путать уровень формализации с уровнем абстракции. На разных слоях логика. Логику еще называют «универсальные законы мышления». Универсальные, потому что применимо к любому мышлению, на любом уровне абстракции.

Раст позволяет формализовать больше смысла.

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

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

Так работает мышление, чем больше формализации, тем меньше ошибок.

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

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

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

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

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

А зачем вам знать типы?

Тапы помогают создавать корректные и управляемые (в смысле доработки) программы. В языке с развитой статической системой типов мы можем проектировать программу так, чтобы перекладывать на компилятор большое количество проверок соответствия программы предполагаемой логике ее работы. Потому что типы - это не только (и не столько) о размере и размещении объектов в памяти, сколько о логике взаимодействия сущностей вашей задачи.

Возьмем ваш пример с рулевым колесом. Типы здесь нужны не только для выражения того, как именно осуществляется поворот (на соответствующем уровне они выполняют и эту функцию), но и для того, чтобы выразить и ограничить саму логику поворота:

enum Drive {
    ToLeft,
    ToRight,
}

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

Другой пример. У нас есть два вида датчиков температуры, с которыми должна работать наша программа. Проблема в том, что одни датчики выдают вещественные числа с градусами Цельсия, а другие - с градусами Френгейта. Как наша программа должна их отличать и гарантировать корректную конвертацию одних в другие при необходимости? Это можно легко сделать с помощью типов. Заведем новые типы:

struct Celsius(f64);

struct Fahrenheit(f64);

Реализуем метод типажа From для конвертации между ними:

impl From<Celsius> for Fahrenheit {
    fn from(c: Celsius) -> Self {
        Fahrenheit(c.0 * 9./5. + 32.)
    }
}

impl From<Fahrenheit> for Celsius {
    fn from(f: Fahrenheit) -> Self {
        Celsius((f.0 - 32.) * 5./9. )
    }
}

Теперь можем водить функции в обобщенном виде:

fn freezing_point<T>() -> T
    where T: From<Celsius>
{
    Celsius(0.0).into()
}

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

let f: Fahrenheit = freezing_point();
let c: Celsius = freezing_point();

https://habr.com/post/326896/

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

Теперь не получится случайно вместо градусов Цельсия передать градусы Фаренгейта - компилятор это гарантирует, но тем не менее, можно легко преобразовать одни в другие и писать обобщенный код, работающий с ними обоими. В этом вся мощь типизации.

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

А то что вы привели в качестве примера, я не знаю зачем - но все это (i) не относится к моему утверждению и (ii) можно сделать и на плюсах, и на D, да и уверен на других языках тоже. Тут Раст вообще ничего нового не приносит.

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

И куда вы уйдете от типа поворота руля влево или вправо? И каким образом вы собираетесь закрыть глаза на несовместимость чисел в разных системах отсчета? А в C++ завезли уже АТД? Для повышения продуктивности нужен язык с мощной системой типов, чтобы в терминах типов можно было выразить больше сущностей и взаимосвязей логики программы, переложив на компилятор ее проверку.

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

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