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

The Problem with F# Evangelism

thomasbandt.com

Post reply on HN
Print view View original

101–110 of 203 posts

Re: The Problem with F# Evangelism

#101

Post by hellofunk »

DeepRote wrote: post #18
KirinDave wrote: post #15

Earlier quoted context omitted.

This is very true, and Purescript and Eta are making big strides here precisely because they expose access to NPM and the world of Java, respectively.

Neither are making "big strides". They both are barely able to exist. Eta will never even approach Scala in terms of adoption, and I had only heard about Purescript a few weeks ago reading about Elm. Typescript will dominate functional JS-world (already is, tbh) and Scala is still crushing function JVM-world, and if Dotty ever actually materializes, adoption will get even better. Additionally, Scala-Native and ScalaJ…

Why do you say Clojure is dying quickly? That seems at odds with its community, which is continuing to grow and the language keeps evolving. I've seen several new companies and start ups in my area adopt it for their main work, just in the last year.

Re: The Problem with F# Evangelism

#102

Post by pjmlp »

magnumkarter wrote: post #94

For me, I only got into .NET because of F#, and even then I pretend C# doesn't exist. I tried learning OCaml, it has cool features, like parametric modules and GADTs. But I always ran into the issue of irreproducible builds. This didn't happened in F#. I eventually tried F# because it was close enough to OCaml and while I was learning OCaml I always referred to this site http://fsharpforfunandprofit.com I'm definitel…

The difference being that Apple is quite vocal that Swift is the future of app development on their platforms, while Microsoft is trying to push UWP as the future of Windows apps (supported languages VB, C#, C++ and JavaScript).

Re: The Problem with F# Evangelism

#103

Post by KirinDave »

rlander wrote: post #100
DeepRote wrote: post #18

Earlier quoted context omitted.

Neither are making "big strides". They both are barely able to exist. Eta will never even approach Scala in terms of adoption, and I had only heard about Purescript a few weeks ago reading about Elm. Typescript will dominate functional JS-world (already is, tbh) and Scala is still crushing function JVM-world, and if Dotty ever actually materializes, adoption will get even better. Additionally, Scala-Native and ScalaJ…

What's with the "Clojure is dying" meme? In the last few months I've seen an uptake in Clojure jobs.

There is nothing but frustration at Scala's stagnancy driving.

Re: The Problem with F# Evangelism

#104

Post by MrBuddyCasino »

rubber_duck wrote: post #32
nickpeterson wrote: post #26

This article retreads common complaints about the F# experience for outsiders that I've seen numerous time. I'm going to go a different direction. The problem with the F# community is that they keep asking how to convince C# developers to use F#. I'm convinced that is not the right way to grow the F# ecosystem. Most C# developers tend to come from enterprise and have a set of values and practices that is generally at…

I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to wr…

You don't increase adoption by making the learning curve steeper.

Rust does its best given the circumstances, but people's top complaint is that its hard to learn.

Scala never went Mainstream because you can't hire developers, and training them takes many months.

F# should not repeat that mistake.

Re: The Problem with F# Evangelism

#105

Post by earthtolazlo »

tome wrote: post #50
rottyguy wrote: post #21

Earlier quoted context omitted.

"...realize that the types of bugs that hold them back can be reduced by using a more powerful language." I hear this a lot with FP but would love to see some real world examples of this if anyone has any links.

How many times have you had the runtime exception AttributeError: 'NoneType' object has no attribute 'foo' (or its equivalent in your favourite language)?

That's something addressed by static typing though. I'm pretty sure any dynamic language has that issue, functional or not.

Re: The Problem with F# Evangelism

#106

Post by sklivvz1971 »

The problem is that people who are drawn to F# tend to be a certain kind of people: generally stronger in CS, but also more prone to think that changing programming language is a solution to a wide variety of problems.

Many people are not like that, and stuff like a small community, worse tools and toolkits and less programmer availability are actually a huge deal, capable of tanking a good project, whereas having a 10% better language isn't a huge gain.

It's that simple.

Re: The Problem with F# Evangelism

#107

Post by DeepRote »

rlander wrote: post #100
DeepRote wrote: post #18

Earlier quoted context omitted.

Neither are making "big strides". They both are barely able to exist. Eta will never even approach Scala in terms of adoption, and I had only heard about Purescript a few weeks ago reading about Elm. Typescript will dominate functional JS-world (already is, tbh) and Scala is still crushing function JVM-world, and if Dotty ever actually materializes, adoption will get even better. Additionally, Scala-Native and ScalaJ…

What's with the "Clojure is dying" meme? In the last few months I've seen an uptake in Clojure jobs.

The fallacy there is that Clojure development is drastically slowing in favor cljs. Because there's jobs doesn't mean anything with regards to dev status.

My dad has been writing COBOL for 30+ years, but I think we could both agree that it's a dead language in a certain sense.

My first language was Scheme. I wrote some stupid BATCH scripts at school and decided I wanted to learn to program. I worked my way through half of SICP, etc etc. I LOVE Lisps. I was rooting for Clojure a few years ago.

However, I think Clojure is embracing types too little too late. Large systems are hard to do in dynamic languages. There's no easy way around that. Sure, immutability helps, and having a strong style guide helps and having strong interactive programming helps, but it never goes away that it's harder to do when you can't reason about the structure of something without evaluating that thing.

That there are more Clojure jobs sprouting up as development is drying up screams disaster maintenance to me.

I'd love to be proven wrong. I would LOOOVE for Clojure 2.0 to fully embrace a strong type system and maybe some stricter semantics but it just isn't going to happen. Very few people are familiar with Clj internals, fewer people still are still working on it, and fewer people still plan on continuing that work for a long period of time.

Call me crazy, but I think there are two major threats to Clojure's current reign in the enterprise lispverse.

Racket's rewrite to Chez. That's big. That will mean big performance gains and I think could provide incentive for someone industrious to wrangle some of the crazier parts of racket into a coherent biz-ready language.

The other is Elixir. Now, I hate elixir but people seem to eat that kind of stuff up. They have a strong macro story, BEAM is very powerful in the right hands, and as time goes on it becomes more and more clear that it's easy to write high-concurrency, low-latency, SMP-enabled systems in Elixir.

Elixir doesn't have a type story (racket does, but it's kinda lame), but that never stopped Clojure up to this point.

Also, Clojerl (clj on erlang/otp) exists, which could strengthen the motivation for moving away from Clojure by making pure-clojure applications vulnerable to completely automated porting thus eliminating the need for clojure maintenance programmers.

That's my take on that whole situation.

Re: The Problem with F# Evangelism

#108

Post by mbenoni7 »

brianberns wrote: post #37
rubber_duck wrote: post #32

Earlier quoted context omitted.

I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to wr…

C# developers in my shop loathe the SQL type provider because it requires them to have a compatible SQL Server database schema at build-time. The extra level of organization required is more than they can accept.

There's a new type provider out that takes a different approach by bundling a SQL parser:

https://github.com/rspeele/Rezoom.SQL

It can't check everything that the other providers can, but IMO you get most of the benefit without requiring any onerous build-time dependencies.

Re: The Problem with F# Evangelism

#109

Post by DeepRote »

KirinDave wrote: post #103
rlander wrote: post #100

Earlier quoted context omitted.

What's with the "Clojure is dying" meme? In the last few months I've seen an uptake in Clojure jobs.

There is nothing but frustration at Scala's stagnancy driving.

Scala is not even remotely stagnant. Scala programmers are becoming stagnant, but scalac hasnt experienced any major growth slowdowns, Scala native is progressing quite a bit, ScalaJS is still a thing, and Dotty seems to at least be implementing some of that new DOT stuff.

I'm not defending how obnoxious it CAN be to write Scala, but say it's stagnant is just dishonest or misinformed. Or both.

Also SBT. Fuck sbt.

Re: The Problem with F# Evangelism

#110

Post by KirinDave »

sremani wrote: post #16
KirinDave wrote: post #9

I think F#'s larger problem is that it doesn't dip into many of the wells that even OCaml (its original inspiration) has dipped into. C# developers are wrong that C#'s functional facilities are just as good, but it's a big struggle to point to a place in F# and say, "THERE! THAT IS THE BEST BIT!" The closest I can get is type providers (which are cool and I wish for them elsewhere) but they're kinda specialist. Ocaml…

Tooling wise, tried Rider IDE from Jetbrains on Ubuntu, and out of the box it works (if you have mono + F# installed). The ionide project is doing tremendous job of support on vscode. It has improved compared to year, and definitely much better, in a month or two all the major IDEs including MonoDevelop will likely have .net core 2.0 support with F# baked in (speculation on my part).

I just don't see a lot of point to Mono in my domain. Even with the code inputs from .NET I've never gotten anything but sub-par performance from it for network services.
Post reply on HN