3 ms·

>I've learned to design the internals of my code around a functional style that makes code composable and the data flow simple. Curious: why not go all the way

>I've learned to design the internals of my code around a functional style that makes code composable and the data flow simple. Curious: why not go all the way and use Scala, F#, Clojure, maybe even Haskell?

lobster_johnson 11y ago
I've considered most of them, actually. One consistent, niggling problem with all of these languages is that they are still obscure compared to everything else, with all that this entails: It's harder to find developers who already know the languages well enough to be true masters, let alone find juniors who are interested and capable of picking them up; the languages are often complicated and unfriendly, so junior developers will again struggle. Something I've learned the last few years is that while having only wizards on your team is great, it's useful to have access to a less advanced contingent of developers who can still contribute productively. In the end, if you buy into something that not every shop uses, there will be a lot of sunk cost into having brought everyone into the fold, and you end up being an "OCaml shop" or "Haskell shop" or whatever. Productivity will probably normalize, but I'm not sure I want to go down that route. OCaml looks to me like the most promising functional language with the fewest warts, the most pragmatic approach to real-world apps, and possibly the best performance. But it's not a simple language, with a learning curve that's similar to Haskell. I also have to say that like Erlang, the toolset and syntax occasionally feels antiquated (for example, there's no excuse not to provide a modern readline-enabled REPL). OCaml still is not good at concurrency. Scala has some good parts, but is overdesigned and way too complex, in my opinion. Last I checked, performance was worse Java. It also runs on the JVM, which means its memory usage is inherently inefficient. F# is a language that I like a lot; in some ways it looks like a more pragmatic Haskell, or Ocaml with a cleaner syntax. I don't like the fact that it's tied to .NET, which (like Java) means it inherits all the issues from that platform. The performance on Mono looks unsatisfying. Haskell is also a language I like a lot — at least in theory. I've been disappointed with performance and memory usage (and the ability to reason about those things). The tools for concurrency (and OTP-type distributed networking) also seem very much lacking. Whenever I see an example of parallel async code in Haskell, I feel like I'm reading an advanced physics paper. While I like and understand the approach to purity, I feel like the tools get in the way of programming; that I have to work at getting in and out of effectful code just so that I can stay pure, and for what reason? Bugs caused by side effects is something I encounter only a few times a year, if that; Haskell builds a huge wall to solve something that isn't a problem for me. Nor do I enjoy that laziness is the default. Finally, there are parts of the language that seem immature; the well-known data record namespacing issue (being fixed?), and the sheer awkwardness that comes with trying to implement certain things (like polymorphic collections and directed graphs) that should be simple, but aren't. Still, it's a beautiful language, but not one I would use for everything. Clojure is the JVM, again. It's also not statically typed. From everything I've seen, performance is worse than Java.
- acconsta 11y ago
  With OCaml, that depends what you mean by concurrency. There's good async IO, but the runtime is still single threaded (just like Node!). The overall library ecosystem is a disappointing though. https://github.com/janestreet/async https://github.com/janestreet/async And it is a huge shame F# doesn't work well cross platform. Hopefully we'll see the runtime ported soon. Looks like it builds, but the tests are probably a mess: https://github.com/dotnet/corefx https://github.com/dotnet/corefx Haskell, yeah, very much agreed. Hopefully one day a big company will build us a modern language with a vibrant ecosystem. Microsoft has come the closest with F#. Rust is tentatively exciting, but who knows if Mozilla has the muscle to get it adopted.
  - lobster_johnson 11y ago
    Yes, I was referring to OCaml's single-core limitation. I was under the impression that some smart people working right now on removing the global lock, though?
- nickbauman 11y ago
  Using a language that isn't already in every shop may limit hiring at first glance, but it will automatically select for folks who have an important sense of craft for the work they do and pay close attention to where there is a lack of return on investment in languages, platforms and applications. People who really care about FP will likely be easier to retain than those who use Blub and couldn't care less. Go is shiny right now. What will be shiny later? Lisp is not shiny but it is power like power has never known with Blub. Aside: I've not found Clojure to be slower than Java and I've benched it. It is fast, fast, fast. As fast as Go even doing the concurrent thing: benched that too. I've even found that Clojure can edge out Java in many cases because of its inherent laziness: the fastest way to expedite a job is not to have to do it in the first place.

lobster_johnson 11y ago

I've considered most of them, actually. One consistent, niggling problem with all of these languages is that they are still obscure compared to everything else, with all that this entails: It's harder to find developers who already know the languages well enough to be true masters, let alone find juniors who are interested and capable of picking them up; the languages are often complicated and unfriendly, so junior developers will again struggle. Something I've learned the last few years is that while having only wizards on your team is great, it's useful to have access to a less advanced contingent of developers who can still contribute productively. In the end, if you buy into something that not every shop uses, there will be a lot of sunk cost into having brought everyone into the fold, and you end up being an "OCaml shop" or "Haskell shop" or whatever. Productivity will probably normalize, but I'm not sure I want to go down that route. OCaml looks to me like the most promising functional language with the fewest warts, the most pragmatic approach to real-world apps, and possibly the best performance. But it's not a simple language, with a learning curve that's similar to Haskell. I also have to say that like Erlang, the toolset and syntax occasionally feels antiquated (for example, there's no excuse not to provide a modern readline-enabled REPL). OCaml still is not good at concurrency. Scala has some good parts, but is overdesigned and way too complex, in my opinion. Last I checked, performance was worse Java. It also runs on the JVM, which means its memory usage is inherently inefficient. F# is a language that I like a lot; in some ways it looks like a more pragmatic Haskell, or Ocaml with a cleaner syntax. I don't like the fact that it's tied to .NET, which (like Java) means it inherits all the issues from that platform. The performance on Mono looks unsatisfying. Haskell is also a language I like a lot — at least in theory. I've been disappointed with performance and memory usage (and the ability to reason about those things). The tools for concurrency (and OTP-type distributed networking) also seem very much lacking. Whenever I see an example of parallel async code in Haskell, I feel like I'm reading an advanced physics paper. While I like and understand the approach to purity, I feel like the tools get in the way of programming; that I have to work at getting in and out of effectful code just so that I can stay pure, and for what reason? Bugs caused by side effects is something I encounter only a few times a year, if that; Haskell builds a huge wall to solve something that isn't a problem for me. Nor do I enjoy that laziness is the default. Finally, there are parts of the language that seem immature; the well-known data record namespacing issue (being fixed?), and the sheer awkwardness that comes with trying to implement certain things (like polymorphic collections and directed graphs) that should be simple, but aren't. Still, it's a beautiful language, but not one I would use for everything. Clojure is the JVM, again. It's also not statically typed. From everything I've seen, performance is worse than Java.

acconsta 11y ago
With OCaml, that depends what you mean by concurrency. There's good async IO, but the runtime is still single threaded (just like Node!). The overall library ecosystem is a disappointing though. https://github.com/janestreet/async https://github.com/janestreet/async And it is a huge shame F# doesn't work well cross platform. Hopefully we'll see the runtime ported soon. Looks like it builds, but the tests are probably a mess: https://github.com/dotnet/corefx https://github.com/dotnet/corefx Haskell, yeah, very much agreed. Hopefully one day a big company will build us a modern language with a vibrant ecosystem. Microsoft has come the closest with F#. Rust is tentatively exciting, but who knows if Mozilla has the muscle to get it adopted.
- lobster_johnson 11y ago
  Yes, I was referring to OCaml's single-core limitation. I was under the impression that some smart people working right now on removing the global lock, though?
nickbauman 11y ago
Using a language that isn't already in every shop may limit hiring at first glance, but it will automatically select for folks who have an important sense of craft for the work they do and pay close attention to where there is a lack of return on investment in languages, platforms and applications. People who really care about FP will likely be easier to retain than those who use Blub and couldn't care less. Go is shiny right now. What will be shiny later? Lisp is not shiny but it is power like power has never known with Blub. Aside: I've not found Clojure to be slower than Java and I've benched it. It is fast, fast, fast. As fast as Go even doing the concurrent thing: benched that too. I've even found that Clojure can edge out Java in many cases because of its inherent laziness: the fastest way to expedite a job is not to have to do it in the first place.