if you were to pick up a single new language to learn and use in real world server side applications. Which one would you pick, Haskell or Google's go?
I personally think that these two languages were built to do different things. I think it depends on the job that you have and what you need the language to accomplish in order to say which language is better to learn.
I chose Go, because I'm a Web Developer and if I ever needed to do low level stuff I would use Go or Java.
Really though it's less about which language you choose and more about which programming paradigms you've studied: functional & oop for example. Personally I'd find learning Haskell entertaining, but not very applicable to my day-to-day enterprise software gig.
> Personally I'd find learning Haskell entertaining, but not very applicable to my day-to-day enterprise software gig.
I'm interested in Haskell - what exactly is lacking about it? Is its design fundamentally flawed, or does it just lack a community and all the things that come with that (libraries, support websites, etc.)?
What kind of "server side" application? As a systems developer many of my applications would be more suited to Go. The biggest problem with Haskell's lazy evaluation system in real world analyses is that performance is unpredictable. While I would strongly consider using Haskell for an academic publication (e.g., my master's thesis), I would be more cautious about using it in a systems capacity. Then again, my assumption for most of HN is that we're not talking about systems development, it's just that Go is directly targeted at systems development.
Haskell with a cleaned up library and eager evaluation would be a dream. Alternatively, adding type classes to OCaml (and removing the object system) would yield a similarly awesome language.
FYI, Haskell was originally created as an extension of Miranda, basically a testbed for lazy functional languages. Removing lazy evaluation seems almost like killing the language.
I would try and expand my Haskell knowledge; Go is too similar to languages I already know. I would take this as an opportunity to learn. Erlang would be the other choice.
This is not to say that Go doesn't have a lot to teach me; it's just that I would be more interested in the semantics of building large systems in a language/environment that's utterly alien from those I've done before.
For the "real world" applications I think you should at least consider Scala and Clojure also. Because they're both JVM based you can rely on the Java infrastructure that's been built up over the past 15 years.
If you're doing web development, or network applications, NodeJS is also notable, there's a reason it's getting a lot of attention lately, the fun-factor is just off the charts.
Haskel is beautiful language, but I voted Go because side effects in Haskel are pain and if you want language to the server I suppose it is because of doing side effects (like working with db or files, changing memory, serving webpages etc).
Plus Go has easy conurrency via message passing, which is nice to have these days.
This is a rather limited poll, but if the choice is between Haskell and Go I'd pick Haskell for a web application, and Go for small things that need to be fast (like receiving and sending messages in a chat application). Go is too low level and generally not a very well designed language. It's a nice improvement over C, but it keeps far too much from C for my tastes.
For me, Go has replaced C++ and Java for systems work. All of my projects at work for the past 6 months have been done in Go. I don't think we'll be going back.
But, really, good systems are based on well-defined protocols, which makes the language choice moot. (If you're passing Java or C++ objects over the wire, shame on you!)
I work on large distributed systems. I've found that Go is a much cleaner and simpler language than C++ or Java, by far. You get the compiled speed and control over memory layout of C++ with the garbage collection of Java. The concurrency model in Go is a natural fit for programs that make heavy use of disks and networks; it neatly sidesteps the threads vs events debate (and both of those can lead to some nasty programs). But most of all, the language is pleasant to use and the compilers are really fast (ever tried to compile a million line c++ or java source tree?).
I've had issues with lazy IO that caused awkward behaviour. Identifying the root cause was not trivial, and altogether, laziness gave me no benefit and caused me lots of harm. This is the most important point here: when laziness is useful very rarely but causes non-trivial trouble often, why on earth have it on by default?
I'm sorry that I cannot remember the specifics of my problems, this project was done years ago.
Would ya'll be willing to give feedback on a similar thing I'm struggling with?
I've been contemplating this same question a lot of the past few months. As many readers point out, the type of application you're writing weighs heavily on what language and tools you should use.
The application I'm writing is a persistent world server for a game. The world server will need to be composed of multiple servers cooperating. Here are the languages I've been looking at:
- Erlang. I really wanted to use this, but just felt so constricted not even being able to do a loop. I realized later after much work that this feeling is simply because I hadn't (and still haven't, sufficiently) manned up and become comfortable with functional programming. The OTP framework is beyond compare for quickly building reliable distributed systems. Actors are a perfect fit for being part of the puzle for this target application of writing a distributed game world.
- Scala. Like erlang, plus the ability to use awesome java things such as Netty and Zookeeper. Lacks OTP, so a lot of the things Erlang has built in like distributed actors are missing. The Akka project seems to be targeted at bringing the missing things into Scala. For a while I felt that I had finally found the perfect platform for doing my server: Scala + Akka. But then I started finding that I was going to have to roll a lot of my own things (e.g. http://stackoverflow.com/questions/3692680/scala-akka-how-to...). Plus I started feeling like the Scala language is kind of more complex than it needs to be. Perhaps I wouldn't feel that way after working with it for a few months every single day.
- Clojure. The main appeal to me here is that I've long felt that I'd never be a real man until I could shoot lisp from my fingertips while laughing at all mere mortals. I've started studying lisp, including working my way through the MIT opencourseware. This is an ongoing side project. But Lately I've been thinking about just writing the software instead of trying to prove myself to the faceless elite whom I'll never meet. The most unique awesome power of Clojure to me for this application is STM, which I can get with Scala + Akka in a format that's less alien to me.
- Go. The syntax is easy. It's trimmed down and simple. Concurrency is trivial to do. There's a lot more rolling-your-own for this app, because it doesn't have built in OTP-like things for restarting failed processes, like Eralng and Scala+Akka do. What Go lacks in requiring me to roll my own, it makes up for by being lean and mean. Biggest downside to me about Go is that it seems relatively complicated to use external libraries I may want to use, such as Zookeeper. I also really grew to love Netty while using Scala, for handling tons of socket connections all at once. But perhaps I won't even need that when using Go, I'm not sure yet. I also think I'll be able to do a lot more per-megabyte of RAM using Go than I can with Scala. I have not tested that hypothesis, but plan to.
Various Python things. I considered using Stackless, but this seems like a dead end today compared to where it was a few years ago. I also looked at Twisted and worked through a book on it. I decided that if I want to do a lot of Arcane backwards tickery, I may as well use Erlang or Scala. Twisted, to me is the worst of all worlds: having to do strange arcane things, plus having it be in Python when it's done instead of compiled or JIT like Go or Scala. (Erlang gets a special pass in this context because it's so proven.)
Node.Js - I never really seriously considered this, because I really want to use an actor-style approach. (Maybe I missed the boat here, and should try this, spawning one node.js per cpu core per machine?)
Over the last year, I keep moving between Erlang, Scala, and Go, trying to figure out which I really want to use. My current plan is to write a working, mult...
I've been using Go for various things for quite a while now. I do love the language. If I would use it for any serious large scale project? Perhaps not just yet. There are still some wrinkles that need ironing out. Most notably: Go's GC.
These 'wrinkles' are not fundamental problems with the language though, and most are on the slate for fixing, so it's just a matter of time for Go to be ready for anything. Development pace is still quite furious and improvements are coming out every week.
In the meantime, I thoroughly enjoy using it for smaller tools and assorted bits and bobs. It's a very pleasant language to work with.
I would pick up Haskell. It is a more mature language, there are already quite a few companies that use it in production code.
Even thought it is a mainly a functional programming language it allows the programmer to express in a more natural way lots of programming algorithms.
It allows a more easy way to explore multiprocessor programming by contrast with Go's go routines, because of the functional semantics.
34 comments
[ 7.0 ms ] story [ 142 ms ] threadI'm interested in Haskell - what exactly is lacking about it? Is its design fundamentally flawed, or does it just lack a community and all the things that come with that (libraries, support websites, etc.)?
If you're doing web development, or network applications, NodeJS is also notable, there's a reason it's getting a lot of attention lately, the fun-factor is just off the charts.
Plus Go has easy conurrency via message passing, which is nice to have these days.
Indeed. I voted Go because learning it made writing concurrent software FUN! (As it should be)
But, really, good systems are based on well-defined protocols, which makes the language choice moot. (If you're passing Java or C++ objects over the wire, shame on you!)
I, for one, would really love to learn more about Go.
Haskell has lots of fundamental weaknesses when it comes to long-running real world programs, laziness being the most obvious one.
I'm sorry that I cannot remember the specifics of my problems, this project was done years ago.
I've been contemplating this same question a lot of the past few months. As many readers point out, the type of application you're writing weighs heavily on what language and tools you should use.
The application I'm writing is a persistent world server for a game. The world server will need to be composed of multiple servers cooperating. Here are the languages I've been looking at:
- Erlang. I really wanted to use this, but just felt so constricted not even being able to do a loop. I realized later after much work that this feeling is simply because I hadn't (and still haven't, sufficiently) manned up and become comfortable with functional programming. The OTP framework is beyond compare for quickly building reliable distributed systems. Actors are a perfect fit for being part of the puzle for this target application of writing a distributed game world.
- Scala. Like erlang, plus the ability to use awesome java things such as Netty and Zookeeper. Lacks OTP, so a lot of the things Erlang has built in like distributed actors are missing. The Akka project seems to be targeted at bringing the missing things into Scala. For a while I felt that I had finally found the perfect platform for doing my server: Scala + Akka. But then I started finding that I was going to have to roll a lot of my own things (e.g. http://stackoverflow.com/questions/3692680/scala-akka-how-to...). Plus I started feeling like the Scala language is kind of more complex than it needs to be. Perhaps I wouldn't feel that way after working with it for a few months every single day.
- Clojure. The main appeal to me here is that I've long felt that I'd never be a real man until I could shoot lisp from my fingertips while laughing at all mere mortals. I've started studying lisp, including working my way through the MIT opencourseware. This is an ongoing side project. But Lately I've been thinking about just writing the software instead of trying to prove myself to the faceless elite whom I'll never meet. The most unique awesome power of Clojure to me for this application is STM, which I can get with Scala + Akka in a format that's less alien to me.
- Go. The syntax is easy. It's trimmed down and simple. Concurrency is trivial to do. There's a lot more rolling-your-own for this app, because it doesn't have built in OTP-like things for restarting failed processes, like Eralng and Scala+Akka do. What Go lacks in requiring me to roll my own, it makes up for by being lean and mean. Biggest downside to me about Go is that it seems relatively complicated to use external libraries I may want to use, such as Zookeeper. I also really grew to love Netty while using Scala, for handling tons of socket connections all at once. But perhaps I won't even need that when using Go, I'm not sure yet. I also think I'll be able to do a lot more per-megabyte of RAM using Go than I can with Scala. I have not tested that hypothesis, but plan to.
Various Python things. I considered using Stackless, but this seems like a dead end today compared to where it was a few years ago. I also looked at Twisted and worked through a book on it. I decided that if I want to do a lot of Arcane backwards tickery, I may as well use Erlang or Scala. Twisted, to me is the worst of all worlds: having to do strange arcane things, plus having it be in Python when it's done instead of compiled or JIT like Go or Scala. (Erlang gets a special pass in this context because it's so proven.)
Node.Js - I never really seriously considered this, because I really want to use an actor-style approach. (Maybe I missed the boat here, and should try this, spawning one node.js per cpu core per machine?)
Over the last year, I keep moving between Erlang, Scala, and Go, trying to figure out which I really want to use. My current plan is to write a working, mult...
These 'wrinkles' are not fundamental problems with the language though, and most are on the slate for fixing, so it's just a matter of time for Go to be ready for anything. Development pace is still quite furious and improvements are coming out every week.
In the meantime, I thoroughly enjoy using it for smaller tools and assorted bits and bobs. It's a very pleasant language to work with.
Even thought it is a mainly a functional programming language it allows the programmer to express in a more natural way lots of programming algorithms.
It allows a more easy way to explore multiprocessor programming by contrast with Go's go routines, because of the functional semantics.