| 1.1, Аноним (1), 09:34, 06/01/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –16 +/– | |
Нужность близка к нулю в эпоху го, раста, и свифта.
Плюс пилят его ноунеймы без поддержки корпораций. Не взлетело за 20 лет, можно не трепыхаться больше, проект пора сворачивать.
| | |
| |
| 2.2, leap42 (ok), 09:46, 06/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Ну раз Аноним сказал что пора... А если серьёзно, D имеет некоторую узнаваемость в профессиональных кругах, так что строчка "разрабатывал D" в резюме может помочь с работой.
| | |
| |
| 3.3, пох (?), 10:02, 06/01/2019 [^] [^^] [^^^] [ответить]
| +5 +/– | |
ассистента на кафедре забытых языков программирования в каком-нибудь третьеразрядном универе?
всем остальным поможет только умение быстро ляпать миллионнозависимый код на го. Желательно "на доске, не пользуясь компьютером". А после прохождения собеседования - и тем более можно "забыть все чему тебя учили", и спокойно копипастить стековерфлоу.
| | |
| 3.5, proninyaroslav (ok), 10:33, 06/01/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
 А есть вообще реальные продукты на D? Как правило это отличает академический язык от реально используемого.
| | |
| |
| |
| 5.13, твой лучший друг (?), 12:34, 06/01/2019 [^] [^^] [^^^] [ответить]
| +3 +/– | |
по ссылке начали за здравие, кончили за упокой:
на некоем сайте есть список из 26 компаний, которые наверное используют D
...
язык D не входит ни в основной (top-20), ни в общий (top-43) список, что говорит о невысокой востребованности у работодателей
кому верить-то
| | |
|
|
| 3.23, Я (??), 18:11, 06/01/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Из википедии: В рейтинге популярности, составленном по результатам агрегации данных о вакансиях разработчиков, язык D не входит ни в основной (top-20), ни в общий (top-43) список, что говорит о невысокой востребованности у работодателей.
| | |
|
| 2.32, Аноним (32), 00:17, 07/01/2019 [^] [^^] [^^^] [ответить]
| +10 +/– | |
> Плюс пилят его ноунеймы
Ну если для тебя Александреску "ноунейм" то с тобой и обсуждать нечего. Кто там должен был быть для тебя - цукерберг, брин и трамп с макроном?
| | |
| 2.45, annual slayer (?), 11:30, 07/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
имхо, как раз на их фоне годность ди и становится заметной
до их появления, впринципе, не особо стоял вопрос зачем переходить с с++ на d, а теперь, по сути, открылась новая ниша
ну а свифт пока я не встречал чтобы кто-то использовал за пределами эппл-мира
| | |
| |
| 3.48, Аноним (48), 14:37, 07/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
на medium есть статьи, правда немного, про использование swift в server-side
| | |
| |
| 4.51, annual slayer (?), 21:09, 07/01/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> на medium есть статьи, правда немного, про использование swift в server-side
я не говорил, что это невозможно, я говорил, что мне не известны факты реального использования в проектах
| | |
|
|
| 2.49, Ванёк (?), 15:51, 07/01/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
"Нужность близка к нулю" - это правда. "в эпоху го, раста, и свифта" - сейчас продолжается эпоха C/C++ и Ассемблера (как бы странно последнее не звучало) как самых ценных универсальных инструментов, на которых пишутся все самые важные базовые вещи - компиляторы, ОС, высокопроизводительные вычисления/оптимизация, в т.ч. библиотек для других языков программирования, ПО для управления любыми устройствами и др., что вместе с возрастом этих языков лучше всяких слов говорит о качестве, зрелости и незаменимости данных инструментов в ключевых областях.
| | |
| 2.59, glebiao (ok), 17:09, 08/01/2019 [^] [^^] [^^^] [ответить] | +1 +/– |  100 500-ый раз, уже надоело D --- зрелый , компилирующий в нативный код язык,... большой текст свёрнут, показать | | |
| |
| 3.65, Аноним (65), 12:07, 15/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Раст --- прекрасно, для драйверов, особо ответственного кода, просто замечательно.
Торвальдс его к ядру и близко не подпустит. И уж, тем более, пока не появится его фронтенд в GCC, он его вдвойне не подпустит.
| | |
|
|
| 1.22, Диносафр (?), 17:07, 06/01/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ди убила ровно одна вещь — сборщик мусора искаропки.
Одно неверное решение — и всё накрылось огромным британским унитазом. Сразу отвалились перспективные системщина, контроллеры и игори, потому как всё нутро, вся местная BCL завязана на сборщик. Можешь писать без него, но всё, вообще вот всё базовое и нужное придётся писать самому и с нуля, что сомнительно и тупо.
| | |
| |
| 2.24, Я (??), 18:14, 06/01/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
D ничего не убивало, он просто не взлетел, по причине того что за ним не стоит никого из великих, а времена когда что-то взлетало само по себе давно прошли.
| | |
| |
| 3.35, Аноним (32), 00:47, 07/01/2019 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> что за ним не стоит никого из великих
"... корпораций и денег", Вы хотели дописать?
| | |
|
| |
| 3.50, FSA (??), 19:27, 07/01/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Появилась идея "урны", "урны" - для хранения.
Упростим. Есть оперативная память. Мы создаём объект, который хранит данные. Что нам нужно? Правильно, выделить оперативную память. Пользуемся объектом. Больше он нам не нужен. Что делать? Перемещать огромные объёмы данных, чтобы переместить то, что расположено в памяти после объекта в участок памяти ниже замещая удаляемый объект? Или просто пометить память, как неиспользуемую? Ой... а это ж и есть мусор. Можно и без автоматического сборщика мусора. Пусть программист сам выделяет и освобождает память. Программист то более эффективно может использовать ресурсы памяти и процессора (думал я в 90-х, когда программировал на ассемблере Z80)... Имхо, достаточно того, чтобы программист понимал как работает сборщик мусора и не создавал объекты без необходимости (впрочем, это сейчас сложно сделать, особенно если используешь что-то вроде фреймворков, например, на PHP, когда тебе при необходимости использовать обезьяну в довесок падают все леса Африки со всеми существующими там видами растений и животных, часть из них просто занимают место на диске, а часть тупо входит в состав той самой обезьяны).
| | |
| |
| 4.56, Sw00p akaJerom (?), 16:50, 08/01/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Так начнем по порядку
>>Мы создаём объект, который хранит данные.
То есть у нас есть "урна" и есть "вещь", которую в нее положим.
>>Пользуемся объектом. Больше он нам не нужен.
Что значить он на не нужен? Будь у нас "великая урна" (бесконечная лента Тьюринга или оперативка) делили бы мы "вещь" на "нужную" и не "нужную"? Что собственно, задумывались бы мы об "удалении" объекта если бы имели бесконечную оперативку? Думаю нет, а отсюда вывод - деление есть следствие того факта, что нет "бесконечной ленты" и собственно ложной идеи о "великой урне".
>>Ой... а это ж и есть мусор.
Оценив, пространственную сложность алгоритма имели бы мы мусор? - нет, так как мы запросили бы ровно столько "урн", сколько требует сам алгоритм.
>>Пусть программист сам выделяет и освобождает память.
Значить этот программист проводит оценку пространственной сложности алгоритма, и собственно запросит ровно столько "урн" сколько достаточно, и собственно он будет лишен идеи "мусора".
>>Программист то более эффективно может использовать ресурсы памяти и процессора (думал я в 90-х, когда программировал на ассемблере Z80)... Имхо, достаточно того, чтобы программист понимал как работает сборщик мусора и не создавал объекты без необходимости
Вот первое предложение - об оценке пространственной сложности, а второе - "предрассудок", который не имеет место быть при оценке.
| | |
|
|
| 2.27, FSA (??), 20:22, 06/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Ди убила ровно одна вещь — сборщик мусора искаропки.
Если у вас есть идея как можно создавать и убивать объекты при объектно-ориентированном программировании и не оставлять мусора, реализуйте её. Весь мир скажет вам спасибо за то, что вы решили проблему мусора и необходимости его уборки.
| | |
| |
| 3.29, funny.falcon (?), 22:27, 06/01/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
C++ RAII?
Rust? (не знаю, что там у них)
Я сам сторонник GC везде, где можно. Я люблю GC, хоть самому приходится порою с ним бороться.
Но "везде, где можно" уже в себе заключает, что "кое-где нельзя". К сожалению, люди слабо понимают, где можно, и где нельзя, и потому боятся GC.
| | |
| |
| 4.30, Sw00p aka Jerom (?), 22:33, 06/01/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>>самому приходится порою с ним бороться.
напоминает про "борца с мельницами", а вам как кажется?
| | |
| |
| 5.36, funny.falcon (?), 01:10, 07/01/2019 [^] [^^] [^^^] [ответить]
| +2 +/– | |
нет, не кажется.
Да, на низком уровне приходится побороться. Но чем ближе к бизнеслогике, тем больше удовольтюствия от GC.
| | |
| |
| 6.37, Sw00p aka Jerom (?), 01:28, 07/01/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>>нет, не кажется.
ещё бы ))
>>Да, на низком уровне приходится побороться. Но чем ближе к бизнеслогике, тем больше удовольтюствия от GC.
сумбурность какая-то, "низкий уровень", "бизнес логика"
| | |
|
| 5.39, Ordu (ok), 01:58, 07/01/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 malloc/free тоже напоминает борьбу с мельницами. Открой Кнута на досуге и почитай. И "на подумать на досуге", если читать влом: геймдев очень не любит malloc/free (в любых их инкарнациях, хоть и new/delete) потому что они приводят к непредсказуемым задержкам и потерям кадров. Правда геймдев по тем же самым причинам не любит и сборку мусора.
| | |
| |
| 6.40, Sw00p aka Jerom (?), 03:13, 07/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>>malloc/free тоже напоминает борьбу с мельницами.
выше я описал, что является причиной "борьбы с мельницами" (пункт 3)
>>Открой Кнута на досуге и почитай.
там нет ничего нового, и повторюсь - спасибо Тьюрингу за "бесконечную ленту", Мур вас попутал со своим
недоказанным законом.
| | |
| |
| 7.41, Ordu (ok), 04:57, 07/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
>>>Открой Кнута на досуге и почитай.
> там нет ничего нового
Ну так почитай хотя бы старое.
| | |
|
|
|
| 4.34, Аноним (32), 00:43, 07/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Rust? (не знаю, что там у них)
раньше в расте были проблемы с циклическими ссылками. Из-за того, что "уборка" объектов опиралась на механизм подсчета ссылок (при уменьшении ссылок до нуля объект удалялся) объекты, ссылающиеся друг на друга (или опосредованно через цепочку промежуточных объектов) навсегда оставались висеть в памяти. Тогда просто отмазывались тем, что в правильно спроектированной программе быть циклических ссылок не должно, перестраивайте архитектуру. Как там сейчас дела - хз.
| | |
|
|
| 2.28, fleonis (ok), 20:38, 06/01/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 ага,сам хотел его начать изучать, остановил именно сборщик мусора :(
| | |
| |
| 3.54, glebiao (ok), 16:25, 08/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>остановил именно сборщик мусора :(
опасность и "вредное вличние" сильно преувеличены.
| | |
|
| 2.33, maximnik0 (?), 00:23, 07/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Ди убила ровно одна вещь — сборщик мусора искаропки.
Так вроде и в C++ с какого то времени можно использовать компиляцию со встраиванием сборщика мусора, и появились какие типы явно слизанные с явы .Читал в конференции у С++ к счастью/сожелению пока это нельзя использовать ,местами дикие провалы по производительности а местами баги вылезающие на ровном месте.
| | |
| 2.55, glebiao (ok), 16:38, 08/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Ди убила ровно одна вещь — сборщик мусора искаропки.
Насчёт "убила", вероятно, несколько преувеличенное заключение. Вполне жив, активно пилится, новые пакеты появляются ежедневно.
По поводу целевой области: разработка глубоко системного ПО, встраиваемого ПО, кажется, вступает в противоречие с идеей быстрой разработки, с автоматизированным контролем памяти.
D делает упор на высокую скорость разработки при *достаточно* высокой надёжности и производительности, вот и всё.
Это не значит, что нельзя делать системное ПО (для этого всё есть) или встраиваемое (@nogc библиотеки потихоньку пилятся). Просто акценты надо правильно расставлять.
Наберёт ли заметную популярность, время покажет. Пробиться через хайп финансово поддержанных и раскрученных альтернатив, сложно. Если до народа дойдёт, что D на сегодня, единственный более -- менее зрелый "компилируемый Питон", то шансы есть.
PS: То, что делает Ярошенко, это же просто чудо и достойно самого широкого пиара.
| | |
|
| 1.38, Аноним (48), 01:43, 07/01/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
уж лучше swift и rust выучить, чем этот D.
на этот D всё также 0 вакансий?
| | |
| |
| 2.44, Аноним (44), 11:28, 07/01/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Так ведь и с вакансиями на Rust как-то не очень. На HH около 20 вакансий во всём ДС. Что на два порядка меньше, чем C/C++. Тем смешнее хайп вокруг него.
| | |
| |
| 3.47, Аноним (48), 14:20, 07/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
Rust 1.0 вышел в 2015 году, а на него уже есть вакансии, это же вроде ок?
| | |
|
| 2.52, . (?), 22:15, 07/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
что-то мне подсказывает, что там где его и используют, в описании вакансии не написаны конкретные языки, потому что как раз это знание приобретается нужным человеком быстро.
Как вариант - вакансия называется "системный архитектор", и вопрос выбора языка обсуждается с успешным кандидатом.
| | |
| 2.53, glebiao (ok), 16:23, 08/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>уж лучше swift и rust выучить, чем этот D.
лучше для чего?
скорость разработки rust << C++ < swift < D.
Это тезис, "если чо".
| | |
| |
| 3.57, Карпович (?), 16:58, 08/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
не дурите людей расставляйте приоритеты правильно
C++ < D < Swift < Rust < Ruby
| | |
| |
| 4.60, glebiao (ok), 17:23, 08/01/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
>не дурите людей расставляйте приоритеты правильно
>C++ < D < Swift < Rust < Ruby
Да ну? На ++ *пишем* быстрее, чем на D, а на D медленее, чем на Свифт? О как. Ну, код constexpr счётчика на ++ в студию (*до* x20), пожалуйста (https://stackoverflow.com/questions/6166337/does-c-support-compile-time-counte Вам в помощь).
И да, у Вас скорость разработки на Расте оказывается медленее, чем на Руби. Оччень нетрадиционный взгляд, не говоря уже о сравнении твёрдого со сладким.
| | |
| |
| 5.61, glebiao (ok), 17:28, 08/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>И да, у Вас скорость разработки на Расте оказывается медленее, чем на Руби.
то бишь быстрее. очепятка...
| | |
|
|
|
|
|
