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

code.dlang.org в помощь

и сколько там заброшенных проектов?)

code.dlang.org в помощь

В какую помощь?

вот да, к code.dlang.org основная претензия что непонятно в каком состоянии проект

и сколько там заброшенных проектов?)

А почему смайл? Вы хочите чтобы это были не заброшенные проекты а заброшенные куски Фобоса?

ЛУчше уж проекты пусть гниют чем Фобос

В какую помощь?

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

Я говорю о подручных 'скриптах' на d.

которые через rdmd запускаются?

которые через rdmd запускаются?

Ну типа

ну есть dub reciepes

я вот хотел себе забацать скрипт бэкапа по webdav с использованием std и rdmd, и столкнулся с тем, что в std нет вменяемой поддержки xml, а что брать на замену — не понятно

ну есть dub reciepes

Надо что-то откуда-то качать, выбирать саму библиотеку, версию

так и бэкаплю башем и курлом)

я вот хотел себе забацать скрипт бэкапа по webdav с использованием std и rdmd, и столкнулся с тем, что в std нет вменяемой поддержки xml, а что брать на замену — не понятно

вроде с xml там норм сейчас, какой-то парень поддерживает (потому чт оему xml по работе нужен) Но в любом случае - тебе не понятно, это значит надо всем сделать неудобно?

Надо что-то откуда-то качать, выбирать саму библиотеку, версию

ditto

ну есть dub reciepes

Но эта тема хорошо упрощает, но вот есть всё те же проблемы

вы не поняли

от того что что-то будет перенесено в std.* оно не станет качественнее само по себе

качественнее становятся вещи к которым любовь прикладывают свою )

оно станет стандартом и перестанут расти как грибы наколенные поделки, как минимум)

а не которые "теперь стандартные"

от того что что-то будет перенесено в std.* оно не станет качественнее само по себе

Из-за процесса допуска кода в std может

оно станет стандартом и перестанут расти как грибы наколенные поделки, как минимум)

хуй! с такой же вероятностью в стд протащат наколенные поделки. См. std.json vs vibe.data.json

Вот что-то типа signals в std не нужно

> Из-за процесса допуска кода в std может Это не работает на качество, оно работает на недопуск некачественного - почувствуйте разницу

@ahdenchik в общем, твоя позиция понятна: делаем фобос клоном стандартной библиотеки Си: математика + ввод/вывод, а дальше, кто как хочет, так и того самого)

Верно

Не очень

Но, т.к. теперь частью процессоров стала многопоточность то её тоже надо поддержать, а для этого надо std.events или типа того

Не очень

я в смысле "меня верно поняли"

если мы про event loop, то это не про многопоточность, а про кооперативную многозадачность)

т.е. про создание иллюзии многопоточности на одном потоке без планировщика)

я в смысле "меня верно поняли"

Я в смысле 'не согласен'

если мы про event loop, то это не про многопоточность, а про кооперативную многозадачность)

верно. но тут про всё сразу, от этого один шажок до горутин

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

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

ибо поддержка компилятора)

нет, они ещё по ядрам процессора планировщиком специальным раскидываются

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

хз хз, Андрей говорил что эта часть в компиляторе Го оче крутая

ну Го придумали ради этого

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

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

То что многим нужно должно в пределах языка иметь одну реализацию

Ты как-то их завуалированно тупыми называешь же )

Будто средний кодер выбирать библиотеки не умеет.

часто это дело вкуса или полноты документации)

Будто средний кодер выбирать библиотеки не умеет.

Я не про то что выбирать не умеет, а про то что все разные выбирают

Ну и? Пусть расцветают 100 цветов же

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

Не удобно же

удобно, потому что то что ты хочешь невозможно сделать

либо ты ему байты-тексты позволяешь себе слать, как json предполагает, либо ты конкретный vibe.data.json выставляешь, безотностильено того сколько у нас вариантов этой библиотеки

а кто-нибудь здесь занимается профессионально разработкой на ди?

короч, другой уровень абстракции это уже

а кто-нибудь здесь занимается профессионально разработкой на ди?

анусов?

софта вестимо

а кто-нибудь здесь занимается профессионально разработкой на ди?

Это всмысле деньги получать за код на D?

да

Ну тогда я

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

ну и я тоже

ну это же от слова профессия, ну

просто интересно, Есть ли в россии конторы, которые разработку на ди ведут или нет :)

ну это же от слова профессия, ну

Ну так я по профессии вообще ракеты делать должен

просто интересно, Есть ли в россии конторы, которые разработку на ди ведут или нет :)

Есть

ERROR: S client not available

это уже неплохо. а то у меня уже ощущение сложилось что ди почти не используется никем.

Бобук из Яндекса говорил как-то что Ди сильно недооценён.

Говоришл почти шёпотом чтобы не съели.

это уже неплохо. а то у меня уже ощущение сложилось что ди почти не используется никем.

Верное.

либо ты ему байты-тексты позволяешь себе слать, как json предполагает, либо ты конкретный vibe.data.json выставляешь, безотностильено того сколько у нас вариантов этой библиотеки

И человеку приходится конвертировать свой std.json в vibe.data.json

Не могу назвать это удобством

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

низкоуровневые имеют преимущество перед высокоуровневыми, если на разных

он ведь не просто так выбрал другую реализацию json

(он ведь не тупой да?)

Если бы std.json был бы хорош для большинства, то не было бы такой проблемы

мы не можем гарантировать хорошесть чего-то в std.*

гляньте как bitop: bt устроен)

https://github.com/dlang/druntime/blob/master/src/core/bitop.d#L270

Как что-то устроено внутри это другой уровень абстракции, хорошо = удобно использовать в моей речи

вы-то думали там асм голый, небось? или остаток от деления на 2 берётся? а вот хер

А там уже можно реализацию улучшать

Как что-то устроено внутри это другой уровень абстракции, хорошо = удобно использовать в моей речи

перформанс важнее удобства, иначе нам всем в питон)

json вообще можно 2 принципиально разными путями реализвоать, как и xml - поточным либо "кусочным"

и библиотеки xml так и делятся на 2 вида обычно

т.е. мы уже оберечны между 2 вариантами выбирать здесь

перформанс важнее удобства, иначе нам всем в питон)

Т.е. ты чисто за скорость в std?

конечно, скорость это цель №1

Из того что я про векторы прочитал это тоже что и динамические массивы. Верно?

нет

вектор это набор чисел

Вектор — (последовательность, кортеж) однородных элементов. из википедии

конечно, скорость это цель №1

Тоесть кандидат, если уж тянуть json в std это fastjson?

хз, fastjson не видел

кандидатов будет 2, или это будет шаблон переключаемый либо на "поточность" либо на "кусочность"

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

хз, fastjson не видел

https://github.com/mleise/fast/blob/master/source/fast/json.d