Ну или хз как там называть

Ишшуй завел?

Нет

Я просто могу забить, поэтому пока решил не заводить)

Хотя уже больше половины перевёл

По идее: F# for fun and profit/learning-fsharp.md

А в какой репе это всё?

А в какой репе это всё?

https://github.com/fsharplang-ru/translations

Ооо, в md формате, какая прелесть.

Я тоже кое-что приготовил для перевода.

Надеюсь, что успею до конца каникул.

Хочу немного хайпануть на теме Azure Functions. Ну, и для блога Microsoft на хабре отлично подойдет.

https://github.com/fsharplang-ru/translations/issues/24

На F# for fun and profit очень годные статьи для начинающих

At the risk of starting another argument ... ? Let's not disparage Windows 10, 10 S, UWP, Visual Studio, Fable, Ionide, Desktop Bridge, F#, NET Native, or other technologies here. Frustrations are understandable, but airing those frustrations in a way which trivializes or otherwise insults others or other technologies only increases frustration. I cannot speak towards the priorities of the .NET Native team after they complete .NET Standard 2.0 support (which is, without question, their top priority right now). But I can speak towards our current top priority: completing the Visual Studio tooling support for .NET Core and .NET Standard. Further work to complete the .NET Core picture with Type Providers and proper F# Interactive support are also a very high priority. Furthermore, the success of current and future customers on Azure is also of very high priority for us, and it is an ongoing priority that surfaces in many areas: Azure Functions, Azure Notebooks, being stakeholders in API changes for different services, etc. Not only is Azure used by many F# customers already, but it's an area of growth for F# that is also of massive strategic importance to Microsoft. This does not mean that UWP support is somehow unimportant to us. It's clearly the future platform for Windows, and although it's not the replacement for WinForms and WPF, the ability of UWP to run on Windows Holographic devices represents an exciting area for F# and computing in general. As these devices become more widespread, I personally believe that Windows 10 will also increase in market share as it helps push the boundaries of computing devices. But the fact of the matter is, UWP is a technology that only ~30% of the Windows market can use today. .NET Core and Azure represent a larger addressable market than UWP does, and that is where the lion's share of our time will go for now. We'll remain subject matter experts for the UWP team to work with on .NET Native support, push for F# on their priority list after their .NET Standard support is completed, and we'll also contribute in identifying problems that need to be solved for proper .NET Native support. We'll also be lending similar support to those who work on CoreRT, as true cross-platform native compilation for F# applications is important for .NET Core and Azure customers.

По поводу uwp

В общем перевёл всё, кроме нескольких моментов: Do understand how partial application works, and try to become comfortable with point-free (tacit) style. And of course, there is no tool to “debug” the compiler and step through its processing (И конечно же нет инструмента для пошаговой “отладки” компилятора) But you will learn much faster if you start with a beginners mind. It is important to understand that functional programming is not just a stylistic difference; it is a completely different way of thinking about programming, in the way that truly object-oriented programming (in Smalltalk say) is also a different way of thinking from a traditional imperative language such as C. (Важно понимать, что функциональное программирование отличается не просто синтаксисом, это совершенно иной способ мышления в программировании. Различия примерно такие же, как между истинным объектно-ориентированным языком программирования (in Smalltalk say) и традиционным императивным языком, таким как C.)

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

Угу, не знаю как сформулировать

Смысл понятен, объяснять не нужно, вот с формулировкой проблема

Да, так, чтоб литературно и красиво, сложненько.)

Точнее, надо подумать.

> But you will learn much faster if you start with a beginners mind. Вы научитесь быстрее, если станете мыслить как новичок (в программировании).

Это ближе всего к дословному

Может так: Вы научитесь быстрее, если начнёте с чистого листа

Да, вариант

Т.к. там в контексте речь идёт о том, что не нужно использовать императивный стиль

Или типа "...если на момент обучения постараетесь забыть всё, что знаете о программировании"

Это уже если от себя добавлять.)

>Do understand how partial application works, and try to become comfortable with point-free (tacit) style. Обязательно поймите/разберитесь, как работает частичное применение и постарайтесь дойти до того, чтобы не испытывать неудобств, имея дело с бесточечным (point-free) стилем.

Правда, немного переосложнил

А правда что async { } всегда создает новый тред? Если я делаю там что-то тяжелое, но синхронное - это не страшно (нигде НЕ используется RunSynchronized)?

async { } следует понимать не как Task из C#, а как Func<Task>. То есть async — это ещё не запущенное вычисление, и вызыватель может управлять способом запуска (в тредпуле, в отдельном треде, синхронно по месту вызова). Я очень долго к этому объяснению приходил :)

At the risk of starting another argument ... ? Let's not disparage Windows 10, 10 S, UWP, Visual Studio, Fable, Ionide, Desktop Bridge, F#, NET Native, or other technologies here. Frustrations are understandable, but airing those frustrations in a way which trivializes or otherwise insults others or other technologies only increases frustration. I cannot speak towards the priorities of the .NET Native team after they complete .NET Standard 2.0 support (which is, without question, their top priority right now). But I can speak towards our current top priority: completing the Visual Studio tooling support for .NET Core and .NET Standard. Further work to complete the .NET Core picture with Type Providers and proper F# Interactive support are also a very high priority. Furthermore, the success of current and future customers on Azure is also of very high priority for us, and it is an ongoing priority that surfaces in many areas: Azure Functions, Azure Notebooks, being stakeholders in API changes for different services, etc. Not only is Azure used by many F# customers already, but it's an area of growth for F# that is also of massive strategic importance to Microsoft. This does not mean that UWP support is somehow unimportant to us. It's clearly the future platform for Windows, and although it's not the replacement for WinForms and WPF, the ability of UWP to run on Windows Holographic devices represents an exciting area for F# and computing in general. As these devices become more widespread, I personally believe that Windows 10 will also increase in market share as it helps push the boundaries of computing devices. But the fact of the matter is, UWP is a technology that only ~30% of the Windows market can use today. .NET Core and Azure represent a larger addressable market than UWP does, and that is where the lion's share of our time will go for now. We'll remain subject matter experts for the UWP team to work with on .NET Native support, push for F# on their priority list after their .NET Standard support is completed, and we'll also contribute in identifying problems that need to be solved for proper .NET Native support. We'll also be lending similar support to those who work on CoreRT, as true cross-platform native compilation for F# applications is important for .NET Core and Azure customers.

Кто это говорит?

@Dolfik Я предлагаю завести WIP PR и обсуждать перевод там.

Кто это говорит?

https://github.com/Microsoft/visualfsharp/issues/1096 Филлип Картер здесь

https://github.com/Microsoft/visualfsharp/issues/1096 Филлип Картер здесь

Можно сразу ссылку на комментарий давать. Она в дате публикации комментария спрятана.

Всем привет) После нескольких неудачных попыток запустил на конкурс голый кестрел, который возвращает "Hello world" на любой запрос и он тоже спекся на 1.5К RPS. Пишут, что это происходит из-за отсутствия поддержки keep-alive на клиенте.

Всем привет) После нескольких неудачных попыток запустил на конкурс голый кестрел, который возвращает "Hello world" на любой запрос и он тоже спекся на 1.5К RPS. Пишут, что это происходит из-за отсутствия поддержки keep-alive на клиенте.

Привет. Т.е. сервер сам закрывает соединение?

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

Хотя не уверен)

Но факт что оно не переиспользуется

А отключить можно?

https://github.com/sat2707/hlcupdocs/issues/3

что отключить?

А, я кажется понял в чём суть)

В чем же суть?) Я например не очень понимаю, почему из-за этого "системы заточенные на асинхронную обработку запросов проигрывают"

Могу предположить, что в случае асинхронной обработки запросов, сервер принимает соединение сразу же, как только поступает запрос, и через keep-alive говорит ему, подожди, я сейчас тебя обработаю. Когда появляется возможность, он обрабатывает запрос и шлёт ответ. А в случае с синхронной обработкой запросов, запрос просто отправляется и висит, пока сервер не закончит обработку предыдущего запроса.

шутка про node.js: "все выполняется асинхронно, кроме вашего кода"

:)

У кого-нибудь есть русская VS?

Всем привет) После нескольких неудачных попыток запустил на конкурс голый кестрел, который возвращает "Hello world" на любой запрос и он тоже спекся на 1.5К RPS. Пишут, что это происходит из-за отсутствия поддержки keep-alive на клиенте.

Можно попробовать поставить перед кестрелом nginx, чтобы мультиплексировать 100500 входящих коннекшенов в десяток с keepalive. В latency немного потеряешь, но возможно переживешь 2к rps. Прочие варианты: тюнить кестрел, либо переключится на чистые сокеты.

Вот про nginx - https://www.nginx.com/blog/load-balancing-with-nginx-plus-part2/

На изменение условий в середине конкурса я бы не расчитывал

На изменение условий в середине конкурса я бы не расчитывал

Там же вроде бета

SemaphoreSlim внутри async { } это норма для ограничения доступа к ресурсу?

Можно попробовать поставить перед кестрелом nginx, чтобы мультиплексировать 100500 входящих коннекшенов в десяток с keepalive. В latency немного потеряешь, но возможно переживешь 2к rps. Прочие варианты: тюнить кестрел, либо переключится на чистые сокеты.

Мм, спасибо, звучит очень обнадеживающе)

А что пишет в ошибках?

Файл fsx?

.fs

Не, в fs так нельзя. Только в fsx

А в чем у них разница, если вкратце?

А то студия его не обрабатывает совсем :(

fsx по идее исполняется в интерпретируемом режиме. И не требует proj файла. Все зависимости разгуливаются директивой #load. Кроме того работают #r и #I и другие директивы интерпретатора.

А fs работает так же как и cs. Там все управление структурой и подгрузка происходит через proj файлы

Понял, спасибо большое)

А то студия его не обрабатывает совсем :(

Студия говорит что синтаксис #r не валиден для fs файла.

Понял, спасибо большое)

Да. В proj файле последовательность fs-файлов важна.

Что подразумевается под function pointer?

If you are trying to create a function pointer or delegate, watch out that you don't accidentally create a simple value that has already been evaluated. Если вы пытаетесь создать указатель на функцию, или делегат, следите за тем, чтобы случайно не создать обычное значение, которое уже вычислено

Не уверен, что правильно перевёл

Думаю тут имеется ввиду что указатель на функцию это и есть делегат

Ну что же, RavenDB оказывается умеет сериализовать list и seq из коробки.

И Map тоже

И Map тоже

А option/tuple/du/records?

records - конечно

tuple, да

records - конечно

А без CLIMutable?

SemaphoreSlim внутри async { } это норма для ограничения доступа к ресурсу?

Я бы на твоём месте посмотрел на MailboxProcessor.

If you are trying to create a function pointer or delegate, watch out that you don't accidentally create a simple value that has already been evaluated. Если вы пытаетесь создать указатель на функцию, или делегат, следите за тем, чтобы случайно не создать обычное значение, которое уже вычислено

Да, указано «указатель на функцию». Видимо, имеется в виду FSharpFunc какой-нибудь (в противоположность обычным .NET-делегатам).

А без CLIMutable?

Успешно сохраняется в базу, с ним и без него.

Успешно сохраняется в базу, с ним и без него.

Круто, респект разработчикам RavenDB :)

Не любит, когда ему голый seq/list пихают. А в составе record норм.

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

Я бы на твоём месте посмотрел на MailboxProcessor.

Пытался, но проблема в том что есть 2 независимых “таски”, у которых нет общего кода (который можно было бы вынести в агента), но нужен доступ к 1 ресурсу.

Пытался, но проблема в том что есть 2 независимых “таски”, у которых нет общего кода (который можно было бы вынести в агента), но нужен доступ к 1 ресурсу.

Так ресурс и вынеси в актор

Так ресурс и вынеси в актор

А трогать его как? В Msg лямбду прокидывать?

А трогать его как? В Msg лямбду прокидывать?

Создаёшь команду. В акторе вызываешь нужную ф-цию

Создаёшь команду. В акторе вызываешь нужную ф-цию

Ооо, так я и думал что к этому сведется - нет это придется все переписывать (и главное писать доп. обвязки и паттерматчинг). Короче спасибо, пока на slimsemaphore посижу.

F# Weekly #34, 2017 – Choose your 2017 F# Heroes ! https://sergeytihon.com/2017/08/19/f-weekly-34-2017-choose-your-2017-f-heroes/amp/

Доброй ночи) Nginx помог, 2К выдержаны)

Доброй ночи) Nginx помог, 2К выдержаны)

?

latency сильно упала?

Хороший рассказ про использование провайдеров типов в продакшене. https://cboudereau.github.io/fsharp/data/prod/2017/08/18/why-we-use-fsharp-data-in-prod.html

Пожалуй, я соглашусь, что для data engineering очень полезны провайдеры типов. Скорее бы их на .Net Standard завели.

Но FSharp.Data, например, в заброшенном состоянии.

https://github.com/fsharp/FSharp.Data/pull/1056

Много PR висит.