A new F# compiler feature: graph-based type-checking • Hacker News Board

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

#91

Post by wavemode » Sun, Nov 05, 2023, 8:50 PM UTC

bee_rider wrote: post #60

wavemode wrote: post #41

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.

Never said that they weren't. I agree with you that they are also free.

But that doesn't change the fact that calling it "character assassination" is hyperbolic.

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

#92

Post by PartiallyTyped » Sun, Nov 05, 2023, 9:05 PM UTC

eddythompson80 wrote: post #32

owlstuffing wrote: post #9

Earlier quoted context omitted.

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

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.

SQLX has entered the chat [1].

[1] https://github.com/launchbadge/sqlx

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

#93

Post by PartiallyTyped » Sun, Nov 05, 2023, 9:06 PM UTC

owlstuffing wrote: post #9

peheje wrote: post #5

F# is sooo great

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

It's available to some in extend in rust, e.g. SQLX [1] allows you to typecheck queries.

[1] https://github.com/launchbadge/sqlx

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

#94

Post by bmitc » Sun, Nov 05, 2023, 9:14 PM UTC

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…

F# is very cross-platform at this point because .NET 7 is very cross-platform. To install F# just install the .NET SDK. JetBrains Rider and VS Code with Ionide are the two cross-platform IDEs.

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

#95

Post by Keats » Sun, Nov 05, 2023, 9:25 PM UTC

anonzzzies wrote: post #7

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.

Is it easy to develop in it without using Windows?

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

#96

Post by IshKebab » Sun, Nov 05, 2023, 9:26 PM UTC

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…

I haven't used F#, but I have had to build OCaml programs from source on Linux and my god OPAM is the worst thing since Autotools. Maybe worse - Autotools actually works!

OPAM - despite the appearance of a modern language management tool - seems to fuck things up almost every time I use it. And not just me. The amount of time I was spending helping coworkers fight it got so much I gave up and just added a caching system so they wouldn't have to deal with the pain of OCaml at all.

So if F# manages to improve on that even slightly I'd say it's definitely worth switching to!

Plus it's more portable than OCaml, which seems to view working on the most popular desktop OS in the world as beneath it.

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

#97

Post by fyzix » Sun, Nov 05, 2023, 9:37 PM UTC

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…

I primarily use F# on linux and the experience is very smooth.

editor: VSCode + ionide extension

stdlib: F# has its own stdlib but it can also access all of dotnet's stdlib seemlessly.

libs: Many of the 3rd party libs are written in C# in an OOP style but you can still use them. Most of the popluar ones have functional F# wrappers if you don't like OOP.

build: the dotnet cli is very advanced and not too hard to grok.

pkg: You can use nuget but most F# devs use paket

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

#98

Post by owlstuffing » Sun, Nov 05, 2023, 10:11 PM UTC

PartiallyTyped wrote: post #92

eddythompson80 wrote: post #32

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.

SQLX has entered the chat [1]. [1] https://github.com/launchbadge/sqlx

Nice.

Java has what looks like SQLx on steroids with the manifold project coming down the pike.

https://github.com/manifold-systems/manifold/blob/master/man...

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

#99

Post by eddythompson80 » Sun, Nov 05, 2023, 10:38 PM UTC

Smaug123 wrote: post #61

eddythompson80 wrote: post #56

Earlier quoted context omitted.

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)!

Interesting. I never upgraded to 7, been waiting to try 8 when it’s out. Might give the beta a try

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

#100

Post by hajile » Sun, Nov 05, 2023, 11:20 PM UTC

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.

Because of that management style, it has been bitrotting for FOUR YEARS and has even gotten forked by a couple people involved so at least some progress could continue.