6 ms·
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 th
by KirinDave 9y ago
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 folks have these. Haskell folks have these. Heck, even psuedo-functional languages like Clojure and Scala have these.
The other problem is one of tooling (disclaimer, last time I tried this was just over a year ago). F# not only has pretty obscure tooling, but in conventional tooling it introduces a total linear order to your entire source tree, and it's one YOU must maintain with a GUI list. What's more, the F# community is very keen to disseminate the language.
I think F# would be more popular if it did more to differentiate itself from imperative programming. There is a longstanding argument that this is "unfriendly to data scientist", but I'm really not convinced by this, as I meet very few mathematicians outside of the stats world who don't on some way, shape or form espouse functional programming.
- Avshalom 9y agoSure but Ocaml and Haskell don't have .Net. F# is .Net for people who feel a bit gross in C#, it's not (specifically) to make people jump ship from the JVM ecosystem.
- KirinDave 9y agoThis 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.
- DeepRote 9y agoNeither 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 ScalaJS are making progress and could eventually be real players. Not likely to take food away from Haskell or Typescript, but they will certainly maintain larger usage than PS or Eta. edit: I'll concede that Clojure matters a bit in JVM-world, but it's dying quickly.
- rlander 9y agoWhat's with the "Clojure is dying" meme? In the last few months I've seen an uptake in Clojure jobs.
- KirinDave 9y agoThere is nothing but frustration at Scala's stagnancy driving.
- DeepRote 9y agoScala 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.
- KirinDave 9y agoThat is not my perception. It's difficult to point to a more poorly managed language project than Scala. The net result is a mess with tons of gotchas, performance pitfalls, technical debt and a 3-way split tie in the community. Scala has driven away a lot of brilliant people.
- eropple 9y agoThis is where I'm at. When people ask me why I don't write Scala anymore, the best answer I can give is "it is not a language that deserves a The Good Parts book, but desperately needs one."
- DeepRote 9y agoThe 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.
- sremani 9y agoTooling 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).
- KirinDave 9y agoI 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.