Мне трудно дать какие-то комментарии, так как уже много лет не использовал язык, но лет 8 назад картина была бы совершенно другой, что еще раз показывает насколько тема непроста.
P.S. В C# разве нету встроенного класса для бенчмарка?
Понятно, что нельзя, я вот нарыл такой док, в свободное время прочитаю, потому что тема с дженериками постоянно всплывает, и опять же, верить на слово никому нельзя.
Хорошо, а как тогда запретить использовать исключения во всех остальных случаях? Собственно, насколько я знаю, причины отсутствия исключений в Go, это сложность реализации и желание ограничить область использования исключительно ошибками.
Действительно, исключения в .net ресурсоемки — но это не значит, что невозможно сделать нересурсоемкую реализацию исключений.
Полагаю при должной настойчивости и запасе времени все возможно, на практике же реализация исключений в ЯП одна из фундаментальных проблем. По вашим же ответам почему-то создается ощущение, что это если не пустячное дело, то говорить тут особо не о чем.
Более того, вот вы пишите, что до сих пор это считается порочной практикой в C#, а на деле это происходит достаточно часто.
Насчет монад, уже вроде решили, что сделать на Go так нельзя. Мне вот так сходу трудно здесь сделать какие-то выводы, почему так сложилось исторически, надо дальше копать.
Под состоянием я имел ввиду логику исполнения (control flow). С C# я работал достаточно давно, уж лет 8 назад, но тогда считалось, нерациональным использовать исключения для управления логикой из-за огромных накладных ресурсов и просадки производительности. Подозреваю, что сейчас это не так актуально, так как часто это встречаю в C# коде. В Java сама реализация исключений переписывалась, на моей памяти, как минимум два раза.
Собственно говоря, мой вопрос о чем-то посредине остался без ответа :( Тут ниже уже написали по макрос для Rust, интересная тема, но тут опять же, надо были изначально закладывать такую возможность.
Насколько я знаю концепция исключений для управления состоянием, в общем случае, считается антипаттерном. К этому, в частности, привело то, что во многих ЯП, отношение к исключениям, сама логика их работы и реализация менялась со временем. И как я понимаю, изначально маленькая команда разработки Go сознательно отказалась от этой концепции учитывая предыдущий опыт.
Реализация большинства монад хоть и проще стека исключений, все равно требует достаточного времени на тестирование и последующий «евангелизм» среди разработчиков.
Мне вот интересно, что осталось за бортом? Более практичное и функциональное, чем IF и менее сложное в реализации и отладке, нежели монады и исключения.
P.S. Последние несколько месяцев по работе имею доступ к одному большому проекту на C++, достаточно узкоспециализированному, но очень популярному в своей нише. Продукт очень недешевый, и позиционируется как надежный, но вот исключениями там совсем беда, и чем старее куски кода, тем все хуже. :(
Причем тут это? Как что располагать в памяти решает производитель рантайма исходя из огромного количества факторов. Мы тут говорим о дизайне языка, стандарт которого вообще не описывает реализацию рантайма.
Сделать отдельные ключи это не так просто, особенно если учесть что их нужно подвязывать на какую-то конкретную реализацию рантайма, например, node (у которого и своих ключей совместимости полно). И вообще не ясно, как все это будет влиять на реальную производительность.
Мне кажется вы немного теряете контекст, этот пример висит там уже без малого 5 лет. В то время, реально поддерживаемые браузерами возможности javascript немного отличаются от теперешних. Насколько я понимаю CoffeeScript до сих пор работает хорошо с IE8, и все это оставлено в угоду совместимости.
О файлики эти пропустил, да. В любом случае, в ассемблерных файлах нету упоминания Intel SHA Extensions (выше я почему-то посчитал, что поддержка SHA быть в AES Instruction Set, но она реализована как часть SSE), а значит все равно некоректно сравнивать эти реализации только по общему времени исполнения. Надо смотреть на реальное время выполнения каждой функции/метода.
В случае с Ruby используется OpenSSL (если библиотека установлена), а это значит, что при подсчете SHA1 и MD5 используются нативные инструкции процессора (если он поддерживает AES instruction set и версия OpenSSL > 1.0.1) и особой разницы нету. В данном случае, большая часть времени расходуется на аллокацию объектов в MRI.
С другой стороны, реализация SHA1 в Go написана на самом Go (даже без Go asm). Так что трудно сказать без профилирования насколько Go реально быстрее в этом случае.
Это мы о Руби, там нету. Зато в Groovy есть, и его перенесли в Swift как вариант, но суть в том, что полученный в результате nil ничего не сообщает о природе ошибки (или не ошибки :).
Да, как бы не проблема, но сам nil, может означать тонну вещей: у пользователя нету подписок, или подписки не подгрузились, или может пользователь вообще заблокирован и т.д. Сама суть nil'а логически зачастую может быть совершенно неясна. Вот выше пишут, что если какая-то ошибка, то в ObjC принятно возвращать NSError, но программисты забивают на это и возвращают nil. Так что сама концепция nil'а очень спорна.
Например, user.subscription.plan.price, а у User'а нету вообще подписки, тогда user.subscription вернет nil, а nil.plan вызовет исключение NoMethodError, так как plan теперь не как метод объекта subscription, а как меторд nil'а. В rails есть хак, метод try, тогда это переписывается как: user.try(:subscription).try(:plan).try(:price). Тогда если на каком-то этапе цепи вызовов будет nil, все выражение вернет nil.
Либо используется NullObject паттерн, или, в случае с rails (когда можно), delegate.
Они решили, переложить эти проблемы на плечи кодеров. Тоже с «опциональными» переменными, теперь надо будет следить чтобы правильно и в нужном месте ее «распаковать». Зато решили рубишную проблему с nil'ами, добавили optional chaining, но опять же, проблема решена не в корне (nil не выбросили), а просто добавили удобный воркэраунд о котором надо всегда помнить.
P.S. В C# разве нету встроенного класса для бенчмарка?
Полагаю при должной настойчивости и запасе времени все возможно, на практике же реализация исключений в ЯП одна из фундаментальных проблем. По вашим же ответам почему-то создается ощущение, что это если не пустячное дело, то говорить тут особо не о чем.
Более того, вот вы пишите, что до сих пор это считается порочной практикой в C#, а на деле это происходит достаточно часто.
Насчет монад, уже вроде решили, что сделать на Go так нельзя. Мне вот так сходу трудно здесь сделать какие-то выводы, почему так сложилось исторически, надо дальше копать.
Собственно говоря, мой вопрос о чем-то посредине остался без ответа :( Тут ниже уже написали по макрос для Rust, интересная тема, но тут опять же, надо были изначально закладывать такую возможность.
Реализация большинства монад хоть и проще стека исключений, все равно требует достаточного времени на тестирование и последующий «евангелизм» среди разработчиков.
Мне вот интересно, что осталось за бортом? Более практичное и функциональное, чем IF и менее сложное в реализации и отладке, нежели монады и исключения.
P.S. Последние несколько месяцев по работе имею доступ к одному большому проекту на C++, достаточно узкоспециализированному, но очень популярному в своей нише. Продукт очень недешевый, и позиционируется как надежный, но вот исключениями там совсем беда, и чем старее куски кода, тем все хуже. :(
С другой стороны, реализация SHA1 в Go написана на самом Go (даже без Go asm). Так что трудно сказать без профилирования насколько Go реально быстрее в этом случае.
Либо используется NullObject паттерн, или, в случае с rails (когда можно), delegate.