As someone who has never done web development and knows nothing about it, how do I learn what to do? Every time I try to determine what people are using and what is the path of least resistance to make a website, I am overwhelmed by choices. How do I determine what is good? If I build a website, I don't want to spend my time learning an interface that has been superseded by something better that all pros now use. What backend do people use? Rails? Django? PHP? Perl? Some Javascript? What javascript libraries do people use? etc.
Really old boring tech (c. 2002): Perl or PHP, MySQL, very little JS (and usually plain vanilla JS if used).
Old boring tech (c. 2007): Rails or Django (the two are largely interchangeable, it's largely personal preference), JQuery, PostGres.
Old tech (c. 2012): Node.js, Angular, Express.js, MongoDB. Not boring, because you will still face lots of problems deploying this stack at scale.
Boring tech (c. 2012): Native iPhone/Android apps, JSON-RPC, often Java on the server. Usually Guice or Dagger is used for dependency injection with Java. Not really old (except for the Java part), there's still a lot of innovation going on in this space.
Bleeding edge stuff (today): React, Polymer, Go, Rust, Erlang/Elixir (Erlang is interesting in that the runtime and standard libraries are rock solid, but because it's so different from most mainstream languages, you can face a lot of integration pain when looking for third-party libraries), Haskell (old, but very different from anything mainstream). Basically everything you read about on Hacker News.
Erlang isn't bleeding edge at all. In fact, it's a battle-hardened and conservatively evolving platform dating back to 1986, which is one of its selling points amongst all the technical benefits.
Depends on your problem domain. It absolutely is battle-hardened and conservatively evolving, but it grew up in the telecom industry, and most of its "mainstream" uses (Facebook chat, Whatsapp) are in messaging.
Erlang strings, for example, are lists of bytes, which will blow up your memory requirements and algorithmic complexity if you do any serious string parsing. You're shut out of common libraries like protobufs. There are libraries available for things like HTML parsing, MySQL, Postgres, and even Apple Push Notifications/Google Cloud Messaging, but many of them are some guy's personal project on GitHub rather than something that's gotten widespread use & testing and has plenty of StackOverflow posts for help.
Lists of Unicode points (integers), specifically. That said, most real world string manipulation is done by passing them as binaries. It really isn't much of an issue, nowhere near as much as is the hell that is NULL-terminated character arrays in C, which, mind you, power most of our software nonetheless.
Erlang does have a good Protocol Buffers library, by the way: https://github.com/basho/erlang_protobuffs. Even if it didn't, you'd use a more native serialization format like BERT.
As for abandoned projects and library sprawl, that is true. However, I'd say that this is far more bearable in Erlang than in other languages. For one, the module system makes deducing how to use a program's API from source code much easier even if there is no explicit documentation - every Erlang program basically gets a user interface for free just by virtue of being a module. In addition, if the library in question is a properly structured OTP application or if it uses vanilla process primitives efficiently, I can have relative confidence that it is less likely to blow up in my face than, e.g. a random Java library.
Even still, there's all sorts of libraries despite the small community. If you're doing web development and there's some RESTful API that has no Erlang bindings, those are relatively trivial to roll yourself.
Elixir, on the other hand, is still a bit bloody on the edges (and the MVC-ish frameworks for it are very much bleeding edge), but because it's built on the same foundations as Erlang, it ends up getting a lot of its benefits (and a lot of the existing ecosystem), which puts it uniquely in-between "boring" and "shiny".
I don't know what your end goals are but I'd say the safest thing to do is probably to pick tech that is not yet outdated (eg. PHP) and not too shiny or arcane either (React or Haskell respectively - while both great, probably not the best place to start).
If your goal is to seek employment 6 months from now, I'd say Django / Angular is a pretty safe bet. I guess if you want to focus on one language, you could use Node instead of Django and target frontend development.
> What backend do people use? Rails? Django? PHP? Perl? Some Javascript?
All of the above, and then some.
If you're just starting out with web development, it's much more useful that you learn MVC and REST; those are architectural skills that will result in you being able to adapt to most frameworks rather quickly. I'd personally vouch for Rails (or perhaps Padrino) and Ruby as an introduction to those concepts, seeing as that's where my own personal experience is, and seeing as Ruby is generally regarded to be an easy and programmer-friendly language, but feel free to make a choice based on your own personal language preference (Django if you like Python, Catalyst or Mojolicious if you like Perl, Chicago Boss or Phoenix or Sugar if you like Erlang or Elixir (respectively), etc.). You can't go wrong, so long as you learn those underlying concepts.
Lots of folks around here express distaste for "polyglot" programmers like (probably, at this rate) myself, but I personally appreciate that focusing on thorough understanding of core concepts rather than the ins and outs of specific implementations thereof is really helpful in this context.
Having played with most of "Rails? Django? PHP? Perl? Some Javascript? What javascript libraries..." I'd suggest starting with Meteor.js. Reasons - quick to learn, easy, one language throughout, one framework throughout, works with modern tech like push notification and phone apps. Check out the tutorial at meteor.com. Or http://meteortips.com/book/ You can be up and running quickly. Once you've got the hang of it you can always try something more complicated. You'll need to learn a bit of javascript for it.
