EPFL Швейцария.
Но я считаю что бакалавриат должен давать общие знания. В этом лучше подходит МФТИ.
Да и если есть хорошая база от вуза то можно пойти в Школу Анализа Данных Яндекса.
Все советы по своему опыту.
Хоть Евгений, а также несколько позже, Наталья Байкевич занимались квазицитатами на заре Scala макросов зимой-весной 2012 года, основным разработчиком скаловских кц является Денис Шабалин, который осенью 2012 года возродил этот на время отложенный проект и довел его до продакшена в составе Скалы 2.11. Привет от Евгения, у которого нет аккаунта на хабре :)
Квазицитаты есть и в Scala 2.10, для этого см docs.scala-lang.org/overviews/macros/paradise.html
Также стоит заметить что квазицитаты и макросы для Scala делают наши соотечественники которые к тому же активно сидят на stackoverflow, оперативно отвечая на вопросы.
Для тех, кого интересует будущее метапрограммирования на Scala советую посмотреть будущий доклад Евгения Бурмако на scaladays.org/
Да. Но mutlifield. И механизм добавления методов другой(у Scala — тут работает стандартный механизм implicit декораторов).
Однако Dotty с интересом наблюдает за тем, что будет в JVM.
У меня язык не поворачивается сказать, что это тоже язык(хотя я и scala 2.6 не назвал бы scala 2.11, разные они), когда за ним другая теория типов, другие возможности и ограничения.
Большинство кода, который был написан для Scala 2.11 будет валидным Dotty кодом. Но — если вы используете «черные стороны Scala» (например структурные типы или early definition) — Dotty намеренно этого лишена.
Также будет небольшое количество отличий логики (в частности lazy vals по умолчанию не treadsafe а volatile lazy val намного быстрее чем в scala и намного более deadlock-proof), для решения большинства которых пишется migration tool.
Лично общался с разработчиком .net frontend-а.
Если коротко — в тот момент dotNet был очень сырой(32 и 64 версии вели себя очень различно, даже баги были местами разные), плохо шел на контакт, да и интереса большого он похоже не вызвал.
Человек, который над этим работал сейчас уже покинул команду, и работает над внутренностями будущих JVM
Я как раз бы сказал, что сильная сторона Scala в том, что многие «фичи языка» на самом деле библиотеки. Просто они идут в поставке с компилятором, но сила в том что не мешает сделать свои новые.
Многие из проблем описанных вами (особые сложности в системе типов, быстрая компиляция, итд) должен решить новый компилятор(правда для чуть-чуть другого языка) github.com/lampepfl/dotty
Сейчас искать лень, но суть такая: некоторые флаги, которые сделали «по умолчанию» в java7 оказались с багами(для JIT), но редко проявляющимися. Некая специфика Lucene сделала так, что 3 бага JIT на нем красиво заставляли JVM падать.
Крики-криками, но исправлено это было достаточно быстро, в 7u1 www.oracle.com/technetwork/java/javase/7u1-relnotes-507962.html
Позже стало ясно что и в 1.6 были те баги, но так как флаги не были включены по умолчанию, то проблему не обнаруживали.
Разрабатываю Scala(коллекции, новые lazy vals и tailrec в компиляторе), мои изменения уйдут в стабильную ветку ИМХО не ранее чем через год, потому:
Использую для разработки java8, проверяю поведение под java7 и Graal.
Похожий пример досконально разобран в «What Every Programmer Should Know About Memory» by Ulrich Drepper.
Теперь намного раньше кончаются все кэши — L1D, L2, L3. Также не стоит забывать про Translation Look-Aside Buffer(TLB).
Добавлю интересный артефакт — подобный тест может быть своеобразным бенчмарком TLB внутри виртуальной машины, так как она там более многоуровневая.
Или я не понимаю Ваш вывод, или в вашем примере +12% скорости.
Вы также не указали количество потоков используемое и какое железо.
Я убежден что при использовании сильно-параллельной архитектуры, с большим количеством сокетов(и толстым Interconnect-ом), те например 4-восмиядерхых Xeon-а разница будет более чем ощутима.
Ваш SafeIdBasedLockManager.obtainLock все еще synchronized. Советую посмотреть в сторону Ctrie, которая позволит решить туже задачу намного эффективней.
Советую Швейцарию. Цены высокие но зп соответствующая. Законодательство адекватное(торренты качать можно но раздавать нельзя). Адекватная экономика и поддержка предпринимательства.
На последней встрече с Java -командой, инициированной ими, вообще разговор не завязался. Они с трудом понимали что за задачи они хотят мне предложить, и не могли ответить на простые вопросы по постановке задачи.
Через час бессмысленного разговора прервала присутствовавшая на нем HR, и сообщила размер компенсации. Был крайне удивлен суммой в 2.5 раза меньшей чем моя зарплата на тот момент. При том что на HH была ясна указана сумма, с которой я начинаю рассматривать предложения.
Но я считаю что бакалавриат должен давать общие знания. В этом лучше подходит МФТИ.
Да и если есть хорошая база от вуза то можно пойти в Школу Анализа Данных Яндекса.
Все советы по своему опыту.
На фоне затрат на жизнь почти незаметно.
Также стоит заметить что квазицитаты и макросы для Scala делают наши соотечественники которые к тому же активно сидят на stackoverflow, оперативно отвечая на вопросы.
Для тех, кого интересует будущее метапрограммирования на Scala советую посмотреть будущий доклад Евгения Бурмако на scaladays.org/
Однако Dotty с интересом наблюдает за тем, что будет в JVM.
Заодно это касается Universal Traits в Scala docs.scala-lang.org/overviews/core/value-classes.html
Первая сотня игр куплены в РФ, потом переехал в Швейцарию. Все цены сейчас в евро, никогда с support-ом не общался.
docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html
Оригинальная идея авторства Alexander Prokopec.
Я ее «перенял», чуть подкрутил, подтюнил, и реализовал. Потом было обсуждение тут
groups.google.com/d/msg/scala-internals/4sjw8pcKysg/GlXYDDzCgI0J
Подробное описание будет, когда Dotty будет «хоть в каком то смысле стабильна». Сейчас может все еще поменяться.
Большинство кода, который был написан для Scala 2.11 будет валидным Dotty кодом. Но — если вы используете «черные стороны Scala» (например структурные типы или early definition) — Dotty намеренно этого лишена.
Также будет небольшое количество отличий логики (в частности lazy vals по умолчанию не treadsafe а volatile lazy val намного быстрее чем в scala и намного более deadlock-proof), для решения большинства которых пишется migration tool.
Если коротко — в тот момент dotNet был очень сырой(32 и 64 версии вели себя очень различно, даже баги были местами разные), плохо шел на контакт, да и интереса большого он похоже не вызвал.
Человек, который над этим работал сейчас уже покинул команду, и работает над внутренностями будущих JVM
Многие из проблем описанных вами (особые сложности в системе типов, быстрая компиляция, итд) должен решить новый компилятор(правда для чуть-чуть другого языка) github.com/lampepfl/dotty
Например вот этот bugs.java.com/bugdatabase/view_bug.do?bug_id=7044738. Проблемы наблюдались и на x86 под Linux.
Крики-криками, но исправлено это было достаточно быстро, в 7u1 www.oracle.com/technetwork/java/javase/7u1-relnotes-507962.html
Позже стало ясно что и в 1.6 были те баги, но так как флаги не были включены по умолчанию, то проблему не обнаруживали.
Использую для разработки java8, проверяю поведение под java7 и Graal.
Теперь намного раньше кончаются все кэши — L1D, L2, L3. Также не стоит забывать про Translation Look-Aside Buffer(TLB).
Добавлю интересный артефакт — подобный тест может быть своеобразным бенчмарком TLB внутри виртуальной машины, так как она там более многоуровневая.
Вы также не указали количество потоков используемое и какое железо.
Я убежден что при использовании сильно-параллельной архитектуры, с большим количеством сокетов(и толстым Interconnect-ом), те например 4-восмиядерхых Xeon-а разница будет более чем ощутима.
И мне тут настолько хорошо что я сделал документ на тему этого, чтоб помочь хорошим людям из пост-СССР сюда попасть.
goo.gl/DcW3x8
Через час бессмысленного разговора прервала присутствовавшая на нем HR, и сообщила размер компенсации. Был крайне удивлен суммой в 2.5 раза меньшей чем моя зарплата на тот момент. При том что на HH была ясна указана сумма, с которой я начинаю рассматривать предложения.