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.
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.
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?
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.)
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.
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.
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.
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:
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.
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).
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"?
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.
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. :-)
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.
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.
> 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].
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.
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.
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.
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 :-) .)
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'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.
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!
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.
79 comments
[ 4.5 ms ] story [ 144 ms ] threadIf you want purely functional, both haskell and clojure do have a good backend community and quite a few good tools.
There may be other options depending on whether you consider JavaScript or Go to be a functional language.
Spring boot (Java) is also very decent, and Play and akka-http have both first-class Java and Scala API's.
Kotlin has the same JVM advantage.
Scala is, amongst other things, a functional language. How much to its HTTP frameworks embrace that?
Do you consider Java a functional language?
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 :-)
I can highly recommend this article (also just in general for people curious about Elixir): http://theerlangelist.com/article/spawn_or_not
A quote:
> 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.
https://www.yesodweb.com/book
If you want to play around with getting up and running with a functional clojure backend, I put up this:
https://github.com/tuddman/moarweba
feedback welcome
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.
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).
http://science.raphael.poss.name/rust-for-functional-program...
Rust has an ecosystem for building web backends.
http://www.arewewebyet.org/
Does Rust have the best ecosystem for a web backend, though? I think that will depend on who you ask and what you are looking for specifically.
* 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.
F# on .NET Core is stable and there are templates for an F# web application.
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.
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].
[1] http://ramdajs.com/
[2] https://www.gitbook.com/book/drboolean/mostly-adequate-guide...
[3] https://leanpub.com/javascript-allonge/
[4] https://cycle.js.org/
[5] http://elm-lang.org/
[6] http://www.purescript.org/
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.
I've never used F# on .NET Core, but I'd be surprised if it didn't work.
For example you might be interested in: http://8arrow.org/caveman/
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.
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.
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 :-) .)
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.
I wrote a blog post about using Giraffe here: https://blogs.msdn.microsoft.com/dotnet/2017/09/26/build-a-w...
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!
Do you need some sort of rest-like HTTP API? Highly suggest Haskell and the Servant framework! It's amazing.