<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>morpheuskafka</author><text>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 &amp;quot;which language has the lowest cold start time?&amp;quot; If you&amp;#x27;re doing ML model design, you use Python because that&amp;#x27;s what the notebooks and libraries are written in. At any given moment, OS&amp;#x2F;cloud platform support, library availability, and desired app model has way more impact on choosing a language than design.</text><parent_chain><item><author>lihaoyi</author><text>Having used and enjoyed F#, I ended up programming in Scala which is almost the same language, despite the huge superficial differences:&lt;p&gt;- Indentation delimited blocks vs curlies&lt;p&gt;- CLR vs JVM&lt;p&gt;- Whitespace vs Parenthesis for function calls&lt;p&gt;- Currying by default vs currying optional&lt;p&gt;Despite all this, when you actually start coding, it&amp;#x27;s remarkably the same:&lt;p&gt;- Immutability by default, transformations rather than mutation&lt;p&gt;- Less classes with embedded implementation logic, more &amp;quot;dumb&amp;quot; records with external functions&lt;p&gt;- Structural pattern matching&lt;p&gt;- Tagged unions&lt;p&gt;- Type inference&lt;p&gt;- Convenient definition of record&amp;#x2F;struct-like data types with free copy-constructor&lt;p&gt;- Operator overloading&lt;p&gt;- Easy FFI to external libraries in a different paradigm&lt;p&gt;- Easy &amp;quot;dropping down&amp;quot; to mutable, imperative code (e.g. for performance, or interop)&lt;p&gt;- Both have lots of syntactic and semantic warts and corner cases, though few enough you can live with them&lt;p&gt;- Garbage collected, multithreaded, JITed runtime&lt;p&gt;- Both compile to Javascript&lt;p&gt;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#)&lt;p&gt;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 &amp;lt;-&amp;gt; JVM is less jarring than F# &amp;lt;-&amp;gt; C#), which is why I ended up sticking around.</text></item></parent_chain></comment><story><title>Why Use F#?</title><url>https://fsharpforfunandprofit.com/why-use-fsharp/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>soulnothing</author><text>I can echo this. I&amp;#x27;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.&lt;p&gt;I bounce between Scala and Kotlin. But as a Linux dev I find the JVM far more forgiving.</text><parent_chain><item><author>lihaoyi</author><text>Having used and enjoyed F#, I ended up programming in Scala which is almost the same language, despite the huge superficial differences:&lt;p&gt;- Indentation delimited blocks vs curlies&lt;p&gt;- CLR vs JVM&lt;p&gt;- Whitespace vs Parenthesis for function calls&lt;p&gt;- Currying by default vs currying optional&lt;p&gt;Despite all this, when you actually start coding, it&amp;#x27;s remarkably the same:&lt;p&gt;- Immutability by default, transformations rather than mutation&lt;p&gt;- Less classes with embedded implementation logic, more &amp;quot;dumb&amp;quot; records with external functions&lt;p&gt;- Structural pattern matching&lt;p&gt;- Tagged unions&lt;p&gt;- Type inference&lt;p&gt;- Convenient definition of record&amp;#x2F;struct-like data types with free copy-constructor&lt;p&gt;- Operator overloading&lt;p&gt;- Easy FFI to external libraries in a different paradigm&lt;p&gt;- Easy &amp;quot;dropping down&amp;quot; to mutable, imperative code (e.g. for performance, or interop)&lt;p&gt;- Both have lots of syntactic and semantic warts and corner cases, though few enough you can live with them&lt;p&gt;- Garbage collected, multithreaded, JITed runtime&lt;p&gt;- Both compile to Javascript&lt;p&gt;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#)&lt;p&gt;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 &amp;lt;-&amp;gt; JVM is less jarring than F# &amp;lt;-&amp;gt; C#), which is why I ended up sticking around.</text></item></parent_chain></comment><story><title>Why Use F#?</title><url>https://fsharpforfunandprofit.com/why-use-fsharp/</url></story>