5 ms·

Can someone explain to me why Haskell will ever be viable as a fullstack language? I have done a few toy projects in Haskell, and it has taught me some great f

by dexwiz 11y ago

Can someone explain to me why Haskell will ever be viable as a fullstack language? I have done a few toy projects in Haskell, and it has taught me some great functional programming concepts that I now apply to other languages. But, purely functional programming seems to work 90% the time, but the other 10% is so negative it invalidates the rest. Edit for clarification: Full Stack would be app server up. So runs a server (some sort of process/thread/worker management), server scripting is in the same language (can auth, process requests, interact with a DB, etc), and build the view (simple JSON/blob response, build html, etc). I exclude client side form this, since most of the X for client-side projects end up transpiling into JS.

jkxyz 11y ago
Care to elaborate on what the 10% covers? I can see a few places where pure functional programming might not be as clear as imperative code, but I don't think that it invalidates the possibility of using it for large projects.
rifung 11y ago
I think most people would argue that it's useful when you want your code to be very maintainable or stable. I think right now the lack of educational materials and overall difficulty of learning it make it impractical for industry use unless you plan on only having a very small team. I don't know what 10% you are referring to but I personally find performance analysis to be a huge issue due to the laziness. I suspect this is largely due to the lack of educational materials which is why I'm a little skeptical that the release of one book will suddenly make it all okay as the article seems to suggest. Still, I find the language itself a complete joy to use and use it almost wherever I can.
mbrock 11y ago
What does full stack language mean in this context?
akurilin 11y ago
Would be interesting to know what you found to be the very negative 10%, maybe we can help.
kyllo 11y ago
Can someone explain to me why Haskell will ever be viable as a fullstack language? It already is. If you are talking about a full stack web application, there are several fully featured production quality frameworks, Yesod being the most popular. What are the negatives to you? Long compile times? Monadic IO? Memory leaks from lazy eval?
- lvh 11y ago
  I'm guessing the poster included being able to do front-end work in Haskell. elm and purescript might be plausible front-end languages, but ghcjs isn't really there yet.
  - kyllo 11y ago
    Picking any compile-to-JS language (not counting ES6/7) is a risky proposition though. There are a lot of people regretting their five year-old "legacy" coffeescript applications today. GHCJS is improving at an astonishing rate, but at this point I still wouldn't use any compile-to-JS language for a serious production application. There's too high of a risk of building something that becomes unreasonably expensive to maintain in a few years.
    - chadaustin 11y ago
      While I use ghcjs for one of my projects, have been a big user of Emscripten in the past, and recently switched from a CoffeeScript project to a TypeScript project at work, I understand what you're saying, but I think it's an overstatement. Compiling to JavaScript is totally okay if the new language 1) adds something meaningful (like a type system [TypeScript, js_of_ocaml] or the ability to conveniently deal with unboxed data [LLJS, Emscripten]) and 2) does not have a significant runtime overhead. GHCJS, in particular, adds a _huge_ amount of runtime overhead, largely because JavaScript doesn't (yet) support tail calls so the CPS transform must be trampolined. In addition, laziness doesn't make a lot of sense for frontend code, which generally should be as tight as possible. Also, look at the code produced by ScalaJS sometime and weep. :D js_of_ocaml, on the other hand, produces extremely tight code, and is very suitable for building web frontends. Of course, OCaml probably has a similar learning curve as Haskell. I can't imagine people would get excited about the syntax. TypeScript is a sweet spot: it's got some value over straight up ES6, but it's easy to integrate and has a very short learning curve.
sseveran 11y ago
I use it as a fullstack language at work. I bumped into the 10% when I was a beginner, but no more.
tathougies 11y ago
I use Haskell exclusively on my SaaS app (http://sostenoto.com http://sostenoto.com). The backend not only provides a simple REST API, but it also provides WebRTC signaling and a real-time graphical communications and presence protocol. Haskell makes it so easy to write correct concurrent code it's not even funny. GHC's magnificent IO manager means I can handle 1000s of connections on one amazon instance. Can't understand why you wouldn't be using Haskell for server-side web development. No other popular server-side language supports concurrency (see STM, MVar's, and Chans), transparent futures/promises for I/O (the entire IO monad in GHC is non-blocking), support for multiple processors (Just add +RTS -N<n> to make your program scale to n processors), and a blazing fast HTTP server (warp).
- andruby 11y ago
  Elixir is getting increasingly popular as a server-side language with Phoenix. It has great concurrency, futures (Tasks [0]), smp and a fast http server (cowboy [1]). [0] http://elixir-lang.org/docs/v1.1/elixir/Task.html http://elixir-lang.org/docs/v1.1/elixir/Task.html [1] https://github.com/ninenines/cowboy https://github.com/ninenines/cowboy
  - zeckalpha 11y ago
    But limited static analysis.
    - cubahacker 11y ago
      why should I want to have static analysis?
- johan_larson 11y ago
  > Can't understand why you wouldn't be using Haskell for server-side web development. I can't tell whether that's just a rhetorical flourish, so I'll answer straight. To begin with, there are a couple of concerns that might kill an attempt to use Haskell. 1. I might not be able to get management approval. Haskell is an obscure language with a reputation for difficulty. The bosses might well say no. 2. I might need to work with an existing codebase in something like Java or Python. Not possible from Haskell. If those don't kill the project, there's the cost-benefit tradeoff. On the benefits side: 1. Haskell code is very concise. (definitely) And greater concision means faster development. (possibly) 2. Haskell code is less likely to contain errors, because of very strict typing. (probably) 3. Haskell coders are disproportionately capable, because the language is obscure and difficult. (probably) On the costs side: 1. I have much more experience in other languages. It would take at least a year, maybe two before I'd be up to pro standards in Haskell. 2. The community of Haskell programmers is small. It might be difficult to hire anyone if the project grew; I might be faced with training someone from scratch, not just in a new language, but in a new programming paradigm. So, this isn't anything like a slam dunk. Quite the opposite, actually. There are a couple of issues that might nix the project right up front, and then a daunting cost-benefit calculation.
dudul 11y ago
What is the 10% that is no negative? I've been using FP for 6 years now (not in Haskell though) and never looked back.
emergentcypher 11y ago
Really? What is this 10%? We're using Haskell for server-side programming at my work and it's been fantastic. Functional programming is so well suited for stateless web services.
nickpsecurity 11y ago
"Full stack would be..." For us older engineers, full-stack was hardware up to OS up to apps. Quite a few projects did that. Haskell is more full stack via that definition given it can build hardware (Bluespec), OS's (House), system code (Ivory), and web apps. Worst case, use it as a DSL to output the language of your choosing like 4GL's used to.
bootload 11y ago
"Can someone explain to me why Haskell will ever be viable as a fullstack language?" Aside from the solid compiler ghc and many libraries, the ability to write less, more reliable software. That's the objective isn't it? Another reason is the increasing number of usable languages written in Haskell. Using say Purescript, elm or other front-end languages, it may be as important as knowing Haskell as know C is for Python, for example.

by dexwiz 11y ago

jkxyz 11y ago

Care to elaborate on what the 10% covers? I can see a few places where pure functional programming might not be as clear as imperative code, but I don't think that it invalidates the possibility of using it for large projects.

rifung 11y ago

I think most people would argue that it's useful when you want your code to be very maintainable or stable. I think right now the lack of educational materials and overall difficulty of learning it make it impractical for industry use unless you plan on only having a very small team. I don't know what 10% you are referring to but I personally find performance analysis to be a huge issue due to the laziness. I suspect this is largely due to the lack of educational materials which is why I'm a little skeptical that the release of one book will suddenly make it all okay as the article seems to suggest. Still, I find the language itself a complete joy to use and use it almost wherever I can.

mbrock 11y ago

What does full stack language mean in this context?

akurilin 11y ago

Would be interesting to know what you found to be the very negative 10%, maybe we can help.

kyllo 11y ago

Can someone explain to me why Haskell will ever be viable as a fullstack language? It already is. If you are talking about a full stack web application, there are several fully featured production quality frameworks, Yesod being the most popular. What are the negatives to you? Long compile times? Monadic IO? Memory leaks from lazy eval?

lvh 11y ago
I'm guessing the poster included being able to do front-end work in Haskell. elm and purescript might be plausible front-end languages, but ghcjs isn't really there yet.
- kyllo 11y ago
  Picking any compile-to-JS language (not counting ES6/7) is a risky proposition though. There are a lot of people regretting their five year-old "legacy" coffeescript applications today. GHCJS is improving at an astonishing rate, but at this point I still wouldn't use any compile-to-JS language for a serious production application. There's too high of a risk of building something that becomes unreasonably expensive to maintain in a few years.
  - chadaustin 11y ago
    While I use ghcjs for one of my projects, have been a big user of Emscripten in the past, and recently switched from a CoffeeScript project to a TypeScript project at work, I understand what you're saying, but I think it's an overstatement. Compiling to JavaScript is totally okay if the new language 1) adds something meaningful (like a type system [TypeScript, js_of_ocaml] or the ability to conveniently deal with unboxed data [LLJS, Emscripten]) and 2) does not have a significant runtime overhead. GHCJS, in particular, adds a _huge_ amount of runtime overhead, largely because JavaScript doesn't (yet) support tail calls so the CPS transform must be trampolined. In addition, laziness doesn't make a lot of sense for frontend code, which generally should be as tight as possible. Also, look at the code produced by ScalaJS sometime and weep. :D js_of_ocaml, on the other hand, produces extremely tight code, and is very suitable for building web frontends. Of course, OCaml probably has a similar learning curve as Haskell. I can't imagine people would get excited about the syntax. TypeScript is a sweet spot: it's got some value over straight up ES6, but it's easy to integrate and has a very short learning curve.

sseveran 11y ago

I use it as a fullstack language at work. I bumped into the 10% when I was a beginner, but no more.

tathougies 11y ago

I use Haskell exclusively on my SaaS app (http://sostenoto.com http://sostenoto.com). The backend not only provides a simple REST API, but it also provides WebRTC signaling and a real-time graphical communications and presence protocol. Haskell makes it so easy to write correct concurrent code it's not even funny. GHC's magnificent IO manager means I can handle 1000s of connections on one amazon instance. Can't understand why you wouldn't be using Haskell for server-side web development. No other popular server-side language supports concurrency (see STM, MVar's, and Chans), transparent futures/promises for I/O (the entire IO monad in GHC is non-blocking), support for multiple processors (Just add +RTS -N<n> to make your program scale to n processors), and a blazing fast HTTP server (warp).

andruby 11y ago
Elixir is getting increasingly popular as a server-side language with Phoenix. It has great concurrency, futures (Tasks [0]), smp and a fast http server (cowboy [1]). [0] http://elixir-lang.org/docs/v1.1/elixir/Task.html http://elixir-lang.org/docs/v1.1/elixir/Task.html [1] https://github.com/ninenines/cowboy https://github.com/ninenines/cowboy
- zeckalpha 11y ago
  But limited static analysis.
  - cubahacker 11y ago
    why should I want to have static analysis?
johan_larson 11y ago
> Can't understand why you wouldn't be using Haskell for server-side web development. I can't tell whether that's just a rhetorical flourish, so I'll answer straight. To begin with, there are a couple of concerns that might kill an attempt to use Haskell. 1. I might not be able to get management approval. Haskell is an obscure language with a reputation for difficulty. The bosses might well say no. 2. I might need to work with an existing codebase in something like Java or Python. Not possible from Haskell. If those don't kill the project, there's the cost-benefit tradeoff. On the benefits side: 1. Haskell code is very concise. (definitely) And greater concision means faster development. (possibly) 2. Haskell code is less likely to contain errors, because of very strict typing. (probably) 3. Haskell coders are disproportionately capable, because the language is obscure and difficult. (probably) On the costs side: 1. I have much more experience in other languages. It would take at least a year, maybe two before I'd be up to pro standards in Haskell. 2. The community of Haskell programmers is small. It might be difficult to hire anyone if the project grew; I might be faced with training someone from scratch, not just in a new language, but in a new programming paradigm. So, this isn't anything like a slam dunk. Quite the opposite, actually. There are a couple of issues that might nix the project right up front, and then a daunting cost-benefit calculation.

dudul 11y ago

What is the 10% that is no negative? I've been using FP for 6 years now (not in Haskell though) and never looked back.

emergentcypher 11y ago

Really? What is this 10%? We're using Haskell for server-side programming at my work and it's been fantastic. Functional programming is so well suited for stateless web services.

nickpsecurity 11y ago

"Full stack would be..." For us older engineers, full-stack was hardware up to OS up to apps. Quite a few projects did that. Haskell is more full stack via that definition given it can build hardware (Bluespec), OS's (House), system code (Ivory), and web apps. Worst case, use it as a DSL to output the language of your choosing like 4GL's used to.

bootload 11y ago

"Can someone explain to me why Haskell will ever be viable as a fullstack language?" Aside from the solid compiler ghc and many libraries, the ability to write less, more reliable software. That's the objective isn't it? Another reason is the increasing number of usable languages written in Haskell. Using say Purescript, elm or other front-end languages, it may be as important as knowing Haskell as know C is for Python, for example.