Как джависты сделали .NET-конференцию

    В .NET-мире есть беда с пониманием рантайма. Ведущие разработчики крупных .NET-компаний, безусловно, понимают общие принципы работы GC, JIT-компилятора, аллокатора и других компонент. Но даже они признают, что не знают деталей. Книги Рихтера помогают узнать какие-то базовые вещи, но не более того. Отсутствие внятных технических докладов о CLR (и зарубежных и русскоязычных) от инженеров Microsoft порождает ненужное брожение в умах девелоперов. Закрытость информации порождает нежелание лезть вглубь. Всё равно фиг узнаешь, что там майкрософтовцы понаписали.

    Осознав эту проблему, в апреле этого года мы вместе с компанией JetBrains провели конференцию .NEXT 2014 Piter, посвященную техническим аспектам программирования на .NET. Послушав некоторые доклады и вволю наобщавшись с людьми в кулуарах, я и сделал вывод, о котором написал выше. Под катом я расскажу о деталях прошедшей конфы и о том, на какие мысли они меня навели.




    Идея новой конференции

    Вот уже два года как я занимаюсь организацией разных технических ивентов. Получается неплохо — народ доволен. Специализируюсь я на Java-ивентах: митапы Java User Group и конференции. В Java-стеке (и в том числе в Java-организации внутри Oracle) я проработал несколько лет, и поэтому примерно понимаю, что происходит в Java-мире.

    Около года назад парни из JetBrains пришли к нам с такой мыслью: мол, раз у вас так неплохо получается делать ивенты по Java, давайте сделаем совместный ивент и для дотнетчиков. Моя дотнет-практика до той поры ограничивалась годовым курсом в питерском универе и небольшой стажировкой в одном из стартапов в конце двухтысячных. Тем не менее, идея показалась интересной: во-первых, посмотреть на мир .NET и понять, что у вас, ребята, нынче творится. А во-вторых, попробовать сделать конфу по технологиям, в которых, как думалось, я мало что понимаю.

    Мы готовились два месяца. Самым трудным оказалось собрать докладчиков. В плане спикеров у нас получился сильный перекос в сторону JetBrains: 6 докладчиков из 13 представляли именно эту компанию. Это связано с двумя вещами. Во-первых, наш программный комитет состоял из двоих ДжетБрейнсовцев: mezastel и philipto. Они знали нескольких сильных спикеров из JB, и позвали их в первую очередь. Во-вторых, о конференции мало кто знал. В форму Call-for-Papers мы получили только две заявки. И только один из двух CFP-докладчиков в итоге смог приехать.

    Интересно тут вот что. Этот, казалось бы минус, странным образом сыграл непосредственно в день конференции. Во-первых, как выяснилось, именно джетбрейнсовские доклады собирали больше народа. А во-вторых, в рейтинге докладов, собранном из отзывов участников конфы, докладчики из JetBrains заняли первые 5 мест. Вот такой вот перекос.

    Открытие

    Конфу открывал Дима Нестерук aka mezastel. Немного философии, немного решарпера, немного общих вещей об индустрии, причём не только дотнетовской. Дима прошелся по больным вещам — скорость разработки, классические задачи vs специфические. Плюс много разного от фишечек R# до кодогенерации. Никакого хардкора, классический keynote.


    Добро пожаловать в .NET

    После Java, в которой всё открыто, мир дотнета кажется очень странным: GC нигде толком не описан, рантайм закрыт, про JIT вообще ничего не понятно. На эти темы существуют какие-то посты в блогосфере, но не более. Даже разработчики ReSharper'а, которые, казалось бы должны знать все детали, иногда теряются в догадках о том, как работает та или иная часть дотнетовского рантайма.

    Это показалось странным, и поэтому мы позвали Стаса Сидристого aka sidristij из Luxoft рассказать какие-то куски о рантайме. Судя по отзывам, получилось довольно хардкорно. В отзывах очень чётко прослеживается два тренда: «доклад скучноват, лучше бы блогпост» и «интересно, но не применимо на практике». Иными словами, закрытость CLR приводит к тому, что народ в дотнет-мире не очень привык лезть в дебри, а больше ориентирован на практические вещи. Это было первое важное наблюдение.

    Наши джавовские приколы с мясом, расчленёнкой и внутренностями C2-компилятора, которые на ура заходят на наших хардкорных Java-конференциях, тут не прокатили. Нужно ли двигаться в этом направлении, и объяснять дотнет-народу, как важно знать внутренности? Или забить и концентрироваться на тулинге? Вопрос открытый.

    А что касается блогпоста — Стас вас услышал. Много хардкора есть в его блоге на хабре.

    Об управлении зависимостями

    Сергей Шкредов, глава .NET-подразделения JetBrains, нечасто появляется на публике. Тем интереснее было слушать его доклад о том, как они у себя в проектах разбираются с зависимостями. Получился высокоуровневый обзор. Ключевой, на мой взгляд, тезис был озвучен в самом начале: управление зависимости и развертывание приложения — это разные вещи, и смешивать их не стоит. Доклад вызвал оживлённую дискуссию, участники не отпускали его после доклада еще часа полтора — дискуссия продолжалась и в перерыве, и в течение следующего доклада.



    Профилирование

    Кирилл Скрыган, мой школьный сосед по парте, сделал прекрасный доклад о профилировании и оптимизации. С одной стороны — это был лучший (по отзывам участников) доклад конференции: техники оптимизации узких мест, асинхронная работа с UI, Memory Traffic и т.п. С другой стороны — у меня было дикое разочарование на фоне докладов Шипилёва и Куксенко из Java Performance Team.



    И вот тут надо пояснить. Фокус в том, что Кирилл рассказывает о профилировщиках. При этом, например, весь российский Java-мир давно уже знает, что профилировщик — это не первая, не вторая и даже не третья по порядку утилита, которую нужно открывать, если твоё приложение тормозит. (если кому-то интересно, по мотивам рассказа оракловых инженеров, Игорь Мазница сделал в 2012 году прекрасный Performace Mind Map, который рассказывает о том, куда копать в случае той или иной проблемы).

    О чем это говорит? На мой взгляд, о том, что отсутствие хардкорных майкрософтовских девелоперов в России вкупе с закрытостью .NET-платформы сильно бьёт по нашем с вами знанию этих технологий. Именно поэтому мы, на мой взгляд, и слышим чаще и чаще обо всех проблемах озвученных Кириллом.

    Что генерится в рантайме из лямбды? Сколько операций боксинга/анбоксинга генерит какая-нибудь неявная операция и сколько мемори траффика возникает в процессе? Что делать со «среднеживущими» объектами в памяти? Как в сборщике мусора в дотнете работают эвристике? Опирается ли он на слабую гипотезу о поколениях и если да, то каким именно образом? Как понять, что тот или иной алгоритм в библиотеках или внутри рантайма изменился (GC, JIT, collections)? Короче, одни вопросы.

    Microsoft не осталась в стороне

    Ромуальд Здебский рассказал на конференциях о новостях с апрельского Build. Вышло очень забавно: еще за два-три дня до .NEXT он не понимал, о чем ему можно рассказывать, а о чем нет. В итоге он ночью смотрел на идущий параллельно нам Build conference, а днём готовил доклад.



    Сначала Рома рассказал о развитии платформы в целом, а потом еще долго отвечал на вопросы в кулуарах. Наш фотограф минут 40 пытался вытащить его на фотосессию, но в итоге забил и побежал фотографировать других докладчиков. Фоткать Рому пришлось позже.

    Гигиена памяти от Романа Белова

    Самое интересное, на мой взгляд, выступление конференции. Рома был неспавший, у него болел зуб, но он героически преодолел все эти трудности и сделал блестящий доклад о том, какие трудности есть с памятью в современных Managed-средах. Кто-то перезагружает сервера раз в неделю, кто-то избавляется от WPF, кто-то тратит кучу времени на оптимизацию статического футпринта. Рома обо всем этом так или иначе рассказывает и показывает решение, к которому пришли парни из JetBrains.



    Итоги

    Конференция была однодневной: 2 потока, 14 докладов. Участников было 300 с небольшим. Тематика — сугубо техническая: никакого буллшита карьерный рост, истории успеха, собеседования и прочие гибкие методологии. Нам хотелось посмотреть максимально плотно именно на технологическую составляющую современного дотнет-мира. И это, могу уверенно сказать, нам удалось. Полный обзор докладов и лучшие видео с конфы — на её сайте.

    Сюрпризов было два. Во-первых, проблемы, с которыми борется современный дотнет-мир, очень сильно напоминают проблемы, с которым борется современный Java-мир. Это производительность (во всех смыслах этого слова), утечки памяти, тулинг для повышения эффективности современной работы, новости технологий от вендоров, автоматическое тестирование в различной форме, внутренности рантайма, кроссплатформенность. Во-вторых, это закрытость рантайма и, как следствие, отсутствие понимания его внутренностей даже у очень сильных разработчиков. И, как следствие второго уровня, понятие «сильный разработчик» из традиционного Java-мира здесь не работает. Акценты смещены с понимания рантайма на какие-то другие вещи. Какие — мне еще только предстоит разобраться.

    Анонс .NEXT в Москве

    Совсем скоро, 8 декабря, мы вместе с JetBrains проведём новый .NEXT — и на этот раз в Москве. Снова — технические доклады: никакого буллшита про карьерный рост, истории успеха, собеседования и прочие гибкие методологии. Наверное, на этот раз будет чуть меньше хардкора и чуть больше тулов. Благо, экспертов по тулам у нас в России довольно много.

    Три зала, 18 докладов по 60 минут: 40-45 минут на доклад и обязательно 15-20 минут на вопросы-ответы. Вообще, отсутствие нормальной дискуссии из-за затяжек докладов начинает бесить. Будем жёстко останавливать спикеров на сорок пятой минуте, чтобы дать народу возможность задать вопросы :)

    Пока что у нас снова перекос по докладам в сторону JetBrains и Microsoft, и именно поэтому мы очень-очень надеемся на хабрасообщество. Народ, нам нужны ваши доклады! Для подачи доклада просто заполните форму заявки.

    Сайт конференции: dotnext.ru.

    Приходите, будет интересно!
    JUG.ru Group 468,57
    Конференции для взрослых. Java, .NET, JS и др. 18+
    Поделиться публикацией
    Похожие публикации
    Комментарии 64
      +2
      Опа, меня добрым словом помянули =) Для меня «хардкор» — доброе слово )))
        +1
        Подавай-ка нам заявку в CFP!
          0
          Посещал твой доклад, было очень интересно, но к сожалению в мире .Net такой хардкор, имеет чисто академический интерес.
            +1
            Почему академический? Разве понимание внутренностей среды исполнения не усиливает разработчика?
              0
              Если этим знаниям нет практического применения, то нет не усиливает.
                0
                А какие вещи, на ваш взгляд, требуют подробного рассмотрения? Или таких вещей нет?
          0
          А что за второй сюрприз был?
            0
            Закрытость рантайма. Классический вопрос на интервью Java-разработчика — «расскажите, как работает сборщик мусора». Такие вопросы задаются дотнет-кандидатам?
              0
              не знаю — не ходил на собеседования по .Net
                +3
                Задаются. Хотя конечный алгоритм все же проприетарный.
                  +4
                  То есть, спрашиваются общие вещи на понимание? Граф объектов, достижимость, корни обхода, гипотеза о поколениях, фазы, подсчет ссылок.

                  Еще вопрос — сборщик один? В Java сборщиков — вагон и маленькая тележка. Вот подборка статей Алексея Рагозина, например.
                    +6
                    Да, спрашивают общие вещи на понимание. Как объекты переходят из поколение в поколение. Как происходит Dispose, что там и как происходит, сколько объект может висеть в очереди на удаление. Как можно потыкать палочкой GC.
                    Достижимость, корни, как объекты живут на стеке и когда оттуда уходят.

                    Сборщик мусора в .net один и везде, насколько я помню, утверждается, что тюнить его и работать с ним надо в последнюю очередь. Так как себе дороже может оказаться со всем этим возиться. Единственное что порой рекомендуется делать, явно указать профиль работы: standalone или server (как-то так кажется. )

                    Сборщик мусора еще немного меняется от версии к версии самой платформы и изменения особенно не афишируются.
                      +2
                      Да все вопросы чисто теоритические. Сборщик один, режимов работы несколько, хотя по факту их можно назвать разными сборщиками.
                0
                Записи об управлении зависимостями нет? Очень интересно было бы.
                +4
                Вы утверждаете, что .NET разработчики не интересуются внутренностями, в то же время на лекции Станислава Сидристого, которая проходила летом, народу было хоть отбавляй. Да и вопросы про сборку мусора, лямбда выражения и прочее уже давно стали стандартом на собеседованиях. Даже в самой базовой книге по .NET (Троелсен) приведены примеры IL кода.
                  +2
                  Я немножко другое утвеждаю: закрытость информации не даёт возможности нормально изучать предмет. Про Станислава Сидристого и то, чем он занимается я уже написал в посте. И очень круто, что у нас есть люди, которые серьёзно эти проблемы изучают. К сожалению, таких людей немного.

                  По поводу Троэлсэна — сейчас у меня в руках русский перевод шестого издания (C# 5.0, .NET 4.5). Да, там есть целая 18 глава про CIL (как положено, синтаксис и семантика), но что-то я не вижу там особо про рантайм. CIL — это не совсем внутренности. Это всё ДО рантайма.
                    +1
                    Добавлю также, что заинтересованность людей в вопросе возникает при появлении информационного потока о чем-либо. Чем плотнее поток, чем ярче заинтересованность. Т.е. чем чаще начнут появляться данные исследования, тем плотнее люди начнут интересоваться этим, пусть даже, зачастую, академическим вопросом.
                  +1
                  Нужно было позвать в докладчики DreamWalker
                  0
                  На мой взгляд у Рихтера все достаточно подробно описано.
                    0
                    А на мой — подробно про поверхностное )) Подробнее — у RedGate «Under the Hood of .NET Memory Management », например =)
                      +2
                      Сразу скажу, что я не спец в дотнете. На мой взгляд, Рихтер — это неплохая вещь. Конкретно в четвертом издании (.NET 4.5) в главе по сборке мусора есть довольно много и про эвристики и про IsServerGC и про GCLatencyMode. Но к сожалению это всё на уровне «если вы сделаете вот так, то GC будет вести себя вот так-то».

                      Представьте, что вы управляете автомобилем. Рихтер показывает, как включить тот или иной режим двигателя, показывает, какие есть опции и рассказывает общие вещи о двигателях внутреннего сгорания. Но, на мой взгляд, не более того.

                      Подскажите, например, где можно прочитать про JIT, про алгоритмы сборки, про то, как устроены эвристики в том же GC, про модель памяти. Я люблю такие штуки, мне будет интересно сравнить с Java.
                        +6
                        Оно всё понятно, что это интересно. Но 99% разрабов не нуждаются в таких знаниях.
                        Я участвую в разработке приложения, к которому предъявляются очень жёсткие требования функционирования 24х7. Но мне ни разу не понадобились эти знания. Ни разу, понимаете? Сегодня работодатель требует в 99% случаев знания фрэймворков, а-ля WCF, WPF. Эти фрэймворки просто громадны. Чтобы быстро девелопить, надо достаточно большую часть их держать в голове. Как в голове ещё уложить и те знания, которыми ты либо никогда, либо почти никогда не пользуешься? Я и части фрэймворков постоянно забываю. Из-за всего этого апатия наступает.
                      +1
                      Видео по профилированию то же самое, что и первое.
                        +1
                        fixed! Спасибо, что заметили!
                        +2
                        Сам Явер но поймал себя на мысли что послушал бы с удовольствием. Интересно сделано. Приезжайте в Воронеж :-)
                          +2
                          Спасибо. Лучше вы к нам.
                          +2
                          Чтобы по хардору все было — надо было Mono обсуждать. Там и свои закидоны со сборщиком мусора и открытость в наличии.
                            +1
                            Mono — супер! Знаете кого-то, кто может о нём рассказать? Желательно, кого-то из разработчиков самой моно или кого-то, у кого моно в продакшене?
                              +1
                              Стоит поспрашивать среди тех, кто плотно с Xamarin работает. Думаю, это то, где сейчас водятся профессионалы по Mono (из известных мне контор — TouchInstinct, причем вроде бы они даже партнеры Xamarin в России). Даже я уж на что не считаю себя разработчиком, но с багами GC в mono разбирался лично. Поэтому у них точно должен быть опыт :)
                                0
                                TouchInstinct более не работает на Xamarin, перешли на нативку. Устали бороться с Xamarin+Android частью. Там два GC: Java+mono. И одно это создает проблемы. Плюс ко всему супербажный runtime. iOS+mono работает отлично, багов мало. Но теряется смысл кроссплатформенности без андроида
                                  0
                                  Вот, значит я прав, что им есть о чем рассказать :)
                                    0
                                    а есть кто-то у тебя из знакомых, кто может эту или похожую историю рассказать?
                                      +1
                                      Сева может в красках рассказать… Сейчас в личку скину
                                      0
                                      Есть слабая надежда, что MS поможет Mono переболеть.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    Отключайте коданализ, помогает :)
                                  +1
                                  Ложка дегтя:
                                  1. Организация — были дикие очереди за кофе
                                  2. 700р за унылый обед, цена которому оптом максимум 150р
                                  3. Доклады реально вытащили ребята из JB. Общее ощущение осталось, что просто хотели поднять бабла в ущерб качеству.

                                  Организаторы простите меня, если я не прав, но нас пришло 7 человек и мнение у всех одно и тоже.
                                    0
                                    Все претензии принимаю. Очереди временами были, обед мог вполне Вам не понравиться и доклады ДжетБрейнсовцев действительно были на полголовы, а то и целую голову, выше остальных.

                                    При этом хочу обратить внимание на то, что билет с обедом в самой максимальной своей версии стоил 2500 рублей. То есть, по курсу того времени, порядка 60 евро.

                                    Что касается 7 недовольных человек — мы без проблем вернём всем недовольным деньги. Мы отвечаем за то, что мы делаем, и поэтому для нас это вообще не проблема. Напишите мне по этому поводу в личку.

                                      0
                                      т.е. я правильно лайфхак понял?

                                      оплатил, пришёл, словил как и везде очередь за кофе/печеньками, возмутился и получил деньги обратно? :)
                                        +3
                                        Видимо да. Мы работаем в длинную, нам неинтересно терять клиентов.
                                      +6
                                      Отвечу как организатор семинара CLRium и организатор другой конференции, которая, надеюсь, случится. Обозначенные цены находятся на балансе риска с легким смещением в сторону прибыли. Во-первых в Москве достаточно высокие цены на большие площади арендуемые. Особенно, если чтобы всем было удобно. Второе: помещения не разрешают организовывать питание самостоятельно: только их кафе. Только их ценники. В работе конференции участвуют фотографы и операторы, которые берут если вы посмотрите на те же группы в контакте ну оччень не дурственно. Отсюда, если все суммировать, при этом учтя риски недонабора зала, учесть налоги и отчисления в страховой, учесть процент, который берет площадка для покупки билетов. Учесть возвраты, которые идут по форс-маржорным обстоятельствам до конференции… То 2500 — это балансовая сумма, прибыль с которой равна месячному доходу каждого кто принимал участие в ее организации, причем организация такого события требует 100% отдачи каждый день. Когда я делал CLRium, у меня не хватало времени на общение с женой, поскольку после основной работы я постоянно отвечал на десятки писем, искал помещения, договаривался и проч. Это только кажется, что деньги большие.
                                        0
                                        PS Еще я не учел случаи, когда выступающие приезжают с других городов за счет организаторов. А это туда-обратно плюс зачастую — отель — от 3 — 6 тысяч с человека до 20,000 — если тот — в Сибири.
                                          0
                                          Станислав, я был на Вашем семинаре в Питере. Все было честно. Была предложена услуга и ее стоимость — была получения услуга сопоставимая по стоимости.
                                          Теперь про .NEXT. Была предложена услуга и ее расширенный вариант. Расширенный вариант стоил на 700р дороже и отличался только обедом. Был куплен расширенный вариант. Итог за ту разницу в 700р был получен бизнес ужасного за свои деньги качества (на входе в бар стояла табличка, предлагавшая отведать их бизнес по 150р — есть подозрения, что это тот же бизнес, который мы если по 700). Во многом именно бизнес ланч, стоимостью 150, проданный за 700 (стоимость бизнеса накрытого а ля карт в ресторане), а кому-то и за 1000 оставил ощущение желания тупо заработать.
                                            –2
                                            Это всё очень классные рассуждения, безусловно. Дьявол в деталях: билеты без обеда стоили запредельно дёшево. Вы почему-то об этом не пишете.
                                              +2
                                              Это дьявол не должен касаться посетителей. Я понимаю, что дорогим обедом вы могли сделать билеты без обеда дешевыми. Фактически же получилось, что люди купившие дорогие билеты просто заплатили часть за тех, кто купил дешевые, не получив ничего взамен. Я, как потребитель услуги, считаю такую практику недопустимой. Я доплатил 700р за дополнительную услугу и получил ее ненадлежащего качества. Вот и весь результат, и я не хочу думать о том, что благодаря моему дорогому билеты другие получились дешевыми.
                                        0
                                        Нехило — билет в онлайн стоит столько же сколько и оффлайн лайт — 2500 руб.
                                        Ух ты, а обед оценивается в 2000 руб — это разница между фулл и лайт.
                                          0
                                          Мы с коллегой тоже не поняли, почему онлайн и личное посещение стоят одинаково. Обед — 2000р. Это зачем такой обед-то?
                                            +2
                                            Обед в гостинице стоит дофига денег — порядка 1500 рублей. Кроме того, с каждого билета мы платим комиссии платежной системе. И налоги, разумеется. Вот 2000 и набегает.

                                            Я не вижу смысла дальше обсуждать цену. Если Вы думаете, что можно сделать лучше и дешевле — расскажите потом, как Вам это удалось ;)

                                            0
                                            Всё так!
                                            +1
                                            Хотелось бы поменьше бла-бла докладов от MS евангелистов. Хватает и на MS конференциях. Даешь нормальные технические доклады.
                                              0
                                              Это кстати мысль. Учтём!

                                              Тренировкам и прогонам докладов майкрософтовцев уделим повышенное внимание!
                                                +1
                                                По-моему, это бесполезно. За последние лет пять, что слежу — те же люди, тот же стиль, та же глубина. Только темы разные. Задача их понятна — рассказать о новых технологиях, ярко и привлекательно. Но для этого есть другие конференции.
                                                Вообще, ориентируйтесь на ADD, которая, к сожалению, похоже почила в бозе. Очень качественное содержимое было.
                                                  0
                                                  Вторая и третья — да, неплохо, но не более. И видимо Вы последнюю ADD в Минске не видели :)
                                                    0
                                                    Да, последнюю не посещал.
                                                      0
                                                      Там были и технические ребята, но всё же слишком много бла-бла-бла было. Судите сами.
                                              +5
                                              Иными словами, закрытость CLR приводит к тому, что народ в дотнет-мире не очень привык лезть в дебри, а больше ориентирован на практические вещи

                                              А вы не думали, что причина в том, что все работает более-менее адекватно? Я слышал жалобы дотнетчиков на GC в Java, что он не адекватный и постоянно течет память по сравнению с .NET.

                                              В Java нету структур, поэтому напедалить вещи которые не будут испытывать потребности в сборщике мусора нереально.

                                              В Java нету нормальных genericов, поэтому даже коллекция примитивных типов — это коллекция Integer, а не int (т.е. reference type, а не value type), поэтому даже тут GC работает как угорелый, нет? В Java вообще нету нормальных genericов, обеспечивающих type safety. К примеру: http://ideone.com/HAPYjw

                                              В .NET сборки загруженные в память шарятся (благодаря GAC), в Java вроде бы нет. Поэтому если запустить одновременно две программы на .NET они будут кушать памяти меньше, чем суммарно они едят при запуске по отдельности. В Java при запуске двух программ одновременно они жрут столько памяти, сколько можно. Кроме того, GAC позволяет избавляться от кучи проблем с версионированием (типа NoSuchMethodError)

                                              Нет, я понимаю жалобы на недокументированность рантайма. К примеру, нельзя напедалить фичу самостоятельного удаления объектов).

                                              Я считаю, что хардкорные вещи прокатывают на Java конференциях потому что в Java все изначально криво. Отсутствие структур, кривой GC, кривое версионирование, неработающая проблемная политика non-breaking changes, отсутствие generics, отсутствие нормальной асинхронности, отсутствие автовывода типов, неудобный синтаксис языка. В стандартных либах Java вместо удобной работы с датами и временем какая-то фигня.
                                                0
                                                Плюсую! Вы, на самом деле, очень по делу написали. Некоторые вещи типа коллекций примитивных типов или аналогов структур сделаны как API в сторонних библиотеках. На уровне языка и виртуальной машины — да, нету. Сейчас обсуждается.

                                                Не согласен я с тем, что value type — это панацея. Если у джависта где-то «GC работает как угорелый», то он в этом месте убирает аллокацию избыточную, например, имитируя value type массивами.

                                                Что касается GC — всё окей у джавы. Я не очень понимаю, почему Вы так агрессивно на джавовые сборщики наезжаете. Посмотрите доклад Кирилла Скрыгана в посте — там memory traffic в полный рост. Сколько у дотнетовского рантайма ручек, управляющих сборкой мусора? Количество GC-потоков можно регулировать?
                                                  +4
                                                  так, кажется можно уже начинать затариваться попкорном.
                                                    +2
                                                    Не согласен я с тем, что value type — это панацея

                                                    Все перечисления (enums) в .NET — это value types, DateTime — struct, Timespan — struct Point — struct, Color — struct, KeyValuePair<,> — struct, Enumeratorы во многих случаях структуры. В .NETовской библиотеке очень много value types, это снижает оверхед на GC. Хотите чтобы переменным типа какой-то структуры можно было присвоить null? Есть Nullable<> (к примеру Nullable<int> или алиас — int?) — который тоже структура

                                                    Если у джависта где-то «GC работает как угорелый», то он в этом месте убирает аллокацию избыточную, например, имитируя value type массивами.

                                                    И получаем ерунду потому что мы не можем вызывать add() на массиве, нет? А если мы описываем сложную структуру из трех полей? Три массива держать? Ну блин, это же не вариант, это говнокод в полный рост. LINQ и ленивые коллекции есть? Они тоже снижают оверхед на тот же GC на обработке коллекций при грамотном использовании (и да, при грамотном использовании обычные коллекции лучше и быстрее, но говнокодистее, а потому неюзабельнее). Нет, фичи делающие возможностью адекватную реализацию LINQ появились только в Java 8. В результате адекватно обрабатывать коллекции можно только заводя промежуточные коллекции или пользуясь новомодными трансьюдерами.

                                                    Что касается GC — всё окей у джавы. Я не очень понимаю, почему Вы так агрессивно на джавовые сборщики наезжаете.

                                                    Извините, не могу подкрепить другими фактами, просто знаю, что на сам Java GC очень сильно ругаются. Мои основные аргументы — что GC в Java сильнее нагружается, чем в .NET (ну собственно говоря песнь про value types и разделение сборок между процессами).

                                                    Сколько у дотнетовского рантайма ручек, управляющих сборкой мусора? Количество GC-потоков можно регулировать?

                                                    У дотнетовского рантайма очень мало ручек по поводу сборщика мусора, да, всего лишь один класс GC и парочка елементов в xml-конфигурации (ну и класс GCSettings). Есть общая информация по поводу того как это все работает, парочка приколов по типу того, что сборщик мусора в Release режиме может собрать объект до завершения его конструктора. Ну и слабые ссылки для избавления от утечек памяти. Но мне реально увидеть проблемы с памятью довелось всего лишь пару раз когда в коде реально держались ссылки на ненужные объекты в root-объектах.

                                                    Посмотрите доклад Кирилла Скрыгана в посте — там memory traffic в полный рост

                                                    Я не спорю что есть случаи когда проблема с памятью и сборщиком мусора реально есть. Просто мне с такими вещами повезло практически не сталкиваться благодаря грамотно написаному коду, что своему, что стороннему.

                                                    По .NETовскому рантайму действительно очень мало документации — тут я согласен. Поэтому когда хочешь залезть в дебри реально сталкиваешься с вакуумом и нету понятия откуда начинать гуглить. По C# и IL документации более-менее достаточно, да и всегда можно посмотреть во что конкретно компилируется код. Ну так уж получилось, что большинству .NET-разработчиков достаточно тех ручек, которые есть. Я спихиваю это на то, что Java не очень-то хорошо продумана, но может быть дело и в разных задачах которые решаются на разных платформах.

                                                    Btw, я немного злюсь на фразы которые восхваляют программистов Java по сравнению с .NET. Началось все с книги Боба Мартина «Принципы, паттерны и методики гибкой разработки на языке C#», в которой он обосрал .NET-чиков, а потом написал кучу ерунды в книге. Так что я немного предвзят по отношению к Java.

                                                    Мне бы лично были бы более интересны доклады по пост-обработке скомпилированного кода (те же PostSharp и Fody), по автогенерации кода. Кстати, у тех же JetBrains есть очень клевый продукт — Metaprogramming System Language, который мне очень интересен.
                                                      +2
                                                      Супер! Много интересных мыслей — мне будет, что почитать в длинные выходные!

                                                      У меня внезапное предложение: а сами не хотите у нас выступить? И заодно в программный комитет?
                                                        0
                                                        Боюсь в этом году точно не получится, но в следующем был бы рад выступить.
                                                    0
                                                    del

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое