Comments 545
Ага когда выпустили .NET говорили что он убьет java очень скоро, мс даже спец программу организовало JUMP — Java User Migration Path. Не выгорело тогда, не выгорит и сейчас. MS с core конопашуться уже больше года, у java jigsaw должен выйти этим летом, не все так просто.
Выбор есть и сейчас. Вы уж простите но слышать о здоровой конкуренции в отношении MS как то без тика не получается.
Не Oracle единым жива java, хвала аллаху.
смешно видеть на этой картинке JetBrains, которые даже под .net (resharper) пишут на Java/Kotlin ;)
Java заняла нишу enterprise когда oracle был ещё не при делах. Тогда это был ещё Sun.
Уточню — целиком на .NET. Проект Rider — не то. Хотя если имплементировать какой то бекэнд, который сможет воспользоваться наработками Rider…
Там Visual Studio еще не портировали на Linux?
Какое отношение эта гипотетическая IDE имеет к энтерпрайзу?
Уточню — это лишь мое мнение, но в любом случае — в чем то же надо писать код? Пока что я не вижу IDE уровня IntelliJ IDEA или Visual Studio под эти платформы (да даже не важно на чем оно написано). Ежели я ошибаюсь — прошу меня поправить и указать на мою ошибку ссылкой.
Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.
Используют же некоторые дизайнеры MacOS чтобы рисовать интерфейсы под винду...
В случае «пилим кговавый ынтерпрайз, работающий на сервере в виртуальной машине» ИМХО вообще пофигу на среду, к которой пишем. И довольно значительный процент явистов, пишущих в винде тому подтверждение.
Мне не повезло познакомится с линуксом в раннем возрасте и учиться писать код я начинал именно с линукса. С тех пор родовая травма — не могу использовать Windows для разработки. Точнее могу, но это неприятно.
Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.Мешает. Для того, чтобы использовать «default operating system» в местах, где она не «default» нужна уйма инфраструктуры. Kerberos и LDAP использовать нельзя, нужны сервера на Windows и масса плясок с бубнами, чтобы две операционки подружить. Это для начала. А потом выяснится что и принтеры нужно особо поддерживать и прочее.
Понятно, что живущие в «default operating system» об этом не задумываются (как и живущие в «default city»), но Microsoft Windows — это «остров, у которого всё своё». Собственно это специально сделали — и этот подход отлично работал: стоит вам использовать хоть что-то от Microsoft — и вам придётся использовать массу других вещей от них же. Но в Enterprise — всё не так: не нужен там никакой Microsoft (у них Oracle рулит и стонут они от него так же, как от Microsoft'а стонет малый бизнес — но это другая история), так что IDE под «default opertaion system», извините, не вариант.
Собственно Microsoft это осознал примерно тогда же, когда и все остальные — но, увы, если «стены» стоить десятилятеями, то дальше их разрушить за пару лет — не выйдет.
Э… а конкретные примеры того, что нельзя подружить, будут?
Для меня, как для программиста, все довольно понятно — есть задача, есть протокол/формат/что-то еще, есть библиотека, пишу решение. Если нет библиотеки — пишу решение дольше, с перспективой создания библиотеки.
В какой момент возникают пляски с бубнами, которые не позволяют мне писать решение для задачи?
Э… а конкретные примеры того, что нельзя подружить, будут?А того, что написано выше — недостаточно?
В какой момент возникают пляски с бубнами, которые не позволяют мне писать решение для задачи?В тот момент, когда вы решили, что хотите использовать «default operation system».
Вспомните ещё раз: мы тут про «ынтырпрайз», да? Ну и хорошо, понеслась. Для доступа в Internet — у вас какой-нибудь Uberproxy с правами доступа в LDAP и авторизацией через Kerberos. Печатаете вы через CUPS, общие файлы — выкладываются на NFS, а управляется это всё — через Ansible.
И вот вы во всё это желаете вкрутить вашу «default operation system». Кто будет «дружить» эти два мира? Притом, что Windows-админы, которых вы можете найти на рынке обычно — «ни в зуб ногой в области POSIX-технологий», а POSIX-админам — ваши «default operation system» со всеми их заморочками — не нужны от слова «совсем»?
Все еще не понимаю, зачем в такой структуре нужны виндовые серверы.
А, я понял. Вы рассматриваете гипотетическую ситуацию, когда какая-то совтописательная фирма с инфраструктурой только на линуксе пытается начать писать на .NET.
Да, это может внезапно оказаться довольно сложным процессом.
Но конкретному разработчику, в отличие от организации, перейти на новый язык довольно просто. Достаточно всего лишь его выучить, после чего найти себе новое место работы.
Вот я и пытаюсь понять, они немного преувеличивают, преувеличивают нагло или же все хорошо и можно писать код?
Пока что получается, что преувеличивают нагло и среднестатистический разработчик не желающий использовать Windows удобным образом писать под .NET не сможет. Согласны?
Ну подумайте сами: какой смысл Microsoft'у делать хоть что-то для того, чтобы улучшить жизнь разрабочиков, использующих не Windows?
Но конкретному разработчику, в отличие от организации, перейти на новый язык довольно просто.Читаем заголовок статьи, которую мы тут обсуждаем, да?
Через год-два .NET Core потеснит Java на рынке enterprise решений
Это у вас «конкретный разработчик» не связанный ни с какой организацией играет на рынке «enterprise решений»?
Все проекты делаются конкретными разработчиками.
Разработать без интеграции с существующими решаниями вам дадут разве что «приложение» для заказа пиццы в офис. Во всех остальных случаях — я придётся учитывать и ограничения вещей, созданных 40 лет назад на Cobol'е и 10 лет назад на Java.
Удобный язык программирования — это вполне достаточный повод купить винду, IDE и даже новый компьютер. Если вы и правда квалифицированный энтерпрайз-разработчик, чье время ценно.
Если вы и правда квалифицированный энтерпрайз-разработчик, чье время ценно.Если вы «квалифицированный энтерпрайз-разработчик, чье время ценно», то вы в гробу видали «винду, IDE и даже новый компьютер», зато, возможно, неплохо знаете Cobol.
В мире энтерпрайзра Windows — так и не стала «default operation system», несмотря на все потуги (если бы стала — рассказов про то, что она вот-вот «всех порвёт на энтерпрайз-рынке» не было бы). Так что вам, в прикуску к «новому языку» придётся одновременно изучить новую OS и новую IDE.
То есть вы должны быть фактически готовы переехать в другую страну, выучить новый язык, сменить машину, работу
Вы точно уверены, что вы всё ещё «квалифицированный энтерпрайз-разработчик, чье время ценно», а не «безбашенный стартапер, которому семь вёрст не крюк»?
В мире энтерпрайзра Windows — так и не стала «default operation system»
AD и Exchange есть у всех, даже в Яндексе с Фейсбуком.
Non-authoritative answer:
Name: exchange-2013.yandex-team.ru
Addresses: 2a02:6b8:0:3400::1:25
213.180.205.25
Aliases: autodiscover.yandex-team.ru
amber.yandex-team.ru
amber-2013.yandex-team.ru
Подробности надо спрашивать у яндексоидов, думаю оставили для бизнеса привыкшего к удобству: достойных конкурентов связке Outlook + Exchange так и не появилось.
Спасало только наличие неплохого GUI в IntelliJ IDEA. Любой шаг в сторону от стандартного флоу «закодил — > запустил тесты -> закоммитил» был тяжек и труден. Все что в линуксе решается в одном окошке консоли на винде требовало больше усилий и движений. В гробу я видал Windows 7 как ОС для разработки на Java.
Если работа в энтерпрайзе требует работы на винде — к черту такую работу, я лучше продолжу писать тулы по автоматизации тестирования или переквалифицируюсь хипстеры :)
P.S.: Удобное рабочее окружение — это повод купить Mac. Однако не все могут согласиться с этим.
Пытаюсь вспомнить какие лишние движения мне приходится совершать при ежедневной разработке — и не могу. Разве что установка нужных программ вспоминается — но она делается всего один раз.
Мне кажется, это просто сказывалась субъективная непривычность обстановки, а не какие-то объективные недостатки.
Не могли бы вы уточнить что именно требовало у вас избыточного числа движений?
- Работа с Git
- Работа с удаленными серверами по SSH
- Сборка проекта с нестандартными параметрами
- Обработка данных при помощи простеньких скриптов
Поясню на примере — для выполнения этих задач в Linux мне требовалось всего одно окошко терминала в котором я мог все эти задачи выполнить одинаково хорошо. В Windows это требовало 4 разных окошек — Git Bash, SuperPutty, окошко запуска команд в IntelliJ IDEA и наконец Cygwin. Половина из этих инструментов не кастомизировалась или кастомизировалась весьма не просто в плане внешнего вида(банальные шрифты).
Этого достаточно?
Для всех этих задач вполне достаточно одного окна, раз уж для вас это так важно.
Для начала, Git Bash для работы с Git не обязателен.
Далее, никто не запрещает вместо Putty (кстати, что это за сборка такая — SuperPutty?) использовать OpenSSH, тем более что ssh.exe идет вместе с git.
Сборку проекта можно делать в том же самом окне если правильно прописать переменные окружения.
Для четверной задачи, раз вы привыкли к linux-окружению, конечно же придется использовать cygwin… Вот только cygwin не отбирает у вас возможность использовать git, openssh и собирать проект в том же самом окне.
Да и выглядит это все как то не очень красиво (я сейчас именно про внешний вид), возможно из-за ограничений виндового терминала.
Ну, это больше ограничения стандартных шрифтов. И стандартного же cmd.exe. Те же git bash или консоль cygwin выглядят довольно неплохо, на мой вкус.
Говорят, еще в десятой винде консоль значительно переделали. Но сам я десятку еще не трогал, сижу на семерках-восьмерках.
P.S.: Хабрасуицид совершен успешно)
Все дело в привычках. Банальная вставка по средней клавиши мыши(отвыкать пришлось долго). Удобный и красивый эмулятор терминала. И много других мелочей которых нет на тех версиях Windows, с которыми я работал и которые есть в Linux. Ну и разумеется отсутствие привычного софта без костылей для установки и использования.
Аналогично можно расписать неудобства Linux — отсутствие привычного софта, установка ПО из репозитария через GUI либо командную строку, настройка определенной части оного путем редактирования текстовых конфигов вместо удобной GUI. Да даже банальная структура директорий непривычна. Все это влияет на удобство и сложность использования.
Возможно, Windows 10 многое изменит, но когда она еще попадет на рабочие места в кровавом энтерпрайзе? Я искренне радовался выходу Ubuntu on Windows. А потома до меня дошло, что большая часть работодателей вряд ли в ближайшее время запланируют апгрейд. И следовательно смысла в этой подсистеме не очень много.
Вставку по средней кнопке в протоколе Нового Более Лучшего Дисплейного Сервера убрали, кстати. Во всяких федорах её сбоку изолентой прикрутили
Я искренне радовался выходу Ubuntu on Windows.Это не клиентская фича, она работает только в режиме разработчика.
Возможно, Windows 10 многое изменит, но когда она еще попадет на рабочие местав кровавом энтерпрайзе?Так что перенаправьте вопрос TheKnight, зачем ему Ubuntu на клиентских виндах.
Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.
Использовать можно. Удобно — далеко не всегда. Можно конечно пользоваться виртуалками, но это опять таки менее удобно получается. Всякие hot redeploy и прочее далеко не всегда работают сквозь виртуалку.
Напомню, мы говорим об энтерпрайзе. Тут считается нормальным купить за большие деньги Talend MDM, который идет со своей Talend MDM Studio на базе Eclipse и не имеет консольных утилит для сборки (прощай, CI и CD!), и посадить опытных Java-разработчиков парсить XML-документы регулярками, потому что другого API не завезли.
И чтобы жизнь медом не казалась, надо загнать всех на удаленную работу через тормозной и глючный VPN, работающий только через IE на терминальный сервер, где один экземпляр Talend MDM Studio выжирает по 2 гига памяти, а их запущено пять штук...
А когда настанет время развертывания релиза на стенде интеграционного тестирования — то десять тысяч документов будут загружаться напрямую в базу вручную разработчиками потому что Talend на таких объемах умирает.
А другой разработчик будет их же публиковать на портале, потому что интеграция не работает в этом режиме.
И после этого вы жалуетесь на какие-то виртуалки? Между прочим, на хорошем железе виртуалки довольно шустро работают, даже если внутрях — серверная винда с Sharepoint… Тоже, кстати, тормозная хрень, но хотя бы память не выжирает и CI поддерживает.
Рассуждения "у кого-то процесс разработки построен через жопу, поэтому мы тоже через жопу делать будем" порочны по самой своей сути.
А виртуалки мне не нравятся не из-за тормознутости (вот как раз эта проблема решается легко).
Вот один пример из жизни пример — на одном из проектов были тесты, которые нормально работают только под линукс. А разработка под виндой. Как результат нельзя просто взять и запустить тесты из IDE. Можно запустить из консоли через билд систему (maven), но там запускаются все тесты, а прогон всех тестов занимает минут 20-30. Да, это можно решить отдав правильные аргументы maven'у, но все-равно неудобно. Ну и запустить таким образом тесты с дебагом становится отдельным испытанием.
- EAP — релиз обещали осенью 2016, ЕМНИП
- Не чистый .NET
- Из-за некоторых технических решений является пруфом(возможным) того, что .NET Core из коробки нельзя использовать для определенного класса задач совсем. Подразумевается написание десктопных приложений.
В остальном я верю в JetBrains и в то, что у них выйдет офигенный инструмент. У меня и претензий то к нему нет, есть претензии к отсутствию аналога написанного целиком на .NET.
P.S.: [humor]А как прописывается тег хабрасуицид?[/humor]
Кроме того хочется переиспользовать имеющиеся наработки и просто портировать приложение внутри одной платформы, не переписывая его целиком на другом языке.
Тем, что он не является полноценной заменой Visual Studio:
- Он будет платный, тогда как VS бесплатна даже для использования в небольших коммерческих проектах.
- Не поддерживает несколько языков в одном солюшене.
- В стадии EAP: имеет ряд багов, тормозит на больших проектах и файлах, которые VS тянет легко.
- Имеет очень слабый функционал по отладке приложений по сравнению с Visual Studio:
- слабый Expression Evaluation (нет поддержки пользовательского отображения значений);
- нет нормальной поддержки асихронных задач (невозможность пошаговой отладки при использовании async/await);
- нет остановки в момент выброса любого исключения (проблему в разы быстрее решить прямо на месте, чем изучать стектрейсы).
Лично для меня эти моменты очень приципиальны. Поэтому для написания кода я обычно использую Rider, но если нужен отладчик — переключаюсь в VS.
ормозит на больших проектах и файлах, которые VS тянет легко.
В нашем solution (150 проектов, WPF, Xamarin), тянет на ура. При вытягивании изменений из гита, за 1-2 секунды готов уже к работе, тогда как студия с трудом переживает внешние изменения в более чем 2-3 проектах. Как правило выжирает 2гб оперативной памяти и зависает.
Райдер (не холодный запуск) за 5с открывает наш solution, тогда как студия (2015) 30-40с.
Никаких тормозов уже не наблюдаю. 2 месяца пишу только в нем.
Последние 2-3 EAP стали вполне рабочими, хотя баги встречаются, но не были для меня принципиальными.
Да дело далеко не только в IDE. И вообще не в языках. Я бы лично хотел посмотреть на хоть какой-то аналог OSGI. Или ESB (что-нибудь вроде Camel). Или я не туда смотрю — но ничего подобного вобще не попадается на глаза.
OSGI -> AppDomains
ESB -> WCF
Конечно они не идентичны, но решают похожие задачи
Насколько я понимаю (хотя тут я могу ошибаться), WCF далеко не аналог шине в нормальном ее виде. Т.е. скажем это ближе к Apache CXF, в лучшем случае, а до Karaf + Camel + CXF + MQ, так как выглядит нормальная шина в мире Java, ему как до луны.
Вот насколько они не идентичны — настолько .Net code Java и потеснит в энтерпрайзе :)
Все дело в том, что значит "нормальная".
Когда я делал корпоративное ПО на java, я тоже так считал, но потом у меня появилась возможность сравнить.
В java нет такого понятия как сборка (Assembly — the smallest unit of versioning, security, deployment and reusability of code in .Net.)
Из этого маленького нюанса растут все различия в корпоративных фреймворках для .net и jvm.
Например, в .net не аналога Camel, не потому что он "не энтерпрайзный", а потому что нет самой проблемы которую он призван решить. Поэтому же нет прямого аналога OSGI. WCF+IOC+MQ-брокер + AppDomains, как изолированная среда, это примерный аналог.
Я не вижу такой технической проблемы в корпоративном ПО, которую невозможно/сложнее решать на .net, чем на java. Просто используется другой набор фреймворков, немного другие подходы.
Думаю посыл статьи в том, что с приходом .NETStandard 2 все это добро будет доступно на unix-системах, вот и получается прямая конкуренция.
Что значит "нет проблемы", которую решает Camel?
Camel не решает технические проблемы JVM или языка — он решает бизнес проблемы интеграции. И аналоги у него есть совершенно прямые — например MS SSIS. И это не просто ужас, а ужас-ужас-ужас. Это я не к тому, что решения от MS плохие, а к тому, что есть бизнес проблема интеграции, которую пытается решать например SSIS, и решает ее по сравнению с Camel ужасно. Суть в том, что потребность есть, и еще какая.
OSGI в общем-то тоже — потому что проблема иметь независимые взаимодействующие компоненты называйте их как хотите, но не будете же вы утверждать, что возня вокруг "микросервисов" происходит на пустом месте?).
Так вот OSGI — это и есть микросервисы в чистом виде. IOC ему кстати не замена, а лишь маленькая его часть.
Ну и кстати в разрезе IDE — меня лично гораздо больше волнуют другие инструменты, потому что после maven/gtadle/чего угодно такая штуковина как MSBuild просто выводит из себя.
А что у вас с MSBuild? В принципе после прочтения пары док вполне неплохо. Собираю им сложные проекты, в него же уехали gulp, npm, webpack и куча PS скриптов.
SSIS — это хрень, которую продают никогда не писавшие кода маркетологи никогда не писавшим кода архитекторам.
Не следует по этой хрени судить о экосистеме .NET, тут есть и более приятные вещи.
Я его привел исключительно в качестве примера наличия потребности, которой якобы нет.
Честно говоря, я не понимаю какую потребность предполагается решать с помощью SSIS, потому что оно ничего не решает. Под словом же "интеграция" иногда подразумеваются совершенно разные вещи...
Ну, типичный кейс выглядит как-то так — есть несвязанные между собой изначально системы. Нужно как-то их связать, передавая данные. Как принято, на входе с ними работает процесс ETL. Он может принимать файлы, а может таблицы из другой базы. И на выходе может делать разное. Как мне тут намекнули, WCF все-таки очень похожая штука — есть endpoints, которые являются входами и выходами, и есть некие маршруты обработки и передачи данных между ними (обычно именуемые EIP).
Вот эти вот ETL на нем и пишут. В моем проекте я ровно тоже самое делал на Camel, при этом значительно удобнее.
Опять же — это не довод за то, что какие-то там другие решения плохи или хороши — это довод именно за то, что потребность в разного рода ETL очень широкая.
Я про банки, если что...
Нет, WCF — это не про ETL. WCF — это про SOA.
У меня был опыт работы с ETL, и я считаю, что самый лучший формат для ETL-процедуры — это обычное консольное приложение.
Возможно, это связано с тем, что в мире .NET и правда нет хорошего инструмента для этих целей. А возможно, это связано с тем что мне приходилось выполнять одновременно работу программиста и системного администратора, и все те вещи, которые создавались для перекладывания работы с первых на вторых, лично мне работы лишь добавляли.
А какая разница, SOA или нет, если там реально есть EIP? На входе например клиент SOA, потом маршрут обработки, потом какой-то выход. Если входы и выходы хоть как-то настраиваются, и есть какой-никакой язык для описания маршрутов (ну скажем, годится BPEL), то это и будет в конечном счете ESB или шина. Все же ETL это как правило некий клей для сервисов, написанных разными командами, и для этого удобнее средства типа скриптовых языков, или похожие инструменты.
Что же до консольного приложения в качестве ETL, то оно как бы и нормально, пока у вас их два. А когда их двадцать два, ими надо рулить, хотя бы в объеме чтобы само запустилось после рестарта сервера. Ну и как вы представляете себе 22 микросервиса в виде сервисов windows, например? Ну и потом, они могут быть хоть и независимые друг от друга по логике, но все равно зависимы по данным (например, на 100 сервисов порядка 10 коннектов к разным базам), поэтому настраивать теже коннкеты все-таки проще один раз, нежели для каждого из 100 микросервисов помнить, какая у нас тут база, это PROD или тестовый сервер, ну и все такое.
Ну то есть если совсем просто — то ESB или шина это обычно куча мелких сервисов интеграции, но с централизованным управлением и мониторингом.
Какой нафиг язык для описания маршрутов? Какой клей? Не выдумывайте чего не знаете. WCF — это библиотека для написания веб-сервисов, и ничего более.
Это вопрос не ко мне. Про наличие там EIP не я придумал. Отмотайте комменты, да посмотрите.
@dimaaan 28 апреля 2017 в 18:40
Я лишь хотел сказать, что EIP типа Каналы сообщений, Pipes, Filters, Router, Translator, Endpoint это все тоже часть WCF
Так вы договоритесь между собой, есть в WCF pipes, filters, или нету? Если есть — то то и есть маршруты.
Это случайное совпадение — одни и те же слова используются в разных смыслах. Тот кого вы цитируете увидел знакомые слова и сказал что это все есть.
Повторюсь: WCF — это библиотека для написания веб-сервисов или подключения к ним, а не платформа для их интеграции
Я совершенно не специалист в WCF, но по-моему вы как минимум упрощаете. Я видел в документации (а не в комментах) и упоминание workflow, и message filters, и много чего еще, что явно не является веб-сервисами, а именно интеграцией. Это конечно может быть случайным совпадением, но MS в явном виде упоминает в доках на WCF как EIP вообще, так и конкретные паттерны, со ссылками на их реализацию.
Workflow — это отдельная библиотека, WWF (Windows Workflow Foundation).
Message filters и routing в WCF действительно есть — но нет инструментов для трансформации сообщений. И никаких аналогов биндингов из вот этого списка кроме трех там тоже нет.
Что же до ETL, то постоянно они работать не должны, ETL это по определению пакетная обработка по расписанию.
Для 22 ETL-процедур за глаза хватает одного консольного приложения с одним конфигом, нет необходимости разводить 22 отдельных проекта до тех пор, пока их разрабатывает один разработчик.
Запускать их можно через системный планировщик или через MS SQL Server Agent. К слову, те же джобы SSIS или Pentaho запускаются точно так же, в этом плане запуск консольного приложения ничем не отличается от того что предлагают якобы профессиональные инструменты.
Зато консольное приложение:
- проще в отладке и настройке;
- пишется на богатом на возможности статически типизируемом языке с возможностью обобщенного программирования, рефлексии и метапрограммирования;
- может использовать любые библиотеки, а не те которые удалось подключить;
- использует общепринятые системы ведения логов а не то что придумали вендоры;
- может поддерживаться любым разработчиком, а не редким специалистом, прошедшим кучу курсов.
Что же до ETL, то постоянно они работать не должны, ETL это по определению пакетная обработка по расписанию.
Кто вам сказал эту чепуху? Если вы никогда не видели ETL, работающего по сообщениям скажем из MQ — это не значит, что их не бывает.
Если вы знаете больше меня по этой теме, не могли бы вы привести источники? В той же Википедии через слово пишется про базы данных и раздельные стадии обработки.
Я просто работаю над этой темой уже лет 10. Базы даных и файлы — это было когда-то. А сейчас нормальные инструменты для делания ETL предполагают и позволяют переваривать данные, приходящие в любом режиме, и откуда угодно. Информатика какая-нибудь, или тот же camel — им по большому счету все равно, сообщения это или база. Возможно это меняет смысл термина, но тем не менее — то на чем сегодня делается ETL, оно именно такое. 24/7, терабайты данных в сутки, смесь пакетных загрузок и стриминга.
Одинаковые инструменты не говорят об одинаковости задач.
Но да, если мне нужно будет делать онлайн-обработку сообщений, бегущих через MQ — консольное приложение для этого я писать уже не буду. Сделаю вин-сервис :-)
Кстати, в 22 вин-сервисах на самом деле нет ничего страшного. Но проще, конечно же, обойтись одним.
Не знаком с SSIS, да и с Camel тоже. Насколько я понимаю это ETL инструменты. Я лишь хотел сказать, что EIP типа Каналы сообщений, Pipes, Filters, Router, Translator, Endpoint это все тоже часть WCF, поэтому и нет проблемы.
Насчет "OSGI — это и есть микросервисы", тогда и WCF — это тоже микросервисы. Значит опять нет проблемы.
П.С.
maven все же не совсем аналог msbuild. скорее аналог Ant.
Или же maven аналог msbuild+nuget.
А знакомство с системами сборки вообще частенько выводит из себя :)
В maven'е куча плагинов, надо с каждым разбираться (прямо как webpack).
В .net core конфиги msbuild похудели, так что все не так уж и плохо.
Я в общем слабо знаком с WCF, поэтому пожалуй в такой формулировке соглашусь с тем, что это похоже на Camel. Лучше или хуже — не знаю, по похоже очевидно.
По вопросу микросервисов — ну тут дьявол как обычно в деталях.
OSGI в виде реализации — это все же не одни только микросервисы, там много чего поверх уже есть. Если совсем уж просто — то на сегодня это ближе скажем к kubernetes Т.е. это еще и оркестрация кластеров микросервисов, например.
Что же до msbuild… ну тут сложно и длинно. Например, первое что не нравится — его еще и устанавливать надо? Ни maven, ни ant, ни gradle не требуют никакой установки (как впрочем и JDK/JRE) — это просто папки.
Тоже самое впрочем касается и проблемы зависимостей как таковых, в мире Java это как правило jar, в разных его подвидах, и некий набор соглашений, где в нем могут лежать зависимости. И он рекурсивный по сути, т.е. один jar внутри другого — ничего такого в этом нет, и обработать это тоже легко.
То есть, я могу собрать только свои классы, запаковать обычным zip, и посмотреть потом тоже, и ресурсы положить туда же — и тоже посмотреть например far-ом. И поправить, если что. А могу собрать свои + зависимости, и сделать так называемый fat jar или uber jar — и задеплоить одним куском. Ничего близкого к этой идеологии в мире .Net мне пока не попадается.
Как вы запустите maven или ant из агента CI, если это "просто папка", лежащая незнамо где?
Надо или в PATH прописать, или положить в известное место, или завести отдельную. переменную окружения, или настроить свойство в агенте...
Хоть это все и мелочи, но в итоге получается что установить msbuild не сложнее чем maven. Хоть там и надо прокликать "далее"-"далее"-"далее" или заморачиваться с "тихой" установкой — но зато msbuild всегда лежит по известному пути.
Для деплоя на IIS можно собрать zip-архив и задеплоить его одним куском при помощи msdeploy.
Для деплоя на Sharepoint нужно собирать не zip, а cab.
Для деплоя на винду существует msi, который можно собрать при помощи wix и развернуть на ферме серверов через групповые политики домена.
И одна сборка всегда может достать из своих ресурсов другую и загрузить ее, так что велосипедостроение никто тоже не запрещает.
Я запущу, и для этого конечно нужно знать папку. Но этих папок можно быть сколько угодно (как это обычно и бывает под Jenkins где-нибудь). Т.е. десять разных версий maven — никаких проблем не вызывает. Более того, дженкинс сам их и поставит, когда нужно. Одна версия из IDEA, другая из эклипса.
А внутри у Weblogic (и у груви заодно) — своя версия ant. Зачем — не знаю, но есть и работает.
Т.е. установки, как таковой, нет вообще, начиная с JDK, которую конечно тоже можно ставить из msi — а можно потом взять готовую папку и скопировать, и не будет никакой разницы (ну, почти никакой, если честно).
при помощи msdeploy.
А что, просто скопировать никак? Вот из таких мелочей оно все и состоит.
А что до msi… ну я как бы прекрасно знаю, что это такое. По сравнению с форматами установок типа jar/war — это примерно также, как старый OLE формат файлов ворда, по сравнению с новым zip форматом у него же — удобство просто несравнимое.
Суть моих мыслей — она простая, и вовсе не состоит в том, чтобы ругать .Net и принятые вокруг решения. Я изначально хотел сказать, что для энтерпрайза (и вообще успеха платформы) гораздо важнее, чем язык, вот такие вот мелочи типа системы сборки, или возможности прикрутить свою систкему сборки, если штатная не нравится.
И еще, в целом — поддержка или возможность ее допилить, для самых экзотических и старинных фиговин, которые только можно себе вообразить — потому что энтерпрайз это в первую очередь многолетние традиции, и куча внедренных и работающих легаси систем, которые никто не собирается выбрасывать просто потому, что они не модные.
Ну, разные версии msbuild тоже в разные папки ставятся.
А что, просто скопировать никак? Вот из таких мелочей оно все и состоит.
Можно и скопировать. Но вы же сами хотели деплоить одним куском...
Я изначально хотел сказать, что для энтерпрайза (и вообще успеха платформы) гораздо важнее, чем язык, вот такие вот мелочи типа системы сборки, или возможности прикрутить свою систкему сборки, если штатная не нравится.
И еще, в целом — поддержка или возможность ее допилить, для самых экзотических и старинных фиговин, которые только можно себе вообразить — потому что энтерпрайз это в первую очередь многолетние традиции, и куча внедренных и работающих легаси систем, которые никто не собирается выбрасывать просто потому, что они не модные.
Полностью с вами согласен, я и сам считаю так же. Но поверьте — в .NET в этом плане все сделано правильно.
msbuild — это расширяемая система сборки, возможностей которой хватает для очень большого круга задач. А где не хватает — там можно сделать <Exec Command="..." WorkingDirectory="..." />.
Можно и скопировать.
А зачем тогда msdeploy? ) Тут я кстати серьезно — сталкивался ровно с тем же, когда результат работы SSIS нужно установить на хост с базой. И написано, что нужно (или можно) для этого некую утилиту. При этом кто-то из команды просто взял, и скопировал, и оно работает, что вызывает некоторые вопросы — а зачем собственно утилита-то, и что она делает кроме копирования файлов?
Но вы же сами хотели деплоить одним куском...
Я не хотел одним куском. Я хотел в зависимости от задачи.
Ни разу и не говорил, что она никуда не годится — это у меня с ней некоторая несовместимость. Ну скажем так — я предпочитаю несколько больший уровень контроля с моей стороны, куда и что класть. И больший уровень понимания, как оно внутри работает (при том что претензий к MSDN у меня в общем-то никогда не было, документации много, и она приличного качества — но вот подиж ты, зачастую части идеологии куда-то ускользают).
Во-первых, msdeploy умеет создавать сайты, пулы и прочее (простое копирование сделает приложение частью существующего сайта или заменит существующий сайт).
Во-вторых, msdeploy работает по сети и является заменой колхозу на сетевых папках.
Соответственно, в зависимости от задачи можно использовать msdeploy, а можно — копирование.
SSIS хранит свои задачи в своей базе данных. Утилита читает файлы и загружает их в базу, раскладывая по табличкам. Да, это бред, но людям, которые привыкли строить энтерпрайз-решения вокруг сервера СУБД такой подход нравится.
Ну скажем так — я предпочитаю несколько больший уровень контроля с моей стороны, куда и что класть. И больший уровень понимания, как оно внутри работает
Ну, если вы не понимаете чего-то конкретного, можете задать вопрос на ru.SO. Я там часто отвечаю.
Что же до идеологии… Я не вполне понимаю что такое идеология системы сборки но думаю, что у msbuild и ant идеология общая.
Ну. exec command — это не плагин, это бяка ) Понятно что это на клайний случай, но все равно, это какая-то фича из эпохи make, по-хорошему, команде должен передаваться проект, а не непойми что. Причем она должна понимать, как он устроен, и где что лежит.
Ну вообще говоря можно и плагины писать и их подключать к проекту через nuget, мсбилд их подхватит. Всякий постпроцессинг сборок обычно так и работает.
exec я упомянул скорее как возможность сбежать с msbuild на любую другую систему сборки, поставив заглушки на цели Build, Rebuild и Clean :-)
Проект Visual Studio — это обычно и есть msbuild-файл. Если не использовать кривые магические надстройки для студии, то любой проект студии может быть собран msbuild, а любой файл msbuild может быть открыт студией как проект если дать ему правильное расширение и прописать правильный ProjectType.
Я так, кстати, часто делаю — создаю шарповый проект, удаляю из него импорт шарпового тулчейна и добавляю свои таргеты. Например, есть у меня проект, где исходниками являются jar-файлы, которые при сборке подаются на вход ikvmc...
Кстати, задача Exec в msbuild намного мощнее чем то же самое в make за счет языковых средств msbuild. MSBuild умеет работать со списками элементов проекта, преобразовывать их, фильтровать, группировать. Сами элементы проекта могут быть добавлены в явном виде (например, через IDE), получены сканированием директорий или получены как выходные параметры других задач.
Ну и ничто не мешает добавлять свои задачи, причем для этих целей есть аж три способа. Можно сделать свою сборку с задачами, можно создать задачу из C#-кода при помощи фабрики задач или же можно создать задачу из скрипта на powershell при помощи сторонней фабрики.
зато msbuild всегда лежит по известному пути.
Это пока у вас он один. Как только вам нужно подерживать скажем старую версию — вы приплыли.
Он с .NET поставляется, в "%SystemRoot%\Microsoft.NET\Framework\" соответствующей версии.
Нет, последние версии MSBuild ставятся отдельно.
А нужна не "хоть какая-то", а та, которая способна собрать проект.
Вы не поняли. "ломает ставить" — это не лично человека. Вот например, возьмите Jenkins. Для большинства систем сборки (и вообще инструментов) он сам умеет скачать и поставить их нужные версии, и подключить к сборке. То есть установка maven — это галочка в настройках проекта "нужен maven версии ххх". Потому что далеко не всегда (а скорее наоборот) сборка делается на машине разработчика. По-идее на машине CI одна должна делаться чаще.
Дело даже не в uber jar — дело в том, что субъективно развертывание можно делать несколько проще (и даже сильно проще), чем это делает MS, когда предлагает свои продукты. И эта простота развертывания в какой-то степени важнее для успеха платформы в целом нежели качество языка (которое у c# вполне хорошее), или многоплатформенность (которая в какой-то степени опять же уже у .Net уже есть). Все остальное — это просто более или менее наглядные примеры, первые какие пришли в голову.
P.S. Кстати, то что я называл — это лишь часть. Например, вы можете представить аналог Hadoop на .Net? Или даже еще проще — любой софт, сильно завязанный на кластер, ну хоть тот же GridGain/Ingite?
И если нет, то почему его не существует?
ravendb это в лучшем случае couchdb, но даже со своим rest интерфейсом очень часто проигрывает в измерениях.
hadoop это полноценная платформа поверх и совместно с которой крутится очень много чего: mapreduce, spark, flink, storm, hbase, accumulo, phoenix, cassandra, kafka и можно продолжать очень долго
у MS была хорошая попытка в виде dryad, правда они её слили, а вот идеи из неё уже и вошли в spark/flink.
вообще в сфере перемалывания и nosql доминируют 2 языка java и c++, местами другие jvm языки в виде scala и clojure.
и тут зачастую вопрос не в том что java туда зашла раньше, а в том что никто ради хадупа не будет покупать еще пару сотен лицензий на windows server, если от хост системы только и требуется что выступать пускателем кода, никаких групповых политик или еще чего.
почти все перечисленные решения могут работать и на windows (не всегда оптимально, но могут), правда в реальной жизни я в работе только linux видел.
с появлением .net core может что-то и поменяется, но тут начинается уже битва рантаймов (именно поэтому некоторые продукты отходят от jvm и переходят на c++), и тут опять же у jvm пока рантайм смотрится чуть лучше. на данный момент я не видел в жизни как себя ведет gc у .net на хипах по 64GB и выше, а в реальной жизни встречались и выше.
для той же jvm вот ultra-low pause допиливает redhat и odnoklassniki его уже в прод пустили
признаюсь, что плотно под .net не разрабатываю, но когда смотрю доклады по кишкам .net в части оптимизации расходов памяти (те же доклады по memory traffic в resharper) и вопросов производительности, то очень часто случается культурный шок от того, что у себя на jvm о данных вопросах даже не задумываешься, все из коробки уже работает хорошо.
так что повторюсь: вопрос далеко не только в маркетинге, но и в рантайме (как и где он может запускаться, ну и насколько утилит готовых на все случаи жизни для него существуют), возможно с появлением .net core что-то начнет меняться, но это займет не год и не два, а в лучшем случае пять лет.
p.s. с интересом слежу за развитием .net платформы и попыткой её стать действительно кроссплатформенной, но уже видно отрезвление у многих, что это не спринт (через год-два у нас все будет отлично работать на linux/mac), а достаточно долгий марафон. остается лишь пожелать удачи, конкуренция и обмен идеями никогда никому не вредила.
А по части оптимизации — магии не существует. Вы либо тюните параметры GC либо более точно работаете с памятью. Ну или и то и другое :) Даже Go с его типа уникальной разработкой ничего нового не принес.
Как раз возможность более детерминировано работать с ресурсами сейчас отличает .Net от Java в лучшую сторону.
Время покажет. В любом случае Java очень долго будет оставаться релевантной, ну если Оракл еще чего не учудит :) А .Net вполне занимает нишу между ней и node/ruby. Но это мои личные ощущения.
Не-не. RavenDB это может и выглядит похоже, но совершенно не то. Суть в выполнении кода на том узле кластера, где у вас лежат данные. Это далеко не просто шардинг или кластеризация.
Покажите аналог на перле, я не против.
Что в Java отличает ее от других языков и платформ так, что только на ней можно написать Hadoop или GridGain или Ignite?
У Java есть одно преимущество — в тот момент, когда эти проекты рождались другой альтернативы не было, а сейчас просто нет смысла переписывать до тех пор пока всех это устраивает. Есть Golang, Rust, С++, тот же .Net. Или вы серьезно считаете, что нельзя выполнить .Net код на том же узле кластера где лежат данные? :D
Это вы не поняли вопрос. Повторяю — расскажите, каким образом софт, написанный на перле или на питоне, попадет на нужный узел кластера, где расположены нужные нам сегодня данные? Кто скомпилирует этот софт, написанный на Go, Rust, C++, или том же .Net, именно под нужную архитектуру и ОС этого узла, и как доставит этот код с зависимостями на нужные узлы, прежде чем их можно будет там выполнить?
Причем тут Java? Это просто написано на ней, но может быть переписано на другом ЯП, например Akka.Net.
Эк вы ловко с перла и питона на рослин-то свалили...
Ага. Берете и исполняете. А потом у вас Process.execute("shutdown") где-то в коде затесался )))
У вас, простите, какой-то очень наивный взгляд на то, как можно выполнять заранее неизвестный код (ad-hoc) на кластере, так чтобы он а) работал (зависимости тоже нужно передать, а для начала собрать их) б) не завалил узлы кластера ни по какой причине, в том числе — потребляя чрезмерно ресурсы, в) имел доступ только к тем данным, к которым ему положено.
P.S. вы правда не знаете про такую секретную фичу, как возможность загрузить в JVM байт-код прямо из потока байт, не передавая никакие "готовые либы"?
Перепишите все на перл, да. У хадупа при всех достоинствах куча недостатков, тянущихся с рождения, когда он был просто MR поверх HDFS. Устраните — озолотитесь. Без всяких шуток. Все что вы тут рассказывали про "всех все устраивает" — не более чем байки. Не всех и не все.
А вы серьезно не вкрусе о Assembly.Load?
Все что вы описываете можно делать через Рослин, зависимости хоть через Nuget гоняйте и динамически загружайте. Хотите — генерите динамические сборки прямо в коде, компилиркйте их в IL и гоните по сети. Java тут никаких преимуществ не дает. Для защиты от дурака — AppDomain.
Кому надо и делают. Пример выше я уже привел. Пилить свое — не всегда лучший вариант. Если не устраивает — перепиливайте. Только надо бабок на это, комьюнити и время, когда на рынке уже есть аналог в который активно инвестируют. Поэтому проще Hadoop к сиквелу прикрутить чем переделывать.
И опять повторюсь — причем тут Java? Какие уникальные фичи есть только в ней, что другим нельзя в кластере код передавать и изолировать процесс/данные?
Был аналог — DryadLINQ.
Его уже не поддерживают, т.к. Hadoop начал поддерживать взаимодействия с другими языками и смысл пилить Dryad пропал, ибо малая популярность.
Так что проблемы сделать аналог нет.
Да и вообще, что именно в .net не позволяет завязываться на кластер?
П.С. промахнулся с веткой
Вообще, если подумать, c# как раз таки больше подходит для систем обработки данных из-за более тонкого управления памятью (value type, указатели, ref return)
Честно говоря, я так и не понял, есть ли тут аналог HDFS, и используется ли data locality. Т.е. распределяется ли код по кластеру, и каким именно способом.
вот только dryad был на уровне beta и даже пару универов смогли «скачать-поиграться». потом его закрыли со словами «кастомеры как-то не горят желанием еще одной системы поэтому будем делать коннектор к хадупу».
из хороших идей там там был нормальный стриминг промежуточных результатов на следующий этап конвеерной обработки, в случае если этап находится на этой же физ ноде стриминг выполнялся по name pipe (а не через сетевой сокет), там же были зачатки RDD (spark их потом развил в уже законченное решение). в общем полезных и интересных вещей было очень много, если бы их действительно развили до промышленного состояния, то вполне возможно у нас сейчас была бы еще одна распределенная система обработки данных.
но ms слили свой шанс и сейчас вокруг jvm и c++ в этих областях и .net там бедный родственник
- Гораздо более слабая поддержка Dependency Injection и Aspects, усложняющая создание mocks, добавление логов, проверок авторизации и т.п.
- Сильная зависимость между компонентами и OS/AppServer, затрудняющая интеграцию — модель JAR/WAR гораздо гибче Assembly
Что такое в вашем понимании "слабая поддержка Dependency Injection"? Чего именно вам не хватает или не хватало?
И каким образом затрудняется интеграция из-за сильных связей между компонентами? Вы пробовали эти связи делать слабыми? :-)
Связи не между компонентами, а между компонентами и ОС. В Яве достаточно остановить апп-сервер и можно деплоить новую версию — в .Net (на Windows) надо останавливать IIS, WAS, собственные сервисы — и только тогда можно быть уверенным что ваши тесты бегут с нужной версией ассембли.
Property Injection работает так же как и field injection, не вижу проблем написать
{get;set;}чтобы превратить field в property.
Чем вам
using (var ts = new TransactionScope())— не простой способ?
- Что же до версий сборок — решение проблемы очень простое. И не нужно было добавлять в GAC.
2. Тем, что это засоряет код и для уже скомпилированной сборки не меняется.
3. Я в GAC ничего и не добавлял (это вообще требует прав администратора для инсталляции — что убивает возможность самоапгрейда).
Вы так пишите как будто field injection — не костыль...
Менять скомпилированные сборки — нехорошо. Но если очень хочется — есть же Mono.Cecil
- В таком случае никаких проблем с обновлением.
2. Вы не поняли. Есть скомпилированный класс с методом DoSomething — разработчик которого о транзакциях, логах и прочем мог вообще не знать. В Джаве (Спринге например) я могу написать внешний файл аннотаций и включать/выключать все вышеописанное как мне хочется, не затрагивая оригинальной функциональности.
3. Это в теории. На практике — если у вас больше одного сервиса, начинается веселуха, особенно с инфраструктурными компонентами. Но не исключено что какие-то гуру DevOps действительно смогли бы это починить.
Костыль — но гораздо меньший
Вы хотите сказать, что когда перед использованием объекта надо установить ему некоторое поле — это нормально, не нуждается в документировании и не раскрывает деталей реализации?..
Необходимости использования транзакций зависит от алгоритма, а не от желания левой пятки. Поэтому не вижу пользы от внешнего файла аннотаций, который управляет транзакциями.
По поводу же логов — повторюсь:
Но если очень хочется — есть же Mono.Cecil
А что вы делаете в Java, когда у вас более одного сервиса? И почему вы не смогли сделать то же самое на .NET?
Необходимость использования транзакций может меняться чуть ли не каждый спринт. Поэтому от внешнего файла аннотаций есть прямая польза. А при отладке больших систем, особенно профилировании — это вообще незаменимо. Замена реальной имплементации моком, включение/выключение логов и т.п. делается без единого изменения в самом коде.
В Джаве я делаю рестарт серверу апликаций. В .Net (точнее в Виндоус) граница между AS и OS довольно размыта.
И что же меняется при замене полей на свойства?
Необходимость использования транзакций может меняться чуть ли не каждый спринт.
Алгоритм, использующий транзакции и алгоритм, их не использующий — это два разных алгоритма. Если вы можете один из них превратить в другой простым обертыванием в транзакцию — значит либо первый неоптимальный, либо второй некорректный.
В Джаве я делаю рестарт серверу апликаций. В .Net (точнее в Виндоус) граница между AS и OS довольно размыта.
А в .NET даже это делать не обязательно, достаточно папку bin заменить. Правильно настроенный IIS заметит это и перезапустит веб-приложение.
И куда же могла быть загружена сборка, которая лежит в папке bin сайта IIS? Не надо грузить что попало куда попало, вот и все.
Shadow cope при прямых руках вообще никак не мешает. Ей даже можно пользоваться, если умеете.
.Net Core в принципе живет без IIS, и именно он является темой топика.
Что значит общий логгер? Если одна и та же либа — nuget restore во время билда. GAC вообще не используется сейчас. И тем более никто не шарит либу между пачкой приложений. Для оптимизации как раз tree shaking подъедет. И ещё забыли что зависимости можно тянуть исходниками и собирать Рослином налету.
2. DynamicProxy — оборачивайте что хотите. Только за транзакции прикрученные непонятно к чему на code review будет много вопросов.
3. Это у вас кривой devops. Это надо очень постараться, что бы устроить конфликты библиотек между изолированными приложениями на IIS. На Core и IIS не нужен. HAProxy/Nginx/Apache + Kestrel.
Проблема .Net проектов, что есть большой пласт разработчиков, которые считают, что освоив инструментарий один раз( зачастую лишь очень поверхностно) больше ничего учить не надо. Только вот инструментарий развивается и меняется.
2. DynamicProxy — неплохой костыль, но лучше когда такое сразу встроено в язык.
3. Приложения — они не только на IIS бывают, Web/REST/WCF — это часто только фронтенд.
То есть вы сравниваете Java-приложение, запущенное на сервере приложений, с .NET-приложением, запущенным абы где — и приходите к выводу что в .NET сложно администрировать приложения?..
Все с вами ясно...
2. В «язык» не будет встроено. А для жаждущих есть DispatchProxy.
3. Конечно, не только. Берете виндовый сервис и делайте как хотите. Он так же может быть полностью self-сontained. Если вы не работали с квалифицированными .Net разработчиками, то тут уж сочувствую. Накосячить можно на любом ЯП/платформе.
Микрософт ставит на то что в его стеке и EAI и SOA будут заабстрагированы микросервисами.
Это если забыть про EAP статус Rider…
… если оно летает в 10 раз быстрее чем студия?
Маленькая поправочка: «быстрее чем студия с решарпером». Попробуйте его отключить и тогда вы узнаете, что такое скорость. Никаких тормозов при наборе, ненужных дополнений кода, которые приходится удалять. И студия, оказывается, сама по себе не вешается насмерть при переключении между бранчами в hg.
А вообще это хорошо, что появился Rider и развивается всё активнее Xamarin — остаётся надежда, что под .net таки появится идеальная среда разработки.
Но студия довольно таки тупит.
По крайней мере, внутри виртуалки.
Кстати позвольте заметить что студия тоже не на .net вовсе, вот и сидим в 2017 году с х32 битным процессом и кучей лагов.
Я помню когда MS выпустила первую версию .NET, они во всю начали трендеть про Новые Васюки заявлять что де в ближайшем будущем все у них будет на .NET, не исключая даже операционной системы. Вот все так и ждем до сих пор.
В Вижуал Студии GUI — WPF, в Expression Blend — тоже. MSN, Bing и прочие cервисы — .net
Даже Singularity три года назад допилили. Чего еще ждать-то?
MSSQL например, или всю студию полностью…
Должен ли в таком случае Oracle переписать свою БД на Java?
Что вас смущает в managed?
Это валидный C# код:
void StackAllocExample() {
unsafe {
byte* data = stackalloc byte[128];
var span = new Span<byte>(data, 128);
// not shown: populate data / span
ProcessData(span);
}
}
Подробнее тут. Вот еще неплохой овервью.
Пожалуйста, прочитайте ветку комментариев сначала. Кажется, вы забыли о чем тут шел спор.
Что-то вы могли сделать пометив пол проекта как unsafe, но сейчас можно
void StackAllocExample() {
unsafe {
byte* data = stackalloc byte[128];
var span = new Span<byte>(data, 128);
// not shown: populate data / span
ProcessData(span);
}
}
void ProcessData(Span<byte> span) {
for (int i = 0; i < span.Length; i++) {
DoSomething(span[i]);
}
}
Ничего не замечаете в этом примере? ;) Вы хоть ознакомьтесь с теми ссылками :)
Нет ядро студии точно на Cи, плагины, обертки и всякая прочая окружная мишура на .NET и вроде бы еще на Cи можно что то делать (тут не уверен, раньше точно была такая возможность, раньше были кучи оберток над COM+ типа VSTO, короче черт ногу сломит).
Да, еще бы и работу с коллекциями сделать более понятной, потому что после LINQ работать что с java.util.collections, что с Guava — это ж просто застрелиться…
theknight@theknight-laptop:~/tmp/langtools-7e0ac3c3eaba$ cloc .
9399 text files.
8696 unique files.
1569 files ignored.
http://cloc.sourceforge.net v 1.60 T=14.75 s (489.1 files/s, 55453.6 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Java 7091 81717 273836 428338
Javascript 13 3021 4718 14932
CSS 7 71 177 2756
XML 32 180 326 2555
Bourne Shell 20 299 763 845
HTML 44 141 531 628
Ant 3 80 131 455
C/C++ Header 5 141 690 358
make 1 53 142 305
XSLT 1 4 0 20
-------------------------------------------------------------------------------
SUM: 7217 85707 281314 451192
-------------------------------------------------------------------------------
Что там c компилятором C# — не смотрел.
Про коллекции — Stream API + лямбда-функции все еще не решают проблемы?
А вот мне все-таки и правда интересно, что значит «компилятор Java написанный на Java»? Вы имеете ввиду компилятор в байткод, виртуальную машину или JIT/AOT-компилятор?
Пытался его поставить на мак, так он не захотел ставиться без android sdk и xcode, "what a hell", подумал я и не стал его устанавливать.
Какая связь между десктопным приложениями и enterprise?
Толстые клиенты вестимо.
Ну это довольна маленькая часть enterprise и его доля всё уменьшается. Все-таки enterprise это больше про серверную логику.
Ну мы тут обсуждаем enterprise в целом, а не вас конкретно. То что вы хотите несколько ортогонально потребностям кровавого enterprise.
Я так-то тоже хочу язык на котором можно писать и серверную часть, и RIA, и десктопные приложения. Но я такого языка не наблюдаю. Это же не повод говорить, что все языки не подходят для enterprise.
Я так-то тоже хочу язык на котором можно писать и серверную часть, и RIA, и десктопные приложения. Но я такого языка не наблюдаю.
На Java можно и и серверную часть, и RIA, и десктопные приложения и мобильные приложения под все основные платформы (RIA на чистом Java это Gwt, десктоп — Swing, SWT, мобильные — под андроид натив, под Apple тоже есть возможность писать). Что-то лучше, что-то сложнее, но потенциально можно все. Только не надо разводить холивар на тему разве GWT лучше ангуляра или что за приложения получаются на Swing/SWT, та же Idea это десктопное приложение, на GWT написано много RIA энтерпрайза (сам писал), есть свои проблемы, но у кого их нет?
Ява подходит настолько плохо, что в некоторых «интерпрайзах»(например ДойчеБанке) сервера на java, а клиенты — .net
Наоборот тоже бывает (сам видел). Это не только зависит от языка/технологии. Десктоп на java вполне встречается (из известных те же IDE от JetBrains), хотя в ней акцент больше на веб приложения
Что-то лучше, что-то сложнее, но потенциально можно все.
Потенциально можно и на brainfuck'е всё это делать :)
Писать RIA на чистой java — это боль. Да, возможно, но будет на порядки сложнее чем если делать это на js. Десктопные приложения на java писать проще и лучше чем RIA, но все равно проблемы есть.
Я имел ввиду, что хочу язык на котором все вышеперечисленное действительно удобно писать, а не просто возможно. Но я понимаю, что через чур много хочу :)
(вероятно это потому что я плотно сижу на windows-инфраструктуре)
Питон — подходит
Язык с динамической типизацией в enterprise? Это шутка, правда?
Это как вопрос:
— назовите серьезное Java-приложение с пользовательским интефейсом?
— IDEA.
И? Кто-то пишет клиентские приложения с UI на Java? Ну нет, не пишет.
Не стоит путать тулы и end-user приложения.
Кросс-платформенного UI в .NET Core сейчас нет. Так же как и во многих других платформах. Это ничего не говорит о зрелости.
Нужен кросс-платформенный UI — Electron. Даже инсталлятор VS на нем :) (ну или на чем-то аналоичном, не смотрел внутрь).
Jigsaw это не только разбиение монолитного JDK на кусочки как с .net core где System.Web всех просто достал. Это тотальная электрификация батенька модуляризация с такими понятиями как объявление и выгрузка модулей, это своего рода эволюция по пути node.js(но только в плане модулей!).
В .net все "пакуется" в dll, в java в jar/war/ear потом это все может распространятся через nuget/maven. Так вот jigsaw привносит так же понятие модулей, вот что можно вкратце почерпнуть из указанного выше источника
In short, JARs are a good attempt at modularization, but they don't fulfill all the requirements for a truly modular environment.
Тоже самое но в меньшей степени касается .net, там вероятность dll ада меньше из за "сильных" имен сборок.
В .NET core никаких понятий модуля нет, просто монолитный .NET порезан и разливается через nuget.
Не помню, оставили ли они или нет, но .Net Core можно было просто исходниками в пакете гонять, и компилировать рослином по необходимости.
Зависимости в случае maven/nuget указываются на уровне упаковки(package).
PackageReference Include="System.ComponentModel" Version="4.3.0"
Прям в csproj файле.
Не понимаю прикола в языке с модификаторами видимости пытаться копировать js…
Нет в csproj файле насколько я помню вы указываете локальные зависимости а вот nuget зависимости идут отдельно в отдельном файле на уровне проекта вроде в packages.config. Когда в вы устанавливаете что то, то нугет вам это бережно пихает в csproj.
Я не сказал что они пытаются копировать js, я говорил про схожий путь.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
</ItemGroup>
</Project>
Всё ещё можно. Просто пропишите файл как content и он nuget pack'ом будет доставляться при установке.
Вот пожалуйста, там файлы module-info описывают что должен экспортировать модуль плюс его зависимости итд.
Если не ошибаюсь то Jigsaw был начат под другим названием еще под Sun(между java 6 и 7), так что ему не пол года от роду. А вот по .net core, там не столько кропотливый труд сколько терзания сомнениями и ошибки на стадии дизайна, отсюда и фокусы типа был poroject.json и нет его, прыг скок обратно на msbuild. До осмысленного конца там еще боюсь далеко, и может не дойти до него вовсе, а выпилят какой нибудь сурагат.
Это желание новых людей сделать модно «как у них» сейчас и здесь
Вот! Вот от таких мыслей при проектировании хорошие системы и загибаются. «Как у них» — не значит «хорошо». project.json для сборки .NET-проектов очевидно не подходит, ибо как вылазит проблема совместимости со старыми системами, завязанными на специфические особенности msbuild-а, как верно команда .NET Core заметила в своем блоге.
У меня просто солидный опыт работы с MSBuild и это реально очень удобная система сборки чем-то похожая на ant. project.json сильно уступает ей в функциональности. project.json отлично работает на маленьких и простых проектах и превращается в сущий ад на попытке собрать большой проект (я собирал свой фреймворк с помощью project.json — прошелся по такому количеству граблей, что страшно становится)
С другой стороны, странно было бы слышать от идеологов и сторонников технологии «надеюсь теперь не сдохнем» — это вряд ли привлечет новых сторонников :)
Хотя в любом случае, я сторонник здоровой конкуренции — если .Net Core будет объективно лучше Java — выиграют все.
Есть ли данное интервью на английском языке?
Пытался понять что за NET Core, вроде как мне не надо. «Главное убедитесь, что не используете WPF и WinForms, и всё будет хорошо». А как там рисовать формы для десктопов (вин и линь)? Или это чисто веб? Также весело насчёт веба — из бесплатного и/или доступного только пхп и больше ничего.
Сделать интерфейс энтерпрайз приложения в виде rich web application с учётом всяких websockets и single page application frameworks это довольно хорошая идея в 2017 году. Excel может запуститься в браузере, а опердень нет?
И поясните пожалуйста по поводу php — так то это самый незахайпленный сегодня язык из бесплатных и доступных.
Проблема в прожорливости таких решений. Наш каталог контролов после прокликивания всех вкладок кушает 42 мегабайта в private working set. И это на альфа-версии фреймворка, который никто особо не оптимизировал. Открываем в качестве единственной вкладки в хроме "хэлловорлд" на ангуларе (если кто возьмётся склепать аналог приложения для нормального сравнения — велкам), то спавнится в сумме 5 процессов, отъедающих больше сотни мегабайт в сумме.
И если при большом числе вкладок хром внутри себя ещё как-то нормально управляет ресурсами, то когда люди начинают делать "десктопные приложения", по факту перепаковывая сайт с браузерным движком, становится очень грустно.
одна реклама. «Используйте это, потому что ваше старое с багами. Используйте это, а это тоже устарело» и ни одного примера чем же лучше и какие баги.Не используйте бета-версию .Net core потому что она старая и с багами. Если используете более старый, но стабильный .NET, то смотрите по ситуации. С каких пор это реклама?
А как там рисовать формы для десктопов (вин и линь)? Или это чисто веб?Веб и консоль, пока.
— IDE уровня IDEA (+ бесплатная community версия)
— аналоги Spring Framework (для политкорректности — или Java EE)
— экосистема тестирования (Mockito, WireMock, JUnit, Spring Test)
— экосистема CI/CD
— полный набор для production — легковесные контейнерные runtime-ы, мониторинги, анализы, да много всего
— проекты уровня Netflix OSS для облака и микросервисов
— про отвязку от Windows думаю даже говорить не нужно
— база знаний сообщества
— … и многое другое
И здесь немного парадоксальный вывод: как мне кажется, чтобы помочь платформе развиваться Майкрософт… нужно слегка притормозить. Нужно перестать менять форматы проектов, менять инструментарий, менять API, выпускать тонны разных продуктов с разными версиями, часто несовместимые друг с другом. Я помню ситуации когда туториалы по .NET Core двух-трех месячной давности были не актуальны! Даже среди .NET Core сторонников иногда звучат голоса, что Майкрософт слишком гонит вперед. И если платформа стабилизируется, будет понятно куда она развивается, если Оракл окончательно настроит против себя сообщество и клиентов, то может через год-два .NET Core и потеснит Java. Хотя как бы не пришлось теснить и какой-нибудь Go к тому времени!
— IDE уровня IDEA (+ бесплатная community версия)Если под уровнем подразумевается кросс-платформенность, ты выше обсуждалось, что она в процессе достижения. Самое главное — Roslin, уже кросс-платформенный. Если про фичи, то тут вкусовщина и холивар.
— аналоги Spring Framework (для политкорректности — или Java EE)Я не вебер, сложно судить всесторонне, но те фичи, что выведены главными на сайте фреймворка в .net присутствуют.
— экосистема тестирования (Mockito, WireMock, JUnit, Spring Test)
NUnit — портированный JUnit. И он не единственный фреймворк.
— экосистема CI/CDhttps://www.visualstudio.com/ru/vso/
— полный набор для production — легковесные контейнерные runtime-ы, мониторинги, анализы, да много всегоAzure
— проекты уровня Netflix OSS для облака и микросервисовЕсли я все правильно понял, то тоже Azure (+ Docker??)
— про отвязку от Windows думаю даже говорить не нужно
.Net Core, Xamarin
— база знаний сообщества
docs.microsoft.com (он же: https://github.com/MicrosoftDocs), stackoverflow.com
— … и многое другоемм?
.NET Core двух-трех месячной давности были не актуальны!Так бывает с бетаверсиями продуктов, более того это нормально, о чем и упоминается в интервью. У отдельных компаний стабильные версии языка каждый год ломают существующий код…
Azure
Разве его можно установить у себя?
Вопрос в том, что имеется в виду под всем этим делом — если IaaS, то ОК, это есть. Если PaaS или фичи типа AppInsights, то не только процесс адаптации любого PaaS-а под вариант поставки on-premise, но и наличие у потенциальных клиентов ресурсов под то, чтобы это работало хорошо, а не в режиме «один сервер — пять ролей» или маленького кластера сложны для однозначного ответа. Хотя планы есть.
Разве windows server бесплатен?
На мой взгляд намекаете, сначала предлагая в качестве замены решение в виде azure, а потом, заменить его на windows server в связке с. Team Foundation Server.
Просто, на мой взгляд, иногда вопрос лицензирования может вызвать большую головную боль, чем разработка ( и даже выделение средств ), что может дать не очевидное преимущество какому-либо продукту.
Если вы используете продукты под GPL только так, и никак иначе — проблем у вас не будет никаких вообще…
Если вы используете продукты под GPL только так, и никак иначе — проблем у вас не будет никаких вообще…это уже проблема. Плюс проблемы с линковкой и т.п.
выделите для себя ту горстку, которая разрешает модификации.Опять же вопрос требований к лицензии. Причем от платности прямой зависимости нет. Есть платный опенсорс.
А если вспомнить про требование наших органов иметь бумажку об отгрузке…
В общем (бес)платность/(за)открытость не спасают от проблем с лицензированием. С ним и так, и так придется разбираться.
Azure Stack в стадии Technical Preview
Сразу дисклеймер — я не пытаюсь говорить что .NET лучше или хуже JVM как платформа, я описываю лишь свои личные ощущения от миграции на другую платформу после многих лет на .NET. Так вот, мое впечатление — в современном (это важно) стеке разработки на JVM решены проблемы о которых я даже не думал в .NET и это сильно помогает в ежедневной разработке.
Например, тестирование — NUnit, конечно есть. Но если взять тот же Spring (я скоро стану адвокатом Spring!) — то там Mockito, Spring и JUnit не просто есть, а образуют органичную систему. Например, чтобы взять полностью Spring-приложение, запустить его как есть на случайном порту и остановить после теста, но замокать взаимодействие с внешним сервисом нужно сделать просто:
@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class DemoWebApplicationTests {
@MockBean
private PayPalPayments payPalPayments;
@Test
public void whenSendPaymentRequest_paypalIsInvoked() {
Mockito.verify(payPalPayments).pay("test@example.com");
}
}
А потом это легко подхватит любой CI/CD, эти тесты понимает IDEA, по этим тестам можно считать покрытие и т.п… Это не набор разрозненных инструментов — это экосистема. И мне не передать как это важно. И здесь сочетание всего — и моков, и тестового фреймворка, и DI, и рантайма который можно легко запустить — да много всего. Могу ли я это написать сам? Конечно могу, да и любой более-менее профессиональный программист сможет. Но зачем? А это только один пример — тесты, и в целом частный случай. Но так во многом — эти утилиты полировались и использовались годами, чтобы получить такую синергию. И вот именно это и нужно .NET — органичную экосистему. Чтобы разработчик мог не думать как решать типовые задачи — разработки, деплоймента, тестирования. И Майкрософт делает отличную работу, чтобы эти инструменты дать — но просто нужно время на все на это. Время и отсутствие потрясений в платформе.
Есть и тестовые сервера, и с контейнерами делайте то, что вам вздумается.
В Core все стало по человечески. IIS можно выкинуть и использовать весь спектр ништяков для деплоя :)
У меня, наоборот, был отрицательный опыт пару лет назад.
Казалось бы, есть простая задача: hello world на Spring+CXF с конфигурацией в коде.
Открываем мануал: http://cxf.apache.org/docs/writing-a-service-with-spring.html
Читаем, понимаем, что там конфиг в xml.
Внизу приписка: For more information on using Spring… первая ссылка — полотно XML, вторая ссылка вообще битая.
Мучаем поисковик. Нам говорят, что нужен spring boot.
Я понимаю, что у меня будет не типовой конфиг и spring boot мне не нужен.
Да и вообще, отдельная библиотека просто для того, чтобы запустить hello world?
Я так и не нашел способа сделать это.
Возможно сейчас все поменялось и мне, наконец, покажут пример, который бы поместился в небольшой комментарий.
та же задача, но с использованием .net core для сравнения:
public class Startup {
public void Configure(IApplicationBuilder app) =>
app.Run(context => context.Response.WriteAsync("Hello world");
}Страшно даже подумать, во что надо вляпаться, что сделать Spring'овский hello world асинхронным...
Да и вообще, отдельная библиотека просто для того, чтобы запустить hello world?Это ынтырпрайз, детка.
При всей проработанности Java-мира очень многое в нём делается не так, как в других мирах.
Казалось бы, есть простая задача: hello world на Spring+CXF с конфигурацией в коде.Ни разу не простая, так как вы идёте наперекор всем канонам: хотите конфигурацию в коде (в коде, Карл!), и без создания всех этих WAR'ов.
Библиотеки, позволяющие делать в Java «конфигурацию в коде» существуют (практически я с Guice работал), но что там бывает на замену CXF — не скажу (у нас всё своё было). А Spring изначально предполагает что в коде конфигурации не будет и, соответственно, старается сделать так, чтобы её там не оказалось — странно после этого ожидать, что ваша задача, которая требует ровно противоположного, окажется «простой».
Возможно сейчас все поменялось и мне, наконец, покажут пример, который бы поместился в небольшой комментарий.И не мечтайте. Вот узнать как это сделать тремя кликами мышки, которые породят 100500 файлов и несколько мегабайт кода — это ещё есть шанс. Увидеть пример, который «поместится в небольшой комментарий» — вряд ли.
@SpringBootApplication
@RestController
public class DemoWebApplication {
@GetMapping("/")
public String helloWorld() {
return "Hello, World";
}
public static void main(String[] args) throws InterruptedException {
SpringApplication.run(DemoWebApplication.class, args)
}
}
Все. Это не генерит никакой код — просто автоматически конфигурирует приложение. И это полностью self-contained приложение — ему не нужно application server-а, его можно просто запустить — т.к. JAR вполне себе executable. На Kotlin или Groovy это еще лаконичнее и проще.
Это не единственный возможный подход. В том же EF можно настраивать все через DataAnnotations, которые деревьев не требуют.
А если не хватает возможностей стандартных аннотаций — можно добавить свои через конвенции. Которые тоже не требуют деревьев.
Fluent-конфигурация удобна тем, что её можно комбинировать через поведенческие примеси, что позволяет легко и непринужденно, например, выносить общую конфигурацию для каких-либо специфических и похожих сущностей в отдельный обобщенный метод. У нас в проекте например довольно много сущностей с полем Name (помимо Id). И все они у нас 128 байт в длину, типа nvarchar, не допускающие пустых строк. Все они конфигурируются через один и тот же метод конфигурации, что весьма удобно.
Такие вещи обычно удобно делаются через общего предка.
С каких пор прибитая гвоздями к языку CI/CD считается чем-то хорошим?
2. ASP.NET MVC + куча расширений от самой же MS.
3. xUnit, NUnit, Storyteller, моков вообще налепили.
4. VSO, да и вообще на всем подряд можно собираться. В чем тут проблема? Берите Jenkins и вперед :)
5. CoreClr, ETW и куча всего.
6. DotNet Foundation.
7. Уже. Есть пара деплоевв прода на Debian.
8. https://docs.microsoft.com/ru-ru/dotnet/
Ну логично, что процесс открытой разработки порождает быстрое устаревание туториалов. Раньше вы бы просто этого не узнали, пока РТМ не вышел.
Не гонит, а медленно движется — народ с беты на проде внедряет и довольны. Если вы можете открыть исходники, найти проблему и решить — хоть альфой пользуйтесь.
C# Tiobe
Да какая то прямо C# fatigue
Как имеющий опыт скажу, что указанная положительная динамика ни коим образом не мешает компаниям плеваться от VB.NET и отказываться от него в пользу C#. Основная проблема VB.NET — это просто дикое, неуправляемое приведение типов, громоздкий синтаксис для лямбда-выражений и сильно урезанная поддержка у ReSharper. Даже литеральные даты и пара полезных LINQ-словечек не спасает
Самое обидное, что мы на грани переворота с «ног на голову». Я о том, что если на одну и ту же должность претендуют мужчина и женщина, то единственным критерием выбора должны быть деловые качества, но мы уже на грани того, что женщина получит преимущество только потому, что в отделе недостаток «слабого пола». Я тоже за равенство, но наличие в зале аудитории в основном из белых мужчин вовсе не говорит о неравенстве. Опять же низвестно, где эта конференция проводилась — в Бангалоре логично увидеть полный зал индусов, а на конференции швей-мотористок в зале будут женщины.
Однако работая на инженерной должности много лет, должен признать, что большинство инженеров (программистов и не только) — мужчины. И мне вот думается, что тут просто склад ума у женщин и мужчин несколько разный. Почему природа так устроила — это загадка.
Феминистки считают, что причина в-основном в женской гендерной социализации — с детства им говорят, надевай розовое, будь слабой эмоциональной, интересуйся куклами, а не машинками и т.д.
Феминизм и меньшинства — очень, очень опасная тема :)
Ну это феминистки так считают — сейчас, пожалуй, такого стереотипа уже нет.
Присмотритесь на все окружение, включая игрушки: Кто нарисован на конструкторах, кто на коробках с куклами и т.д. Т.е. ту фиг знает что причина, а что следствие, но гендерные стереотипы есть и окружают детей везде.
У меня самого растут две дочки, я сделал отчаянную попытку вырастить двух программистов, но дальше Scratch дело не пошло.
У знакомого мальчик, но даже до скретч дело не дошло.
Самое обидное, что мы на грани переворота с «ног на голову». Я о том, что если на одну и ту же должность претендуют мужчина и женщина, то единственным критерием выбора должны быть деловые качества, но мы уже на грани того, что женщина получит преимущество только потому, что в отделе недостаток «слабого пола».Мне в кулуарах российского офиса одной международной компании открытым текстом говорили, что не могут найти подходящего по скилам кандидата. мол ты бы подошёл если б пошёл, но нам все равно надо взять девочку. Придётся учить.
Очень разочаровывает такое отношение, и вербовка "феминистов". Джон неглупый мужик, но видно, что он довольно наивный, и немного критического мышления и матстатистики ему бы не помешало, а то его ложными дихотомиями прям завалили настолько, что он во всем видит дискриминацию. Писсуары наверное тоже надо называть дискриминацией, ведь они уменьшают время, проводимое человеком в туалете в разы! Девочки играют в куклы только потому, что им об этом говорят родители, а на самом деле они все сплошь да рядом в солдатиков хотят да машинки погонять… Люди просто пытаются в упор не замечать разницы...
О, вот что еще придумал. 100% детей были рождены женщинами. По-моему, это дискриминация. Я требую, чтобы не менее 50% детей были рождены мужчинами.
Очень разочаровывает такое отношение, и вербовка "феминистов". Джон неглупый мужик, но видно, что он довольно наивный, и немного критического мышления и матстатистики ему бы не помешало, а то его ложными дихотомиями прям завалили настолько, что он во всем видит дискриминацию.
Из чего вы сделали такой вывод и какую матстатистику вы имеете ввиду? Джон ничего не говорил ни про писсуары ни про 50% — у него достаточно общие слова.
Статистика такая, что если только 20% девочек после школы идут в технические вузы, из них еще 20% идут работать по специальности, а из них еще 20% идут до кандидатской и защищают её. Вопрос, стоит ли ожидать, что на конференции по условным "сферическим затополуполям" будет поровну мужчин и женщин?
Да что там говорить, stackoverflow проводил же опрос масштабный недавно, по разным срезам, в том числе и по половому признаку. Уж не думаете ли вы, что на форуме, где человек сидит под анонимной аватаркой с ничего не говорящим именем "абвырлг123" будет подвергаться дискриминацией по половому признаку? Да в большинстве случаев никто даже не знает, какого пола тот или иной человек, благо в английском произношение от первого лица никак не выдает пол говорящего. Однако статистика там такая, что как будто всех девушек застращали и не пустили.
Тут обычно идут аргументы, что это их общество так задавило, вот они и не заходят, все начинается в детстве и т.п. Да не вопрос, подойдите тогда к деткам 10 лет и проведите опрос, среди мальчиков и девочек, кому нравится в компе копаться, а кому — с куклами играть.
В итоге имеем смешную (сквозь слезы) ситуацию, когда типа "задавленность" взрослых объясняется детскими травмами (которых по сути никто не видел), а "задавленность" детей объясняется тем, что на них давят общественное мнение, а из кого оно состоит? Да из взрослых. В итоге имеем типичную веру без аргументов, в которой есть 2 тезиса, ссылающихся друг на друга, которые конечно же невозможно опровергнуть. "Почему Бог всегда прав? Потому что так написано в библии. А почему нужно верить тому, что написано в библии? А потому, что Бог всегда прав" Поэтому это чистая демагогия в чьих-то не очень чистоплотных целях. Спорить с этим бесполезно, нужно только сделать для себя выводы.
Статистика такая, что если только 20% девочек после школы идут в технические вузы, из них еще 20% идут работать по специальности, а из них еще 20% идут до кандидатской и защищают её. Вопрос, стоит ли ожидать, что на конференции по условным "сферическим затополуполям" будет поровну мужчин и женщин?
С чего вы решили что он не знает эту статистику? Может именно это и его растраивает.
Да что там говорить, stackoverflow проводил же опрос масштабный недавно, по разным срезам, в том числе и по половому признаку. Уж не думаете ли вы, что на форуме, где человек сидит под анонимной аватаркой с ничего не говорящим именем "абвырлг123" будет подвергаться дискриминацией по половому признаку?
Кстати, Women considered better coders – but only if they hide their gender
Тут обычно идут аргументы, что это их общество так задавило, вот они и не заходят, все начинается в детстве и т.п. Да не вопрос, подойдите тогда к деткам 10 лет и проведите опрос, среди мальчиков и девочек, кому нравится в компе копаться, а кому — с куклами играть.
Почему вы решили что общество не может формировать определенные стереотипы в возрасте до 10 лет?
С чего вы решили что он не знает эту статистику? Может именно это и его растраивает.
Что его расстраивает? Физиология? Или мы считаем, что мужская и женская психика ничем не различаюстя?
Кстати, Women considered better coders – but only if they hide their gender
Такая статистика без нормального исследования не может считаться достоверной. Ну простой пример, у женщин как правило нет склонности к этим наукам, поэтому если она все же занимается этим, то это значит, что она сделала серьезный шаг и много над собой работало. В таком случае можно переформулировать как "программисты, которые над собой работают, добиваются большего успеха, чем средний кодер" — кто-то удивился?
Видео в тему:
Почему вы решили что общество не может формировать определенные стереотипы в возрасте до 10 лет?
Не стоит придираться к цифрам. Возьмите любых детей того возраста, где как вам кажется еще нет давления, и проведите опрос.
Что его расстраивает? Физиология? Или мы считаем, что мужская и женская психика ничем не различаюстя?
Если немного подумать, то в голову могут придти еще варианты кроме этих двух. Вы почему-то приписываете оппоненту радикальную точку зрения и пытаетесь с ней категорично спорить :).
Не стоит придираться к цифрам. Возьмите любых детей того возраста, где как вам кажется еще нет давления, и проведите опрос.
Провел — они одинаково отвечают на вопрос "Агу" :)
Если немного подумать, то в голову могут придти еще варианты кроме этих двух. Вы почему-то приписываете оппоненту радикальную точку зрения и пытаетесь с ней категорично спорить :).
Ну как бы закон исключенного третьего говорит о том, что либо отличаются, либо нет. Так что да, другого варианта кроме этих двух — нет.
Давайте подумаем вместе, какие могут быть еще вырианты?
Например чем-то различаются, но не в той мере чтобы обусловить такую сильную разницу в поведении :)
Придираемся к формулировкам? Ок. "Мужская и женская психика недостаточно отличаются для того, чтобы объяснить такую сильную разницу в поведении" — да или нет?
Придираемся к формулировкам?
Да именно категоричная формулировка человека который знает как оно на самом деле побуждает меня дискутировать с вами :)
Ок. "Мужская и женская психика недостаточно отличаются для того, чтобы объяснить такую сильную разницу в поведении" — да или нет?
Нет.
"Совокупность душевных процессов и явлений (ощущения, восприятия, эмоции, память и т. п.); специфический аспект жизнедеятельности животных и человека в их взаимодействии с окружающей средой[1]." мне кажется тут нет ничего про то, врожденное это или воспитанное обществом.
Я бы сказал так, "Надо убедиться в том, насколько врожденные или приобретенные факторы влияют на разницу в поведении и по возможности предоставить разным людям побольше возможности выбирать чем заниматься, особенно из групп которые исторически дискриминировались"
Есть мнение, что дискриминация есть, но она направлена как раз на белых мужчин.
Назвал я чёрного однажды чёрным,
И сразу получил клеймо "расист",
Характер женский я отметил вздорным,
и — БАЦ! — ещё одно клеймо — "сексист"
Противно видеть бородатых женщин — и я уже нетолерантный гомофоб.
Нас с каждым днём становится всё меньше,
К тому же я не верю в гороскоп,
В богов и духов, в Атлантиду и приметы…
Мне кажется, хоть я и не статист,
Что самый угнетённый тип на свете:
Мужчина. Белый. Натурал. И атеист.
Местами не согласен, но где-то так и есть. Ситуация с Оскарами, например, или всевозможные квоты в западных правительствах: не важно, какие у тебя скиллы, если ты женского пола или нетрадиционной ориентации — велкам.
Назвал я чёрного однажды чёрным,
И сразу получил клеймо "расист",
Ок — лирический герой сопоставил нейтральный врожденный признак нейтральному врожденному признаку (это если так, не ипользовал слово ниггер)
Характер женский я отметил вздорным,
и — БАЦ! — ещё одно клеймо — "сексист"
Вы не видите принципиальной разницы между этим двустишием и предыдущим? Тут он приписал половине человечества отрицательно окрашенный признак, вернее приписал отрицательную окраску нейтральному признаку "повышенная эмоциональность". Например в этой ветке вы высказываетесь в категоричной эмоциональной манере, но я же не оцениваю это как вздор, а обсуждаю с вами по существу. Если заглянуть в словарь, то мне кажется термин "сексист" вполне подойдет.
Противно видеть бородатых женщин — и я уже нетолерантный гомофоб.
Наверное что там ему внутри противно всем пофиг, мне вот тоже могут быть противны какие-то вещи (какая-нибудь безобразная рана или типа того). Другое дело что он выражает. Мы не знаем, но есл опять-таки посмотреть в словарь, вполне может быть, что если он не сдерживается перед выражением неприязни перед гомосеками он и нетолерантный и гомофоб.
Местами не согласен, но где-то так и есть. Ситуация с Оскарами, например, или всевозможные квоты в западных правительствах:
Разумеется если пытаться скоменисировать перекосы то может перекосить в другую сторону. Это нормально — надо любить людей и стараться помочь тем кому трудно но не давать сесть на шею.
не важно, какие у тебя скиллы, если ты женского пола или нетрадиционной ориентации — велкам.
То есть совсем не важно? Даже собесеования не проводят? Сразу половину населения принимают в правительство?
Итого: феминистические убеждения автора не означают, что он не знаком со статистикой. Он просто может ее интерпретировать не так как вы.
Если вы хотите разобраться в теме, рекомендую взглянуть на нее со стороны женщин — почитать феминистические сайты, побеседовать с жещинами об их жизни, причем чтобы выслушать, а не навязать свою точку зрения — с искренним любопытством.
Психика это продукт "обучения", а за основную часть обучения отвечают родители, у которых есть свои взгляды на жизнь.
Ага, потеснит Java на рынке. Через пару лет, в лучшем случае, .net core будет только готов к серьезному применению. Потом для него нужно написать софт и инфраструктуру, потом набрать опыт администрирования серверных приложений под эту платформу. А уже потом — "потеснит". Может быть.
Пока же .net core сильно отстает даже по быстродействию:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=csharpcore
Я думаю, что майкрософт пошел не туда — .net является лучшей платформой в мире для разработки оконных приложений. Если бы они портировали поддержку GUI на линукс и мак — это была бы бомба, даже если с платной лицензией.
Если бы они портировали поддержку GUI на линукс и мак — это была бы бомба,Поддержку GUI без BCL?
А так, не все анонсируют технологии, а отличить качественное XF приложение от полностью нативного невозможно.
Мораль сей басни обычно сводится к тому, что если хочешь сделать серьезный GUI в серьезном приложении — пиши отдельно на каждую платформу. Ну то есть примерно та же ситуация, что и с мобильными приложениями.
Очень мало людей использует линукс как рабочую операционную систему, а не серверную
Я щас чуть чаем не поперхнулся.
Поэтому и не используют(с gui проблемы), потому ms и не портирует, чтобы не терять рынок.
Запустите ради интереса этот бенч с CoreClr 1.1 собранным с PGO и ништяками C#7.
Для серверов весьма торт. А гуй нафиг. вон Электрон + Реакт и вперед.
Нельзя так просто взять и портировать гуи
(тут нужна картинка с Боромиром)
Сейчас в .NET есть два варианта создания GUI, и оба прибиты гвоздями к WinAPI. Портирование этого всего на линукс — само по себе нетривиальная задача, а тут надо еще и кроссплатформенно это сделать...
FMX и LCL отвязаны от WinAPI, на подходе crossvcl, тоже отвязанный от WinAPI.
Я думаю, что майкрософт пошел не туда — .net является лучшей платформой в мире для разработки оконных приложений. Если бы они портировали поддержку GUI на линукс и мак — это была бы бомба, даже если с платной лицензией.А они так и сделали, только наоборот — портировали поддержку линуха к себе =)
Ядро норм, гуи норм, теперь будет и шелл норм.
Разрабатывай, если хочешь, все на месте, без миграций (на встроенной линух-подсистеме). Окончательный результат задеплоишь куда-угодно в облака.
C# Гуй перестали развивать, как минимум активно. Возможный таргет (я не вижу этому опровержений) -> сервер сайд днет + JS клиенты
С самого появления на свет Джавы — Майкрософт стремится заменить ее на рынке своими продуктами и чуть ли ни каждый свой релиз кричит что вот-вот, ну завтра, в крайнем случае послезавтра, максимум через год — новейшая и лучшая дот-нет-какая-то-там вытеснит отсталую Джаву с рынка серверных технологий!..
Но через год у Майкрософта появляется дот-нет еще новее, еще лучше и еще серверней прежней и все начинается сначала…
Майкрософт слишком подвержена шараханиям от технологии к технологии и стремлению намертво привязать пользователя к своим продуктам, чтобы серьезные компании сделали окончательный выбот в пользу ее серверных прдуктов.
Такие «откровения» от майкрософтовского деятеля — либо реклама очередной «судбоносной версии дот-нет»
Джон Скит работает в Google; в работе на Майкрософт вроде замечен не был.
Но тогда «это все меняет», да?
И дот-нет вместе с ее явыками от МС от этого становится удивительно стабильной, без шараханий от технологии к технологии, без нагромождения ориентированных на МС сервисов/библиотек/продуктов, без гонки новых версий при недоработанных предыдущих?..
И дот-нет вместе с ее явыками от МС от этого становится удивительно стабильной
Да, C# язык удивительно стабильный.
нагромождения ориентированных на МС сервисов/библиотек/продуктов
Про ориентированные на МС сервисы говорить не буду, так как занимаюсь разработкой игр под iOS и Android. На C#.
Сама риторика типа «шараханий» и «нагромождений» свидетельствует о заведомой предвзятости. Развеивать ваши предубеждения я не берусь.
И все одновременно, каждая по пять-шесть версий с интервалом в год.
Это, по-вашему не «шараханья»?
И где они щас?
А к «морально-технологическому» облику МайкроСофт еще стоит добавить их откровенно грязную политику саботажа Джава-платформы (это когда всплыло их внутренне письмо о «всемерно дискредитировать идею многоплатформенности...»).
в девяностые немало повозился именно с нагромаждением...
Девяностые были двадцать лет назад.
письмо о «всемерно дискредитировать идею многоплатформенности...»
Терии заговора такие теории. Даже отсутствие подтверждений этих теорий в реальности, данной нам в ощущениях (и реально скачиваемых дистрибутивах), не способно пошатнуть слепую веру «умудрённых жизнью» адептов.
А девяностые были всего двадцать лет назад.
Про разногласия между Sun и Microsoft… Рекомендую почитать...
Это как аргумент к какому тезису? Что Майкрософт написало письмо про дискредитацию идеи многоплатформенности?
Было письмо, не было — этого я не знаю. А факт суда — да, был. И дискредитация была. Этим не сложно подпирать любую теорию заговора со стороны Microsoft против платформы Java.
Давайте подытожим.
С одной стороны мы имеем выложенные в публичный доступ сборки и исходники (под OSI-совместимой лицезией) компилятора Roslyn и платформы .NET Core, уже работающие под платформами macOS, Linux и Windows. (Вы всё врёти!)
С другой стороны какое-то внутреннее письмо и факт суда, которые якобы являются подтверждением дискредитации идеи многоплатформенности Майкрософтом. Хотя в первых ссылках Гугл выдаёт упоминания антимонопольного иска со стороны Sun против Microsoft, что, очевидно, дискредитирует только Джаву (сюда же можно вспомнить поползновения Оракла против Гугла насчёт Джавы в Android). (Баллмер чмо!)
Я правильно понял рассатновку аргументов? Давайте же на этом остановимся и предоставим читателям самим оценить поступающие свидетельства и критично обновить имеющиеся у них убеждения.
Цитирую
Было письмо, не было — этого я не знаю. А факт суда — да, был. И дискредитация была. Этим не сложно подпирать любую теорию заговора со стороны Microsoft против платформы Java.
Я не говорю было было письмо. Я могу лишь утверждать, что Microsoft не выглядит сторонником кроссплатформенности исходя из своего прошлого опыта. И что исходя из прошлого поведения данной компании можно строить теории заговора в направлении «дискредитации идеи кроссплатформенности».
P.S.: Меня в добрых помыслах Microsoft в области кроссплатформенности убедит только появление кроссплатформенной GUI библиотеки от Microsoft(сразу уточню, что я имею в виду десктопы, а конкретно Linux + MacOS + Windows) и кроссплатформенной Visual Studio на оном фреймворке. Но это лично мое мнение. Я его не навязываю.
P.P.S.: Отсюда
The dispute dates back to a Java licensing agreement that Microsoft signed in 1996. In November the following year, Sun filed suit against Microsoft for breach of contract, accusing the company of distributing a version of Java that was not compatible with Sun's. Sun amended its complaint in May 1998 to include charges of unfair competition and copyright infringement.Остальное вы думаю и так видели.
Я могу лишь утверждать, что Microsoft не выглядит сторонником кроссплатформенности исходя из своего прошлого опыта.
Это называется предвзятость выборки и предвзятость подтверждения. Из потока входящих свидетельств для обновления и переоценки своих убеждений использовать не все, а отфильтровывать те, которые подтверждают заранее имевшуюся точку зрения.
Например, бережно лелеять свидетельства двадцатилетней давности («прошлый опыт»), и полностью игнорировать свидетельства последнего года. При этом произвольно интерпретировать и назначать веса разным свидетельствам.
Меня в добрых помыслах Microsoft в области кроссплатформенности убедит только появление кроссплатформенной GUI библиотеки от Microsoft
Что делать языкам и платформам типа Rust, у которых вообще нет нормального GUI? Можно ли их считать кроссплатформенными? Если да, то останутся ли они таковыми после появления на них GUI-библиотеки только под одну платформу?
Это называется предвзятость выборки и предвзятость подтверждения.Разумеется. Вы правы. Я и не утверждал, что я не предвзят.
Что делать языкам и платформам типа Rust, у которых вообще нет нормального GUI? Можно ли их считать кроссплатформенными? Если да, то останутся ли они таковыми после появления на них GUI-библиотеки только под одну платформу?
Урф. Опять передергиваете. Кроссплатформеннй GUI под .NET за авторством Microsoft нужен как свидетельство доброжелательности Microsoft к другим платформам, а не как признак кроссплатформенности сам по себе. Если внимательно почитать комментарии — я неоднократно выссказывался о нужности проссплатформенного GUI библиотеки за авторством MicroSoft и нужности кросслатформенного IDE за их же авторством.
На текущий момент .NET Core является вполне себе кроссплатформенным решением и с этим я спорить не собираюсь. Ему не хватает нескольких нужностей для удобства использования мной. Именно их я и жду. Как появятся — буду внимательно смотреть на него и возможно даже изучу досконально для перенятия лучшего опыта. А может и сделаю что то для его развития. Альтернатива — это прекрасно.
При этом произвольно интерпретировать и назначать веса разным свидетельствам.Ну почему же произвольно-то?
Например, бережно лелеять свидетельства двадцатилетней давности («прошлый опыт»), и полностью игнорировать свидетельства последнего года.Ну дык это — обычный научный подход. Многократно преверенные и перепроверенные факты — важнее последнего единичного опыта.
А в случае с Microsoft'том есть ещё и дополнительное мета-знание: хорошо известно, что традиционная технология устроена так, что в первые годы Microsoft как бы в очередной раз показывает как он любит кросс-платформенность (про COM for UNIX и Microsoft Explorer for UNIX вы уж, наверное, и забыли — а я помню), а потом уже, через несколько лет делает так, чтобы у вас не было выбора.
Притом что это было проделано не один и не два раза, а повторялось на протяжении десятилетий… нужно быть последним глупцом, чтобы придавать большой вес «свидетельствам последного года»: если 20 лет назад они неверно предсказывали будущее, то почему сейчас вдруг всё станет по-другому?
Вот в мире где последняя версия MS IE для UNIX — не 5я, а 11я и где Edge — тоже кроссплатформенный… там да — свидетельства последнего года можно было бы принимать во внимание. А в нашем мире — нет, им верить нельзя…
Объясняю.
1. В те времена никакого.НЕТ еще не было.
2. МС и Сан были официальными партнерами по равитию Джавы (МС напросилось к Сан).
3. МС начала продвигать не-многоплатформенные изменения в Джаве и добиваться их стандартизцации.
4. Сан завозражали, но МС в нарушение соглашения занялись реализацией и распространением этих изменений.
5. Сам подала в суд.
6. Добрые люди-правдолюбы обнариодовали внутреннуюю переписку МС, где в качестве одной из целей Мс опрелелялось «дискредитация многоплатформенности Джавы».
7. Суд принял р3ешение в пользу Сан.
8. МС разобиделось и через несколько лет (ЕМНИП, года три) вылатило Си-шарп. Которых в начале ну удивительно был похож на Джаву.
Детали достаточно широко освещались в профильной прессе тех лет.
Из внутренней переписки между начальниками МС, в которой обсуждалась политика фирмы относительно Джавы и аглицким по-белому дикертивно определялись цели фирмы, очень неблаговидные.
ЕМНИП, предъявлено в качестве доказательства на суде, что и определило решение суда в пользу Сан.
1) Может MS уже перестанут ломится на платформы конкурентов, а всерьез уже возьмутся за развитие своей платформы, в лицензировании что нибудь исправят например. Вон Apple живет на своей платформе и не плохо так живет, с каждым годом все лучше и лучше живет.
2) Что это?, MS в очередной раз решило кинуть разработчиков под win платформу? Ау, чуваки, у вас под win все отлично работает и прям нечем больше заняться, а вот давайте dotNet на linux перепишем, а вот давайте python в MSSQL пихнем, а вот давайте c SilverLight что нибудь нехорошее сделаем и т.д. и т.п.
Вон Apple живет на своей платформе и не плохо так живет, с каждым годом все лучше и лучше живет.
Silverlight умер когда Google Chrome перестал поддерживать NPAPI.
Unity значит пользователи ставить себе соглашаются, а Silverlight — наотрез отказались? :-)
Что же до WCF RIA — это дополнительная возможность, а не нечто обязательное к использованию.
WCF RIA, на сколько я помню, был нужен обязательно для работы с датагридами от Silverlight. И вот пересадить оные на DTO вместо прямого подключения к контексту данных EF/Linq2Sql, да еще и попутно внедрить IoC привносило некоторый геморрой и нотку сюрреализма в решаемую задачу. Дело было давно, всех деталей уже не упомню, но я взялся тогда писать внутреннюю корпоративную админку для одного веб-сайта на этом стеке и меня постигла боль и разочарование при том, что изначально технология смотрелась весьма вкусно. Полагаю, я не один такой был.
Вы просто не с тем сравниваете. Альтернативой Silverlight является обычное десктопное приложение. Так вот — все механизмы, доступные ему, доступны и Silverlight, а еще в Silverlight есть WCF RIA. Обычный контекст EF/Linq2Sql, к примеру, декстопному приложению тоже не доступен если разработчики хоть немного думают о безопасности.
js и flash имеют еще большие проблемы с датагридами, нежели Silverlight
Что-то в мире не то. Ставлю камтазию.
Камтазия потянула дотнет 4.6
Дотнет выкачивается и ставится
Процесс установки уже второй час
$%^ его знает, что я делаю не так?
притом, оно не повисло. Оно ставится...
10 мбитный канал у него, если что.
Удобно, когда программам для работы не нужно еще кучи прослоек. Моё личное многолетнее мнение. Что бы кто ни говорил.
За такие заголовки я бы заставлял их менять…
Про JVM:
Сервер-сайд, мобильные устройства(андроид), встраиваемые устройства и устр. обладающие небольшими ресурсами, библиотеки/фреймворки почти на любой случай жизни, много качественных языков Java, Scala, Clojure, Kotlin, огромное сообщество, отличная кросплатформенность. Что из этого есть у .Net? С аналогичным успехом можно перейти на любую другую платформу. Реальная конкуренция JVM|.Net существует только в устах маркетолога MS и студентов которых научили #C за счет агрессивного продвижения всяких курсов в университетах.
Про .Net:
Если вдруг что-то случиться с JVM что звучит смешно если знать о экосистеме что-то за пределами маркетинговых усилий от MS. То я лично предпочту что-то не связанное с MS, почему? MS, исторически доказано, демонстрирует стратегию -> захват рынка и внедрение максимум проприетарных стандартов, после прекращение всякого развития как следствие следствие, вспомнить хотя бы веб захват рынком IE, офисного софта(сейчас есть альтернативы и это круто). Крупный бизнес: Google, IBM, Amazon, Facebook, Oracle и д.р. никогда не переведет свои продукты на технологии от MS, потому что это означает зависимость от MS который может манипулировать развитием технологии и лицензиями для давления на своих конкурентов, хотя бы на рынке облачных технологий. Есть варианты конечно, это полностью открытое и переданное в руки сообщества развитие .Net, включая соответствующую лицензию. Но возникает вопрос зачем, когда есть JVM которая сейчас отлично развивается, которая реализована не только для сервер сайда но и для мобильных устройств(Android), в экосистему которой входят готовые решения почти на все случаи жизни, тщательно протестированные и проверенные годами.
Сервер-сайд, мобильные устройства(андроид), встраиваемые устройства и устр. обладающие небольшими ресурсами, библиотеки/фреймворки почти на любой случай жизни, много качественных языков Java, Scala, Clojure, Kotlin, огромное сообщество, отличная кросплатформенность. Что из этого есть у .Net?Дайте подумать… всё?
под Intel Edison, Raspberry Pi 2, например можно UWP запускать.
Ну и Java Card это платформа, а не устройство
хотя кто мешает нормально в native компильнуться
Ни кто не мешает. Просто тогда вычеркните этот пункт из "все".
хотя кто мешает нормально в native компильнуться
Отсутствие нормального нативного компилятора. corert только с месяц назад перестал падать на Console.ReadKey
https://en.wikipedia.org/wiki/.NET_Micro_Framework
UPD: Именно то что нужно!
Простите но такого уровня поделки можно найти почти под каждый более/менее популярный язык.
https://github.com/NETMF репозиторий говорит сам о себе.
К тому же это не серьезная система поддерживаемая на уровне свей платформы а любительская разработка.
- Андроид: вычеркните пожалуйста .Net. Или по вашему в VM Android'а поддерживает стандартны .Net?
- Встраиваемые устройства, устройства с ограниченными ресурсами: можно ссылку на ресурс MS, где написано что поддерживают данное направление?
- библиотеки/Фреймворки почти на любой случай жизни: говорить что в .net все ок и хотя бы близко к тому что есть в мире JVM, это мягко говоря вранье.
- Java, Scala, Clojure, Kotlin: что есть для .Net? #F использование которого реально можно найти только под микроскопом.
- огромное сообщество: по сравнению с JVM сообщество у .net оно не большое.
- отличная кросплатформенность: отлично что MS начало что-то в это направлении, пару лет назад.
P.S.
Мне кажеста что для вашего уровня понимаия платформа и языки под неё это одно целое, т.е. C# и .Net.
Минусануть и написать три слова просто. Написать развернутый внятный ответ, нет. Простите что задел ваши религиозные чувства.
Андроид: вычеркните пожалуйста .Net. Или по вашему в VM Android'а поддерживает стандартны .Net?Я его и не вчеркивал. Речь была про мобильные устройства. С помощью Xamarin можно писать под Android и iOS, более редкие WP и Tizen поддерживают .Net нативно.
Встраиваемые устройства, устройства с ограниченными ресурсами: можно ссылку на ресурс MS, где написано что поддерживают данное направление?раз два
Java, Scala, Clojure, Kotlin: что есть для .Net? #F использование которого реально можно найти только под микроскопом.Из нормального C#, VB.Net, F#, C++. ну и всякие резвлекаловки типа brainfuck или портов питона и руби.
Как я и писал у вас нет понимания отличий платформы и языка. Xamarin это .net? Это транслятор для C#.
О встраиваемых устройствах. Первая ссылка на WIndows 10 т.е. на OS. Вторая на что-то любительское и уже мертвое судя по активности.
Из нормального C#, VB.Net, F#, C++. В итоге что-то ощутимо используемое для разработки под .Net это только C#.
P.S. я писал о платформе и в статье обсуждается платформа .Net. Давайте ограничимся этим. Левые ссылки на что-то что просто связано с деятельностью MS, не нужно приводить в доказательство.
По итогу получается что-то на .Net есть, но в меньшем кол-ве чем под JVM и в основном худшего качества, кроме продуктов которые непосредственно поддерживаются MS. Если бы под .Net все было в реальности так хорошо как вы пишите. Я, да и многие кто сейчас использует JVM уже давно бы использовали эту платформу.
Xamarin основан на Mono, так что это именно что реализация .NET, а не просто компилятор.
Xamarin это .net? Это транслятор для C#.Это .net-совместимая платформа, поддерживающая .NET Standart библиотеки. Если кто-то из нас не знает про Xamarin, то это точно не я.
О встраиваемых устройствах. Первая ссылка на WIndows 10 т.е. на OSВы просили ссылку на ресурс, где мс поддерживает это направление. Это именно та ссылка. win10 IOT с поддержкой UWP.
P.S. я писал о платформе и в статье обсуждается платформа .Net. Давайте ограничимся этим. Левые ссылки на что-то что просто связано с деятельностью MS, не нужно приводить в доказательство.Ну если вы не можете левое от не левого отличить…
Если бы под .Net все было в реальности так хорошо как вы пишите. Я, да и многие кто сейчас использует JVM уже давно бы использовали эту платформу.Отличная логика, я не использую — никто не использует.
Так что вы ошибочно разделяете платформу и язык. Они взаимосвязаны настолько, что если вы выбрасываете составляющую часть платформы — у вас перестают работать фичи языка.
Компилятору сиренево, где брать эти типы, в mscorlib или в вашей вручную изготовленной dll-ке. Я так LINQ и async/await на .NET 2.0 заводил.
Для сравнения авалония при отрисовке в фреймбуфер кушает порядка сотни. На 32-битном арме это ужмётся где-то до 70. Ну и системный линуксовый хлам скушает мегабайт 20. Но это всё пока на уровне альфы, да.
Java, Scala, Clojure, Kotlin: что есть для .Net? #F использование которого реально можно найти только под микроскопом.
А нам не нужно иметь 3 дополнительных языка только по той причине что основной язык создатели развивать не желают.
Java развивается отлично. Просто есть нюанс, обратная совместимость, которая очень важна в долгоживущих проектах.
К тому же в Scala/Clojure это далеко за пределами доп. фич в C#.
Ну так и в C# обратная совместимость терялась только 1 раз, когда скоуп для переменной цикла в foreach заменили — но то изменение исправило больше багов чем создало.
Что фич в Scala/Clojure больше — я не спорю, это шутка была.
Но полного аналога LINQ в Scala все равно нет.
LINQ может только читать, прочие возможности не поддерживаются.Начнем с того, что Linq это не только для БД, это для декларативно-функциональной работы с любыми коллекциями независимо от источника.
Попрошу так же заметить, что в java традиционно поддерживаются api не только для чтения, но и модификации данных в БД.Вы не поверите…
Но это же ужас какой-то...
query()
.select(Projections.constructor(
ProductDTO.class, PRODUCT.ID, PRODUCT.NAME, PRODUCT.LAUNCH_DATE)
)А что если в конструкторе ProductDTO не три параметра? А что если там другие типы данных?
Тот самый "чисто IQueryable" такие вещи проверяет.
Кстати, тут пишут что Clojure может исполняться в CLR...
Java развивается отлично. Просто есть нюанс, обратная совместимость, которая очень важна в долгоживущих проектах.
Если рассматривать только синтаксис языка, то C# оказывается более динамично развивающимся, чем более инертная Java. Нововведения, появляющиеся в C#, доходят до Java только через год-два.
http://www.netmf.com/.
Ну расскажите чего не хватает.
Вообще есть Scala.Net. Только нафиг никому не сдалась. ClosureClr. Сравнивая C#7 c Kotlin и Scala… ну как бы они и не нужны особо, так как ЯП очень активно развивается в сторону гибрида между OO и FP.
Это вы как посчитали?
Позвольте поправить, scala все таки далеко до F#, но есть Clojure
- Нормальный pattern matching
- Discriminated union
- Record types
- Нормальный type inference
- Active Patterns
- Отсутствие множественного наследия, объектов компаньонов и прочей ненужной фигни
- Интеграция с Azure, оператор cloud
- Type providers
- Итд итп
Мой следующий проект я буду вынужден пилить на скале, как бы я хотел что бы он был на F#.
P.S.: Если сравнивали с oCaml — будет любопытно почитать.
Пока нет. И это не Ф диез а FSharp даже по FR. В oCaml плюшек будет больше но он не на .NET.
Кстати, где то читал, что там оригинальный знак должен быть именно диезом.
Судя по логотипам — очень на то похоже.
UPD: Это реально диез. Тык!
У Java есть Clojure — Лисп поверх JVM.
Да и в целом, альтернативных языков для JVM полно: Groovy, Kotlin, Scala. Хотя у .Net тоже выбор есть: VB, F#. Это все не считая Ruby и Python, которые могут использоватсья и там и там, хотя я не знаю, насколько это распространено.
VB.NET появился для удовлетворения одной объективной потребности — миграции внушительного количества
Ваше замечание было бы хорошим аргументом, если бы вы упомянули, скажем, Nemerle или Boo :). Но вот беда — оба они широкого распространения не получили и так и остались на уровне такого своеобразного концепта, который люди реферируют в пламенных интернет-дискуссиях, когда надо подчеркнуть богатство возможностей CLR/CTS/CIL. Не встречал ни одного человека, который использовал бы оные в продакшене. Nemerle бедный — так вообще загнулся в развитии по ходу дела и остался притчей во языцех и интересным материалом для теоретических исследований.
Ну т.е. под .NET не было такого случая, когда команда сторонних по отношению к платформе людей заявляет с огромной помпой что вот, мол, сейчас мы сделаем самый-лучший-язык для JVM, который будет лучше чем Java. И в результате получается Scala или Kotlin, который активно начинает использоваться в живом продакшне и в который влюбляются тысячи разработчиков — уж не знаю плохо это или хорошо.
То есть поймите меня правильно, за столько лет ничего лучше чем C# для продакшна и массового использования придумать не удалось :)
Вот список языков, о которых вы никогда не слышали и не станете использовать в продакшне
А агрессивно продвигает всякие курсы в университетах все равно Microsoft, ну.
Наладить контакт с Microsoft просто чтобы выбить ну хоть какую-то поддержку локальному коммьюнити (хотя бы информационную — о деньгах не говорю) — оооочень сложная задача в отличие от безгрешного в ваших устах Oracle. Даже гугл лучше поддерживает локальные коммьюнити.
базы данных на Oracle зачастую с жестким ограничением на него в лабораторных работахЧто не мешало мне подключаться к нему из дотнета.
компьютерная графика — на Java (но тут правда у студентов есть выбор)Когда я учился там ещё был препод, который на MFC древней версии заставлял писать. Потом его таки подвинули.
на терминальных компьютерах в дуалбуте стоит (стояла?) солярка с LibreOffice.За это нужно сказать спасибо ровно 2м людям. Тов. Иртегову, и товарищу ex Java Ambassador Романенко, последний в том числе терминальные классы админил и пассивно-агресивно противился раздаче ПО из купленного ФИТом MSDN )
Гугл двигает комьюнити инициативами другого небезразличного частного лица. Собственно есть вузы, где МС продвигается примерно как у нас Java то же за счет личной инициативы. Просто в нск менталитет специфичный, тут ни одно МС-сообщество не зашло.
Что не мешало мне подключаться к нему из дотнета.
Само собой. Однако если не интересуешься, то кроме Oracle ничему и не научат. Именно на это одностороннее освещение я и указывал.
Когда я учился там ещё был препод, который на MFC древней версии заставлял писать
Я тоже писал графику на MFC. Сейчас Java с возможностью выбора.
пассивно-агресивно противился раздаче ПО из купленного ФИТом MSDN
Ну и зачем? Люди деньги потратили, купили, а тут внутри все отказываются использовать, мотивируя это… чем?
мотивируя это… чем?Ничем. По-нормальному, там надо заводить студентам акки, чтоб они сами скачивали. «настраивать долго и интернет в нгу(2008) плохой забьют канал». Поэтому писалось все на болванки и очень нехотя.
Когда это добро перешло в другие руки, девушка хотела настроить заведение студентов, но я не знаю, чем это закончилось. На других факультетах (ММФ, ФФ) примерно так же.
Именно на это одностороннее освещение я и указывал.Я еще помню как в 2006 первокурсникам раздали блокнотики sun с «live»-CD солярки. Причём на CD был записан ISO-файл :D. Кстати, региональный представитель Sun'а живет(жила?) в академе (последний раз я видел её в IBM). Вероятно это тоже сыграло большую роль на засилие Sun в НГУ. Универам-то особо без разницы с кем сотрудничать.
Ну а вообще, в МАИ, ТПУ, в Кемерово (вуз не помню), в некоторых других вузах МС хорошо зашел.
Она уже 15 лет теснит. Таким макаром она будет еще лет 100 теснить.
В среде джавистов говорят, что даже если появиться язык заменяющий джаву то хорошо оплачиваемой работы будет еще года так 4. Так как 60-70% ентерпрайза на джава.
Да, .Net уже много лет успешно теснит Java на enterprise-рынке. Не вытесняет, но долю свою имеет. .Net Core только-только зарелизился и у него еще все впереди. Собственно Jon Skeet и утверждает, что через год-два технология достаточно повзрослеет, чтоб начать какое-то значительное внедрение в enterprise. Собственно тогда она отъест некую долю от Java на не-windows платформах.
А вы тут уже java-капец разглядели…
Чтобы подсказывать что там вообще в Java-коде написано и зачем так было сделано, очевидно же...
К примеру, меня в свое время смутили property в C#. Думаю, что то непонятно и непривычное для C# можно найти и в Java.
Как можно жить без Property?
@Data
public class Example {
private final String ururu;
private final int arara;
public static void main(String[] args) {
Example ex = new Example("Ага!", 3);
System.out.println(ex);
}
}
Я уж не знаю, в шарпе есть аналоги?
Вполне
class Example
{
public string ururu { get; set; }
public int arara { get; set; }
public static void Main(string[] args)
{
var ex = new Example
{
arara = 3,
ururu = "Ага!"
};
System.Console.WriteLine(ex);
}
}Правда, поля не будут выведены в WriteLine.
Ну и immutable класс — тоже важно.
Это просто пример то, что может удивить и с чем придется разбираться. А так то все просто — мы при помощи маленькой аннотации сгенерировали:
- конструктор
- геттеры (не были бы поля final — сгенерировались бы и сеттеры)
- equal and hascode
- ну и toString заодно
Умеет ли так C# — я не знаю. Нужно ли это там — тем более не знаю.
Умеет ли так C# — я не знаю. Нужно ли это там — тем более не знаю.
Умеет, нужно. Например для реализации интерфейса INotifyPropertyChanged часто используют.
То есть какого-то общеупотребимого набора инструментов вроде lombok в C# нет?
А существование коммерческих решений для подобного — для меня это показывает разницу в мировоззрении. С тех пор как перешел на jvm я уже не могу себе представить платные решения для тивиальных действий — скорее приходится выбирать из нескольких свободных.
[NotifyPropertyChanged]
class Calc
{
private int a, b;
public int Sum
{
get { return this.a + this.b; }
}
public void Update(int a1, int b1)
{
this.a = a1;
this.b = b1;
}
}
static void Main()
{
Calc calc = new Calc();
((INotifyChildPropertyChanged) calc).PropertyChanged +=
(sender, eventArgs) =>
{
Console.WriteLine("Property {0} changed. New value = {1}.",
eventArgs.PropertyName,
sender.GetType().GetProperty(eventArgs.PropertyName).GetValue(sender));
};
calc.Update(1, 2);
calc.Update(2, 1);
}
static void Main()
{
Это просто демонстрация, что кодогенирация работает. То есть просто привели к интерфейсу который был добавлен генерацией, и подписались на него.
Сам атрибут кодогенирации это [NotifyPropertyChanged] и все. Или о чем вы?
И передача по значению — не всегда хорошо. Но иногда полезно, особенно при размещении в массиве. В jvm структуры сейчас добавляют, но только в immutable варианте.
И Data class — класс с полноценными методами, который можно проксировать, инструментировать и извращаться всеми остальными способами. Иногда и это важно.
К примеру, меня в свое время смутили property в C#
в c# 6 они и меня смущают. А ещё есть события, асинки и т.п. Впрочем в Java тоже есть парочка конструкций, которых нет в c#. Но так или иначе, я ещё не видел андроидовского кода, который был мне непонятен с точки зрения языка настолько, чтоб самому не разобраться.
Прочесть код еще не означает понять его. Даже на знакомом ЯП бывают фрагменты кода, про которые невозможно сходу сказать бизнес-логика это, инфраструктура, костыль, велосипед или просто говнокод — а на чужом к этому списку добавляются еще и boilerplate-код для чужих фреймворков.
Вот свежий пример, C#. Попробуйте угадать что этот код делает.
mapping.Map(data, this);
mapping.End();
// начало загадочного фрагмента кода
if (SelectedItem != null) {
var old = SelectedItem;
SelectedItem = Items.Where(item => item.Id == old.Id).FirstOrDefault();
if (SelectedItem != null) {
SelectedItem.IsSelected = old.IsSelected;
}
}Даже на знакомом ЯП бывают фрагменты кода, про которые невозможно сходу сказать бизнес-логика это, инфраструктура, костыль, велосипед или просто говнокод — а на чужом к этому списку добавляются еще и boilerplate-код для чужих фреймворков.Вот вы и сами сказали, что что у Java-разработчика не так уж и много преимуществ при чтениии портировании кода на .Net.
Боюсь, что нового вот прямо такого же нет. Но если посмотреть статьи в нашем блоге по хабам .NET/C# + JUG.ru Group — что-нибудь интереное может всплыть.
Это, собственно, основа, на которой держится Java в Enterprise: возможность сделать программистов «винтиками».
Java, при всех улучшениях, остаётся на уровне, когда её можно давть в руки даже не полному дебилу, а «олигофрену с инструкциями». И её тщательно удерживают на этом уровне не допуская сложных конструкций в сам язык. Кое-что, с боями, протаскивается — но это слёзы. Большая часть сложных (и реально клёвых) вещей — в сторонних библиотеках (а их использование можно легко ограничить).
C#, C++, Haskell и прочее — требуют разработчиков рангом повыше, ценой подороже… нафига это «эффективным манагерам»? Им же нужно собственную эффективность повышать, а не программистам ФОТ увеличивать…
Чем текущий .net core 3 не клон Java?
Версия 3.0 — времянка, а вот 3.1 — уже LTS, поддержка заканчивается в декабре 2022 года. Написано здесь: https://dotnet.microsoft.com/platform/support/policy/dotnet-core
и как ? потеснило ? :)
Всё еще не потеснило...
«Через год-два .NET Core потеснит Java на рынке enterprise решений», — Интервью с Jon Skeet, Google