Haskell.

I notice there's nothing functional on your list. Any functional programming should prove really interesting for you, and teach you a lot. Certainly learning a bit of Haskell has changed how I write in all other languages. I would go for Haskell because the strict type system is also a really interesting thing to learn, but alternatively you could go for Erlang which emphasises error handling/recovery for services with high uptime, or something like Scheme which has s-expressions and macros which are apparently really great to learn.

Thanks for the additional details on these.

I experimented only very little with Erlang when I was setting up an XMPP server but the syntax was so confusing. I could get over it eventually as I imagine everyone faces that.

If you're interested in erlang but intimidated by the syntax, check out Elixir - it runs on the erlang vm, you have access to all erlang libraries, and you'll get exposure to erlang patterns and semantics (and OTP) with a much friendlier syntax. http://elixir-lang.org/

Erlang's syntax is actively klunky. It's not a characteristic of functional languages, it's Erlang. Functional languages will introduce you to new concepts and that will also introduce new syntax (such as pattern matching), so I'm not promising smooth sailing, but that is not a universal problem.

In fact, Haskell's syntax is quite beautiful and clear. If Haskell's syntax is mind-expanding, it is mostly in how much syntax other languages have, yet to seemingly so little effect at times, when a language with a great deal less syntax like Haskell turns out to have so much nicer ways of saying certain things.

But let me echo in general that even if you don't choose Haskell, you need to get out of the Algol language arena. From where I sit, you basically said you are familiar with about 1.5 distinct languages. C would force you into manual memory management, which is a real change, and I'd bump that number a bit, but still not a full language. Ruby and Python are basically redundant between VB and Node and I think I'd add 0.0 total. Erlang is, arguably, 70-80% redundant to Go; Erlang is a bad functional language so I wouldn't say it checks that box, and while there's still some nice aspects of the Erlang language as compared to Go, you've still gotten quite a bit of the Erlang value out of Go.

SICP is another excellent suggestion. You won't find it quite as mindblowing as someone coming solely from C, but there's still some great stuff in there for you, which will translate quite nicely into some of those languages you already know.

Disclosure: I am a Go contributor and my day job consists in writing and maintaining Erlang systems. I am not biased towards any of them, on the contrary, I really love both languages.

Do you have any arguments about Erlang’s syntax being “actively” clunky, whatever that “actively” means? Or is it just your personal opinion? (This comes immediately to mind: http://rvirding.blogspot.se/2014/01/erlang-syntax-again-and-...)

Another claim that you make without baking is that Erlang is 70-80% redundant “to” Go. Care to elaborate? How have you measured that number?

Let’s go to the next point where you claim that Erlang is a “bad” functional language. What does that mean? “Bad”? What is that? Maybe you mean that it isn’t a pure functional programming language? That’s not a bad thing, nor good, but it’s not bad. Erlang has never aimed to be a pure functional programming language, it aimed at solving a very specific set of problems. Erlang is a functional programming language, and its simplicity, the minimal syntax that you can pick up in a day, actually makes it a really good choice for introducing functional programming to someone who has never had contact with it.

Let me tell you something about Erlang and Go. Contrary to what you have read in the news, Erlang and Go are totally different. As a user of both languages I have no idea what you mean when you say “there's still some nice aspects of the Erlang language as compared to Go, you've still gotten quite a bit of the Erlang value out of Go”. What? What aspects/value? The only thing that these two languages may have in common is the fact that they both offer concurrency primitives as first-class language citizens. Even with that, the concurrency models are very different. Only someone without experience in the languages would say that the concurrency in Erlang is like the one in Go. On the other hand, none of the aspects that make Erlang an amazing language for its niche aren't present in Go. In Go you can mutate state, Erlang is immutable. In Go you use channels to communicate between processes by sending data, in Erlang you send messages. Erlang processes are garbage collected individually which makes it a perfect fit for soft real time systems, Go goroutines are not. Erlang has primitives for building distributed systems, you can spawn processes on remote nodes just as you would spawn processes locally, Go does not have this either. In Erlang you can reload code while the system is still running, in Go you cannot do that. I can go on and on. So, yeah, don’t trust the news, see for yourself before you “advertise” stuff that you have only read about in the news.

"Or is it just your personal opinion?"

Of course it is. But contrary to the occasional Erlang syntax defender, after 8 years of use I still find it klunky. It's klunky enough that I find myself frequently having to override a desire to do something the easy, wrong way rather than the harder, right way. I consider this a great sin.

'Let’s go to the next point where you claim that Erlang is a “bad” functional language. What does that mean? “Bad”?'

It makes everything functional a real pain. Yes, you can pass functions around, but the syntax is klunky and annoying enough that you don't want to do it. Practical usage of Erlang ends up using it as an imperative language with a "strange" restriction against using the same variable twice (leading to the very common Result, Result1 = Something(Result), Result2 = SomethingElse(Result2), etc pattern), not as a functional language. Compare the structure of Erlang code with other functional languages; Erlang looks more like imperative code than functional code. It's a bad functional language. It's a decent enough language itself, but it's not a good functional language.

And let me pull that out and emphasize that... I'm not looking at the theoretical design issues of the language, I am looking at what code comes out in the real world. Erlang is not programmed functionally. In fact you could strip it out entirely, allow in-process "mutation", and as long as you prevented processes from being able to share any data, you would not notice the difference, excepting that your code might get simpler. As near as I can tell, virtually nothing would require any significant rearchitecting, or indeed even any API changes to speak of. It's entirely incidental to the real considerations of total process isolation and message passing. Erlang is programmed procedurally, with isolation between actors being the primary isolation tool.

'As a user of both languages I have no idea what you mean when you say “there's still some nice aspects of the Erlang language as compared to Go, you've still gotten quite a bit of the Erlang value out of Go”.'

In terms of learning multiple paradigms, if you're already intimately familiar with Go, Erlang won't teach you very much.

"Only someone without experience in the languages would say that the concurrency in Erlang is like the one in Go."

I have extensive experiences in both. On the grand scale of things, they are fairly similar. Locally they have a lot of differences, but designs come out fairly similar in both cases. Compare with the incredible differences that you get in Haskell designs, or conventional threading designs. With just a bit of grease code added to Go, you can straight-up port an Erlang design to a Go design. This would not be optimal in Haskell, and not be practical in a pthreads&locking-based world or an event-based world like Node, both of which would exert significant pressures to structure your code in other ways.

Again, I am looking at how the designs come out, not the theoretical considerations.

I think perhaps the perspective difference here is that I've also got a great deal more than just Erlang and Go under my belt. For all the superficial differences, if you already know one, if you're out to get a lot of experience in the different languages in the world, you're better off learning something else entirely than go learn the other. Erlang has some advantages on the crash-first front and multi-node stuff, but they aren't open-your-eyes perspective changing the way that, say, your first encounter with closures are, or a read-through of the SICP is.

You missed the biggest practical difference between the languages, which is that Go's synchronization primitives default to synchronous and Erlang's to asynchronous. I find that dominates most of the other differences you listed. As opposed to issues like garbage collection, which hardly even enter your mind until you've got a system larger than what your average Go programmer will encounter. (Mine is, though, but even then it's not stopping me.)

For that matter, my experience is that Erlang's multi-node stuff is a bit oversold. Less is provided that is often claimed (you certainly do not simply write idiomatic Erlang code and get a multi-node capable system; you must write a multi-node capable system, Erlang just gives you a few primitives. Useful, but nowhere near a complete solution.) and I personally have had huge stability problems with Mnesia for years. It just likes to stop clustering sometimes, for no apparent reason, on machines sharing a switch, multiple times a week, on a load that shouldn't be a problem.

Robert Virding is not “the occasional Erlang syntax defender”, look him up. Or were you referring to myself maybe? Anyway, I’ve been using Erlang, too, since about 2000 and I cannot relate to “doing things the wrong way rather than the harder, right way”, I guess it works in a different way for you.

What practical usage of Erlang are you talking about? I work in telco and I have yet to see that practical usage of Erlang ends up using it as an imperative language. What you are referring to can happen in many other functional languages when used by people without FP experience. I don’t see how this is related to Erlang in an explicit manner. I agree with you that it does not provide what Haskell does but it’s a functional programming language, wether you like it or not.

You talk too general. Again, which real world are you referring to, I am working in telco and the quality of the code is impressive in most of the areas. If you work in a startup where programmers used Node and Ruby until yesterday and today they are doing CRUD with Erlang then yeah, probably the quality of your real world Erlang lets to be desired or maybe not, but you get the point. However, the code that I had contact with so far was functional, easy to understand and reason about, despite being written in Erlang.

-- In fact you could strip it out entirely, allow in-process "mutation", and as long as you prevented processes from being able to share any data, you would not notice the difference, excepting that your code might get simpler. --

Erlang is a niche language, you can also prevent dangling pointers, that’s not the point though, people make mistakes. The fact that everything is immutable is very important in the domain that Erlang was conceived for. What do you mean that the code might get simpler? Are you sure? I guess it would get more complicated since you no longer have the immutability guarantee.

-- Erlang is programmed procedurally, with isolation between actors being the primary isolation tool. --

Says who? And which Erlang are we referring to?

-- In terms of learning multiple paradigms, if you're already intimately familiar with Go, Erlang won't teach you very much. --

It will teach you some functional programming concepts, requirements and architecture of real-world soft real-time distributed systems (given that you will not ignore OTP), the fail first concept. These are not light subjects. As I said earlier, I am very intimately familiar with Go. I contribute code to the project and use it almost daily, however I fail to see how Go would learn me anything about these issues, and this list is big and important enough for me so that it would make it worth to learn something about Erlang, probably not good enough for you and I understand that.

-- I have extensive experiences in both. --

Please allow me to have my doubts about that. What kind of systems have you built with Go, how about Erlang? Have you tried to implement 3GPP in Go for instance, how about Erlang? Are you confident that you could reimplement 3GPP in Go with minimal effort, and get back the same guarantees that you get for free in Erlang? If not, how can you reason that Erlang brings nothing new to the table if you already know Go.

-- On the grand scale of things, they are fairly similar. Locally they have a lot of differences, but designs come out fairly similar in both cases. --

No, they are not. They are completely different, the only commonality being that they offer concurrency primitives. Again, what kind of systems are we talking about? CRUD web apps?

-- With just a bit of grease code added to Go, you can straight-up port an Erlang design to a Go design. --

Right, I am really curious to see someone porting a distributed Erlang system to Go in the same amount of code, with the same safety guarantees, with “just a bit of grease code added“. I am not saying that it is not possible to achieve something similar, I am saying that you will probably need a lot more work than you imagine or describe here, and your first attempt will be 50x less robust than the Erlang solution. Not to talk about hot code reload for instance, which alone would drive you insane. And I am not talking about some kill main process and keep descriptor alive, then switch to the process carrying the new version kind of thing, I am talking about real code swapping like the one that you can achieve in an Erlang system.

-- I think perhaps the perspective difference here is that I've also got a great deal more than just Erlang and Go under my belt. --

Yeah, I guess me too, the only difference is that when I say I have something under my belt, I really have it, unlike lots of other people that talk from what they read in the news.

-- You missed the biggest practical difference between the languages, which is that Go's synchronization primitives default to synchronous and Erlang's to asynchronous. I find that dominates most of the other differences you listed. --

No, I omitted that one intentionally since it’s a lot more subtle than the obvious differences that I was trying to describe.

-- As opposed to issues like garbage collection, which hardly even enter your mind until you've got a system larger than what your average Go programmer will encounter. --

Right, as I said before, you probably work with CRUD web apps (which is not a negative thing) but in my world these kind of things are of crucial importance. Please go ahead and implement soft real-time systems ignoring this aspect and then fix it later when you “got a system larger than what your average Go programmer will encounter“. I was actually talking about exactly those kind of systems in my first comment when I said that the two languages have nothing in common because, you see, Erlang was conceived precisely those kinds of problems that you take out of discussion and then conclude that they are more or less the same. I guess we can agree that for some systems you can get the same out of both languages, but not for any systems.

-- For that matter, my experience is that Erlang's multi-node stuff is a bit oversold. --

Yes, if you build web-apps probably. If you want to implement distributed systems they are not oversold.

-- and I personally have had huge stability problems with Mnesia for years. --

Maybe, but without facts, means nothing. I could tell you that I used Mnesia in lots of systems, the kind that millions of people use, and never encountered such problems. So yeah, each to its own.

If you haven't read SICP yet, I can highly recommend it. It is taught in Scheme (dialect of Lisp); you'll be reading one of the greatest programming books of all time while you're at it -- it certainly opened up a whole new paradigm of coding for me (and I still use Lisp in production today, along side Node.js)

I'd suggest trying to think about what types of things you want to build in the future and then picking a language that is used to build those types of things.

I can shout "learn assembler" until the cows go home, but if you want to go into AI and hate the idea of being an embedded programmer, then you'd be much better off learning LISP.

When I was a bit younger, everyone told me to learn PERL, because PERL was very powerful. I learned it, but never really needed it, because I never needed to write software that was heavy on text processing or system administration. If I were able to do it all over again, I would have picked R instead, because it would have been much more useful for my career path.

Well after reading your comment I thought a bit and I think maybe half of what I'm looking for is a change from the types of things I build now. I'm essentially all web at the moment. APIs, TCP & UDP, aqp, etc.

I would love to do desktop apps on Linux but it seems that my only real choice there is C++ and that has always seemed a language beyond what I could do.

> I would love to do desktop apps on Linux but it seems that my only real choice there is C++

node-webkit runs on Linux, that's a pretty reasonable choice for cross-platform development these days. Used by https://github.com/LightTable/LightTable and https://github.com/slate/slate, for example.

I agree with the suggestion to move to a functional language -- Ruby and Python wouldn't teach you much on top of Node and Go. Doesn't really matter which one -- Scheme, Haskell, Clojure, whichever.

I've also used node-webkit but either I can't match the performance of a desktop with my code or node-webkit can't. I'm mainly referring to UI interaction.

>I would love to do desktop apps on Linux but it seems that my only real choice there is C++

Lots of Linux apps are also written in Python, so that might be something to look into.

Go and QML for desktop apps: https://github.com/go-qml/qml

Modern AI (Machine Learning) doesn't have anything to do with Lisp.

All the languages on your list are basically the same in terms of supported concepts, imperative and OO, with a little bit of functional.

If you are learning just for fun I would suggest a bit of Prolog for logical programming, a Smalltalk derivative to see how the original OO is all about and the Xerox Parc concepts or a more pure FP language like F#, OCaml, Scala, Lisp derivative.

If on the other hand you intend to learn more with focus on a certain career path, then better look into what languages are being used in the fields you care about and learn one of those which you still don't know.

I think a purely functional language would teach you quite a lot, it certainly did me. F# runs on the .net run time and you should be able to easily find/figure out the .net libs since you have used C# and VB a good bit. Clojure and ClojureScript are really great options. Clojure is a lisp that runs on the jvm, plenty of great web frameworks to work with and a metric ton of libs available to the jvm. Clojure Script is Clojure targeting a JavaScript runtime, it works great with node.

> What language should I learn next?

You should definitely learn PHP.

That way you can partake in all the wonderful flame wars that pop every few weeks here.

> That way you can partake in all the wonderful flame wars that pop every few weeks here.

You're being silly. To be best equipped for a PHP bashing one shouldn't know PHP or anything related to PHP.

I've tried to learn PHP some years ago when I was a teenager. I could never understand the language design. It just didn't resonate with me. Working through examples, it never felt right (and that's despite having worked through a C++ intro book at the same age).

Attribute this to my increased maturity if you want, but I've started web development again just over a month ago. Full-stack JS feels great to me. It's intuitive, unlike what PHP was. It feels clean, uncluttered, unlike what PHP was.

I've been exposed to PHP, Java, Perl, C++, VB Python and C# and it's definitely the case so far that PHP seems to be the most haphazardly designed. Although personally, I've never had much of a problem with PHP's ugliness. It's not my least favorite language (that would probably be VB.)

> I used to hate

thats good. There are 10 kind of languages: Those nobody use, and those everybody hate. So a coder who does not curse a language has never used it.

Now the question what to learn next is depending if you want to learn languages that open your mind for new concepts, or do you want to learn a language that helps you in the job market?

For the first I would recommend:

Forth or Postscript to learn a stack oriented language.

Lisp or Scheme to learn a lambda calculus language.

Smalltalk to learn what real object orientation means.

Lua or Javascript to learn prototyping.

Haskell to learn functional programming.

Erlang to learn how to write massive parallel code.

Last improve your C skills, read "a little Smalltalk", and write your own programming language. Dont be shy. Ruby or Python code reads as if they also did read a little Smalltalk, decided that designing their own language is easy, and repeated all errors from the book. Always remember: Smalltalk was 35 years ahead of its time. Since then every year a new language is hyped, each of them one small step closer to Smalltalk.

If you want to learn for the job market, then learn Linux, Perl, PHP, Java, SQL, HTML, CSS and JavaScript.

What errors did python make wrt to design that were first found in smalltalk?

I remember reading somewhere that the OO system for python was sort of bolted on after the language had been around for awhile. When I write classes in python, there is something awkward about it that I just can't put finger on. I remember thinking it was strange to have to pass in 'self' to member functions, and then realizing that it was like 'this' in c++. So why does c++ hide that implementation detail while python lets that detail leak out? I wonder if 'self' could be passed in behind the scenes and any references to local variables that haven't been declared in that scope can be assumed to be instance variables.

What about OCaml or SML/NJ? :(

Good alternative to Haskell. Less strict in being functional, and therefore perhaps better suited for real world. Well I learned Miranda ages ago, so Haskell is closer to me.

Java is a very important language that's missing from your list. You should probably spend some time learning a bit about it. And Scala could be a language you'd decide to stick with to build some serious stuff.

I've actually been looking into it somewhat. I just grabbed Eclipse but though I might gather some opinions before I start investing serious time.

C# is basically Microsoft's version of java. As you already know that java isn't going to be very interesting.

What's interesting about Java is not so much the language per se but the ecosystem around it. There are a lot of very interesting libraries, tools and middleware. Things like Apache ActiveMQ and Solr.

I'm going to suggest that you don't learn a new language, but that you learn how to deal with broader issues and to think about problems.

Go deeper, not broader. Another language can help you learn about stuff, but knowing languages is less important than understanding how they are used.

Learn about event handling. If you have toyed around with C, get an arduino and learn about hardware interrupts. Learn about concurrency and distributed systems. learn about semaphors and locks and other ways to deal with resource contention.

Understand memory. Know how a hash/dictionary works. Look at implementations of variable length arrays.

Write a toy database and driver. Now make it work when two programs are accessing it at the same time.

Write a server.

Take old horrible code in some language you know well, and update it to current standards with unit tests.

Read the code libraries you use often. Or try to implement your own version of the base case of a POSIX like tail.

Write a function to convert a string to a floating point number without taking advantage of the built in float or atof functions.

Learn about how compression algorithms work and implement a simple one.

These are not easy things. And you don't have to finish them or do well or do all of them. But you will get experience you can't get sticking with the basic features of a language that will serve you well.

I think this is the best advice. A lot of these projects will force you to learn new concepts, algorithms, and they will give you a new way of thinking about problems. Learning a new language won't necessarily do any of those things.

Highly agree. I've got my main languages fleshed out (Python, C(++), Java, and Haskell), and have found it incredibly rewarding to implement web servers, regex engines, databases, interpreters, etc.

If you want to experiment, Rust might be something for you.

Rust is definitely most worth learning. Everything else will then be pretty much a subset (perhaps with the vague exception of C++).

If you want a structured, high-level intro to several languages, Bruce Tate's "Seven Languages in Seven Weeks" is pretty good. (http://pragprog.com/book/btlang/seven-languages-in-seven-wee...)

I'd recommend Erlang for its concurrency model (especially comparing how languages like Erlang, Scala, Go and JavaScript/Node handle concurrency and parallelism differently).

Haskell is good for functional concepts - understanding FP will help with functional stuff that is migrating into more mainstream languages.

Learning a Lisp (Common Lisp or Clojure) is good too.

Python is great for the mature community that's developed around scientific projects like machine learning, NLP and such.

JVM knowledge.

I would encourage you to learn some Java (helps with understanding the ecosystem, and used in plenty of examples), and then focus on a JVM language. Scala and Clojure are obvious choices, because they come with their own ecosystems and contain new language paradigms.

Scala or Haskell would be my vote. You already have enough imperative stuff up on your learning wall there - learning more languages won't really teach you how to think differently unless they are able to produce sufficiently different ways of describing problems and their solutions. You could probably learn ruby in a day but would it make you better for doing it? Probably not so much. But learning functional programming WILL make you better - you'll be able to take the approaches and write better code in imperative languages because you'll understand how to reduce mutability and write more declarative code using lambdas in the other languages you mention.

You might also consider learning something other than a new language. Learning more about operating systems, fundamental computer science stuff or even project management might make you a better developer than learning yet another programming language.

My career is actually in PM but good point.

About the strange Ruby pipes when iterating thing...

Ruby, like many languages, has support for anonymous functions (lambdas, procs, blocks, etc.) The pipes are the delimiters for the formal parameters that the function receives. Most languages use parentheses for that. For instance, you might expect something that looks like this:

  function_that_accepts_a_lambda(arg1, arg2, lambda(lambda_arg1, lambda_arg2) { lambda body; })

Here, a function body is defined and passed as an argument in the same place other arguments are listed. Also, the parameters of that function are defined outside the body of the function, within parentheses.

In Ruby, the format is just different. You can bind a lambda to a variable and pass that variable in just like any other argument, but if you want to give an actual unbound function body as an argument, you have to use the Ruby block syntax, which delimits the block using either `do`...`end` or `{`...`}`, and immediately after the beginning delimiter, you can define formal parameters. The definition of the formal parameters of the block is delimited by pipe `|` characters. The other strange part is that the block is not presented as an argument quite the same as the others: it is outside the list of formal parameters for the function receiving the block. The previous example in Ruby is

  function_that_accepts_a_lambda(arg1, arg2) { |lambda_arg1, lambda_arg2| lambda body }

The name of the function now is slightly misleading since in Ruby, every function can receive a block (although it may not do anything with it).

I can assure you that after working with the language for a while, that syntax is not a problem at all. I had, in fact, completely forgotten that I thought it was strange when I first learned Ruby. There are things much more annoying in Ruby than that syntax, like an abundance of slightly different ways to define a closure, each with subtly different effects.[1] Overall, however, it is quite a nice language to work with.

[1] http://innig.net/software/ruby/closures-in-rubyhttp://innig....

Wow.

Thank you very much for that. It is somewhat of a jarring change from what I'm use to but I at least understand it now.

Lisp/Scheme. Go through SICP[0] and do the exercises. Also, mandatory pg essay: http://www.paulgraham.com/avg.html

[0]: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html

If you want to learn how to get more performance out of your event/thread driven code, go with golang, it has improved how i write my code in python. I think more and more people are going to use golang in the long run. If you want to learn something different go with haskell.

Ruby and Python syntax are quite different. Ruby syntax seems designed to be difficult to learn. It uses obtuse, non-standard, irregular syntax for common operations, requiring constant consultation of the manual for the beginner to see any non-trivial program as anything other than line noise. For reasons I do not really understand, Ruby is quite popular with HN users and I may actually receive downvotes for what I've said so far.

Python's syntax, by contrast, is simple, intuitive, and fairly standard. Python does have a few innovations over other languages -- the most important that come to mind are indentation-delimited blocks [1], tuple unpacking, list comprehensions, generators, args/kwargs, and access operator overloading. All of these are usually optional in your own code and easy to grok when you seem in others' code. When you are ready to use these syntax elements, you will find them easy to learn and quite practical in a variety of situations.

Python code can be concise without being unreadable. This greatly improves developer productivity, which is very important. Most projects are bottlenecked by developer time.

Python is a truly general purpose programming language, with excellent library support. People can and do use it for command-line utilities, web applications [2], math/science [3], and desktop applications [4].

[1] Using indentation to delimit blocks is a controversial "innovation" of Python. I suggest suspending judgment until you've written at least one medium-sized program in Python. As a matter of coding style, usually programs written in high-level languages also use indentation to denote blocks; when this indentation gets out of sync with the rules the language actually uses to delimit blocks, you can get hard-to-spot bugs like this one:

    if (myflag);
        myFunction();

This will compile, but the if statement is a no-op, and myFunction() will always be called, which is probably not what the author intended. The above bug cannot happen in Python; since Python actually uses indentation to determine blocks, by definition the indentation cannot get out of sync with the way the compiler/interpreter sees your code.

[2] For Python webapp development, I recommend writing a simple webapp with Flask first, then adding sqlalchemy for proper database support. Once you're comfortable with that combination, you'll want to switch to Django.

[3] Try Sage, IPython, numpy, and scipy.

[4] I recommend GTK+ for desktop apps, especially on Linux. http://python-gtk-3-tutorial.readthedocs.org/

I spent some time with Python just this morning and was curious. Starting out.. should I use Python 3 or 2.x because most packages / modules are written for 2?

> most packages / modules are written for 2

This is actually not so much the case any more; many packages now support Python 3, and Python 2.7 is nearing end-of-life. However, many of the tutorials you will read have probably not updated their statements about Python 2/3 compatibility.

Python 2.x was indeed far better as far as library compatibility for quite some time after the (IMHO idiotic) decision not to use the proven Python way to introduce new features (from __future__ import), and instead have the 3.x release break backwards compatibility entirely.

My advice is to start with Python 3, then switch to Python 2 if you discover your project requires a specific library that does not yet support Python 3.

Python is a fantastic eco system and it can be used for a HUGE variety of tasks with really great results. Certain problem domains are better tackled from 3 and some from 2.7. Web development (my day job is writing python for a series of django webapps) is a great experience with either. I think scientific and data science based environments have better lib support in 2.7.

Spending some time in Ruby is really good to really grok the metaprogramming and DSL capabilities of the langauge. These are generalizable elsewhere.

If you want to get into C, check out Lua. It embeds into C and adds a scripting language to it. It's really straightforward and well-made, too.

I think it's matter of personal taste, and depends a lot on which domain your project is in. (Web, mobile, desktop, scientific, big data, machine learning etc...)

My preference (since I do a lot of JVM work) and first recommendation is Scala, it has good libraries for all of the above, web, scientific, big data, and even Android development (and all Java / Clojure libraries you can find, as well as Jython, JRuby and even with Java 8, some Node.JS clone). Another reason I like it is that it let's you write both in a functional style and in a object oriented style without compromising or enforcing either. (it gives you a nudge towards functional style when possible, but let's you write imperative and OO code with the same ease). Cons - a bit long compile times (bearable for me) and some say it has a "too complex" type system, I think that for most programmers the type system complexity doesn't really have any impact.

If you like dynamic languages, I'd try Clojure, it's been very popular here and from the little I played with it I appreciate it's simple syntax and way of thinking. As others have mentioned your background is mostly imperative / OO background and Clojure is a great way to venture into functional programming (especially if you need a JVM language)

If you don't need a JVM language, try Haskell! (same reason - learn some functional programming paradigm for great good)

Out of the above 3 you can find paying jobs, but I have a feeling Scala will render more openings (though usually with Java experience requirement as well)

If you aim at Systems programming, I'd try d / Rust rather than C++.

If you want web orientation, Python and Ruby are a must (sorry) Ruby is a nice language once you let it grow on you, you'll get used to the pipes.

If you are into scientific programming, Python, Julia and even Scala are good choices.

If you want to get a fast high paying job - depends on where you are located, if in SF, go with Rails, Django, Node, knowing the framework is as important as knowing the used language (Ruby, Python and JavaScript respectively)

If you are in Atlanta, stay with the .NET stack or pick up Java.

In NY Java will serve you well (also in SF, but perhaps in less startups and more Google / Twitter kind of companies)

I think Java is good to know even if you hate it, it's everywhere (and with the new Java 8 it's almost bearable again to code in it)

My last point is that the programming language is the least of a developer's concerns. A developer needs so many more skills than knowing language X spec by heart. Things like SQL, Linux, Git, HTTP, HTML5, CSS3, Good design and coding standards (read the pragmatic programmer / clean code / code complete etc...) And most important - interview skills and other soft skills. All of the above are way more important that the language of choice IMHO. (I'm sure you have all these, but I think that the impact of which language to go with next has much less weight in making you a great developer than what people usually seem to depict. E.g. I don't see often a "which soft skills should I pick up next" or "which general design book should I read next". I think it's because programming languages are more interesting :) (at least to me) and simpler to define. They have strict rules, and you either like it or not. General programming skill and soft skills are so hard to quantify and not easy to explain I guess. But I work on myself to try and spend more time improving these, than learning yet another language. (I fail at this too often though)

I'm actually strong with most of those other items you mention (admittedly only the basics with Git because when I code its mostly me committing to my own repo).

Consumer-facing design has been one of my weak points but as far as system management, server maintenance, etc I manage cloud deployments of several (some my own, some not) for the company I work for out in PA.

That side of technology I am very comfortable with. It was only two years ago that I started coding but I've seen my own code evolve over time--significantly I might add.

I think I will end up getting into systems programming. I've got the rust compiler installed but it does seem a little young.