Live data from Hacker News

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

devblogs.microsoft.com

41–50 of 118 posts

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

#41

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…

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

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

#42

Can anyone recommend a good hard copy book for F#? One that covers the syntax, language features, and covers functional programming fundamentals along the way? Like, the F# book that Brian Kernighan would write?

Several other books that are good have been mentioned, I'll throw in one more, Stylish f# 6 by Kit Eason. He does a good job covering things and it covers features up through the .NET 6 version of F# so less stuff to learn once you're done with it.

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

#43

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…

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 team behind the work.

In other words, a bet on TypeScript is also a bet on the TypeScript team, and in my experience the TS team is very fast at their work. This makes me more forgiving of bugs. Similarly, a bet on Terraform is also a bet on Hashicorp.

Here we have someone recommending a choice of F# over Elm because betting on the leadership is allegedly not good. This is not character assassination. The commentator is not criticizing Evan on irrelevant private affairs and by extension saying that you shouldn't use Elm. Evan has created a company and is advocating for his product; he is a public figure and is being criticized on the grounds of project management.

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

#44
post #36
post #31

Earlier quoted context omitted.

It's useful to keep these anyway, as if you make a change that accidentally changes the type of some function, the error message makes it immediately obvious what you did. Otherwise it's hard to tell whether you messed up the function or the caller. Also having type annotations makes code reviews easier. Basically people's brains can use the same optimization that compilers do.

There is also a helpful compiler command to generate updated signature files for you. Then you just glance at the git changes and see if you accidentally broke an API or not.

May I plug https://github.com/G-Research/ApiSurface/ ? It ensures this as part of your testing pipeline, and requires an appropriate minor or major SemVer bump if you alter the API in a non-breaking or breaking way.

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

#45

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…

Totally agree. Even the mention of Elmish, which has nothing to do with the creator of Elm, is derailed into yet another discussion of why some people hate the creator of Elm. It is the deadest of beaten horses on HN.

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

#46

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.

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.

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

#47

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?

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 based on an external source. Source Generators are a compiler feature that analyzes C# source code, optionally with other files, emits C# source code to include back into a compilation.

https://devblogs.microsoft.com/dotnet/introducing-c-source-g...

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

#48
post #11

Earlier quoted context omitted.

I would recommend two. F# in Action [1] by Isaac Abraham is a great (and recent) introduction to the F# language. For a more philosophical, domain-oriented book, you can't go wrong with Scott Wlaschin's Domain Modeling Made Functional book[2]. Scott's blog[3] is also must-read material. [1] https://www.manning.com/books/f-sharp-in-action [2] https://pragprog.com/titles/swdddf/domain-modeling-made-func... [3] https://…

I had discovered Scott’s blog in the last couple of days while searching for resources related to writing lexers and parsers in F#. It is indeed a great resource! Thank you for your other recommendations, I’ve just ordered both books!

Enjoy your F# journey! I have yet to find a more ergonomic, practical language for daily use :)

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

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

Yeah, I suppose it depends on what you're building.

Three years of building with it (plus constant re-evaluation of that decision) has supports our conclusion that it is far more concise and easier to manage (esp for less technical folks who need to sign off on the business logic/domain) than anything we'd have done in JS.

With that said, we're building a product that requires much more interactivity than most, and we're performing a lot of typical "back-end" logic in the client - that might color our evaluation.

To be sure, it hasn't been without tradeoffs, but we haven't found those tradeoffs to be at the language level.

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

#50
post #29

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…

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

And doing this re-implementation, would in no way be a comment on the ELM founder.

Also, Doesn't Linus say "NO", quite a bit with Linux? Why jump on the ELM guy for doing same thing.

Post reply on HN