Здравствуйте, 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 для простых или просто желающих.


_>Уже можешь сам выводы сделать или всё ещё нет? )

Учитывая новомодные тег-хелперы + Разор, теперь на полноценом ASPI 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:

class UnmanagedMemory : MemoryManager { byte * _mem; uint _size; ... }

При том, что сам объект UnmanagedMemory перемещаемый в управляемой куче, но указуемая им память фиксированная, что позволило портировать string_view вместе со всей обвязкой. Неуправляема память жива до тех пор, пока жив хотя бы один ссылающийся на неё объект, это реализовано в порождаемом через MemoryManager объекте Memory<>.

Весь ввод-вывод теперь доступен через Span<byte>, поэтому можно больше не оперировать дотнетными массивами.
В общем, где раньше у меня был код с нейтивными указателями и всякими графами объектов на них, он такой и остался.
Потому что теперь такой код заходит архигладко в остальной дотнетный код.
И эффективность примерно та же.


2. "Compile-time" трейты:

interface IConstant<T> { T Value { get; }  }

static class SomeOptions {
    public class Option1 : IConstant<bool> { public bool Value => true; }
    public class 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 — это примерно того же порядка явление, как в специализированном алкомаркете еще продают соки и воду.
Чтобы клиентам не было надобности идти еще в другой магазин.

Здравствуйте, 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 для простых или просто желающих.


_>Уже можешь сам выводы сделать или всё ещё нет? )

Учитывая новомодные тег-хелперы + Разор, теперь на полноценом ASPI 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:

class UnmanagedMemory : MemoryManager { byte * _mem; uint _size; ... }

При том, что сам объект UnmanagedMemory перемещаемый в управляемой куче, но указуемая им память фиксированная, что позволило портировать string_view вместе со всей обвязкой. Неуправляема память жива до тех пор, пока жив хотя бы один ссылающийся на неё объект, это реализовано в порождаемом через MemoryManager объекте Memory<>.

Весь ввод-вывод теперь доступен через Span<byte>, поэтому можно больше не оперировать дотнетными массивами.
В общем, где раньше у меня был код с нейтивными указателями и всякими графами объектов на них, он такой и остался.
Потому что теперь такой код заходит архигладко в остальной дотнетный код.
И эффективность примерно та же.


2. "Compile-time" трейты:

interface IConstant<T> { T Value { get; }  }

static class SomeOptions {
    public class Option1 : IConstant<bool> { public bool Value => true; }
    public class 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 — это примерно того же порядка явление, как в специализированном алкомаркете еще продают соки и воду.
Чтобы клиентам не было надобности идти еще в другой магазин.