There's a lot of runtime introspection above and beyond hot code swapping. You can attach a console to a running node and inspect and modify state interactively. I'm a big fan of debugging with printfs, but if you've got a stateful server in production and you want to debug it, it's a lot easier to connect using a real REPL shell than with say gdb.
Try finding an online tutorial, but don't be afraid to ask a friend for help — if you're fortunate enough to have one that knows Erlang. The core language isn't too bad if you're familiar with FP, but the associated concepts like gen_*, supervision hierarchies, and error handling are tricky. Don't be ashamed to ask for help … it's not as straightforward as most of the languages you've learned.
Implement the things you're learning. After you learn a concept, try building something that uses that concept. If nothing comes to mind, ask someone for an assignment or find a tutorial with homework. Reading tutorials and manuals will tell you how a feature works, but you won't really understand where it's appropriate to use until you've actually used it incorrectly a few times. Experience is key; you'll probably find that after a while of programming Erlang that everything you wrote more than two weeks ago is complete crap.
Once you get into the real world use http://erldocs.com for reference. It's the same material as http://www.erlang.org/doc but presented better.
One thing is that the syntax is annoying because of use of separators instead of terminators. There's a good description here: http://damienkatz.net/2008/03/wh…
Akka embraces and extends OTP: http://akkasource.org/
The following companies have used Erlang at places where it's features fit best:
- ProcessOne, built loads of xmpp,messaging, streaming stuff on erlang
- Mochimedia built mochiweb, used by projects like Riak, Erlyweb,etc
- Yahoo within delicious, content extraction
- Amazon to build simpleDB *
- Facebook for chat, as mentioned in another answer & as part of thrift rpc
- Github data serializing, among several others
- 37 Signals ( socket related work at somet point )
- heroku *
- geodesic uses erlang which is used in mundu products such as radio, messenger, tv apps popular in some parts of the world
- [plug] hover.in btw runs on the LYME stack ( linux,yaws,mnesia,erlang )
- Basho has one the most talented erlang teams with products like riak, riak search, rebar, nitrogen web, erlang_js, etc
- Membase ( caching /nosql db which used erlang even before acquiring couchdb which was built with plenty of erlang )
- ipad video discovery app Showyou
Easiest to use and robust rarely come together in one package, particularly when talking about something like web-services. It's amazing how people always think these are so simple to set up — here lie many daemons (spelling intentional).
The simplest I've found so far is probably node.js, but it's not perfect… yet. As far as I last saw, it still only will run on a single core. So if you want to take advantage of any modern machine, you'll need to run it behind something that can partition requests across multiple node.js processes, which already starts adding complications. Also, while many backend service integrations have been written for it, this is still a developing area, so YMMV.
Scala (in particular with Akka) looks to possibly be the best up and coming bet, but getting started with it can still be a bit difficult at first. After you get over the initial bumps (mostly just getting your environment set up for building projects with it), it's mostly smooth sailing based on my experiences so far. You'll have access to all the solid Java-based libraries, so you won't want for access to backend services.
The stability of Riak is excellent, and it handles node failure well. Performance varies on your configuration, of course, but you can easily determine your needs by modeling your load with basho_bench: http://github.com/basho/basho_bench.
I think you are approaching this wrong.
A co-founder is a true partner. Someone you want to spend a huge part of your life with. Someone you can go through the tough spots with. Someone who has some skills you don't. Someone you want to be with as you go through the inevitable failures and pivots. The criteria are quite subjective and emotional.
I think you are defining a co-founder too narrowly…you say "the only reason I need a cofounder is…" That says to me that you aren't really looking for a true partner, just labor. That attitude probably comes across when you talk to people.
And given how few people are going to fit the above criteria, why would you limit it even further to people who know Erlang? Anyone good enough for you to want to work with in the first place will pick Erlang up quickly. After all, you did. Yes, it will take a few weeks, but for how many weeks have you been looking for a co-founder?
Startup founders are not defined by what language they know.
halt() and init:stop() do very different things.
The init:stop() function gives each running process an opportunity to do an orderly shutdown*, whereas erlang:halt() signals to all schedulers to stop scheduling erlang processes and close all ports (file descriptors); once the last port is closed, the VM terminates. No cleanup work at the Erlang level is allowed.
* This is done by sending an exit(Pid, shutdown) signal, so only processes that trap exits can actually execute Erlang code in response. Still, individually terminating each Erlang process will always take longer than just tearing down the VM.
While Haskell and Erlang are definitely languages that are in "left-field", software written in Haskell and Erlang is hardly domain specific.
Haskell has an immense amount of work, effort, and output available in its community. Unlike other non-mainstream languages such as Common Lisp, Scheme, and Prolog, the Haskell community regularly produces large, high-quality, and practical pieces of software.
Here are some interesting, well-known, and non-trivial Haskell projects:
- XMonad: A tiling window manager written for the X11 windowing system. 
- Darcs: One of the first distributed version control system, inspiring the likes of VCS like hg and git. 
- Pugs: An implementation of Perl6 that has now been retired in favor of Rakudo. 
Erlang too has several non-trivial, interesting projects. These two come to mind:
- Apache CouchDB: A high performance NoSQL database which stores data in JSON. 
- ejabberd: An XMPP server written in Erlang, used by Facebook and other users of XMPP. 
The communities for both Haskell and Erlang seem quite active (Haskell moreso than Erlang), though there isn't quite the depth of easy help available for these two languages as there is in languages like Python or Java. That said, if you have ever worked on any non-trivial application, such as writing operating system or architecture level code, or writing highly parallel code, you quickly find that the amount of easy help available to you diminishes. It seems like only in the domain of trivial web or desktop applications will you find thousands of StackOverflow posts addressing your concerns. Writing hard code isn't for the faint of heart.
Lastly, as to answer the original question of why languages like Haskell and Erlang remain underused in practice, I feel (purely my opinion) it comes down to ease of use and problem domain. Programs in Haskell an Erlang require a great deal more thought to write and debug. As a result, prototyping in these languages is slow, and output is even slower. The extra time given to writing and debugging code in languages like Haskell and Erlang often results in more robust, bug-free code, while languages like Python lend themselves well to a hacker mentality where code is written quickly, and debugged as errors are encountered.
The hacker mentality works well for certain situations. Technology startups need to produce products quickly and care more about output than correctness. As such, startups benefit heavily from using languages like Python and Ruby, and their associated ecosystems. Other situations are less forgiving. If the databases that back these startups have a subtle bug losing customer data, then the bug can result in millions of dollars in losses, and a catastrophic loss of confidence in the database.
The decision to use Haskell or Erlang over something like Java, Python, or Ruby then should be based upon the nature of the problem being solved. If you are writing a complicated, robust piece of software then languages like Haskell and Erlang work well. On the other hand, if you just need to ship a product as quickly as possible, with correctness being a secondary matter, then languages like Python or Java work just fine.
EDIT: As was mentioned by Bartosz Milewski, Darcs was not the first distributed version control system.