![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Ад дотнета
Тут недавно выпустили akka.net, которая, по идее, сможет решить большую часть проблем с асинхронным обменом сообщениями для моего софта.
Сижу читаю всякое по теме, набрел на такую ссылку: http://www.aaronstannard.com/the-profound-weakness-of-the-net-oss-ecosystem/ - это один из разработчиков akka.net, занимавшийся ее remoting-кишками.
Вкратце: "если на дотнете делать что-то сложное и осмысленное - садись и пиши фреймворки с нуля, потому что индусам и микрософту ничего этого не надо".
Еще одна забавная хрень оттуда же: они подумали и вместо переезда своего приложения с дотнета на jvm, решили спортировать акку с jvm на дотнет. Это только с первого взгляда выглядит странным в рамках религии "мы не занимаемся изготовлением инструментов", но если сравнить приложение со сложной бизнес-логикой, разрабатываемое 2-3-5 лет и фреймворки - может оказаться, что портировать вторые потребует гораздо меньше времени.
Сижу читаю всякое по теме, набрел на такую ссылку: http://www.aaronstannard.com/the-profound-weakness-of-the-net-oss-ecosystem/ - это один из разработчиков akka.net, занимавшийся ее remoting-кишками.
Вкратце: "если на дотнете делать что-то сложное и осмысленное - садись и пиши фреймворки с нуля, потому что индусам и микрософту ничего этого не надо".
Еще одна забавная хрень оттуда же: они подумали и вместо переезда своего приложения с дотнета на jvm, решили спортировать акку с jvm на дотнет. Это только с первого взгляда выглядит странным в рамках религии "мы не занимаемся изготовлением инструментов", но если сравнить приложение со сложной бизнес-логикой, разрабатываемое 2-3-5 лет и фреймворки - может оказаться, что портировать вторые потребует гораздо меньше времени.
no subject
no subject
no subject
no subject
no subject
no subject
В википедии - вроде есть: http://en.wikipedia.org/wiki/Actor_model но все запилены достаточно недавно, или заброшены или альфа.
Большинство .net разработчиков имеют именно такой mindset - если этого нет в микрософте, значит это никому не нужно, а писать свое ни в коем случае нельзя и садятся делать синхронные crud-сервисы из подручных материалов. Ну или переходят на жабу со скалой.
no subject
no subject
Дотнетчики выбирают второе, т.к. первое для них - табу. И это чисто .net-специфика.
no subject
Ну и стереотипы не всегда работают. Разные задачи, разные люди, те же линуксоиды или жависты - тоже притча во языцах, но случаи бывают разные.
no subject
Ну, например, я например реально слышал что-то типа "ну ты навернул функциональщины" за вот такой примерно хелпер:
T Run(this Logger log, string description, Func fn) {
.. таймеры-логирование-try
fn();
.., catch и записать исключение, сколько времени заняло, и т.п.
}
От такого подхода, со временем, мозг отключается до того состояния, когда кроме CRUD он вообще ни на что не способен.
no subject
no subject
no subject
В любом софте есть масса нюансов, которые определяют как именно этот софт удобнее, быстрее и качественнее писать. Разработчики стороннего софта, в принципе, эти нюансы учесть не могут. Поэтому утверждать об абсолютном вреде велосипедостроения, как минимум, глупо и некомпетентно.
no subject
no subject
no subject
no subject
no subject
no subject
Потому что пример вот этих вот ребят как раз. Я пробежался по остальным постам в этом же блоге и ситуация складывается весьма забавная: с начала используя линукс как платформу запуска и Hadoop+Hive для map/reduce, они занимались прикладным дрочерством и писали аналоги уже существующих вещей или всё-таки брали уже существующее (как Cassandra против первоначального RavenDB). И после всех этих радостей оказалось, что их стартап не успевает делать бабло и софт под запросы рынка.
Также, в камментах к этой записи виден denisio, чей дотнет головного мозга говорит сам за себя не первый год.
no subject
Есть типа IIS, который сложно заставить просто не выключаться. Т.е. какие-нибудь фоновые процессы там нельзя хостить. Не говоря уже о том, .NET туда воткнут откровенными хаками.
Есть windows services, которые надо руками каждый раз прикручивать, придумывать как их деплоить, как мониторить.
Т.е., грубо говоря, в дотнете нет Application Server-а. Какие там в жопу асинхронные агенты?
no subject
Можете подробнее?
capcha: no-brainer
no subject
Вне обработки запроса считается что сервисы никак не существуют, т.к. никакого состояния у них нет.
В приложении, где хостятся сервисы, состояние может быть, но при рестарте воркеров оно теряется, его надо где-то отдельно хранить.
А вещи вроде "раз в 10 минут выполнять какую-нибудь обработку" в таком варианте вообще поместить некуда.
no subject
no subject
no subject
no subject
no subject
The paramount technical challenge facing the majority of .NET developers today looks like building Web APIs that serve JSON over HTTP, judging from the BUILD 2014 sessions. Distributed computing, consistent hashing, high availability, data visualization, and reactive computing are concepts that a virtually absent from the any conversation around .NET.
...
Compare this to the Java ecosystem: virtually every major .NET project is a port of something originally evented for the JVM. I’m looking at you, NAnt, NUnit, NuGet (Maven), NHibernate, Lucene.NET, Helios, Akka.NET, and so on
:)
PS: капча внезапно доставляет
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
.net... jvm... C/C++!
no subject
no subject
no subject
no subject
no subject
А религиозные фанатики реюза говна и менеджеры с "мы же не должны писать для себя инструменты" должны сдохнуть.