Здравствуйте, Максим Зелински, Вы писали:

МЗ>Надо написать такую, есть выбор между C++ (производительность) и C# (простота разработки).
C++ — даже не думай об этом.

МЗ>Нюанс в том, что эта erp — по сути "конструктор" (наподобии 1С или Axapta). Если брать С++ то надо писать парсер маппирования данных, новую компонентную систему (COM/CORBA не подходит). Рвусь писать на .Net — так как это там всё гораздо проще, но вот его производительность и прожорливость меня останавливает.
Забей. Во первых, языки дотнета довольно шустры, посмотри тесты. На численных расчетах они на равных с С++.
К тому же, все равно твоя еэрпя упрется в базу данных, это не численные методы. Это во вторых. Если ты запустишь профайлер на 1С-коде (там очень тормозной интерпретатор), ты сможешь сам увидеть раскладку 90/10%. Да и вообще, такая раскладка имеет место быть в большинстве правильно написанных приложений БД. Это если говорить о двухзвенке.

В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака) того стоит, чтобы на него плюнуть, не говоря о том, что ты просто его не заметишь. К тому же, аллокатор дотнета работает в целом лучше, чем стандартный плюсовый . Бояться надо другого. Большие boxed массивы маленьких объектов — в этом проблема (решаемая), а не в сборщике мусора.

Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.

МЗ>зы. Я буду писать в комманде (я главный архитектор), у меня есть как С++ программисты, так и C# программисты. Бяков утечек памяти/крахов указателей я от С++ не жду.
А это как раз не проблема. Ты с компонентной моделью и скриптингом гораздо больше натрахаешься.