clojure, elixir. Из типизированных — F#, Scala. Good luck!
Вы, очевидно, не понимаете о чем идет речь. Почитайте как устроен конструктор запросов в EntityFramework.
Больше чем на c++/java/python
Мы тут вроде не сосисками меряемся. Я просто говорю о том, что бекенда на C# пишется довольно много. Это был контраргумент к
почему ни кто не торопится перевести бэкенд с java/c++/nodejs на C#
Потому что, наверное, мало кто в принципе занимается переводом тяжелого бекенда с фреймворка на фреймворк забавы ради. А так — как я и сказал. Бекенда на C# написано достаточно много, чтобы оценить все плюсы и минусы подхода. Если вам для дискуссии именно что надо "больше чем на X", то сочувствую.
благодаря отсутствию "убийц времени"
Гы. Молодой человек, если generic-и, наследование и перегрузка операторов убивают ваше время, то есть отличный выход. Готовы? Открываю тайну: не пользуйтесь ими. :) Не говоря уже о том, что сдуру можно и член сломать: если вы пользуетесь ими так, что они отнимают ваше время, а не экономят — то вы пользуетесь ими неправильно.
В типичных приложениях Гоу такие задачи решаются взаимодействием и интеграцией с сервером БД. Почитайте на досуге про шардинг и репликацию, ага?
Это вы-то меня будете шардингу учить? Спешу расстроить: после корпоративной системы документооборота с распределенными БД — вы меня точно шардингу не научите. Так или иначе шардинг и репликация даже близко ничего не имеет с распределенными транзакциями. Читайте, читайте что делает MSDTC и почему.
Начнем с того, что я его не знаю :) И учить ради того, чтобы проверить решает ли он мои задачи — смысла не вижу. Мне достаточно факта что никто из моих многочисленных знакомых на лиспе свои задачи (особливо — бизнес-задачи) не решает.
Спойлер: вся простота и красота гошечки (равно, кстати, как и nodejs) превращается в нещадное адище, когда вы понимаете что вам нужен координатор распределенных транзакций (который, кстати, в C# точно есть, насчет Java не скажу). Если вы с таким не сталкивались и считаете что проблема нерелевантна — расслабьтесь и примите как данность что вы просто пишете слишком простые вещи.
Любой ЯП умеет разобрать переданную лямбду на куски и транслировать в другой язык? Это какой такой ЯП так умеет кроме C# — покажите, я с радостью на него перейду. :)
Бекенда на C# написано как раз столько, что вам и не снилось. Самый известный — для stackoverflow и из русского — moedelo. Так что тут вы тоже ошибаетесь.
А гошечка… Ну если ваше приложение ограничивается 20-30 REST-методами для CRUD-а, то гошечка — выбор для вас, да. Как только надо сделать что-нибудь более сложное (e.g. интеграцию между несколькими сервисами, REST со сложной функциональностью, вытягивание выборки из БД по сложному запросу) — тут-то гошечка начинает только мешать и вот мои знакомые, например, с радостью съезжают с гошечки на C#, ибо как удобнее. :)
Есть. Однако это два разных инструмента для решения разных задач. В частности асинхронность — это работа исключительно через Thread Pool и потоки вы не контролируете, равно как и не можете настроить свой дизайн потоков в приложении. Она работает по модели "поставить в очередь задачу — присвоить коллбек — делать что-то другое пока задача выполняется". Многопоточность — она именно о том, чтобы 2 и более задач выполнялись одновременно, а вы имели возможность собирать результаты, получать уведомления из этих потоков и т.п.
Технически (на примере C#) асинхронный ввод-вывод, как уже было сказано ниже, реализуется через completion ports и не имеет ничего общего с тредами как таковыми. Отличие от многопоточности очевидно.
Вы это говорите человеку, который водиночку на голом TS без зависимостей написал фреймворк-контрол для датагридов, тесно интегрирующийся с MVC. Поверьте, я знаю о чем говорю. JS гораздо проще C#.
Я боюсь, вы очень мало знаете о C# чтобы судить о низком пороге входа. Если вы начинаете писать на C# с WinForms и перетаскивания компонент — то вы начинаете неправильно.
Вопрос был в пороге входа в язык. Как по мне, так сравнивать пороги входа в полноценный промышленный мультипарадигменный язык с JS, в котором бесконтекстную функцию воткни на страницу и она заработает — несколько бесперспективное занятие.
Вокруг VBS не было хайпа во-первых (кстати как и вокруг всего WSH, который существовал как внебраузерный скриптовый движок ооооочень задолго до nodejs), во-вторых — не было удобных инструментов отладки. Не было консоли, не было документации и уроков. Ну уроки — лишнее, согласен. Я кстати на VBS все же писал. Это было весело, но окружение как-то не располагало к глубокому изучению.
Просто стало очевидным что много потоков абсолютно не требуется для создания эффективных и масштабирующихся серверов и клиентов
Посмотрите исходники nodejs. Я мог не так понять, но вроде как он тупо берет новый поток из тредпула на любой асинхронный вызов. Если я понял правильно, то потоков этот подход создает еще больше, чем традиционные подходы. В остальном libevent и asio — это хорошо. Но делать на этом подходе АБСОЛЮТНО ВСЕ — несколько перебор.
Гробы-фреймворки
За Java не скажу, но С# весьма резво развивается. Новая версия языка выходит чуть ли не каждый год, а с открытием компилятора (Roslyn) — дискуссии по вопросу "что добавить в язык" идут чуть ли не ежедневно. При достаточной квалификации — можно сделать хоть свой билд компилятора и запилить туда все, что угодно. В NuGet-е каждый день появляется что-то новое. При том никакого уклона в хаос — в большинстве случаев скачанное прекрасно работает и выполнено идеологически в более-менее едином стиле. Достаточно заметить что асинхронность на completion ports (async/await) появились в C# несколько раньше чем в ES. Как и стрелочные функции, которые появились, например, еще до того как мир узнал что такое AngularJS. Так что кто быстрее развивается — я бы поспорил. И при том это не просто "фича для галочки" или Haskell-way — фича есть, но она сложная и поэтому ей никто не пользуется. Наоборот, все изменения внедряются на хорошем инженерном уровне и гармонично вливаются в язык.
Если смотреть с точки зрения поиска самого современного фреймворка с передовыми технологиями
Простите, а вам шашечки или ехать? В смысле вам нужен современный фреймворк просто чтобы иметь современный фреймворк, или вам все же надо решить вашу задачу наиболее быстрым и дешевым способом? Эти задачи несколько ортогональны.
Речь идет о вот этой технике работы.
Так и в Java/C# можно все скастить к object и далее к любому требуему типу. Но зачем?
Вы, очевидно, не понимаете о чем идет речь. Почитайте как устроен конструктор запросов в EntityFramework.
Мы тут вроде не сосисками меряемся. Я просто говорю о том, что бекенда на C# пишется довольно много. Это был контраргумент к
Потому что, наверное, мало кто в принципе занимается переводом тяжелого бекенда с фреймворка на фреймворк забавы ради. А так — как я и сказал. Бекенда на C# написано достаточно много, чтобы оценить все плюсы и минусы подхода. Если вам для дискуссии именно что надо "больше чем на X", то сочувствую.
Гы. Молодой человек, если generic-и, наследование и перегрузка операторов убивают ваше время, то есть отличный выход. Готовы? Открываю тайну: не пользуйтесь ими. :) Не говоря уже о том, что сдуру можно и член сломать: если вы пользуетесь ими так, что они отнимают ваше время, а не экономят — то вы пользуетесь ими неправильно.
Это вы-то меня будете шардингу учить? Спешу расстроить: после корпоративной системы документооборота с распределенными БД — вы меня точно шардингу не научите. Так или иначе шардинг и репликация даже близко ничего не имеет с распределенными транзакциями. Читайте, читайте что делает MSDTC и почему.
А то ж.
Нет, потому что я видел код на LISP и мне даже сложно предположить какие из моих задач он может теоретически решить.
Начнем с того, что я его не знаю :) И учить ради того, чтобы проверить решает ли он мои задачи — смысла не вижу. Мне достаточно факта что никто из моих многочисленных знакомых на лиспе свои задачи (особливо — бизнес-задачи) не решает.
Все остальные задачи написания околобухгалтерской бизнес-логики. Опердень такой опердень.
LISP — отдельная тема. На нем, вероятно, удобно решать означенную задачу. А вот все остальные — нет :)
BTW, знавал людей, которые в таком окружении умудрились сделать подключение к БД синглтоном. А вы говорите...
Спойлер: вся простота и красота гошечки (равно, кстати, как и nodejs) превращается в нещадное адище, когда вы понимаете что вам нужен координатор распределенных транзакций (который, кстати, в C# точно есть, насчет Java не скажу). Если вы с таким не сталкивались и считаете что проблема нерелевантна — расслабьтесь и примите как данность что вы просто пишете слишком простые вещи.
Любой ЯП умеет разобрать переданную лямбду на куски и транслировать в другой язык? Это какой такой ЯП так умеет кроме C# — покажите, я с радостью на него перейду. :)
Бекенда на C# написано как раз столько, что вам и не снилось. Самый известный — для stackoverflow и из русского — moedelo. Так что тут вы тоже ошибаетесь.
А гошечка… Ну если ваше приложение ограничивается 20-30 REST-методами для CRUD-а, то гошечка — выбор для вас, да. Как только надо сделать что-нибудь более сложное (e.g. интеграцию между несколькими сервисами, REST со сложной функциональностью, вытягивание выборки из БД по сложному запросу) — тут-то гошечка начинает только мешать и вот мои знакомые, например, с радостью съезжают с гошечки на C#, ибо как удобнее. :)
Есть. Однако это два разных инструмента для решения разных задач. В частности асинхронность — это работа исключительно через Thread Pool и потоки вы не контролируете, равно как и не можете настроить свой дизайн потоков в приложении. Она работает по модели "поставить в очередь задачу — присвоить коллбек — делать что-то другое пока задача выполняется". Многопоточность — она именно о том, чтобы 2 и более задач выполнялись одновременно, а вы имели возможность собирать результаты, получать уведомления из этих потоков и т.п.
Технически (на примере C#) асинхронный ввод-вывод, как уже было сказано ниже, реализуется через completion ports и не имеет ничего общего с тредами как таковыми. Отличие от многопоточности очевидно.
Как-то так.
Вы это говорите человеку, который водиночку на голом TS без зависимостей написал фреймворк-контрол для датагридов, тесно интегрирующийся с MVC. Поверьте, я знаю о чем говорю. JS гораздо проще C#.
Ну вам по ходу дела бессмысленно объяснять про деревья выражений, LINQ и where-констрейнты в C# :) Спите спокойно: C# убог
И я вам очень сочувствую.
Я боюсь, вы очень мало знаете о C# чтобы судить о низком пороге входа. Если вы начинаете писать на C# с WinForms и перетаскивания компонент — то вы начинаете неправильно.
Дык и сумасшествия поголовного тогда не возникало. Претензий к JS до '10х годов у меня вообще нет.
У меня в принципе нет претензий к технологиям. А вот к сообществу — таки есть, да. :)
Вопрос был в пороге входа в язык. Как по мне, так сравнивать пороги входа в полноценный промышленный мультипарадигменный язык с JS, в котором бесконтекстную функцию воткни на страницу и она заработает — несколько бесперспективное занятие.
Вокруг VBS не было хайпа во-первых (кстати как и вокруг всего WSH, который существовал как внебраузерный скриптовый движок ооооочень задолго до nodejs), во-вторых — не было удобных инструментов отладки. Не было консоли, не было документации и уроков. Ну уроки — лишнее, согласен. Я кстати на VBS все же писал. Это было весело, но окружение как-то не располагало к глубокому изучению.
Асинхронность и многопоточность — разные вещи. Как технически, так и с точки зрения дизайна.
Посмотрите исходники nodejs. Я мог не так понять, но вроде как он тупо берет новый поток из тредпула на любой асинхронный вызов. Если я понял правильно, то потоков этот подход создает еще больше, чем традиционные подходы. В остальном libevent и asio — это хорошо. Но делать на этом подходе АБСОЛЮТНО ВСЕ — несколько перебор.
За Java не скажу, но С# весьма резво развивается. Новая версия языка выходит чуть ли не каждый год, а с открытием компилятора (Roslyn) — дискуссии по вопросу "что добавить в язык" идут чуть ли не ежедневно. При достаточной квалификации — можно сделать хоть свой билд компилятора и запилить туда все, что угодно. В NuGet-е каждый день появляется что-то новое. При том никакого уклона в хаос — в большинстве случаев скачанное прекрасно работает и выполнено идеологически в более-менее едином стиле. Достаточно заметить что асинхронность на completion ports (async/await) появились в C# несколько раньше чем в ES. Как и стрелочные функции, которые появились, например, еще до того как мир узнал что такое AngularJS. Так что кто быстрее развивается — я бы поспорил. И при том это не просто "фича для галочки" или Haskell-way — фича есть, но она сложная и поэтому ей никто не пользуется. Наоборот, все изменения внедряются на хорошем инженерном уровне и гармонично вливаются в язык.
Простите, а вам шашечки или ехать? В смысле вам нужен современный фреймворк просто чтобы иметь современный фреймворк, или вам все же надо решить вашу задачу наиболее быстрым и дешевым способом? Эти задачи несколько ортогональны.