D as a Better C

Да задолбали все уже, язык Х лучше С потому что он в отличии от него бла бла бла. )))

Но ведь D рулит и педалит. А поскольку теперь уже есть LLVM-фронтенд, то теперь и почти все поддерживаемые C архитектуры тоже поддерживаются.

А поскольку теперь уже есть LLVM-фронтенд, то теперь и почти все поддерживаемые C архитектуры тоже поддерживаются

Братишка, ты что-то попутал. LLVM поддерживает намного меньше архитектур, чем gcc.

Ну я скромно написал «почти». Просто изначально, когда D только появился, для меня основным недостатком было x86/x86_64 only, что сразу ставило на нём крест.

Просто изначально, когда D только появился, для меня основным недостатком было x86/x86_64 only

В 2001?

Язык о том как взять худшее ото всех миров.

Да я против D ничего не имею, просто меня прикалывает когда говорят слово «Лучше». Он не лучше, он другой просто. ))

Но ведь это мёртвый язык.

D as a Better C

Нинужно, есть Rust.

D мог бы отлично вписаться в нишу кросплатформенного десктопа вместо C++ или нативного серверсайда вместо Go, но не судьба.

Мёртвый язык у тебя в штанах! А D активно используют такие конторы, как, например, Facebook, Govnosoft Enterprises Inc., LTD, и много других известных фирм. Да что уж там, даже я (помимо работы в Govnosoft Enterprises Inc., LTD) иногда для личных целей его использую: всяко удобнее, чем C++17.

Я в своё время, вообще на Mono\C# убежал, лишь-бы не писать на C++11(в то время это был 11).

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

Назови хотя бы два активных проекта фейсбука на D?

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

Нахер, нахер. Сишка рулит в своей области.

http://okante.narod.ru/D

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

Тебе нравится возможность писать за границы буфера

LOL это не свойство языка а ошибка разработчика конечного софта. Не надо вот тут мемчиками про сишку то ))))

неотделимость области ошибок от области значений

Чего? Вы там абстрагируя каждую букву от другой на уровне одного алфавита совсем поехали?

отсутствие модулей и единой системы сборки?

Модулей? Если приспичит можно и модули прикрутить...нонам не нужен очередной nodejs который для «hello world» выкачивает тонны кода. Нам не нужны модули у нас есть нативные библиотеки статические и динамические.

отсуцтвие...системы сборки

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

Поклонники кулькакерских недоязычков - это типа сектантов.

нам не нужны модули

Да лучше уж тормозной препроцессор который раскрывает кучу разного уровня и заставляет компилятор компилировать(строить AST проводить оптимизации) один и тот же код для каждого объектника. Даже в C++ осознали что модули нужны

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

Он и сейчас x86 only в том случае если нужны ассемблерные вставки. А без этого на микроконтроллеры его не запустишь.

Exceptions, typeid, static construction/destruction, RAII, and unittests are removed. But it is possible we can find ways to add them back in.

D as

Death.

Проблема D, для системщины, указана в самой статье - код на D нельзя вызывать из других языков.

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

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

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

и про «отделение ошибок от значений» - тоже бред. возвращай код ошибки и никаких проблем. никто не страдает, однако. а вот смешивать ошибки и значения - действительно дурной тон.

про «единую систему сборки»: чем же автотулзы не угодили? можно собрать всё, что угодно. ну, на мелкоконтроллерах свои компиляторы, конечно. но на мелкоконтроллерах и всякого хлама нет. а С есть.

LOL это не свойство языка а ошибка разработчика конечного софта. Не надо вот тут мемчиками про сишку то ))))

Статистика по уязвимостям говорит о том, что 80% всех дыр это результат buffer overflow. Даже в обожемойкакиемысекурные OpenBSD.

Чего? Вы там абстрагируя каждую букву от другой на уровне одного алфавита совсем поехали?

Ты не можешь вернуть Either(struct foo_bar, error_t), например. Отсюда либо ты возвращаешь только код ошибки, а результат устанавливаешь через отдельный аргумент, либо делаешь монстров в духе ssize_t.

Модулей? Если приспичит можно и модули прикрутить...нонам не нужен очередной nodejs который для «hello world» выкачивает тонны кода.

Поэтому каждый упырь лепит свою систему сборки и свою реализацию функций min() и max(), ага.

Нам не нужны модули у нас есть нативные библиотеки статические и динамические.

Это вообще разные вещи.

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

Угу. Потом, правда, всплывает pkg-config, libtool и прочие прелести, которыми к Make прикручивают зависимости между библиотеками.

Тебе нравится возможность писать за границы буфера

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

отсутствие модулей и единой системы сборки?

Очень нравится. По сравнению с тем как это сделано в python/node/rust/go..., где в качестве зависимостей может прилететь любой вредоносный код, либо гнилые зависимости вообще принято таскать с собой, нормальная сборка где зависимости берутся из системы - это просто сказка.

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

Повторюсь: 80% уязвимостей результат buffer overflow в том или ином виде. Да, даже в коде именитых разработчиков. Да, даже там, где есть вменяемый peer review.

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

Я уже говорил про то, что min() и max() у каждого программиста свои? Да, мы можем сделать библиотеку для этого. Проблема в том, что распространение такой библиотеки довольно сложное дело, потому что как только таких библиотек набирается 20-30 штук, мы тут же вступаем на скользкий путь сливания зависимостей проекта. И тут выясняется, что у всех разная система сборки, разный механизм передачи CFLAG'ов и прочее. Кто-то вообще делает header-only и выкладывает релизы в качестве постоянно обновляющейся статьи на wiki.

В итоге, вместо того, чтобы слить модуль с реализацией jenkins hash, приходится сливать какой-нибудь openssl, потому что по отдельности такие штуки никто не распространяет. Ну или копипастить хидер себе в проект.

про «единую систему сборки»: чем же автотулзы не угодили? можно собрать всё, что угодно. ну, на мелкоконтроллерах свои компиляторы, конечно. но на мелкоконтроллерах и всякого хлама нет. а С есть.

Потому что у кого-то автотулзы, у кого-то cmake, у кого-то pure make, а у кого-то вообще scons.

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

Для числодробилок можно было бы сделать отдельный механизм адресации без проверок.

Очень нравится. По сравнению с тем как это сделано в python/node/rust/go..., где в качестве зависимостей может прилететь любой вредоносный код, либо гнилые зависимости вообще принято таскать с собой, нормальная сборка где зависимости берутся из системы - это просто сказка.

Да-да. Поэтому min(), max() и ARRAY_SIZE() стабильно пишутся в любом проекте руками. Ах да, ещё в каждом проекте почему-то свои списки. Особо продвинутые используют <sys/queue.h>. Правда, он почему-то во всех операционных системах разный.

Да лучше уж тормозной препроцессор который раскрывает кучу разного уровня и заставляет компилятор компилировать(строить AST проводить оптимизации) один и тот же код для каждого объектника.

Стоит признать, что шаблоны ещё хуже — хидеры по крайней мере не могут так затормозить сборку, как хорошо написанный шаблон :D

Для числодробилок можно было бы сделать отдельный механизм адресации без проверок.

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

Да-да. Поэтому min(), max() и ARRAY_SIZE() стабильно пишутся в любом проекте руками

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

Правда, он почему-то во всех операционных системах разный.

А вот прикинь, это потому что системы разные.

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

Мм?

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

Где ровно та же проблема возникает, когда нужны RB деревья, какие-нибудь хеши или другие специализированные структуры данных. А они много где нужны. Сейчас ты мне скажешь про boost. Правда, когда в Centos 7.2 мне потребуется новая фича из нового boost, мне придется пересобирать ВЕСЬ boost. В итоге сломается что-то ещё.

А вот прикинь, это потому что системы разные.

Нет, потому, что в glibc забили его обновлять. В итоге в openbsd есть TAILQ_FOREACH_SAFE, а в glibc нет. Хотя в мане указано, что есть :D

P.S. К слову о манах. Из-за того, что нет центрального репозитория, документация тоже у всех в разных форматах.

замедляющий числодробилки в разы

В разы ли?

В разы ли?

Тсс, мб он сам про likely() и unlikely() узнает.

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

Это не работает даже под линем. Что говорить про другие ОС.

Алсо, ради лулзов:

https://paste.pound-python.org/show/WCbdg52YGqb0lsE5UgTG/
https://paste.pound-python.org/show/sFopOg6TxvxIFvNr4Qah/
https://paste.pound-python.org/show/ckEiQTdkL3FG2M2MGjbJ/

Результаты отличаются где-то на 0.3%.

Это не работает даже под линем.

Не смеши. С этим припеваючи живут десятки репозиториев из десятков тысяч пакетов.

Что говорить про другие ОС.

BSD? Порты, порты, pkgsrc и порты. Макось? На ней же нельзя жить без brew или macports.

Не смеши. С этим припеваючи живут десятки репозиториев из десятков тысяч пакетов.

Можно ссылку на пакет с jenkins hash, пожалуйста? В Python есть в репозитории.

Мсья не слышал про оптимизации и о том что нужно тестироваться на неизвестных на момент компиляции данных?

Мсья не слышал про оптимизации и о том что нужно тестироваться на неизвестных на момент компиляции данных?

Ну приведи мне пример того, где оно тормозит.

P.S. Ты можешь собрать с -O2, проверить вывод objdump и увидеть там сравнение и ветвления.

Навскидку, http://www.sisyphus.ru/en/srpm/Sisyphus/python-module-jenkins

Я сишный хочу. Где питоновый найти, я знаю.

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

Для кода оно, мб, и не надо. Вон, в ноде какой вой поднялся, когда leftpad удалили.

Для кода оно, мб, и не надо. Вон, в ноде какой вой поднялся, когда leftpad удалили.

Это потому что они придурки и не запретили удаление пакета, от которого кто-то зависит. В том же Hackage ЕМНИП такой запрет есть.

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

Есть же уже пакетные менеджеры и даже хранилища типа CPAN, но по сути они никому нафик не нужны.

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

Есть огромный пласт вещей, которые все делают руками. Типа префиксных деревьев, хеш-таблиц, RB деревьев или генерации UUID'ов, прости господи. И это можно было бы опакетить. Если нужны arch-specific — сделай руками, кто мешает-то. У меня складывается ощущение, что нормальных строк в C нет примерно по этой же причине — все юзают готовое дерьмо из stdlib, потому что написать свои и распространить их по всей экосистеме — себе дороже.

P.S. Ты можешь собрать с -O2, проверить вывод objdump и увидеть там сравнение и ветвления.

У меня там абсолютно идентичный код. А вот это:

#define _GNU_SOURCE

#include <limits.h>
#include <stdio.h>
#include <time.h>
#include <fcntl.h>
#include <unistd.h>

#define SEC_TO_NSEC(x) ((x) * 1000000000U)
#define RND_SIZE (1024)

int main(void) {
    unsigned int indexes[RND_SIZE];
    volatile size_t array[1024] = {0};
    struct timespec t1 = {0};
    struct timespec t2 = {0};

    read(open("/dev/random", O_RDONLY), &indexes, sizeof(indexes));
    for (size_t i = 0; i < RND_SIZE; i++)
        indexes[i] = indexes[i] % 1024;

    clock_gettime(CLOCK_MONOTONIC_PRECISE, &t1);
    for (size_t i = 0; i < 1000000000; ++i) {
#ifdef BOUNDS
        if (indexes[i % RND_SIZE] >= 1024)
            return 1;
#endif
        array[indexes[i % RND_SIZE]] = i;
    }
    clock_gettime(CLOCK_MONOTONIC_PRECISE, &t2);

    printf("time = %luns\n",
           (SEC_TO_NSEC(t2.tv_sec) + t2.tv_nsec) -
           (SEC_TO_NSEC(t1.tv_sec) + t1.tv_nsec));

    return 0;
}

Даёт на clang 4 и gcc 5 разницу в 30%. Это простой случай, а я реальном проекте на перемножении матриц я видел 2.2x разницу.

Он сишный.

$ gcc -Wall -Wextra -std=c11 -O2 -DBOUNDS -o bounds test.c
$ gcc -Wall -Wextra -std=c11 -O2          -o no-bounds test.c
$ ./bounds; echo $?  
time = 658250917ns
0
$ ./no-bounds; echo $?
time = 654786097ns
0
$ gcc --version
gcc (Gentoo 7.1.0-r1 p1.1) 7.1.0

P.S. Ты забыл indexes volatile сделать, цомпилер догадался, что ты все элементы меньше 1024 сделал.

Summary: Python ctypes wrapper around Bob Jenkins' hash functions
Description:
This python module provides Bob Jenkin's hash functions in python (via
a ctypes wrapper calling the original C implementation).

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