но я даже если у них будут хорошие свойства я не знаю почему я должен предпочесть их решению от @chshersh

у них кавайная организация, и даже если сингапур снесёт землетрясением, то наверное будут поддерживать пакеты

но я даже если у них будут хорошие свойства я не знаю почему я должен предпочесть их решению от @chshersh

это ты про typerep-map?

да

я конечно видел еще http://hackage.haskell.org/package/dependent-map-0.2.4.0/docs/Data-Dependent-Map.html http://hackage.haskell.org/package/dependent-sum-0.4/docs/Data-Dependent-Sum.html

там бойлерплейта много

вроде

я где-то использовал в игрушечных вещах

а это? http://hackage.haskell.org/package/type-level-sets

но я даже если у них будут хорошие свойства я не знаю почему я должен предпочесть их решению от @chshersh

Формально говоря, именно typerep-map написал не я, а @vrom911

а разве vrom911 не в вашей огранизации и её тоже не убьет землетрясением, которое уничтожит сингапур?

а чорт, да я там сослаться что решение твое, ок

я думал, я корректнее написал, поправка принята

у них кавайная организация, и даже если сингапур снесёт землетрясением, то наверное будут поддерживать пакеты

Спасибо за приятный отзыв ^_^ Если возникнут какие-то issue с библиотеками, то с радостью поможем! ? Всегда можно открыть issue и обсудить! Я вот typerep-map как раз использую для введений клевой штуки в новой библиотеке (скоро еще один блог пост будет). Всегда приятно, когда свои же библиотеки нужны себе же ?

Спасибо за приятный отзыв ^_^ Если возникнут какие-то issue с библиотеками, то с радостью поможем! ? Всегда можно открыть issue и обсудить! Я вот typerep-map как раз использую для введений клевой штуки в новой библиотеке (скоро еще один блог пост будет). Всегда приятно, когда свои же библиотеки нужны себе же ?

напомни ваш блог

я конечно видел еще http://hackage.haskell.org/package/dependent-map-0.2.4.0/docs/Data-Dependent-Map.html http://hackage.haskell.org/package/dependent-sum-0.4/docs/Data-Dependent-Sum.html

Стать лучше dendent-map было одной из мотивацией для создания typerep-map. dependent-map по сути является копипастой кода библиотеки containers, только сам тип изменен, чтобы поддержать индексирование по типам. Согласно бенчмаркам, typerep-map в 3-4 раза быстрей dependent-map на поиске. Но поскольку реализована на массиве, то вставка медленней. Хорошо подходит, когда поисков намного больше, чем вставок) Оказалось, что таких юзкейсов не так уж мало.

прикольно что у вас есть время на опенсорс прилично

напомни ваш блог

Пожалуйста ? * https://kowainik.github.io/posts

вообще для меня typerep-map скорее похожа на typemap снойманову или что там в vault, только а. с безопасным интерфейсом б. тип это ключ в. быстрее на моих кейсах

у меня были похожие штуки, но я а. не выделял это в пакет, б. или не безопасные или с именами, а не по типам

а тут все за меня сделано

прикольно что у вас есть время на опенсорс прилично

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

@qnikst, это телеграм чатик, а не твиттер, напиши то, что ты думаешь про хаскель и db

я ж писал

[количество цензарной ругани превысило размер сообщения]

у нас нету ни одной приличной low level либы работающей с pg

все работает поверх libpg

ты смотришь графики rps, и видишь проседание на 20% при тупых запросах мелких

у тебя большие и ты ловишь RTS на вечном spin lock где оно проводит 80% cpu времени на threaded RTS

ибо GC

приличной либы опубликованной на hackage

все работает поверх libpg

тебе нужен прябой байндинг к libpq?

МНЕ НЕ НУЖЕН libpq

вот postgres-wire то что мне нужно

мне нужна нативная либа общающаяся с pg напрямую

а разве с Посгресом можно общаться мимо libpq? я не в курсе

ну сокет у него есть, куда коннект идет значит можно

в go например нативный драйвер

у Никиты libpq но бинарный протокол его

т.е. все те же проблемы остаются

я всегда думал, что libpq — это самый нативный способ. то есть ниже идёт только внутренный протокол, совместимость которого никто не гарантирует

Потому что в Go линковать внешее не любят

вон у Дениса, пришлось на RTS=-N1 переходить

Потому что в Go линковать внешее не любят

не умеют

ибо тормозило

Кмк, поддерживать свою версию либы для постгри, это тяжко

лучше иметь говно, которое убивает производительность на 20-99%?

или переписать pg-simple (что не факт, что в принципе возможно)

там свой шедулер, конкурирующий с нашим RTS?

я думаю там выделение памяти попадающее в largeobjects или как-то на одну капабилитю

в итоге параллельная сборка мусора деградирует до того, что только 1 тред работает

а остальные на спинлоке

т.е. в бизилупе

так что работает все, а работу делает только 1

в общем по мне так нативный драйвер (написанный в основном), это лучше чем воевать с pg-simple

тем более, что в других языках (более чем одном) этим путем пошли достаточно успешно

тем более, что в других языках (более чем одном) этим путем пошли достаточно успешно

Насколько сложно будет реализовать такой драйвер на Haskell? Например, человеку, который не писал драйверы для БД никогда, но знает сносно Haskell? Достаточно ли реализовать только протокол (и вообще, где этот протокол-то описан) или нужно применить мозг, чтобы аккуратно подумать о перформансе и многопоточности?

уже реализован

но он есть

https://github.com/postgres-haskell/postgres-wire

но он есть

То есть уже можно тащить в продакшн вместо postgresql-simple смело, например?

но там нужно: 1. привязки к библиотекам persistent, opaleye, hasql, чтобы можно было взять и заменить и посмотреть что с твоим проектом 2. документация / туториалы (?) 3. утилиты (?) типа как в pgsimple есть много дополнительных фич

нет

ERROR: S client not available

т.е. нужна ещё работа поверх

как сказал @VividDesires сделать совместимый интерфейс с pg-simple тяжело, но вот заставить более высокие либы работать поверх pg-wire можно

вообще было желание сделать хакатон по всему этому, но не факт, что взлетит

как сказал @VividDesires сделать совместимый интерфейс с pg-simple тяжело, но вот заставить более высокие либы работать поверх pg-wire можно

Подтверждаю, pg simple заточен под текстовый синхронный драйвер

А это асинхронный с бинарным форматом

В теории можно переключить на текстовый и засинхронить, но у коллеги возникли дополнительные проблемы с этим год назад

Собственно он подавляющую часть кода написал

@VividDesires вообще если ты сможешь скординировать как-то effort то можно начать (у меня правда ничерта времени на opensource пока нет)

Как минимум я сам начну

вон у ребят вроде есть целые полдня*человек на opensource

У нас пока еще не все свои идеи кончились для своих проектов, чтобы еще БД заниматься) Мы пока на проде используем postgresql-simple и это все равно бекенд работает в целом намного быстрей чем прошлый, написанный на Node.js И так не для всего есть библиотеки, что приходится самим писать, поэтому еще и postgresql тащить нет сил... Могу разве что так сделать! * https://github.com/morphismtech/squeal/issues/63

вон у ребят вроде есть целые полдня*человек на opensource

эт у кого?

Это будет считаться за рекламу компании, хех

У нас пока еще не все свои идеи кончились для своих проектов, чтобы еще БД заниматься) Мы пока на проде используем postgresql-simple и это все равно бекенд работает в целом намного быстрей чем прошлый, написанный на Node.js И так не для всего есть библиотеки, что приходится самим писать, поэтому еще и postgresql тащить нет сил... Могу разве что так сделать! * https://github.com/morphismtech/squeal/issues/63

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

а у меня где встречалось решение сделать 1 капабилитю было ок

а в другом и сможет выдержать нормально нагрузку раз в 10 выше текущей

у нас нету ни одной приличной low level либы работающей с pg

У вас и по качеству кода нет ни одного хорошего драйвера. Помню как-то ради интереса выбрал одну реализацию, чтобы посмотреть как промышленный код на хаскелл выглядит. А там сплошной liftM5/liftA5. Выглядело так себе, крякнул и закрыл

У вас и по качеству кода нет ни одного хорошего драйвера. Помню как-то ради интереса выбрал одну реализацию, чтобы посмотреть как промышленный код на хаскелл выглядит. А там сплошной liftM5/liftA5. Выглядело так себе, крякнул и закрыл

А в чём проблема с liftM5/liftA5? Ну, кроме функций принимающих 5 аргументов.

А в чём проблема с liftM5/liftA5? Ну, кроме функций принимающих 5 аргументов.

У меня с непривычки глаз задергался. И это я еще тогда не знал о монад трансформерах.

У вас и по качеству кода нет ни одного хорошего драйвера. Помню как-то ради интереса выбрал одну реализацию, чтобы посмотреть как промышленный код на хаскелл выглядит. А там сплошной liftM5/liftA5. Выглядело так себе, крякнул и закрыл

Код мог писаться ещё в те времена, когда аппликатив не был распространён

Я как-то раз открыл код проекта на языке X, не понял его, и решил, что на языке X не бывает хорошего кода

Я ковырялся в либах 2002ого и они норм были написаны

Я как-то раз открыл код проекта на языке X, не понял его, и решил, что на языке X не бывает хорошего кода

Я про драйверы pg писал. Если что. Посмотрел и другие варианты

Я как-то раз открыл код проекта на языке X, не понял его, и решил, что на языке X не бывает хорошего кода

так делают жсеры, потом говорят, что хаскель страшный и не практичный

У вас и по качеству кода нет ни одного хорошего драйвера. Помню как-то ради интереса выбрал одну реализацию, чтобы посмотреть как промышленный код на хаскелл выглядит. А там сплошной liftM5/liftA5. Выглядело так себе, крякнул и закрыл

отстань

У вас и по качеству кода нет ни одного хорошего драйвера. Помню как-то ради интереса выбрал одну реализацию, чтобы посмотреть как промышленный код на хаскелл выглядит. А там сплошной liftM5/liftA5. Выглядело так себе, крякнул и закрыл

и на чем же ты пишешь родной?

кислота пошла

и на чем же ты пишешь родной?

На чем потребуется. Сейчас бы спрашивать на чем, вместо "что".

На чем потребуется. Сейчас бы спрашивать на чем, вместо "что".

достойный ответ, впрочем ничего нового

На чем потребуется. Сейчас бы спрашивать на чем, вместо "что".

ортогональные вещи

На чем потребуется. Сейчас бы спрашивать на чем, вместо "что".

важно именно "на чём"