Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

71–80 of 118 posts

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

#71

Post by [deleted] »

Smaug123 wrote: post #64
yodsanklai wrote: post #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 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…

[deleted]

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

#72

Post by phillipcarter »

CharlieDigital wrote: post #40
owlstuffing wrote: post #9

Earlier quoted context omitted.

Type providers are boss. Why doesn’t every language type system have this feature by now?!

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

Yes. The mechanisms are very different of course, but both the F# and C# components involved generate types with properties, methods, etc. that can populate IntelliSense.

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

#73

Post by _svoh »

G4BB3R wrote: post #39
_svoh wrote: 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…

Without this management style Elm would be the oppositive of what it is today (simple language, very fast compiler, efficient tree shaking, no runtime exceptions) wanting to add at all costs Haskell features and JS direct sync interop.

I simply don't think locking down the compiler so only blessed Elm devs can modify internals was necessary. I don't think the flack given to people forking the repo was necessary. Say no to pull requests, fine. Don't try to control the technology.

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

#74

Post by _svoh »

FrustratedMonky wrote: post #50
_svoh wrote: 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…

When Linus says no, he rejects features and pull requests. That's fine. That's responsibly shepherding your implementation.

That's not what Elm does. They lock down the compiler so only Elm devs can modify internals, which would be equivalent to Linus trying to prevent people from modifying the kernel.

They really don't like people forking their repo, which would be equivalent to Linus getting mad at people making derivative kernels (because it would "split the community.")

It's not just a matter of saying "no," it's trying to control what devs do to an UNREASONABLE degree.

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

#75

Post by Arelius »

aeonik wrote: post #37

I have a tangential question that is related to this cool new feature. Warning: the question I ask comes from a part of my brain that is currently melted due to heavy thinking. Context: I write a fair amount of Clojure, and in Lisps the code itself is a tree. Just like this F# parallel graph type-checker. In Lisps, one would use Macros to perform compile-time computation to accomplish something like this, I think. Mo…

> Given that this F# feature enables parallel analysis, wouldn't it make sense to do all of our development in a Lisp-like Trie structure where the types are simply part of the program itself, like in Idris2?

Yeah, maybe, you for sure could, but in the context of F# as it exists, it may be hard to get from here to there.

> 'm afraid I don't even understand what the difference between code, data, and types are anymore... it used to make sense, but these new languages have dissolved those boundaries in my mind, and I am not sure how to build it back up again.

Yeah, good luck with that. I think maybe taking a mental step away from programing might help. It's true that human interpretation of the world often has these properties. And he generalization of the systems in no way invalidate the usefulness of the categorization system. Maybe it's helpfulnto consider the properties of your classes.

To risk your further descent into madness. I recommend the Lambda days talk on the Verse programming language [1]. Which has further contemplation on the topics you are thinking about. With an eye towards practicality.

[1]: https://youtu.be/OJv8rFap0Nw?si=XvUoBqO7IeCLIbrn

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

#76

Post by phillipcarter »

no_wizard wrote: post #70
Smaug123 wrote: post #64

Earlier quoted context omitted.

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/

FWIW I don't think there's much reason to use paket and FAKE these days. FAKE just shells out to msbuild (and usually via dotnet) and it's pretty easy to use targets/props files if you want to factor a few things out of project files. Although even that is of minimal benefit. Paket is still different, but it's not 2016 anymore. The default nuget client is stable and fast. IMO these tools served the community well for a decade or so, but it's not worth bringing into a new project.

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

#77

Post by G4BB3R »

threatofrain wrote: post #43
carapace wrote: post #25

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…

We should be open & honest in our discussions about whether we genuinely recommend a platform or project to others, including the details which underlies our thoughts. As I go through rewrites and greenfield projects and so forth, I begin to realize that for any particular technology you are not simply having a relationship with a static list of pros and cons, but you're also having a living relationship with the tea…

This is not only about leadership style, but also founding. I don't know the current TS team, but I know its dozens of full time workers backed by microsoft, not only core devs, but community organizers, evangelists, etc. There is no comparison to an independent project.

Evan recently gave a talk about it on strange loop. https://www.youtube.com/watch?v=XZ3w_jec1v8

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

#78

Post by Capricorn2481 »

catlover76 wrote: post #65
Capricorn2481 wrote: post #38

Earlier quoted context omitted.

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.

I'm not talking about that JS output, I mean the F# itself. While I'm not the most familiar with F#, I've enjoyed other languages that transpile to JS a lot more.

For whatever reason, F# to me looks surprisingly verbose in Fable, which is odd because it's pretty terse on the backend.

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

#79

Post by Capricorn2481 »

durable_queue wrote: post #55
Capricorn2481 wrote: post #38

Earlier quoted context omitted.

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

I'm not supposed to read the F#?? Someone should tell the Fable guys

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

#80

Post by catlover76 »

Capricorn2481 wrote: post #78
catlover76 wrote: post #65

Earlier quoted context omitted.

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.

I'm not talking about that JS output, I mean the F# itself. While I'm not the most familiar with F#, I've enjoyed other languages that transpile to JS a lot more. For whatever reason, F# to me looks surprisingly verbose in Fable, which is odd because it's pretty terse on the backend.

Oh, I see. You said "resulting code", that's why I thought otherwise.
Post reply on HN