Having used and enjoyed F#, I ended up programming in Scala which is almost the same language, despite the huge superficial differences:
- Indentation delimited blocks vs curlies
- CLR vs JVM
- Whitespace vs Parenthesis for function calls
- Currying by default vs currying optional
Despite all this, when you actually start coding, it's remarkably the same:
- Immutability by default, transformations rather than mutation
- Less classes with embedded implementation logic, more "dumb" records with external functions
- Structural pattern matching
- Tagged unions
- Type inference
- Convenient definition of record/struct-like data types with free copy-constructor
- Operator overloading
- Easy FFI to external libraries in a different paradigm
- Easy "dropping down" to mutable, imperative code (e.g. for performance, or interop)
- Both have lots of syntactic and semantic warts and corner cases, though few enough you can live with them
- Garbage collected, multithreaded, JITed runtime
- Both compile to Javascript
While every single feature looks totally different on the surface, starting with a totally different syntax, the two languages are more the same than different. If you look at the tutorials linked from that page, all of them can be translated almost line-for-line from F# to Scala (and vice versa: take any random Scala tutorial, and you can trivially translate it line-for-line into F#)
Scala brings with it a bigger ecosystem, both in Scala and from the JVM, and better tooling support in general (Both Scala-specific, as well as general JVM tooling which all works with Scala: profilers, debuggers, package managers, ...), and slightly more seamless platform interop (Scala <-> JVM is less jarring than F# <-> C#), which is why I ended up sticking around.
Ultimately these higher-level requirements like JVM vs. .NET are the biggest factor in deciding a language. For example, my latest project need to run on Azure Functions (consumption plan, has cold-start) for cost reasons, so the deciding factor was "which language has the lowest cold start time?" If you're doing ML model design, you use Python because that's what the notebooks and libraries are written in. At any given moment, OS/cloud platform support, library availability, and desired app model has way more impact on choosing a language than design.
I can echo this. I'm working in F# in my day to day. While I like the language. I find the tooling IDE and other essentials are missing. I spent several weeks fighting swagger generation client and server tools. Something that just worked on the jvm.
I bounce between Scala and Kotlin. But as a Linux dev I find the JVM far more forgiving.
Re F# tooling and IDEs: sadly the churn around the transition to .Net Core has really hurt F#s tools. Things that were stable and working since inception, and enabled highly productive workflows, have been trampled by missing features and shifting boundaries on the new platform.
That said: it seems it's finally coming around, as .Net Core matures and gets more mature secondary tooling, a lot of the little blocking issues can finally be addressed.
I am new to programming...wanted to import and process tables from https://en.m.wikipedia.org/wiki/Megacity
Was using ionide on vscode But not working because .NET CORE is not supported
Returns the suggestion to switch Fsac.Runtime to netcore after I get the error fs0039 HtmlProvider is not defined even though Intellisense recognises it..
Is F#'s type system sophisticated enough to express type classes, higher-kinded types, and/or existential types? Scala's implicits and related language features can go a long way down those roads, but I know very little about F# other than "it's like Scala but on the CLR" and am curious what the story is over there.
You can grow the build quotas as well to support larger applications. Furthermore, you can use the open source pieces of Codename One for free without the build servers. There is no restriction on that.
> JVM knows nothing about generics. What kind of casts are you talking about?
Precisely! because the bytecode doesn't know about generics (it's syntactic sugar in higher levels, i.e. Java), then casts need to be performed at runtime (e.g. when getting an item from a collection).
> Why would you bother with F# or Scala when iOS has Swift?
Haha, thanks for agreeing with me that Scala is not good in this regard. When I choose F# over Scala is because it can run in any platform. I'm not constrained.
I suppose you meant boxing/unboxing. If so, yes, that's necessary for primitive types. As for regular objects, no casts are needed.
Regarding TCO, that's a well known limitation of the current Scala compiler. Hardly a "horror story".
Let me assure you, there are plenty of platforms where F# is nowhere to be seen. Thus, "can run on any platform [I care about]", which is a different set for different people anyway. For example, F# does not run on JVM, does it?
Yes, you are right, I didn't consider the checkcast instruction.
Yes, F# does not have this particular limitation, but has few of its own in different places. Most notably, it lacks HKT (arguably, because of CLR awareness of generics).
> Yes, F# does not have this particular limitation
And guess what? it doesn't have it because F# doesn't run on the JVM! If it run in the JVM, it would have it. So your obsession with "runtime" as a platform not only not useful, it's asking for trouble! ;)
- Indentation delimited blocks vs curlies
- CLR vs JVM
- Whitespace vs Parenthesis for function calls
- Currying by default vs currying optional
Despite all this, when you actually start coding, it's remarkably the same:
- Immutability by default, transformations rather than mutation
- Less classes with embedded implementation logic, more "dumb" records with external functions
- Structural pattern matching
- Tagged unions
- Type inference
- Convenient definition of record/struct-like data types with free copy-constructor
- Operator overloading
- Easy FFI to external libraries in a different paradigm
- Easy "dropping down" to mutable, imperative code (e.g. for performance, or interop)
- Both have lots of syntactic and semantic warts and corner cases, though few enough you can live with them
- Garbage collected, multithreaded, JITed runtime
- Both compile to Javascript
While every single feature looks totally different on the surface, starting with a totally different syntax, the two languages are more the same than different. If you look at the tutorials linked from that page, all of them can be translated almost line-for-line from F# to Scala (and vice versa: take any random Scala tutorial, and you can trivially translate it line-for-line into F#)
Scala brings with it a bigger ecosystem, both in Scala and from the JVM, and better tooling support in general (Both Scala-specific, as well as general JVM tooling which all works with Scala: profilers, debuggers, package managers, ...), and slightly more seamless platform interop (Scala <-> JVM is less jarring than F# <-> C#), which is why I ended up sticking around.