I bounce between Scala and Kotlin. But as a Linux dev I find the JVM far more forgiving.
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.
Returns the suggestion to switch Fsac.Runtime to netcore after I get the error fs0039 HtmlProvider is not defined even though Intellisense recognises it..
...refer below
- JVM is less efficient for generics than the CIL (casts happening at runtime underneath).
- I've read about horror stories about tailcalls in the JVM world.
- There's no way to build an iOS app with Scala (i.e.: https://stackoverflow.com/questions/13460780/any-way-to-use-... ), while you can do easily with F# thanks to Xamarin.
And there is another way paying for GluonVM.
EDIT: corrected my statements based on comment below.
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.
Trampolines are a common technique to implement tailcalls on platforms that don't support them natively. What are the horror stories then?
Why would you bother with F# or Scala when iOS has Swift?
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).
> What are the horror stories then?
https://stackoverflow.com/a/18196685/544947
> 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.
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?
> As for regular objects, no casts are needed.
Are you sure? See https://stackoverflow.com/a/10126425/544947
> Hardly a "horror story".
F# doesn't have this limitation and F# does tailcalls by default instead of having to explicitly remember to decorate it with the @tailrec attribute.
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).
BTW, alternative approaches to stack-safe recursion do exist in Scala. For example, https://github.com/slamdata/matryoshka
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! ;)
@tailrec is not necessary to enable tailcalls.
All the annotation does is error if a function is not able to be optimized for tail calls.
The (attempt at) optimization takes place either way, you don't need the annotation unless there's some doubt in your mind.
[1] https://github.com/dotnet/corert/blob/master/Documentation/i...
Just watched this video about Scala 3 last night and the list of features Scala pioneered in a mainstream language is fairly incredible.
- 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.