Rust, документация и т.д. - Rust

Здравствуйте, alex_public, Вы писали:

_>Если честно, то не очень ясно. Т.е. примеры эти вполне ясны, но в них не видно никаког преимущества (разве что юнит тесты).

Как ты понимаешь, я еще далеко не по всем возможностям Rust примеры написал.

_>Т.е. можно провести какое-то сравнение (пусть даже по личным впечатлениям) с C++, D, Go?

Что мне больше всего нравится в Rust по сравнению с C++. С D не сравниваю, почему — напишу ниже:

Туплы, входящие в сам язык, а прикрученные сбоку;
Сравнение с образцом;
Полноценные замыкания;
Расширенная версия перечислений;
Возможность передавать данные в функцию by-copy или by-move;
Простые и очевидные шаблоны (хотя да, за лет 5-7 я к плюсовым тоже привык);
Встроенная в язык система сборки и система модульного тестирования;
Интерфейсы, позволяющие добавлять функции к существующим типам. Полиморфные интерфейсы;
Ну и конечно же система тасков, с портами и каналами.

_>Лично мне больше всего нравится D, но пока не могу его нигде использовать в связи с отсутствием инфраструктуры. Поэтому пока C++ как основное. Go кажется интересным только своей простотой, но она не всегда полезна. Возможно для серверных скриптов Go может быть интересен (вместо java/python/ruby), но это всё в будущем. Rust не пробовал.

D — мертвый язык, ты его ни сейчас ни потом не сможешь использовать. С практической точки зрения он интересен не более чем латынь, хотя с теоретической, он не менее интересен, а с учетом того что он уже имеет неплохой набор библиотек, даже более интересен чем Rust.
Если говорить о плюсах — язык, за счет огромного багажа кода, не может себе позволить какого-то более менее серьезного развития или изменения. Go — глянул и он меня ну совсем ничем не зацепил, так что я его не использовал и не планирую использовать в принципе.
Если же говоить про Rust, он еще только формируется и, вполне возможно, и не взлетит вовсе. Но, за Rust стоит корпорация, и это не просто развлекуха пары чуваков (как в случае с D), так что это дает некие надежды на его дальнейшее практическое использование. Ну а текущий задел языка, лично меня, после 12 лет работы с C++, очень радует.

Здравствуйте, kaa.python, Вы писали:

KP>Последнее вермя меня просто неописуемо прет от Rust, посути — это тот язык которого мне давно не хватало. Так вот, [...]

Да, не хватает адекватной альтернативы для С++, но Rust несколько настораживает.

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

Как-то неоднозначна ситуация с обработкой ошибок. Нет никаких перехватов fail. Всё сделано по мотивам Эрланга: пусть таск упадёт, раскрутим стэк, всё удалим, плюнем в лог, потом разберёмся, контролирующий таск заново перезапустит упавший поток, если нужно. Якобы нет гарантий, что состояние таска можно восстановить корректно при fail. Но всё-таки Rust это не Эрланг, а язык общего назначения, без спец. заточенной ВМ, да ещё с намеком на системную разработку. Да и в Эрланге вроде не сразу ввели конструкции для аналогов try-catch, но всё-таки вынуждены были ввести. Имхо, механизмы его брата языка Go — defer и recover — как раз бы точно не помешали: это, фактически, один блок catch на функцию (оптимизация), возможность остановить раскрутку стэка и корректно указать результат функции, и нет управляющих специнструкций вида try-catch/except/finally. При этом наличие в языке деструкторов, в отличие от Go, не вынуждает часто писать defer, фактически, он нужен будет только для перехвата fail. К тому же, в Rust как-то нет сейчас массовой привычки возвращать код ошибки в функциях, в рамках стандартной библиотеки. Это подталкивает как бы к одному способу обработки всех проблем, т.е. через fail (в отличие от Go, где есть некоторое смешение способов, навязанное авторами: panic и коды возврата).
А так, приятно, что борятся с ошибками: пытаются убрать null-ссылки, есть тип option, ввели RAII (ресурсы), есть пока мутный typestates (плохо ещё описан), и пр.

И есть опасение, что язык могут переусложнить, причём из-за стремления "к идеальности". Вот отрывок из твоего сообщения из соседней темы (вырезка из документации):

KP>Then there is the by-copy style, written +. This indicates that the function wants to take ownership of the argument value. If the caller does not use the argument after the call, it will be 'given' to the callee. Otherwise a copy will be made. This mode is mostly used for functions that construct data structures. The argument will end up being owned by the data structure, so if that can be done without a copy, that's a win.

KP>

KP>type person = {name: str, address: str};
KP>fn make_person(+name: str, +address: str) -> person {
KP>    ret {name: name, address: address};
KP>}
KP>

KP>Finally there is by-move style, written -. This indicates that the function will take ownership of the argument, like with by-copy style, but a copy must not be made. The caller is (statically) obliged to not use the argument after the call; it is de-initialized as part of the call. This is used to support ownership-passing in the presence of non-copyable types.

Имхо, современные компиляторы должны сами всё оптимизировать по самое не могу, и нужно как бы им не мешать. Вот они собираются ещё ввести классы (что, имхо, уже излишне), как в "продвинутом" языке они захотят иметь декларации и для контр/ковариантности для типов. Т.е. эти плюсы и минусы будут рядом ещё и с типами, где ещё уже есть указания kind-а (copy, send). И это всё ещё разбавлено отдельным указанием мутабельности, константности, а также указателями, "боксовостью" и "уникальностью", причём и для указателей, и для лямбд, а также ещё есть желание и регионы для указателей ввести. Т.е. в языке есть такой "огород":

fn SHA1(src: *u8, sz: uint, out: *u8) -> *u8
fn mk_appender(suffix: str) -> fn@(str) -> str 
call_twice(fn@() { "I am a boxed closure"; });
fn box<T>(x: T) -> @T { @x }
fn increase_contents(pt: @mut int)
fn for_each(v: [mut @int], iter: fn(@int)) 
fn vec_push(&v: [int], elt: int) 
fn plus1(&&x: int) -> int
fn head<T: copy>(v: [T]) -> T
fn pure_foldl<T, U: copy>(ls: list<T>, u: U, f: fn(&&T, &&U) -> U) -> U
fn proc_tree<T>(t: ~tree<T>)
fn foo(&t: T, v: @const int)
let x: @int = @10;
let x: ~int = ~10;

// и планируемые регионы:

fn pick_one(a: A& T, b: A& T) -> A& T

type tree<D, R&> = {
    left: R& option<R& T<R&>>;
    right: R& option<R& T<R&>>;
    data: D;
};

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

Да, все эти фичи дадут не мало пищи для фана многим энтузиастам, особенно в рамках своих любительских проектов. Но, имхо, для массовой промышленности это как-то опасно. Тут можно и запросто не доглядеть, что где-то какая-то закорлючка пропущена, а также утяжеляет и процесс разработки. Непросто и программистам, и компиляторам для оптимизаций.
В языке здравые концепции: неизменность объектов по умолчанию, явное указание мутабельности и передача прав владения объектов (вместо их копирования). Имхо, нужно как-то уже избегать в языке всех этих супер-указателей, например, ввести какие-то блоки для явного указания того, что мы хотим править "по месту", как по мотивам Кложуры, что ли: transient v: [T] {... правим v без копий}. Аналогично и для "send"-блока, т.е. после того, как мы передали объект куда-то внутри этого блока, мы уже не владеем объектом. Причём как-то нужно в языке подводить к тому, чтобы таким могли заниматься только владельцы объектов. Тут и компиляторы смогут сами догадаться, когда что-то возможно по ссылке передать (или вообще заинлайнить), когда не нужны лишние барьеры/блокировки между потоками и т.д.

К сожалению, ничего конкретно сказать не могу, т.к. нет глубокого понимания, как нужно сделать, особенно в рамках около системного языка. Хотелось бы, чтобы вся эта "сверх-мудрённая указательность" уже осталась в С++, пусть он уже будет вечным супер-элитным. Но пока это розовые мечты.

Всё выше перечисленное сугубо личное имхо.

Здравствуйте, alex_public, Вы писали:

_>Т.е. можно провести какое-то сравнение (пусть даже по личным впечатлениям) с C++, D, Go?
Самое классное — это многопоточность в Erlang-стиле (т.е. shared-nothing по умолчанию).

Здравствуйте, PSV100, Вы писали:

PSV>Да, не хватает адекватной альтернативы для С++, но Rust несколько настораживает.

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

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, PSV100, Вы писали:

PSV>>Да, не хватает адекватной альтернативы для С++, но Rust несколько настораживает.

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

Да, написать то можно, но нет почвы для "любовных писем". Я лично не могу что-то сказать, что мол вы ребята ошибаетесь, нужно делать так-то, наоборот, они меня во многом смогут поучить. А почему они делают именно так, в принципе, в своей документации они объясняют. Совершенно понятно их стремление быть по духу близким к С++, понятно, что Эрланг сильно оказал впечатление, хотя его модель многопоточности не идеальна, например, автор той же вскользь упомянутой здесь Кложуры вполне адекватно её критиковал, поэтому у себя сделал иные подходы, но местами и похожие. Просто есть опасение, что в языке получится, ну, не знаю как сказать, некий эффект Хаскеля: сначала придумывают жёсткую и максимально контролирующею систему типов, но народ ленивый, как и Хаскель, хочет писать универсально и гибко, поэтому вынуждены затем придумывать средства по "безопасному" обходу этих ограничений. Если базовые концепции (да и синтаксис) в Хаскеле просты как валенок, но как дело доходит до монадных вычислений (но это ещё не смертельно), полиморфизма фиг знает какой степени, семейств типов и пр., то среднепаршивый программист начинает уже себя чувствовать валенком.

Будет грустно, если язык в чём-то окажется проще, чем С++ (как те же шаблоны, ты верно подметил, хотя всё-таки эти угловые скобки неудобны), а в чём-то на два кг опаснее и тяжелее.

Здравствуйте, PSV100, Вы писали:

PSV>Здравствуйте, kaa.python, Вы писали:

KP>>Здравствуйте, PSV100, Вы писали:

PSV>>>Да, не хватает адекватной альтернативы для С++, но Rust несколько настораживает.

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

PSV>Да, написать то можно, но нет почвы для "любовных писем". Я лично не могу что-то сказать, что мол вы ребята ошибаетесь, нужно делать так-то, наоборот, они меня во многом смогут поучить. А почему они делают именно так, в принципе, в своей документации они объясняют. Совершенно понятно их стремление быть по духу близким к С++, понятно, что Эрланг сильно оказал впечатление, хотя его модель многопоточности не идеальна, например, автор той же вскользь упомянутой здесь Кложуры вполне адекватно её критиковал, поэтому у себя сделал иные подходы, но местами и похожие. Просто есть опасение, что в языке получится, ну, не знаю как сказать, некий эффект Хаскеля: сначала придумывают жёсткую и максимально контролирующею систему типов, но народ ленивый, как и Хаскель, хочет писать универсально и гибко, поэтому вынуждены затем придумывать средства по "безопасному" обходу этих ограничений. Если базовые концепции (да и синтаксис) в Хаскеле просты как валенок, но как дело доходит до монадных вычислений (но это ещё не смертельно), полиморфизма фиг знает какой степени, семейств типов и пр., то среднепаршивый программист начинает уже себя чувствовать валенком.

А касательно Хики и Эрланга нет ссылки случаем?

Здравствуйте, Курилка, Вы писали:

К>А касательно Хики и Эрланга нет ссылки случаем?

Clojure: Identity and State — здесь поверхностно описывается модель многопоточности в clojure и там же есть немного про акторов, какие есть с ними нюансы.

Здравствуйте, kaa.python, Вы писали:

KP>D — мертвый язык, ты его ни сейчас ни потом не сможешь использовать.

А... держите меня семеро. И это говорит новоиспеченный фанат еще не рожденного языка.

Мил человек. D живет уже около 10 лет. Дай бог, чтобы этот Раст столько же прожил.

Здравствуйте, Cyberax, Вы писали:

_>>Т.е. можно провести какое-то сравнение (пусть даже по личным впечатлениям) с C++, D, Go?
C>Самое классное — это многопоточность в Erlang-стиле (т.е. shared-nothing по умолчанию).

А тебе не кажется, что подобные вещи должны в библиотеках лежать, а не в язык хардкодиться?

Здравствуйте, VladD2, Вы писали:

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, WolfHound, Вы писали:

WH>Только ты их без жестокого метапрограммирования в библиотеку не положишь.
WH>А оно есть только в лиспе и сам знаешь где.

Это чёто? Если в языке есть паттерн-матчинг, то можно и в библиотеку положить. По сути это типизированные очереди.

Здравствуйте, VladD2, Вы писали:

VD>Мил человек. D живет уже около 10 лет. Дай бог, чтобы этот Раст столько же прожил.

Живой язык — это язык употребляющийся для коммерческой разработки. Rust еще не родился даже, и, возможно, и не родиться. Но вероятность рождения есть. В случае с D такой вероятности уже нет, хотя, лично я, долгое время на это очень надеялся.

Здравствуйте, VladD2, Вы писали:

_>>>Т.е. можно провести какое-то сравнение (пусть даже по личным впечатлениям) с C++, D, Go?
C>>Самое классное — это многопоточность в Erlang-стиле (т.е. shared-nothing по умолчанию).
VD>А тебе не кажется, что подобные вещи должны в библиотеках лежать, а не в язык хардкодиться?
Чтобы полный профит от Эрланговского стиля получить — не должны.

В Rust и Erlang нет глобальной кучи, к примеру. Так что GC можно очень шустро собирать мусор в одном лёгком потоке, не мешая остальным.

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, VladD2, Вы писали:

VD>>Мил человек. D живет уже около 10 лет. Дай бог, чтобы этот Раст столько же прожил.

KP>Живой язык — это язык употребляющийся для коммерческой разработки.

Из этого определения следует, что Rust мертвый язык, а D живой.

KP>Rust еще не родился даже, и, возможно, и не родиться.

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

KP>Но вероятность рождения есть.

Вероятность того, что на тебя сейчас упадет астероид тоже есть.

KP>В случае с D такой вероятности уже нет, хотя, лично я, долгое время на это очень надеялся.

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

Но это твой выдуманный мир. А в реальном мире D уже есть около 10 лет. И где-то лет 5 он вполне стабилен для реального использования.

Твое же преклонение перед Rust закончится точно так же. Тысячи таких же как ты будут сидеть и ждать чуда которое превратит Rust в "живой" язык, в их глазах.

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

Здравствуйте, VladD2, Вы писали:

VD>>>Мил человек. D живет уже около 10 лет. Дай бог, чтобы этот Раст столько же прожил.

Он 10 лет пишется и никак не напишется. Подтверждением этому служат чуть больше 0 реальных (коммерческих) приложений/сайтов/чего угодно на нем написанных. Эти 10 лет разработки как бы намекают на то, что и дальше он останется вечно пишущимся языком.

VD>Из этого определения следует, что Rust мертвый язык, а D живой.

На данный момент они оба в одинаковом положении. Но то, что не взлетело за 10 лет, не взлетит и дальше. То что новое, и довольно логичное, очень может даже взлететь.

VD>И это, видимо, куда перспективнее реально используемого языка.

Где используемый? Кем используемый? Линки приведи, кроме "ну я его использовал в исследовательской разработке и ...".

VD>Вероятность того, что на тебя сейчас упадет астероид тоже есть.

Есть. И? Ты чего так разошелся-то? Я же даже не Немерле мертворожденным назвал, а какой-то D

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

Я один из упертых, который 12 лет сидит на C++ и его почти все устраивает. Но, иногда, хочется какого-то разнообразия (для системной разработки).

VD>Но это твой выдуманный мир. А в реальном мире D уже есть около 10 лет. И где-то лет 5 он вполне стабилен для реального использования.

про реальный мир см. выше.

VD>Твое же преклонение перед Rust закончится точно так же. Тысячи таких же как ты будут сидеть и ждать чуда которое превратит Rust в "живой" язык, в их глазах.

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

Здравствуйте, Cyberax, Вы писали:

C>Чтобы полный профит от Эрланговского стиля получить — не должны.

Да? Обоснуй!

C>В Rust и Erlang нет глобальной кучи, к примеру. Так что GC можно очень шустро собирать мусор в одном лёгком потоке, не мешая остальным.

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

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

Здравствуйте, VladD2, Вы писали:

VD>Но это твой выдуманный мир. А в реальном мире D уже есть около 10 лет. И где-то лет 5 он вполне стабилен для реального использования.
...
VD>Так что не фига думать. Бери и используй. И вот когда при использовании появятся какие-то непреодолимые трудности, а авторы языка откажутся их исправлять, вот тогда язык и будет мертвым.

Ну вот лично мне не хватает в D различных библиотек. Мы используем не только C библиотеки (с которыми у D всё хорошо), но и C++. А их он ликовать не может. И с биндингами ужас, в отличие от например Питона или вообще Хаскеля. Т.е. язык замечательный (на мой вкус), но вокруг него не создана реальная инфраструктура, которая есть у других языков.

Здравствуйте, Cyberax, Вы писали:

VD>>А тебе не кажется, что подобные вещи должны в библиотеках лежать, а не в язык хардкодиться?
C>Чтобы полный профит от Эрланговского стиля получить — не должны.
C>В Rust и Erlang нет глобальной кучи, к примеру. Так что GC можно очень шустро собирать мусор в одном лёгком потоке, не мешая остальным.

Ну вот например у нас есть проект на C++, в котором потоки используются в Эрланг стиле. И ничего сложного.

Преимущества Go и Rust в этом смысле больше напоминают синтаксический сахар. Что в прочем тоже бывает очень приятно. )

Здравствуйте, kaa.python, Вы писали:

KP>Он 10 лет пишется и никак не напишется.

Открою тебе секрет. Все языки пишутся все время пока они живут. Даже Лисп которому боле 50 лет пишется.

KP> Подтверждением этому служат чуть больше 0 реальных (коммерческих) приложений/сайтов/чего угодно на нем написанных.

Это никак может быть подтверждением. К тому же коммерческие применения (как и не коммерческие) у Ди точно есть. FR, если не ошибаюсь, еще несколько лет назад давал страничку со ссылками на проекты созданные на Ди.

Но ты умудрился не понять моих слов.

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

KP>Эти 10 лет разработки как бы намекают на то, что и дальше он останется вечно пишущимся языком.

И слава богу. Вот когда его перестанут "писать" (а реально — развивать) — это и будет днем его смерти.

VD>>Из этого определения следует, что Rust мертвый язык, а D живой.

KP>На данный момент они оба в одинаковом положении. Но то, что не взлетело за 10 лет, не взлетит и дальше. То что новое, и довольно логичное, очень может даже взлететь.

Да ладно. На Ди пишутся проекты. И не так уж мало.

KP>Где используемый? Кем используемый? Линки приведи, кроме "ну я его использовал в исследовательской разработке и ...".

Ссыкли приводил FR, если не ошибаюсь. Я Ди не занимаюсь, да и вообще, ссылки не собираю.

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

VD>>Вероятность того, что на тебя сейчас упадет астероид тоже есть.

KP>Есть. И? Ты чего так разошелся-то? Я же даже не Немерле мертворожденным назвал, а какой-то D

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

KP>Я один из упертых, который 12 лет сидит на C++ и его почти все устраивает. Но, иногда, хочется какого-то разнообразия (для системной разработки).

VD>>Но это твой выдуманный мир. А в реальном мире D уже есть около 10 лет. И где-то лет 5 он вполне стабилен для реального использования.

KP>про реальный мир см. выше.

VD>>Твое же преклонение перед Rust закончится точно так же. Тысячи таких же как ты будут сидеть и ждать чуда которое превратит Rust в "живой" язык, в их глазах.

KP>То что ты называешь чудом, я называю "использованием в коммерческой разработке".

Здравствуйте, alex_public, Вы писали:

_>Ну вот лично мне не хватает в D различных библиотек. Мы используем не только C библиотеки (с которыми у D всё хорошо), но и C++. А их он ликовать не может. И с биндингами ужас, в отличие от например Питона или вообще Хаскеля. Т.е. язык замечательный (на мой вкус), но вокруг него не создана реальная инфраструктура, которая есть у других языков.

А к Хаскелю или Питону можно подключать С++-библиотеки?

И вообще, есть язык к которому можно подключать С++-библиотеки? В С++ нет никаких бинарных стандартов. О чем вообще может идти речь?

Любой С++-ник норовит переписать все библиотеки, так как чужие использовать боится. И в друг у Ди начинает не хватать библиотек.

Заверни нужные библиотеки в C-библиотеку и используй. Плюс еще у Ди есть кое-какая поддержка С++.

Здравствуйте, VladD2, Вы писали:

VD>А к Хаскелю или Питону можно подключать С++-библиотеки?

У Питона есть биндинги ко всем используемым нами C/C++ библиотекам. На счёт Хаскеля не уверен (не проверял), но в любом случае у него на порядок больше их, чем у D.

VD>И вообще, есть язык к которому можно подключать С++-библиотеки? В С++ нет никаких бинарных стандартов. О чем вообще может идти речь?

Ну в этом и проблема простого ухода от C++. Кстати, у Digital Mars же есть свой C++ компилятор — вполне могли бы что-нибудь такое сделать совместимое. Это по идее всех удовлетворило бы.

VD>Заверни нужные библиотеки в C-библиотеку и используй. Плюс еще у Ди есть кое-какая поддержка С++.

Хы, я же не про какие-то микробиблиотечки говорю. А про всяких монстров. Там делать биндинги самим — это может быть больше месяца работы. У нас нет свободного времени на такие дела. А вот для того же Питона оно уже всё есть готовое...

Здравствуйте, alex_public, Вы писали:

_>У Питона есть биндинги ко всем используемым нами C/C++ библиотекам. На счёт Хаскеля не уверен (не проверял), но в любом случае у него на порядок больше их, чем у D.

Не надо мешать С и С++.

Потом, как я понимаю, биндинги — это обертки. Кто мешает сделать обертки для С++-библиотек?

В чистом виде никакие средства импорта С++-библиотек невозможны, так как большая часть С++-библиотек — это шаблоны. А шаблоны невозможно использовать за пределами С++.

VD>>И вообще, есть язык к которому можно подключать С++-библиотеки? В С++ нет никаких бинарных стандартов. О чем вообще может идти речь?

_>Ну в этом и проблема простого ухода от C++.

Нет никаких проблем в отказе от С++. Я бросил этот недоязык 10 лет назад и ни капельки не жалею.

_> Кстати, у Digital Mars же есть свой C++ компилятор — вполне могли бы что-нибудь такое сделать совместимое. Это по идее всех удовлетворило бы.

Они и сделали. Но невозможное сделать нельзя. Тащить шаблоны плюсов в другой язык — гробить этот язык.

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

VD>>Заверни нужные библиотеки в C-библиотеку и используй. Плюс еще у Ди есть кое-какая поддержка С++.

_>Хы, я же не про какие-то микробиблиотечки говорю. А про всяких монстров. Там делать биндинги самим — это может быть больше месяца работы. У нас нет свободного времени на такие дела. А вот для того же Питона оно уже всё есть готовое...

Какие на фиг монстры на С++? О чем вообще речь?

Здравствуйте, VladD2, Вы писали:

C>>В Rust и Erlang нет глобальной кучи, к примеру. Так что GC можно очень шустро собирать мусор в одном лёгком потоке, не мешая остальным.
VD>GC вообще никак не связан с языком.
Ну вот как ты сделаешь так, чтобы в C# мусоросборщик был гарантировано локализован одним потоком?

А никак, так как могут быть ссылки между потоками. Так что ты вынужден будешь:
1) Таки тормозить все потоки на время сборки, хотя бы на короткое время.
2) Использовать тормозной на больших кучах трёхцветный mark&sweep.

Я уж не говорю, что сложность GC будет зашкаливать.

VD>Вот для той же риалтайм-явы сделали и потоки со своим GC, и даже потоки вообще без GC.
Realtime Java — это больше мифологический персонаж. Его некоторые видели, некоторые герои из легенд с ним сражались, но в обычной жизни не встретить.

Здравствуйте, Cyberax, Вы писали:

C>Realtime Java — это больше мифологический персонаж.

О... это вера. Тут наука бессильна. Могу только посоветовать попробовать на практике. Может поможет. Хотя вряд ли.

Извини, но вести полемику с верующими мне не интересно.

Здравствуйте, VladD2, Вы писали:

VD>Открою тебе секрет. Все языки пишутся все время пока они живут. Даже Лисп которому боле 50 лет пишется.

Да, и эльфийский язык тоже жив. Только сможешь ли ты погороить на нем с кем-то, кроме пары фанатиков? А если не сможншь, то жив ли он?

VD>Это никак может быть подтверждением. К тому же коммерческие применения (как и не коммерческие) у Ди точно есть. FR, если не ошибаюсь, еще несколько лет назад давал страничку со ссылками на проекты созданные на Ди.

Угу, на уровне использования в повседневных разговорах языка Высоких Эльфов

VD>Дело в тебе и таких как ты. Пока ты будешь ждать какие-то коммерческих применпний, то их так и не появится. Потому как ты присоединявшийся к планктону вечно ждущему погоды от моря.

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

VD>И слава богу. Вот когда его перестанут "писать" (а реально — развивать) — это и будет днем его смерти.

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

VD>Да ладно. На Ди пишутся проекты. И не так уж мало.

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

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

Я даже занию почему ты никогда не мог их понять

Но, изучение языка должно давать какой-то выхлоп (вот ты будешь учить эльфийский? он же такой классный! а почему не будешь?). Во всех остальных случаях, изучения языка превращается в пустую трату времени и сил, которых и так крайне мало и всегда можно потратить на что-то более полезное.
Поэтому я и сказал что D мертв — он не будет использоваться в коммерческой разработке уже никогда (если только чудо не случиться). А Rust, его еще и сложившимся языком назвать нельзя и, само собой, ничего хорошего, кроме него самомго, на нем на данный момент написанно не может быть в принципе.

Здравствуйте, VladD2, Вы писали:

C>>Realtime Java — это больше мифологический персонаж.
VD>О... это вера. Тут наука бессильна. Могу только посоветовать попробовать на практике. Может поможет. Хотя вряд ли.
Ну вот всё. Закрыл IDEA с проектом на полмиллиона строк кода на Java и ушёл пить кока-колу с горя.

Я объяснил почему realtime с подходом Rust'а много проще — куча естественным образом сегментирована на гарантировано независимые блоки. У глобальных GC такой помощи нет.

VD>Извини, но вести полемику с верующими мне не интересно.
Зеркало нужно?

Здравствуйте, Cyberax, Вы писали:

C>Я объяснил почему realtime с подходом Rust'а много проще — куча естественным образом сегментирована на гарантировано независимые блоки. У глобальных GC такой помощи нет.

Ты бы почитал бы немного о том, что что взялся обсуждать. Для RTSJ и сборщики мусора есть гарантирующие задержки не более 1 миллисекунды, и специальные типы потоков которые позволяют вообще без GC обходиться.

Какой смысл заменять С++ в 10 раз более сложной системой? Вот RTSJ другое дело. Тут есть разумные средства контроля отклика, но при этом нет нужды изучать 5 типов указателей и рулить памятью вручную в 100% случаев.

Здравствуйте, VladD2, Вы писали:

C>>Я объяснил почему realtime с подходом Rust'а много проще — куча естественным образом сегментирована на гарантировано независимые блоки. У глобальных GC такой помощи нет.
VD>Ты бы почитал бы немного о том, что что взялся обсуждать. Для RTSJ и сборщики мусора есть гарантирующие задержки не более 1 миллисекунды, и специальные типы потоков которые позволяют вообще без GC обходиться.
Yawn. Я как бы знаю как GC в Java рабтают вплоть до уровня ассемблерного кода, с помощью которого делаются барьеры записи.

Пока ситуация такая — realtime GC имеют неприемлимые для обычных приложений характеристиски. До того неприемлимые, что товарищи из http://www.azulsystems.com/ делают специализированное железо для аппаратного ускорения GC (у них там натурально полностью свой процессор, со специальной архитектурой).

VD>Какой смысл заменять С++ в 10 раз более сложной системой? Вот RTSJ другое дело. Тут есть разумные средства контроля отклика, но при этом нет нужды изучать 5 типов указателей и рулить памятью вручную в 100% случаев.
У тебя какая-то C++-мания.

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

Здравствуйте, kaa.python, Вы писали:

KP>А ты не думаешь о том, что пракстически нулевое коммерческое использование как раз говорит о том, что с языком что-то не так?

Нет. Я способен сам попробовать и определить пригодность.

KP>Только быстрый поиск поиск гуглом ничего не дает. Так же как и поск по Монстру и аналогичным сайтам, которые являются отличным индикатором того, пациент скорее жив или скорее мертв.

А как ты себе это видишь? Вот как найти продукты написанные на VB? И означает ли то, что я не могу их найти, что VB мертв?

KP>Я даже занию почему ты никогда не мог их понять

Но, изучение языка должно давать какой-то выхлоп

Ты язык для чего ищешь? Что ты от него хочешь? Вот поставь и проверь свой выхлоп. Чё рассуждать то не о чем?

Я бы еще понял бы, если ты не знал бы ФП и пытался понять подходит ли тебе некий ФЯ. Но тут то императивный язык. Тут ведь все очевидно. Да и выучить его можно буквально за неделю.

KP> (вот ты будешь учить эльфийский? он же такой классный! а почему не будешь?).

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

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

Обсуждение языка, и тем более, заочная критика — вот это самое бесполезное проведение времени. Скачай попробуй... позадавай вопросы на форумах... Сделай выводы (свои выводы). Тогда, даже если откажешься от его выбора сможешь аргументировать свой отказ/выбор. А так это треп — бесполезная трата времени.

KP>Поэтому я и сказал что D мертв — он не будет использоваться в коммерческой разработке уже никогда (если только чудо не случиться). А Rust, его еще и сложившимся языком назвать нельзя и, само собой, ничего хорошего, кроме него самомго, на нем на данный момент написанно не может быть в принципе.

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

Здравствуйте, Cyberax, Вы писали:

C>Yawn. Я как бы знаю как GC в Java рабтают вплоть до уровня ассемблерного кода, с помощью которого делаются барьеры записи.

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

C>Пока ситуация такая — realtime GC имеют неприемлимые для обычных приложений характеристиски.

Это очередная глупость. Приемлемость определяется задачами. Реалтайм — это не "супер-пупер быстро", а "с гарантированным откликом в определенный интервал времени".

C>До того неприемлимые, что товарищи из http://www.azulsystems.com/ делают специализированное железо для аппаратного ускорения GC (у них там натурально полностью свой процессор, со специальной архитектурой).

Таких проектов было выше крыши. Все как одни вымерли.

VD>>Какой смысл заменять С++ в 10 раз более сложной системой? Вот RTSJ другое дело. Тут есть разумные средства контроля отклика, но при этом нет нужды изучать 5 типов указателей и рулить памятью вручную в 100% случаев.
C>У тебя какая-то C++-мания.

Мания? Скорее фобия. Язык реально бездарный. Точнее бездарный был автор.

Но менять шило на мыло утыканное шилами — это просто глупо. В плюсах мы имели указатели и ссылки, а теперь будем еще 5 видов указателей, плюс знать кода присесть и ку сказать.

C>Ты заметил, что в этом треде обсуждается Rust, в котором каждый поток может иметь свою кучу. И система типов гарантирует, что объекты не будут иметь ссылок на объекты из других потоков.Это даёт офигительный плюс для GC, в частности.

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

Здравствуйте, VladD2, Вы писали:

C>>Yawn. Я как бы знаю как GC в Java рабтают вплоть до уровня ассемблерного кода, с помощью которого делаются барьеры записи.
VD>Ай какой молодец! А ничего, что реализаций серверов, предоставляющих сервисы сильно больше одного? Или ты их все изучил?
А причём тут они? Там или одна общая VM на всех (и тогда они сосут), или куча делится на независимые сегменты.

C>>Пока ситуация такая — realtime GC имеют неприемлимые для обычных приложений характеристиски.
VD>Это очередная глупость. Приемлемость определяется задачами. Реалтайм — это не "супер-пупер быстро", а "с гарантированным откликом в определенный интервал времени".
Ну да. Только гарантия "ну может соберёт 10 мусорных объектов в секунду, но зато всегда откликнется за 1 миллисекунду!" для реальных приложений не особо интересно.

У realtime GC сейчас проблемы такие:
1) Или они требуют многократного overhead'а по памяти по сравнению с обычными GC.
2) Или у них отстойная пропускная способность.

C>>До того неприемлимые, что товарищи из http://www.azulsystems.com/ делают специализированное железо для аппаратного ускорения GC (у них там натурально полностью свой процессор, со специальной архитектурой).
VD>Таких проектов было выше крыши. Все как одни вымерли.
Азул живёт — у них машины покупают высокоскоростные трейдеры, которые на латентности собаку съели.

C>>Ты заметил, что в этом треде обсуждается Rust, в котором каждый поток может иметь свою кучу. И система типов гарантирует, что объекты не будут иметь ссылок на объекты из других потоков.Это даёт офигительный плюс для GC, в частности.
VD>Я заметил, что кто-то хочет найти очередное легкое решение сложных проблем. Причем легкость этого решения заключается в перекладывании на пользователя все сложности этой проблемы.
Ну а что сделать, если проблема реально сложная?

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

Один глобальный GC работает в такой ситуации плохо. Надо как-то его сегментировать, но при этом так, чтобы кросс-сегментное общение было всё же возможно.

VD>Нет. Я способен сам попробовать и определить пригодность.

Пригодность для чего? Для твоего проекта — домашнего питомца? Или для коммерческого проекта, который будет писать большое количество народу? Это две совершенно разные категории проектов. И если в первом случае достаточно просто твоего личного мнения, то во втором случае, т.к. проект надо еще и поддерживать, нужно намного больше.

VD>А как ты себе это видишь? Вот как найти продукты написанные на VB? И означает ли то, что я не могу их найти, что VB мертв?

Причем тут продукты? Он активно использовался (а может и сейчас используется, я не знаю) в коммерческой разработке.

VD>Ты язык для чего ищешь? Что ты от него хочешь? Вот поставь и проверь свой выхлоп. Чё рассуждать то не о чем?

Да я как бы поставил Rust и смотрю что к чему. Так же я ставил и смотрел D. Кстати, понравились оба.

VD>Нет его в природе. Так что трудно сказать классный он или нет.

Это ты говоришь что нету, а кучка фанатиков будет с тобой не согласна.

VD>Твои слова не стоят ни копейки. Ди есть и им можно пользоваться. Он не завоевал признание С++-ников не потому, что он чем-то плох, а потому что есть огромная косность в мышлении, привычки, страх (как у тебя) и т.п.

Он не завоевал успеха не потому что плох, и не потому что мышление костное, а потому, что не надо находить в первой версии языка "критический недостаток", все бросать и начинать пилить уж точно правильнуе версию. Язык для коммерческой разработки отличается от языка для домашних проектов тем, что дает не только и не столько развитие и новые круты примочки, сколько стабильность и возможность собрать старый код новым компилятором (при этом не требуя переписать чуть меньше 50%).

Вообще, костность мышления — это просто отличная отмазка, особенно если язык вроде и не плохой, а не стартует (ну не хотят его использовать в продуктовой разработке хоть убей). Ведь это значит только одно — вокруг закостенелый офисный планктрон, который не оценил гениального творения авторов. Что-то мне это напоминает

Здравствуйте kaa.python, Вы писали:

KP>Последнее вермя меня просто неописуемо прет от Rust,

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

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

... Отправлено с помощью КЫВТ.андроид 0.1

Отчасти то, о чем ты пишешь, и было причиной того, что D не взлетел. В то же время, за Rust стоит Мозилла, и ей же язык нужен не просто прикола ради, а для собственного проекта. Из этого можно сделать вывод о том, что надежда на "взлетит" есть. Хотя, я с тобой согласен — она не велика.

Здравствуйте, ArtemGorikov, Вы писали:

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

AG>Разработчик может быть трижды прав, проводить тренинги в своей команде, демонстрировать работающие проекты. На все будет один ответ "Руководство не готово идти на дополнительный риск поиска спецов с экзотическим скиллом".

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

За Rust-ом, кроме мазилы, фактически стоит гугл, если он сможет для себя воспользоваться проектом, то он сможет, даже косвенно (без обширного целевого PR), повлиять на промышленность.

Здравствуйте, ArtemGorikov, Вы писали:
KP>>Последнее вермя меня просто неописуемо прет от Rust,
AG>Imho экзотические, функциональные, и т.п. языки, за которыми не стоит баблос корпораций, ...
Бывает что корпорации не начинают разрабатывать новый язык с нуля, а "подхватывают" какой либо, из любительских проектов, подходящий им.

Здравствуйте, VladD2, Вы писали:

VD>Нет никаких проблем в отказе от С++. Я бросил этот недоязык 10 лет назад и ни капельки не жалею.

Соболезную)))

Моё мнение: C++ очень плох, но лучше ничего нет. Естественно мы говорим только про решения имеющие инфраструктуру вокруг языка, а не поделки энтузиастов.

VD>Они и сделали. Но невозможное сделать нельзя. Тащить шаблоны плюсов в другой язык — гробить этот язык.

И без шаблонов полно нужных библиотек.

VD>Короче, это очередной поиск отмазок. Если у вас руки не из задницы, то за месяц вы спокойно создадите себе окружение.

Месяц (или несколько) работы только над этим? Возможно. Но у нас дела есть и другие. От применения D пока только приятность программистам (и при этом ещё кстати некое снижение быстродействия, хотя не так критично) — всё тоже самое можно делать и на C++, но без затраты этого месяца или более.

VD>Какие на фиг монстры на С++? О чем вообще речь?

Вот неполный список библиотек валяющихся с одного из проектов:
Boost (ну эту в других языках требовать не будем — это по сути доработка и расширение C++)
wxWidgets (есть биндинги у Питона и ещё кучи языков, включая даже Хаскель; wxPython использовали на практике — удобно)
АхТк
Curl(есть в Питоне)+wxCurl
libavcode+libavformat (есть в Питоне)
Lua
OpenCV (есть в Питоне)
OpenSSL (есть в Питоне)
SFML (есть в Питоне)
sqlite(есть в Питоне)+wxsqlite
wxwebconnect (есть аналог в Питоне)

Что касается D, то к нему можно подключить (как C библиотеки) некую часть, но и только — никаких приличных биндингов нет. Добавим к этому что в стандартной системе локализации gettext есть C/C++/Python и ещё куча языков, но не D.

Вот я гляжу на это всё и вижу что перейти с C++ на Питон не особо проблематично (ну точнее нам то это не подходит, но по совершенно другим причинам). А вот что бы с C++ на D перейти...

Здравствуйте, kaa.python, Вы писали:

KP>Живой язык — это язык употребляющийся для коммерческой разработки. Rust еще не родился даже, и, возможно, и не родиться. Но вероятность рождения есть. В случае с D такой вероятности уже нет, хотя, лично я, долгое время на это очень надеялся.

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

Здравствуйте, kaa.python, Вы писали:

KP>Угу, на уровне использования в повседневных разговорах языка Высоких Эльфов

Ну на Хаскеле пишут же

Здравствуйте, kaa.python, Вы писали:

KP>Он не завоевал успеха не потому что плох, и не потому что мышление костное, а потому, что не надо находить в первой версии языка "критический недостаток", все бросать и начинать пилить уж точно правильнуе версию. Язык для коммерческой разработки отличается от языка для домашних проектов тем, что дает не только и не столько развитие и новые круты примочки, сколько стабильность и возможность собрать старый код новым компилятором (при этом не требуя переписать чуть меньше 50%).

Тут я согласен, но в случае D все-таки были и объективные причины начинать вторую версию. Брайт, как и создатели C#,
в самом начале допустил очень грубую ошибку, начал делать "нативную яву", а надо было "убийцу C++", а это абсолютно
разные мало совместимые языки.

Здравствуйте, kaa.python, Вы писали:

KP>Отчасти то, о чем ты пишешь, и было причиной того, что D не взлетел. В то же время, за Rust стоит Мозилла, и ей же язык нужен не просто прикола ради, а для собственного проекта. Из этого можно сделать вывод о том, что надежда на "взлетит" есть. Хотя, я с тобой согласен — она не велика.

Да надежда есть, но поддержка корпораций ничего ни гарантирует, например Dylan поддерживала Apple в период своего первого расцвета, а Smalltalk корпорации как раз и закопали.

Здравствуйте, kaa.python, Вы писали:

KP>Последнее вермя меня просто неописуемо прет от Rust, посути — это тот язык которого мне давно не хватало. Так вот, к чему я это. На данный момент я затеял перевод руководства пользователя, полагаю что его проще перевести пока оно еще не очень большое (около 24 страниц). Собственно вопрос в том, не хочет ли кто-то присоедениться к переводу руководства?
KP>Если хочется посмотреть на то, что из себя представляет Rust, то можно почитать заметки про него.
Почему бы вам не написать пару-тройку статей в наш РСДН о Расте?
Я бы с удовольствием почитал. Особенно про шаблоны. В чем они так радикально проще С++нутых?
Да и другие, я уверен, тоже.
И вам польза — публикация в известном журнале.
Можно при смене работы козырять...

Здравствуйте, LaptevVV, Вы писали:

LVV>Почему бы вам не написать пару-тройку статей в наш РСДН о Расте?
LVV>Я бы с удовольствием почитал. Особенно про шаблоны. В чем они так радикально проще С++нутых?
LVV>Да и другие, я уверен, тоже.

Идея со статьями отличная, я сам об этом думал. Но, на данный момент, однозначно рано: во-первых, язык сырой и часто меняется; во-вторых, я сам на данный момент пытаюсь понять, на сколько мне этот язык нравится и на сколько он меня устраивает. Все же составить впечатление сходу довольно трудно. Попутно работаю над биндингами к libevent и планирую из дальше в одной задумке использовать.
Но если все устроит, то после биндингов возьмусь за статьи

LVV>И вам польза — публикация в известном журнале.
LVV>Можно при смене работы козырять...

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

Здравствуйте, kaa.python, Вы писали:
LVV>>Почему бы вам не написать пару-тройку статей в наш РСДН о Расте?
LVV>>Я бы с удовольствием почитал. Особенно про шаблоны. В чем они так радикально проще С++нутых?
LVV>>Да и другие, я уверен, тоже.

KP>Идея со статьями отличная, я сам об этом думал. Но, на данный момент, однозначно рано: во-первых, язык сырой и часто меняется; во-вторых, я сам на данный момент пытаюсь понять, на сколько мне этот язык нравится и на сколько он меня устраивает. Все же составить впечатление сходу довольно трудно. Попутно работаю над биндингами к libevent и планирую из дальше в одной задумке использовать.
KP>Но если все устроит, то после биндингов возьмусь за статьи

Это не важно, что язык меняется. Тут важно ухватить идеи, заложенные в язук, и их изложить.
Вон Влад как Немерлю разложил по полочкам — класс!!!

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, kaa.python, Вы писали:

KP>>Угу, на уровне использования в повседневных разговорах языка Высоких Эльфов

FR>Ну на Хаскеле пишут же

Ещё бы
curl, hslua, OpenCV, OpenSSL, SFML, sqlite и многое другое.
Причём это только hackage, но когда я начинал изучать Haskell, весь список был максимум в 5-6 экранов.

Здравствуйте, alex_public, Вы писали:

_>И без шаблонов полно нужных библиотек.

А без шаблонов они к Ди подключается на раз. Так что не надо выдумывать. Это все отмазки.

VD>>Короче, это очередной поиск отмазок. Если у вас руки не из задницы, то за месяц вы спокойно создадите себе окружение.

_>Месяц (или несколько) работы только над этим? Возможно. Но у нас дела есть и другие.

Это из серии анекдота — "Что думать? Трясти надо!...". Этот месяц вы потеряете ровно один раз. И быстро его отиграете на первом же проекте. А на втором у вас будет внушительная фора.

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

Так и не придумают, потому что для консерватора все к чему он не привык — худшее.

_>Boost (ну эту в других языках требовать не будем — это по сути доработка и расширение C++)

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

_>wxWidgets (есть биндинги у Питона и ещё кучи языков, включая даже Хаскель; wxPython использовали на практике — удобно)

10 секунд в гугле и нашел:
http://wxd.sourceforge.net/

_>АхТк

Та же фигня http://www.algonet.se/~afb/d/dtk.html

_>Curl(есть в Питоне)+wxCurl

http://dlang.org/phobos/etc_c_curl.html

_>libavcode+libavformat (есть в Питоне)

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

_>Lua

Уж Луа точно имеет С-ишный интерфейс.

_>OpenCV (есть в Питоне)

Это С-шная библиотека.

_>OpenSSL (есть в Питоне)

Ты что, издеваешься? Это тоже С-шная библиотека.
http://stackoverflow.com/questions/5451130/using-openssl-library-in-d

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

_>Что касается D, то к нему можно подключить (как C библиотеки) некую часть, но и только — никаких приличных биндингов нет. Добавим к этому что в стандартной системе локализации gettext есть C/C++/Python и ещё куча языков, но не D.

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

_>Вот я гляжу на это всё и вижу что перейти с C++ на Питон не особо проблематично (ну точнее нам то это не подходит, но по совершенно другим причинам). А вот что бы с C++ на D перейти...

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

Здравствуйте, Cyberax, Вы писали:

C>И система типов гарантирует, что объекты не будут иметь ссылок на объекты из других потоков.

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

Здравствуйте, Cyberax, Вы писали:

C>Азул живёт — у них машины покупают высокоскоростные трейдеры, которые на латентности собаку съели.

А какая латентность получается? А то озвученные 1ms — это никуда не годится.

Здравствуйте, vdimas, Вы писали:

C>>Азул живёт — у них машины покупают высокоскоростные трейдеры, которые на латентности собаку съели.
V>А какая латентность получается? А то озвученные 1ms — это никуда не годится.
У них он полностью pauseless с помощью аппаратной реализации forwarding pointers.

Здравствуйте, vdimas, Вы писали:

C>>И система типов гарантирует, что объекты не будут иметь ссылок на объекты из других потоков.
V>Можно с этого места подробней? Я так понимаю, что ты уникальные указатели имел ввиду? А что насчет разделяемых? А как данные м/у потоками передавать, коль есть такая прикладная необходимость?
Всё просто — только иммутабельные объекты могут посылаться между задачами (с помощью очередей сообщений). Это означает, что они могут быть скопированы как по значению, так и по ссылке (на усмотрение реализации).

Мутабельные данные есть, но:
1) Мутабельность надо указывать явно.
2) Мутабельные данные ограничены одним потоком.

Ну и есть ещё unsafe-блоки, с помощью которых можно делать хаки.

Здравствуйте, VladD2, Вы писали:

VD>Это из серии анекдота — "Что думать? Трясти надо!...". Этот месяц вы потеряете ровно один раз. И быстро его отиграете на первом же проекте. А на втором у вас будет внушительная фора.

Не уверен что фора вообще будет. D даёт приятность кода, но не сокращение его по сравнению с C++. Если в команде уже умеют проф. писать на C++, то...

_>>Boost (ну эту в других языках требовать не будем — это по сути доработка и расширение C++)
VD>Это подпорки к кривому язяку, чтобы он хоть чуточку походил на нормальные.

Хыхы, и у каких же нормальных языков в стандартную библиотеку входит функциональность типа Boost.Spirit? )

VD>10 секунд в гугле и нашел:
VD>http://wxd.sourceforge.net/

Ты действительно думаешь что я этого не видел? ) Посмотри внимательно сам эту ссылку. Это действительно биндинг, находящийся в каком-то пре-альфа состояние (практические ничего не работает) и реализованый через какое-то wx.NET (

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

И ты предлагаешь использовать это в рабочем проекте? )))

_>>АхТк
VD>Та же фигня http://www.algonet.se/~afb/d/dtk.html

AxTk не имеет никакого отношения к Tcl/Tk вообще. )))

_>>OpenCV (есть в Питоне)
VD>Это С-шная библиотека.

Не совсем. У неё от рождения 3 интерфейса: C (неудобный естественно), C++, Python.

VD>Короче, лично мне все ясно. Ты даже не удосужился разобраться в вопросе (попробовать язык на практике), но уже вынес обвинительный приговор языку.

Хыхы, ну давай начнём с самого начала. Покажи мне GUI библиотеку, которую я могу использовать в реальном проекте ма D. Желательно кроссплатформенную, но как минимум работающую на windows и имеющую там красивый нативный вид.

Я могу даже подсказать полезную ссылку: http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries

И вот точно такое со всем языком творится все эти годы. И как ЭТО использовать в бизнес-проекте? А хотелось бы конечно...

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

А я гляжу на тебя и вижу теоретика. )

Здравствуйте, alex_public, Вы писали:

_>Не уверен что фора вообще будет. D даёт приятность кода, но не сокращение его по сравнению с C++. Если в команде уже умеют проф. писать на C++, то...

Вот это уже другой разговор. Тут, правда, можно поспорить, но по крайней мере это уже не выглядит совершенно высосанным из пальца.

D действительно не сильно ушел от С++ (особенно 11-го) по возможностям, но все же есть, как минимум, два фактора которые делают разработку на D более быстрой:
1. Скорость компиляции. D модульный язык с весьма высокой скоростью компиляции. Это делает разработку намного более интерактивной.
2. D имеет безопасное подмножество и позволяет переложить управление памяти на GC. Так что куски проекта которые не требуют диких оптимизаций можно писать существенно быстрее и проще.

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

_>

Ты действительно думаешь что я этого не видел? )

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

_>Посмотри внимательно сам эту ссылку. Это действительно биндинг, находящийся в каком-то пре-альфа состояние (практические ничего не работает)

Как это можно понять из ссылки? Судя по копирайтам 2005-го и 2010-го годов, скорее можно сказать, что это весьма зрелый продукт. В прочем, порывшись я таки нашел информацию об этом.

_> и реализованый через какое-то wx.NET (

),

Даже беглого чтения описания достаточно чтобы понять, что ты, не прав.
Он реализован не через wx.NET, а портирован с wx.NET. В основе лежит библиотека выставляющая C-интерфейс:

xD is not a D port of wxWidgets, so it uses the C++ libraries. It is composed of two parts: (2 static libraries)
* wxc is a C++ library which exposes the wxWidgets API as a collection of D-friendly functions (extern "C").
* wxd is a library written in D which parallels the wxWidgets (C++) classes, ported over from wx.NET (C#).

Очевидно, что wx.NET использует ту же С-шную библиотеку.

_>само находящееся в не лучшем состояние. Причём он уже устарел (так и не родившись), т.к. мы используем более новую версию библиотеки, чем у них там может подключаться.

Тут — да. Любая библиотека являющаяся оберткой для библиотеки на другом языке будет отставать от жизни. Вопрос только насколько критично.

_>И ты предлагаешь использовать это в рабочем проекте? )))

ОК, wxWidgets — это С++-ное решение. Но на нем же мир не кончается. Есть GTK. Судя по этой ссылке библиотека в релизном состоянии. Почему не воспользоваться ей? Вам ведь нужен GUI, а не конкретная либа?

_>>>АхТк
VD>>Та же фигня http://www.algonet.se/~afb/d/dtk.html

_>AxTk не имеет никакого отношения к Tcl/Tk вообще. )))

Ну, сори. Уж больно название они выбрали забавное. Как я понял — это опять какая-то надстройка над wxWidgets.

Складывается ощущение, что wxWidgets главный код в вашем проекте. У вас там своя то логика есть? Не ужели ее меньше чем возни с GUI-ом?

_>>>OpenCV (есть в Питоне)
VD>>Это С-шная библиотека.

_>Не совсем. У неё от рождения 3 интерфейса: C (неудобный естественно), C++, Python.

Совсем. То что к чему-то прикрутили обертку на С++ не значит, что сама библиотека стала С++-ной. Создай свою обертку на D и будет даже удобнее.

_>Хыхы, ну давай начнём с самого начала. Покажи мне GUI библиотеку, которую я могу использовать в реальном проекте ма D. Желательно кроссплатформенную, но как минимум работающую на windows и имеющую там красивый нативный вид.

_>Я могу даже подсказать полезную ссылку: http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries

_>И вот точно такое со всем языком творится все эти годы. И как ЭТО использовать в бизнес-проекте? А хотелось бы конечно...

А что вас не устраивает в GTK то?

Кстати, а для каких платформ вы код пишите?

_>А я гляжу на тебя и вижу теоретика. )

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

Посуди сам. Что стоит 3-4 конторам взяться за тот биндинг к wxWidgets? Или даже написать свой кроплатформный аналог?

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

Здравствуйте, VladD2, Вы писали:

VD>D действительно не сильно ушел от С++ (особенно 11-го) по возможностям, но все же есть, как минимум, два фактора которые делают разработку на D более быстрой:
VD>1. Скорость компиляции. D модульный язык с весьма высокой скоростью компиляции. Это делает разработку намного более интерактивной.
VD>2. D имеет безопасное подмножество и позволяет переложить управление памяти на GC. Так что куски проекта которые не требуют диких оптимизаций можно писать существенно быстрее и проще.

Мне вот кажется, что если бы C++11 не вышел, то D возможно и взлетел бы.

VD>Ну, и естественно в D есть множество мелких фич облегчающих жизнь программиста. Так что заявление о том, что D ничего не даст явно не соответствуют действительности. Другой вопрос, что есть и более мощные языки.

Как бы это сказать... Я сомневаюсь что D что-то даст в "бизнес масштабах". Но и приятность работы программеров тоже важна, при условии что за это не надо платить слишком много. Т.е. я бы сказал переходить на D (у нас как раз я определяю все подобные вещи), при условии наличия активной D инфраструктуры (т.е. библиотек, как существующих, так и в активной разрабоке по всем новым поводам).

_>>AxTk не имеет никакого отношения к Tcl/Tk вообще. )))
VD>Ну, сори. Уж больно название они выбрали забавное. Как я понял — это опять какая-то надстройка над wxWidgets.
VD>Складывается ощущение, что wxWidgets главный код в вашем проекте. У вас там своя то логика есть? Не ужели ее меньше чем возни с GUI-ом?

Ты не совсем понял. wxWidgets — это жирнющий монстр, в котором GUI скорее всего и половину не занимает. Т.е. это полноценный фреймворк, позволяющий писать реальные кроссплатформенные приложения. Кстати, в каких-то элементах его функциональность пересекается с Boost'ом (конфиги, файлы, сокеты и т.п.), но в большинстве своём дополняет.

И соответственно существует множество разных полезных библиотек, использующих разные элементы wxWidgets как базис. Даже без GUI.

Конкретно AxTk — это кроссплатформенное распознование/синтез речи (ну в смысле обёртка для sapi и т.п.), реализованное с использованием wxString и т.п.

Ну и потом кроме отдельных полезных библиотек есть ещё много wx объектных обёрток к C библиотекам. Т.е. wxCurl, wxsqlite и т.п.

В общем это просто большая удобная инфраструктура вокруг большой библиотеки, не входящая в неё саму. У QT тоже что-то похожее есть.

_>>Не совсем. У неё от рождения 3 интерфейса: C (неудобный естественно), C++, Python.
VD>Совсем. То что к чему-то прикрутили обертку на С++ не значит, что сама библиотека стала С++-ной. Создай свою обертку на D и будет даже удобнее.

Ну достаточно посмотреть что там внутри, что бы понять кто тут к кому обёртка. ) Там внутри сплошные классы и шаблоны. ) Хотя вообще это к теме дискуссии никакого отношения не имеет вообще — зачем об этом спорим? )))

VD>А что вас не устраивает в GTK то?

Оно страшное под windows.

VD>Кстати, а для каких платформ вы код пишите?

Windows — основные деньги. OS X — мелкая добавка. Linux версию держим для красоты (типа что бы было, т.к. нам это ничего не стоит). Под iOS собирается проект, но с точки зрения бизнеса пока не нужен. Думаем что делать с Андроидом (java — гадость), захватывающим мир планшетов.

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

А у этого твоего языка случаем проблем не больше чем у D? ) Кстати, я пока так и не нашёл время его посмотреть подробно, хотя планирую. Правда это в любом случае будет не для практической работы, т.к. .Net там.

VD>Посуди сам. Что стоит 3-4 конторам взяться за тот биндинг к wxWidgets? Или даже написать свой кроплатформный аналог?

Ммм, вот как раз в идеале было бы написать свой кроссплатформенный фреймворк (для начала просто GUI) на D. Это же нативный язык со всеми возможностями для этого. Причём с учётом возможностей D он был бы ещё намного красивее. Но как раз такой проект не то что 3-4 конторы не потянут (в приемлемое время), но похоже никто сейчас не возьмётся. Если посмотреть на тот же wxWidgets, то там просто тонны кода (т.к. он релизован нативно под каждую платформу, на ifdef грубо говоря), причём что бы его повторить, нужны спецы под разные платформы и языки (к примеру в OS X варианте там Objective-C++ используется

).

Что касается биндинга, то это и мы потянули бы сами. Если бы серьёзно решили потратить на это время. Но как бы не до этого...

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

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

Здравствуйте, alex_public, Вы писали:

_>Хыхы, ну давай начнём с самого начала. Покажи мне GUI библиотеку, которую я могу использовать в реальном проекте ма D. Желательно кроссплатформенную, но как минимум работающую на windows и имеющую там красивый нативный вид.

_>Я могу даже подсказать полезную ссылку: http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries

Сорри, что вклиниваюсь в беседу. А ты прорабатывал для себя основные библиотеки, указанные по этой ссылке? Меня интересует DIUP — это обёртка над IUP — библиотека для С и Lua, имхо, неплохая альтернатива для WxWidgets (я как-то давал тебе ссылку на этот проект). Но на той страничке ссылка DIUP мёртвая, а вручную что-то не находится. Не довелось искать этот биндинг?

Кстати, там есть ссылка на проект Harmonia, его делал местный c-smile (HTMLLayout), он где-то описывал все проблемы, с которыми он столкнулся в тогдашнем D, было полезно.

Здравствуйте, PSV100, Вы писали:

PSV>Сорри, что вклиниваюсь в беседу. А ты прорабатывал для себя основные библиотеки, указанные по этой ссылке?

Я смотрел там две отдельные вещи: 1. биндинги к известным мне C++ библиотекам, умеющим выглядеть нативно 2. родные D библиотеки (как нечто новое для себя).

По поводу пункта 1 там всё очень печально — ни одного законченного продукта.

По поводу пункта 2 обнаружился довольно симпатичный вариант в потенциале — DFL. Оно сделано уже нормально в стиле D, использует нативные контролы и даже имеется в наличие визуальный редактор. Но оно только под window и пока ещё очень бедное. Т.е. набор фунцкиональности там только самый самый базовый.

PSV> Меня интересует DIUP — это обёртка над IUP — библиотека для С и Lua, имхо, неплохая альтернатива для WxWidgets (я как-то давал тебе ссылку на этот проект). Но на той страничке ссылка DIUP мёртвая, а вручную что-то не находится. Не довелось искать этот биндинг?

IUP в общем то не плохой продукт, как я посмотрел. Но под OSX вроде как используется не нативный интерфейс. Само программирование в стиле C тоже не особо привычно. Ну и редакторов визуальных не видно, хотя это не так принципиально.

Кстати, странно что IUP нет там в списке нормально работающих с D — оно же в чистом C интерфейсе, а значит в теории может быть использовано из D напрямую...

PSV>Кстати, там есть ссылка на проект Harmonia, его делал местный c-smile (HTMLLayout), он где-то описывал все проблемы, с которыми он столкнулся в тогдашнем D, было полезно.

Ага. Ну сам HTMLayout нам не особо интересен, а вот про D я вроде что-то такое читал, когда его разбирал.

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	20.04.12 11:07
Оценка:	32 (6)

	От:	VoidEx
	Дата:	20.04.12 11:33
	Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	20.04.12 11:36
Оценка:

	От:	alex_public
	Дата:	20.04.12 16:13
	Оценка:	+1

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	20.04.12 22:15
Оценка:

	От:	PSV100
	Дата:	20.04.12 23:15
	Оценка:	13 (2) +2

От:	Курилка	http://kirya.narod.ru/
Дата:	21.04.12 10:43
Оценка:

От:	VladD2	www.nemerle.org
Дата:	21.04.12 14:21
Оценка:

От:	ArtemGorikov	жж
Дата:	23.04.12 01:13
Оценка:

От:	AlexCab	LinkedIn
Дата:	23.04.12 11:38
Оценка:	+1

	От:	Cyberax
	Дата:	22.04.12 00:07
	Оценка:	+1

	От:	Cyberax
	Дата:	22.04.12 19:10
	Оценка:

	От:	Cyberax
	Дата:	22.04.12 21:52
	Оценка:	+1

	От:	Cyberax
	Дата:	22.04.12 22:43
	Оценка: