Pull to refresh

Comments 34

Четвертая статья за неделю по языку D!
А кто-то писал, что сообщество разработчиков на D не продвигает свой язык.
Вот вот, тоже подумал о том, что читая Хабр, можно вполне себе сносно знать D. С остальными «Убийцами C++» не так (по крайней мере у меня).
Считаете, что Go относится к категории «Убийци С++»?
Настолько же, насколько D туда относится. Или даже больше, если учесть социальные аспекты и качество интеграции с C.
Давайте я приведу свои доводы в пользу отношения к категории «Убийцы С++» а вы свои и сравним ну так для интереса:

1) Легок для переучивания владеющими языком С/С++
2) Имеет нативный С/С++ интерфейс вызова функций, а значит доступны все наработки С/С++
3) Потенциальная область применения перекрывает область применения С/С++, начиная скажем от драверов ОС
4) Реально компилируемый, исполняемый файл не нуждается в окружении.
Ну пока что пришло в голову, наверно будет и что добавить.
Извиняюсь, что вклиниваюсь в дискуссию, но. Мне кажется, последние десять лет очень наглядно показали, что категории «убийца C++» просто не существует. Его даже ломом хрен убьешь. Да и (как по мне) большего успеха добились те языки, которые не стремились его убить.
Его даже ломом хрен убьешь.

Полностью согласен, оказался очень живуч. :)
Но категория все же есть, хотя правильнее её называть наверно «Потенциальные убийцы С/С++»
1) и 4) это Go, 2) тоже присутствует, не знаю, как это сделано в D, может там удобнее.
Насчёт 3) это губу придётся завернуть обратно, потому что никакого смысла в этом нет по логике вещей (я про драйвера). Вот насчёт игр не знаю, в Go внутренние изменения GC происходят сейчас и судить о будущем Go в этом направлении не могу.

Что касается самого процесса убивания, то бекенд многие переписывают с плюсов на Go и получают сплошной профит.
1) Субъективно, я например так и не прочувствовал синтаксиса Go
4) Допилили таки? Отлично!
2) Очень удобно, да собственно кроме указания extern© особо и нечего не надо.
3) Думаю чем больше область применения, теб больше должна быть популярность при всех равных условиях.
Вот в 3, скорее всего, и кроется проблема. C++ смог каким-то невообразимым образом накрыть ОЧЕНЬ широкую область применения. Я бы сказал, неоправданно широкую. Видимо, из-за отсутствия альтернатив на тот момент. И теперь, «потенциальные убийцы» стремятся накрыть именно такую же широкую область. И это не очень хорошо сказывается на популярности.

Возьмите тот же go. На нем, вроде как, хоть черта лысого можно написать. Но его не пишут, а пишут другой софт — из одной вполне конкретной ниши.
Или erlang. На нем черта лысого уже не напишешь, но популярность (в определенных кругах) он сохраняет достаточно стабильно. Он просто делает то, для чего предназначен.
А у D как-то и предназначения толком нет.

PS: Надеюсь, никого не смутит, что я все эти языки поставил в один ряд, понятно, что общего у них ничего нет между собой, а тот же erlang даже и не замахивался на C++ никогда.
А какую нишу занимает Go, предыдущий оратор тоже относил его к языкам «Убийцам С+++»? И я в общем-то с ним в основном согласен, что это язык широкого спектра.
Я под «нишей» языка понимаю не то, что на нем можно в теории писать, а то, что на нем реально пишут.

В случае go как я себе представляю, это сервера с претензией на высокую нагрузку и неблокирующие операции. В эту категорию я бы отнес следующее.

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

По моему это определяет архитектура приложения, а не язык. Другое дело что на том или ином языке это можно удобнее реализовать. Но я вроде ничего эксклюзивного на этот счет кроме горутин в Go не припомню. Если есть какие-то ссылки по теме создания таких приложений в Go, поделитесь пожалуйста, с интересом бы прочитал.
Язык очень сильно определяет архитектуру приложения. Ну или должен задавать, как минимум. И горутин для этого вполне достаточно =)
Насчет ссылок — предоставить что-либо внятное не смогу, поскольку сам я не гофер. Сам бы посмотрел что-то на эту тему.
Чуть поясню свою мысль насчет связи языка и архитектуры приложения. Идеальной демонстрацией моей точки зрения может служить Erlang/OTP. Эрланга, как таковой не имеет смысла без OTP. А OTP в свою очередь задает очень четкий формат для приложений. Это, я считаю, замечательно, и каждый язык должен стремиться к этому.

Другой пример (уже на грани холивара) — ruby, который большинством разработчиков не отделяется от рельс, и которому рельсы точно так же задают свой собственный формат.
Не знаю, не знаю, те же аналоги гороутин сейчас есть во всех языках притендующих на универсальность, в D есть, в той же Scala, C# и т. д. Доступ к epoll и переключение сокетов в не блокируемый режим, тоже не проблема.

Касаемо Erlang, там да есть серьезная заточенность на такого типа задачи, но он изначально под это и делался (программирование коммутационных систем).

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

>> Но я вроде ничего эксклюзивного на этот счет кроме горутин в Go не припомню.

Поэтому я и говорю, что очень важно то, что реально пишут на языке.
Я, например, около 20% рабочего времени занимаюсь тем, что шарюсь по опенсорсным проектам, изучая как там решаются задачи, похожие на мою. И когда мне нужно будет выбрать тот или иной язык, я буду отталкиваться именно от количества уже написанных проектов, к которым можно будет обращаться как к справочнику по известным проблемам best practices.

Вокруг go на данный момент уже сложилась вполне конкретная ситуация (не важно, обосновано это языком, или нет). И лично я выберу go именно в том случае, если моя задача будет похожа на те, которые уже решены на этом языке.
Вам не кажется скучным решать уже решённые задачи? :-)
Ну это смотря с какой стороны посмотреть ) Нерешенных задач — миллион. Паттернов, из которых можно собрать решение — не так уж много. Мне интереснее не выдумывать какие-то велосипеды (и потом гадать, а не треснет ли там чо-нибудь потом в продакшоне), а изучать уже готовые, отработанные и практически обоснованные паттерны, и уже из них компоновать решение своей задачи. Учитывая специфику проекта, в котором я участвую, простора для мысли хватает =)
Ну и это. Я (как и все мы) на работу же хожу не только развлекаться, но в первую очередь, собственно, зарабатывать деньги и решать конкретные задачи проекта. Чаще всего, проекту почему-то не важно, было мне весело, или нет =)
В связи с выросшим количеством постов про Dlang рискну и спрошу. А вообще, в природе есть ПО, написаное на этом языке? Может кто-нибудь мне показать хоть одну софтину, которой пользуется ненулевое количество человек?

PS: Если что, это не наезд на язык, это просто любопытство.
За неимением на данный момент качественной реализации GUI пока основная масса приложений на D пишутся под CLI. Причем если я правильно понимаю, то это либо web (на основе vibe.d) либо что-то связанное с разработкой на других языках (внутренние штуки для сборки, валидации, автоматизации и т.д. Есть github.com/facebook/flint и другие либки).

Для UI есть два проекта за которыми я слежу: dlangui и DQuick. Первый выглядит пока не слишком серьезным, но он активно пилится и шансов релизнуться и продолжить развитие у него чуть больше как по мне.
Ну, GUI лично меня не очень и интересовал, на самом деле. Чуть разовью свой вопрос примерами.

На erlang написаны riak, couchdb, rabbitmq, ejabberd.
На golang — docker, nsq, influxdb.
На scala — всякие марафоны, спарки и прочий хадуп.

А вот насчет веба — очень удивлен, даже не подумал бы, что Dlang там себе откопал норку ))
Как минимум пакетный менеджер языка dub, хотя этим врятли можно удивить. При увеличении популярности будут и программы.
Я думаю, что справедливо утверждение «для любого языка $SOME_LANG существует пакетный менеджер написанный на $SOME_LANG».
В 2010 сидел в летнем домике и читал доки по D, думал, что лет через пять займёт свою нишу. Ан нет, где был там и остался, лично меня он сразу отпугнул тем, что поддерживал хорошо только Windows, учить плохокроссплатформенный язык заведомо нет смысла.
В 2010 это был не тот D о котором мы говорим сейчас.
Хоть и язык разрабатывался давно, там была история с версиями. Первая и вторая по сути разные языки с серьезными отличиями в синтаксисе и разными стандартными библиотеками. Это конечно сказалось пагубным образом на его популярности. Фактически сейчас это новый язык, ставший стабильным не так давно. Отсюда и отсутствие каких-то значимых разработок на нем.
Но библиотеки пишут довольно бурно, фэйсбук вроде как его поддерживает и даже что-то на нем пишет. Так что есть надежда на развитие.
Очень хочется верить, что так и будет, потому что язык выглядит вполне себе симпатичным.
Есть очень прикольный скроллшутер Parsec47.
А есть где посмотреть его коды?
UFO just landed and posted this here
github.com/CyberShadow/RABCDAsm
Очень хороший, можно сказать уникальный тул для работы с байткодом AVM (виртуальная машина Adobe Flash). Действительно полезный тул, которым пользуются.
Sign up to leave a comment.

Articles

Change theme settings