
Nikolay
18.08.2017
20:02:42
Ну или хз как там называть
Я просто могу забить, поэтому пока решил не заводить)
Хотя уже больше половины перевёл

Google

Astmatik
18.08.2017
20:03:38

Nikolay
18.08.2017
20:04:02

Astmatik
18.08.2017
20:05:04
Ооо, в md формате, какая прелесть.

Evgeniy
18.08.2017
20:14:27
Я тоже кое-что приготовил для перевода.
Надеюсь, что успею до конца каникул.
Хочу немного хайпануть на теме Azure Functions. Ну, и для блога Microsoft на хабре отлично подойдет.
https://github.com/fsharplang-ru/translations/issues/24

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


Vlad
18.08.2017
20:38:52
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


Nikolay
18.08.2017
20:44:45
В общем перевёл всё, кроме нескольких моментов:
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.)


Artemy
18.08.2017
20:45:30
Типа проблемные места?

Nikolay
18.08.2017
20:45:42
Угу, не знаю как сформулировать

Google

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

Artemy
18.08.2017
20:48:01
Да, так, чтоб литературно и красиво, сложненько.)
Точнее, надо подумать.
> But you will learn much faster if you start with a beginners mind.
Вы научитесь быстрее, если станете мыслить как новичок (в программировании).
Это ближе всего к дословному

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

Artemy
18.08.2017
20:52:05
Да, вариант

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

Artemy
18.08.2017
20:52:34
Или типа "...если на момент обучения постараетесь забыть всё, что знаете о программировании"
Это уже если от себя добавлять.)
>Do understand how partial application works, and try to become comfortable with point-free (tacit) style.
Обязательно поймите/разберитесь, как работает частичное применение и постарайтесь дойти до того, чтобы не испытывать неудобств, имея дело с бесточечным (point-free) стилем.
Правда, немного переосложнил


Friedrich
19.08.2017
05:08:45
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.
Кто это говорит?


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

Vlad
19.08.2017
05:48:57
Кто это говорит?
https://github.com/Microsoft/visualfsharp/issues/1096 Филлип Картер здесь

Evgeniy
19.08.2017
05:50:00

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

Nikolay
19.08.2017
06:30:33

Vladimir
19.08.2017
06:31:22
Насколько я понимаю клиент его обрывает

Google

Vladimir
19.08.2017
06:31:43
Хотя не уверен)
Но факт что оно не переиспользуется

Nikolay
19.08.2017
06:33:15
А отключить можно?

Vladimir
19.08.2017
06:33:43
https://github.com/sat2707/hlcupdocs/issues/3
что отключить?

Nikolay
19.08.2017
06:37:03
А, я кажется понял в чём суть)

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

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

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

Nikolay
19.08.2017
08:14:44
:)
У кого-нибудь есть русская VS?

Aleksander
19.08.2017
08:27:23
Вот про nginx - https://www.nginx.com/blog/load-balancing-with-nginx-plus-part2/
На изменение условий в середине конкурса я бы не расчитывал

Nikolay
19.08.2017
08:30:33

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

Vladimir
19.08.2017
11:37:54

Anton
19.08.2017
12:01:46

Roman
19.08.2017
12:03:10
А что пишет в ошибках?

Nikolay
19.08.2017
12:03:29
Файл fsx?

Google

Anton
19.08.2017
12:03:34
.fs

Roman
19.08.2017
12:03:48
Не, в fs так нельзя. Только в fsx

Anton
19.08.2017
12:04:00
А в чем у них разница, если вкратце?
А то студия его не обрабатывает совсем :(

Roman
19.08.2017
12:06:07
fsx по идее исполняется в интерпретируемом режиме. И не требует proj файла. Все зависимости разгуливаются директивой #load. Кроме того работают #r и #I и другие директивы интерпретатора.
А fs работает так же как и cs. Там все управление структурой и подгрузка происходит через proj файлы

Anton
19.08.2017
12:07:50
Понял, спасибо большое)

Roman
19.08.2017
12:07:52

Nikolay
19.08.2017
13:02:29
Что подразумевается под 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.
Если вы пытаетесь создать указатель на функцию, или делегат, следите за тем, чтобы случайно не создать обычное значение, которое уже вычислено
Не уверен, что правильно перевёл

Vladimir
19.08.2017
13:20:05
Думаю тут имеется ввиду что указатель на функцию это и есть делегат

Astmatik
19.08.2017
15:18:02
Ну что же, RavenDB оказывается умеет сериализовать list и seq из коробки.
И Map тоже

Nikolay
19.08.2017
15:24:46

Astmatik
19.08.2017
15:25:10
records - конечно
tuple, да

Nikolay
19.08.2017
15:26:33

Google

Friedrich
19.08.2017
15:27:19

Astmatik
19.08.2017
15:36:46

Nikolay
19.08.2017
15:37:23

Astmatik
19.08.2017
15:39:00
Не любит, когда ему голый seq/list пихают. А в составе record норм.
Ну вообще, хранить в качестве документов анонимные списки вряд ли кому-нибудь придет в голову.

Igor
19.08.2017
15:43:35

Roman
19.08.2017
15:44:54

Igor
19.08.2017
15:45:34

Roman
19.08.2017
16:04:31

Igor
19.08.2017
16:05:24

Evgeniy
19.08.2017
17:54:34
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/

Vladimir
19.08.2017
22:29:15
Доброй ночи) Nginx помог, 2К выдержаны)

Aleksander
19.08.2017
22:33:35
latency сильно упала?

Evgeniy
20.08.2017
05:08:05
Хороший рассказ про использование провайдеров типов в продакшене.
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 висит.