
Ask HN: What language should I learn next? - mattkrea
So I&#x27;ve spent significant time in Node, Go, VB, and C#. I&#x27;ve got an &quot;understanding&quot; of Objective-C also.<p>I&#x27;ve toyed around with C and love it but haven&#x27;t been able to think of a tool for myself to build as a project and that&#x27;s really how I actually learn a language.<p>I have no interest in Cpp but other than that I&#x27;m very interested and open minded.<p>I used to hate Ruby and Python syntax but I am warming up to Python after experimenting some more. Ruby not so much ( what is it with the pipes when you iterate over something ) but I could be convinced.<p>All in all I&#x27;m open to suggestions and with a fairly diverse group here I imagine I could find some direction or at least some pointers ( no pun intended ).<p>Thanks everyone
======
danpalmer
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.

~~~
mattkrea
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.

~~~
jerf
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.

~~~
bbng
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-...](http://rvirding.blogspot.se/2014/01/erlang-syntax-again-and-
again-and-again.html))

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.

~~~
jerf
"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.

~~~
bbng
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.

------
mck-
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)

------
taprun
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.

~~~
mattkrea
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.

~~~
cjbprime
> 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](https://github.com/LightTable/LightTable)
and [https://github.com/slate/slate](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.

~~~
mattkrea
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.

------
pjmlp
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.

------
jaegerpicker
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.

------
maratd
> 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.

~~~
adamors
> 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.

~~~
chm
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.

~~~
krapp
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.)

------
kephra
> 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.

~~~
trhtrhth
What about OCaml or SML/NJ? :(

~~~
kephra
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.

------
facorreia
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.

~~~
mattkrea
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.

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

~~~
facorreia
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.

------
lsiebert
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.

~~~
kotakota
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.

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

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

------
dethtron5000
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...](http://pragprog.com/book/btlang/seven-languages-in-seven-weeks))

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.

------
ludicast
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.

------
ninjakeyboard
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.

------
greenyoda
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.

~~~
mattkrea
My career is actually in PM but good point.

------
planckscnst
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....](http://innig.net/software/ruby/closures-in-
rubyhttp://innig.net/software/ruby/closures-in-ruby)

~~~
mattkrea
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.

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

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

------
leftrightupdown
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.

------
csense
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/](http://python-
gtk-3-tutorial.readthedocs.org/)

~~~
mattkrea
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?

~~~
csense
> 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.

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

------
pikachu_is_cool
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.

------
eranation
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)

~~~
mattkrea
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.

