Project future

[Krzysztof-Cieslak]

OK, so given all... stuff... that happened around my other projects (VSCode debugger, Rider) I'm not really sure if i still want to do lot of F# OSS.

So I guess, we should somehow decide if anything is going to happen with this project. Theoretically we have many maintainers listed here, but practically I've been developing it on my own, with some suggestions from others from time to time.

Current state of the project:

1. It's opt-in extension for existing MsBuild system - user still need to have .fsproj file (tho, it's super simple) where he needs to add reference to FsToml target file responsible for generation of .props - this can be done as MsBuild SDK - whatever it really means - which will work automatically after SDK nuget package is added. F# integration with new .fsproj file works like that - @enricosada knows more about it.
2. User puts .fstoml file next to .fsproj file - it contains all important informations about project - file, properties, dependencies.
3. .fstoml is integrated with Paket - it replaces paket.references file [solution level Paket files are still needed]
4. .fstoml is transformed to normal MsBuild-XML .props file put into obj dir - this makes it automatically imported every-time MsBuild access .fsproj file. It means, that our .props file is automatically imported when dotnet CLI is called, or when editor tries to crack project file. It doesn't require any changes to dotnet CLI, FSAC, FCS etc. It works with them out of the box
5. Drawback of this is that user needs to rerun dotnet restore whenever .fstoml file is changed. It may not be as big problem as same behavior is required for Paket integration with new .fsproj

I don't know if it's best way of doing things. I know that it's a way that provides best integration with existing ecosystem without any changes to existing tooling. What in my view is really important for possible adoption of the project.

CC: @alfonsogarciacaro @cloudRoutine @forki @matthid @dsyme @7sharp9

[matthid]

Sorry I was watching on this project. But you are right, we should just start to bootstrap this into some projects of the ecosystem. As I'm currently on FAKE & Paket I can do it if people there agree.

[alfonsogarciacaro]

Not entirely related to this issue, but I hear you @Krzysztof-Cieslak and I'd like to share my biased and likely wrong view of the current state of F# OSS.

In spite of everything, I think we're living a really good moment for F# OSS as this tweet from @haf summarizes. The tooling is getting better and better which encourages people to approach F# and also to start contributing. We're enjoying wonderful synergies: devs like Fable no because Fable itself but because it's really pleasant to work with Ionide, and this is also thanks to the improved F# compiler error messages by @forki, etc. Paradoxically it's this popularity which attracts big players and makes Jetbrains, for example, create an F# IDE. I perfectly understand your concerns about this threat (specially considering they can just take YOUR stuff to compete with you), but we've seen at fsharpX the compromise of the community with Ionide. I think this is not only because Ionide is a fantastic tool but also because it's a symbol of the wonders a community member can do, and I don't see this compromise disappearing all of a sudden.

That said, at the same time there's a risk this momentum dies from its success. The more users we have the more responsibilities we take on our shoulders, and the longer we have to dedicate to make sure our projects keep up with the ever changing OSS ecosystem. Open source development has many funny moments but also others that are not. So IMHO we need to be careful not to fight too many battles.

That's not to say fstoml could bring great benefits to the F# ecosystem but as everybody knows it's difficult to establish a new standard: users need to learn a new thing (even if it's easier than the old one), community splits, editors need to support it somehow (here at least editors with a GUI for project files)... and even as awesome as the F# community is, resources are still limited ;)

[cloudRoutine]

A better project configuration format is a neat idea that I'd like to come back to in the future, it's just not super important to me right now.

As for JetBrains that's kinda cool, but it doesn't change any of my plans or what I'll be working on.

Once paket is fully featured on netcore with no nuget dependency, FAKE is working on netcore, FSharp.Editing is up and running to the point where I'm not the only person who can work on it, and netcore projects are supported in VFT, then I'll come back to this and see what's up.

[enricosada]

Speaking for myself, i can help anyone who will continue, if has questions i can answer about msbuild/newsdk/integration/possibile enhancements, any time, as usual.

I cannot commit to maintain or actively help/code to move forward this project (and probably i was not a target for that).

For same reasons (time and focus) i didnt commit to other projects i'd like to play with.

Sry for lenghly post, but this is a common issue i see lately, and because lots of tooling dev are here, i'd like to explain why.

About Rider, i enjoy ionide and vscode a lot, and for me is good news, but is just another editor i am not going to use (like atom or emacs, but i use vim for example). Some people may like that, for reasons, good, more choice. Rider will be a big bonus if that help other projects, using shared components (FCS for example) contributing to these instead of just consume it. But we create shared components also for that, to enable new scenarios.

Ionide currently has lot of polish, enhancement, performance and new ideas (the signature code lens are amazing, and i really say that every time i speak about f# in vscode). And a really nice user experience, thx @Krzysztof-Cieslak about that, thx a lot. And ihmo is there to stay, because is really a joy to use. Is not an easy feat to have a complete product, proto are easy, ionide is really complete. Is on a different level then other projects, who are poc or optional usage. And you helped everyone, fixing shared components to arrive there.

I think some components are finally converging in the F# tooling ecosystem, not just FCS/FSAC and vf#, but also soon between mono/.netfull/.netcore, for all .NET languages. We can leverage some, and that mean maybe collaborate to existing projects (because resources are a finite amount) to fix our pain points, or replace some.

About tooling, ihmo we really need to discuss somewhere about near future (1year, or 2), to revise what are the pain point now, and how to best fix that, in the current and near future ecosystem who changed quite a bit (oss, merge and split of fsharp/fcs/vf#, new sdk, languageserver, etc).

The new sdk and oss changed things a bit, users now see that just for .net core, but is going to be used really soon for mono/.net full users too (it's not just netstandard2.0 the big win). For example we are going to use the same msbuild, with new sdk, without modifications, in all three big players, with the same tooling code (project parsing will change a bit, and will be finally the same for VS and FSAC and XAM), finally. And that's going to help with other scenarios, like xam ios or fable, or corert.

That may impact other projects like forge too, because more tooling mean overlap, but also opportunity to offload parts of tooling, when make sense. Or opportunity to reuse or integrate existing code/tools. Tooling is more stable now, and flow/experience has really improved, so possibile gain are minor now. finally.

fstoml was the right answer to a big issue with old fsproj, but has a minor impact with new fsproj, and that's not just because xml is less verbose, but also because the tools used with new fsproj, and the flow. Recreate the flow is lot of work and feedback, and possibile friction. But we can see that only after using a bit, not everything can be seen at design time, without feedback using it.

Ihnmo fstoml project can help some scenarios, but like everything has tradeoff on usage, so we'll see feedback soon (with this milestone, is now a bit more public and easy to try). The way you integrated with current msbuild help a lot to lower the bar for adoption, and i agree with pro and cons as @alfonsogarciacaro said.

[haf]

I think we should throw all our combined weight behind bazel instead, starting here – to leapfrog the current build systems of F# and support large enterprise projects (like mine) that needs cascading builds and fast recompile times.

That way we don't have to invent another specification format and we can compile C++, C, Python, Java and so on, together with F#. The future lies in being able to use the right tool for the job; even if that's not F#, while improving F#-the-tool-for-the-job. This would be great for my project with dependencies on OpenCV, Theano, TensorFlow, libuv, openssl, Z3, etc.

[haf]

@Krzysztof-Cieslak Code with Ionide is amazing. You should absolutely not give it up. It won't die because it has too many users. Also, it has too many users who care about F#, as a cross-platform language that is unbound to a single company – otherwise that company would be dictating the terms for everybody.

[gchiaramonte]

@Krzysztof-Cieslak - I agree with @haf, please don't give up on Ionide. Why not charge for it after a trial period or for commercial usage? At least give us the option to pay you something. (I don't think open source should mean free.) Can you change the license so JetBrains can't steal your work. Just curious, but what would you want from the F# community that would make you happy to continue working on the project?

[7sharp9]

Not sure I would agree that jumping to bazel would help anything at all.

[haf]

@7sharp9 I think it would. Why don't you think so?

[7sharp9]

You can't really change the license for ionide because it itself uses oss code churned around between different repo over the years.

I think you would freeze the codebase, zero support other than send me a PR and add all new features as chargeable.

[Krzysztof-Cieslak]

Can we please focus on this project, instead of getting sidetracked by Ionide awesomeness?