Comments 6
Думаю, выскажу непопулярное на Хабре мнение, но всё же…
F# хорош как функциональный язык, но плохо годится для написания в императивном стиле. Через строчку писать |> ignore — это не то, что хотелось бы от современного языка. И как бы в статьях не хвалили чисто функциональный подход, f# не является удобным универсальным языком(функциональным+императивным).
К тому же, разработчики языка решили, что просто сменить язык — это недостаточно круто, и поэтому они отрешились от привычного для c# разработчиков linq.
Ещё авторы языка решили, что привычные для c# разработчиков Task — это нечто чуждое для такого прекрасного функционального языка, поэтому все вызовы к асинхронным функциями из .Net фреймворка должны сопровождаться |> Async.AwaitTask вместо привычного лаконичного ключевого слова await.
В общем, начало было хорошим, но в погоне за чистотой функционального подхода, авторы f# забыли о том, что в первую очередь это должен быть удобный практичный язык.
Через строчку писать |> ignore — это не то, что хотелось бы от современного языка.
Можете выключить этот варнинг навсегда через:
#nowarn "0020"
и говнокодить как на C# сколько влезет.
разработчики языка решили, что просто сменить язык — это недостаточно круто, и поэтому они отрешились от привычного для c# разработчиков linq.
open System.Linq
[1..10].Select(fun x -> x + 1)
.Where(fun x -> x % 2 = 0)
.ToArray()Но если что, то Дон Сайм (автор языка), является мейнтейнером либы FSharp.Core.Fluent.
Она даёт доступ к функциям "через точку" для List, Array, Array2D, Array3D, Seq, Event и Observable. Так что там ещё авторы языка сделали плохого?)
Ну и конечно же, LINQ появился позже чем этот синтаксис:
[1..10]
|> Seq.map (fun x -> x + 1)
|> Seq.filter (fun x -> x % 2 = 0)Поэтому "отрешиться" от LINQ авторы F# не могли в принципе.
Ещё авторы языка решили, что привычные для c# разработчиков Task — это нечто чуждое для такого прекрасного функционального языка, поэтому все вызовы к асинхронным функциями из .Net фреймворка должны сопровождаться |> Async.AwaitTask вместо привычного лаконичного ключевого слова await.
Авторы языка запилили async/await в F# за 2 года до появления async/await в C# :)
Поэтому и Async<T>, и асинхронные методы в стримах и HttpRequestMessage появились сильно раньше. Авторы языка C# решили что они хотят свой Async<T> и назвали его Task<T>.
Вы постоянно путаете причину и следствие.
Почти все фичи в начале появлялись в F#, поэтому авторы языка просто не могли скопировать дизайн из C#. Дизайна просто не было!
В моем понимании удобство использования .Net Framework не менее важно, что фичи языка.
Поэтому если в .Net FW решили внедрить TPL (Task — это фича фреймворка, а не языка), то это значит что нужно привести синтаксис языка под эту новую функциональность, как это сделали в C#, а не говорить, что мы это придумали раньше, поэтому мы теперь меняться не будем (пусть весь остальной мир перепишет свои либы под
Async<T>, вместо Task<T>).Поэтому если в .Net FW решили внедрить TPL (Task — это фича фреймворка, а не языка), то это значит что нужно привести синтаксис языка под эту новую функциональность, как это сделали в C#
Поддержку Task конечно же ввели сразу же, добавив Async.AwaitTask и Async.StartAsTask. Я вот лично не видел чтобы авторы C# вводили интероп с Async :)
Если пользоваться этими методами неудобно (можно понять), то вам никто не мешает расширить базовый AsyncBuilder для работы с тасками:
Или взять taskBuilder, который используется в Giraffe (кстати второй после Zebra Fullstack фреймворк на дотнете по скорости)
del
Полезная статья.
Всегда когда хочу найти нужную ф-цию ищу её по сигнатуре. Не проходите мимо.
Функциональное мышление. Часть 8