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

311–320 of 424 posts

Re: Why F#?

#311

Post by throwaway2037 »

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'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems.
Scala? I am not trolling here: Are you joking? Scala is part of the Java ecosystem. Sure, Maven gets lots of hate on HN, but it is very mature and has excellent integration with IDEs and CI/CD systems (TeamCity, Jenkins, etc.). In the last 10 years, many Java developers have moved to Gradle, which has equally good integration.

    > Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the build system.
What is wrong with CMake for C++?

Re: Why F#?

#312

Post by smcl »

rawoke083600 wrote: post #300

I'm waiting for the excellent F# Article about railroad-coding to be posted here. Required F#e reading :) No not trolling. Am on mobile and traveling else I would have searched-posted

I assume you're talking about Scott Wlaschin's "Railway Oriented Programming": https://fsharpforfunandprofit.com/rop/

Re: Why F#?

#313

Post by blatantly »

kqr wrote: post #124
raphinou wrote: post #107

F# was for me the best functional language when I looked at rewriting a Ruby on Rails app. I wanted to go with a functional language, as it seems to better fit my thinking and reasoning, and I looked at Haskell, Ocaml, Scala, F#. Being a stranger to Microsoft technologies, F# was the least likely to be chosen, but easily became the first choice. Haskell's purity made it hard to adopt (for me), Ocaml's ecosystem is su…

Curious since you don't expand on it on the blog: in what way did Haskell's purity make it difficult to you? Having used Haskell in production for a bit now, I don't even notice its purity. Most functions are in some kind of I/O context making it similar as other languages, except with the option of running without I/O capabilities for functions that shouldn't need it.

What about libraries though? They might force you to use certain monads rather than IO?

Re: Why F#?

#314

Post by oblio »

throwaway2037 wrote: post #311
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'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. Scala? I am not trolling here: Are you joking? Scala is part of the Java ecosystem. Sure, Maven gets lots of hate on HN, but it is very mature and has excellent integration with IDEs and CI/CD systems (TeamCity, Jenkins, etc.). In the last 10 years, many Java developers have mov…

How long are Scala compilation times for a Hello World CLI, a Hello World basic webapp and for a reasonably sized production size code base?

My guess is that it's much longer than for the equivalent Java apps.

> What is wrong with CMake for C++?

It doesn't manage dependencies.

Re: Why F#?

#315

Post by apwell23 »

raphinou wrote: post #144
breadwinner wrote: post #130

Earlier quoted context omitted.

Apache Spark, Delta Lake are written Scala. Being JVM based, it has a large ecosystem. Scala seems like a better choice than F#.

I'm sure it can be the better choice, but for me it was not. It seems there was some incompatibility between me and Scala. I find it such a complex language and I never managed to wrap my head around it. As I said F# was my last choice at the start of my evaluation, and Scala was high on the list due to the Java ecosystem. But in the end it didn't work out for me. F# on the JVM would be great though!

i've used scala for over 8 yrs everyday and i agree with your assessment.

Even intellij has no idea sometimes about what the hell is going on. It throws up compile errors when there none.

Re: Why F#?

#316

Post by UK-Al05 »

airstrike wrote: post #157
loxs wrote: post #97

I tried F# some years back when I was searching for a language to port my OCaml project in... It felt too much .NET-y and too much MicroSoft-y. And back then .net for linux had just been released and was somewhat unpolished. It seemed that I had to learn C# in order to use F# properly and it seemed that porting it to C# was the saner option. I went with Rust after all and it seems to have been the right choice.

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.

Re: Why F#?

#317

Post by UK-Al05 »

bob1029 wrote: post #185
UK-Al05 wrote: post #87

Earlier quoted context omitted.

A language is just as much about what it can't do, then what it can do.

Can you elaborate on what you mean by this? I assume you are implying that too many choices could confuse a junior developer, which I agree with. However, I don't think this is a concern in the bigger picture when talking about the space of all languages.

A language by making certain things harder makes the resulting code be built in a certain way.

F# makes mutable code harder to do, so you tend to write immutable code by default.

Re: Why F#?

#318

Post by anentropic »

noahbp wrote: post #279
Lyngbakr wrote: post #258

Earlier quoted context omitted.

While I've never used it in anger, I really quite like dune. Was there something specific that makes you characterise it as "ridiculously bad"?

Not Dune exactly, but having to run 'eval $(opam env)' in the terminal every time you open an OCaml project rather than the default being npm-like, where you can just open the directory and use the package manager command without having to think about it.

(writing all the below while being aware you likely know much more about OCaml than I do...!)

Possibly `eval $(opam env)` is something that should just go in your ~/.zshrc

The OCaml folks have done some work recently to improve the onboarding documentation, which I think is going in a positive direction

e.g. https://ocaml.org/docs/installing-ocaml (the eval as a one-off post install command)

And then guiding people to use 'switches' https://ocaml.org/docs/opam-switch-introduction, which I totally missed when I started with the language.

> Local switches are automatically selected based on the current working directory.

Re: Why F#?

#319

Post by DeathArrow »

z5h wrote: post #66
pimbrouwers wrote: post #46

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?

Jobs are kind of rare. I have to learn F# hoping maybe I will find a job in one or two years. And if I find it, they might want someone with F# work experience.

Re: Why F#?

#320

Post by felixyz »

innocentoldguy wrote: post #163
raphinou wrote: post #152

Earlier quoted context omitted.

Elixir getting a strong type system is interesting, but watch out for gleam though But they still miss the computation expressions, which open interesting possibilities like https://github.com/CaptnCodr/Fli and https://github.com/fsprojects/FsHttp

Gleam lacks lisp-style macros, and its implementations of BEAM and OTP are not exhaustive. For example, Gleam does not support: - Hot updates. - Full distributed system support. – Low-level process manipulation. - Named processes. - Advanced supervision strategies. - Behaviours other than GenServer. - Type-safe distributed messaging. - And several other things that I value in BEAM and OTP. I can't justify trading the…

My current preference is to use Elixir and its great ecosystem as the shell for my project, and implement the core business logic in Gleam.
Post reply on HN