Search
Write a publication
Pull to refresh
0
0
Fedor Gogolev @knsd

User

Send message
Был в общем-то, у нас даже есть некоторые вещи на Окамле, но в те времена с Окамлом было не так хорошо как сейчас, OPAM ещё не был запущен, Real World Ocaml ещё даже не начали писать.
Ну например недавно появившаяся услуга «Мониторинг» подавляющей частью написана на Эрланге, некоторые инфраструктурные внутренние сервисы на Эрланге.
Нет-нет, очень активно используем. Единственный случай на моей памяти, когда выпиливали — это как раз половина «сервера API», о котором пишет amarao, мы тогда использовали Эрланг как веб-сервер и менеджер Хаскелль-бекендов, подключаемых через механизм портов Эрланга, но это оказалось не очень удобно и мы оставили здесь только Хаскелль.
Хотелось бы больше информации по поводу сложности сопровождения. Понятно, что каждый желающий в хаскель не залезет, но интересует скорость внедрения доработок по сравнению с питоном. Были ли ситуации, когда надо было делать жуткий рефакторинг?

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

Есть ли неудобства, связанные с отсутствием java-подобных (или хотя бы PyCharm'оподобных IDE)?

О есть, однако ходят слухи, что кто-то из сотрудников JB начал писать плагин для Х-ля. Ну ещё есть довольно продвинутый SublimeHaskell для Sublime Text и недавно FP Complete зарелизили web-IDE.
Такое может быть при использовании cabal-dev и параллельной разработки нескольких пакетов, один из которых зависит от другого. Речь не о сборке в продакшн, конечно, но при сборке для тестирования, например у нас возникали ситуации, когда зависимый пакет уже установлен в cabal-dev, удовлетворяет зависимостям (программисты ещё не бампнули версии), но интерфейсы уже изменены — ошибка компиляции.

Кстати, вероятно, с выходом Cabal 1.18, который поддерживает sandbox, такой проблемы уже нет. Но это случилось буквально над днях и мы ещё не успели перейти на него.
По поводу количества используемой памяти. Это c учетом использования строгих вычислений там, где это нужно (например), или вы пишите на Haskell, будто он строгий язык, и не паритесь?


Мы действительно в начале пару раз столкнулись с недостаточным пониманием ленивости, накопления санков и т.д. Но сейчас, конечно это уже не проблема, например у нас, как рекомендует Джона Тибел, поля структур по-умолчанию строгие.
Почему вы предпочли persistent-mongodb написание собственной библиотеки?

Мы используем persistent-mongodb, на самом деле речь идёт о библиотеке MongoDB, которая была когда-то написана Тенгеном, затем им же дропнута, и теперь мы продолжаем её поддерживать, persistent-mongodb использует её же. Если интересно, то пару дней назад начался процесс её переписывания — изначально библиотека была довольно низкого качества.
Не из-за Х-ля уменьшилась скорость разработки. amarao ближе к концу пишет, что «в контраргументы мне приведут изменившийся стиль программирования» — из этих изменений сильнее всего повлияло, что программисты примерно в это же время решили проводить более содержательные code review.
Активно используется в Селектеле, в том числе и в больших проектах.

Общие принципы на мой взгляд:
  • Используйте строгие структуры, например Control.Monad.State.Strict вместо Control.Monad.State.Lazy
  • Используйте deepseq
  • Используйте BangPatterns
  • Определяя свои типы, так же определяйте строгие поля, {-# UNPACK #-} сэкономит вам память, в GHC 7.8 можно будет распаковывать даже полиморфные поля
  • Используйте более производительные (в общем случае) контейнерные типы, например Data.Vector вместо Data.List, Data.HashMap.Strict вместо Data.Map, Text вместо String и ByteString когда вас интересует только массив байтов. String лучше не использовать в принципе


Если вы подозреваете утечки, их часто можно найти используя ghc-heap-view.
Насколько я знаю, мы никогда не использовали Yesod, в тех случаях, когда был нужен веб-сервер, использовался snap, например в качестве вебсокет-сервера для консолей, исользуется websockets-snap.

Что вы имеете ввиду? Субъективно cabal, cabal-install, cabal-dev кажутся мне наиболее удобной системой сборки из используемых.

В данный момент мы собираем пакеты deb/rpm для всех х-ль программ.
Подскажите, а есть способ указать тип переменной в rst?
всё бы мило, но смущает
«3. CONDITIONS: To be licensed to use Abbeyphone Extension, You must:
c) Allow Abbeynet S.p.a. to collect usage data for statistical analysis»
Вернее будет так, 2-5, на несколько ресурсов(хорошо бы немало ^^), а уж куда те 2-5 пойдут меня не очень волнует.
Да, исключительно владельцу, именно 2-5, без посредников, которые берут процент.Но только, если будет удобная система оплаты, например вебмани не очень удобная, хотя сойдёт, идеальный вариант — терминал, что-нибудь типа уникассы, они, фактически с меня процент не берут, только фиксированную сумму с тебя. Хотя, конечно, народ будет и смс-сервисам платить половину.
Но ресурс при этом должен не иметь аналогов, иначе, конечно, не буду ничего платить, а пойду на халявный, или более дешёвый.
Дa ^^.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity