HN user
It also solves a more subtle problem - when people install a tool globally they install latest _at that time_. But the world doesn't stand still, and things get updated. `dnx` always uses the latest available version by default (you can of course pin with `dnx <package>@<version>`) so that you never get out of date.
Hi, I'm the maintainer for the VSCode F# support. Rider support for F# is great, that team is very engaged, and I'd strongly consider it if
* you have mixed C#/F# projects in a solution (C# and F# support in VSCode can't communicate today)
* you use Rider for other technology
* you want paid support for your editor tools
* you prefer IDE-style experiences rather than editor/ extension-style experiences
* you want to take advantage of Rider features like their accelerated build caching
Capturing these guidelines is one of the primary reasons that https://clig.dev/ exists.
They've worked for several years now on dotnet, but the type provider author has to do some work to allow their type provider to compile and target that runtime.
We've been baking this functionality directly into the .NET SDK for a couple releases now: https://github.com/dotnet/sdk-container-builds
It's really nice to derive mostly-complete container images from information your build system already has available, and the speed/UX benefits are great too!
Assuming you're talking about FsAutoComplete and this was recently, that's nothing to do with the .NET Runtime and entirely a coding mistake that I made that we've released a fix for :)
There is some benefit to building inside a container - it keeps your build environment consistent across team members and makes it easier to replicate your CI.
Having said that, because the .Net toolchain is capable of cross-targeting this feature should enable broad swaths of users to not need to build inside a container to get a container created. So I completely agree with your puzzlement here and would hope that this feature leads to a reduction in that particular pattern.
You make great points about the need for customization and the boundaries of solutions that aren't based on Dockerfiles. Our approach to that problem is twofold, though both parts are still only in the planning stage:
* eventually providing an 'eject' mechanism to create the matching Dockerfile for a given project. this serves as a basis for any customization you might need, as well as a base language that many existing tools can understand.
* making it easy to include arbitrary image layers by reference in your container through a syntax like `<ContainerLayer Include="<layer SHA ref>" />`. This makes it easy to grab already-built components and inject them into your build.
I entirely agree with your summary. More choices, but all built on the same standard foundation :)
IMO running a managed runtime like .NET inside a container isn't done as a security measure (like sandboxing) - instead it's done for uniformity and ease of deployment to the infinite number of cloud services/hosting providers that understand containers. Making it easy to make containers for .NET applications means that it's easy to go to any hosting model of your choice, instead of waiting for $NEXT_BIG_CLOUD to provide .NET-runtime runners for their bespoke service.
Mainly what I was getting at here is that there are often repo-level files that are part of the .NET build process that are easy to forget to include in your build context/as part of the initial COPY command that most folks to do to a package restore before build to take advantage of Dockerfile layer caching. Right now as a user you have to be aware of the repo/file layouts and get your build contexts right if you build inside of a multi-stage Dockerfile.
IMO for a significant part of the user base there's no reason to have to manage that at all - .NET is capable of cross-targeting enough to not need to perform the build inside of a container. That keeps the user in the 'build context' that they are used to, and we can use all of that context to still end up at the ideal result - a correct container, with all of their app dependencies.
Hey folks - author here, happy to answer any questions about the feature or what we're hoping to do with it.
Broadly we just want to lower barriers to containerization for all .NET developers. Jib/Ko/etc are proven patterns in this field, and we saw an opportunity to use the existing infrastructure of MSBuild to reduce the amount of concepts our users would need to know in order to be successful in their journey to the cloud. On top of that, having the feature in SDK provides some opportunities to help users adhere to conventions around container labeling (or customize container metadata entirely!) so we can make .NET containers good citizens in the container ecosystem overall.
This is similar in aim to FSharp.Formatting[1], which has been used for a while to generate syntax highlighting and hover tooltips for code samples and API docs in the F# ecosystem. Very cool to see!
In F# we call it 'collect' instead, partially for this reason.
Nitpick here = the `Load` member takes a path to _any_ file of the same schema as the sample, but you can also just use the sample at runtime with the use of `Load()`. So it doesn't have to be as redundant as you've shown here, the flexibility is all about loading other instances of the same data shape.
Yeah, there are four standout features for me in this release:
* resumable code for computation expressions - zero-overhead, ergonomic state machines that are user-extensible! really excited to see what folks dream up with this.
* overloading computation expressions members - another great enhancement for using CE's for task-specific DSLs
* enhancements to debugging to make stepping through pipelines muuuuuuch friendlier
* relaxing the indentation rules to make them much more natural for a whole host of expressions
just really solid, feel-good features in this release. Let's keep 'em coming!
I wouldn't do this, as this is the mono bundle of fsharp. The blessed/supported way to go now is to install the dotnet-sdk packages[1] and then use `dotnet fsi` for interactive work, and `dotnet build/run/etc` for project-based work in F#.
1: https://docs.microsoft.com/en-us/dotnet/core/install/linux-d...
Please use the appropriate name for the person in question. Claire is her name.
I'm not at all sure what you mean by 'typescript docs' in your comment. The protocol for things like tooltips/signature completion literally just says 'put arbitrary markdown here'. It doesn't proscribe the structure of the text the LSP author decides to use.
There are also many different display/view methods that more sophisticated LSP implementations can implement. In my own LSP, we have different 'views' of the signatures/types/docs for
* hovers * signature completion * detailed type-level embedded docs in a separate pane
to name a few. It's entirely customizable.
That's simply not true; there are LSP client implementations/integrations for vim, neovim, emacs, sublime text, web environments like gitpod.io, Eclipse IDE (via Theia IDE), Jetbrains supports it in their IDEs, and Visual Studio even has some level of support for it.
LSP is _the_ way to write IDE integrations in the modern era.
(I maintain LSP tooling for F# and actively support at least half of the editors above)
Worth noting that snap installs aren't supported in the vscode tooling for F#. There's an open issue and I have a handle on some of the core problems, but they invalidate a ton of assumptions we have.
The safer route is to install the non-snap-based versions.
(I maintain this tooling, for what it's worth)
Yes, and the F# library for asynchronous sequence processing had support added for them shortly thereafter (https://fsprojects.github.io/FSharp.Control.AsyncSeq/library...)
For clarity, the position is that large features like TC/HKT won't be added in a way that could conflict with a later-added .net/IL version of the feature.
A big push in .net core 2.x and 3.x was what we call the Span-ification of the base class library and the runtime. This means there are many new APIs for dealing with slices of memory in a non-allocating manner, and this combined with memory pooling has contributed greatly to an overall performance boost to the runtime by reducing copying and GC time. These same APIs are available to the developer so I'd imagine that it would be simple to build a non allocating network buffer reader. I have built a non-allocating video renderer before using the new APIs, for example.
You can choose to do a self-contained deployment, which bundles the runtime with your app, or a framework-dependent deployment, which requires a pre-existing shared install. Pick your poison.
I'd say more like Elm's Pheonix LiveView, to be honest.
on the free plan it caps at 100GB of total stored logs, which then rotate out. It's great if you don't care about super-old logs.
This is silly, F# has never been more of a first-class citizen. It's explicitly part of the .net core distributions, part of the nightly testing and validation cycles, and is in the TechEmpower benchmarks.
For my money your type provider was the single coolest one I've seen before. The ahead of time query execution and planning is a killer feature, and for us the only gaps were either process related, meaning we did not have a good out-of-band migration pipeline, or some constructs that were not understood by your type provider.
Yes, that's the case. However there's also the 'merge this when the build successfully completes' that means you can push one button and walk away. They are also developing features around MRs that 'ripple' in this way, so that when you have several going the rest will continue rebasing+building until they either fail the build (due to changes that are no longer correct), can't be rebased (due to a need for conflict resolution), or finally merge successfully.
Right now I have a one button rebase operation in gitlab, and if that does work (due to conflicts) then I'm at a situation I want to be in: verifying that my changes integrate cleanly.