Willingness to try new things and experiment with them (for longer than 90 minutes..) is how you prevent being one of those people who nowadays still only does COBOL. Or Java. Some day Ruby is likely to have a similar status.
This is the introduction and conclusion to what could be an interesting blog post on how to present and "sell" new technology to people using Go and Ruby as examples. Unfortunately, the entire body of that blog post is missing. Kudos for getting me interested in the topic, but go back and finish the post, even just talking about what you didn't like about Go and what they could've done better to sell you would be interesting.
I wouldn't say the gains are entirely unknown. Perhaps as yet unrealized in your learning efforts. But assuming you're building web applications, the two languages you cited (Go and Ruby) are effectively opposites on the performance spectrum [1].<p>[1] <a href="http://www.techempower.com/benchmarks/#section=data-r5&l=fsw" rel="nofollow">http://www.techempower.com/benchmarks/#section=data-r5&l=fsw</a>
this post is face-palm worthy. I can't even form an opinion on a new technology before using it for a solid week. Even then I often suspect I've missed something important. Ninety minutes is ludicrous.
I've been using Go for a few weeks and I think it's amazing. However, I have a considerable arsenal of other languages under my belt already. If I didn't already know C and C++ I probably would feel differently about Go. It certainly isn't as easy of a language to pick up as Ruby. That being said, it's totally worth the effort if you can muster it!<p>Cheers
My hesitation about using Go would be having to forgo all of the ecosystem built up around a more mature language. I haven't coded much in Ruby (I gravitated to Python), however I would assume that Ruby has a much richer set of libraries than what is available for Go. I use interpreted languages because of their inherent ability to be able to rapidly prototype applications. If Go's ecosystem doesn't have libraries for things I need, I'm going to be extremely reluctant to switch, regardless of any performance gains, no matter how large they are.<p>Of course this will only improve with time if other people switch first and decide to fill in missing libraries. From looking at the Go package list at <a href="http://golang.org/pkg/" rel="nofollow">http://golang.org/pkg/</a> it looks like they've got a reasonable base, and hopefully it will continue to grow.
People do this all the time. I myself have given up Haskell what, 3 times already? [edit: Granted, each attempt took no less than a full weekend, sometimes more. Yet, I had no meaningful data to merit a blog post]<p>When you have no motivation to learn something at work, and your free time is limited, do you use the time you already have to create new things, with old tools, or do you use it to learn new tools?<p>Of course, this runs completely against my instincts: either I will want to go near the metal and use C, or I'll try to use the fanciest, highest level thing I can find.<p>To counteract that (in order to get things done), for the former I think about EVE Online (mostly Python, client and server). For the latter, I think about Minecraft (Java).
Or you could (gasp) actually learn/use more than one language at once. Sane people don't <i>switch</i> from one language to another -- they use the best tool for the job, when it's needed. I probably use between four and eight different languages a week, all of which I'm proficient in. I use them for different jobs, because they (or their libs) are more or less suited toward the task at hand.<p>And moreover, why the fuck should anyone have to "sell" you on a language? You're not buying the damned thing; it's free. Use it, or don't. Actually, don't. We need fewer entitled-feeling developers like you, and more people who care about improving the community.
The kudos mechanism on that site is a great way to ask for them. You don't know what you're looking at it, or what it does and it's mouse-over activated (which makes no sense given the age of the touchscreen anyway).
I can't decide if the author is brilliant and doing a scathing critique of short attention spans and knee jerk reactions of the modern developer or is entirely on the level and just a bit of an imbecile.