потому что линейные типы в хаскель уже впиливают afaik
а hkt в расте мы видимо так и не дождёмся :с
доня.
Loo
а hkt в расте мы видимо так и не дождёмся :с
сидишь такой на работе и мечтаешь КОГДА ЖЕ ТАМ ХКТ ВПИЛЯТ
Alexander
пилят, но пока в master не идет
Loo
https://intellij-rust.github.io/2018/02/13/changelog-67.html
Alexander
через несколько релизов есть шанс наверное
Антон
Каждый игречный язык умеет в ФП
Антон
Игрушечное
Alexander
но шансов на линейные типы в хаскеле больше, чем на HKT в расте
Антон
Потому что HKT нет
A64m
@qnikst же вроде говорил что пилят, не?
1) да, есть экспериментальная имплементация
2) в языке с исключениями поведение вроде растового воспроизвести все равно сложно
3) пропозал по этому расширению пока не прошел
Alexander
А как линейные типы сочетаются с ленивой семантикой?
с ленивой норм, а вот с исключениями - не очень
Антон
Alexander
да, растовые "исключения" и кодогенерация делает все проще
Alexander
паника не ловится
A64m
проблема не в кидании а в перехватывании
Bogdan
пока существуют книги про фп и жс в этом мире все возможно
Alexander
это несколько другое, впрочем в расте можно и ловить "исключения" или как они там зовутся
Alexander
не все ловится
Alexander
так вот unwind в haskell нормально не сделать из-за того какой там стек
Alexander
или выкидываем TCO
A64m
ну, любой язык с ГЦ более ФП чем любой язык без ГЦ.
Alexander
можно почитать обсуждение пропозала
Alexander
папира нету, было бы понятно как решать - можно было бы писать
Alexander
в имплементации есть аналог resourcet который позволяет более менее нормально жить
A64m
да, конечно
Alexander
но там проблемы с "чистыми" функциями
Alexander
в линейные типы для этого ъотят пользовать
Alexander
например для работы с векторами
Alexander
ещё раст выставляет affine types в интерфейсе пользователю
Alexander
и лифтит их до линейных через кодогенерацию :)
Alexander
что можно видеть если в MIR смотреть
Alexander
мы не готовы идти на такое для haskell
Alexander
сложна, семантика немного не та
Alexander
поэтому хотим пока без этого протолкнуть расширение дальше видно будет
Alexander
у меня вообще было желание зоделать блогопост, make your own Rust in Haskell
Alexander
с описанием, что можно делать по другому чтобы линейные типы отлично были
Alexander
но я не умею писать
Alexander
ага а для всех n/y ветки делать с проверкой y/=0 и все такое
Alexander
ну раст так и делает
Антон
с описанием, что можно делать по другому чтобы линейные типы отлично были
Там не слишком сильно рантайм перелопачивать надо?
Alexander
причем надо хитро с учетом того, что у нас асинхронные исключения есть
Alexander
асинхронные исключения это реально проблема
Alexander
как если бы на каждую аллокацию вызывать функцию проверяющую стек, не прилетело ли исключение
Alexander
и делать свой unrolling
Alexander
который дешевый в haskell в отличии от
Alexander
да
Alexander
модель вычисления сильно другая, сишный стек используется только для ffi
Антон
Дешёвый как таковой или дешёвый на фоне в целом дорогого Хаскелля?
Alexander
отчасти из-за этого проблемы с эффективным llvm и dwarf и т.п.
Alexander
ну haskell уступает сишке ~1.5
Alexander
т.е. уровень современно rust :) /немного троллю/
A64m
в лучшем случае
Alexander
если не переходить в написание ручного simd, углубления в asm и т.д.
Alexander
а без асинхронных исключений наверное в haskell смерть
A64m
если нужные фичи в ллвм пропихнуть, то производительность получше будет, конечно
Alexander
любой concurrent код на них сильно пологается и за счет них можно простой код писать
Alexander
@LooMaclin мы же помним недавние спецолимпиады ^_^
Антон
> чат про Rust
> обсуждают Haskell
Alexander
это нормально
Alexander
хотя бы не go
A64m
у раста производительность что-ли хорошая? Яву хотя-бы догоняет?
доня.
> чат про Rust
> обсуждают Haskell
ты как будто первый день тут, в чатике про раст обсуждать раст - моветон
Vlad
Alexander
ну если честно у раста пока производительность не очень для языка того класса, которым он является
Alexander
не то, чтобы я прям печалился, но я бы ждал большего
Matwey
Господа, у меня вопрос