Здравствуйте, wl., Вы писали:
wl.>решил зачем-то запустить skype for business (который с офисом ставится) — фиг там, скачайте teams, wl.>похоже скайп окончательно догнил
Это другой скайп. Вообще другой и ничего общего с собственно скайпом не имеющий. Только имя похожее. Оно раньше Lync называлось, потом после покупки скайпа переименовали в skype for business.
Просмотрел все изменения в 7.2 и 7.3 — не увидел ничего существенного. Какие-то мелкие правки, исправляющие старые косяки (это всё можно было сделать ещё в версии 1.0) в целях производительности.
Для примера посмотрел на изменения в 7.0 и вот там увидел несколько вполне интересных изменений (хотя тоже не сказать чтобы революционных).
S>>>RuyJIT, _>>Помнится игрался (кода запускал тесты на быстродействие) с ним ещё несколько лет назад. И кстати эффект был, но слабенький. S>В том-то и дело, что в него активно коммитят. Недавние улучшения поддержки Span<T>, а также поддержка SIMD.
Ммм, так SIMD же там вроде изначально был, не? Я собственно ради тестирования этого момента его и ставил когда-то.
_>>Скорее напоминает оптимизацию расходов на неактуальное направление. ))) S>"Оптимизация расходов" обычно выражается в резком снижении количества коммитов.
Не обязательно. Сброс продукта в опенсорс вполне может вызвать и увеличение количества коммитов, если у продукта много фанатов.
Здравствуйте, kaa.python, Вы писали:
_>>Вот ты вроде бы действительно в курсе C++, а такую ерунду пишешь. KP>Да не пишу я ерунду, я говорю о текущей ситуации которая мне не нравится, всё же меня C++ уже почти 20 лет кормит и надеюсь что и дальше будет
У C++ сейчас всё хорошо (хотя есть некие вопросы к комитету, принимающем всякую ерунду и тормозящего самое важное, но всё равно не плохо) и кормить он будет и дальше, при условие что ты будешь оставаться в тренде актуальных в IT вещей, использующих C++ (т.е. грубо говоря специалист умеющий только MFC действительно может печалиться).
KP>Если ты, к примеру, глянешь на тренды в мире C++ за последний месяц, то ничего кроме ML та там не увидишь по большому счету: математика и числомолотлки, фсё . Я как раз об этом и говорил изначально: "крайне редко про новые, молодые и активно развиваемые проекты". Можешь сравнить с трендами в Python, Go, Rust, просто обрати внимание что в тренде.
Ты вот постоянно смешиваешь в качестве примера 3 совершенно разных языка, существующих для абсолютно разных ниш. Давай разберём их по отдельности:
1. Python. Очень популярный скриптовой язык общего назначения, используемый для очень большего числа задача. Максимально развиваемое сейчас направление (ML) — как раз одно из максимально актуальных для C++.
2. Go. Компилируемый язык со сборщиком мусора, популярный преимущественно в одной области (web бэкенд, сервисы и т.п.). Причём это одна из редких активно развиваемых в данное время областей, в которых C++ практически не используется (кроме компаний типа Гугла и Яндекса), а конкурентами являются Java/C#. Соответственно эти два языка (C++ и Go) живут в полностью параллельных вселенных и даже сравнивать их странно.
3. Rust. Компилируемый язык с прямым доступом к железу — по сути прямой конкурент C++, пытающийся стать его заменой. Понятно что язык очень активно развивается, в силу своей молодости. Однако всё это развитие связано в основном с восполнением дыр в инфраструктуре, а не с какими-то инновациями в прикладных областях. При этом я не слышал про серьёзные проекты на Rust (ну кроме движков Firefox) — большинство предпочитает брать старый добрый C++. Возможно когда-нибудь это и изменится (и Rust всё же заменит C++), но пока что нет даже малейших намёков на это.
Цветёт и пахнет!
Растёт число репозиториев и разработчиков, где ожидаемый отток? В целом похоже, что open source побеждает (вряд ли победит, но доминирует). "Умирающий" С++ также не сдаёт позиции, что бы не лаяли про труп страуса. Короче, просто хорошая новость.
Здравствуйте, Nuzhny, Вы писали:
N>Цветёт и пахнет! N>Растёт число репозиториев и разработчиков, где ожидаемый отток? В целом похоже, что open source побеждает (вряд ли победит, но доминирует). "Умирающий" С++ также не сдаёт позиции, что бы не лаяли про труп страуса. Короче, просто хорошая новость.
я все правильно понял, на мелкософтовском ресурсе плюсы обогнали шарп?
Здравствуйте, so5team, Вы писали:
S>Вот как-то так получается, что вроде как есть (по словам на форуме) крутые и небольшие разработки
Эээ. А что в HTTPS геттере такого крутого? Там только с TLS повозиться надо а так сам по себе базовый функционал HTTP GET простой как бревно. HTTP протокол появился в 1991м, тогда всё было просто.
S> которые, кроме их авторов никто не видит и переиспользовать не может.
Ну я софт который для себя пишу никуда не выкладываю, просто потому что не хочу. Иногда со знакомыми какими нить сурсами делюсь если они им полезны, но паблисити меня не интересует совершенно никакая.
S>А в публичном доступе есть тот же libcurl, который древний и большой, но использован в таком большом количестве сценариев, что и вообразить сложно.
Я кстати перед тем как написать свой сперва скачал курл и в него посмотрел, ужаснулся, почитал спеки, ужаснулся уже от того как в курле всё переусложнено, написал свой, прифигел что на деле оказалось ещё на порядок проще.
S>Поэтому когда у человека, далекого от HTTP, возникает задача сделать исходящий HTTP-запрос
Всё что тебе надо для HTTP — это чутка почитать RFC, написать на сокетах простейшую отправлялку и принималку, формирование текста запроса на отправку, и разбор текстового ответа.
В винде вон вообще WinHTTP есть встроенный.
S>Что не отменяет того факта, что у кого-то где-то может быть собственная наколенная разработка намного лучшего качества.
Здравствуйте, alex_public, Вы писали:
_>2. Для какой ниши создан движок node.js? Ответ: бэкенд.
node.js создан для весьма узенькой ниши бэкэнда — наколенной, медлительной и не образующей большой сетки/экосистемы/кластеров.
Это чтобы можно было какой-нить несложный сервис за пол-дня озвучить.
Ничего серьёзного на node.js нет и не будет.
Не, кластеризация для node.js в природе существует, и даже более-менее работает на некоторых сборках линухов, но для серьёзного применения не рекомендуется. ))
_>3. Инструменты для какого бэкенд-движка активно развивают MS внутри своего основного инструмента для разработчиков? Ответ: node.js.
Ответ: MS SQL, ASP .NEt Core и т.д..
В общем, семество Azure сервисов.
В этом смысле node.js — лишь малая часть такого семейства.
ASP MVC идёт для сложных решений, node.js для простых или просто желающих.
_>Уже можешь сам выводы сделать или всё ещё нет? )
Учитывая новомодные тег-хелперы + Разор, теперь на полноценом ASP MVC что-то несложное но полноценное за пол-дня тоже можно сделать.
Т.е. эта технология уже наступает ноде на пятки.
ИМХО, взять тот же VS Code — если бы на момент начала разработки этой технологии уже был .Net Core в современном виде, то ни о каком node.js-бэкенде этого редактора речи бы не было. Там слишком большой разрыв в возможностях технологий.
_>TS очевидно не вместо Шарпа или чего-то ещё. Он вообще не "вместо", а "для" — для развития платформы JS. Только вот если взглянуть на темпы развития TS (которым рулит MS) и C# (которым так же рулит MS), то тоже можно очень быстро сделать очевидные выводы.
Из первых рук (моих).
Тоннами запросы от клиентов на перевод наших продуктов на .Net Core под Линуха.
_>Вот даже не смешно уже видеть подобное на форуме. Я про данные тенденции писал здесь ещё несколько лет назад и тогда многочисленные фанаты C# натужно смеялись в этих дискуссиях. В последнее время смех куда-то делся и у части из них появились обречённые нотки
Похоже, весь 18-й год ты вопросом не интересовался.
Собсно, с версии 2.1 и версии языка C# 7.3, можно смело утверждать, что в дотнете началась новая эра.
Кароч, там всё по-другому теперь.
С этими новыми Span<> + Memory<>/MemoryManager я с минимальными изменениями за весьма короткий срок портировал под 400к осмысленных строк плюсового кода.
До 80% всей работы получилось сделать через глобальную замену регесами. ))
Пара трюков, кратко:
1. Свой бэкенд для класса Memory:
При том, что сам объект UnmanagedMemory перемещаемый в управляемой куче, но указуемая им память фиксированная, что позволило портировать string_view вместе со всей обвязкой. Неуправляема память жива до тех пор, пока жив хотя бы один ссылающийся на неё объект, это реализовано в порождаемом через MemoryManager объекте Memory<>.
Весь ввод-вывод теперь доступен через Span<byte>, поэтому можно больше не оперировать дотнетными массивами.
В общем, где раньше у меня был код с нейтивными указателями и всякими графами объектов на них в плюсах, он такой и остался.
Потому что теперь такой код заходит архигладко в остальной дотнетный код.
И эффективность примерно та же.
2. "Compile-time" трейты:
interface IConstant<T> { T Value { get; } }
static class SomeOptions {
public struct Option1 : IConstant<bool> { public bool Value => true; }
public struct Option2 : IConstant<bool> { public bool Value => false; }
}
class SomeClass<TOption> where T : struct, IConstant<bool> {
public void SomeMethod() {
if(default(TOption).Value)
DoA();
else
DoB();
}
}
...
SomeClass<SomeOptions.Option1> _someVar = Get(...);
_someVar.SomeMethod();
Из релизной сборки ветвление уходит.
Показал в простейшем варианте, но суть понятна, думаю.
3. Компиляция в самодостаточный деплой (не требуется предварительная установка дотнета).
4. Компиляция конечной приложухи в нейтив.
_>а другую часть я постоянно замечаю за хвалебными отзывами о JS/TS.
Это всё хомячки.
В этой реальности не существует достаточно больших проектов, писанных на TS.
Единственный — это VS Code, но и тот тулзовой направленности, да еще и клиентская часть онли. ))
_>И только редкие непробиваемые динозавры типа тебя продолжают игнорировать реальность и делать вид что ничего не изменилось в политике MS за последние пять лет.
Изменилось сильно, только чуть не так, как ты рассказываешь.
Торговля инструментами под node.js — это примерно того же порядка явление, как в специализированном алкомаркете еще продают соки и воду.
Чтобы клиентам не было надобности идти еще в другой магазин.
N>>Глянь как новые библиотеки и инструменты активно рождаются для Go, Rust да даже Python.
Делаешь такой pip install ... и вдруг запускается компиляция плюсового когда. У тебя очень поверхностное и неправильное ощущение смерти языка С++.
Здравствуйте, Danchik, Вы писали:
D>>>Питон? У него своя ниша — что-то быстрее для разработки на линухах. После плюсов это просто отдушина, а для математиков сребрянная пуля. В серьезном проекте заметно снижение производительности разработчиков ибо трогать уже опасно, рефакторить стремно. _>>Ты всё верно написал, за исключением упоминания Линуха. Причём тут он и Питон? К примеру я занимаюсь разработкой исключительно на Винде (под множество разных платформ) и при этом у меня из каждого угла торчит Питон. D>Ноги оттуда. Плюсовики в основном на него прыгают и комфортно себя чувтсвуют на минуточку на интерпретируемом языке! Это не ты мне тут про такты генерации сиквела диферамбы пел? Об чудовищной рефлексии?
Так а я и не использую Питон там, где требуется хоть какое-то быстродействие. Однако у меня имеется множество мест, где быстродействие не принципиально, а вот скорость и удобство написания кода очень чувствуется.
D>>>Go? Вот и это я тоже считаю высером для линукса, в котором library hell породил решения на докерах. Куда они дели дженерики... _>>А вот Go, являясь "оптимизированным под бэкенд" языком, является прямой угрозой Java и C# в одной из их ключевых областей. И да, опять же Go никак не завязан на Linux. D>Все оттуда, от того же линуха. Монолитные исполняемые модули — убрать зависимость от толпы опенсорсных либ.
Вообще то этот подход как раз напрямую противоречит линуксовой философии, в которой каждому приложению полагается иметь множество разделяемых библиотек, с версиями управляемыми менеджером пакетов дистрибутива. А вот под windows мало кого удивишь статически скомилированным приложением (у которого зависимости только к win api). Так что это скорее наоборот, виндовый подход, который пролил луч света в кривом линуксовом мире. )))
D>Как язык он убог.
Конечно. Но PHP в момент захвата им рынка был ещё более убог (да и собственно сейчас не стал сильно лучше), однако это ему не помешало. Простота+специализация — это убойное сочетание.
D>>>Rust? Писать на нем иногда может быть посложнее плюсов. Сложность увеличивается с каждым релизом. _>>С учётом направления и темпов развития C++ в последние годы, лично я потерял прямой интерес к Rust'у. Однако посматриваю за его развитием краем глаза. Подозреваю, что множество коллег по C++ (потенциальная целевая аудитория Rust'а) придерживается аналогичной позиции. Но к аудитории пользователей C# это всё вряд ли имеет какое-то отношение — вообще разные миры. D>На плюсах писать все что ты там сверу упомянул об Go — это мозахизмом заниматься вместе с Шериданом.
А где ты видишь, что бы я писал об использование C++ для написания бэкенда? Хотя это и не мазохизм, а просто нужная только очень специфическим компаниям (Гугл, Яндекс и т.п.) задача. Я как раз сказал, что C++ вне этого рынка (за редкими, хотя и жирными исключениями), так что не конкурент C#/Java/Go в этой области. Так же как и Rust.
_>>А вот JS сейчас активно пихают как раз в ниши C#. Причём что самое главное: один из главных "пихателей" — это MS (автор C#). Глядя на такую картину, только твердолобый фанатик может остаться верным C#... ))) D>Они JS пихают куда надо. Спасибо за еще одни «познания», он еще и автор Turbo Pascal, Delphi, но он пихает TypeScript, типизированный JS. И я за него рад — человек занимается любимым делом, разрабатывает новые языки.
Я вообще то имел в виду не Хейлсберга, а именно Microsoft, как компанию "владельца" (в смысле управляющая его развитием) C#. Если такая компания начинает делать ставку на другой язык, то это вызывает очень большие сомнения в будущем первого.
D>Хипстеров расплодилось... не о тебе, но все же и Go и JS и Питон я считаю языками с которых начали на хайпе и спрыгивать не хотят.
Совершенно разные языки ты перечислил:
1. Питон — это универсальный скриптовой язык. Наверное лучшие в данной области. Который годами зарабатывал себе репутацию во множестве разных ниш. И в некоторых стал стандартом де факто. Причём полностью заслуженно и совсем не рывком, а плавно (без всякого хайпа), за множество лет развития соответствующих инструментов (посмотри например год первого выпуска библиотечки numpy, на которой основано современное царствование Питона сразу в нескольких популярных областях).
2. JS — изначально убогий и сильно специализированный (удобен для встраивания) скриптовой язык, который сумел заиметь огромную армию пользователей благодаря своему монопольному положению в браузерах. Плюс к этому, благодаря тому же положению в браузерах 10 лет назад этот язык заполучил сильно оптимизированный движок (сейчас быстродействие JS не сильно отличается от Java/C#/Go, что его выгодно отличает от большинства других скриптовых языков), который в сочетание с удобством встраивания языка привёл к популярности встраивания JS в качестве скриптового языка во многие большие (написанные обычно на C++ проекты). Ну а дальше из сочетания армии дешёвых программистов и быстрого, легко встраиваемого движка, пошло уже распространение на не особо подходящие ниши типа бэкенда (Node.js), десктопа (Электрон), мобилок (Кордова) и т.д. и т.п. Плюс к этому в последние годы сам язык пытаются слегка исправить с помощью выхода новых стандартов (хотя кривое от рождение исправить трудно). И да, тут поднялся большой хайп (в котором кстати MS принимает очень активное участие). Но говорить о том, что JS поднялся благодаря хайпу всё же не верно. Скорее благодаря ему он стал проникать в несвойственные ему ниши.
3. Go — простой, компилируемый в нативный код, язык со статической типизацией, с изначальной специализацией на написание бэкендов/сервисов и т.п. Да, язык активно пиарится Гуглом, но какого-то особого хайпа вокруг него не видно. В своей родной нише он изначально неплохо себя показал и планомерно отгрызает (преимущественно у Java/C#) себе жизненное пространство. Возможно в последние годы он стал более заметен на рынке и из-за этого кажется что появился какой-то хайп.
А вот язык целиком существующий в данный момент на хайпе — это уже упоминаемый тут Rust. Огромная "теоретическая" популярность при почти полном отсутствие (не считая движков в FF, написанных опять же создателями языка) реальных проектов — это именно хайп и если он вдруг пропадёт, то язык сразу сдуется до состояния D и ему подобных.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В винде для ссерверной части есть http.sys, который...
... не имеет отношения к клиентской HTTP GET, которая обсуждается в этой ветке
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>В винде для ссерверной части есть http.sys, который... CC>>... не имеет отношения к клиентской HTTP GET, которая обсуждается в этой ветке НС>В этой ветке обсуждается curl.
http.sys точно так же не имеет к нему отношения
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, so5team, Вы писали:
S>>Вот как-то так получается, что вроде как есть (по словам на форуме) крутые и небольшие разработки CC>Эээ. А что в HTTPS геттере такого крутого? Там только с TLS повозиться надо а так сам по себе базовый функционал HTTP GET простой как бревно. HTTP протокол появился в 1991м, тогда всё было просто.
Эмм... А ваш "геттер" умеет хотя бы фолловить редиректы? Как насчёт докачки (Range Header)? Что с поддержкой GZIP encoding? Conditional get осилит? Есть ли встроенная поддержка content-disposition:attachment?
Multiline и Binary хидеры декодировать умеет? Это так, первое, что в голову.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Даже так? ) Ну расскажи тогда, развитие какого инструмента для Шарпа в последнее время ты считаешь аналогом по значимости развитию TS (это же инструмент для JS не так ли? И создан MS, правильно?) ? S>C# 7.2/7.3,
И что там нового? )
S>RuyJIT,
Помнится игрался (кода запускал тесты на быстродействие) с ним ещё несколько лет назад. И кстати эффект был, но слабенький.
S>.Net Core.
А тут то что? Там не то что нового, а даже старого целиком нет (не смогли сделать весь .net кроссплатформенным и взяли только некий кусок).
S>Там реально начался наконец-то движняк, видный невооружённым глазом.
Скорее напоминает оптимизацию расходов на неактуальное направление. )))
Здравствуйте, alex_public, Вы писали: _>И что там нового? ) https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/
Кратко: дофига. S>>RuyJIT, _>Помнится игрался (кода запускал тесты на быстродействие) с ним ещё несколько лет назад. И кстати эффект был, но слабенький.
В том-то и дело, что в него активно коммитят. Недавние улучшения поддержки Span<T>, а также поддержка SIMD. S>>.Net Core. _>А тут то что? Там не то что нового, а даже старого целиком нет (не смогли сделать весь .net кроссплатформенным и взяли только некий кусок).
Видны бешеные темпы развития. Смотреть надо не на "старое", хотя его портирование идёт полным ходом, а на то, что все импрувменты сейчас в первую очередь попадают в Core, а уже потом бэкпортятся в основной фреймворк. _>Скорее напоминает оптимизацию расходов на неактуальное направление. )))
"Оптимизация расходов" обычно выражается в резком снижении количества коммитов. Пока что виден строго обратный эффект: 15 лет нас кормили обещаниями вроде "ну, потенциально JIT может быть способен на бла-бла-бла", на практике имея zero-to-none улучшений. А сейчас и язык, и джит, и экосистема развиваются очень активно, и, я бы сказал, интерактивно. Раньше мы могли следить за процессом только постфактум из блогов Липперта (в основном — в стиле "почему мы не сделали фичу X"), и иногда подсматривать в будущее на MVP саммитах. Теперь всё обсуждение открыто идёт в гитхабе, и можно даже влиять на процесс разработки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>>>Посмотри внимательнее на свою же цитату — это ты перешёл от движков бэкенда (у .net это будет ASP) НС>>Чего вдруг ты бэк ASP ограничил? _>А для .net есть какие-то ещё популярные движки бэкенда?
Для дотнета не обязателен какой то особенный "движок бэкенда". У меня, к примеру, значительная часть кода это обычные windows сервисы/линуксовые демоны. ASP.NET имеет смысл только на самом верхнем слое бэка, который REST отдает.
_>>>Так MS в последнее время активно помогает выбрать именно node.js для написания бэкенда. ))) НС>>Где он именно ноду помогает?
_>Эм, вообще то вся наша дискуссия прямо про это.
Эм, вообще то нет. То что МС поддержал ноду не означает, что он предлагает ее выбирать вместо шарпа. Основная аудитория этих инструментов — те кто уже использует ноду. И шарпу это скорее помогает, чем мешает. Люди подсаживаются на VS, а потом, когда и если наступает осознание убогости JS, под боком есть нормальное решение.
Помнишь 15 лет назад такая штука была, J#? Вот та же самая история и с нодой.
Чтобы действительно речь зашла о вытеснении, нужно чтобы МС либо что то крупное переводил с шарпа на ноду, при этом переключая шарповый вариант в режим поддержки, либо хотя бы что то на ноде стартовало очень крупное без аналога в шарпе. Пока таких фактов не будет, говорить ни о каком вытеснении нельзя.
НС>>Там знаешь сколько таких инструментов? Одно время даже для php было. МС, как обычно, придерживается оппортунистической стратегии, поддерживает то, что уже популярно. При этом инструментарий для шарпа на две головы круче инструментария для JS/TS _>Ты говоришь про какие-то сторонние модули для VS или про официальные модули написанные MS и рекламируемые на странице VS? Если речь про второе, то я что-то не припомню такого для PHP...
Не VS, IIS — https://php.iis.net/
Если же говорить именно про полного аналога ноды — есть поддержка Питона. Официальная, входящая в поставку студии.
НС>>Только это никак не доказывает, что все это вместо шарпа. _>Повторяю по буквам: ОНО ДЛЯ БЭКЕНДА.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Sinclair, Вы писали:
S>>Эмм... А ваш "геттер" умеет хотя бы фолловить редиректы? CC>Умеет, но я выключил и спецом репорчу редирект.
S>> Как насчёт докачки (Range Header)? CC>Технически да, а практически я забил: ни один сайт откуда мне надо тягать данные ranges не юзает а искать спецом на чём протестировать мне было влом. Я ж решал свою практическую задачу.
S>> Что с поддержкой GZIP encoding? CC>Забил болт по причине выше.
S>> Conditional get осилит? CC>Same
Всё понятно. Вы воспользовались либеральностью HTTP и его graceful degradation. По факту, большинство современных источников данных умеют всё вышеперечисленное, но для того, чтобы им воспользоваться, клиент должен быть умным.
Например, если к нему пристёгнут локальный кэш с поддержкой частичных результатов, то клиент мог бы сэкономить своё время и время сервера, отправляя нужные хидеры.
Обманчивая простота HTTP — в том, что тупой клиент пишется очень быстро. И он даже будет работать корректно с практически любым сервером.
А вот написать клиента, который бы работал эффективно, требует вложений. Не отдали вы серверу хидер Accept-Encoding: gzip — и всё, он вам шлёт несжатые данные.
А вам кажется, что "да мне и не предлагают".
S>> Есть ли встроенная поддержка content-disposition:attachment? CC>Есть, но опять таки протестил только отправку POST с аттачментами — никто мне нужный аттачи не шлёт.
То есть прямо ни один из источников не реализует фичу "скачать в виде файла"? Повезло. CC>А кто binary hdr шлёт?
По RFC — можно. По факту — хз, давно не занимался вопросом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kaa.python, Вы писали:
TSP>>Делаешь такой pip install ... и вдруг запускается компиляция плюсового когда. У тебя очень поверхностное и неправильное ощущение смерти языка С++. KP>Ну да, расскажи мне про C++ Ты говоришь про небольшое подмножество Си, реже C++ динозавров и крайне редко про новые, молодые и активно развиваемые проекты. Особенно чётко эта тенденция прослеживается в Open Source, где народ выбирает то, на чем интереснее и/или проще писать, а не корпоративная политика навязала.
Вот ты вроде бы действительно в курсе C++, а такую ерунду пишешь. Как раз Питон тем и нравится всем, что можно писать на лёгком языке в удобном интерактивном блокноте, а при этом реальные вычисления делает быстрый C++ код. И это касается не только старых классических проектов типа numpy и т.п. компании, но и совсем новых библиотек, в областях, которые находятся на самом пике популярности. Вот посмотри например на чём написана библиотека LightGBM. И таких примеров ещё множество, в самых "горячих" сейчас областях.
Что касается Rust'а, то там вполне естественен бурный рост библиотек, т.к. язык очень новый и там надо банально заполнять пустоту. Если ты действительно хочешь провести какой-то сравнительный с C++ анализ развития/популярности, то тогда надо посмотреть имеется ли на Rust'е хоть одна библиотека, аналогов которой нет на C/C++ (ну естественно не учитывая библиотеки созданные для решения каких-то внутриязыковых проблем). Обратных примеров естественно можно привести множество, но это пока ни о чём не говорит, в силу молодости Rust'а. А вот если на нём появится много интересных решений, у которых нет никаких аналогов в C/C++, то тогда действительно можно будет говорить о существенном перетоке популярности к Rust'у.
Здравствуйте, kaa.python, Вы писали:
KP>Если ты, к примеру, глянешь на тренды в мире C++ за последний месяц, то ничего кроме ML та там не увидишь по большому счету: математика и числомолотлки, фсё .
Здравствуйте, СоколОрлов, Вы писали:
СО>Здравствуйте, jazzer, Вы писали:
J>>я все правильно понял, на мелкософтовском ресурсе плюсы обогнали шарп?
СО>Что-то этот шарпец не жилец, а сколько было амбиций при создании..
А кто супер жилец? Жава? Которую тот же Котлин начал вытеснять с мобилок. Застоялась жавав, очень сильно.
Питон? У него своя ниша — что-то быстрее для разработки на линухах. После плюсов это просто отдушина, а для математиков сребрянная пуля. В серьезном проекте заметно снижение производительности разработчиков ибо трогать уже опасно, рефакторить стремно.
Go? Вот и это я тоже считаю высером для линукса, в котором library hell породил решения на докерах. Куда они дели дженерики...
Rust? Писать на нем иногда может быть посложнее плюсов. Сложность увеличивается с каждым релизом.
Также давайте не будем перечислять еще толпу динамических языков, которые я бы в сложном проекте никогда не использовал.
Так почему же не C#? Мне UI сейчас на линухах ни к чему. Работает, удобен, стандартные либы просто вершина продуманности и перформанса. Новые плюшки языка появляющиеся не реже года и радуют мой глаз, сокращая рутинные проверки.
Здравствуйте, Danchik, Вы писали:
СО>>Что-то этот шарпец не жилец, а сколько было амбиций при создании.. D>А кто супер жилец? Жава? Которую тот же Котлин начал вытеснять с мобилок. Застоялась жавав, очень сильно.
Kotlin вообще то входит в инфраструктуру Жабки) Так же как и Scala. Т.е. это приблизительно как F# должен был развиваться платформу .net, при этом не являясь конкурентом C#. Только вот у F# не сложилось с популярностью, а вот у Scala вполне ничего так. А теперь похоже ещё и у Kotlin.
D>Питон? У него своя ниша — что-то быстрее для разработки на линухах. После плюсов это просто отдушина, а для математиков сребрянная пуля. В серьезном проекте заметно снижение производительности разработчиков ибо трогать уже опасно, рефакторить стремно.
Ты всё верно написал, за исключением упоминания Линуха. Причём тут он и Питон? К примеру я занимаюсь разработкой исключительно на Винде (под множество разных платформ) и при этом у меня из каждого угла торчит Питон.
D>Go? Вот и это я тоже считаю высером для линукса, в котором library hell породил решения на докерах. Куда они дели дженерики...
А вот Go, являясь "оптимизированным под бэкенд" языком, является прямой угрозой Java и C# в одной из их ключевых областей. И да, опять же Go никак не завязан на Linux.
D>Rust? Писать на нем иногда может быть посложнее плюсов. Сложность увеличивается с каждым релизом.
С учётом направления и темпов развития C++ в последние годы, лично я потерял прямой интерес к Rust'у. Однако посматриваю за его развитием краем глаза. Подозреваю, что множество коллег по C++ (потенциальная целевая аудитория Rust'а) придерживается аналогичной позиции. Но к аудитории пользователей C# это всё вряд ли имеет какое-то отношение — вообще разные миры.
D>Также давайте не будем перечислять еще толпу динамических языков, которые я бы в сложном проекте никогда не использовал.
Ну один такой язык ты упомянул — почему не заговорить о других?
А вообще, в твоём монологе из популярных и активно развиваемых языков не хватает упоминания всего двух: C++ и JS.
Первый очевидно мало пересекается с C#, живя в своей особой нише.
А вот JS сейчас активно пихают как раз в ниши C#. Причём что самое главное: один из главных "пихателей" — это MS (автор C#). Глядя на такую картину, только твердолобый фанатик может остаться верным C#... )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Danchik, Вы писали:
СО>>>Что-то этот шарпец не жилец, а сколько было амбиций при создании.. D>>А кто супер жилец? Жава? Которую тот же Котлин начал вытеснять с мобилок. Застоялась жавав, очень сильно.
_>Kotlin вообще то входит в инфраструктуру Жабки) Так же как и Scala. Т.е. это приблизительно как F# должен был развиваться платформу .net, при этом не являясь конкурентом C#. Только вот у F# не сложилось с популярностью, а вот у Scala вполне ничего так. А теперь похоже ещё и у Kotlin.
Спасибо КО
D>>Питон? У него своя ниша — что-то быстрее для разработки на линухах. После плюсов это просто отдушина, а для математиков сребрянная пуля. В серьезном проекте заметно снижение производительности разработчиков ибо трогать уже опасно, рефакторить стремно.
_>Ты всё верно написал, за исключением упоминания Линуха. Причём тут он и Питон? К примеру я занимаюсь разработкой исключительно на Винде (под множество разных платформ) и при этом у меня из каждого угла торчит Питон.
Ноги оттуда. Плюсовики в основном на него прыгают и комфортно себя чувтсвуют на минуточку на интерпретируемом языке! Это не ты мне тут про такты генерации сиквела диферамбы пел? Об чудовищной рефлексии?
D>>Go? Вот и это я тоже считаю высером для линукса, в котором library hell породил решения на докерах. Куда они дели дженерики...
_>А вот Go, являясь "оптимизированным под бэкенд" языком, является прямой угрозой Java и C# в одной из их ключевых областей. И да, опять же Go никак не завязан на Linux.
Все оттуда, от того же линуха. Монолитные исполняемые модули — убрать зависимость от толпы опенсорсных либ.
Как язык он убог.
D>>Rust? Писать на нем иногда может быть посложнее плюсов. Сложность увеличивается с каждым релизом.
_>С учётом направления и темпов развития C++ в последние годы, лично я потерял прямой интерес к Rust'у. Однако посматриваю за его развитием краем глаза. Подозреваю, что множество коллег по C++ (потенциальная целевая аудитория Rust'а) придерживается аналогичной позиции. Но к аудитории пользователей C# это всё вряд ли имеет какое-то отношение — вообще разные миры.
На плюсах писать все что ты там сверу упомянул об Go — это мозахизмом заниматься вместе с Шериданом.
D>>Также давайте не будем перечислять еще толпу динамических языков, которые я бы в сложном проекте никогда не использовал.
_>Ну один такой язык ты упомянул — почему не заговорить о других?
Тупанул, принято
_>А вообще, в твоём монологе из популярных и активно развиваемых языков не хватает упоминания всего двух: C++ и JS.
О плюсах я сверху написал, да и плюсы давно вычеркнул из своего репертуара. Хотя нет, вот вернулся на недельку, ненависть растет. Инклюды, линкеры, ключи...
_>Первый очевидно мало пересекается с C#, живя в своей особой нише.
_>А вот JS сейчас активно пихают как раз в ниши C#. Причём что самое главное: один из главных "пихателей" — это MS (автор C#). Глядя на такую картину, только твердолобый фанатик может остаться верным C#... )))
Они JS пихают куда надо. Спасибо за еще одни «познания», он еще и автор Turbo Pascal, Delphi, но он пихает TypeScript, типизированный JS. И я за него рад — человек занимается любимым делом, разрабатывает новые языки.
Хипстеров расплодилось... не о тебе, но все же и Go и JS и Питон я считаю языками с которых начали на хайпе и спрыгивать не хотят.
Здравствуйте, kaa.python, Вы писали:
KP>В каком-то смысле он умер. Глянь как новые библиотеки и инструменты активно рождаются для Go, Rust да даже Python.
Портируют то, что уже 100 лет существует для С/С++?
S>, быстро взять, попробовать, получить результат и пойти дальше решать прикладные задачи -- вот это будет гораздо важнее.
нюанс вот этих требований позволяет сейчас хоть как то фильтровать специалистов от
а если дать всем таким право-лево руким программистам такую библиотеку
то вы и другие начнут голодать, потому что тот каждый программист будет решать ваши/их задачи за n/100.. денег
как тогда отличить специалистов, тех кто действительно знает и может такую библиотеку, от тех кто умеет только пользоваться ею, ведь она предположим уже стандартна(в С++ даже приняли) ?
задачи в виде "взял подкинул и пошел", в сетевых технологиях не встречал за последние 10 лет
если такие задачи возникают у программиста, значит он не той задачей занимается и задача как минимум не правильно поставленна
S>Ну а по поводу libcurl. Автор вложил в нее что-то порядка 20 лет труда. Пусть даже на http-часть приходится всего 5 из них. Как-то неразумно на коленке лабать собственный вариант libcurl-а, особенно если супер-пупер эффективность не нужна.
там такой туши свет в этом curl как для программиста, на коленке пишется, а автор 20 лет выбросил в пустую
но она очень хороша для администраторов что бы на коленке скриптами шелла что то автоматизировать
Здравствуйте, reversecode, Вы писали:
R>как тогда отличить специалистов, тех кто действительно знает и может такую библиотеку, от тех кто умеет только пользоваться ею, ведь она предположим уже стандартна(в С++ даже приняли) ?
Это не так уж и сложно делается. Достаточно определится с требованиями. Если ищут прикладного разработчика, который будет использовать готовые библиотеки для решения конкретной задачи, то это одно. И список требований один.
Если нужен писатель библиотек, то это другое и список требований другой.
Да, писателям библиотек будет не сладко (на самом деле уже). Но такова се ля ви.
R>задачи в виде "взял подкинул и пошел", в сетевых технологиях не встречал за последние 10 лет
REST API уже много лет как относится к сетевым технологиям лишь косвенно.
Здравствуйте, so5team, Вы писали:
S>Ну а по поводу libcurl. Автор вложил в нее что-то порядка 20 лет труда.
Оно и заметно что там всё заросло наглухо за 20 лет. Продираться через эти наслоения довольно неприятно.
S>Пусть даже на http-часть приходится всего 5 из них.
Походу даже меньше. Там всё в столько обёрток завёрнуто что ну его нафиг.
S>Как-то неразумно на коленке лабать собственный вариант libcurl-а, особенно если супер-пупер эффективность не нужна.
На то, чтоб написать с нуля HTTPS GET мне понадобился вечер, в основном на TLS.
Супер-пупер эффективности там может и нет, сайты всё равно отдают медленнее чем я могу это перерабатывать.
Здравствуйте, CreatorCray, Вы писали:
S>> которые, кроме их авторов никто не видит и переиспользовать не может. CC>Ну я софт который для себя пишу никуда не выкладываю, просто потому что не хочу. Иногда со знакомыми какими нить сурсами делюсь если они им полезны, но паблисити меня не интересует совершенно никакая.
Почему люди не выкладывают свои разработки в свободный (да даже и не в свободный доступ) понятно. Причин может быть множество.
Но все это совершенно неважно, когда какому-то обычному разработчику дают задачу обратится по HTTP к такому-то сервису. Что сейчас не редкость, ибо микросервисная архитектура и вот это вот все. По факту выбирать-то не из чего. И libcurl среди очевидных вариантов.
S>>Поэтому когда у человека, далекого от HTTP, возникает задача сделать исходящий HTTP-запрос CC>Всё что тебе надо для HTTP — это чутка почитать RFC, написать на сокетах простейшую отправлялку и принималку, формирование текста запроса на отправку, и разбор текстового ответа.
Современный RFC на HTTP 1.1 -- это не две страницы и даже толковый парсинг определенных HTTP-полей требует работы и тестирования. Не говоря уже про поддержку transfer conding-в и механизмов аутентификации, пайплайнинга и пр.
Понятно, что сделать тяп-ляп для использования внутри маня-мирка не проблема. Но если захочется чего-то продвинутого и хоть сколько-нибудь защищеного и протестированного, то свой собственный велосипед, который кому-то затем нужно сопровождать... Ну так себе идея.
CC>В винде вон вообще WinHTTP есть встроенный.
В свое время этот самый WinHTTP сильно зависел от версии установленного IE.
_>Только вот у F# не сложилось с популярностью, а вот у Scala вполне ничего так. А теперь похоже ещё и у Kotlin.
однохренственно у них. у Scala тож с популярностью не очень. юзают его либо в тех же областях, что и F#(какой-нибудь quantitative finance чисто из возможностей написать свой dsl для оных целей, ну еще кейсы в data science и в биг дата там где spark, но там и жава себе живет нормально) либо некоторые конторы, где просто захотели выпендриться и заюзать вместо Java, но особой причины не было. никакого повсеместного использования скалы не случилось. а на фоне выхода Java 8, 9, а теперь еще 11 и предстоящей 12, как-то и смысла нет, только если ты не резерчер в каких-то академ. целях
Здравствуйте, reversecode, Вы писали:
R>задарит мне кто то лям баксов, я до конца жизни буду бесплатно кодить, фиксить, разрабатывать для опенсорса проекты любой сложности, хоть линуксы драйвера, хоть фрейморки для сетей, да вообще все где есть С/C++, знаний вагон, всегда можно освежить
Не будешь. С таким подходом ты просто забьешь, пока деньги не кончатся (а кончатся они быстро)
Тебе надо разжёвывать всё как ребёнку? Ну давай попробуем с помощью простеньких риторических вопросов:
1. Какая самая актуальная (если уже не единственная) ниша для C#? Ответ: бэкенд.
2. Для какой ниши создан движок node.js? Ответ: бэкенд.
3. Инструменты для какого бэкенд-движка активно развивают MS внутри своего основного инструмента для разработчиков? Ответ: node.js.
Уже можешь сам выводы сделать или всё ещё нет? )
Да, и естественно пункт 3 — это просто пояснение именно к данной ссылке, а не единственный аргумент в данной схеме. Так то их можно десятками накидать, т.к. активность MS в данной области очень солидная (не ограничивается инструментами для VS).
_>>А уж если посмотреть на продвижение TS... НС>Вместо шарпа?
TS очевидно не вместо Шарпа или чего-то ещё. Он вообще не "вместо", а "для" — для развития платформы JS. Только вот если взглянуть на темпы развития TS (которым рулит MS) и C# (которым так же рулит MS), то тоже можно очень быстро сделать очевидные выводы.
НС>Итого, примеров нет, ты все выдумал.
Вот даже не смешно уже видеть подобное на форуме. Я про данные тенденции писал здесь ещё несколько лет назад и тогда многочисленные фанаты C# натужно смеялись в этих дискуссиях. В последнее время смех куда-то делся и у части из них появились обречённые нотки, а другую часть я постоянно замечаю за хвалебными отзывами о JS/TS. И только редкие непробиваемые динозавры типа тебя продолжают игнорировать реальность и делать вид что ничего не изменилось в политике MS за последние пять лет.
Здравствуйте, alex_public, Вы писали:
_>Даже так? ) Ну расскажи тогда, развитие какого инструмента для Шарпа в последнее время ты считаешь аналогом по значимости развитию TS (это же инструмент для JS не так ли? И создан MS, правильно?) ?
C# 7.2/7.3, RuyJIT, .Net Core.
Там реально начался наконец-то движняк, видный невооружённым глазом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>>>3. Инструменты для какого бэкенд-движка активно развивают MS внутри своего основного инструмента для разработчиков? Ответ: node.js. НС>>>Инструменты для шарпа он развивает намного активнее. _>>Даже так? ) Ну расскажи тогда, развитие какого инструмента для Шарпа в последнее время ты считаешь аналогом по значимости развитию TS (это же инструмент для JS НС>Как ловко ты от инструментов для бэкенда перешел к инструментам для JS.
Посмотри внимательнее на свою же цитату — это ты перешёл от движков бэкенда (у .net это будет ASP) к самим языкам. Так что определись что мы будем сравнивать, инструменты для ASP с инструментами для Node.js или же инструменты для C# с инструментами для JS. Оба варианта корректны. Но не твоя твоя смешная хитрость со сравнением C# с node.js.
_>> Так что по факту для разработчика, использующего VS, никакого "вместе" нет — он выбирает что-то одно. НС>И? Напоминаю, а то ты опять забыл — речь о поведении МС, а не о поведении разработчика.
Так MS в последнее время активно помогает выбрать именно node.js для написания бэкенда. )))
_>>>>TS очевидно не вместо Шарпа НС>>>ЧТД _>>Угу, обрезал фразу, исказив её смысл до неузнаваемости НС>Т.е. смысл был в том что JS вместо шарпа?
Смысл был в том, что вообще все эти вещи делаются не "против" кого-то, а только "за".
Однако если мы имеем два конкурирующих в одной области продукта, то активное развитие одного из них в любом случае негативно влияет на другой. Это в общем то нормальное рыночная ситуация, но тут у нас есть один принципиальный нюанс: оба продукта принадлежат одной компании — это сразу наводит на вполне однозначные мысли...
_>> Мда, когда-то ты действительно мог приводить технические аргументы, делать логические выводы и т.п., а теперь остался лишь скучный троллинг. НС>Технические аргументы это твои личные нападки, да?
Техническим аргументом от меня была ссылка на инструменты для Node.js в VS. И подобных аргументов я могу накидать ещё множество. Вот навскидку из первых строк гугла репозиторий от MS https://github.com/Microsoft/TypeScript-Node-Starter как раз помогающий проще перейти на данный стек бэкенд технологий. И такого добра ещё полно. А вот от тебя пока что-то кроме болтовни и демагогии ничего не видно. Хотя да, я понимаю что трудно найти технические аргументы для того, что расходится с объективной реальностью. Но не понимаю зачем тогда влезать в дискуссию...
Здравствуйте, alex_public, Вы писали:
_>Посмотри внимательнее на свою же цитату — это ты перешёл от движков бэкенда (у .net это будет ASP)
Чего вдруг ты бэк ASP ограничил?
_>>> Так что по факту для разработчика, использующего VS, никакого "вместе" нет — он выбирает что-то одно. НС>>И? Напоминаю, а то ты опять забыл — речь о поведении МС, а не о поведении разработчика. _>Так MS в последнее время активно помогает выбрать именно node.js для написания бэкенда. )))
Где он именно ноду помогает?
_>Смысл был в том, что вообще все эти вещи делаются не "против" кого-то, а только "за".
Не все.
_>Однако если мы имеем два конкурирующих в одной области продукта, то активное развитие одного из них в любом случае негативно влияет на другой.
Ты забыл о том, что ноду не один МС развивает. Так что твои взаимоисключающие правила не работают.
_> Это в общем то нормальное рыночная ситуация, но тут у нас есть один принципиальный нюанс: оба продукта принадлежат одной компании
Нода не принадлежит МС.
_>Техническим аргументом от меня была ссылка на инструменты для Node.js в VS.
Там знаешь сколько таких инструментов? Одно время даже для php было. МС, как обычно, придерживается оппортунистической стратегии, поддерживает то, что уже популярно. При этом инструментарий для шарпа на две головы круче инструментария для JS/TS
_> И подобных аргументов я могу накидать ещё множество. Вот навскидку из первых строк гугла репозиторий от MS https://github.com/Microsoft/TypeScript-Node-Starter как раз помогающий проще перейти на данный стек бэкенд технологий. И такого добра ещё полно.
Только это никак не доказывает, что все это вместо шарпа.
_> А вот от тебя пока что-то кроме болтовни и демагогии ничего не видно.
А я и не делаю никаких утверждений. Бремя доказательств на тебе.
Здравствуйте, Somescout, Вы писали:
_>>Ну например здесь https://visualstudio.microsoft.com/ru/vs/features/node-js/. Это если непосредственно взглянуть на то, что вытесняет C# из его единственной актуальной ниши (написания бэкендов). S>А nodejs разве из бэкенда уже не вытесняется активно Go?
По моим ощущениями они оба всё ещё на волне хайпа. )
S>ЗЫ. Я думал как-то попробовать написать бэкенд на nodejs, а теперь смысла не вижу — единственный плюс — общие модели для клиента и сервера нивелируются генерацией моделей, или можно вообще swagger использовать. А NetCore для бэкенда в целом удобнее.
Ну это дело вкуса. Я например вообще Питон предпочитаю для этих целей, а от JS кода меня подташнивает. ))) Но мои вкусы никак не влияют на общий расклад по индустрии — node.js сейчас очень популярен.
Здравствуйте, takTak, Вы писали:
T>т.е. если подытожить, то ничего за эти несколько лет не изменилось, правильно? T>тебе не опять, а снова кажется, что "только редкие непробиваемые динозавры продолжают игнорировать реальность", в то время как "буйволы, медленно спускающиеся по склону холма" по-прежнему делают то же, что и несколько лет назад?
Я тебе предысторию расскажу, чтобы было понятнее о чем он пишет. 15 лет назад МС начал активно работать над .net, при этом несколько сбавив обороты по направлению к С++. У Алекса от этого полыхнуло, причем полыхнуло столь мощно, что боль не затихла даже спустя 15 лет.
И да, он еще тогда всем рассказывал, что пройдет несколько лет, и МС точно так же бросит .net и займется чем то еще. Годы шли, а боль все не утихала, МС, гад такой, продолжал работать над дотнетом.
Вот теперь он и пытается найти хоть что то, чтобы успокоить себя прежде всего. То что, помимо ноды, там еще и питончик поддержали, что поддержка ноды на редкость убога и не идет ни в какое сравнение с first citizens по уровню его никак не смущает. Заменяет и точка.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Ну если тебе хочется в это верить НС>Это не вопрос веры. _>>, то я тут ничем не могу помочь. Но советую всё же жить не религиозными догмами, а объективной реальностью: НС>Воспользуйся собственным советом.
Не вижу смысла спорить с фанатиком. Ты игнорируешь (и даже фигурно вырезаешь из цитат) все аргументы и отвечаешь при этом одними зеркальными лозунгами. Беседы с тобой стали просто потерей времени. А когда-то было совсем по другому...
Т.е. Netflix и Ebay — это не масштабное? )))
V>И да, в моей формулировке было "В этой реальности не существует достаточно больших проектов, писанных на TS."
Твоя формулировка отлично видна в цитате на самом верху и в ней нет ничего про TS.
V>На TS я ничего заметного так и не нашёл сегодня, как и год назад, когда искал последний раз.
В любом проекте на JS может быть легко использован TS. Причём для этого не потребуется никаких процессов "перехода" и соответственно каких-то анонсов и т.п. Более того, TS может использовать только часть команды. TS — это не платформа (которую не так просто сменить), а всего лишь один из инструментов, помогающих JS разработчику.
_>>Да не важно хомячки это или нет. Главное что 5 лет назад они молились на .net и смеялись над любыми сомнениями в его светлом будущем. А сейчас многие из них точно так же молятся на JS/TS... ))) V>Я что тогда всерьёз "молящихся" не воспринимал, что сегодня. V>Если ты профик, ты жуткий циник относительно технологий. V>И непременный пессимист, бо хотя бы немножко знаешь подробности изнутри, а многие знания — многие печали. )) V>А вот это всё — хомячки, т.е. пользователи технологий, причём, самая маргинальная часть из них.
Я со всем этим согласен. Только в любом случае согласись, что факт данных забавных изменений, сам по себе является довольно интересным индикатором.
P.S. А больше всего в данной дискуссии меня забавляет то, что я в ней выступаю в роли "защитника" JS, хотя меня самого от этого языка и окружающего его стека технологий подташнивает. ))) Вот что значит пытаться быть объективным...
N>>Растёт число репозиториев и разработчиков, где ожидаемый отток? CC>Скайп тоже не сразу сгнил, дай им время.
Да, в данном случае придется потратить много сил.
Как много веселых ребят, и все делают велосипед...
O>>Да, в данном случае придется потратить много сил. CC>Не, скорее согласно стиху будет "то просто тратит меньше сил"
Почему? Гитхаб как сервис оч неплох.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Nuzhny, Вы писали:
N>>Растёт число репозиториев и разработчиков, где ожидаемый отток? CC>Скайп тоже не сразу сгнил, дай им время.
решил зачем-то запустить skype for business (который с офисом ставится) — фиг там, скачайте teams,
похоже скайп окончательно догнил
Здравствуйте, Nuzhny, Вы писали:
N>Цветёт и пахнет! N>Растёт число репозиториев и разработчиков, где ожидаемый отток? В целом похоже, что open source побеждает (вряд ли победит, но доминирует).
Отток будет тогда, когда сервис станет не стабильным. А он таким станет после передачи разработки и поддержки в индийское подразделение.
N> "Умирающий" С++ также не сдаёт позиции, что бы не лаяли про труп страуса. Короче, просто хорошая новость.
В каком-то смысле он умер. Глянь как новые библиотеки и инструменты активно рождаются для Go, Rust да даже Python. Но не C++, что своего рода смерть языка.
Здравствуйте, TimurSPB, Вы писали:
TSP>Делаешь такой pip install ... и вдруг запускается компиляция плюсового когда. У тебя очень поверхностное и неправильное ощущение смерти языка С++.
Ну да, расскажи мне про C++ Ты говоришь про небольшое подмножество Си, реже C++ динозавров и крайне редко про новые, молодые и активно развиваемые проекты. Особенно чётко эта тенденция прослеживается в Open Source, где народ выбирает то, на чем интереснее и/или проще писать, а не корпоративная политика навязала.
Здравствуйте, alex_public, Вы писали:
_>Вот ты вроде бы действительно в курсе C++, а такую ерунду пишешь.
Да не пишу я ерунду, я говорю о текущей ситуации которая мне не нравится, всё же меня C++ уже почти 20 лет кормит и надеюсь что и дальше будет
Если ты, к примеру, глянешь на тренды в мире C++ за последний месяц, то ничего кроме ML та там не увидишь по большому счету: математика и числомолотлки, фсё . Я как раз об этом и говорил изначально: "крайне редко про новые, молодые и активно развиваемые проекты". Можешь сравнить с трендами в Python, Go, Rust, просто обрати внимание что в тренде.
Здравствуйте, kaa.python, Вы писали:
KP>Если ты, к примеру, глянешь на тренды в мире C++ за последний месяц, то ничего кроме ML та там не увидишь по большому счету: математика и числомолотлки, фсё . Я как раз об этом и говорил изначально: "крайне редко про новые, молодые и активно развиваемые проекты". Можешь сравнить с трендами в Python, Go, Rust, просто обрати внимание что в тренде.
Всё таки у тебя противоречие: ML — это как раз молодая и горячая тема, в ней С++ цветёт и пахнет, все фреймворки написаны исключительно на нём. Блокчейн — хайп вчерашнего дня, это тоже С++ и GPU programming. Тот факт, что на С++ почти перестали писать прикладной код, как по мне, совсем не смерть, а наоборот, новая жизнь. Язык стал активней развиваться, стал более дружественным для профессионалов. Новые проекты на нём пишутся и активно, но не толпами "индусов" или обезьянками.
Здравствуйте, jazzer, Вы писали:
J>я все правильно понял, на мелкософтовском ресурсе плюсы обогнали шарп?
М...
Чую, ты хочешь предложить, чтобы гитхаб остался только для Шарпа и Бейсика?
Здравствуйте, Danchik, Вы писали:
D>На плюсах писать все что ты там сверу упомянул об Go — это мозахизмом заниматься вместе с Шериданом.
По большому счету -- это все упирается в библиотеки. То, что в Go есть "из коробки", в C++ нужно искать по сторонам. И не факт, что можно найти.
Например, HTTP-вход в C++ организовать. Это не проблема, но многие не идут дальше Boost-а. Либо перепиливают штатные примеры из Boost.Asio, либо с недавних пор используют Boost.Beast. И тот, и другой вариант, в сравнении с Go-ными http/fasthttp -- это как закат Солнца вручную. Пойти дальше и найти что-то более простое и удобное уже могут не все.
А вот сделать исходящий HTTP-запрос из C++, тут уже все грустно. Можно, конечно, запарится с Boost.Beast, но проще libcurl взять с какой-нибудь плюсовой оберткой. Но оба эти варианта так себе.
Тем не менее, речь идет о том, что здесь и сейчас в C++ной экосистеме мало инструментов для этой ниши. Что вовсе не означает, что такие инструменты не появятся в будущем. Тем более, что интерес к таким вещам есть.
проблема в другом
написать на С++ библиотеку которая бы удовлетворяла всех С++ разработчиков или даже большинству сложно, не возможно
потому как в С++ можно проявлять творчество, слишком творческий язык
а вот в том же Го все более тесно и меньше творчества
одна стандартная либа + кто то там фастхттп написал и гоу разработчики довольны как слоны
резюме, С++ решает больше задач чем другие языки, отсюда и тёрки
Здравствуйте, reversecode, Вы писали:
R>написать на С++ библиотеку которая бы удовлетворяла всех С++ разработчиков или даже большинству сложно, не возможно R>потому как в С++ можно проявлять творчество, слишком творческий язык
R>а вот в том же Го все более тесно и меньше творчества R>одна стандартная либа + кто то там фастхттп написал и гоу разработчики довольны как слоны
R>резюме, С++ решает больше задач чем другие языки, отсюда и тёрки
Собственно, все так и есть.
Но, вроде как, в контексте разговора не так важно, почему для С++ меньше библиотек. Важен сам факт, что хорошие и удобные библиотеки под определенные типы задач в C++ либо отсутствуют, либо их немного и их нужно разыскивать. Поэтому тот же C++ сложно использовать для разработки бэкендов. А не потому, что в этом занятии мало смысла. Смысла как раз становится все больше, по мере того, как разработчики бэкендов начинают слазить с Python/Ruby и даже с Java в пользу более быстрых нативных языков. Плюс к тому, кроме скорости работы еще и получаются более компактные и быстро запускающиеся Docker-образы.
S> Смысла как раз становится все больше, по мере того, как разработчики бэкендов начинают слазить с Python/Ruby и даже с Java в пользу более быстрых нативных языков. Плюс к тому, кроме скорости работы еще и получаются более компактные и быстро запускающиеся Docker-образы.
и в этом моменте и сливаются все те крутые специалисты которые с легкостью могут посчитать гномиков, знают наизусть все паттерны проектирования, имеют большой набор каких то непонятных проектов на гит хабе, даже знают не в теории а на практике как работает tcp/ip и даже http !
но как только доходит дело до набросать пару строк на С++ клиента или сервера http
да еще что бы в нем не только restapi(это я не о вас) можно было обрабатывать,
тут они сразу сливаются
и бегут за мерзким(на мой взгляд) libcurl который обмазывают С++ обёрткой в лучшем случае
резюме, я рад что того нетворкинга то предлагают еще не будет в С++20
и я рад то количество библиотек http или других подобных сетевых протоколов мало, их надо искать, либо писать самостоятельно
это хоть как то ограничит эту сфера от всякого рода профессионалов правой(или левой) руки
Здравствуйте, reversecode, Вы писали:
R>но как только доходит дело до набросать пару строк на С++ клиента или сервера http R>да еще что бы в нем не только restapi(это я не о вас) можно было обрабатывать, R>тут они сразу сливаются R>и бегут за мерзким(на мой взгляд) libcurl который обмазывают С++ обёрткой в лучшем случае
Придется сказать банальность: на C++ программируют очень разные люди и решают очень разные задачи. Где-то, например, нужно сделать REST API, который будет обрабатывать всего 10 запросов в секунду, но зато на обработку каждого запроса будет тратится по 2-3 минуты. Эффективность сетевого кода в таком сценарии будет стоять где-то в конце первой сотни проблем (если не в конце второй). Зато вот возможность за полдня разобраться с библиотекой для реализации REST API, быстро взять, попробовать, получить результат и пойти дальше решать прикладные задачи -- вот это будет гораздо важнее.
Ну а по поводу libcurl. Автор вложил в нее что-то порядка 20 лет труда. Пусть даже на http-часть приходится всего 5 из них. Как-то неразумно на коленке лабать собственный вариант libcurl-а, особенно если супер-пупер эффективность не нужна.
Здравствуйте, alex_public, Вы писали:
a> Kotlin вообще то входит в инфраструктуру Жабки) Так же как и Scala. Т.е. это приблизительно как F# должен был развиваться платформу .net, при этом не являясь конкурентом C#. Только вот у F# не сложилось с популярностью, а вот у Scala вполне ничего так. А теперь похоже ещё и у Kotlin.
Только есть ещё и kotlin native, которому инфраструктура жабки не нужна.
Здравствуйте, so5team, Вы писали:
S>А вот сделать исходящий HTTP-запрос из C++, тут уже все грустно.
Я HTTPS getter сам написал развлекухи ради, без единого гвоздя, для своей проги, которая тягает всякую финансовую инфу из разных источников.
10 кб кода на сам HTTP, который элементарный просто до жути, ещё 12 кб на TLS wrapper.
Фигачит тока шуба заворачивается.
S> Можно, конечно, запарится с Boost.Beast, но проще libcurl взять с какой-нибудь плюсовой оберткой. Но оба эти варианта так себе.
Оба варианта говно — слишком много там лишнего.
Здравствуйте, CreatorCray, Вы писали:
S>>А вот сделать исходящий HTTP-запрос из C++, тут уже все грустно. CC>Я HTTPS getter сам написал развлекухи ради, без единого гвоздя, для своей проги, которая тягает всякую финансовую инфу из разных источников. CC>10 кб кода на сам HTTP, который элементарный просто до жути, ещё 12 кб на TLS wrapper. CC>Фигачит тока шуба заворачивается.
Вот как-то так получается, что вроде как есть (по словам на форуме) крутые и небольшие разработки, которые, кроме их авторов никто не видит и переиспользовать не может.
А в публичном доступе есть тот же libcurl, который древний и большой, но использован в таком большом количестве сценариев, что и вообразить сложно.
Поэтому когда у человека, далекого от HTTP, возникает задача сделать исходящий HTTP-запрос, то выбор есть либо из создания собственного велосипеда (непонятного качества), либо из использования libcurl-а. С точки зрения экономии ресурсов выбор в пользу libcurl очевиден.
Что не отменяет того факта, что у кого-то где-то может быть собственная наколенная разработка намного лучшего качества.
Здравствуйте, so5team, Вы писали:
S> С точки зрения экономии ресурсов выбор в пользу libcurl очевиден.
С точки зрения склепать что то что шевелится и забыть — да, безусловно.
Но вот с точки зрения сделать хорошо и ещё чему то научиться в процессе — нет.
Я когда то принял принципиальное решение весь свой софт писать с нуля, просто потому что у меня сроков никаких нет так что могу себе позволить.
Занимает несколько больше времени но в качестве результата у меня есть либа которая умеет кучу вещей от специфических структур данных до эллиптической криптографии, и я имею хорошее понимание как все эти предметные области работают, что в итоге выливается в хорошие предложения работы. Ну а вещи типа написать HTTPS на досуге позволяют размять чем то новым мозги, занятые ежедневной рабочей спецификой.
S>Вот как-то так получается, что вроде как есть (по словам на форуме) крутые и небольшие разработки, которые, кроме их авторов никто не видит и переиспользовать не может.
это все пропорционально бенефитов авторам
задарит мне кто то лям баксов, я до конца жизни буду бесплатно кодить, фиксить, разрабатывать для опенсорса проекты любой сложности, хоть линуксы драйвера, хоть фрейморки для сетей, да вообще все где есть С/C++, знаний вагон, всегда можно освежить
S>А в публичном доступе есть тот же libcurl, который древний и большой, но использован в таком большом количестве сценариев, что и вообразить сложно.
не работает увы, на недельке играться с janus + rtsp, rtsp там как раз через curl прикручен
сомнение были что оно чуть больше чем не рабочее, но попытка не пытка
так и оказалось
S>Поэтому когда у человека, далекого от HTTP, возникает задача сделать исходящий HTTP-запрос, то выбор есть либо из создания собственного велосипеда (непонятного качества), либо из использования libcurl-а. С точки зрения экономии ресурсов выбор в пользу libcurl очевиден.
иногда это звучит абсурдно
пример абсурда — p2p стриминг sopcast
значит ребятам хватило ума написать пиринговый сетевой видео стриминг
но не хватило ума докинуть простого http протокола
поэтому авторизация там через curl как клиент
а сервер http какая то полу рабочая балалайка, лишь бы локальный клиент как то забрал
S>Что не отменяет того факта, что у кого-то где-то может быть собственная наколенная разработка намного лучшего качества.
и не у одного, поэтому часто пересекается с темой велосипедов итд
N>>Растёт число репозиториев и разработчиков, где ожидаемый отток? CC>Скайп тоже не сразу сгнил, дай им время.
емнип скайп стал тухнуть еще до покупки мелкомягкими, еще за год до все жаловались на глючность десктопной версии и даже были ожидания у некоторых, что после покупки что-то изменится в лучшую сторону, наивные
J>я все правильно понял, на мелкософтовском ресурсе плюсы обогнали шарп?
а что тут удивительного, они как бы никогда против плюсов и не были особо. я однажды чуть не поперхнулся, когда по какойто рассылке, от azure по моему пришла картинка microsoft сердечко java
D>А кто супер жилец? Жава? Которую тот же Котлин начал вытеснять с мобилок. Застоялась жавав, очень сильно.
жилец, еще какой жилец, просто вы не в теме совсем. котлин вытесняет с мобилок и что? а где там на мобилках чистый dotnet+C# покажи мне, без всяких xamarin, unity и прочего?
upd джаба не жилец, ага http://pypl.github.io/PYPL.html D>Питон? У него своя ниша — что-то быстрее для разработки на линухах. После плюсов это просто отдушина, а для математиков сребрянная пуля. В серьезном проекте заметно снижение производительности разработчиков ибо трогать уже опасно, рефакторить стремно.
питон серебряная пуля для математиков, серьезно? кого ты математиками называешь?
D>Go? Вот и это я тоже считаю высером для линукса, в котором library hell породил решения на докерах. Куда они дели дженерики...
вот кстати go может потеснить java в области всякой микросервисной обвязки. комментировать же сие предложение не вижу смысла ибо троллинг детектед. ты докер не юзаешь, а чем ты тогда занимаешься?
D>Также давайте не будем перечислять еще толпу динамических языков, которые я бы в сложном проекте никогда не использовал.
конечно, ты же показатель и тренд всех сфер IT индустрии
Здравствуйте, alex_public, Вы писали:
_>А вот JS сейчас активно пихают как раз в ниши C#. Причём что самое главное: один из главных "пихателей" — это MS (автор C#).
Здравствуйте, CreatorCray, Вы писали:
CC>В винде вон вообще WinHTTP есть встроенный.
В винде для ссерверной части есть http.sys, который в винде надо использовать обязательно, как для перформанса, так и для успешного уживания с другими сервисами на одном порту.
Здравствуйте, CreatorCray, Вы писали:
НС>>В винде для ссерверной части есть http.sys, который... CC>... не имеет отношения к клиентской HTTP GET, которая обсуждается в этой ветке
В этой ветке обсуждается curl. И, это, начиная с W2K в винде доступен wininet.dll.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>В этой ветке обсуждается curl. CC>>http.sys точно так же не имеет к нему отношения НС>Имеет. Функционал пересекается.
Э... Это в каком месте то?
НС> А чего ты про wininet то поскипал?
А что я должен был про него написать?
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>А вот JS сейчас активно пихают как раз в ниши C#. Причём что самое главное: один из главных "пихателей" — это MS (автор C#). НС>Где конкретно МС пихает JS вместо шарпа?
Ну например здесь https://visualstudio.microsoft.com/ru/vs/features/node-js/. Это если непосредственно взглянуть на то, что вытесняет C# из его единственной актуальной ниши (написания бэкендов). Кстати, меня недавно весьма рассмешил один забавный нюанс из этой области: я узнал, что .net веб-приложения работающие с Angular для серверного рендеринга используют тот же самый node.js. )))
Здравствуйте, alex_public, Вы писали:
_>>>А вот JS сейчас активно пихают как раз в ниши C#. Причём что самое главное: один из главных "пихателей" — это MS (автор C#). НС>>Где конкретно МС пихает JS вместо шарпа? _>Ну например здесь https://visualstudio.microsoft.com/ru/vs/features/node-js/.
И где там вместо шарпа?
_>А уж если посмотреть на продвижение TS...
Здравствуйте, alex_public, Вы писали:
_>1. Какая самая актуальная (если уже не единственная) ниша для C#? Ответ: бэкенд. _>2. Для какой ниши создан движок node.js? Ответ: бэкенд. _>3. Инструменты для какого бэкенд-движка активно развивают MS внутри своего основного инструмента для разработчиков? Ответ: node.js.
Инструменты для шарпа он развивает намного активнее.
_>Уже можешь сам выводы сделать или всё ещё нет? )
Могу. Не вместо, а вместе.
_>>>А уж если посмотреть на продвижение TS... НС>>Вместо шарпа? _>TS очевидно не вместо Шарпа
ЧТД
НС>>Итого, примеров нет, ты все выдумал. _>Вот даже не смешно
Оно действительно не смешно.
_> уже видеть подобное на форуме. Я про данные тенденции писал
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>1. Какая самая актуальная (если уже не единственная) ниша для C#? Ответ: бэкенд. _>>2. Для какой ниши создан движок node.js? Ответ: бэкенд. _>>3. Инструменты для какого бэкенд-движка активно развивают MS внутри своего основного инструмента для разработчиков? Ответ: node.js. НС>Инструменты для шарпа он развивает намного активнее.
Даже так? ) Ну расскажи тогда, развитие какого инструмента для Шарпа в последнее время ты считаешь аналогом по значимости развитию TS (это же инструмент для JS не так ли? И создан MS, правильно?) ?
_>>Уже можешь сам выводы сделать или всё ещё нет? ) НС>Могу. Не вместо, а вместе.
С точки зрения VisualStudio или Azure и т.п. — совершенно верно. Они позволяют работать хоть одновременно на десятке языков. Нюанс в том, что никто так проекты не делает и для конкретной задачи в проекте выбирается ровно один язык. Так что по факту для разработчика, использующего VS, никакого "вместе" нет — он выбирает что-то одно. А с учётом того, что JS/TS новичок, активно завоёвывающий себе нишу, а C# (вместе с ещё несколькими языками) наоборот старожил этой же ниши, то вполне понятно за чей счёт осуществляется взлёт JS.
_>>>>А уж если посмотреть на продвижение TS... НС>>>Вместо шарпа? _>>TS очевидно не вместо Шарпа НС>ЧТД
Угу, обрезал фразу, исказив её смысл до неузнаваемости, и думаешь что это тебе поможет в споре? Мда, когда-то ты действительно мог приводить технические аргументы, делать логические выводы и т.п., а теперь остался лишь скучный троллинг.
_>>Я про данные тенденции писал здесь ещё несколько лет назад НС>Ты не авторитет ни разу, скорее наоборот.
Здравствуйте, alex_public, Вы писали:
_>>>3. Инструменты для какого бэкенд-движка активно развивают MS внутри своего основного инструмента для разработчиков? Ответ: node.js. НС>>Инструменты для шарпа он развивает намного активнее. _>Даже так? ) Ну расскажи тогда, развитие какого инструмента для Шарпа в последнее время ты считаешь аналогом по значимости развитию TS (это же инструмент для JS
Как ловко ты от инструментов для бэкенда перешел к инструментам для JS.
_>>>Уже можешь сам выводы сделать или всё ещё нет? ) НС>>Могу. Не вместо, а вместе. _>С точки зрения VisualStudio или Azure и т.п. — совершенно верно.
Ну и?
_>Нюанс в том, что никто так проекты не делает и для конкретной задачи в проекте выбирается ровно один язык.
И?
_> Так что по факту для разработчика, использующего VS, никакого "вместе" нет — он выбирает что-то одно.
И? Напоминаю, а то ты опять забыл — речь о поведении МС, а не о поведении разработчика.
_>>>TS очевидно не вместо Шарпа НС>>ЧТД _>Угу, обрезал фразу, исказив её смысл до неузнаваемости
Т.е. смысл был в том что JS вместо шарпа?
_>, и думаешь что это тебе поможет в споре?
Мне поможет пресекать твои постоянные попытки сменить неудобную тему. Ты постоянно рассказываешь что угодно, но не то что отвечает на заданный тебе вопрос.
_> Мда, когда-то ты действительно мог приводить технические аргументы, делать логические выводы и т.п., а теперь остался лишь скучный троллинг.
Технические аргументы это твои личные нападки, да?
Здравствуйте, alex_public, Вы писали:
_>С точки зрения VisualStudio или Azure и т.п. — совершенно верно. Они позволяют работать хоть одновременно на десятке языков. Нюанс в том, что никто так проекты не делает и для конкретной задачи в проекте выбирается ровно один язык.
Нюанс в том, что никто так проекты не делает и для конкретной задачи выбирается конкретный язык. Если нужно насиловать BD, то берётся sql, если нарисовать UI в броузере, то берётся ts/html, если логика на сервере — то .net/java.
В принципе можно вообще всё сделать на каком-то одном языке(например рендерить html на .net only или там писать бекенд на js), но на практике это означает, что остальные части настолько убоги, что их можно делать хоть на брейнфаке.
_>Так что по факту для разработчика, использующего VS, никакого "вместе" нет — он выбирает что-то одно. А с учётом того, что JS/TS новичок, активно завоёвывающий себе нишу, а C# (вместе с ещё несколькими языками) наоборот старожил этой же ниши, то вполне понятно за чей счёт осуществляется взлёт JS.
Так что по факту для разработчика, использующего VS, есть ценый набор инструментов на все случаи жизни. А с учётом того, что TS новичок, активно завоёвывающий себе нишу, а javascript наоборот старожил этой же ниши(ведь C# вместе с ещё несколькими языками находяся в слегка другой), то вполне понятно за чей счёт осуществляется взлёт JS.
Типичный пример — angular.
Здравствуйте, Max Mustermann, Вы писали:
_>>С точки зрения VisualStudio или Azure и т.п. — совершенно верно. Они позволяют работать хоть одновременно на десятке языков. Нюанс в том, что никто так проекты не делает и для конкретной задачи в проекте выбирается ровно один язык. MM>Нюанс в том, что никто так проекты не делает и для конкретной задачи выбирается конкретный язык. Если нужно насиловать BD, то берётся sql, если нарисовать UI в броузере, то берётся ts/html, если логика на сервере — то .net/java.
Последний пункт у тебя не верен. Ты там пропустил множество других вариантов, в том числе текущего лидера по установкам. Правильный список в недалёком прошлом был: php, java, .net, ruby, python, ...
Так вот в последние годы к этому списку добавилась пара очень активно развиваемых и популярных новичков: JS/TS (для написания бэкенда это язык новый) и Go. И эти новички естественно отжимают часть ниши у перечисленных выше. Вполне естественная рыночная ситуация, если бы не один интересный нюанс: развитием C# и TS занимается одна компания...
MM>В принципе можно вообще всё сделать на каком-то одном языке(например рендерить html на .net only или там писать бекенд на js), но на практике это означает, что остальные части настолько убоги, что их можно делать хоть на брейнфаке.
Нет, всё сделать на одном языке получится только если этот язык JS. Ну во всяком случае пока WebAssembly не разовьются и не получат свой (нативный) доступ к DOM браузера. Или быть может ты считаешь использование всяческих генераторов JS из других языков (типа дохлого GWT) за написание фронтенда не на JS? )))
_>>Так что по факту для разработчика, использующего VS, никакого "вместе" нет — он выбирает что-то одно. А с учётом того, что JS/TS новичок, активно завоёвывающий себе нишу, а C# (вместе с ещё несколькими языками) наоборот старожил этой же ниши, то вполне понятно за чей счёт осуществляется взлёт JS. MM>Так что по факту для разработчика, использующего VS, есть ценый набор инструментов на все случаи жизни. А с учётом того, что TS новичок, активно завоёвывающий себе нишу, а javascript наоборот старожил этой же ниши(ведь C# вместе с ещё несколькими языками находяся в слегка другой), то вполне понятно за чей счёт осуществляется взлёт JS. MM>Типичный пример — angular.
Мы тут фронтенд вообще не обсуждали, т.к. C# к нему вообще никак не относится. Здесь идёт обсуждение только бэкенда, в котором JS/TS является новичком, хотя при этом уже крайне популярным.
Ну а разделение TS и JS на конкурирующие языки — это вообще смешно. )))
Здравствуйте, alex_public, Вы писали:
_>Ну например здесь https://visualstudio.microsoft.com/ru/vs/features/node-js/. Это если непосредственно взглянуть на то, что вытесняет C# из его единственной актуальной ниши (написания бэкендов).
А nodejs разве из бэкенда уже не вытесняется активно Go?
ЗЫ. Я думал как-то попробовать написать бэкенд на nodejs, а теперь смысла не вижу — единственный плюс — общие модели для клиента и сервера нивелируются генерацией моделей, или можно вообще swagger использовать. А NetCore для бэкенда в целом удобнее.
_>Вот даже не смешно уже видеть подобное на форуме. Я про данные тенденции писал здесь ещё несколько лет назад и тогда многочисленные фанаты C# натужно смеялись в этих дискуссиях. В последнее время смех куда-то делся и у части из них появились обречённые нотки, а другую часть я постоянно замечаю за хвалебными отзывами о JS/TS. И только редкие непробиваемые динозавры типа тебя продолжают игнорировать реальность и делать вид что ничего не изменилось в политике MS за последние пять лет.
т.е. если подытожить, то ничего за эти несколько лет не изменилось, правильно?
тебе не опять, а снова кажется, что "только редкие непробиваемые динозавры продолжают игнорировать реальность", в то время как "буйволы, медленно спускающиеся по склону холма" по-прежнему делают то же, что и несколько лет назад?
Здравствуйте, Sinclair, Вы писали:
S>Эмм... А ваш "геттер" умеет хотя бы фолловить редиректы?
Умеет, но я выключил и спецом репорчу редирект.
S> Как насчёт докачки (Range Header)?
Технически да, а практически я забил: ни один сайт откуда мне надо тягать данные ranges не юзает а искать спецом на чём протестировать мне было влом. Я ж решал свою практическую задачу.
S> Что с поддержкой GZIP encoding?
Забил болт по причине выше.
S> Conditional get осилит?
Same
S> Есть ли встроенная поддержка content-disposition:attachment?
Есть, но опять таки протестил только отправку POST с аттачментами — никто мне нужный аттачи не шлёт.
S>Multiline и Binary хидеры декодировать умеет?
А кто binary hdr шлёт?
Здравствуйте, takTak, Вы писали:
_>>Вот даже не смешно уже видеть подобное на форуме. Я про данные тенденции писал здесь ещё несколько лет назад и тогда многочисленные фанаты C# натужно смеялись в этих дискуссиях. В последнее время смех куда-то делся и у части из них появились обречённые нотки, а другую часть я постоянно замечаю за хвалебными отзывами о JS/TS. И только редкие непробиваемые динозавры типа тебя продолжают игнорировать реальность и делать вид что ничего не изменилось в политике MS за последние пять лет. T>т.е. если подытожить, то ничего за эти несколько лет не изменилось, правильно? T>тебе не опять, а снова кажется, что "только редкие непробиваемые динозавры продолжают игнорировать реальность", в то время как "буйволы, медленно спускающиеся по склону холма" по-прежнему делают то же, что и несколько лет назад?
У тебя похоже какие-то проблемы с чтением или пониманием... Перечитай ещё раз моё сообщение и осознай, что в нём написано прямо противоположное: ситуация за несколько лет полностью изменилась и только парочка редких динозавров осталась верна себе.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Посмотри внимательнее на свою же цитату — это ты перешёл от движков бэкенда (у .net это будет ASP) НС>Чего вдруг ты бэк ASP ограничил?
А для .net есть какие-то ещё популярные движки бэкенда?
_>>>> Так что по факту для разработчика, использующего VS, никакого "вместе" нет — он выбирает что-то одно. НС>>>И? Напоминаю, а то ты опять забыл — речь о поведении МС, а не о поведении разработчика. _>>Так MS в последнее время активно помогает выбрать именно node.js для написания бэкенда. ))) НС>Где он именно ноду помогает?
Эм, вообще то вся наша дискуссия прямо про это.
_>>Однако если мы имеем два конкурирующих в одной области продукта, то активное развитие одного из них в любом случае негативно влияет на другой. НС>Ты забыл о том, что ноду не один МС развивает. Так что твои взаимоисключающие правила не работают.
Эээ что? Негативное влияние будет в любом случае, вне зависимости от того, кому принадлежат продукты.
_>> Это в общем то нормальное рыночная ситуация, но тут у нас есть один принципиальный нюанс: оба продукта принадлежат одной компании НС>Нода не принадлежит МС.
Речь была про TS, который пиарится MS в том числе и для написания бэкендов.
_>>Техническим аргументом от меня была ссылка на инструменты для Node.js в VS.
НС>Там знаешь сколько таких инструментов? Одно время даже для php было. МС, как обычно, придерживается оппортунистической стратегии, поддерживает то, что уже популярно. При этом инструментарий для шарпа на две головы круче инструментария для JS/TS
Ты говоришь про какие-то сторонние модули для VS или про официальные модули написанные MS и рекламируемые на странице VS? Если речь про второе, то я что-то не припомню такого для PHP...
_>> И подобных аргументов я могу накидать ещё множество. Вот навскидку из первых строк гугла репозиторий от MS https://github.com/Microsoft/TypeScript-Node-Starter как раз помогающий проще перейти на данный стек бэкенд технологий. И такого добра ещё полно. НС>Только это никак не доказывает, что все это вместо шарпа.
Повторяю по буквам: ОНО ДЛЯ БЭКЕНДА. И да, оно не только вместо шарпа, но и вместо java, php и всех остальных. Шарп я выделил только потому, что он принадлежит той же компании, что двигает и JS. И это говорит об их отношение к данному языку.
Здравствуйте, alex_public, Вы писали:
_>И что там нового? )
В гугле забанили? Или как обычно, судишь по номеру версии?
_>Помнится игрался (кода запускал тесты на быстродействие) с ним ещё несколько лет назад. И кстати эффект был, но слабенький.
Несколько лет назад была специальная версия, которую выкатили с прицелом на максимальную совместимость. В коре нет такого груза совместимости, и его версия с тех пор ушла очень далеко вперед. Сейчас основное направление развития — tiered compilation.
_>А тут то что? Там не то что нового
Все там есть, просто кто то, как обычно, абсолютно не в теме, но мнение имеет.
_>, а даже старого целиком нет (не смогли сделать весь .net кроссплатформенным и взяли только некий кусок).
И? Оно ж не стоит на месте. К 3.0 все что в принципе имеет смысл — перетащат.
S>>Там реально начался наконец-то движняк, видный невооружённым глазом. _>Скорее напоминает оптимизацию расходов на неактуальное направление. )))
Ну да, если не в теме, то можно какие угодно гипотезы насочинять, факты то полету фантазии не мешают.
Здравствуйте, Sinclair, Вы писали:
S>Видны бешеные темпы развития. Смотреть надо не на "старое", хотя его портирование идёт полным ходом, а на то, что все импрувменты сейчас в первую очередь попадают в Core, а уже потом бэкпортятся в основной фреймворк.
Все несколько печальнее — сейчас в очередной раз пытаются в fw не бэкпортить. Новые net standard и asp.net core старый фреймворк уже не поддерживают. Финита ля комедиа.
T>>т.е. если подытожить, то ничего за эти несколько лет не изменилось, правильно? T>>тебе не опять, а снова кажется, что "только редкие непробиваемые динозавры продолжают игнорировать реальность", в то время как "буйволы, медленно спускающиеся по склону холма" по-прежнему делают то же, что и несколько лет назад?
НС>Я тебе предысторию расскажу, чтобы было понятнее о чем он пишет. 15 лет назад МС начал активно работать над .net, при этом несколько сбавив обороты по направлению к С++. У Алекса от этого полыхнуло, причем полыхнуло столь мощно, что боль не затихла даже спустя 15 лет. НС>И да, он еще тогда всем рассказывал, что пройдет несколько лет, и МС точно так же бросит .net и займется чем то еще. Годы шли, а боль все не утихала, МС, гад такой, продолжал работать над дотнетом. НС>Вот теперь он и пытается найти хоть что то, чтобы успокоить себя прежде всего. То что, помимо ноды, там еще и питончик поддержали, что поддержка ноды на редкость убога и не идет ни в какое сравнение с first citizens по уровню его никак не смущает. Заменяет и точка.
ну, как бы, наверное, всем понятно, что ничто не вечно под луной, и когда-то и WPF и C# и javascript и React уйдут навсегда в прошлое, просто в последнее время я заметил такую тенденцию, что разработка унифицируется и одни и те же самые идеи реализуются практически во всех современных языках, так что казавшийся немыслимым переход с клиппера на си в переводе на нынешние современные реалии, когда нужно перейти с сишарпа на яву , свифт или тот же тайпскрипт, становится вообщем-то вполне себе тривиальным и посильным делом
Здравствуйте, Sinclair, Вы писали:
S>По факту, большинство современных источников данных умеют всё вышеперечисленное, но для того, чтобы им воспользоваться, клиент должен быть умным.
Браузеры достаточно умные?
S>Например, если к нему пристёгнут локальный кэш с поддержкой частичных результатов, то клиент мог бы сэкономить своё время и время сервера, отправляя нужные хидеры.
Всё что я тяну имеет низкий TTL, данные постоянно меняются.
S>А вот написать клиента, который бы работал эффективно, требует вложений.
Да можно хоть исписаться но если сервер плевать хотел на всё то толку?
S>Не отдали вы серверу хидер Accept-Encoding: gzip — и всё, он вам шлёт несжатые данные. S>А вам кажется, что "да мне и не предлагают".
Ну вот браузер шлёт, и не только этот, но ему тоже не предлагают
S>То есть прямо ни один из источников не реализует фичу "скачать в виде файла"? Повезло.
Дык щас практически весь веб данные отдаёт в таком виде, чтоб их JS хавал. Либо JSON либо вообще кусок JS с вкоряченными данными, что особенно буэээ.
Когда то yahoo отдавала данные в CSV, который тоже шёл не аттачем а просто тупо body
CC>>А кто binary hdr шлёт? S>По RFC — можно. По факту — хз, давно не занимался вопросом.
Просто я сколько ни смотрел что там бегает — ни разу не видел.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Все несколько печальнее — сейчас в очередной раз пытаются в fw не бэкпортить. Новые net standard и asp.net core старый фреймворк уже не поддерживают. Финита ля комедиа.
Здравствуйте, vdimas, Вы писали:
НС>>Все несколько печальнее — сейчас в очередной раз пытаются в fw не бэкпортить. Новые net standard и asp.net core старый фреймворк уже не поддерживают. Финита ля комедиа. V>Это из-за отставания netstandart.
[q]
Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core 3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1.
Library authors who need to support .NET Framework customers should stay on .NET Standard 2.0.
[/q
.
Вообще, с фреймворком сейчас беда. Они, к примеру, зачем то переделали коровский фреймворк конфигурации, который под netstd, и выпустили точно такой же под фреймворк, но свой. Когда же был задаен прямой вопрос — нафига, в ответ я услышал только невнятное блеянье, что у них, типа, свои цели.
Здравствуйте, vdimas, Вы писали:
V>Это уже выглядит как преступление. )) V>Бо по изначальной задумке, можно брать таргетом .NET Standard и быть уверенным, что твоя либа заработает везде.
О том и речь. Поэтому остается только констатировать — .NET FW is dead. И главная причина — жуткая неповоротливость CLR Team. Они своей томознутостью вконец достали даже внутренние команды МС.
V>А какие сейчас у клиентов причины сидеть на FW, кроме WPF?
Интероп.
V>Насколько я понял, WinForms уже перенесли на Core.
Нет. В текущем коре нет интеропа нормального. Будет в 3.0, но это еще не меньше года до релиза.
Здравствуйте, reversecode, Вы писали:
R>а вот в том же Го все более тесно и меньше творчества
Не нужен. Когда язык вяжет руки — он выбывает из списка вариантов "на чом писать?"
Да, ты щас начнош "вооот, для бииизнеса, для бооольших групп программиииистов!..." и, внезапно, будешь прав. Меньше творчества в таким случае — более одинаковый код, который проще поддерживать.
Но когда в проекте потом натыкаешься на ограничение и понимаешь что язык был выбран неверно, а бежать назад уже поздно. Ну в общем только локти кусать.
Так что лучший выбор — ограничить творчество программистов правилами проекта, а не языком. Правила можно поправить/дописать/изменить/ужесточить/упростить. Язык в принципе тоже можно, но выйдет сильно дороже, ибо придётся дописывать сам язык.
НС>О том и речь. Поэтому остается только констатировать — .NET FW is dead. И главная причина — жуткая неповоротливость CLR Team. Они своей томознутостью вконец достали даже внутренние команды МС.
НС>Нет. В текущем коре нет интеропа нормального. Будет в 3.0, но это еще не меньше года до релиза.
кстати, по поводу бардака версий: майкрософтская организация всё больше начинает напоминать сборище хипстеров, коим не ведомы ни правила здравого смысла ни нормы приличия: сравним просто .NET 1.1 против, соответственно, 2.0 или 3.5: для любого программиста сразу же ясно, что где есть и как использовать, с нынешней котовасией уже версия .NET CORE 3.0 или какая? отличается ли эта версия от .NET CORE 1.0 , как отличалась .NET 2.0 от .NET 3.5? и если .NET 2.0 до сих пор можно использовать, в CORE набодяжили такое, что сами же, кто набодяжил, рекомендуют выкинуть это уже сейчас 1.0 на помойку? может, .NET CORE 1.0 надо было назвать как-то по-другому ? например: ASPNET4Linux 0.0.1-beta ?
кто-то там ещё знает, что такое альфа, что такое бета, что такое minor, major ?
НС>И, это, начиная с W2K в винде доступен wininet.dll.
Помнится, wininet очень любил выплевывать ERROR_CALL_NOT_IMPLEMENTED или ERROR_NOT_SUPPORTED.
Настолько любил, что от него в итоге пришлось отказаться потому как "меньше чем XP c SP2 мы не работаем" не катило совсем.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я тебе предысторию расскажу, чтобы было понятнее о чем он пишет. 15 лет назад МС начал активно работать над .net, при этом несколько сбавив обороты по направлению к С++. У Алекса от этого полыхнуло, причем полыхнуло столь мощно, что боль не затихла даже спустя 15 лет.
Всё правильно написал, если не обращать внимания на сленг троллей. )
НС>И да, он еще тогда всем рассказывал, что пройдет несколько лет, и МС точно так же бросит .net и займется чем то еще. Годы шли, а боль все не утихала, МС, гад такой, продолжал работать над дотнетом.
А вот тут ты наврал. Ничего такого я естественно тогда не писал, потому что не было ни малейших предпосылок для этого. В то время MS однозначно пыталась продавить .net по всем направлениям (и десктоп и встриваемы/мобильные решения и интернет и даже ОС задумала написать на языке типа C#). Так что всем было очевидно, что там однозначный приоритет на данную технологию.
А вот относительно недавно появились однозначные факты, показывающие что больше такого приоритета нет. Кстати, помнится ты и сам их тут обсуждал и признавал, правда заявляя что это всё вина одного человека (Синофски) и если он уйдёт, то всё снова наладится. Однако он ушёл, а тенденция сохранилась. Хотя конечно теперь технологии не убивают намертво (как с Silverlight например), а сбратывают в опенсорс...).
Но тут главное даже не в закрытие и т.п, а в приоритетах. Кстати, не припомнишь, что первое появилось в поставке VisualStudio, Xamarin или Cordova? )))
НС>Вот теперь он и пытается найти хоть что то, чтобы успокоить себя прежде всего. То что, помимо ноды, там еще и питончик поддержали, что поддержка ноды на редкость убога и не идет ни в какое сравнение с first citizens по уровню его никак не смущает. Заменяет и точка.
О, а тут ты снова пытаешься проделать тот же простенький развод, что и в начале нашей дискуссии. Снова смешиваешь языки и движки. Если бы в VisualStudio поддержали бы например Django, то это действительно было бы аналогом поддержки node.js и конкурентом ASP. Однако в VS поддерживают просто Питон, а не разработку бэкенда на нём. Точнее даже не просто, а как раз ту самую область, где он сейчас однозначный лидер (наука, инженерия, аналитика, ML).
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>А какие сейчас у клиентов причины сидеть на FW, кроме WPF? НС>Интероп.
Обычный интероп у меня работает чудесно и в виндах и в линухах.
V>>Насколько я понял, WinForms уже перенесли на Core. НС>Нет. В текущем коре нет интеропа нормального.
Я пока не понимаю, что подразумевается под "нормальным" интеропом.
На сейчас он динамический, т.е. банально ветвлюсь в коде через InteropServices.RuntimeInformation.
Т.е. платформенно-зависимый код, не предназначенный для текущей платформы, если не дёргается, то и не мешает своим присутствием.
Это когда билдить "единую сборку" для кучи платформ.
Есть еще вариант собирать в один nuget-пакет сразу несколько вариантов одной и той же либы под разные платформы и архитектуры, такие варианты содержат (каждый из них) только интероп-ы для целевой платформы/архитектуры.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Чего вдруг ты бэк ASP ограничил? _>>А для .net есть какие-то ещё популярные движки бэкенда? НС>Для дотнета не обязателен какой то особенный "движок бэкенда". У меня, к примеру, значительная часть кода это обычные windows сервисы/линуксовые демоны. ASP.NET имеет смысл только на самом верхнем слое бэка, который REST отдает.
Ну т.е. нет других популярных.
_>>Эм, вообще то вся наша дискуссия прямо про это. НС>Эм, вообще то нет. То что МС поддержал ноду не означает, что он предлагает ее выбирать вместо шарпа. Основная аудитория этих инструментов — те кто уже использует ноду. И шарпу это скорее помогает, чем мешает. Люди подсаживаются на VS, а потом, когда и если наступает осознание убогости JS, под боком есть нормальное решение.
Ну да, TypeScript... )))
НС>Помнишь 15 лет назад такая штука была, J#? Вот та же самая история и с нодой.
Может ты имел в виду J++? Потому как J# не имел никакого отношения к Java и являлся всего лишь Java-подобной обёрткой для .Net. Так же как например IronPython и ещё множество ненужных языков для .net.
НС>Чтобы действительно речь зашла о вытеснении, нужно чтобы МС либо что то крупное переводил с шарпа на ноду, при этом переключая шарповый вариант в режим поддержки, либо хотя бы что то на ноде стартовало очень крупное без аналога в шарпе. Пока таких фактов не будет, говорить ни о каком вытеснении нельзя.
Хы, ну естественно вытеснение будет происходить не силами одного MS, а с помощью всего IT мира. Тут речь о том, что MS уже явно с этим смирилась и более того, активно пытается поймать новую волну. Нюанс в том, что эти её движения ещё глубже закапывают их старую платформу...
НС>>>Там знаешь сколько таких инструментов? Одно время даже для php было. МС, как обычно, придерживается оппортунистической стратегии, поддерживает то, что уже популярно. При этом инструментарий для шарпа на две головы круче инструментария для JS/TS _>>Ты говоришь про какие-то сторонние модули для VS или про официальные модули написанные MS и рекламируемые на странице VS? Если речь про второе, то я что-то не припомню такого для PHP... НС>Не VS, IIS — https://php.iis.net/
Ха, ну ещё бы у веб-сервера, претендующего на универсальность, не было поддержки исполнения самого популярного веб-языка...
НС>>>Только это никак не доказывает, что все это вместо шарпа. _>>Повторяю по буквам: ОНО ДЛЯ БЭКЕНДА. НС>Повторяю по буквам — ЭТО НЕ ОЗНАЧАЕТ ВМЕСТО.
Здравствуйте, vdimas, Вы писали:
_>>2. Для какой ниши создан движок node.js? Ответ: бэкенд. V>node.js создан для весьма узенькой ниши бэкэнда — наколенной, медлительной и не образующей большой сетки/экосистемы/кластеров. V>Это чтобы можно было какой-нить несложный сервис за пол-дня озвучить. V>Ничего серьёзного на node.js нет и не будет.
Перевода откуда? Если с .Net под винду, то не вижу ничего удивительного...
_>>а другую часть я постоянно замечаю за хвалебными отзывами о JS/TS. V>Это всё хомячки.
Да не важно хомячки это или нет. Главное что 5 лет назад они молились на .net и смеялись над любыми сомнениями в его светлом будущем. А сейчас многие из них точно так же молятся на JS/TS... )))
Здравствуйте, alex_public, Вы писали:
НС>>Для дотнета не обязателен какой то особенный "движок бэкенда". У меня, к примеру, значительная часть кода это обычные windows сервисы/линуксовые демоны. ASP.NET имеет смысл только на самом верхнем слое бэка, который REST отдает. _>Ну т.е. нет других популярных.
Есть и другие, service fabric к примеру. Все зависит от задачи. asp.net и asp.net core просто максимально универсальны.
НС>>Чтобы действительно речь зашла о вытеснении, нужно чтобы МС либо что то крупное переводил с шарпа на ноду, при этом переключая шарповый вариант в режим поддержки, либо хотя бы что то на ноде стартовало очень крупное без аналога в шарпе. Пока таких фактов не будет, говорить ни о каком вытеснении нельзя. _>Хы, ну естественно вытеснение будет происходить не силами одного MS, а с помощью всего IT мира.
Причём что самое главное: один из главных "пихателей" — это MS (автор C#).
НС>>Не VS, IIS — https://php.iis.net/ _>Ха, ну ещё бы у веб-сервера, претендующего на универсальность _>, не было поддержки исполнения самого популярного веб-языка...
С нодой в студии ровно та же история.
НС>>Повторяю по буквам — ЭТО НЕ ОЗНАЧАЕТ ВМЕСТО. _>Ну если тебе хочется в это верить
Это не вопрос веры.
_>, то я тут ничем не могу помочь. Но советую всё же жить не религиозными догмами, а объективной реальностью:
Прошелся по ссылке — ничего масштабного не обнаружил, кроме Убера.
Для примера, второй по масштабности PayPal.
Копнул по нему, вот перевод статьи от 2017-го года: https://habr.com/post/324912/
Там всё еще в бете и в процессе переезда, но сама статья вызывает эмоции рука-лицо со своими графиками на 15-25 единиц одновременных подключений.
Ну и упоминается, что нода юзает при этом одно ядро.
Ес-но! ))
Остальное, из разряда "LinkedIn, ... last year they moved their mobile app backend from Ruby on Rails to Node.js" или внутреннего тестового фреймворка в NetFlix даже обсуждать бесполезно.
В общем, всё мимо.
"Walmart ... re-engineered the mobile app"
И т.д.
По Uber.
Закат солнца вручную, полностью своя с 0-ля распределённая инфраструктура RPC на своих p-2-p, которая в пике даёт аж 2 млн внутренних RPC-вызовов в секунду, дословно, на "всём флоте Node.Js серверов".
Это эпик фейл, Карл.
Это грёбанный стыд.
И да, в моей формулировке было "В этой реальности не существует достаточно больших проектов, писанных на TS."
На TS я ничего заметного так и не нашёл сегодня, как и год назад, когда искал последний раз.
V>>Из первых рук (моих). V>>Тоннами запросы от клиентов на перевод наших продуктов на .Net Core под Линуха. _>Перевода откуда? Если с .Net под винду, то не вижу ничего удивительного...
Перевод из плюсов на дотнет-корку под линуха.
_>Да не важно хомячки это или нет. Главное что 5 лет назад они молились на .net и смеялись над любыми сомнениями в его светлом будущем. А сейчас многие из них точно так же молятся на JS/TS... )))
Я что тогда всерьёз "молящихся" не воспринимал, что сегодня.
Если ты профик, ты жуткий циник относительно технологий.
И непременный пессимист, бо хотя бы немножко знаешь подробности изнутри, а многие знания — многие печали. ))
А вот это всё — хомячки, т.е. пользователи технологий, причём, самая маргинальная часть из них.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Я пока не понимаю, что подразумевается под "нормальным" интеропом. НС>Например поддержка CCW/RCW
Было бы что дёргать из под линухов под CCW.
В любом случае, есть возможность самим описать нейтивные интерфейсы IUnknown и далее по наследованию и дёргать эти интерфейсы самому, если даже некоторую ответную COM-часть портировали под линуха.
Если же под винды-онли, то смысла в core пока не много, согласен.
Здравствуйте, vdimas, Вы писали:
V>>>Я пока не понимаю, что подразумевается под "нормальным" интеропом. НС>>Например поддержка CCW/RCW V>Было бы что дёргать из под линухов под CCW.
Не линухом единым.
V>Если же под винды-онли, то смысла в core пока не много, согласен.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>>>Я пока не понимаю, что подразумевается под "нормальным" интеропом. НС>>>Например поддержка CCW/RCW V>>Было бы что дёргать из под линухов под CCW. НС>Не линухом единым.
Листать до private class AsioDriverVTable
Метод выше автоматически заполняет VTable.
Это способ вызывать любые виртуальные С++-методы, не только COM.
Но в том числе и COM, ес-но, если встроенная поддержка хромает.
Пример интересен тем, что COM-интерфейс ASIO-драйверов не является OLE-совместимым, поэтому не может быть использован через стандартный COM-Interop.
UPD2
Хотя оно и выглядит немного "страшно", генерирование таких описаний требуемых интерфейсов, ес-но, может быть автоматизированно develop-time утилиткой, писанной на десктопном .Net Framework.
Здравствуйте, alex_public, Вы писали:
V>>>>Ничего серьёзного на node.js нет и не будет. _>>>Ну да, ну да. ))) _>>>https://www.netguru.co/blog/top-companies-used-nodejs-production V>>Прошелся по ссылке — ничего масштабного не обнаружил, кроме Убера. _>Т.е. Netflix и Ebay — это не масштабное? )))
Нужны подробности, чтобы оценить масштаб.
Бо по Netflix пока известно, что сделали на ноде персональную страничку аккаунта юзверя.
Как часто юзверь заходит на страницу аккаунта?
Думаю, почти никогда.
_>P.S. А больше всего в данной дискуссии меня забавляет то, что я в ней выступаю в роли "защитника" JS, хотя меня самого от этого языка и окружающего его стека технологий подташнивает. ))) Вот что значит пытаться быть объективным...
. Я как раз об этом и говорил изначально: "крайне редко про новые, молодые и активно развиваемые проекты". Можешь сравнить с трендами в Python, Go, Rust, просто обрати внимание что в тренде.
