A Peek into F# 4.1
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
Its Ocaml heritage gives it tons of advantages over other functional languages rolled from scratch when it's time to write server or application code, it has a class library equivalent to the Java stdlib behind it, and its focus on data processing has made it a good choice for people doing data science.
Specifically, don't introduce new syntax, but force your users to deal with the fact that your bytecode is now incompatible with previous versions and now requires a new minimum version for the VM. They can recompile...it's not really that big of a deal. It is far more of a big deal to rewrite all of your code than it is to upgrade your VM and recompile.
For records and unions however I think the attribute is fine. Most of the time for types of more than 3 fields say structs can be worse in performance than classes anyway. Records and unions tend to be assigned more and live longer than tuples most of the time. For unions for obvious reasons structs are not recursive in nature which with unions is required somewhat (see https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110...). Definitely wouldn't want structs to be the default here.
This is what F# had to begin with! They were sort of pushed into using a heap-allocated type via System.Tuple, in the name of compatibility with the rest of .NET. Frustrating!
It's also sad to see no mention of really improved tooling, to put F# on the level of C#. MSCorp paid some lip service, well overdue since the F# guys are the ones that gave them generics which was the biggest thing technical advancement .NET had over Java.
Could you clarify what you mean here? Perhaps I could have written more about it in the blog post, but sitting the language service atop the Roslyn Workspace layer is critical work that:
1. Gives F# a "modern" editor experience out of the box.
2. Gives F# an entry point into the large amount of Roslyn-based IDE features. Workspaces are how they "talk" to the language, so that means that they can now "talk" to F# as well. This is not possible with tooling today.
This also has another big impact: F# will be able to use the CPS-based project system that is being built for C# and VB right now: https://github.com/dotnet/roslyn-project-system
I'm tentatively hopeful I suppose.
It seems the feature was implemented to answer the concern of interop with C# (which in future v7 will have shorthand syntax only for System.ValueTuple but not for System.Tuple), the language might later add better support for deconstruction without the extra keyword.
For tuples which remain local, the compiler is generally good at eliding those (but not in all cases, if it is a concern, always check the optimized compiled output).
type S = struct val X:int end
type [<Struct>] R = val Y:int
The examples in the blog post aren't in accordance with the RFC as far as type signatures are concerned [1] The tuple decomposition is mixed in with the type sig.
let getPointFromOffset (point: struct (x, y)) (offset: struct (dx, dy)) = ...
let getPointFromOffset (struct(x, y) as point) (struct (dx, dy) as offset) = ...
let getPointFromOffset ((x, y): struct(int * int)) ((dx, dy): struct(int * int)) = ...
[1] https://github.com/fsharp/FSharpLangDesign/blob/master/RFCs/...
Hearing this in the context of Scala is hilarious[0].
> force your users to deal with the fact that your bytecode is now incompatible with previous versions and now requires a new minimum version for the VM. They can recompile...it's not really that big of a deal.
Only in the ideal world of greenfield development. You have to ensure that the build system, bytecode enhancer, AOP injectors all are able to cope with the new bytecode format.
> Hearing this in the context of Scala is hilarious[0].
I'm confused, I don't see any syntax in this link. Wrong link?
> You have to ensure that the build system, bytecode enhancer, AOP injectors all are able to cope with the new bytecode format.
If you use Scala you usually need none of them. Problem solved.
Currently no classloader is needed to run Scala code.
However, in order to solve binary compatibility once and for all, Scala 3 (aka Dotty) adds an extra bytecode layer on top of Java bytecode.
Details at https://d-d.me/talks/scaladays2015
http://stackoverflow.com/questions/26775760/how-to-create-a-...
Not sure how difficult it would be to implement a [CliVirtual] attribute (https://fslang.uservoice.com/forums/245727-f-language/sugges...), but that would definitely help and make the EF-models more readable.
But in general, F# is great. I hope more people will use it.
Part of that is that F# doesn't really have the level of tooling that I've come to expect from C# in VS, with ReSharper.
I would like a static analysis tool for F# that tells you when you are doing something that is legal, but dumb, as ReSharper does.
I'm not sure if it is integrated to ionide yet.
When c# dev see f#, always ask for tooling like resharper. That's because you expect to have same issue/experience of c# development, but it isnt.
In F#, there is a lot less need for Resharper help, but that's become visibile only you start writing code, because the compiler help you a lot more than c# compiler
Writing f#, lots of the issue fixed/highlighted by resharper are not possibile, the language fix entire classes of problems (like null ref, make invalid states impossibile or really difficult, type safety for external data, etc)
And refactoring is really easy, because function usually are passed as value, so less need to rename things.
Last is, having less code, there is less to change. Seem a simple reason, but that's it.
For example because methods/function doesnt explicitly write class/types in the signature (are infered), there is no need to change it when is renamed.
Or refactor: extract function is just indent or move, because compiler will complains about missing capture closure, etc, and with immutable data, it's easy
Another really strange feature (it's not a bug) of f# ordering of files, make you cleanly separate types/functions in separate modules, making the creation of entangled code that may happen with c#, really really difficult.
brew install mono
brew cask install visual-studio-code
You are ready to script (or more) with a great / lightweight editor.
http://blog.nikosbaxevanis.com/2015/04/25/fsharp-on-emacs-wi...