I have been using Elixir for the past more than 2 years and got say that it has an awesome ecosystem for overall web development, I've been using and writing open source libraries and they are looking pretty solid as well. The company I work for also uses it as its main backend for the past almost 3 years and it has been working nicely since then. Hiring also got way easier, not only because of the existing developers using it already but also because the interest on it has increased.
I second that Elixir's ecosystem is exceptionally great for such a young language. I love working with it.
That said, I'd wager it can hardly be called a functional language. Sure, you can't write for loops, but every Elixir process encapsulates a little piece of mutable state. Elixir and its ecosystem allow and encourage you to have (very) many processes, and thus many global singleton-like pockets of mutable state. It's a powerful and pragmatic concept, it works very well, but it doesn't really feel very functional.
The most extreme example of this design philosophy is a Elixir standard library module called "Agent", which is just a cute name for "global mutable variable". When used with care it's a very handy tool but, well, functional? Nah :-)
While I don't disagree entirely, I find that Elixir is actually quite functional. Using processes for state as if they're objects is generally considered bad practice.
> But before starting, since this is going to be a long article, I want to immediately share my main points:
> Use functions and modules to separate thought concerns.
> Use processes to separate runtime concerns.
> Do not use processes (not even agents) to separate thought concerns.
> The construct “thought concern” here refers to ideas which exist in our mind, such as order, order item, and product for example. If those concepts are more complex, it’s worth implementing them in separate modules and functions to separate different concerns and keep each part of our code focused and concise.
> Using processes (e.g. agents) for this is a mistake I see people make frequently. Such approach essentially sidesteps the functional part of Elixir, and instead attempts to simulate objects with processes.
Clojure! the thing I like most about a lot of the libraries is how they seem to blend so seamlessly. I don't know if it's an artefact of just being a lisp or just a lot of the developers sharing a mindset, but the whole experience feels less janky.
I prefer Clojure as well. I'd say that Elixir probably has the better ecosystem, though, as it seems almost exclusively focused on web development via Phoenix the way Ruby was via Rails. Sure, you could use it for other things, but that is its primary use case. I'm not sure what Clojure's primary use case is.
That said, if I had a choice I'd choose Clojure every time. I just enjoy it so much more. And it has a lot of good web options: you can easily write REST APIs via Ring, build your front-end in re-frame, and use Lacinia for GraphQL endpoints.
To the OP, I'd highly recommend checking out Elixir and Clojure and spending a little time with each before ruling either out.
agree. Once I discovered Clojure, it's all kinds of fun to write in! The community is great. The ecosystem now has plenty of robust libraries to handle most any heavy-lifting task(s).
If you want to play around with getting up and running with a functional clojure backend, I put up this:
Well, IMHO It's F#. F# is really good due to it's better tooling and you have access to the plethora of libraries and framework of the .NET Ecosystem. Unlike Scala or Kotlin, F# retains a lot from it's functional roots like
- Automatic Currying
- ML Type System
Plus it adds some really innovative features like
- Type Providers which allows you to lazily/automatically generate Types for real world data/systems which is pretty cool.
Ultimately it boils down to the Runtime/Tools/Ecosystem which is also true for Scala and Kotlin but it retains a lot from it's OCAML Heritage which makes it lean more towards FP than it contemporaries
PS - I didn't mention clojure as I don't consider dynamic languages a good fit for building large codebase backend systems
We at Crowded (https://crowded.co) have had some very good successes with running F# on .NET Core, both with giraffe and just bare ASP.NET Core. The ecosystem has no shortage of good tooling and libraries, all well maintained by knowledgeable authors.
Application performance and our development productivity is excellent, osx/linux tooling took a while to mature but is only getting better than ever now.
The choice we made when .NET Core was still in development (pre 1.0) for it to become our main stack is definitely paying off!
Elixir/Erlang are one among best functional programming languages for web today. Phoenix is a very performant and productive web framework. You can build a typical web app really fast using Phoenix and Elixir.
Well, the erlang vm is what runs Elixir apps. Elixir runs on the erlang VM (called BEAM) similar to how scala/clojure run on the JVM. However, while writing a lot of elixir code you end up using the erlang standard library for things which are not available in Elixir, :crypto is a module which comes to mind. Elixir apps at the end of the day are erlang apps.
I find .NET Core (particularly ASP.NET Core with F# via Giraffe - https://github.com/giraffe-fsharp/Giraffe) extremely good since Microsoft went all open source. I have multiple backends running in a GCloud Kubernetes cluster and develop all my stuff from a non Windows environment. Couldn't be more happy and the speed of ASP.NET Core with Giraffe is fantastic (~100K r/s).
I'd like to add that with F# you get all the benefits of an extremely mature web stack with asp.net core and a huge eco system of very high quality libraries. Frameworks like Giraffe, Suave or Freya make it all possible to write your backend in a functional idiomatic way. Also a big plus for F# is the choice of top notch tooling. You've got Visual studio which works on Windows and Mac, then JetBrains Rider which is awesome and Visual studio code with the Ionide extension. I'd highly recommend anyone to go and check it all out!
JSON.NET is the standard library for handling JSON on the .NET platform, and to my knowledge it's available for both .NET Core and for use with F# collections.
I've never used F# on .NET Core, but I'd be surprised if it didn't work.
Yep F#, the language, works all right in .NET Core 2.0. Some libraries, particularly, type providers, not yet, but they are working, on it. And JSON.Net also works fine on .NET Core.
Chiron is what I've been using. I like it because it's simple which means I can understand it. Currently using it with fable elmish architecture, again because it's simple and i understand it.
F#, first because its ecosystem is the whole .NET Framework world of libraries, utils, etc. Second, because it's got its own set of very functional libraries like suave.io for web apps/services, FSharp.Data for consuming data of diverse sources/natures, Fable.io an elegant JavaScript transpiler. Finally, with very demanding production projects like jet.com it already has proved that it can process massive amounts of transactions.
The only circumstance under which I can imagine someone calling Go "functional" is that, yes, it has first-class functions and closures. But if that's your definition of functional, the term is almost useless because in the modern language landscape, there's pretty much just two or three languages that would not qualify as functional. Sure, they happen to still be the top 3 languages (Java, C, C++), but that would make the entire rest of the landscape functional. Java of course recently grew closures, and C++ has... things... you can do if you really want closures, which would really leave only C as not having closures. Though if you're willing to go so far as to call Go functional, you're not that far from calling C functional because it has function pointers. (In 2018, that may not sound that impressive, but in the 1970s that put it at "at least modestly functional" by the standards of the time.)
The OP specifically asked for a functional language, though. Java and Kotlin have adopted some ideas from functional languages, but they aren't themselves functional languages, and their HTTP frameworks certainly aren't designed along functional lines.
Scala is, amongst other things, a functional language. How much to its HTTP frameworks embrace that?
Another one for Scala. Between Play which is a full blown framework and bare bones akka-http you have every possible scenario covered. Also Slick for database access is a great library to make a full combo. Put on top of all that access to every imaginable library that exists in JVM ecosystem and you have a clear winner.
Third party resources can be sort of out of date; your first link is from 2014, and therefore has a bunch of inaccuracies. Your second was last updated last Octoboer, so not so much, but is still missing out on stuff.
Yes, the first link is only for the part about some saying that you could call Rust functional. Should probably have specified that in my original comment.
* the h2 crate was released last week, which adds http2 support to the ecosystem
* the frameworks page is missing, off the top of my head, shio and actix. It also includes pencil, which has been abandoned for a long time.
* It includes nothing about Rust's fairly recent wasm support and all of the crates that let you work with that
In general, this is an extremely active area, with few "winners" so far, and crates.io is adding roughly 23 crates a day, though obviously not all web-related. There's just so much stuff all the time that keeping a curated resource like this up-to-date is a lot of work.
I second F#. You have access to the full .NET Standard library as well as all of the open source libraries available. I personally found it more of a joy to use than Scala, but that may be due to my knowledge of and experience with .NET.
F# on .NET Core is stable and there are templates for an F# web application.
I also find F# a joy to work with. Not only because it's .NET which I find nicer to work with than the JVM, but also because it feels more well thought out and less every feature except the kitchen sink, like Scala. They're both great languages though. Scala >> Java, and F# > C# (more due to C# already being better than Java).
I'm an experienced Scala dev but after reading the "fun and profit" ebook F# looked really interesting. Naturally I tried to take the next step of creating a small webapp with it on a Linux dev machine. Unfortunately I ran into a lot of problems identifying and setting up the needed tools and frameworks on Linux and eventually gave up. My assumption was that the tooling+frameworks were likely "not quite there yet" (late 2017) for Linux but I'd love to be proven wrong. Any suggestions for an up-to-date tutorial on "web development using F# on Linux"?
Thanks for the pointers, I will definitely check both of these out. In my last attempt I got to the "can compile 'Hello World' from the command line and even debug it in VSCode" stage but after that things quickly went off the rails IDE-wise. I even tried MonoDevelop (did some C# work with it long ago) but IIRC the Xamarin stuff was barfing on one or more asp.net dependencies. Hopefully one of your links will be to an "Idiot's guide to F# on Linux" and then I'll be in good shape. :-)
I'm glad to hear that, I will definitely try again. F# looks pretty sweet and I have a couple of half-baked Scala side-projects that might port nicely to F# and Suave.
Been using F# in a web-backend capacity for about two years now. Language is great, hits a very sweet spot when it comes to productivity, tooling (F# has some of the best dev tools out there), etc. Interop with the rest of .NET is pretty much seamless, so there's no lack of good libraries.
I'd say that in terms of ecosystem, anything running on the JVM is probably going to be the broadest; that is, you'll have the most choices (mostly Java libs and frameworks) to decide from. In terms of functional libs/frameworks, that number will drop a lot, but in practice you'll probably have what you need.
If the JVM or Scala/Clojure doesn't sound like a good time, F# is a good option (I'm biased as I work on it). The ecosystem is similar in that most libs/frameworks on NuGet are for C# developers, but in practice you really won't need them for a web service. Giraffe, Suave, and Freya are three choices that will run on .NET Core today.
Giraffe and Suave are likely to be easier for a newbie, and both have the "Suave programming model" for API routing, so you'll find the way to set things up is very similar (despite a few different names, such as WebPart and HttpFunc). Both run on .NET Core as well. The main difference is that Giraffe sits atop the Kestrel HTTP server which ASP.NET Core is built on, whereas Suave has its own web server implementation.
Eco-system-wise you might want to try compiling from a functional language to JS and target Node.js -- Bucklescript or GHCJS would be my choices. That way you get access to all of the libraries on NPM.
I've been using Clojure on the backend for about 5 years now and find it an absolute joy to work with, having come from a Java background. You get full access to the masses of Java libraries out there as it's on the JVM. Great community support, too.
As an addition, there's also ClojureScript for the front-end. It's come a long way recently, and I've been using it for the last couple of years in production (check out reagent and re-frame if you're interested).
I wouldn't call its ecosystem great, but if you like complex type hackery and don't need to do anything very complicated, Ur/Web can get you quite far.
It's very hard to learn, especially if you're not that familiar with Haskell and SML/OCaml, but once you grok it writing CRUD apps is a breeze. Just be prepared to spend a lot of time looking at the standard library's signature files.
Do note, that some functional languages have good out-of-the-box support for both backend and frontend. An this is not negligible. I'm using F# which in combination with Fable (F#->.js transpiler) lets me really quickly share code, datastructures and serialization with frontend code.
Now, I'm a primarily a backend developer. But sometimes it is just really convenient to be able to hack together an in-house real-time data-analysis or reporting service and render statistics as webpages rather than .csv documents.
If your frontend team is functional as well, then the benefits of sharing the language could be even bigger.
Sure, not everything is perfect in the F# world. However having the possibility to share code with frontend saves me more time than I spend in fighting with the F# ecosystem. And also: programming in F# is just fun joyful. And productive.
Lisp ecosystem is really mature and gives you a lot of freedom.
Dynamic typing, interpeted language, homoiconity, tons of great battle-tested libraries etc., Lisp is truly a great language for backend web development.
Even this very site runs on a homebrew lisp dialect (Arc) running on Dr. Racket (Scheme). If even that bizarre setup (sorry PG :)) can handle this much traffic on a single server, you shouldn't worry about speed or scalibility if you opt for Common Lisp.
Interpreted language? Common Lisp is typically compiled. Besides which, why is interpreted a particular advantage? e.g. Python was interpreted 10 years ago when I was using it, but Common Lisp felt far more flexible and powerful, because you can compile single functions with a key press in SLIME and seamlessly load them into your running (compiled) image... shortest feedback loop I've ever experienced. Maybe Python has caught up in the mean time, I haven't used it seriously for a long time though, so I don't know.
I instinctively used the "interpreted" term, because mainly you can execute instructions on the fly in an interpreter the language ships with. Whether it's compiled to bytecode and then executed from there is IMHO an implementation detail. With compiled languages (following this logic) such as Java or Go or C, you need to write your program pass it through a compiler to get an output.
With languages like Javascript, Lisp, Python, Ruby etc. you can write your programs incrementally, going back and forth between the REPL.
Sorry if my terminology has caused you trouble. I regard dynamically typed languages that ship with an interpreter as interpreted languages. For optimization reasons the implementation probably uses some sort of compilation but you can still use the built-in interpreter on all of these "interpreted" languages.
I should probably have used the term "ships with an interpreter" :)
BTW the current python-mode in Emacs also allows SLIME-like behaviour. You can open a python process with C-c C-p and then send the buffer, functions, marked areas, lines etc. to the python session.
Well, SBCL does not ship with an interpreter, for example. Expressions entered at the REPL get compiled directly to machine code, so there's no difference in performance for a function entered at the REPL (or via SLIME C-c C-c) and one built as part of a batch compile.
Contrast that to Haskell's ghci interpreter, which is slower (last time I checked) than the same code built on the command line with ghc, the compiler. But I would still consider Haskell a compiled language, not an interpreted one, since you never run code in production under ghci, you always ship your binaries.
I suppose it's about perception. To me "interpreter" refers to a language implementation strategy. It's fuzzy, I know, since there is some continuum between interpreting an AST directly, compiling the AST to bytecode and running the bytecode on a VM, JIT compiling the bytecode to machine code on the fly, and compiling offline direct to machine code (like C/Go/Rust). To some ears, "interpreted" can sound synonymous with "slow", which is I guess what prompted my comment.
Finally, to me the place where you can enter expressions to try out your program interactively is the REPL, not the interpreter.
Anyway, thanks for explaining your position to me. (Also, good to know Python dev environments have improved, but I guess it's to be expected, 10 years is a long time :-) .)
I got excited by both Elixir and Clojure, but vastly prefer Elixir. That said, Clojure would probably be my second choice and one major advantage is that ClojureScript would allow you to also build out the front-end in the same language. As far as I know Elixir's equivalent, ElixirScript, is nowhere near ready enough for that.
There’s a huge difference between being a functional language and supporting functional paradigms.
Nearly every major language does the latter, but if you consider immutability a key functional feature, for example, you’ll sorely miss it when the language doesn’t really support it.
> but if you consider immutability a key functional feature ...
Fair point. I have to say that I appreciate both the
libraries [1] and resources [2][3] concerning functional programming in the javascript community. The functional
reactive programming movement is a neat example where we can
find functional ideas brewing [4].
Say someone decides that vanilla JS isn't enough. They can play with functional first languages that transpile to JavaScript [5][6].
Or use something like Immutable.js, but enforcing immutability on anything but a tiny project is likely to go awry. Takes a lot of discipline from everyone involved.
Have they sorted the differences with async/await? I'd be using if it wasn't from the different implementation meaning you need to use typescript to babel.
