Программерское
Около 12 лет мне потребовалось, чтобы окончательно упарить OCaml-ом всех на работе.
Ибо курс там взяли на jvm-язычки (clojure,scala,java), у которых туго с отдачей памяти обратно в
систему - для ситуации когда много серверов - на одно jvm-приложение - это не критично, но
в нашем случае могло быть и 20-30 jvm на одном серваке - налицо архитектурная неаккуратность.
У ЯП OCaml есть всего две проблемы, влияющие на производительность - наличие однопоточного
сборщика мусора и отсутвтие unboxed-типов данных. Но зато при рантайме в 5Mb - весьма приятный
fork - с которым проблем не возникает, если использовать в паре с асинхронным вводом/выводом.
Что там с параллельным сборщиком мусора - я так и не понял - то ли пока не сделали, то ли
сходу не получилось из-за последующих проблем с производительностью (при его включении).
В общем за более чем 12 лет я не нашел ни одной проблемы в компиляторе OCaml-а (хотя поискать
порой хотелось). Самое пожалуй неочевидное для новичка - это применение мутабельных строк и
массиовов по-умолчанию (можно организовать побочный эффект).
Последний год активно исследовал вопрос производительности приложений, написанных на различных
ЯП и пришел к очевидному выводу - что пора "тряхнуть стариной", это как со старыми ружьями - которые
из-за меньшего максимального давления в канале ствола - выглядят заметно легче и элегатнее
современных образцов. То бишь думаю повнимательнее посмотреть на программирование на голом C,
на крайняк C++ - речь тут конечно о задачах (где важна скорость и минимальное потребление
ресурсов оперативной памяти), а для обеспечения надеждности - есть достаточный запас ресурсов.
В общем принцип - чем ближе к железу - тем меньше ограничений. Соотвественно для меня
нормальным подходом всегда было и будет - достаточно низкоуровневое производительное ядро,
которое уже скриптуется поверх динамическими встроенными языками - либо ядро оформляется
как либа и используется в приложении на более высокоуровневом ЯП.
Сейчас, в течении какого-то времени буду отдыхать и смотреть вакансии по двум
направлениям - либо управление шайкой диких программеров, либо какая-нибудь новенькая
(хорошо забытая) для меня специализация (например С/C++). В общем, можно и ещё что-нибудь
рассмотреть, если дело стоящее так сказать. Про Haskell, Erlang я и не мечтаю - но если
вдруг, то почему бы и нет. Erlang - поприятнее java-технологий мне показался.
А Haskell - у меня ещё впереди (может когда-нибудь дорасту).
Ибо курс там взяли на jvm-язычки (clojure,scala,java), у которых туго с отдачей памяти обратно в
систему - для ситуации когда много серверов - на одно jvm-приложение - это не критично, но
в нашем случае могло быть и 20-30 jvm на одном серваке - налицо архитектурная неаккуратность.
У ЯП OCaml есть всего две проблемы, влияющие на производительность - наличие однопоточного
сборщика мусора и отсутвтие unboxed-типов данных. Но зато при рантайме в 5Mb - весьма приятный
fork - с которым проблем не возникает, если использовать в паре с асинхронным вводом/выводом.
Что там с параллельным сборщиком мусора - я так и не понял - то ли пока не сделали, то ли
сходу не получилось из-за последующих проблем с производительностью (при его включении).
В общем за более чем 12 лет я не нашел ни одной проблемы в компиляторе OCaml-а (хотя поискать
порой хотелось). Самое пожалуй неочевидное для новичка - это применение мутабельных строк и
массиовов по-умолчанию (можно организовать побочный эффект).
Последний год активно исследовал вопрос производительности приложений, написанных на различных
ЯП и пришел к очевидному выводу - что пора "тряхнуть стариной", это как со старыми ружьями - которые
из-за меньшего максимального давления в канале ствола - выглядят заметно легче и элегатнее
современных образцов. То бишь думаю повнимательнее посмотреть на программирование на голом C,
на крайняк C++ - речь тут конечно о задачах (где важна скорость и минимальное потребление
ресурсов оперативной памяти), а для обеспечения надеждности - есть достаточный запас ресурсов.
В общем принцип - чем ближе к железу - тем меньше ограничений. Соотвественно для меня
нормальным подходом всегда было и будет - достаточно низкоуровневое производительное ядро,
которое уже скриптуется поверх динамическими встроенными языками - либо ядро оформляется
как либа и используется в приложении на более высокоуровневом ЯП.
Сейчас, в течении какого-то времени буду отдыхать и смотреть вакансии по двум
направлениям - либо управление шайкой диких программеров, либо какая-нибудь новенькая
(хорошо забытая) для меня специализация (например С/C++). В общем, можно и ещё что-нибудь
рассмотреть, если дело стоящее так сказать. Про Haskell, Erlang я и не мечтаю - но если
вдруг, то почему бы и нет. Erlang - поприятнее java-технологий мне показался.
А Haskell - у меня ещё впереди (может когда-нибудь дорасту).