Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why F#?

batsov.com

Post reply on HN
Print view View original

341–350 of 424 posts

Re: Why F#?

#341

Post by debugnik »

neonsunset wrote: post #74
cogman10 wrote: post #63

Earlier quoted context omitted.

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.

F# is a statically typed language with gradual typing and full type inference. Given let hello value = printfn "%A" value hello "world" hello 2 The binding "hello" has "'a -> unit" signature where 'a is a generic argument it accepts because the "printfn" binding with a given format specifier is generalized the same way and an unconstrained 'T (here 'a) is the most narrow type inferred for "hello".

> with gradual typing

Isn't gradual typing widely understood to mean "gradual between static and dynamic", which F# certainly isn't?

Re: Why F#?

#342

Post by paddim8 »

psychoslave wrote: post #301
int_19h wrote: post #176

Earlier quoted context omitted.

Ruby is dynamically typed, which makes "fluent" API design that much easier at the cost of maintainability elsewhere. If you want to compare apples to apples, you need to compare F# to other statically typed languages.

Also note that the following is a valid Crystal-lang code: %w[Peter Julia Xi].map { |name| "Hello, #{name}" }.each { |greeting| puts "#{greeting}! Enjoy your Crystal" } As they put it: >Crystal is a general-purpose, object-oriented programming language. With syntax inspired by Ruby, it's a compiled language with static type-checking. But this time, one can probably say that Crystal will lake the benefits of ecosystem…

The only difference is that you have to specify the type of the list when you declare it though... That's not really a big deal.

List names = ["Peter", "Julia", "Xi"]; names.Select(name => $"Hello, {name}").ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#"))

or

new List { "Peter", "Julia", "Xi" }.Select(name => $"Hello, {name}").ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#"))

Re: Why F#?

#343

Post by davydog187 »

neonsunset wrote: post #206
tasuki wrote: post #160

Earlier quoted context omitted.

These days there's Gleam[0], as a strongly typed alternative for the BEAM virtual machine. Of all the languages I haven't used yet, it seems to hit the safe + minimalistic + productive sweet spot the best. (Yes the C-inspired syntax is slightly off-putting, but syntax is the least important aspect of a language.) [0]: https://gleam.run/

Gleam, much like any language which primarily targets BEAM, is slower by an order of magnitude or two when compared to F#.

For most of the workloads you’re putting on the BEAM, they are IO bound and this is not of any consequence

Re: Why F#?

#344

Post by DeathArrow »

UlisesAC4 wrote: post #288
BenGosub wrote: post #166

Two nice things about F# are that you can introduce it into an organisation using the dotnet ecosystem and that you can use all libraries in dotnet, which is a huge advantage over OCaml. Otherwise, I am happy with OCaml, but F# has also a place in this world.

You can use adapters via Foreign Function Interface and interact with C++ code. The deal breaker is that memory is separated, C++ code has its own heap and Ocaml too. Quiet different to F# in which operating with C# is seamless and the runtime is the same.

You can call C++ code from F#, too.

Re: Why F#?

#345

Post by airstrike »

UK-Al05 wrote: post #316
airstrike wrote: post #157

Earlier quoted context omitted.

This rings true to me as well. I'm not sure what I get out of F# that I can't get from Rust, unless you specifically want .NET, which I don't.

Less arduous memory management.

I am not sure what you mean. My memory management for a recent 30k LOC app boils down to "thinking before cloning"

Re: Why F#?

#346

Post by debugnik »

sklivvz1971 wrote: post #252

As a person who's worked with the author (a great guy!) and with the F# community on a very large F# project: don't bother with F#, professionally speaking. F# has many theoretical qualities, which make it fun if you like these things, but it also has some fundamental flaws, which is why it's not getting a wide professional adoption. - the build system was a mess last I checked (slow, peculiar) - syntax is not c-like…

The build system is exactly the same as C#, MSBuild with its .NET SDK, and syntax and community are entirely subjective; F# has the least weirdo community I've personally seen for an FP language. Weak arguments to say the least.

I'll give you the chicken-and-egg hiring problem and it being second-class to the .NET team, though; I'd add poor IDE support by modern standards, only Rider feels right. I love F# but I've moved on for these reasons.

Re: Why F#?

#347

Post by germandiago »

darksaints wrote: post #219

I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. More significantly, they are being passed up in favor of Rust, which is a great language but nonetheless a bad fit for a lot of problem domains, simply because Rust has a superior build system. Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the buil…

I use C++ with Meson and Conan and I can say that there is an initial learning curve if you need to adapt Conan recipes but once you get past, the results are quite good.

Re: Why F#?

#348

Post by shortrounddev2 »

cjbgkagh wrote: post #266
shortrounddev2 wrote: post #253

Earlier quoted context omitted.

I understand that you CAN do this, I'm saying that it makes your code look like shit and takes away some of the elegance of ML

Are you saying you prefer Ocaml to F# or C# to F#? Your example was indeed inelegant but it is also poorly designed as you take 4 lines to reproduce a function that is already built in, people can poorly design code in any language.

I'm saying that I wish computation blocks looked better in F#. Instead of:

    let foo id = async {
      let! bar = getBar id
      return bar
    }
I would prefer

    let async foo id =
      let! bar = getBar id
      bar
or even something like

    let async foo id =
        getBar! id
So that computation blocks don't feel like you're switching to an entirely different language. Just wrap the ugliness in the same syntactic sugar that C# does. As it is, C# can achieve arrow syntax with async methods more elegantly than F# can:

    async Task foo(int id) => await getBar(id);
This, to me, is also part of a larger problem of F# introducing unique keywords for specific language functions instead of reusing keywords, like

    member this.Foo = ...
and

    member val Foo = ...

Re: Why F#?

#349

Post by RUnconcerned »

hoseja wrote: post #321
baq wrote: post #298

Earlier quoted context omitted.

strong typing: 2 + "2" is an error (e.g. Python vs JS) static typing: 2 + "2" does not compile/parse (e.g. Python vs mypy, Typescript vs JS) this is a very simplistic example, but should get you to feel the difference.

weak typing: 2 + "2" is 22

could also be "4" or 4! 4 seems like it would be the most evil option, honestly

Re: Why F#?

#350

Post by pjc50 »

RUnconcerned wrote: post #349
hoseja wrote: post #321

Earlier quoted context omitted.

weak typing: 2 + "2" is 22

could also be "4" or 4! 4 seems like it would be the most evil option, honestly

The real evil option is C: 2+"22" = 0, 4+"4" = undefined behavior and probably the value of some other variable.
Post reply on HN