6 ms·

F# doesnt work ootb with sdk preview2. Work ok with preview1 of SDK (win/ubuntu/osx/docker), but preview2 has a bug, the fix is in progress ( ref https://github

F# doesnt work ootb with sdk preview2. Work ok with preview1 of SDK (win/ubuntu/osx/docker), but preview2 has a bug, the fix is in progress ( ref https://github.com/dotnet/netcorecli-fsc/issues/12 https://github.com/dotnet/netcorecli-fsc/issues/12 ) and will be published a nuget package with fix soon.

acangiano 10y ago
You reported the issue 11 days ago. I'm surprised they just announced it with such a basic use case being broken. It doesn't bode well for F# as a first class citizen in their ecosystem.
- ubertaco 10y ago
  Seconded. I saw the announcement and immediately went to grab the docker image and give it a shot with F# via "dotnet new -l F#" and go. It restored and built, but didn't run. So v1.0 is broken, I guess?
  - Eyas 10y ago
    I don't think so. It means that the tooling is broken, which is not at 1.0 yet (still in `preview2` I believe).
    - enricosada 10y ago
      Exacly, the preview2 of the sdk, atm, is broken for f#. Not the .net core, that's ok. new console/lib templates are going to be published (with the fixed fsharp compiler/library package), that's all.
      - ubertaco 10y ago
        Still a little odd for a release announcement. It feels disingenuous to only afterwards make the fine-grained distinction that yes the libraries are technically v1, but the tooling is still in preview. Kinda like announcing your new line of cars is ready for purchase today! Except that down in the fine print you might find out that the engine is ready to go, but the steering wheel, headlights, dashboard, and pedals are all still in development and so it's justifiable that they're broken.
        enricosada 10y ago
        Was like that also in the previous release. The .net core was rc2 and the .net core sdk was preview1. I use it, and i think it's ok. The sdk it's just a build system. the real value is the .NET Core, that mean the coreclr (the virtual machine) and the foundation libraries (corefx). I can change the build system one month from now, to build a project using the old packages. It's not a car (engine vs wheel). It's more like food vs marketplace. the food it's the real deal, the markeplace may be incomplete (no parking).
- MichaelGG 10y ago
  F# is not a first class citizen. They pay it lip service because it's a far more advanced language and makes MS look like they're on the cutting edge. Plus the team that made it is responsible for dragging the CLR into the modern era (or into the 60s) by bringing generics. And showing off important features on .NET such as quoted code, async workflows, F# interactive. But a simple look at tooling and language announcements shows that the F# team is very underfunded.
  - snaky 10y ago
    > The results of the 2016 Stack Overflow Developer Survey are in! F# came out as the single most highly paid tech worldwide and is amongst the third top paying techs in the US https://fsharp.tv/gazettes/f-the-most-highly-paid-tech-worldwide-in-2016/ https://fsharp.tv/gazettes/f-the-most-highly-paid-tech-world...
    - MichaelGG 10y ago
      Yes and it's clear from what the F# team has said that the hope they have for the future of the language is that the community will invest. That's fine, but let's not think that this will produce tooling anywhere nearly as refined as C#'s stuff. Take F# interactive v the C# one. F# has like a decade lead. Yet the C# interactive editor is smooth, polished, even has VS project integration, something the F# team had thought of doing many years ago. Non F#-team members[1] have said that internal politics are the issue here. To the point where some books were ... edited ... to paint C# in a better light, relatively. MS's marketing reflects this. My guess is they're too proud to admit their flagship language from their high-profile hire was shown up by what was a research project. And that the CLR's arguably biggest tech advantage over the JVM (generics) was also only done through the intense efforts of MSR; that MS Corp was against it. It's sad, because MS is in a position to really elevate the world's programming consciousness/ability by really promoting F#, yet it's still a novelty for, as MS has said "scientific and engineering" applications. Yet, apart from tooling/legacy, F# handles every case C# does in a better way. At worst, it's C# with lighter syntax. Oh well. At least it's there, works, and has some level of support. Only reason I consider using .NET these days. 1: The F# folks are amazingly polite and I've never heard them even hint at a complaint about MS.
- enricosada 10y ago
  Bug was found too late, near code freeze for rtm, not enough time for fix. fix is in progress ( https://github.com/Microsoft/visualfsharp/pull/1290 https://github.com/Microsoft/visualfsharp/pull/1290 ) probably tomorrow, it's not a big problem one or two days of delay. Also because that's an sdk issue (preview2) not of .NET Core (rtm) The f# support is in beta, c# was ahead obv, but that's ok i think, it's used as the language for the corefx, etc. vb is not working at all atm. The .NET Core sdk preview1 worked ok ootb, see for example the https://github.com/SuaveIO/Suave-CoreCLR-sample https://github.com/SuaveIO/Suave-CoreCLR-sample working xplat (win/ubuntu/osx/docker). And the preview1 continue to work. What i really like it's how the sdk it's evolving, using modularized components it's possibile to fix/improve/evolve the f# compiler/library, without waiting a new version of sdk. That's really good. In the next sdk or rtm also the `dotnet new` it's going to be updatable, so np about template too
hurricaneSlider 10y ago
Odd it worked for me without any problems
phillipcarter 10y ago
To build off of enricosada's post, this is indeed being tracked and actively worked on right now. More information here: https://github.com/dotnet/cli/issues/3705#issuecomment-228895422 https://github.com/dotnet/cli/issues/3705#issuecomment-22889... Known issues will also be updated, as will documentation on how to use F# on .NET Core.
louthy 10y ago
I have just run into this problem when migrating my project. I see the build is nearly done; when it is, what's the best way of patching?

acangiano 10y ago

You reported the issue 11 days ago. I'm surprised they just announced it with such a basic use case being broken. It doesn't bode well for F# as a first class citizen in their ecosystem.

ubertaco 10y ago
Seconded. I saw the announcement and immediately went to grab the docker image and give it a shot with F# via "dotnet new -l F#" and go. It restored and built, but didn't run. So v1.0 is broken, I guess?
- Eyas 10y ago
  I don't think so. It means that the tooling is broken, which is not at 1.0 yet (still in `preview2` I believe).
  - enricosada 10y ago
    Exacly, the preview2 of the sdk, atm, is broken for f#. Not the .net core, that's ok. new console/lib templates are going to be published (with the fixed fsharp compiler/library package), that's all.
    - ubertaco 10y ago
      Still a little odd for a release announcement. It feels disingenuous to only afterwards make the fine-grained distinction that yes the libraries are technically v1, but the tooling is still in preview. Kinda like announcing your new line of cars is ready for purchase today! Except that down in the fine print you might find out that the engine is ready to go, but the steering wheel, headlights, dashboard, and pedals are all still in development and so it's justifiable that they're broken.
      - enricosada 10y ago
        Was like that also in the previous release. The .net core was rc2 and the .net core sdk was preview1. I use it, and i think it's ok. The sdk it's just a build system. the real value is the .NET Core, that mean the coreclr (the virtual machine) and the foundation libraries (corefx). I can change the build system one month from now, to build a project using the old packages. It's not a car (engine vs wheel). It's more like food vs marketplace. the food it's the real deal, the markeplace may be incomplete (no parking).
MichaelGG 10y ago
F# is not a first class citizen. They pay it lip service because it's a far more advanced language and makes MS look like they're on the cutting edge. Plus the team that made it is responsible for dragging the CLR into the modern era (or into the 60s) by bringing generics. And showing off important features on .NET such as quoted code, async workflows, F# interactive. But a simple look at tooling and language announcements shows that the F# team is very underfunded.
- snaky 10y ago
  > The results of the 2016 Stack Overflow Developer Survey are in! F# came out as the single most highly paid tech worldwide and is amongst the third top paying techs in the US https://fsharp.tv/gazettes/f-the-most-highly-paid-tech-worldwide-in-2016/ https://fsharp.tv/gazettes/f-the-most-highly-paid-tech-world...
  - MichaelGG 10y ago
    Yes and it's clear from what the F# team has said that the hope they have for the future of the language is that the community will invest. That's fine, but let's not think that this will produce tooling anywhere nearly as refined as C#'s stuff. Take F# interactive v the C# one. F# has like a decade lead. Yet the C# interactive editor is smooth, polished, even has VS project integration, something the F# team had thought of doing many years ago. Non F#-team members[1] have said that internal politics are the issue here. To the point where some books were ... edited ... to paint C# in a better light, relatively. MS's marketing reflects this. My guess is they're too proud to admit their flagship language from their high-profile hire was shown up by what was a research project. And that the CLR's arguably biggest tech advantage over the JVM (generics) was also only done through the intense efforts of MSR; that MS Corp was against it. It's sad, because MS is in a position to really elevate the world's programming consciousness/ability by really promoting F#, yet it's still a novelty for, as MS has said "scientific and engineering" applications. Yet, apart from tooling/legacy, F# handles every case C# does in a better way. At worst, it's C# with lighter syntax. Oh well. At least it's there, works, and has some level of support. Only reason I consider using .NET these days. 1: The F# folks are amazingly polite and I've never heard them even hint at a complaint about MS.
enricosada 10y ago
Bug was found too late, near code freeze for rtm, not enough time for fix. fix is in progress ( https://github.com/Microsoft/visualfsharp/pull/1290 https://github.com/Microsoft/visualfsharp/pull/1290 ) probably tomorrow, it's not a big problem one or two days of delay. Also because that's an sdk issue (preview2) not of .NET Core (rtm) The f# support is in beta, c# was ahead obv, but that's ok i think, it's used as the language for the corefx, etc. vb is not working at all atm. The .NET Core sdk preview1 worked ok ootb, see for example the https://github.com/SuaveIO/Suave-CoreCLR-sample https://github.com/SuaveIO/Suave-CoreCLR-sample working xplat (win/ubuntu/osx/docker). And the preview1 continue to work. What i really like it's how the sdk it's evolving, using modularized components it's possibile to fix/improve/evolve the f# compiler/library, without waiting a new version of sdk. That's really good. In the next sdk or rtm also the `dotnet new` it's going to be updatable, so np about template too

hurricaneSlider 10y ago

Odd it worked for me without any problems

phillipcarter 10y ago

To build off of enricosada's post, this is indeed being tracked and actively worked on right now. More information here: https://github.com/dotnet/cli/issues/3705#issuecomment-228895422 https://github.com/dotnet/cli/issues/3705#issuecomment-22889... Known issues will also be updated, as will documentation on how to use F# on .NET Core.

louthy 10y ago

I have just run into this problem when migrating my project. I see the build is nearly done; when it is, what's the best way of patching?