Спасибо за ответ, хотелось бы послушать подробности:
Как вы управляете зависимостями? DI контейнер через кодогенерацию?
На сколько удобно работать без нативной иммутабельности? Обычно с ростом кодовой базы именно баги в мутациях становятся главной болью
Встречались ли с проблемами отделения бизнес логики от инфраструктуры? Это важный вопрос, посколько реализация паттерна Спецификация крайне многословна (а потому и излишня) в go
Я тоже так думал, пока не провел небольшой опрос джунов. Оказалось, что для них вообще не проблема разобраться как работать с этими "новомодными" конструкциями! От слова ВООБЩЕ! А вот у кого есть проблема, так это у "вечных мидлов".
Давайте оттолнемся от этой аксиомы и попробуем сделать вывод:
В будущем в C# будет меньше "вечных мидлов"
Раз будет меньше "вечных мидлов", значит средняя зп станет выше
Раз средняя зп станет выше, больше людей будут "идти в C#"
Сборка мусора. Да, есть incremental gc, но это не панацея, так как он дает лишь небольшой послабление, в любом случае необходимо все подряд пулить.
Жду статью :)
Вообще с Burst не так все плохо, а вот с ECS беда. Там любое действие требует танцев с бубном
А вот это физически невозможно сделать :( но мне тоже не хватает
Это называется TShaped Skills
Спасибо!
Тот же вопрос к default interface methods вообще. Может лучше было ввести новую сущность trait?
Спасибо, а как вообще ощущение от работы с ЯП "без магии"?
Спасибо,
Выглядит многословно, но "должно работать" :)
Да, с такой точки зрения я не смотрел
Ныл я про это недавно знакомому джависту, а он мне сказал, что у них тоже самое.
Иммутабельность плохо уживается с изменчивостью игрового мира
Если мы будет строить pipeline в каждом цикле game loop, то не факт что сможем "уместить" все в один кадр
Достаточно удобный подход в асинхронном выполненияя кода в функциональном стиле, но это требует "слома головы"
А вот если писать императивно, но с async/await или корутинами, получается даже удобнее
Самое неприятное, что ФП стиль неплохо ложится на многие тулы в Unity (то же DOTween), но сложно это жкстраполировать на все.
Про перфоманс не буду говорить, а то захоливаримся:)
Странно, не у всех работает
Именно :)
"Нам не нужны неудачники" :)
Спасибо за ответ, хотелось бы послушать подробности:
Как вы управляете зависимостями? DI контейнер через кодогенерацию?
На сколько удобно работать без нативной иммутабельности? Обычно с ростом кодовой базы именно баги в мутациях становятся главной болью
Встречались ли с проблемами отделения бизнес логики от инфраструктуры? Это важный вопрос, посколько реализация паттерна Спецификация крайне многословна (а потому и излишня) в go
ИМХО, такие фичи просто никто не будет использовать. А если и будут, то вреда много не нанесут
Странное дело, но у меня ссылка работает. Проверил в режиме инкогнито.
У других ребят может не работаь в хроме, но работать в сафари и наоборот
Джуны достаточно быстро становятся мидлаим, а потом и сеньерами. А раз они такие активные, то в ловушку "вечных мидлов" не попадут
Я тоже так думал, пока не провел небольшой опрос джунов. Оказалось, что для них вообще не проблема разобраться как работать с этими "новомодными" конструкциями! От слова ВООБЩЕ!
А вот у кого есть проблема, так это у "вечных мидлов".
Давайте оттолнемся от этой аксиомы и попробуем сделать вывод:
В будущем в C# будет меньше "вечных мидлов"
Раз будет меньше "вечных мидлов", значит средняя зп станет выше
Раз средняя зп станет выше, больше людей будут "идти в C#"
???
PROFIT
Ну а как же наследование?