Comments 28
Про джавовый HotSpot и другие интересные вещи, которые возможны только в рантайме, уже можно рассказывать?
В рантайме можно спекулятивные оптимизации на основе статистики использования, которые нельзя в compile time.
Вот тут есть довольно общий список: https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
А вот тут пара слов про Profile: https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
Если не углубляться совсем в дебри, то на основе статистики поведения метода в runtime, виртуальная машина может его не только скомпилировать в машинный код, но и например, выкинуть какие-нибудь проверки аргументов, ветки условий, итд.
Более того, эти оптимизации занимают некоторое время, и требуют определенного способа использования приложения. Поэтому иногда для того, чтобы свежезапущенное приложение было молодцом с самого начала, в него профиль оптимизации можно загрузить. Вот так никогда не делал, но на хабре где-то не так давно была статья по этому поводу.
Строго говоря, в некоторые компилируемые языки уже некоторое время назад вкрутили PGO. Например, у gcc есть набор флагов для сборки приложения для сборки профиля и набор флагов для компиляции с учётом собранной статистики.
Конечно, это не настолько гибко, как сборка в рантайме и deopt и повторный opt при изменении нагрузки.
Ведь все проблемы программистов от скриптовых языков) И от дженериков.
И есть несколько инженеров, которые пишут на Rust и не знают проблемы с гонкой данных.
Было бы интересно узнать какие главные сложности у инженеров Dropbox при работе с языком Rust, если его используют совсем немного.
Не не везде с гонками все так плохо, есть Кложур, к примеру — там транзакционная память и иммутабельность. Хотя синтаксис подкачал, читать его — это специальный скилл, я до сих пор не освоил. Вот бы кложур, но со статической типизацией и пайтоновским синтаксисом...
Пайтоновский синтаксис — это баланс, при котором код читабелен, может иметь статическую типизацию и при этом все еще можно писать настоящие лисповые макросы (и при этом не вывихивать мозг как в скале и без больших ограничений как в расте).
Более сложный синтаксис не всунуть, там есть два ограничения — 1) весь синтаксис должен быть разобран ДО поступления в макрос 2) парсер не должен знать структуры программы, так как макрос может сгенерировать любую программу.
Лисп — самый простой способ сделать парсер максимально тупым, парсер на основе отступов — следующий уровень, а если исхитриться то можно и операторы в парсер засунуть. Я как-то интерпретатор писал такого добра, на уровне хобби.
Эта статья — перевод статьи Tammy Butow? Или вольное мыслеизяснение после прочтения статьи\статей Tammy Butow?
Так почему Dropbox использует Go? В чем профит, ведь до Go Dropbox использовал что-то другое, или нет?
Странная статья…
Мне очень нравится Go, но охота больше видеть примеры конкретных применений, архитектурные решения и т.п., а не «Мы пишем на языке Х потому-что нам нравится на нем писать»…
Информации на самом деле много, но увольте в случае расхождения громкого оглавления статьи с содержанием
Подожду на первоисточник сабжа.
Вот больше про выбор Go в dropbox https://www.youtube.com/watch?v=EWsXbsUBm-M
При этом метания у них начались именно с момента выхода Python 3. Врятли он им так сильно мешал, но похоже это заставило их задуматься над выбором языка. Помнится я видел последовательно два или три видео, где они говорят, что переходят, то на Go, то на JVM (не помню какой язык), то клянутся в любви к Python.
Врядли Pyston будет дальше развиваться.
Ну а как же матра питонистов, что те немногие узкие места надо переписывать на C? Вроде действенный подход. Да, все равно останется беда с математической многопоточностью (GIL и вот это вот все), но в целом то язык неплох.
Я думаю дело не в технических характеристиках, а в политике: просто появилось много людей желающих попробовать что-то новое. А дальше одно за другое: "Вы слышали, вот те ребята с 15го этажа переписали приложуху X на go и получили прирост в стопицот! Давайте и мы тоже так сделаем!"
Ну а как же матра питонистов, что те немногие узкие места надо переписывать на C?Так оно, но в dropbox очень много io, а го для этого самое то, в итоге они начали переписывать узкие места не на C, а на go, что выглядит разумно.
Надёжность Go в инфраструктуре Dropbox