Live data from Hacker News

A new F# compiler feature: graph-based type-checking

devblogs.microsoft.com

61–70 of 118 posts

Re: A new F# compiler feature: graph-based type-checking

#61

Earlier quoted context omitted.

F# is my go-to language for new backend projects and console apps. You can be as functional as you like, with imperative/mutable/OOP escape hatches available for those rare but unavoidable times you need them

for console apps, F# sadly suffers from general .NET issues for console apps. Very large size (>150MB for a simple app) and at least 400-700msec startup time

AOT compilation is actually usable in net7, and I'm told it's got much better in net8 - massively reduces startup time (and in net8 apparently binary size too)!

Re: A new F# compiler feature: graph-based type-checking

#62

Noob question. I developed projects in OCaml (ocaml + opam + merlin + core/async) on linux/macos. I'm clueless about F#, I've always thought of that as some sort of JVM for Windows, not great for Linux. How would my experience compare if I was to use F#? not so much in term of language, but developer experience: IDE integration, richness of stdlib and third-party libs, build system, package management, tools stabilit…

I only tried F# for few days, but it was a pleasant experience on both macos and linux.

dotnet CLI should take care of build process, it can even generate self-sufficient executable (that bundle parts of .NET in them). The infamous required XML boilerplate has also been cut down to near-zero.

My biggest gripe is that Microsoft's debugger is closed-source and proprietary (though free for users of official VSCode builds). There is open-source netcoredbg by Samsung, so you can use VSCod[e,ium] with https://open-vsx.org/extension/muhammad-sammy/csharp , but YMMV.

Re: A new F# compiler feature: graph-based type-checking

#63

Earlier quoted context omitted.

"Character assassination" ...? Not sure where the comment said anything about the project owner as a person. He is free to manage his project in whatever way he sees fit. And the public is free to criticize that management.

People criticizing the project management style are free to do so. But other members of the discussion are free to criticize that criticism.

But the trail never ended at "one ought not critique my critique", so who are you responding to? If anything, saying that something is character assassination is a statement on what's off-limits for debate.

Re: A new F# compiler feature: graph-based type-checking

#64

Noob question. I developed projects in OCaml (ocaml + opam + merlin + core/async) on linux/macos. I'm clueless about F#, I've always thought of that as some sort of JVM for Windows, not great for Linux. How would my experience compare if I was to use F#? not so much in term of language, but developer experience: IDE integration, richness of stdlib and third-party libs, build system, package management, tools stabilit…

JetBrains Rider is really excellent until you start getting up to like the 30-project mark. Stdlib is very extensive although has a bunch of annoying quirks due to being like twenty years old and due to having Linux retrofitted onto it; I have personally had to reimplement parts of its API from syscalls, but if performance isn't super-important for you then it's OK. MsBuild (the build system) and NuGet (the package manager) are both absolutely cursed, but if you are doing totally vanilla things then they're usable out of the box. The `dotnet` command line tools are weirdly inconsistent, sometimes buggy, and full of edge cases even in the places where they are self-consistent, but again if you're doing something super-vanilla then they should be fine.

Re: A new F# compiler feature: graph-based type-checking

#65
post #16

Great addition to a great language. We've been building a very technical product in F# + Rust for the last three years or so (think R lang + R Studio or Replit but for DSLs we built for finance and contracts). While most folks tend to see F# as a .NET-oriented/back-end kind of language, they'd be missing some incredibly unique web technologies such as the Fable compiler (F# -> JS, Python, Dart, etc) and Elmish (Elm,…

I looked at Fable and the resulting code just looked way more complicated than anything Javascript could write. I'm interested in F# still on the backend, but I don't think people "haven't discovered" Fable, it's just not a great alternative.

Is it really appreciably different from "transpilation" with TypeScript?

Like, I have seen a little of both (I've used a lot of TypeScript, but who actually looks at the output JS lol), and while I agree the JS output from Fable seemed surprisingly verbose, I'm not sure I see how it practically matters unless one is worried about bundle size or something.

Re: A new F# compiler feature: graph-based type-checking

#66

Earlier quoted context omitted.

this sounds exciting, but I wonder. How closely linked is Elmish to Elm? In theory Elm is just such a fascinating project... if it was not held back by the people developing it.

Please PLEASE enough with the character assassination of the Elm guy. He wants to run his own project his own way. There's a small but dedicated residue of people who just can't stand being told "no" and go around crapping on the kid whenever they get a chance. I get it. You don't like Evan's project management style. Move on already. - - - - The fact of the matter is that he's a person who took his thesis, made it i…

It's not "character assassination" to criticize someone.

Re: A new F# compiler feature: graph-based type-checking

#67
post #16

Great addition to a great language. We've been building a very technical product in F# + Rust for the last three years or so (think R lang + R Studio or Replit but for DSLs we built for finance and contracts). While most folks tend to see F# as a .NET-oriented/back-end kind of language, they'd be missing some incredibly unique web technologies such as the Fable compiler (F# -> JS, Python, Dart, etc) and Elmish (Elm,…

I looked at Fable and the resulting code just looked way more complicated than anything Javascript could write. I'm interested in F# still on the backend, but I don't think people "haven't discovered" Fable, it's just not a great alternative.

FWIW the benefit tends to come in the long run. Same argument as TypeScript, really. You add some conceptual overhead to get code that fails less in the face of change, better refactoring, etc.

Re: A new F# compiler feature: graph-based type-checking

#68

Earlier quoted context omitted.

F# is my go-to language for new backend projects and console apps. You can be as functional as you like, with imperative/mutable/OOP escape hatches available for those rare but unavoidable times you need them

for console apps, F# sadly suffers from general .NET issues for console apps. Very large size (>150MB for a simple app) and at least 400-700msec startup time

My CLI is 180-185ms startup time, and about 10-20MB for a complex app (with a runtime dependency).

Re: A new F# compiler feature: graph-based type-checking

#69

Noob question. I developed projects in OCaml (ocaml + opam + merlin + core/async) on linux/macos. I'm clueless about F#, I've always thought of that as some sort of JVM for Windows, not great for Linux. How would my experience compare if I was to use F#? not so much in term of language, but developer experience: IDE integration, richness of stdlib and third-party libs, build system, package management, tools stabilit…

JetBrains Rider is really excellent until you start getting up to like the 30-project mark. Stdlib is very extensive although has a bunch of annoying quirks due to being like twenty years old and due to having Linux retrofitted onto it; I have personally had to reimplement parts of its API from syscalls, but if performance isn't super-important for you then it's OK. MsBuild (the build system) and NuGet (the package m…

YMMV with the build and package system depending on your experience. Sheet staying my career writing with JVM languages and then moving to C#, I far prefer MSBuild + NuGet over Maven or Gradle. But I know lots of folks who feel the opposite, so maybe it's just a matter of preference.

Re: A new F# compiler feature: graph-based type-checking

#70

Noob question. I developed projects in OCaml (ocaml + opam + merlin + core/async) on linux/macos. I'm clueless about F#, I've always thought of that as some sort of JVM for Windows, not great for Linux. How would my experience compare if I was to use F#? not so much in term of language, but developer experience: IDE integration, richness of stdlib and third-party libs, build system, package management, tools stabilit…

JetBrains Rider is really excellent until you start getting up to like the 30-project mark. Stdlib is very extensive although has a bunch of annoying quirks due to being like twenty years old and due to having Linux retrofitted onto it; I have personally had to reimplement parts of its API from syscalls, but if performance isn't super-important for you then it's OK. MsBuild (the build system) and NuGet (the package m…

I’ve never ran into an issue with 30+ projects open though I question why one would have so many in one project in the first place personally, but I never had an issue

F# also has an alternative toolchain based around Paket[0] and Fake[1]

[0]: https://fsprojects.github.io/Paket/index.html

[1]: https://fake.build/

Post reply on HN