enricosada · HackerTrans

enricosada

no profile record

comments

5 anni fadiscuss

See https://dotnet.microsoft.com/download

Download the Sdk, who bundle both the runtime and the C#/F# compilers (everything you need to build a program) and the `dotnet fsi` REPL

All of that is open source, developed in different repos and bundled there in a nice installer.

Support all platform and can cross compile for other OS

Please do not use Mono, because contains an old version of F# and lots of quirks to use.

The current way is .NET (was called .NET Core, renamed recently) because is cross platform by design, and eventually Mono will be merged 100% there.

Plus is tons more performant and better tooling

5 anni fadiscuss

C# switch are just syntactic sugar. nice for sure.

But if you compare F# with C#, is not just LINQ .Select vs List.map

And i am not speaking about function, who is just a part of why i like F#, not the best one

Is the different defaults who matter, who guide you to an easier code who highlight the domain

- structural comparison vs reference comparison - expression vs statement based - immutability

C# will catchup with some features for sure.

Lot of new C# feature remove boilerplate (file scoped namespace, etc) and is a good trend

But the core defaults will be the same.

That will not push to a single direction (if fact you have LOTS of way to write the thing in C#) while F# try to push to the same way

To do so, C# continue to add thing to the LANGUAGE. Now is a lot more complicated than .NET 2.0

While F# try to do the same, but the language doesnt change.

An example: the async/task.

C# added the async as keyword, plus all needed to make it work, and the compiler generate special code.

F# has built that from the general computation expression feature and (recently) the state machine support.

5 anni fadiscuss

As a note, the codebase is also huge because contains lot of code:

- FSharp.Core library, who contains most of the types and functions you want to use

- the fsc F# compiler

- the FSharp.Compiler.Service, who is the compiler as a library used by all editors/ide, written to be performant and support the logic of IDE functionalities (find references, etc)

- The Microsoft Visual F# code, who is the F# extension for Visual Studio

So is complicated repo, but for a reason. But nice to work with given the features there

5 anni fadiscuss

For me is that pratically every time, if compile, it works.

It's really easy to express a domain (with discriminated union and type) and the defaults (immutability, option, removal of boilerplate, high order function to manipulate data, structural comparison not reference) allow me to write correct code, who is readable without too much friction.

Support a repl as first class, so that works too if you like repl driven development

Community is also nice

7 anni fadiscuss

Appveyor also support stop and RDP in the windows build agents for 60 minutes each build. really nice for diagnose the issues

7 anni fadiscuss

The F# repl (FSI as fsharp interactive) works in .net core 3.0 preview already, you can do `dotnet fsi` to run it

Type providers works in general, but depends if the type provider library was updated to use latest type provider sdk. Also generative type provider may not works, erasing works

8 anni fadiscuss

For F#, you can also use F# to transpile f# to clean javascript (will use standard babel and has an awesome interop story with existing npm packages or js libraries), and use electron api as is

https://github.com/fable-compiler/samples-electron

Related, the ionide extension of Visual Studio Code ( https://github.com/ionide/ionide-vscode-fsharp ) is implemented with fable, and used to generate extension of vscode (electron/js based). works really well and power the F# language support of Visual Studio Code

8 anni fadiscuss

An example of Core Erlang usage:

- fez ( https://github.com/kjnilsson/fez ) is an F# to Erlang compiler (compiling to Core Erlang)

A good intro with some word about core erlang too

https://skillsmatter.com/skillscasts/11312-fez-fsharp-type-s...

8 anni fadiscuss

Depends for what you need GUI. You need it for complex LOB app? So no, editor will be good.

Personally, i write c# and xaml, and i dont use the editor (vs or blend), but i edit directly the xaml.

About f# and gui, depends on use case. For example https://fslab.org/XPlot/ to show graphs.

  let series = [ "bars"; "bars"; "bars"; "lines" ]
  let inputs = [ Bolivia; Ecuador; Madagascar; Average ]
  
  inputs
  |> Chart.Combo
  |> Chart.WithOptions 
       (Options(title = "Coffee Production", series = 
          [| for typ in series -> Series(typ) |]))
  |> Chart.WithLabels 
       ["Bolivia"; "Ecuador"; "Madagascar"; "Average"]
  |> Chart.WithLegend true
  |> Chart.WithSize (600, 250)

this is used to generate programmatically i chart. inside a window with some layout, usually in enough. And i can do testing in the repl.

But yes, if you use editor like c# version, F# is less nice to use. But again, programmatically allow other things, like https://github.com/fsprojects/Elmish.XamarinForms

So depends how much time you edit the view (and why), vs gains in the logic behind the view. For me the global tradeoff, but depends, so you are right.

8 anni fadiscuss

About GUI on .NET Framework:

- Windows form works but not perfect. The editor works if you install the template for it, but not the auto generation of code, like double click on button -> handler generated. You write code programmatically. but is used a lot. I use it in the repl (fsi), to generate chart, custom data visualization.

- WPF the same, works, no editor (but codegen is less needed)

- Xamarin support F# ( https://docs.microsoft.com/en-us/xamarin/cross-platform/plat... ) on Forms, etc

Some good from community+MS, because community tried to adapt techonologies and make it more friendly to use in F#

- Xamarin XAML in Elmish style, really more idiomatic ( https://github.com/fsprojects/Elmish.XamarinForms ) from F# creator itself (Don Syme, who now work on xamarin division too)

- WPF and Xamarin xaml can be used with a type provider too for statically type view at compile type ( http://fsprojects.github.io/FsXaml/ )

The only one not yet supported is UWP, because of of .NET Native.

All that without speaking of the gui stack outside .net framework, like electron+fable or just fable+elmish/react/react.native ( https://github.com/SAFE-Stack/SAFE-Nightwatch )

8 anni fadiscuss

Is already at the beginning of the article, but should be more visibible how MS Research and Don Syme seen the opportunity to add generics (neeeded for F#) and added that. With design already supporting later addition like variance.

Not just the design, the real implementation too in the existing already complex CLR codebase. And that include lot of areas like NGEN, AppDomains, etc, so is no small feat at all, for a production ready framework already used by lot of developers.

I am programming in .NET Framework from v1.0, the v2.0 (with generics) was a clear cut, so is not something you can add too late because it become pervasive in the framework who leverage it in the design (generics in v2.0, LINQ in v3.0, TPL and Async v4.0) As a note, .NET continue to support non generic collections for backward compatibility, but usage is deprecated.

Really interesting piece of .NET history in https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...

9 anni fadiscuss

There are lot of scenario where F# can be used.

In some scenario support is more stable, other experimental, other are not supported. like every technology.

Because budget is not infinite, you need to prioritize.

Just to show you things happened MS tech related to F# and .NET in the last two years:

- .net core

- .net standard (is not the same as .net core)

- new project system for VS

- new .net sdk (that mean work to support these on VS)

- portable pdb

- F# 4.1

- temporary stuff like project.json, who added work and was replaced

- new .net templating

- F# in VS now use roslyn workspaces (yes, that's big)

- integration of VisualF# powertools in default VS extension

- f# bundled in .net sdk and compiler in .net core sdk

- F# on azure notebooks

- F# on azure functions

- VS 2017

- VS 2017 installer (yes, that was annoying)

And that list is just some of MS technologies, who VF# team need to support/adapt too.

NOTE the list doesnt contains things created from community itself, like Fable. and some of these were added by community

Yes, and there is too:

- UWP

- .NET Native

- Corert

but you need to prioritize and choose your (moving) targets.

So ihmo while UWP can be nice to have (ihmo), was put in a lower priority than the others.

When you choose there are lot of factors:

- time to implement

- unknown

- other things open in parallel scenarios

- support needed to complete/make it usable

Community help a lot the F# development, and also a lot the VS VF# extension, see the repo. Because F# has lot of OSS in the dna.

But that doesnt mean we cannot complain when things need improvements, in some important scenario.

And as a note, the MS VF# project manager was awarded the `F# community Hero award`, that mean the community like and support his work (the award is indipendent and run from community voting)

9 anni fadiscuss

See https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for quickstart and info for F# on .NET Core.

VSCode (with ionide), vim (vim-fsharp binding), emacs (fsharp-mode) already support it, with full intellisene. VSCode also support debugging.

About the aspnet stack, same future limitation of C#, as discussed on the post. But there are also alternative web stack, like Suave.

9 anni fadiscuss

Or using awesome |> pipeline operator

    "/path/to/file"
    |> File.ReadLines
    |> Seq.iter (printfn "%s")

the printfn can be expanded as function, instead of partial app

    "/path/to/file"
    |> File.ReadLines
    |> Seq.iter (fun line -> printfn "%s" line)

9 anni fadiscuss

Big :+1: to continuous, the f#/c# ide for ipad, really slick

9 anni fadiscuss

About .net core and F#, see wiki https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for info

Debugging in vscode is coming soon (before rtm), works already in dev version

9 anni fadiscuss

About .net core and f#, just see wiki https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for more info

9 anni fadiscuss

that website is gold anyway, not only for f#. Lots of nice concepts, explained simply.

And lots of good tutorial/ideas

9 anni fadiscuss

Depends what you mean released. rtm not, but rc are out, and works.

Or use VS2017-rc, to use f# 4.1 with .NET framework

Or use .NET Core sdk and .net core https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... the default templates use new f# 4.1

Ionide in vscode support .net core (both project.json and msbuild sdks), atm there is a temporary issues with rc4, but feel free to use a previous sdk (are really similar, no need to stay bleeding edge, and will be fixing sooner than later).

See wiki https://github.com/dotnet/netcorecli-fsc/wiki for more info about f# and .net core, or new sdk (all version, with how-to and workaround if needed)

9 anni fadiscuss

the Suave extension for ASP.NET Core (https://www.nuget.org/packages/Suave.AspNetCore/) is fast and you can use lots of suave specific features, with same performant kestrel as base, because suave is added as middleware.

Or there is also a new attempt (https://github.com/dustinmoris/AspNetCore.Lambda) to use api similar to suave, more integrated with asp.net core itself (security/auth/etc).