Live data from Hacker News

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

devblogs.microsoft.com

51–60 of 118 posts

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

#51

F# is so good, such a shame so few companies use it. I have to touch C# and it's always a little bit painful after a few weeks of F# work.

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

Have to agree. Recently decided to try out Python instead. Everyone at work wanted Python, it's popular, so why not give it a shot. In constant regret, missing the type checking in F#.

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

#52
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,…

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.

> In theory Elm is just such a fascinating project... if it was not held back by the people developing it.

PureScript may be worth a look, it’s got several features that were rejected by Elm devs: typeclasses, ability to publish modules that use FFI to JS, runs server-side, etc.

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

#53

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…

He's absolutely entitled in running his project his own way. As such, it is obvious that adoption outside of his own circle is to remain minimal.

I would love Elm to be in a position where I could advocate for it at work (aside from it being a "neat hobby"). However, the simple fact is that the way Elm is run has lead to disillusionment among advocates of the first hour. And there is nothing to indicate that this will change.

And if the guy has inspired a new generation to create something to his own achievement, kudos to him. As far as I'm concerned Elm is not the enemy, JavaScript is the enemy.

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

#54

Earlier quoted context omitted.

Couldn't these also be done in C# via source generators?

No. > How do Source Generators compare with Type Providers in F#? > If you’re an F# programmer (or familiar with the language), then you might have heard of Type Providers. Source Generators were inspired in part by Type Providers, but there are several differences that make them distinct. The main difference is that Type Providers are a part of the F# language proper and emit types, properties, and methods in-memory…

I get that the mechanisms are different, but the end result is the same.

Edit: sample here with a JSON template: https://github.com/CharlieDigital/dn7-source-generators

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

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

The generated JS is only somewhat readable, but you're not supposed to be reading the F#.

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

#56

F# is so good, such a shame so few companies use it. I have to touch C# and it's always a little bit painful after a few weeks of F# work.

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

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

#57
post #29

Earlier quoted context omitted.

Eh, it doesn't seem like character assassination. Dude chose his management style. That makes his project unfit for purpose for certain people. Those people are allowed to make that determination and state as such. I remember when the Elm team first decided to lock down the Elm compiler, so that only the team in charge had special privileged access to modify it. I thought, "wow, this looks like a bunch of people who…

From outside, with no knowledge of this "ELM Controversy", this is all very confusing. I love the ELM Architecture. Why is there a problem if it is implemented in another language? I'd think any functional language could implement the ELM Architecture, and thus be 'native', or more integrated into that particular languages ecosystem, and this would offer benefits beyond trying to integrate ELM into each individual ec…

The link is that Elmish is a competitor of Elm, and that the creator of Elm is a factor to the evolution of Elm. Leadership is a big deal in open source and is the sole differentiator behind the late iojs and OpenTofu. The matter of leadership is especially weighty for niche or emerging ecosystems like Clojure, Rust, or SolidJS.

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

#58
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 stability.

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

#59

Earlier quoted context omitted.

I got downvoted on the typescript subreddit when I mentioned how Type providers work in F# because "nah, it can't be working that way. The compiler can't be making http requests to make up types for an API" smh.

In fairness it is rather terrifying :P personally I pull all necessary information into some form of version-controlled storage, and then have a test to assert that the remote information is consistent with the stored version. Life's too short to have nondeterministic builds.

yeah that's fair. That's what I landed on too, and would think anyone using it seriously would be doing the same. But the fact that you could extend the compiler to program your own code generation in F# itself is amazing. Comptime in Zig reminds me of this too. I'd have to think OCaml has something similar, but I'm not too familiar with it.

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

#60

Earlier quoted context omitted.

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…

"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.
Post reply on HN