LINUX.ORG.RU

[D-lang] Итоги и небольшой обзор о состоянии языка


0

0

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

Маленькое введение:
На данный момент язык D является успешно воскрешаемым системным языком программирования высокого уровня. Хочется подчеркнуть два слова: «Системный», «Высокоуровневый». Данные слова редко когда можно встретить рядом. Так получилось что что «Системный» стало синонимом слов: «сложный», «ручной», «быстрый», «низкоуровневый». А «Высокоуровневый»: «медленный», «лёгкий», «большой», «безопасный».

Язык D включает в себя самое лучшее:

  • он быстрый - компиляция идёт напрямую в бинарный код, как в c, cpp, pascal
  • он лёгкий - синтаксис не сложен. Поддерживаются все возможности CPP. Внешне синтаксис и семантика почти идентичны аналогам в C#.
  • он безопасный - за памятью следит сборщик мусора, более не нужно следить за памятью вручную. А сам GC очень быстр ибо его создателями были и являются мировые специалисты по оптимизации. Благодаря конструкциям try, можно легко отловить все проблемы и ошибки, при этом легко оперируя объектами{ом} ошибки.

За пруфами - http://www.digitalmars.com/

Я узнал о том что у нас есть русское коммьюнити, которое активно занимается D - d@conference.jabber.ru
Я пообщался с людьми и смог узнать много нового. И так, обо всём по порядку.

Сейчас есть 2 реализации, на которые стоит обратить внимание:

  • DMD - официальная реализация. Сейчас активно развивается D2.0, который сейчас очень даже жив и используется всеми. Последний релиз был несколько дней назад. Сейчас данную реализацию используют почти все, в т.ч. и я.
  • LDC - фронтэнд к LLVM. В данный момент слабо развивается, не поддерживает D2.0. Как говорят в коммьюнити, лучшим вариантом для ldc будет вовсе отказ от цели «поддержка D2.0». Увы, это охначает что половина последних проектов прост не запустится и не будет запускаться на LDC. Лично я, пока, забыл про LDC.

Развитие языка, в общем смысле этого слова, представляет из себя странный процесс: основные разработчики занимаются компилятором и стандартом, а всё остальное делают коммьюнити. Лично я пока не заметил чтобы хоть одна коммерческая компания приложила руку к развитию D.

По сему, всё что было и есть в D - творение рук человеческих, а не «лап коммерческих». Что удивительно, коммьюнити успело сделать уже многое:

  • Биндинг к GTK - gtkD. Развивается активно. Увы, сейчас есть пара багов из-за изменений в последнем DMD(ну не успели пока).
  • Биндинг к QT - qtD. Достаточно большая и сильная разработка. Заявлено что будет реализация биндингов ко всему функционалу QT - в т.ч. и DB, OGL etc.
  • Полноценный 3D-движок на opengl с поддержкой glsl - moonglide. Сейчас активно разрабатывается. О всех подробностях разработки всегда можно наблюдать на d@c.j.r.
  • Продвинутая система сборки - xfBuild. Сейчас всё больше и больше используется вместо dsss(ныне почти не развивается). Даёт действительно большие возможности. Отличная альтернатива make.
  • Интерпретатор+скриптовой язык - miniD. Уже вышел miniD2, который поддерживает D2.0!
  • Хорошая библиотека GUI для opengl-based приложений - hybrid. Сейчас используется в moonglide. Очень и очень хорошая либа.
  • 2D движок для игр с редактором - ArcLib. От создателя DreadMoon Linux!

И ещё десятки биндингов и хороших проектов: http://www.dsource.org/projects/ http://h3.team0xf.com/ http://talks.dprogramming.ru/

Всё это делает коммьюнити, при этом не просто как «лисперы» и «хаскелеводы», ибо оно нужно и иначе никак, а так, ради забавы. Всё это развивается, несколько людей думают заняться хорошим ORM, кто-то хочет сделать нормальный биндинг python, кто-то переписывает свой проект на D. Язык имеет большой потенциал и развитие идёт. Одна проблема - люди. Цель данного треда - призвать новых людей, заинтересовать всех кого можно. Лично я сейчас прекратил разработку редактора на python и начинаю изучать глубже сам язык D чтобы помочь gtkD в написании биндингов.

Если у вас есть лишнее время, вам надоело считать байты на сях, вы уже погрязли в скобках лиспа и не знаете как из них выбраться, если вы осознали что до релиза(а не промежуточных отчётов-сырцов) UnladenSwallow ждать ещё не мало, если вам надоело что очередной билд вашего приложения течёт из-за того что вы забыли добавить ещё 2-3 звезды(разыменование) в начало переменной, то

присоединяйтесь к нам: d@conference.jabber.ru.

Надпись на этикетке: жир - 0%, бЕлки - ни одной, ккал - овер9к



Последнее исправление: tia (всего исправлений: 5)
Ответ на: комментарий от Love5an

Универсальный язык, вообще, один, насколько я знаю. Common Lisp. И то, не совсем, покуда мы не на лисп-машинах пишем. Говорить об универсальности Cей, Плюсов, Додиеза, Похапэ или Питона это настолько глупо, что даже не смешно. У большинства из них столько недостатков, что никак кроме как говном их назвать язык не поворачивается.

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

Ничего, я не в обиде. Конечно, востребованность в RL - это, наверное, главная больная точка приверженцев Lisp-а. И некрасиво на неё наступать. Пардон.

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

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

bibi
()
Ответ на: комментарий от naryl

>DMD сам работает на x64, но генерирует код только для x86.

А намечается, вообще, генерастение х86_64 кода?

LDC работает и компилит и там и там.


Или D2.0 этой вещи?

tzukko
()
Ответ на: комментарий от tzukko

А намечается, вообще, генерастение х86_64 кода?

В DMD - нет. Это потребует доработки бэкенда, а Уолтер Брайт предпочитает над бэкендом не работать из-за его несвободной лицензии. ИМХО правильно делает. Лучше пилить фронтенд, который можно прикрутить к чему угодно.

GDC говорят умеет генерировать рабочий код в x86-64, ARM и PPC. Не пробовал.

Или D2.0 этой вещи?

Да, но начало разработки будет не раньше релиза книги Александреску. ЕМНИП март.

naryl ★★★★★
()
Ответ на: комментарий от Love5an

>Универсальный язык, вообще, один, насколько я знаю. Common Lisp.

Очень жирно. Есть живая ОС, написанная на CL (ядро + системные библиотеки)? Нет? Значит не универсальный, а так, обычный прикладной ЯП.

linuxfan
()
Ответ на: комментарий от linuxfan

Очень жирно. Есть живая ОС, написанная на CL (ядро + системные библиотеки)? Нет? Значит не универсальный, а так, обычный прикладной ЯП.

Ну это как раз не показатель. В своё время было предостаточно систем, практически полностью написанных на ассемблере. Причем вполне себе живых. Что впрочем не даёт повод причислять ассемблер к 'обычным прикладным ЯП'.

bibi
()
Ответ на: комментарий от bibi

> Что впрочем не даёт повод причислять ассемблер к 'обычным прикладным ЯП'.

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Love5an
()
Ответ на: комментарий от linuxfan

Я написал, для тех, кто читать не умеет, что *не совсем*, поскольку мы пишем не на лисп-машинах.
Есть некоторый класс задач, связанный с низкоуровневым дрочевом, который в область применимости CL вписывается довольно плохо в силу отсутствия специальной аппаратной поддержки для некоторых фич этого языка(например, динамической типизации и gc). Если мы говорим о распространенном железе, по крайней мере, т.е. x86(64).
И хотя, в принципе, это вполне реально, см. Movitz, это не особо практично, издержки слишком высоки.

Love5an
()
Ответ на: комментарий от Love5an

> О, я догадаюсь щас.

Не догадаешься. Ты почему-то думаешь, что я троллю.

Ты хочешь так толсто намекнуть что лиспы это что-то из прошлого?

Нет.

Какой же у тебя в голове сракотан, а.

Загляни лучше в свою голову.

tailgunner ★★★★★
()
Ответ на: комментарий от naryl

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

В любом случае - в гугл.

ну есть там сотня другая приложения, но какие из них реально стоящие-то?

thevery ★★★★
()
Ответ на: комментарий от Love5an

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

anonymous
()
Ответ на: комментарий от anonymous

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

Нононо! Брейк! Разойдитесь по углам. Переход к конкретике - это запрещённый приём. Только абстрактные высказывания. Максимум - переход на личности. Бой..

bibi
()
Ответ на: комментарий от thevery

Интересно, как Бьярне Строустрап доказывал ценность C++ в реальных приложених, а не на бумаге, когда у него даже нативного компилятора не было.

naryl ★★★★★
()
Ответ на: комментарий от Love5an

>Вообще, это(«ОС на языке X») не то, что даже не критерий универсальности языка, а даже не необходимое условие.

Еще какое необходимое. Ядро ОС на языке X означает буквально, что этот язык применим для написания низкоуровневых вещей.

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

А это, как ты его называешь, «прочее говно», между прочим, выполняет вполне конкретные полезные задачи. Было бы интересно посмотреть на мобильный телефон с нативными регистрами car, cdr и сборкой мусора. Сдается мне, они бы были не такими мобильными, как «прочее говно» :D

linuxfan
()
Ответ на: комментарий от bibi

>В своё время было предостаточно систем, практически полностью написанных на ассемблере.

Даже сейчас на ассемблере пишут. Не for fun, и даже не ради выигрыша пары тактов. К нему дело скатывается там, где ресурсы весьма и весьма ограничены.

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

linuxfan
()
Ответ на: комментарий от tia

>Вы мне скажите, вы правда не увидели ни одного аргумента «за» в ОП-посте?

имхо там больше видно маркетинга и «активно развивается»(читай: пока сырое) и «заброшено»

thevery ★★★★
()
Ответ на: комментарий от thevery

И что вы хотели этим сказать? Ответа на вопрос там нет.

Как C++ стал таким популярным, что для него написали (Брайт, а не Строустрап-дизайнер-языка) компилятор, если без компилятора нечем было показать *практическую* (не на бумаге) польезность?

naryl ★★★★★
()
Ответ на: комментарий от naryl

> Как C++ стал таким популярным, что для него написали (Брайт, а не Строустрап-дизайнер-языка) компилятор

Ну глупость же. Компилятор написал Страуструп, просто целевым языком компилятора был не машкод или асемблер, а Си.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Интересно, как Бьярне Строустрап доказывал ценность C++ в реальных приложених, а не на бумаге, когда у него даже нативного компилятора не было.

Ок. Приведите пару примеров киллер-апп, скомпиленных cfront.

naryl ★★★★★
()
Ответ на: комментарий от naryl

> Приведите пару примеров киллер-апп, скомпиленных cfront.

Маленький был, не помню. Да и требовать киллер-аппы - мошенничество в данном случае (впрочем, это не ты их требуешь :)). Си++ поднялся на волне ООП и в отсуствие реальной конкуренции.

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

tailgunner ★★★★★
()
Ответ на: комментарий от linuxfan

>Есть живая ОС, написанная на CL (ядро + системные библиотеки)? Нет?
Значит не универсальный, а так, обычный прикладной ЯП.

Конечно есть. Моя Symbolics до сих пор в шкафу трудится, я на ей секретаршу себе написал.

volh ★★
()
Ответ на: комментарий от Love5an

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

аппаратной поддержки динамической типизации

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

suzuki
()
Ответ на: комментарий от Love5an

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

Love5an
()

Я один не понимаю какое будущее ждет язык у которого нет стандарта, нет поддержки платформ окромя x86, нет стандартизированной встроенной библиотеки (как оказывается их несколько и все разные)? Зачем он нужен ну кроме как «на поиграться».

Зато компиляторов целых три штуки и ни один из них с друг-другом не совместим.

Не бред ли выставлять ЭТО как самый перспективный язык?

mono ★★★★★
()
Ответ на: комментарий от tia

Вы мне скажите, вы правда не увидели ни одного аргумента «за» в ОП-посте?

Ну, давай смотреть.

На данный момент язык D является успешно воскрешаемым системным языком программирования высокого уровня.

Чтобы быть «воскрешаемым» надо сначала стать мёртвым.

он быстрый - компиляция идёт напрямую в бинарный код, как в c, cpp, pascal

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

он лёгкий - синтаксис не сложен.

Синтаксис - дело привычки. Неинтересно.

Поддерживаются все возможности CPP.

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

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

Интересно, у кого из современных языков нет сборщика мусора?

Благодаря конструкциям try, можно легко отловить все проблемы и ошибки, при этом легко оперируя объектами{ом} ошибки.

Уй, какая пакость.

Я узнал о том что у нас есть русское коммьюнити, которое активно занимается D - d@conference.jabber.ru

Нунафик. Мировое коммьюнити есть? И не в чатике, желательно.

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

А вот эту фразу разъясни. Ибо очень похоже на неудачную попытку нахамить.

кал - овер9к

Очень на то похоже.

Ну изучите http://www.digitalmars.com/d/2.0/index.html

Cмотрю. Куча трескучих фраз и один исходник, написанный в стиле «мама, смотри, какое у меня ООП».

all D users agree that by downloading and using D, or reading the D specs, they will explicitly identify any claims to intellectual property rights with a copyright or patent notice in any posted or emailed feedback sent to Digital Mars.

Подобные бюрократизмы меня вообще вырубают.

Вопрос. Параметрический полиморфизм в языке есть?

Miguel ★★★★★
()

А как на счёт написания и использования EDSL? =)

yyk ★★★★★
()

подождём пока Александреску допишет своё творение, а там снова пощупаем

jtootf ★★★★★
()

Пробовал какое-то время назад, язык действительно интересен (он действительно современный, таже конструкция «int main(string[] args){}» радует с первого взгляда) и меня смущает только сборщик мусора и хотелось бы qtD допиленный (я привык к Qt). Стандартная либа вроде тоже не плохо выглядит... Но вот трабла на практике пока не вижу куда бы его применить.

erfea ★★★★★
()
Ответ на: комментарий от Love5an

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

solid
()
Ответ на: комментарий от Love5an

>Нужны биты на тайптег и т.п.

хм, а не лучше ли было-бы использовать [un]boxing? Всё равно low-level функции типизируются, а для прочих, в массе своей использующих и списки/структуры/классы, оверхед не был бы так страшен?

yyk ★★★★★
()
Ответ на: комментарий от yyk

Это надо спросить у разработчиков CMUCL/SBCL(компилятора SBCL и CMUCL, а не того скриптового говноязыка); после чего следует задаться вопросом - почему оные создают для такого динамичного и высокоуровневого языка, как CL код, схожий по производительностью с статически типизированной(!!) жабой, которая как раз боксингом занимается.

Love5an
()
Ответ на: комментарий от tia

>Преимуществ в разы больше чем у ваших мудулоберонов.

Синтаксический сахар в основном, и метапрограммирование. Приятно, что из модулооберонов сохранили нормальную модульность. К модулооберонам, наверное, ближе будет Go — интерфейсы с duck typing это почти расширяемые типы Оберона. Хотя если поискать в манах, это умеет и стандартный GCC (гуглить про signature, и их отличия от интерфейсов и абстрактных виртуальных классов)

как там дела, кстати, с парсерами json'а

Советую глянуть форум. Увы, не в курсе json'а,

c JSON-ом всё нормально: tango, phobos2 умеют его парсить и генерировать. Компилятор DMD умеет выдавать AST информацию (ближе, наверное, к ctags) в JSON формате, так что клепальщикам IDE остаётся только разбирать его на лету.

anonymous
()
Ответ на: комментарий от anonymous

Компилятор DMD умеет выдавать AST информацию (ближе, наверное, к ctags) в JSON формате, так что клепальщикам IDE остаётся только разбирать его на лету.

Учитывая, что DMD файл аналогичного размера компилит в 20-30 раз быстрее, чем g++, это можно использовать для получения оперативной информации о коде. Хотя, конечно, лучше бы сделали компилер либой, как dil.

naryl ★★★★★
()

Да, запускается «из коробки» под FreeBSD, MacOSX, Linux, Windows. Сорцы открыты, есть SVN. Сорцы написаны в довольно понятном, портабельном виде — все архитектурно-осе-специфические места аккуратно выделены #ifdef-ами, и обставленны assert-ами. Я недавно портировал dmd 1.052 под Хайку. Порт получился довольно простой, хвала Волтеру Брайту за понятные исходники. Порт пока не доделан, так что релизов пока не будет, надо тестировать, сделать нормальный чистый diff, а не HG репу, сделать порт по всем требованиям Haiku Ports — он нестабильный в том смысле, что компилятор собирается, успешно собирает Танго, Фобос, но при попытке линковки collect2/ld ругается на версионированный символ _d_throw@4 , не может его найти и прилинковать (хотя и в местах объявления, и использования всё нормально) — у Гайки свой ELF формат, свои ld скрипты, которые, как я подозреваю, просто выкидывают секцию с версионированным символом. Надо гуглить на тему GOT, PLT, DSO, атрибутов GCC, собрать под линуксом и гайкой, сравнить их ЛД скрипты.

Проблема где-то в гайковском тулчейне GCC 4.3.3 — может, GCC 2.95 нормально соберёт, может надо расставить аттрибуты секций вручную, может надо что-то в скриптах пофиксить. Кому интересно, смотрите подробности на qube.ru, может кто из энтузиастов допилит поделие.

Факт в том, что компилятор портировать невероятно просто. Проблемы вылазят в основном с тулчейном.

Также недавно собирал LDC под MinGW. Потребовалось невероятное терпение к долгой сборке + глюкам msys + немного допортировать Tango,  — библиотека считала, что винда\MINGW это Posix, пришлось фигурно расставить version. Но тоже не могу порт Танго назвать сильно сложным, может сейчас в SVN оно и работает «из коробки», давно не проверял.

Алсо, есть gdc — старый под Gcc 4.1 и новый под GCC 4.3.4. Видел блог, как кто-то кросскомпилировал им под arm-ы и iPod-Ы, делали какую-то игрушку.

anonymous
()

>а по теме компилер запукаеся под архитектурами отличными от x86?

А, тебе нужно именно другую архитектуру процессора, не оси? gdc в этом смысле более портабельный. DMD больше написан «под DMC», хотя под FreeBSD/Linux/MacOSX/..(Haiku ;-) он собирается именно через GCC.

Так что да. запускается. Только вот как там с optlink — ХЗ, надо пользоваться системным LD.

anonymous
()
Ответ на: комментарий от alg0rythm

> еще вопрос: можно из D вызывать системные вызовы Unix? Поискал по сайту, но ничего не нашел :-(

через встроенный ASM можно. А вообще, посмотри на xombb http://wiki.xomb.org/index.php?title=XOmB_Bare_Bones

Cистемные вызовы, однако, тебе вряд ли понадобятся напрямую. Можно дергать через libc, это модули std.c.*

anonymous
()
Ответ на: комментарий от wfrr

> «The compiler back-end source code is available but not under an open source license.»

вот поэтому те исходники dmd что в svn лежат, и собираются через GCC, его бекендом. А исходники dmd+dmc+optlink+symantec бекенда закрыты, да. И фиг с ними.

anonymous
()
Ответ на: комментарий от thevery

>а где описание киллер-апсов?

Deadlock и вся team0xf? Deadlock там как, живой ещё?

Супер-синтаксического сахара?

См. Hybrid, + рейтрейсер того же автора на шаблонах времени компиляции.

anonymous
()
Ответ на: комментарий от bibi

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

anonymous
()
Ответ на: комментарий от Love5an

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

то, что так делают [наверное] во всех лиспах (CL) - традиция скорее =)

Ну и битовый тайпинг «размазывает» «оверхед» по всему коду тоникм слоем, тогда как боксинг «густо кладёт» его в конкретных местах.

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

Я что хочу сказать: с боксингом функции от «простых типов» (и их применение) получались бы максимально быстрыми. Да и типизированные функции от сложных объектов то-же бы получались практически без оверхеда. Все тормоза аккумулировались бы в области перехода между статикой и динамикой. А применение этой область можно пытаться контролировать в программах.

P.S. Я не «наезжаю» на CL - я пытаюсь понять в каких случаях какая «политика» выгоднее.

yyk ★★★★★
()
Ответ на: комментарий от bibi

> Лишь сумасшедший будет использовать в Windows среде GCC или вообще что-то, отличное от MSVC. В серверной же стихии - это ещё большой вопрос.

Ну я такой сумашедший. MSVC мне менее приятен, чем нормальный шелл+нормальный компилятор. Правда, я собираю MinGW-вом через crossdev -t i686-pc-mingw32 в Генту, пишу свои ебилды в оверлей /usr/local/crossdev/crossdev-i686-pc-mingw32, собираю через tmpfs и гораздо быстрее чем через msvc. Плюс имеем нормальный пакетный менеджер. Это конечно ещё не Gentoo prefix win32 (там маньяки собирали через SFU и msvc), но пользоваться уже приятнее — есть нормальный пакетный менеджер «под винду» (целевую кросстулзами, да ;-)

Хочу ещё вот Гайку прикрутить по той же схеме. Не возиться с портами врукопашную, а использовать всю мощь сrossdev-a.

anonymous
()

Я правильно понял, что краткий статус это:

1. Нестабильные спеки

2. Глючные компиляторы

3. Нет доделанных портабельных компиляторов

4. Доступно мало библиотек.

5. Дохлое и неразвитое коммьюнити (если сравнивать с хаскелем/лиспом)

6. Ещё вот-вот и всё допилят?

suzuki
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.