Похоже, просто у них компилятор кривой, и не умеет в некоторые паттерны байткода, которые использует компилятор F#. Починят они свой компилятор — и всё заработает.

Ну так и есть. Таже хвостовая рекурсия.

Ну так и есть. Таже хвостовая рекурсия.

F# не использует хвостовую рекурсию на CLR.

.tailcall уже давно никто не эмитит.

Рекурсия просто раскрывается компилятором в цикл если возможно.

там нужна поддержка Roslyn, в первую очередь для UWP

Да UWP нахер никому не нужен. То, что это говно до сих пор не опенсорс намекает, что жить ему недолго осталось.

Да UWP нахер никому не нужен. То, что это говно до сих пор не опенсорс намекает, что жить ему недолго осталось.

Я прошу умерить пыл, пожалуйста.

Я прошу умерить пыл, пожалуйста.

Простите, это просто моя больная мазоль)

.tailcall уже давно никто не эмитит.

В C# используется вроде tailcall

.tailcall уже давно никто не эмитит.

Это точно? Просто у них до сих пор это числится в списке ToDo для поддержки F# на .net native

Roslyn и RyuJIT x64

Да UWP нахер никому не нужен. То, что это говно до сих пор не опенсорс намекает, что жить ему недолго осталось.

отучаемся говорить за всех) uwp куда как более перспективная область, чем net core. а net native - это прорыв конечно. Я понимаю, что сейчас идёт много глупого хайпа про "десктоп не нужен", тем не менее 10-ка весма популярная ось, и аппы под неё писать с каждым днём все выгоднее и выгоднее

В C# используется вроде tailcall

Неа, у меня больше не получилось воспроизвести его появление. Последний раз видал в C# 4 на x64 платформе, больше нету.

Roslyn и RyuJIT x64

JIT не имеет прямого отношения к кодегену компилятора.

JIT не имеет прямого отношения к кодегену компилятора.

Ну JIT уже оптимизирует после компиляции

отучаемся говорить за всех) uwp куда как более перспективная область, чем net core. а net native - это прорыв конечно. Я понимаю, что сейчас идёт много глупого хайпа про "десктоп не нужен", тем не менее 10-ка весма популярная ось, и аппы под неё писать с каждым днём все выгоднее и выгоднее

Это все оффтоп конечно, но десктоп жив и все такое, полностью согласен. Вопрос только в том, зачем там увп? Есть нормальные полноценные десктоп приложения, для которых F# отлично работает.

Ну JIT уже оптимизирует после компиляции

JIT может оптимизировать те кейсы, в которых не указана .tailcall

Okay

отучаемся говорить за всех) uwp куда как более перспективная область, чем net core. а net native - это прорыв конечно. Я понимаю, что сейчас идёт много глупого хайпа про "десктоп не нужен", тем не менее 10-ка весма популярная ось, и аппы под неё писать с каждым днём все выгоднее и выгоднее

Извиняюсь, .net native - это что за зверь такой? Прогуглил поверхностно, что-то вроде компиляции в нативный код, который не требует установки дотнета на клиенте? Получается, нужен только для десктопов?

Это все оффтоп конечно, но десктоп жив и все такое, полностью согласен. Вопрос только в том, зачем там увп? Есть нормальные полноценные десктоп приложения, для которых F# отлично работает.

не согласен. UWP - это очень крутой и сверх качественный фроненд, в сравнении с winforms/WPF - суперские возможности дизайна, высокая скорость разработки и поразительно высокая производительность без боли. Ну и с net native это вообще открывает безграничные возможности.

Извиняюсь, .net native - это что за зверь такой? Прогуглил поверхностно, что-то вроде компиляции в нативный код, который не требует установки дотнета на клиенте? Получается, нужен только для десктопов?

UWP использует .NET Native для прекомпиляции приложений. Поэтому отстуствие поддержки F# в .NET Native означает, что UWP на F# писать нельзя.

не согласен. UWP - это очень крутой и сверх качественный фроненд, в сравнении с winforms/WPF - суперские возможности дизайна, высокая скорость разработки и поразительно высокая производительность без боли. Ну и с net native это вообще открывает безграничные возможности.

Поживем увидем. После около двух лет разработки под UWP боли заметил не меньше, чем со старым добрым WPF.

Извиняюсь, .net native - это что за зверь такой? Прогуглил поверхностно, что-то вроде компиляции в нативный код, который не требует установки дотнета на клиенте? Получается, нужен только для десктопов?

Перед публикацией в стор МС обрабатывает твой appx этим зверем. Что-то типа компилятор+линковщик. На выходе нативные бинари под arm и x86. Ты можешь писать на F# UWP, но без этой обработки они в стор не попадут.

После нескольких легаси проектов на wf/wpf выработалось не совсем приятное отношение к десктоп разработке, поэтому в сторону uwp не смотрел

@ruzzke_mir , думаете, UWP только прибавит в популярности ?

wpf вполне себе ок, если на нем писать нормально. Но порог вхождения высокий, да

Во всяком случае, вспоминая mfc,winforms

wpf на голову выше

@ruzzke_mir , думаете, UWP только прибавит в популярности ?

Могу сказать точно, что как только хайп прошел популярность только падает. Нативные UWP приложения или перестают поддерживать или убирают из стора. Большинство пошло по пути предложенному майкрософт - конвертирование классического десктоп приложения через UWP desktop bridge. После того, как мобилки оффициально всё, все в ожидании. Никто не хочет инвестировать в не понятно что.

UWP использует .NET Native для прекомпиляции приложений. Поэтому отстуствие поддержки F# в .NET Native означает, что UWP на F# писать нельзя.

Был workaround от MS для того, чтоб совать в стор приложения на F# без прогона native.

Что мне не нравится во фронтенде (и десктопа, и веба) - слишком много технологии - Angular, Vue, React, Knockout, или Wf/Wpf/Uwp/DevExpress - сиди и думай, что учить

На бэкэнде все спокойно, 80% всех задач решается стандартными средствами

Учить F# ?

До появления всего этого зоопарка были winforms на десктопе и jquery + css в вебе.

Так что думай об этом как о расширении набора инструментов.

У меня коллеги робототехникой занимаются - клепают формочки на Windows Forms, горя не знают. WPF не упёрся ни разу :)

wpf на голову выше

Если начинать с WPF, то вполне себе ок

Потом WinForms убогим считаешь)

Я начинал с MFC

ПОтом Winforms, потом WPF

@ruzzke_mir , думаете, UWP только прибавит в популярности ?

UWP - это офиц. UI фреймворк для 10-ки. ну вы надеюсь согласитесь с тем, что в будущем все эти 7-ки и хр-шки сдохнут а винда так и останентся лучшей осью для конечног оюзера? что касается остальных, не думаю,что скажу что-то новое: winform - прошлый век, wpf - тормозит и в депрекейшене

UWP - это офиц. UI фреймворк для 10-ки. ну вы надеюсь согласитесь с тем, что в будущем все эти 7-ки и хр-шки сдохнут а винда так и останентся лучшей осью для конечног оюзера? что касается остальных, не думаю,что скажу что-то новое: winform - прошлый век, wpf - тормозит и в депрекейшене

это я к тому, что если них net core в приоретете для развития F# тулов над UWP и net native, то эти люди от реальности далеки

это я к тому, что если них net core в приоретете для развития F# тулов над UWP и net native, то эти люди от реальности далеки

У кого у них? Этим занимаются разные команды, с разными задачами и приоритетами.

У кого у них? Этим занимаются разные команды, с разными задачами и приоритетами.

понятия не имею - у кого. вы же вроде написали - что приоретет net core выше

понятия не имею - у кого. вы же вроде написали - что приоретет net core выше

не,не вы, другой человек

UWP - это офиц. UI фреймворк для 10-ки. ну вы надеюсь согласитесь с тем, что в будущем все эти 7-ки и хр-шки сдохнут а винда так и останентся лучшей осью для конечног оюзера? что касается остальных, не думаю,что скажу что-то новое: winform - прошлый век, wpf - тормозит и в депрекейшене

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

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

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

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

Более того, делать ставку на UWP вообще рискованно. Есть гораздо более надёжные пути создания десктопного ПО

Более того, делать ставку на UWP вообще рискованно. Есть гораздо более надёжные пути создания десктопного ПО

ну что значит "делать ставку"? речь идёт о принципиальной возможности. Есть в C# - должно быть в F#.

Более того, делать ставку на UWP вообще рискованно. Есть гораздо более надёжные пути создания десктопного ПО

любой стартап связан с рисками. в WPF я вижу на порядок больше рисков

ну что значит "делать ставку"? речь идёт о принципиальной возможности. Есть в C# - должно быть в F#.

Да, было бы хорошо, но имеем что имеем. F# слишком маргинален, чтобы активно решать эту проблему

Да, было бы хорошо, но имеем что имеем. F# слишком маргинален, чтобы активно решать эту проблему

об чом и спич. вендор сливает потихоньку. для C#/VB добавляют всё больше и больше конкурентных способностей на рынке, а F# - сами как нибудь что нибудь сделайте, господа опенсорцники

F# и вообще функциональщина вроде тоже набирают обороты. Взять ту же скалу

Так что может уже и не такой уж маргинальный

об чом и спич. вендор сливает потихоньку. для C#/VB добавляют всё больше и больше конкурентных способностей на рынке, а F# - сами как нибудь что нибудь сделайте, господа опенсорцники

а для последних - проще и дальше рассказывать на конфах про world bank provider, чем запилить что-то стоящее. например net native для F#

а для последних - проще и дальше рассказывать на конфах про world bank provider, чем запилить что-то стоящее. например net native для F#

.NET Native закрытая проприетарная технология.

.NET Native закрытая проприетарная технология.

Да, поэтому господа опенсорщики тут бессильны

.NET Native закрытая проприетарная технология.

да ладно, думаю в msr есть доступ этому секрету ))

да ладно, думаю в msr есть доступ этому секрету ))

Не вижу связи.

Не вижу связи.

связь такая, что хотели бы запилить - запилили бы. Автор языка выбрал не правильный вектор развития.

связь такая, что хотели бы запилить - запилили бы. Автор языка выбрал не правильный вектор развития.

Не понимаю, как сотрудник MS Research может повлиять на работу другой команды в MSFT.

Ходить и обивать пороги начальства с прошениями? Есть много более важных дел.

рядовой сотрудник - не знаю. Авторитетный автор ЯП - легко без обиваний порога.

рядовой сотрудник - не знаю. Авторитетный автор ЯП - легко без обиваний порога.

Ок, напиши ему письмо с предложением.

Вот!

это дело

ERROR: S client not available

Ок, напиши ему письмо с предложением.

???

Давайте петицию запилим на change_org.

Хитрая рыба

тут не постит рекламу

Ок, напиши ему письмо с предложением.

стоп, я не правильно прочёл из-за трещины на экране смартфона) в слове "напиши" у меня почему то последней буквой "У" увиделась)) так что нет, не "Вот! это дело" ))

стоп, я не правильно прочёл из-за трещины на экране смартфона) в слове "напиши" у меня почему то последней буквой "У" увиделась)) так что нет, не "Вот! это дело" ))

Блин, тоже показалось.

Нет, извините, меня лично поддержка .NET Native и UWP слабо интересует. :)

https://github.com/Microsoft/visualfsharp/issues/1096

Предлагают не использовать UWP APIs.

> corert is likely to be the future of cross-platform native compilation of .NET code В общем, в конце концов MS, возможно, переедет на открытый стек, и тогда заживём.

> corert is likely to be the future of cross-platform native compilation of .NET code В общем, в конце концов MS, возможно, переедет на открытый стек, и тогда заживём.

только если при этом микрософт пожелает вендорить эту тему. иначе будет очередной suave/fable/worldbank

вобщем вот это вот I want F# as a programming language to succeed, but to do that it must be its own community. - в корне не верно

IMHO: F# для мейнстрима майкрософт всегда был полигоном новых технологий. Пока не появился Рослин они пытались на нем катать новые возможности за счет более зрелого комьюнити. Сейчас мы отстаем по фичам.. То что наработано в мейнстрим не войдет (типа тайппровайдеров и инлайнов) - слишком специфично и, что там, говорить, узко. Рывок возможен, но пока сил у нас мало.

IMHO: F# для мейнстрима майкрософт всегда был полигоном новых технологий. Пока не появился Рослин они пытались на нем катать новые возможности за счет более зрелого комьюнити. Сейчас мы отстаем по фичам.. То что наработано в мейнстрим не войдет (типа тайппровайдеров и инлайнов) - слишком специфично и, что там, говорить, узко. Рывок возможен, но пока сил у нас мало.

+1

Характерная ситуация - тайпклассы. Дон ждет C#, а С# думает на чем бы проверить. Основной принципиальный функционал спроектирован уже дай бог, года 2 если не 3 назад. И...

Характерная ситуация - тайпклассы. Дон ждет C#, а С# думает на чем бы проверить. Основной принципиальный функционал спроектирован уже дай бог, года 2 если не 3 назад. И...

Интероп важнее. Скорее всего тайпклассы в C# будут идти вместе с изменениями в CLR.

Но это только одна из причин.

Опять же IMHO. Появление async в FSharp спровоцировало и открыло дорогу для async в C#. Для создания тайпклассов в принципе не нужны изменения в CLR. Они нужны только для оптимизации памяти при их работе. И то только для места занимаемого кодом.

Опять же IMHO. Появление async в FSharp спровоцировало и открыло дорогу для async в C#. Для создания тайпклассов в принципе не нужны изменения в CLR. Они нужны только для оптимизации памяти при их работе. И то только для места занимаемого кодом.

Изменения в CLR нужны, чтобы тайпклассы стали нормальной фичей платформы, а не хаком компилятора.

Если нужны "тайпклассы" в виде хака, то в F#4.2 планируются.

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

типа си-линукс-18кк

Не вижу хака. Если в CLR будут поддержаны тайпклассы, то этобудет только рантайм поддержка. В копайл тайм это не нужно. Собственно вся оптимизация УЖЕ ЕСТЬ за счет безполевых структур. Все что нужно - это generic type specialization inference - но это чисто кмпиляторная фича. Я не понимаю, что нужно добавить в CLR для просто тайп классов. Вот для HKT - да. Там будут костыли компилятора.

Я повторюсь, если нужна чисто компиляторная F#-only фича, то она в каком-то виде будет в F#4.2

Она же запланирована в С# 8. Точка в точку. То самое, что Дон и Метью тогда на хакатоне показали.

Она же запланирована в С# 8. Точка в точку. То самое, что Дон и Метью тогда на хакатоне показали.

Что? Нет.

В C#8 не будет тайпклассов.

В F#4.2 будет улучшенный вывод для SRTP.

https://github.com/dotnet/csharplang/issues/164

Недавно метка стояла - C# 8