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

371–380 of 424 posts

Re: Why F#?

#371

Post by fodkodrasz »

Rohansi wrote: post #340
jadenPete wrote: post #278

Earlier quoted context omitted.

It’s always puzzled me that so many languages have their own build systems and package managers. Why aren’t programming language-agnostic build systems like Bazel and Buck more popular? It seems so strange that every new programming language essentially has to reinvent the wheel multiple times, inventing a new build system, package manager, formatter, linter, etc. I wonder if we’ll ever see something like LLVM for th…

Because there are differences that go beyond just the language syntax. The build processes are very different for C++ vs. C#, vs. F#, etc. C++: invoke compiler for all compilation units, invoke linker to combine object files into executable C#: invoke compiler once with all source files listed F#: same as C# AFAIK, except file order matters!

C++ I have worked only a little with it, more so with C, but AFAIK order of files does kind-of matter, so at least declarations need to be present in each file upfront before use.

C# has a multi-pass compiler so that it can compile and link the components from multiple files, without need of placeholder declarations, regardless of the order the symbols appear in the files.

F# has a single pass compiler, which keeps the compiler implementation simpler, but the file, and symbol definition order does matter that way. This is totally intentional, this is supposed to make the codebase more straightforward, with which I personally agree with. This avoids the need for declarations and centralization of them, the includes all the baggage that comes with that approach, and all the complexity C# has. I have rarely found a limiting factor, though there are some cases when it can be a bit inconvenient, for me the application setup/composition (~DI, but I prefer more static approach in F#) needed some cumbersome refactoring in some cases (have only vague memories by now, and yes, I know co-recursive types exists)

I really like F#, but rarely have to opportunity to work in it.

Re: Why F#?

#372

Post by DeathArrow »

F# is a lovable language as in people are really enjoying using it vs not being bothered using it.

Once every other month a new F# link lands on top page and receives a few hundred of upvotes.

I think F# needs and deserves more publicity in order for it to win a larger audience. If only F# community would be half as vocal as Rust community.

Re: Why F#?

#373

Post by psychoslave »

paddim8 wrote: post #342
psychoslave wrote: post #301

Earlier quoted context omitted.

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#"))

Nothing is that much a big deal on a small selected sample, on the one hand on the other. That is, maybe some will prefer mandatory explicit type for every single variable, and some other will prefer type inference whenever possible, and both have pros and cons.

To jump in a REPL (or any debug breakpoint observation facility), having optional type inference is a great plus to my mind.

Note that Crystal does allow to make type explicit, and keep the fluent interface on track doing so:

    Array(String).new.push("Peter", "Julia", "Xi").map{|name| "Hello, #{name}"}.each{|greeting| puts "#{greeting}! Enjoy your Crystal"}
Let’s remark by the way that, like with C# lambda parameters, block parameters are not explicitly typed in that case.

Re: Why F#?

#374

Post by fodkodrasz »

torginus wrote: post #326
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…

My two cents is that F# hasn't received the same care and attention as C# and working with it can be awkward. At the same time, a lot of the cool features (list comprehension, pattern matching, immutable records) have slowly trickled into c#, giving even less incentive to switch

I personally find the way these features were shoehorned into the C# syntax an eyesore, I have quite some C# experience, and I think the language is getting more and more convoluted and noisy, with ever less coherent syntax.

On the other hand many of these features are really convenient and handy in F#. Adding many of the oh-my-gamedev-such-speed features from C# to F# also makes its syntax less pleasant to work with.

Personally I also think that the C# async model is terrible, and was a grave mistake. The F# async model with computation expressions, and explicit control over their execution context was a better approach, and I'm really sorry the hack-something-together to unblock the event loop WPF/frontend-dev usecase won over the more disciplined backend-focused approach.

Re: Why F#?

#375

Post by iLemming »

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.

> felt too much .NET-y and too much MicroSoft-y

That was kind of my main problem with dotnet stack in general, although that was some years ago. I've tried sneaking F# into our project by building set of tests (the main codebase was in C#), but some of my teammates would have none of that.

My personal perception of the dotnet community was that developers either were too pigheaded about doing things "the Microsoft way", or hyped about "innovation" — "Oooh... check this out, Scott Hanselman made a whole new conference talk about it...", and then you'd look into this "innovation", and it often turns out to be some decades old, well-known thing, only "wrapped into MSFT packaging", which is not really bad by itself - it just seemed that people didn't actually use them in a practical way. I just never found that sweet-spot between pragmatism and excitement. You have to find a middle ground between: "This works! Sure, yeah, but isn't it darn ugly and probably not scalable?" and "This is so beautiful, and cool, but nobody besides Jeff really understands it." And my personal experience was that .net programmers would always want to be on one of those sides.

Re: Why F#?

#376

Post by runevault »

protonbob wrote: post #328

I've found that as C# gains much of the features that F# has and will soon gain more (pattern matching, functions as first class data types, great fp libraries, etc) the "moat" that F# has over C# has gotten smaller. I write most of my c# code in a primarily functional style, but I still have the advantage of using the libraries in their own native ways that follow the examples given by microsoft and other vendors.

Watching c# eat f# features as someone who has dabbled in f# lightly for over a decade has been wild. And supposedly DU's are in the works but multiple years out.

Though one thing I doubt c# ever gets that I love when I'm writing f# is pipeline operators. I love the way they read, from object/collection being worked on and then a list of operations being run on it in order from left to right (or you can do right to left if you need to for some particular reason).

Re: Why F#?

#377

Post by fodkodrasz »

DeathArrow wrote: post #305
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 would call .NET build system excellent.

Lets settle on a finally good enough. I can give honest compliments on learning from the past problems and from the better examples in the indsutry.

You may not remember the early .net core times with yeoman and other then-current javascript ecosystem originated things applied in really cumbersome, half-assed ways, with lacking docs and always being in flux for years. The project.json era was terrible.

Also msbuild was way worse 10-15 years ago...

Mono with automake was special circle of hell IMO, I have very small exposure but it was really unproductive and painful.

Re: Why F#?

#378

Post by kstrauser »

ninetyninenine wrote: post #364
dboreham wrote: post #336

Earlier quoted context omitted.

This seems...a very contrarian sentiment. Imho while C might lead you to create slightly fragile code once in a while, Rust is something like two orders of magnitude more complex.

No I know what he’s saying. C is not “slightly fragile code once in a while”. When you up the complexity of the code and the amount of code and the people working on the code the fragility becomes pervasive.

That's a huge part of it. If I stumble across random Rust code, I can assume that it's using typed data correctly, that it's not accessing freed memory, that it's not allocating but never freeing, that length checks are being enforced, etc. If they weren't, it wouldn't even compile (and the compiler would explain why).

Glancing at random C code tells you nothing about what happens with the data flowing into and out of it.

In my experience with it, rustc has been insistent on making me write code that's actually correct. I could translate that code back to C and have better C code than I would likely have written on my own. If there were something similar to `gcc -Werror -Weverything-rust-would-complain-about` — and if that thing were even possible — I very well might stick with C. Oh, and something as fast and ergonomic and informative as rust-analyzer would be hugely welcome.

Re: Why F#?

#379

Post by marcosdumay »

int_19h wrote: post #188
marcosdumay wrote: post #86

Earlier quoted context omitted.

You may start to get a point when C# gets a two-directional type inference system. As it's now, any functional-looking code requires so much boiler plate that it's shorter and less bug-prone to copy your functions code everywhere you want to use them.

Can you give an example of said boiler plate?

Just try to make any generic high order function in C#. Any one you can think of.

Re: Why F#?

#380

Post by cjbgkagh »

shortrounddev2 wrote: post #348
cjbgkagh wrote: post #266

Earlier quoted context omitted.

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 a…

Your criticism is rather incoherent and it is difficult for me to make sense of it.

You don't even have to use the computation block for that and can use the built in functions as I mentioned earlier and gave 3 examples of.

You're both complaining about extra keywords while trying to make the case of adding yet another one. Thus your complaint boils down to F# not picking the exact keywords that you like - that the language is not specialized to exactly how you want to use it. In language design there are always tradeoffs but I'm unable to see how your suggestions would improve the language in the general case or even in your specific case.

Computation expressions are a generalized concept which are there to add the exact kind of syntactic sugar that you're after. It's better than C# in that you can create your own as a first class concept in addition to using the built in ones. It's there for the exact purpose of creating mini-embedded DSLs, the very thing you're complaining about is the exact point of it.

F# is not for everyone, nor should it be.

Post reply on HN