Прочитайте обсуждение на реддите и две статьи здесь, на Хабре. Вы сможете увидеть, что рамки тестового задания были очень узкими — и основную роль играла оптимизация алгоритмов под конкретный случай, а не язык.
На уровне платформы существуют только веи. И никаких других единиц попросту не существует.
Но на входе-выходе существуют эфирные монеты и много чего ещё. У НАСА был спускаемый аппарат, который навернулся из-за нестыковок между метрической и имперской системой. Вы постоянно "тычете" оппонента в "плавучку", которой в его комментариях нет. Он как раз говорит о такой штуке, как единицы измерения, закодированные в виде типов. Это сильно уменьшает вероятность ошибки, т.к. при попытке комбинирования в одной операции вы либо получите ошибку компиляции, либо корректное преобразование, закодированное один раз в логике типа.
Маленькая проблемка, о которой писали уже несколько раз выше. Альтернативные теории противоречат целой пачке фактов. Впрочем, ТМ тоже далеко неидеально ведёт себя с теми же галактиками. Так что вы и правы, и не правы. Как писали выше, ТМ — по сути эвфемизм для «неведомая летающая фигня». И, кстати, в современной физике целая пачка нерешённых проблем, начиная от несовместимости ОТО и КМ.
Скорее всего заминусуют, но всё равно спрошу.
Когда планируете сделать полноценную и единообразную поддержку MSBuild в студии? Сейчас — зоопарк наборов фич для разных типов проектов.
А главное — когда наконец умрут в корчах или починятся "фильтры" в С++ проектах?
Чтобы не быть голословным, попробую перечислить, о чём я.
Для С++ проектов имеем нормальную поддержку макро-переменных в свойствах проекта и property sheets. Однако, нельзя вменяемо в этих самых property sheets задать шаблоны для отладочной и релизной сборки так, чтобы не плодить и не инклюдить их по нескольку штук. Также, если руками в property sheet прописать свойство, а потом поменять в UI — заданное вручную свойство исчезнет.
В C# проектах ничего похожего вообще нет, извольте либо в UI все пути прописывать ручками, либо опять же руками писать все свойства в проектном файле, с риском что UI в студии всё это потрёт.
По поводу фильтров — основная проблема в том, что "файловые" операции на фильтрах работают не так, как ожидалось. А режим All Files просто выводит в список вообще все файлы, которые лежат в папке рядом с проектом. Было бы неплохо, чтобы во-первых этот режим работал как надо и показывал только файлы, включенные в проект, а во-вторых мог быть включен глобально, как режим отображения в студии. А не локально для проекта.
Мне кажется, или со стримами Java конкретно упёрлась лбом в type erasure и отсутствие деструкторов? "Станцуйте этот танец племён Куру-Кусу, чтобы у вас не утекли ресурсы".
Как по мне, представленная статья — таки нытьё. Основная проблема современного десктопа — ОС представляет собой не набор компонентов, которые можно изолировать, раздавать им права и управлять связями и зависимостями, а огромный, простите, сельский сортир, в любое место которого может нагадить любой процесс. Утрирую конечно. Я, кстати, не понимаю, почему сэндбоксинг всех приложений, включая создание для каждого CoW виртуального окружения, не вкручен прямо в ОС. Это позволило бы, к примеру, запускать древнючий легаси без толстенной абстракции виртуальной машины — просто подсунув в процесс слой легаси-библиотек.
Вы что! Там же свинок можно на шашлык пускать! На бедных эндерменчиков надо охотиться ради лута! Грифить в конце концов! А визера — так вообще! Сначала сотворил — потом убиваешь! Ужос-ужос-ужос какая жестокая игра!
/sarcasm off
Не-компилируемые хотят рантайм. Например, была задачка — собрать тонкий Node.JS сервис из толстой нативной либы и засунуть в докер. Подружить этот зоопарк, чтобы собирался одной кнопкой — нетривиально, хоть и решаемо. А потом корректно проставить всё в контейнер и вычистить мусор. Куда проще скрутить и запаковать монолитный бинарь.
Это крайне печально.
К тому же, я подозреваю, Phobos завязан на исключения. А значит, перевести его на variant-совместимый подход — переписать хорошим куском. Либо руками обёртки над libc. Пока напрашивается вывод — в betterC фактически нет стандартной библиотеки.
Я как раз к языкам со слабой типизацией стараюсь пореже подходить.
По поводу же конца моего комментария — суть в том, что функция не меняет поведения в зависимости от полного входного типа. Поэтому полиморфизмом там как бы и не пахнет.
Не ради саморекламы (там 300 строчек кода, плюнуть и растереть) https://github.com/target-san/httpdl/tree/step-by-step
Простейший загрузчик файлов по HTTP, конкретно в той ветке что я указал он строится пошагово, в т.ч. с переходом на "идиоматичную" обработку ошибок. Пример не ахти какой, без асинхронки — но маленький, а значит понять должно быть легко.
Меня смущает, что сам по себе язык очень сильно завязан на сборку мусора. Многие вещи могли бы без проблем работать, сидя на стеке или кастомных аренах. Те же классы с наследованием, интерфейсы и т.п. Однако — увы.
Кстати, вопрос к знающим Ди. А как там теперь с обработкой ошибок, после того как выкинули на мороз исключения? Потому что C-style коды ошибок и libc в голом виде низводят бОльшую часть преимуществ в ноль.
Назвать синтаксис Rust ML-подобным это довольно оригинально. Если сравнивать с хаскеллем и С++, он больше всего похож именно на плюсы — двойные двоеточия, фигурные скобочки, угловые скобки шаблонов и т.п. Наличие же let и указания типа после имени отнюдь не делает язык ML-подобным, как по мне.
Если не секрет, что именно непривычно? Я, например, в основном тоже на плюсах пишу — и Rust мне вполне даже зашёл. Очень многие вещи выглядят как раз знакомо.
А кстати какие претензии к Rust по синтаксису?
Прочитайте обсуждение на реддите и две статьи здесь, на Хабре. Вы сможете увидеть, что рамки тестового задания были очень узкими — и основную роль играла оптимизация алгоритмов под конкретный случай, а не язык.
Но на входе-выходе существуют эфирные монеты и много чего ещё. У НАСА был спускаемый аппарат, который навернулся из-за нестыковок между метрической и имперской системой. Вы постоянно "тычете" оппонента в "плавучку", которой в его комментариях нет. Он как раз говорит о такой штуке, как единицы измерения, закодированные в виде типов. Это сильно уменьшает вероятность ошибки, т.к. при попытке комбинирования в одной операции вы либо получите ошибку компиляции, либо корректное преобразование, закодированное один раз в логике типа.
Скорее всего заминусуют, но всё равно спрошу.
Когда планируете сделать полноценную и единообразную поддержку MSBuild в студии? Сейчас — зоопарк наборов фич для разных типов проектов.
А главное — когда наконец умрут в корчах или починятся "фильтры" в С++ проектах?
Чтобы не быть голословным, попробую перечислить, о чём я.
Мне кажется, или со стримами Java конкретно упёрлась лбом в type erasure и отсутствие деструкторов? "Станцуйте этот танец племён Куру-Кусу, чтобы у вас не утекли ресурсы".
С драйверами в текущей модели ничего не сделать, это факт. Но хоть пользовательские вещи можно "причесать".
Как по мне, представленная статья — таки нытьё. Основная проблема современного десктопа — ОС представляет собой не набор компонентов, которые можно изолировать, раздавать им права и управлять связями и зависимостями, а огромный, простите, сельский сортир, в любое место которого может нагадить любой процесс. Утрирую конечно. Я, кстати, не понимаю, почему сэндбоксинг всех приложений, включая создание для каждого CoW виртуального окружения, не вкручен прямо в ОС. Это позволило бы, к примеру, запускать древнючий легаси без толстенной абстракции виртуальной машины — просто подсунув в процесс слой легаси-библиотек.
/sarcasm off
Не отменял. Но это то же, что было в Java до 1.5.
Не-компилируемые хотят рантайм. Например, была задачка — собрать тонкий Node.JS сервис из толстой нативной либы и засунуть в докер. Подружить этот зоопарк, чтобы собирался одной кнопкой — нетривиально, хоть и решаемо. А потом корректно проставить всё в контейнер и вычистить мусор. Куда проще скрутить и запаковать монолитный бинарь.
Это крайне печально.
К тому же, я подозреваю, Phobos завязан на исключения. А значит, перевести его на variant-совместимый подход — переписать хорошим куском. Либо руками обёртки над libc. Пока напрашивается вывод — в betterC фактически нет стандартной библиотеки.
Я как раз к языкам со слабой типизацией стараюсь пореже подходить.
По поводу же конца моего комментария — суть в том, что функция не меняет поведения в зависимости от полного входного типа. Поэтому полиморфизмом там как бы и не пахнет.
Тут более каверзный вопрос — а как у stdlib с error handling через него?
И есть ли сахар "unpack-or-return"?
Не ради саморекламы (там 300 строчек кода, плюнуть и растереть)
https://github.com/target-san/httpdl/tree/step-by-step
Простейший загрузчик файлов по HTTP, конкретно в той ветке что я указал он строится пошагово, в т.ч. с переходом на "идиоматичную" обработку ошибок. Пример не ахти какой, без асинхронки — но маленький, а значит понять должно быть легко.
Эмм… оперирование разнородными типами через некий единый интерфейс?
То, что вы показали — по сути использование объекта-потомка вместо объекта-предка. Только в Ди реализованное через алиасинг. Вот если бы у вас
это был бы полиморфизм
Меня смущает, что сам по себе язык очень сильно завязан на сборку мусора. Многие вещи могли бы без проблем работать, сидя на стеке или кастомных аренах. Те же классы с наследованием, интерфейсы и т.п. Однако — увы.
Кстати, вопрос к знающим Ди. А как там теперь с обработкой ошибок, после того как выкинули на мороз исключения? Потому что C-style коды ошибок и libc в голом виде низводят бОльшую часть преимуществ в ноль.
Назвать синтаксис Rust ML-подобным это довольно оригинально. Если сравнивать с хаскеллем и С++, он больше всего похож именно на плюсы — двойные двоеточия, фигурные скобочки, угловые скобки шаблонов и т.п. Наличие же let и указания типа после имени отнюдь не делает язык ML-подобным, как по мне.
Если не секрет, что именно непривычно? Я, например, в основном тоже на плюсах пишу — и Rust мне вполне даже зашёл. Очень многие вещи выглядят как раз знакомо.