[HN Gopher] A new F# compiler feature: graph-based type-checking
___________________________________________________________________
A new F# compiler feature: graph-based type-checking
Author : soheilpro
Score : 159 points
Date : 2023-11-03 00:39 UTC (2 days ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| GiorgioG wrote:
| Great, now how about Microsoft stop treating F# like a redheaded
| stepchild? 99.999% of .NET shops will not touch it.
| owlstuffing wrote:
| Statistically, functional languages _are_ redheaded
| stepchildren.
| peheje wrote:
| While f# is definitely founded in functional paradigm. I feel
| like it's more a universal language.
|
| Like Kathleen says in her intro to f#6
|
| https://youtu.be/jOrgDoMuFog?si=Dnu8kPPi5QS5rNOR
|
| "Im gonna do cool stuff like fold this unfold that. Dom said.
| Why don't you just write code?" (Paraphrasing it's first of
| the video)
| moogly wrote:
| I'm not sure the F# community would like it if MS took more
| control of it though.
| williamcotton wrote:
| 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?
| mdm12 wrote:
| 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://fsharpforfunandprofit.com/
| williamcotton wrote:
| 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!
| mdm12 wrote:
| Enjoy your F# journey! I have yet to find a more ergonomic,
| practical language for daily use :)
| akkad33 wrote:
| I don't know Brian is, but I would recommend Expert F#, a book
| cowritten by F# creator and BDFL Don Syme
| williamcotton wrote:
| He named UNIX, he invented the "Hello, world!" program, he's
| the K in K&R (The C Programming Language), he's the K in AWK,
| and he's the co-author of other classic works like The UNIX
| Programming Environment and more recently The Go Programming
| Language. He's currently a CS professor at Princeton.
|
| EDIT: Why the downvotes? It's just terse, it's not at all
| rude.
| runevault wrote:
| 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.
| bcherny wrote:
| I was looking forward to the benchmarks. Did I miss them?
| peheje wrote:
| F# is sooo great
| owlstuffing wrote:
| Type providers are boss. Why doesn't every language type system
| have this feature by now?!
| Akronymus wrote:
| Because they are pretty annoying to implement and most are
| quite fragile
| eddythompson80 wrote:
| They are only as fragile as your type source.
| owlstuffing wrote:
| Yep, implementing one (a solid one) is hardcore. But think
| about it. Building, say, an XML or SQL type provider is a
| big deal. Doing it right requires special talent, because
| you are essentially building a transpiler to seamlessly
| interface with F#.
|
| But this is also it's greatest strength. Having direct,
| type-safe access to structured data is truly awesome. What
| else compares? Certainly not conventional code gen.
| Akronymus wrote:
| Oh, don't get me wrong: Type providers are absolutely
| fantastic. Just, they are such a complex beast, most
| implementations I used so far are pretty fragile, at
| best. But tbh, even a fragile one is surprisingly useful
| eddythompson80 wrote:
| 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.
| Smaug123 wrote:
| 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.
| eddythompson80 wrote:
| 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.
| owlstuffing wrote:
| Java has this too with the Manifold[1] project. It's mind
| blowing.
|
| 1. https://github.com/manifold-systems/manifold
| eddythompson80 wrote:
| woah, I had no idea. That seems pretty cool
| PartiallyTyped wrote:
| SQLX has entered the chat [1].
|
| [1] https://github.com/launchbadge/sqlx
| owlstuffing wrote:
| 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...
| CharlieDigital wrote:
| Couldn't these also be done in C# via source generators?
| AlexErrant wrote:
| 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...
| CharlieDigital wrote:
| 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
| AlexErrant wrote:
| Ah, okay I thought that source generators had more
| limitations compared to F#. Turns out they can make
| arbitrary calls, including across a network, which
| previously I thought was only in the domain of type
| providers:
|
| > For Schema.NET, we do a HTTP request to get the JSON we
| need to build
|
| https://turnerj.com/blog/the-pain-points-of-csharp-
| source-ge...
|
| Also phillipcarter says yes so I'll happily take his view
| over mine.
| phillipcarter wrote:
| 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.
| PartiallyTyped wrote:
| It's available to some in extend in rust, e.g. SQLX [1]
| allows you to typecheck queries.
|
| [1] https://github.com/launchbadge/sqlx
| anonzzzies wrote:
| 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.
| arrow7000 wrote:
| 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
| FrustratedMonky wrote:
| 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#.
| eddythompson80 wrote:
| 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
| Smaug123 wrote:
| 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)!
| eddythompson80 wrote:
| Interesting. I never upgraded to 7, been waiting to try 8
| when it's out. Might give the beta a try
| Dayshine wrote:
| My CLI is 180-185ms startup time, and about 10-20MB for a
| complex app (with a runtime dependency).
| eddythompson80 wrote:
| keyword: with a runtime dependency :)
|
| For CLIs I much prefer self-contained build outputs which
| is quite huge when it comes to .NET unfortunately.
| Keats wrote:
| Is it easy to develop in it without using Windows?
| JaggerJo wrote:
| Btw. building GUI apps is super simple in F#.
|
| (mac, linux, windows, ios, android, web)
|
| https://github.com/fsprojects/Avalonia.FuncUI
| peheje wrote:
| Also Fable is pretty cool https://fable.io/
|
| Here build times are not really an issue as it seems to be hot-
| transpiling to js, so save and site is reloaded almost instant
| (at least small sites):
|
| My small tools site built with Fable:
| https://peheje.github.io/compare.html
|
| If you look at the JS - that's of-course the production
| minimized build, the transpiled JS is pretty nice and readable.
|
| Super simple site - vanilla JS seems wonderfully easy with F#,
| easy to hide its warts and build easy re-usable items.
|
| But there's of course also smarter stuff with two-way bindings
| via html annotation and builders etc. I am actually using
| Feliz.ViewEngine, which is building the HTML using F#, but only
| for the navigation bar. Might try converting a page to it.
| mumblemumble wrote:
| I did a project using Avalonia.FuncUI a few years ago, and
| would highly recommend it. It made GUI development fun again.
| twunde wrote:
| This is the type of feature that makes me want to use F#. Really
| great work, I would love to see similar work replicated in other
| languages (python's type checking libs especially). As an
| outsider it feels like the Bazel/Buck/Pants approach applied to
| type checking
| phillipcarter wrote:
| This is very neat, I love the idea of using the syntax tree to
| guide what can be parallelized vs. not.
|
| As some additional background, there's a very good reason why the
| F# language typechecks files sequentially. Because F# supports
| type inference at every scope, a single change in the body of a
| function can result in cascading type changes across an entire
| project. This kind of change can not only affect other files, but
| other files inside of other projects in the same solution.
|
| A way to curb these kinds of cascading changes is explicit type
| annotations and/or signature files, which "lock" the type
| signature for a given construct/file. And the F# compiler has had
| optimizations in place when signature files are used to know when
| to re-check stuff based on this. However, these didn't extend to
| the sequential typechecking of files, and for the large majority
| of codebases that don't use signature files, these optimizations
| didn't really kick in anyways.
| jeremyjh wrote:
| That's interesting. In Haskell top-level annotations are not
| required but I don't think I've ever seen a real project
| without them - its basically a community standard that's
| universally adopted, in a community that doesn't adopt many
| standards.
| daxfohl wrote:
| 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.
| piaste wrote:
| 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.
| Smaug123 wrote:
| 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.
| obeavs wrote:
| 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, but for F# with a JS target via Fable). It
| boggles my mind that more of the web dev community haven't
| discovered these tools.
|
| These "communities" fall completely outside of MSFT's umbrella,
| but are transformative for how you think about architecting
| applications: Elm as an architecture (rather than as a language)
| enables a large amount of optionality in terms of what
| technologies one might use as a "reactivity layer" (e.g. can swap
| out React for SolidJS or even non-JS targets like Avalonia quite
| easily if it made sense to).
|
| Our bet is that it enables us to future proof things in a number
| of unique ways as better WASM-based solutions come online as well
| that hopefully won't require shipping the whole .NET runtime
| (e.g. Bolero). The approach is also v helpful in managing state
| across an otherwise very complex application.
| DarkNova6 wrote:
| 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.
| arrow7000 wrote:
| It's not linked at all, it just uses "The Elm Architecture"
| as inspiration to recreate the same architecture in F#
| carapace wrote:
| 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 into a product, and got traction in the real
| world. People have used Elm to make things. Things that go.
|
| How many of us can say the same?
|
| And that's before you get to all the fascinating and as yet
| still-too-obscure things that the OP talks about. Things that
| are in part a little more widely known and understood thanks
| to Elm project.
| jurynulifcation wrote:
| 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 don't want to collaborate, who
| want to take their ball and tell others how to play with
| it, really putting the 'dictator' in BDFL." and you know
| what? that's fine. I don't harbor anything against them as
| people. But that left a permanently bad taste in my mouth
| and I'm unlikely to ever trust that group or a project
| they're managing.
| carapace wrote:
| FWIW my comment was along the lines of allergic reaction.
| I'm not an Elm fanatic, I'm just sick of seeing people
| snipe on the dude.
|
| You're entitled to your opinion, of course, and you
| articulated it well. But again I see it as another
| example of someone not liking being told "no", no?
| ObscureScience wrote:
| My understanding of this is that he managed to hype the
| language with certain killer features. A lot of people
| were enthusiastic and invested alot of time in learning
| and building in it. Evan than "suddenly" said they wanted
| to take the language in another direction and dropped
| some of the core features and pricipals that drew people
| in. While perhaps a mischaracterization, it comes a cross
| as a kind of "bait and switch" or at least undependable.
| jurynulifcation wrote:
| That's really reductive and biased against us, the
| potential user base of Elm that decided not to engage.
| Why is it that we don't like being told "no," as opposed
| to the Elm leadership and Elm community not liking being
| told "this isn't a 100% solution for me so I'd like to
| modify it"?
|
| Obviously Elm is his passion project, that's fine. But
| nobody who locks down their compiler on a supposedly
| "open source" project can actually seriously expect
| others to engage with that in good faith.
|
| Furthermore, the absolute state of just trying to modify
| Elm to be more fit for purpose is horrendous. Every time
| I see a parallel implementation or a fork, the author has
| to bend over backward with platitudes to placate the Elm
| masses and ensure them that this project isn't trying to
| "split the community," which is a nonsense idea to start
| with imo.
|
| It feels cultish, on top of a project that is actively
| hostile to people who want to use it any way other than
| how the BDFL has mandated its usage. If you want to say
| the problem is with the users, that's fine, but that's
| exactly the attitude keeping me from ever engaging. I
| personally think the problem is with the people who want
| such fine control over their technology and community, as
| opposed to understanding that they can really only
| shepherd their implementation. That's about as far as
| their reach rightfully extends.
|
| EDIT: also, the fact that they aggressively lock down
| their compiler and have such hostility to anyone working
| in parallel is imo the definition of "holding it back"
| G4BB3R wrote:
| 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.
| jurynulifcation wrote:
| 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.
| FrustratedMonky wrote:
| 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.
| threatofrain wrote:
| 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.
| jurynulifcation wrote:
| 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.
| wavemode wrote:
| "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.
| bee_rider wrote:
| People criticizing the project management style are free
| to do so. But other members of the discussion are free to
| criticize that criticism.
| threatofrain wrote:
| 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.
| wavemode wrote:
| 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.
| threatofrain wrote:
| 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.
| G4BB3R wrote:
| 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
| SantalBlush wrote:
| 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.
| DarkNova6 wrote:
| 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.
| catlover76 wrote:
| It's not "character assassination" to criticize someone.
| obeavs wrote:
| Some references if helpful:
|
| * Elmish (F#) repo - https://github.com/elmish/elmish
|
| * The Elmish Book (... remarkably good) - https://zaid-
| ajaj.github.io/the-elmish-book/#/
|
| * Fable compiler - https://fable.io/
|
| The F# community is very friendly (sub-communities as well),
| and there are plenty of good opportunities to contribute OSS
| work across any skill level.
|
| Phosphor isn't hiring right now, but we will begin a search
| for FE/interface engineers soon. oliver@phosphor.co for
| anyone interested.
| aranchelk wrote:
| > 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.
| Capricorn2481 wrote:
| 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.
| obeavs wrote:
| 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.
| durable_queue wrote:
| The generated JS is only somewhat readable, but you're not
| supposed to be reading the F#.
| Capricorn2481 wrote:
| I'm not supposed to read the F#?? Someone should tell the
| Fable guys
| catlover76 wrote:
| 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.
| Capricorn2481 wrote:
| 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.
| catlover76 wrote:
| Oh, I see. You said "resulting code", that's why I
| thought otherwise.
| Capricorn2481 wrote:
| My mistake!
| phillipcarter wrote:
| 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.
| aeonik wrote:
| 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.
|
| More context: Idris2 allows for first class type-driven
| development, where the types are passed around and used to
| formally specify program behavior, even down to the value of a
| particular definition.
|
| 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?
|
| Also related, is this similar to how HVM works with their
| "Interaction nets"?
|
| https://github.com/HigherOrderCO/HVM
|
| https://www.idris-lang.org/
|
| https://clojure.org/
|
| I'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.
| Arelius wrote:
| > 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
| yodsanklai wrote:
| 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.
| pzmarzly wrote:
| 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.
| Smaug123 wrote:
| 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.
| rpeden wrote:
| 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.
| no_wizard wrote:
| 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/
| phillipcarter wrote:
| 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.
| bmitc wrote:
| 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.
| IshKebab wrote:
| 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.
| fyzix wrote:
| 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
| devmunchies wrote:
| It would be nice if I stopped needing to update the fsproj file
| for imports and hierarchy. If this could be dynamically built
| using a topological graph approach that would be a huge
| improvement. I don't use a heavy IDE so it's kinda tedious to
| need to update the fsproj file when i want to add a new file.
| Smaug123 wrote:
| Personally I strongly prefer F#'s way, and I always enable it
| manually in C# by setting `<EnableDefaultCompileItems>` to
| `false`. It's _so much easier_ to debug e.g. compiler
| deficiencies /bugs when you can just binary chop to find the
| file that's causing a problem, and the reason you can do this
| is the linear ordering of explicitly listed files. (In C# I
| generally just give up and hope that someone else will do it,
| because it takes so much longer; in F# it's trivial.)
|
| What are you using as your development environment? Personally
| I don't find the overhead in Vim to be too onerous
| (`yypf"ci"NewFile.fs`), and even in Rider I routinely edit
| fsproj files manually. (I even create new projects mostly by
| hand.)
___________________________________________________________________
(page generated 2023-11-05 23:01 UTC)