Здравствуйте, Явь-истъ, Вы писали:

ЯИ>Все просто. Побеждают открытые стандарты и open source. А проприетарщина отходит на второй план.
.Net Core open source

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, varenikAA, Вы писали:

AA>>

KP>Кстати, про C#. У нас в компании было всего одно приложение на Go, и то не в бэкэнде. Бэкэнд весь на C#, ну, исторически так сложилось. И тут вдруг начали появляется компоненты для бэка на Go. Поинтересовался в чём дело... сюрприз в том, что нормальные кандидаты как слышат про бэкэнд на C# — машут ручкой, а пилить надо. Я прям порадовался, глядишь и вытеснит это говнище, .NET всмысле, приличная платформа.

То есть у вас HR совсем отбитые что на позицию C# бэкэнд разработчик зовут GO программистов? Или приходит C# разработчик и говорит "не, не хочу я бэкэнд на C# писать, хочу на GO", так?

Здравствуйте, Ikemefula, Вы писали:

I>Обоснуй уже эту правильность. При чем здесь лисп?

в лиспе скобки обязательны. для if обязательно наличие обеих веток.
возможность опускать создает неопределенность.
в любом языке есть правописание. старые языки не могли обеспечить контроль форматирования.

Здравствуйте, microuser, Вы писали:

M>То есть у вас HR совсем отбитые что на позицию C# бэкэнд разработчик зовут GO программистов? Или приходит C# разработчик и говорит "не, не хочу я бэкэнд на C# писать, хочу на GO", так?

У нас HR-ы достаточно продвинутые что бы понимать что бэкэнд разработчик — это именно что бэкэнд разработчик, а не разработчик на каком-то языке. Бывают, конечно, исключительные языки типа C++ и Haskell где без знания самого языка никуда, но к счастью для большинства языков это не так. Если человек умеет писать бекенд на Go, он однозначно сможет его писать на C#, было бы желание. И вот как раз желания не наблюдается

Здравствуйте, kaa.python, Вы писали:


KP> Если человек умеет писать бекенд на Go, он однозначно сможет его писать на C#, было бы желание. И вот как раз желания не наблюдается

Ну не знаю. ведь ЯП это инструмент и им нужно овладеть до нужной квалификации.
иначе получится как всегда.

Здравствуйте, varenikAA, Вы писали:

AA>Ну не знаю. ведь ЯП это инструмент и им нужно овладеть до нужной квалификации.

Зачем нужно? Если в проекте есть: стандарт кодирования, код ревью, используются линтеры... то разработчик в одной и той же предметной области легко перейдет на другой язык за то же время что вольётся в новый проект

AA>иначе получится как всегда.

Как всегда — это как? Есть опыт? У меня есть (компании разные, выходил работать с новым языком, до первого дня опыта с языком небыло, если не считать того что до выхода на работу книжек по языку почитл): C++ -> Java -> C++/Go -> Elixir -> C++. Полет нормальный, все были довольны. C++ задолбал, правда, но что уж тут поделаешь

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, varenikAA, Вы писали:

AA>>Ну не знаю. ведь ЯП это инструмент и им нужно овладеть до нужной квалификации.

KP>Зачем нужно? Если в проекте есть: стандарт кодирования, код ревью, используются линтеры... то разработчик в одной и той же предметной области легко перейдет на другой язык за то же время что вольётся в новый проект

Семантика разная. Разные технологии.

AA>>иначе получится как всегда.

KP>Как всегда — это как? Есть опыт? У меня есть (компании разные, выходил на работать с новым языком): C++ -> Java -> C++/Go -> Elixir -> C++. Полет нормальный, все были довольны. C++ задолбал, правда, но что уж тут поделаешь

По моему это очевидно. Я же не знаю, может вы джедай. Чаще наоборот, нежелание даже смотреть на другой ЯП и технологию.
Но даже если есть желание на качество продукта скажется отсутствие опыта. первый блин, как говорится.

Здравствуйте, varenikAA, Вы писали:

AA>Семантика разная. Разные технологии.

Это не проблема, изучается крайне просто. Язык не более чем инструмент, важны базовые знания.

AA>По моему это очевидно.

Это очевидное, довольно распространённое заблуждение.

AA>Чаще наоборот, нежелание даже смотреть на другой ЯП и технологию.

Да, такое бывает и обговаривается "на берегу". Что-то в духе "- но мы тут пишем на Elixir, надо будет выучить самом. — Угу, без проблем, книгу посоветуете?"

AA>Но даже если есть желание на качество продукта скажется отсутствие опыта. первый блин, как говорится.

Не снижается если есть нормальная командная работа. Вообще никак не влияет, часто даже на оборот, человек знает как ещё можно решить ту же самую проблему и предлагает альтернативный вариант.

Проверять знания языка стоит в двух случаях а) ты ищешь разработчика на C++, b) ты ищешь разработчика на Haskell. Всё. Остальные языки (те что есть в живой природе) — они для людей, а не мутантов. Ну, наверное в этот список Rust еще можно добавить, но если человек знает C++, то уж с Rust справится.

K>ВАМ ЛИЧНО зачем эта... гм... "крос т платформенность"?
Хорошая фраза. Можно использовать при обсуждении проектов и не придётся потом поддерживать несколько платформ!

N>Если тут нужно добавлять аж в два разных набора переменных, то это проблемы винды, а не питона.
Но не должен ли питон, заявляя кросс-платформенность, абстрагировать питониста от этой мерзости и обеспечить минимальное протекание этой абстракции?
Просто я винду и её траблы воспринимаю как данность, а питон как инструмент написания скриптов, избавляющих меня от этих подробностей.

MS>С/C++ еще более кроссплатформенные,
до первого #include "windows.h"

MS>на С/С++ еще больше библиотек.
Вот только там не pip install, а боль и страдания поддержки кучи зависимостей под все целевые платформы с помощью conan или иных витееватых систем.

Здравствуйте, Codealot, Вы писали:

C>Раз пошла такая пьянка — кто-нибудь может объяснить, что в питоне хорошего?

ИМХО крутость Питона в том, что на нем можно писать, не зная самого языка, и получается вполне сносно. Поэтому Питон и стал так популярен среди разного рода ученых, которые не особо утруждаются глубоким изучением языков программирования.

Здравствуйте, varenikAA, Вы писали:

Мне вот интересно почему ты решил, что MS забил на дотнет? Развивают питон хорошо, но и .Net и линукс развиваются полным ходом.
Зарабатывают то они на облаках.

Что касается асинков, то да дурость было сделать использовать контекс синхроницации по умолчанию. Нужно явно вызывать ConfigureAwait(true)
Или понавесить на класс атрибут типа Fody https://github.com/Fody/ConfigureAwait

yield и асинки суть одна, замена файберов то есть замкнуть переменные и запомнить состояние между MoveNext. С чем они прекрасно и справляются.
А подводные камни давно известны.

Здравствуйте, varenikAA, Вы писали:

A>>

A>>if (flag)
A>>{
A>>    ...
A>>}
A>>

A>>для IDE всё было бы очевидно. На C# пишешь, IDE форматирует сама. И если отформатировала неправильно, значит ты написал очевидную глупость — своего рода дополнительный контроль ошибок.

AA>К скобочкам привык, однако обратите внимание на то что глазам приходится переключаться после прочтения условия на первую скобку.
AA>в java форматирование более правильное if(1 == 1) { открывающая скобка на первой строке. аналогично скобки форматирует и F#

Это как привык. Строку с условием можно временно закомментировать или удалить, скобки остаются парные, код работает. Если они больше не нужны, то т.к. они парные, IDE может сама их убрать и всё заровнять как надо.

Здравствуйте, varenikAA, Вы писали:

AA>Здравствуйте, Ikemefula, Вы писали:

I>>Обоснуй уже эту правильность. При чем здесь лисп?

AA>в лиспе скобки обязательны. для if обязательно наличие обеих веток.

Ты как то ожидаемо отвечаешь на половину вопросов а остальные пропускаешь. Ты чтото утверждал про перевод взгляда. Выяснилось, что этот твой аргумент был невалидный. То есть, ни про какую правильность речи быть не может. А лисп ты притянул что бы можно было хоть чтото внятно сказать

Здравствуйте, kaa.python, Вы писали:

KP>Это не проблема, изучается крайне просто. Язык не более чем инструмент, важны базовые знания.
Сложный вопрос. Вот лично мне переходы даже между языками более-менее одной группы, типа C#/Java даются тяжело — потому что идиоматика существенно другая. И это — императивные ОО-языки со сборкой мусора.
Понятно, что code review часть проблем может решить, но для меня это означает, что первые пару недель весь мой код на "новом" языке придётся выкидывать и переписывать полностью.
Там, где в одном я буду просто прицеплять метод к событию, в другом мне придётся плодить анонимный интерфейс. И такого — очень много, как только мы выходим на шажок за пределы hello world.

То есть код-то, наверное, работать будет. Но это будет не идиоматический код.

Всё будет ещё хуже при переезде на какой-нибудь функциональный язык, где конструкции типа "добавить к массиву ещё один элемент" выполняются за O(log(N)), а не за O(N), как ожидает любой императивщик.

И даже после освоения базовых кирпичиков языка, остаётся ещё неизвестного размера стандартная библиотека. Которую нужно знать более-менее наизусть, чтобы не тратить по полчаса на stackoverflow лучшего способа прибавить время к дате (или скачать документ по http), а сразу писать код. То есть с переезом в новую экосистему эффективность работы снижается в разы.

Это — мой личный опыт. Помню, как я переходил с java на С# — причём это был C#2, без большинства тех штук, которые его от жавы отличают. Ну ведь невозможно вспомнить тот код без слёз.
Ушло примерно год-полтора на то, чтобы начать думать на C#.

В обратную сторону сейчас переходить — займёт примерно столько же.

Поэтому мне не близок ваш оптимизм по поводу перехода между Go с его каналами и С# с его TPL. Ну, то есть если человек плохо умеет на Go — то есть медленно пишет неэффективный, избыточный код и велосипедит стандартные вещи, то переход на C# его не сильно испортит — он просто продолжит писать неэффективный, избыточный код и велосипедить стандартные вещи. Если же это был нормальный разработчик, который при постановке задачи сразу в голове видит примерный код, который ему надо только записать, то переезд на новый язык сделает его в десяток раз менее эффективным.
Наверное, вы говорите о каких-то мега джедаях, которые способны за неделю-две, пусть даже и с помощью коллектива, изучить совершенно новый для себя язык вместе с его набором библиотек так, чтобы сразу думать на нём.
Увы, я к таким не отношусь, и своими глазами таких никогда не видел.

Здравствуйте, Ilya81, Вы писали:

C>>>Раз пошла такая пьянка — кто-нибудь может объяснить, что в питоне хорошего?
B>>На нем удобно писать скрипты. Простой мощный язык + куча библиотек + рецепты для всего на свете.
B>>Делать на нем большие проекты уже не так удобно, но некоторые делают.
I>Чем удобнее, чем на C# или Swift?

Скрипты-то? Гораздо удобнее. Он ведь интерпретируемый и динамический, да еще с кучей библиотек для всего на свете.

С C# или Swift дела не имел, но думаю, что на них тоже удобно. Просто чуть дольше и порог вхождения выше.

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Basil2, Вы писали:

B>>Простой мощный язык

C>В чем это заключается?

Конструкции языка несложные, но выразительные. Плюс куча библиотек для всего на свете.

Здравствуйте, Sinclair, Вы писали:

Идиоматика и стандартная библиотека — это ещё полбеды. Хуже, что код нужно иначе декомпозировать на другом языке, то есть иначе думать на языке. Для того, чтобы это понять и уложить в голове, нужно смотреть как на новом языке пишутся разные крупные проекты, понять почему они именно так пишутся и разложить это у себя по полочкам. А на это необходимы месяцы тяжелой работы, как бы не годы. Ну то есть если ты джун и копаешь от забора и до обеда, то действительно пофиг какой лопатой копать. Но если уровнем выше, где надо самому декомпозировать задачи, то тут другой разговор.

Здравствуйте, Sinclair, Вы писали:

S>Понятно, что code review часть проблем может решить, но для меня это означает, что первые пару недель весь мой код на "новом" языке придётся выкидывать и переписывать полностью.
S>Там, где в одном я буду просто прицеплять метод к событию, в другом мне придётся плодить анонимный интерфейс. И такого — очень много, как только мы выходим на шажок за пределы hello world.

S>То есть код-то, наверное, работать будет. Но это будет не идиоматический код.

Альтернативы:
1 найти готового разработчика "под ключ", что бы умел все — домен, платформу/язык и стек технологий — шансы близки к нулю даже за большие деньги
2 найти полу-готового разработчика, которого надо научить домену — месяцы инвестиций, иногда годы

Вобщем, если нужно переучивать на другой стек это наименьшие потери. ​
Язык-платформа — побольше, но терпимо, т.к. нужно вникать не в платформу вообще, а в код конкретного проекта.
Домен — лидер по издержкам.

Собтсвенно, потому конторы регулярно предпринимают интервенции вида "переучим на scala/python/C#/go/нужное вписать" да еще и велком бонус предлагают, тип xxxx$ после испытательного срока.
Вот, глянь, может заинтересует https://dev.by/news/flo-scala-python?utm_source=yxnews&utm_medium=mobile