Да. видимо я переоценил функционал роутинга без контроллеро в ASP.NET Core. Я просто думал что это настолько же удобно делается. как в жирафе (F# фреймворк поверх ASP.NET Core)

А, у них же там ещё пакетного менеджера не существует. Можно импортировать напрямую с гитхаба зато. И ко второй версии дженерики завезут, честно-честно! Ну и что такого что мы уже который год говорим что это будет в этом году.

>=>

<=<

^
||
^

Вроде уже существует

И модули туда завезли

Последнее что я видел - это было ПРОКСИ чтобы перехватывать запросы от го гет и отвечать тем что нужно, дальше у меня вытекли глаза, может и изменилось чего.

Статья не говорит что паттерн репозиторий является антипаттерном. Приводится пример когда нормальный паттерн превращается в "антипаттерн" из-за лишних абстракций и других переделок.

Ну функциональные языки иногда бывают удобнее, что есть то есть. Другое дело, что универсальные языки практичнее))

У нас архитектор на проекте рассматривал Go как средство для генерации GraphQL API которое будет играть роль довольно тонкого прокси в gRPC (чтобы gRPC в паблик апи напрямую не выносить). Я в итоге взялся ковырять и пробовать что то нагенерить с gqlgen (гошная тула для генерации GraphQL классов и скелета проекта). Все было ок до того момента пока я не начал писать конкретно реализацию резолверов, а потом еще оказалось что нам надо туда пагинацию надо будет кастомную добавлять и прочее. Я стал понимать что наша команда банально не вывезет, ибо для этого как минимум надо нормально так в Go разобраться и потратить время для обучение, короче залупа а не затея. Основной поинт архитектора был в том, что го это быстро. а нам нужен быстрый прокси. В итоге я начал топить за дотнет реализацию чисто из практичных соображений (команда дотнетеров, экспертиза знакомая, разница в производительности будет не такой уж и большой), вот сейчас пока этот вопрос все еще висит в воздухе, моя .NET реализация ждет пока у него дойдут руки ее посмотреть. Но даже если он скажет что на дотнете мы его писать не будем, будем топить против го просто потому что выигрыш в данном случае в производительности не стоит столько потенциально потраченного времени банально (в нашем случае конкретно). Тем более дотнет реализация не медленная тоже

F# это не совсем функциональный язык, функциональный язык это Haskell
На F# ты можешь писать в том же ООПшном стиле как и в сишарпе при надобности (обычно это надо когда нужно завязываться на ООПшные либы написанные на сишарпе)

Я вот тут задумался, можно ли код си шарп компилировать в машинный код? Вот слышал про IL2CPU, но он для операционки, а есть вообще для простой программы?

да вроде

Вот я по бенчмаркам не заметил, что ГО быстрее. В дотнете есть проблемы с перформансом ORM, но объективно, где еще есть настолько мощная ормка? Да и в 6.0 они вроде как на 30 процентов ускорят ее

https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator оно?

Я хотел сделать бенчмарки gqlgen + Go vs HotChocolate + .NET, но в итоге я начал понимать что на го реализацию уходит дохера времени и забил банально

Ибо других задач на проекте полно