Hacker News new | comments | ask | show | jobs | submit login

I'm betting on Go at the moment, using it to build some little libraries and writing some dummy apps to test the waters.

Hopefully in 4 years when Golang developers are in demand, I have 4 years of experience under my belt. :)

Programming is now multi-language and multi-paradigm. It matters more what you can do and not what you can do it in. Being able to compose libraries and systems from parts is way more important than knowing a specific language.

This is true but, from my experience with developers (not to mention HR/hiring managers) at my own company and elsewhere there is a prevalent attitude that language is the basis of "What You Do". I agree that attitude is totally wrong but a lot of places seem to have this backwards prejudice about hiring good developers and chucking them headfirst into a language or technology they haven't already proven they know.

Indeed, for example getting your brain wrapped around concurrency patterns in Go is very straightforward (especially since there is a plethora of documentation and examples).

These skills will transfer very well into other programming languages.

I'm thinking Go has got to eventually eclipse Python in popularity, since the former can do the same work using a fraction of the servers, for about the same coding difficulty.

One place Go won't be replacing python (or perl) is in the "smarter shell-scripts that don't suck" space. Being able to write a 10 line script, dump it on the server and point cron at it, and then open it in situ to see what it's doing is invaluable. Also, when things get a bit edgy, to copy the file, edit 2 lines, and run it to fix something that the original didn't cover...

It may be better than Python for some kinds of large applications programming, I don't know. But since a lot of apps do need the simple scripts and the application logic, it's kind of nice to have them all in the same language - which is one place where javascript may take over more, I suppose, if ever they can convince OS designers to build node.js tools into the default installs...

I find good old /bin/sh is better than perl or python for the use case you are talking about. Perl rose out of the huge gulf between shell and C. The distance from shell to go is much smaller.

I have a bunch of scripts which are written in standard shell, and for simple stuff, it's fine. But as soon as it starts doing file name manipulation, or working with collections of files (say finding the age of the most recently changed file in a directory, and checking how long ago that was and changing color-extended attributes of the enclosing directory so projects untouched in over a month turn grey...), and you have people on the network who name files by copying and pasting from word documents (I didn't even know you could put a newline in a filename!), I've found python to be much more reliable and easy to write correctly.

What you described is exactly what I mean by simple stuff where shell is ideal. People generally find perl or python easier for those tasks because they took the time to learn perl or python, but didn't take the time to learn sh.

"for about the same coding difficulty."

Oh really? Checking every single function call for an error return code doesn't complicate things?

If the function has less chance of erroring than a hardware failure, why check? I have a function that calls functions that call functions and so on. At the top level function I check if Go has panic()ked; if so I recover() and report the nice error message I want. Seems to offer close enough functionality to try...catch.

By then you'll need at least 10 years of Go experience to qualify for the job postings. ;-)

That is almost doable, but would be exceptional unless your name is Rob, Robert or Ken. I think I could almost claim 9 years at that point, conveniently ignoring the fact I stopped coding a few years back.. :-)

I think this is a joke -- job postings have been spotted in the wild demanding X years experience for languages that have existed for <X years.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact