71–80 of 424 posts
I want to ask a weird question. I'd love to learn ASP.net but i can't bring myself to deal with Microsoft Windows and their tech. Is F# a way for me to learn enough NET to make some money?
I have a few questions. Can it do GUIs well? How about mobile? And how does it compare to e.g. Scala?
For F# , you need some basic C# knowledge For Clojure, you need some basic Java knowledge For Elixir, you need some basic Erlang knowledge
I like all 3 languages but usually each vm have a primary language, and each hosted language eventually become hosted on that primary language not the vm
I understand that for many task simple, to medium complexity, you might not need that, but it seem as you try to be more advanced you hit the wall of having to learn you host vm primary language
Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable. There are a few drawbacks, depending on your perspective: - compilation is slow…
How does the typing system work for F#? From the article, it looks like it's mostly dynamically typed. Or is it inferred? Or is it something else? Like, if I write let hello value = print value hello "world" hello 2 Does that just work? To me, that'd be a point that might steer me away from the language. Deducible types seem vital to larger and long lived projects.
Given
let hello value =
printfn "%A" value
hello "world"
hello 2
Earlier quoted context omitted.
Curried functions combined with that magnificent pipe operator, overlaid on the .NET runtime. Don Syme et al knocked it out of the park. It's the one programming language that changed how I think about programming. I'm only talking about the version before type providers. Then it got messy. Before that, we could (and I did) recompile fsi.exe to do some custom prompt manipulation. It was a slog, but it worked, but the…
F# is up to version 9 now, and has only improved over time, IMHO. Type providers are a very small part of the story and can be avoided entirely if you want.
If you've had C# and F# co-exist in the same codebase, how do they co-exist? Is it like C# and VB.Net where a project (dll) is either C# or VB.Net, and they can reference each other? Or: Is it more like the Swift / Objective C ecosystem where Swift, Objective C, and even straight C can co-exist in the same library? In a mixed C# and F# codebase, generally when do you favor C# versus F#? Coming from a C# background, w…
When mixing, you often write business logic as self-contained F# libraries with a C#-friendly API; and use C# to integrate them with whatever imperative, reflection-heavy and DI-heavy frameworks .NET is promoting the current year, since those are filled with interop edge cases for F# anyway.
You really want to avoid a language sandwich though (e.g. C#/F#/C#), because you'll keep wishing to remove the middle layer. Sadly, the addition of source generators make this mistake even more appealing.
Earlier quoted context omitted.
The funny thing is that you can write very similar code in C#, so maybe you don't need to switch which language you're using as a CLR frontend. using System.Linq; using System; var names = new string[] {"Peter", "Julia", "Xi" }; names.Select(name => $"Hello, {name}").ToList().ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#")); LINQ is such a good library that I miss it in other languages. The Java s…
You can write a vast majority of your C# codebase in a functional style if you prefer to. All the good stuff has been pirated from F# land by now: First-class functions, pattern matching, expression-bodied members, async functional composition, records, immutable collections, optional types, etc.
Maybe that's just research, and I'm glad that Microsoft hasn't killed F# (I do work there, but I don't write F# at work.)
Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable. There are a few drawbacks, depending on your perspective: - compilation is slow…
How does the typing system work for F#? From the article, it looks like it's mostly dynamically typed. Or is it inferred? Or is it something else? Like, if I write let hello value = print value hello "world" hello 2 Does that just work? To me, that'd be a point that might steer me away from the language. Deducible types seem vital to larger and long lived projects.
With regards to your example, the print/printfn (equivalent of Write/WriteLine) functions are a bit funny in F#. They don't actually take bound string values directly. You need to specify the type (which could be a string, a number, obj, etc)
https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable. There are a few drawbacks, depending on your perspective: - compilation is slow…
As a proficient Elm developer with industry experience, I’m wondering what are the biggest challenges in hiring devs? Is it the paradigm, learning the ecosystem, lack of interest? Are you currently hiring?
I certainly wish I were doing f# professionally, but I only ever found 1 job listing for it, and that was in vienna while I am located like 200km away from it :(
Speaking of elm: I really like elmish for the frontend, when I need to make a dynamic page in the first place. Maybe that could be to your interest? (It transpiles to react under the hood via fable, which you can webpack into a drop in bundle. But I digress)
I learned F# in 2013 and had a lot of fun with it, some of that code remains on Github (e.g. a 2D platformer game for windows https://github.com/lihaoyi/FSharpMetro/tree/master/Applicati... ). My experience was that it was a surprisingly nice language with a surprisingly warty user experience: papercuts ranging from naming conventions and function call styles (`|> List.map` vs `.Select`), basic syntax (`foo.[0]` to l…
Interesting - I'm curious where your thoughts are now on using FP/Scala in 2025? I've always looked at F# with envy as it is a hosted ML that will have extremely battle tested bindings to the important day to day stuff via C# (Darklang's stories of struggling with postgres and AWS when using OCaml was a good cautionary tale on the risks of using less common langs as a startup) Never had a chance to try out Scala but…
- Typelevel libraries: modern and more welcoming take on ScalaZ ideas, rich and mature, extensible libraries that are written in "tagless final" style.
- ZIO: concrete "super monad" with 3 type parameters, shuns the Haskell baggage and category theory lingo but pretty much the same concepts, compile-time autowiring dependency injection, a bit less mature.
- Kyo: new effects system on the block, pushing Scala 3's type system to the limit to stack effects using an "auto-flattening" monad (sorry if I butchered the description).
- Li Haoyi's own ecosystem that sticks to the standard library and JVM built-in mechanisms whenever possible, focused on Python style expressiveness, only more functional and with stronger types.
- I'd skip Akka/Pekko libraries but it's still an interesting piece of software if you need actor based, stateful cluster sharding.
Martin Odersky and the LAMP are focused on "capabilities" and we should eventually see something like direct-style algebraic effects, or like Kyo but without monads.
Also we have much better build systems than before (Scala-CLI, Mill, sbt has improved a lot too), binary backwards compatibility since Scala 3, and a very capable LSP backend if you don't like IntelliJ IDEA.