*предсказуем

*непредсказуем

java же есть инкрементальные

даже в го будет

да, у ГЦ есть недостатки, но на удобство ФП они плохо не влияют

Я ненастоящий сварщик, лишь транслирую мифы

да, у ГЦ есть недостатки, но на удобство ФП они плохо не влияют

GC? Garbage Collector?

Плюсовики на это скажут, что GC непрелсказуем и делает Stop the World (по крайней мере в Java)

только для явы и есть конкурентный сборщик пригодный для продакшона. (не в оракловой имплементации, там псевдоконкурентный)

Вот, кстати, и вопрос в целях повышения образованности: а Haskell какой GC?

stop the world

даже в nursery

с поколениями

точный

Понятненько

immutability aware

у пушера к этому претензии

но из пушера уже и гошники бежать начинают

хаскелисты убежали при переходе на го

но из пушера уже и гошники бежать начинают

вот это новость

О чем речь, что есть "пушер"?

ну может не все, но некоторые уже ищут куда бы свалить

Токсичен?

пушер - сервис доставки сообщений, известен тем что перешёл с хаскель на го из-за гц

но судя по словам людей оттуда ушедших они профессионалы отстреливается себе ноги

https://pusher.com/

Спасибо. Приятно, что можно не гуглить, особенно на ходу

пушер - сервис доставки сообщений, известен тем что перешёл с хаскель на го из-за гц

А можно поподробнее? Чем гошный гц лучше хаскельного?

под low latency оптимизирован

Пишут, что любят девелоперов: "We <3 developers"

А можно поподробнее? Чем гошный гц лучше хаскельного?

лопата, вентилятор

особенно если хип по какой-то причине не разрастается

в Haskell под high throughput

типа мы быстрее собираем, но в среднем пауза больше, но пауз меньше

под low latency оптимизирован

У хаскеля разве не инкрементальный гц?

к сожалению нет

ветка с инкрементальным замержена в мастер не была

profit doesn't worth the cost

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

https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/

в современном мире было бы интересно померять снова

Т.е. на больших объемах хипа остановки тоже дольше?

да

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

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

Я просто слышал (очень поверхностно) что гошный гц хорошо работает только в очень небольшом количестве кейсов - вроде какие то проблпмы с рекордами там были

https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/

Выглядит так, что ребята захотели hard realtime от Haskell

ну не то что хард, но они хотели минимизировать лэтенси

в хаскелле тоже все можно сделать, но нужно сверх аккуратным быть

Любопытно. Если брать мутабельные массивы и использовать те же техники, что и в плюсах для минимизации memory traffic - сработает?

ветка с инкрементальным замержена в мастер не была

тот, что не замерджен все-таки не конкурентный, и решал он проблемы не с паузами а с потоковой производительностью на большом числе ядер

были две работы по псевдоконкурентному, но они не доходили до такой стадии готовности

еще какой-то интерн начинал иммикс писать, там не было особого продвижения вроде

Любопытно. Если брать мутабельные массивы и использовать те же техники, что и в плюсах для минимизации memory traffic - сработает?

там не трафик надо минимизировать, а размер долгоживущих в гц-ной (и не компакт) куче

короче мне говорили что стек особо не кеширует. Я в своём проекте указал зависимости на 5 проектов в extra-deps, на гитовые комиты в гитхабе и он их собрал 1 раз. далее в консоли не было видно их пересборки и по времени тоже не чувствовалось. В чём подвох? где стек всё таки не кеширует?

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

короче мне говорили что стек особо не кеширует. Я в своём проекте указал зависимости на 5 проектов в extra-deps, на гитовые комиты в гитхабе и он их собрал 1 раз. далее в консоли не было видно их пересборки и по времени тоже не чувствовалось. В чём подвох? где стек всё таки не кеширует?

видимо, в том смысле, что эти зависимости у вас в .stack-work лежат, а не в ~/.stack

короче мне говорили что стек особо не кеширует. Я в своём проекте указал зависимости на 5 проектов в extra-deps, на гитовые комиты в гитхабе и он их собрал 1 раз. далее в консоли не было видно их пересборки и по времени тоже не чувствовалось. В чём подвох? где стек всё таки не кеширует?

вроде сборку с разными флагами не кеширует.

вроде сборку с разными флагами не кеширует.

если флаги меняются, тупо пересобирает, да

видимо, в том смысле, что эти зависимости у вас в .stack-work лежат, а не в ~/.stack

а типа глобально ставить это реальный кейз?

вроде сборку с разными флагами не кеширует.

аа мб. ну у меня там совсем не было флагов, это ж либы

--enable-profiling какой захочется если?

а типа глобально ставить это реальный кейз?

не думаю

хотя у меня весь снапшот пересобирало, когда я --trace включил

а потом пересобирало обратно ?

короче да мб. в этом что-то есть. но в общем стека достаточно для большинства случаев. остаётся необходимость в никсе только для не-хаскельных зависимостей

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

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

Сноймана здесь не любят?

не все

Сноймана здесь не любят?

как и везде, тут есть разные люди

короче да мб. в этом что-то есть. но в общем стека достаточно для большинства случаев. остаётся необходимость в никсе только для не-хаскельных зависимостей

ещё .stack-work пересобирается при каких-то изменениях stack.yaml насколько я понимаю

просто тупо переключаю ветку и давай пересобирать пару десятков зависимостей

насколько оправданные пересборки были точно не выяснял

а можно в стеке что-нибудь где-нибудь включить чтоб стек сразу собирал с базами для хугла, а не пересобирал все при первом его (хугла) использовании?

вроде как и с профилированием

никак, но это не точно, Sloan домой долетит, я у него спрошу

@qnikst он тоже чтоль теперь у вас работает? Предал сноймана?

нет он от fpcomplete работает на того же клиента

чего-то я не понял

почему -with-opts не срабатывает

@qnikst ты там грозился посмотреть как можно рантайм проверить на выставленные параметры

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

почему -with-opts не срабатывает

у меня был случай, когда -with-rtsopts не работал

но я не поню точно при каких обстоятельствах

у меня такой же, походу

я на глаз вижу что ведет себя по другому, если я в +RTS все запихиваю

Есть ещё переменная среды для опций

Может выставил кто в shellHook

грепнул, нету

вообще походу nix где-то их теряет

> вообще походу nix где-то теряет исправил )

никс теряет ртс опции?

у меня похожая проблема была со стеком без никса

это была толстая шутка про то что никс в принципе теряет. прошу прощеня если задел чьи-то чувства

Так а чо было то?

не знаю, мне не удалось решить эту проблему

а с никсом чо было?

,c with-rts-opts нужно правильно кавычки делать

с кавычками кабал не жрет

а ты что кавычками закрываешь? только опции? тогда и шелл не жрёт