В любом случае интересно наблюдать за всей этой историей с обработкой ошибок в go. Многие просто смеются над гошникамии и говорят, что они никак не могут осилить обычный try/catch, но и этот подход хоть и самый популярный, но не общепризнанный. В haskell, например, не особо любят эксепшены и предпочитают всякие MayBe и Either. Интересно, чем это закончится. Может, Пайк придумает нечто совсем революционное.
Одобряю выбор первого парня, но во время работы стараюсь слушать звуки, которые способствуют концентрации, а именно: Noisli Asoftmurmur Mynoise
Для винды ещё есть Elpy.
DI — это паттерн решения проблемы. SL — конкретный подход для реализации этого паттерна.
Не всегда. Зависит от того, что скрывается за аббревиатурой DI. Если это dependency inversion, то всё так. Если же речь про dependency injection, то нет. В общем виде ситуация следующая:
1. Есть IoC (Inversion of Control)
2. Есть DI (dependency inversion) — частный случай IoC
3. Есть ещё один DI (dependency injection) — решение «проблемы» DI (dependency inversion). SL — это тоже решение «проблемы» DI.
Да, термины подобраны не очень удачно. Но вот тут Мартин Фаулер хорошо поясняет
Как зачем? Чтобы сформировать это «огромное полотенце всех данных».
Noisli
Asoftmurmur
Mynoise
Для винды ещё есть Elpy.
Как по мне, так гораздо продуктивнее
Не всегда. Зависит от того, что скрывается за аббревиатурой DI. Если это dependency inversion, то всё так. Если же речь про dependency injection, то нет. В общем виде ситуация следующая:
1. Есть IoC (Inversion of Control)
2. Есть DI (dependency inversion) — частный случай IoC
3. Есть ещё один DI (dependency injection) — решение «проблемы» DI (dependency inversion). SL — это тоже решение «проблемы» DI.
Да, термины подобраны не очень удачно. Но вот тут Мартин Фаулер хорошо поясняет
Какой ужас. Зачем?