Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Peek into F# 4.1

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: A Peek into F# 4.1

#21

Post by phillipcarter »

MichaelGG wrote: post #17
akra wrote: post #5

Earlier quoted context omitted.

I definitely agree with you for tuples especially smaller tuples. As tuples get larger however performance can swing the other way. As someone who codes some F# for my day job it seems that while tuples should be easier in a functional language like F# for backwards compatibility struct tuples will be more awkward to use than in C# 7. I think they should of just bit the bullet for tuples up to a certain size. For rec…

This tuple stuff is a mess. From the RFC: >This is based partly on the assumption that the proposed C# 7.0 tuples will use struct representations for at least some small tuple types. 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, t…

> It's also sad to see no mention of really improved tooling, to put F# on the level of C#.

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

Re: A Peek into F# 4.1

#23

Post by _pmf_ »

saosebastiao wrote: post #2

I'm not a fan of the new syntax for struct tuples, struct records, and struct unions. I feel like it could have been avoided with a lesser evil if they had followed the same approach that Scala is using for anonymous functions in the upgrade to 2.12. 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 ne…

> Specifically, don't introduce new syntax

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.

[0] http://www.flotsam.nl/dispatch-periodic-table.html

Re: A Peek into F# 4.1

#24

Post by oblique63 »

smoothdeveloper wrote: post #16
Lewisham wrote: post #15

Earlier quoted context omitted.

Can you point me to instructions for this setup? I'd love to try F# (having dabbled in Haskell) on macOS, but I keep getting the feeling that F# really needs Visual Studio to shine... which is a feeling which may or may not be accurate.

brew install mono brew cask install visual-studio-code once you are in vscode, install ionide: http://ionide.io You are ready to script (or more) with a great / lightweight editor.

Spacemacs[0] with its F# layer enabled is also painless to set up, if that's more your cup of tea:

http://blog.nikosbaxevanis.com/2015/04/25/fsharp-on-emacs-wi...

[0] http://spacemacs.org/

Re: A Peek into F# 4.1

#25

Post by premium-concern »

_pmf_ wrote: post #23
saosebastiao wrote: post #2

I'm not a fan of the new syntax for struct tuples, struct records, and struct unions. I feel like it could have been avoided with a lesser evil if they had followed the same approach that Scala is using for anonymous functions in the upgrade to 2.12. 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 ne…

> Specifically, don't introduce new syntax 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,…

>> > Specifically, don't introduce new syntax

> 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.

Re: A Peek into F# 4.1

#26

Post by codelike »

F# is definitely a great language. It would be amazing if the interop with Entity Framework was improved, too, with regards to code-first development. Not having a nice and easy way to define virtual properties on records and classes is something I miss a lot:

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.

Re: A Peek into F# 4.1

#27

Post by enricosada »

douche wrote: post #4
ElliotH wrote: post #3

It's pretty cool being able to get this setup on my Mac and easily play around from the command line. It makes it much more accessible as a language than when it was more closely tied to the Windows/Visual Studio ecosystem.

I've probably spent more time messing with F# on my Mint laptop than I have on my Windows desktop... 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 write lot of c# at work, and Resharper really help.

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.

Re: A Peek into F# 4.1

#28

Post by ThatsWhatHappen »

premium-concern wrote: post #25
_pmf_ wrote: post #23

Earlier quoted context omitted.

> Specifically, don't introduce new syntax 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,…

>> > Specifically, don't introduce new syntax > 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, soon yes.

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

Re: A Peek into F# 4.1

#29

Post by premium-concern »

ThatsWhatHappen wrote: post #28
premium-concern wrote: post #25

Earlier quoted context omitted.

>> > Specifically, don't introduce new syntax > 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, soon yes. 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

Wrong parent? (_and_ wrong content, btw)

Re: A Peek into F# 4.1

#30

Post by MichaelGG »

phillipcarter wrote: post #21
MichaelGG wrote: post #17

Earlier quoted context omitted.

This tuple stuff is a mess. From the RFC: >This is based partly on the assumption that the proposed C# 7.0 tuples will use struct representations for at least some small tuple types. 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, t…

> It's also sad to see no mention of really improved tooling, to put F# on the level of C#. 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. Works…

Hmm, how much does this provide? Will this make, say, F# interactive competitive with C# interactive? (Which blew past it, despite F#'s near-decade lead.)

I'm tentatively hopeful I suppose.

Post reply on HN