S
я не раз Диме писал. убрать эту хрень.
Size: a a a
2020 October 04
S
тут адеквантые люди, а неадекват можно и без этих предупреждений молча банить
2020 October 05
IS
Тут cпрашивали про .net core, если кому-то интересно, могу рассказать, почему мы после 10+ месяцев её использования и даже поставок бета версий клиентам, свалили на go. Но может получитьcя "простыня" 😊
R
Тут cпрашивали про .net core, если кому-то интересно, могу рассказать, почему мы после 10+ месяцев её использования и даже поставок бета версий клиентам, свалили на go. Но может получитьcя "простыня" 😊
Расскажите
ВВ
Привет 🙋
ВВ
Такой вопрос, к сознательным людям. Возможно неправильно такие вопросы тут задавать ...
ВВ
Как вы относитесь к масочному режиму?
1) положительно - это нужно и важно для сохранения жизни людей
2) отрицательно - это вынужденная мера, соблюдаю только там где требуют и просят отказывая в обслуживании
3) нейтрально - ну надо и надо
1) положительно - это нужно и важно для сохранения жизни людей
2) отрицательно - это вынужденная мера, соблюдаю только там где требуют и просят отказывая в обслуживании
3) нейтрально - ну надо и надо
ВВ
Можно конечно свой вариант.
A
Тут cпрашивали про .net core, если кому-то интересно, могу рассказать, почему мы после 10+ месяцев её использования и даже поставок бета версий клиентам, свалили на go. Но может получитьcя "простыня" 😊
интересно было бы послушать. входим в проект на дот.нете, вдруг инфа будет полезна в плане сбора чужих граблей, дабы не повторять весь сложный путь
K
Тут cпрашивали про .net core, если кому-то интересно, могу рассказать, почему мы после 10+ месяцев её использования и даже поставок бета версий клиентам, свалили на go. Но может получитьcя "простыня" 😊
++
ВВ
есть вообще плюсы от .net?
AC
Экосистема)
DS
Тут cпрашивали про .net core, если кому-то интересно, могу рассказать, почему мы после 10+ месяцев её использования и даже поставок бета версий клиентам, свалили на go. Но может получитьcя "простыня" 😊
Да, очень интересно! Жги 🔥
IS
Дисклеймер: все будет очень субъективно. Ядро команды - С++-ники без очень глубокого .net опыта, хотя с технологией работали еще со времён .net 2.0, поэтому часть проблем вам могут показаться странными. Разрабатываемая система – специализированная аналитическая система, архитектурно – монолит с небольшими сервисами рядом и своей системой оркестрации и мониторинга.
Минусы .net core:
Большое количество мелких и не очень проблем со сборкой и развертыванием. В теории они могут собирать все в один executable, но на практике добиться его 100% работоспособности нам не удалось (валился в случайных местах), поэтому windows-решение выглядело как 130 мегабайт и пара сотен DLL. Сборки из IDE, MS Build и родным CLI от .net core порождают разные бинарники из одного и того же набора исходников, причем в третьем случае – не всегда работоспособные.
В один каталог не удается развертывать два executable, а нам это технологически было очень удобно. Происходит это из-за того, что вышеупомянутый «комплект» из 120-130 Мб DLL разный в зависимости от того, какие классы .net используются. В результате в сравнении с Go бинарный размер решения отличается ровно на порядок при том же самом функционале.
При накатывании updates на Visual Studio незаметным образом меняются и DLL от .net core, что тоже порождает свои чудеса – за этим надо сделать чтобы не получить несовместимый комплект «мира». У нас есть система update решения прямо на лету (5-7 секунд downtime) и эти чудеса порождали отдельный напряг раз в месяц-полтора.
Проблема с драйверами: Microsoft толкает всех в свой ORM (Entity Framework), а у нас есть свои, довольно тонкие, обвязки вокруг СУБД, в результате чего включить в комплект развертывания low level драйвер не получается и его надо отдельно ставить. Для Windows это ODBC, для Linux какой-то костыль, с которым мы так до конца и не справились, увы.
.net core достаточно высокоуровневый и абстрактный, то есть для того, чтобы что-то поменять на низком уровне или покопаться в кишочках pipeline, нужна магия, в свою очередь требующая «курения» документации, а то и исходников самого core. От «вау как круто» в первые месяцы это свелось к «б%я, но почему именно так?» на более зрелых этапах разработки.
Оно кушает память не всегда понятным образом. Не Java конечно, но разница с Go все равно получилась от 50 до 200-300%.
Плюсы .net core:
Безусловно, главный плюс – это сам C#, комфортный и современный язык. Новые версии Visual Studio (desktop, не Code) очень хороши.
Плюсы Go
Zero dependency binary – это просто прелесть, проблем нет вообще, скопировал единственный executable на любую систему и оно поднялось. После core – небо и земля, примерно 100% проблем с deployment были устранены.
Кросс-компиляция – один ключик, а дальше смотри предыдущий абзац.
Шикарный tooling из коробки, от unit testing и benchmarking до linter и formatter – тут можно много говорить, спрашивайте, если интересны подробности.
Порог вхождения для developers в конкурентное программирование выглядит ниже. Все понимают что канал – это банальная очередь с mutex, но пользоваться ими комфортно. Горутины и вот это все.
Минусы Go
Такого убогого языка я не видел со времен Fortran 77, нет даже тернарного оператора. Есть ряд неочевидных «подводных грабель», на разборки с которыми уйдет день-два своими силами или прочтение пары статей. Обратная сторона – любой middle из мира С++ или C# будет радостно кодить на go через пару дней после выдачи документации.
Минусы .net core:
Большое количество мелких и не очень проблем со сборкой и развертыванием. В теории они могут собирать все в один executable, но на практике добиться его 100% работоспособности нам не удалось (валился в случайных местах), поэтому windows-решение выглядело как 130 мегабайт и пара сотен DLL. Сборки из IDE, MS Build и родным CLI от .net core порождают разные бинарники из одного и того же набора исходников, причем в третьем случае – не всегда работоспособные.
В один каталог не удается развертывать два executable, а нам это технологически было очень удобно. Происходит это из-за того, что вышеупомянутый «комплект» из 120-130 Мб DLL разный в зависимости от того, какие классы .net используются. В результате в сравнении с Go бинарный размер решения отличается ровно на порядок при том же самом функционале.
При накатывании updates на Visual Studio незаметным образом меняются и DLL от .net core, что тоже порождает свои чудеса – за этим надо сделать чтобы не получить несовместимый комплект «мира». У нас есть система update решения прямо на лету (5-7 секунд downtime) и эти чудеса порождали отдельный напряг раз в месяц-полтора.
Проблема с драйверами: Microsoft толкает всех в свой ORM (Entity Framework), а у нас есть свои, довольно тонкие, обвязки вокруг СУБД, в результате чего включить в комплект развертывания low level драйвер не получается и его надо отдельно ставить. Для Windows это ODBC, для Linux какой-то костыль, с которым мы так до конца и не справились, увы.
.net core достаточно высокоуровневый и абстрактный, то есть для того, чтобы что-то поменять на низком уровне или покопаться в кишочках pipeline, нужна магия, в свою очередь требующая «курения» документации, а то и исходников самого core. От «вау как круто» в первые месяцы это свелось к «б%я, но почему именно так?» на более зрелых этапах разработки.
Оно кушает память не всегда понятным образом. Не Java конечно, но разница с Go все равно получилась от 50 до 200-300%.
Плюсы .net core:
Безусловно, главный плюс – это сам C#, комфортный и современный язык. Новые версии Visual Studio (desktop, не Code) очень хороши.
Плюсы Go
Zero dependency binary – это просто прелесть, проблем нет вообще, скопировал единственный executable на любую систему и оно поднялось. После core – небо и земля, примерно 100% проблем с deployment были устранены.
Кросс-компиляция – один ключик, а дальше смотри предыдущий абзац.
Шикарный tooling из коробки, от unit testing и benchmarking до linter и formatter – тут можно много говорить, спрашивайте, если интересны подробности.
Порог вхождения для developers в конкурентное программирование выглядит ниже. Все понимают что канал – это банальная очередь с mutex, но пользоваться ими комфортно. Горутины и вот это все.
Минусы Go
Такого убогого языка я не видел со времен Fortran 77, нет даже тернарного оператора. Есть ряд неочевидных «подводных грабель», на разборки с которыми уйдет день-два своими силами или прочтение пары статей. Обратная сторона – любой middle из мира С++ или C# будет радостно кодить на go через пару дней после выдачи документации.
АВ
Отличная иллюстрация к теме "СТО из девелоперов", кстати.
Программист выбирает Rust за красоту концепций, "модность" и итоговый performance (если осилил).
СТО - Go, за простоту, "кондовость", отличный тулинг из коробки и доступность разработчиков на рынке.
Программист выбирает Rust за красоту концепций, "модность" и итоговый performance (если осилил).
СТО - Go, за простоту, "кондовость", отличный тулинг из коробки и доступность разработчиков на рынке.
+100500
С
Дисклеймер: все будет очень субъективно. Ядро команды - С++-ники без очень глубокого .net опыта, хотя с технологией работали еще со времён .net 2.0, поэтому часть проблем вам могут показаться странными. Разрабатываемая система – специализированная аналитическая система, архитектурно – монолит с небольшими сервисами рядом и своей системой оркестрации и мониторинга.
Минусы .net core:
Большое количество мелких и не очень проблем со сборкой и развертыванием. В теории они могут собирать все в один executable, но на практике добиться его 100% работоспособности нам не удалось (валился в случайных местах), поэтому windows-решение выглядело как 130 мегабайт и пара сотен DLL. Сборки из IDE, MS Build и родным CLI от .net core порождают разные бинарники из одного и того же набора исходников, причем в третьем случае – не всегда работоспособные.
В один каталог не удается развертывать два executable, а нам это технологически было очень удобно. Происходит это из-за того, что вышеупомянутый «комплект» из 120-130 Мб DLL разный в зависимости от того, какие классы .net используются. В результате в сравнении с Go бинарный размер решения отличается ровно на порядок при том же самом функционале.
При накатывании updates на Visual Studio незаметным образом меняются и DLL от .net core, что тоже порождает свои чудеса – за этим надо сделать чтобы не получить несовместимый комплект «мира». У нас есть система update решения прямо на лету (5-7 секунд downtime) и эти чудеса порождали отдельный напряг раз в месяц-полтора.
Проблема с драйверами: Microsoft толкает всех в свой ORM (Entity Framework), а у нас есть свои, довольно тонкие, обвязки вокруг СУБД, в результате чего включить в комплект развертывания low level драйвер не получается и его надо отдельно ставить. Для Windows это ODBC, для Linux какой-то костыль, с которым мы так до конца и не справились, увы.
.net core достаточно высокоуровневый и абстрактный, то есть для того, чтобы что-то поменять на низком уровне или покопаться в кишочках pipeline, нужна магия, в свою очередь требующая «курения» документации, а то и исходников самого core. От «вау как круто» в первые месяцы это свелось к «б%я, но почему именно так?» на более зрелых этапах разработки.
Оно кушает память не всегда понятным образом. Не Java конечно, но разница с Go все равно получилась от 50 до 200-300%.
Плюсы .net core:
Безусловно, главный плюс – это сам C#, комфортный и современный язык. Новые версии Visual Studio (desktop, не Code) очень хороши.
Плюсы Go
Zero dependency binary – это просто прелесть, проблем нет вообще, скопировал единственный executable на любую систему и оно поднялось. После core – небо и земля, примерно 100% проблем с deployment были устранены.
Кросс-компиляция – один ключик, а дальше смотри предыдущий абзац.
Шикарный tooling из коробки, от unit testing и benchmarking до linter и formatter – тут можно много говорить, спрашивайте, если интересны подробности.
Порог вхождения для developers в конкурентное программирование выглядит ниже. Все понимают что канал – это банальная очередь с mutex, но пользоваться ими комфортно. Горутины и вот это все.
Минусы Go
Такого убогого языка я не видел со времен Fortran 77, нет даже тернарного оператора. Есть ряд неочевидных «подводных грабель», на разборки с которыми уйдет день-два своими силами или прочтение пары статей. Обратная сторона – любой middle из мира С++ или C# будет радостно кодить на go через пару дней после выдачи документации.
Минусы .net core:
Большое количество мелких и не очень проблем со сборкой и развертыванием. В теории они могут собирать все в один executable, но на практике добиться его 100% работоспособности нам не удалось (валился в случайных местах), поэтому windows-решение выглядело как 130 мегабайт и пара сотен DLL. Сборки из IDE, MS Build и родным CLI от .net core порождают разные бинарники из одного и того же набора исходников, причем в третьем случае – не всегда работоспособные.
В один каталог не удается развертывать два executable, а нам это технологически было очень удобно. Происходит это из-за того, что вышеупомянутый «комплект» из 120-130 Мб DLL разный в зависимости от того, какие классы .net используются. В результате в сравнении с Go бинарный размер решения отличается ровно на порядок при том же самом функционале.
При накатывании updates на Visual Studio незаметным образом меняются и DLL от .net core, что тоже порождает свои чудеса – за этим надо сделать чтобы не получить несовместимый комплект «мира». У нас есть система update решения прямо на лету (5-7 секунд downtime) и эти чудеса порождали отдельный напряг раз в месяц-полтора.
Проблема с драйверами: Microsoft толкает всех в свой ORM (Entity Framework), а у нас есть свои, довольно тонкие, обвязки вокруг СУБД, в результате чего включить в комплект развертывания low level драйвер не получается и его надо отдельно ставить. Для Windows это ODBC, для Linux какой-то костыль, с которым мы так до конца и не справились, увы.
.net core достаточно высокоуровневый и абстрактный, то есть для того, чтобы что-то поменять на низком уровне или покопаться в кишочках pipeline, нужна магия, в свою очередь требующая «курения» документации, а то и исходников самого core. От «вау как круто» в первые месяцы это свелось к «б%я, но почему именно так?» на более зрелых этапах разработки.
Оно кушает память не всегда понятным образом. Не Java конечно, но разница с Go все равно получилась от 50 до 200-300%.
Плюсы .net core:
Безусловно, главный плюс – это сам C#, комфортный и современный язык. Новые версии Visual Studio (desktop, не Code) очень хороши.
Плюсы Go
Zero dependency binary – это просто прелесть, проблем нет вообще, скопировал единственный executable на любую систему и оно поднялось. После core – небо и земля, примерно 100% проблем с deployment были устранены.
Кросс-компиляция – один ключик, а дальше смотри предыдущий абзац.
Шикарный tooling из коробки, от unit testing и benchmarking до linter и formatter – тут можно много говорить, спрашивайте, если интересны подробности.
Порог вхождения для developers в конкурентное программирование выглядит ниже. Все понимают что канал – это банальная очередь с mutex, но пользоваться ими комфортно. Горутины и вот это все.
Минусы Go
Такого убогого языка я не видел со времен Fortran 77, нет даже тернарного оператора. Есть ряд неочевидных «подводных грабель», на разборки с которыми уйдет день-два своими силами или прочтение пары статей. Обратная сторона – любой middle из мира С++ или C# будет радостно кодить на go через пару дней после выдачи документации.
Наверное речь о тернарном операторе? Тоже каждый раз плююсь от его отсутствия.
IS
С
Наверное речь о тернарном операторе? Тоже каждый раз плююсь от его отсутствия.
Поправил, спасибо.
IS
Дисклеймер: все будет очень субъективно. Ядро команды - С++-ники без очень глубокого .net опыта, хотя с технологией работали еще со времён .net 2.0, поэтому часть проблем вам могут показаться странными. Разрабатываемая система – специализированная аналитическая система, архитектурно – монолит с небольшими сервисами рядом и своей системой оркестрации и мониторинга.
Минусы .net core:
Большое количество мелких и не очень проблем со сборкой и развертыванием. В теории они могут собирать все в один executable, но на практике добиться его 100% работоспособности нам не удалось (валился в случайных местах), поэтому windows-решение выглядело как 130 мегабайт и пара сотен DLL. Сборки из IDE, MS Build и родным CLI от .net core порождают разные бинарники из одного и того же набора исходников, причем в третьем случае – не всегда работоспособные.
В один каталог не удается развертывать два executable, а нам это технологически было очень удобно. Происходит это из-за того, что вышеупомянутый «комплект» из 120-130 Мб DLL разный в зависимости от того, какие классы .net используются. В результате в сравнении с Go бинарный размер решения отличается ровно на порядок при том же самом функционале.
При накатывании updates на Visual Studio незаметным образом меняются и DLL от .net core, что тоже порождает свои чудеса – за этим надо сделать чтобы не получить несовместимый комплект «мира». У нас есть система update решения прямо на лету (5-7 секунд downtime) и эти чудеса порождали отдельный напряг раз в месяц-полтора.
Проблема с драйверами: Microsoft толкает всех в свой ORM (Entity Framework), а у нас есть свои, довольно тонкие, обвязки вокруг СУБД, в результате чего включить в комплект развертывания low level драйвер не получается и его надо отдельно ставить. Для Windows это ODBC, для Linux какой-то костыль, с которым мы так до конца и не справились, увы.
.net core достаточно высокоуровневый и абстрактный, то есть для того, чтобы что-то поменять на низком уровне или покопаться в кишочках pipeline, нужна магия, в свою очередь требующая «курения» документации, а то и исходников самого core. От «вау как круто» в первые месяцы это свелось к «б%я, но почему именно так?» на более зрелых этапах разработки.
Оно кушает память не всегда понятным образом. Не Java конечно, но разница с Go все равно получилась от 50 до 200-300%.
Плюсы .net core:
Безусловно, главный плюс – это сам C#, комфортный и современный язык. Новые версии Visual Studio (desktop, не Code) очень хороши.
Плюсы Go
Zero dependency binary – это просто прелесть, проблем нет вообще, скопировал единственный executable на любую систему и оно поднялось. После core – небо и земля, примерно 100% проблем с deployment были устранены.
Кросс-компиляция – один ключик, а дальше смотри предыдущий абзац.
Шикарный tooling из коробки, от unit testing и benchmarking до linter и formatter – тут можно много говорить, спрашивайте, если интересны подробности.
Порог вхождения для developers в конкурентное программирование выглядит ниже. Все понимают что канал – это банальная очередь с mutex, но пользоваться ими комфортно. Горутины и вот это все.
Минусы Go
Такого убогого языка я не видел со времен Fortran 77, нет даже тернарного оператора. Есть ряд неочевидных «подводных грабель», на разборки с которыми уйдет день-два своими силами или прочтение пары статей. Обратная сторона – любой middle из мира С++ или C# будет радостно кодить на go через пару дней после выдачи документации.
Минусы .net core:
Большое количество мелких и не очень проблем со сборкой и развертыванием. В теории они могут собирать все в один executable, но на практике добиться его 100% работоспособности нам не удалось (валился в случайных местах), поэтому windows-решение выглядело как 130 мегабайт и пара сотен DLL. Сборки из IDE, MS Build и родным CLI от .net core порождают разные бинарники из одного и того же набора исходников, причем в третьем случае – не всегда работоспособные.
В один каталог не удается развертывать два executable, а нам это технологически было очень удобно. Происходит это из-за того, что вышеупомянутый «комплект» из 120-130 Мб DLL разный в зависимости от того, какие классы .net используются. В результате в сравнении с Go бинарный размер решения отличается ровно на порядок при том же самом функционале.
При накатывании updates на Visual Studio незаметным образом меняются и DLL от .net core, что тоже порождает свои чудеса – за этим надо сделать чтобы не получить несовместимый комплект «мира». У нас есть система update решения прямо на лету (5-7 секунд downtime) и эти чудеса порождали отдельный напряг раз в месяц-полтора.
Проблема с драйверами: Microsoft толкает всех в свой ORM (Entity Framework), а у нас есть свои, довольно тонкие, обвязки вокруг СУБД, в результате чего включить в комплект развертывания low level драйвер не получается и его надо отдельно ставить. Для Windows это ODBC, для Linux какой-то костыль, с которым мы так до конца и не справились, увы.
.net core достаточно высокоуровневый и абстрактный, то есть для того, чтобы что-то поменять на низком уровне или покопаться в кишочках pipeline, нужна магия, в свою очередь требующая «курения» документации, а то и исходников самого core. От «вау как круто» в первые месяцы это свелось к «б%я, но почему именно так?» на более зрелых этапах разработки.
Оно кушает память не всегда понятным образом. Не Java конечно, но разница с Go все равно получилась от 50 до 200-300%.
Плюсы .net core:
Безусловно, главный плюс – это сам C#, комфортный и современный язык. Новые версии Visual Studio (desktop, не Code) очень хороши.
Плюсы Go
Zero dependency binary – это просто прелесть, проблем нет вообще, скопировал единственный executable на любую систему и оно поднялось. После core – небо и земля, примерно 100% проблем с deployment были устранены.
Кросс-компиляция – один ключик, а дальше смотри предыдущий абзац.
Шикарный tooling из коробки, от unit testing и benchmarking до linter и formatter – тут можно много говорить, спрашивайте, если интересны подробности.
Порог вхождения для developers в конкурентное программирование выглядит ниже. Все понимают что канал – это банальная очередь с mutex, но пользоваться ими комфортно. Горутины и вот это все.
Минусы Go
Такого убогого языка я не видел со времен Fortran 77, нет даже тернарного оператора. Есть ряд неочевидных «подводных грабель», на разборки с которыми уйдет день-два своими силами или прочтение пары статей. Обратная сторона – любой middle из мира С++ или C# будет радостно кодить на go через пару дней после выдачи документации.
В привате спросили про грабли. Вот две, для примера:
1. Измененные в переданном в функцию по значению slice элементы снаружи будут видны, а добавленные через append – не будут.
2. Нельзя передавать содержащие slice структуры через канал, они не копируются, будет гонка за slice.
1. Измененные в переданном в функцию по значению slice элементы снаружи будут видны, а добавленные через append – не будут.
2. Нельзя передавать содержащие slice структуры через канал, они не копируются, будет гонка за slice.
K
Дисклеймер: все будет очень субъективно. Ядро команды - С++-ники без очень глубокого .net опыта, хотя с технологией работали еще со времён .net 2.0, поэтому часть проблем вам могут показаться странными. Разрабатываемая система – специализированная аналитическая система, архитектурно – монолит с небольшими сервисами рядом и своей системой оркестрации и мониторинга.
Минусы .net core:
Большое количество мелких и не очень проблем со сборкой и развертыванием. В теории они могут собирать все в один executable, но на практике добиться его 100% работоспособности нам не удалось (валился в случайных местах), поэтому windows-решение выглядело как 130 мегабайт и пара сотен DLL. Сборки из IDE, MS Build и родным CLI от .net core порождают разные бинарники из одного и того же набора исходников, причем в третьем случае – не всегда работоспособные.
В один каталог не удается развертывать два executable, а нам это технологически было очень удобно. Происходит это из-за того, что вышеупомянутый «комплект» из 120-130 Мб DLL разный в зависимости от того, какие классы .net используются. В результате в сравнении с Go бинарный размер решения отличается ровно на порядок при том же самом функционале.
При накатывании updates на Visual Studio незаметным образом меняются и DLL от .net core, что тоже порождает свои чудеса – за этим надо сделать чтобы не получить несовместимый комплект «мира». У нас есть система update решения прямо на лету (5-7 секунд downtime) и эти чудеса порождали отдельный напряг раз в месяц-полтора.
Проблема с драйверами: Microsoft толкает всех в свой ORM (Entity Framework), а у нас есть свои, довольно тонкие, обвязки вокруг СУБД, в результате чего включить в комплект развертывания low level драйвер не получается и его надо отдельно ставить. Для Windows это ODBC, для Linux какой-то костыль, с которым мы так до конца и не справились, увы.
.net core достаточно высокоуровневый и абстрактный, то есть для того, чтобы что-то поменять на низком уровне или покопаться в кишочках pipeline, нужна магия, в свою очередь требующая «курения» документации, а то и исходников самого core. От «вау как круто» в первые месяцы это свелось к «б%я, но почему именно так?» на более зрелых этапах разработки.
Оно кушает память не всегда понятным образом. Не Java конечно, но разница с Go все равно получилась от 50 до 200-300%.
Плюсы .net core:
Безусловно, главный плюс – это сам C#, комфортный и современный язык. Новые версии Visual Studio (desktop, не Code) очень хороши.
Плюсы Go
Zero dependency binary – это просто прелесть, проблем нет вообще, скопировал единственный executable на любую систему и оно поднялось. После core – небо и земля, примерно 100% проблем с deployment были устранены.
Кросс-компиляция – один ключик, а дальше смотри предыдущий абзац.
Шикарный tooling из коробки, от unit testing и benchmarking до linter и formatter – тут можно много говорить, спрашивайте, если интересны подробности.
Порог вхождения для developers в конкурентное программирование выглядит ниже. Все понимают что канал – это банальная очередь с mutex, но пользоваться ими комфортно. Горутины и вот это все.
Минусы Go
Такого убогого языка я не видел со времен Fortran 77, нет даже тернарного оператора. Есть ряд неочевидных «подводных грабель», на разборки с которыми уйдет день-два своими силами или прочтение пары статей. Обратная сторона – любой middle из мира С++ или C# будет радостно кодить на go через пару дней после выдачи документации.
Минусы .net core:
Большое количество мелких и не очень проблем со сборкой и развертыванием. В теории они могут собирать все в один executable, но на практике добиться его 100% работоспособности нам не удалось (валился в случайных местах), поэтому windows-решение выглядело как 130 мегабайт и пара сотен DLL. Сборки из IDE, MS Build и родным CLI от .net core порождают разные бинарники из одного и того же набора исходников, причем в третьем случае – не всегда работоспособные.
В один каталог не удается развертывать два executable, а нам это технологически было очень удобно. Происходит это из-за того, что вышеупомянутый «комплект» из 120-130 Мб DLL разный в зависимости от того, какие классы .net используются. В результате в сравнении с Go бинарный размер решения отличается ровно на порядок при том же самом функционале.
При накатывании updates на Visual Studio незаметным образом меняются и DLL от .net core, что тоже порождает свои чудеса – за этим надо сделать чтобы не получить несовместимый комплект «мира». У нас есть система update решения прямо на лету (5-7 секунд downtime) и эти чудеса порождали отдельный напряг раз в месяц-полтора.
Проблема с драйверами: Microsoft толкает всех в свой ORM (Entity Framework), а у нас есть свои, довольно тонкие, обвязки вокруг СУБД, в результате чего включить в комплект развертывания low level драйвер не получается и его надо отдельно ставить. Для Windows это ODBC, для Linux какой-то костыль, с которым мы так до конца и не справились, увы.
.net core достаточно высокоуровневый и абстрактный, то есть для того, чтобы что-то поменять на низком уровне или покопаться в кишочках pipeline, нужна магия, в свою очередь требующая «курения» документации, а то и исходников самого core. От «вау как круто» в первые месяцы это свелось к «б%я, но почему именно так?» на более зрелых этапах разработки.
Оно кушает память не всегда понятным образом. Не Java конечно, но разница с Go все равно получилась от 50 до 200-300%.
Плюсы .net core:
Безусловно, главный плюс – это сам C#, комфортный и современный язык. Новые версии Visual Studio (desktop, не Code) очень хороши.
Плюсы Go
Zero dependency binary – это просто прелесть, проблем нет вообще, скопировал единственный executable на любую систему и оно поднялось. После core – небо и земля, примерно 100% проблем с deployment были устранены.
Кросс-компиляция – один ключик, а дальше смотри предыдущий абзац.
Шикарный tooling из коробки, от unit testing и benchmarking до linter и formatter – тут можно много говорить, спрашивайте, если интересны подробности.
Порог вхождения для developers в конкурентное программирование выглядит ниже. Все понимают что канал – это банальная очередь с mutex, но пользоваться ими комфортно. Горутины и вот это все.
Минусы Go
Такого убогого языка я не видел со времен Fortran 77, нет даже тернарного оператора. Есть ряд неочевидных «подводных грабель», на разборки с которыми уйдет день-два своими силами или прочтение пары статей. Обратная сторона – любой middle из мира С++ или C# будет радостно кодить на go через пару дней после выдачи документации.
про .net core.
Да, удобнее собирать каждый exe в отдельный каталог со своими зависимостями.
если хотите чтобы все лежало вместе, то надо желательно завести отдельный nuget репозиторий,в котором каленым железом выжигать дубли пакетов (чтобы была только одна версия).
Тогда будет согласованность.
И конечно на build сервере не забыть вычистить темповые каталоги с пакетами.
Да, удобнее собирать каждый exe в отдельный каталог со своими зависимостями.
если хотите чтобы все лежало вместе, то надо желательно завести отдельный nuget репозиторий,в котором каленым железом выжигать дубли пакетов (чтобы была только одна версия).
Тогда будет согласованность.
И конечно на build сервере не забыть вычистить темповые каталоги с пакетами.
K
.net core тащит