Go, I can understand. But why Ruby? It is just as old as Python, behaves very similarly, and its ecosystem for non-web related tasks pales in comparison. And why Scratch? I really enjoy it (I've taught many workshops to kids 6-14 yo with it) but I would absolutely not use it in anything else but introductory classes.
Some examples; Puppet, Chef, Vagrant, github, Jekyll.
I'm noticing similar cutting edge infrastructure/service stuff being written in go by default.
Salt and Ansible, successors to Puppet and Chef, are written in Python. The author of Vagrant is writing his new tools in Go. The buzz and constant churn of new shiny things that I saw in the Ruby community a few years ago seems to have moved more to the node.js community these days.
I think the thing that sucks about node is that javascript sucks. It's really a horrible language, it's just that it's everywhere. It's not the most horrible, but the type coercion, scoping and standard libraries really suck.
When you say salt and ansible are successors to puppet and chef, it sounds like you are saying they are inherently better, but really they just came later.
Out of interest are you saying you don't believe in Paul Graham's language spectrum? Blub paradox and that?
Wrong. You need to be at the core. In many areas that I've looked at, most of the activity happening at the edge is just churn from an ignorance of history and a naive blindness or lack of understanding of root problems.
And there is plenty of interesting stuff happening in Python: compilers, visualization systems, devops orchestration, you name it. Don't mistake the noise on HN for reality.
Ruby has no real reason to be if you're already using Python. Nothing wrong with that language (although I consider its programming culture to be inferior in many aspects) but it doesn't really do anything that Python doesn't do, even if it has a few more syntax tricks, which are at best a nice but superficial advantage, at worst another point of confusion and bugs.
Scratch is impractical, and a toy language. Whatever ease of use it has is very quickly surpassed by the need to be productive.
Requires curly braces and type declarations. These are easy for beginners to screw up.
> Ruby
Ruby's syntax makes me want to gouge my eyes out -- it's every bit as bad as Perl. I'm an expert and I hate Ruby. I wouldn't dream of exposing beginning CS students to that crap unless I wanted to convince them to change their major.
> Scratch
This is a toy language in a toy environment. I don't know the language well enough to judge its syntax, but the author's goal is "...rather swiftly bringing [students] to a level of skill where they can use computing in their other courses: to analyze data for those lab reports, to learn linear algebra, to solve problems in particle mechanics, problems involving differential equations, maybe even to write a program to control a robot." Scratch doesn't seem well-suited to this role, but there's enough language and library support for Python to be used in all these roles and many more.
From a non-superficial standpoint, you haven't brought up a single thing wrong with Ruby— or Go, aside from explicit typing.
The thing about syntax is that, to some extent, it's subjective. You say Ruby syntax is awful? OK. Personally, when I first started programming, I hated Python syntax¹ so much that I called it quits. It wasn't until later, when I started learning Ruby and its "eye-gouging" syntax, that I could get past that hurdle. So I wouldn't exactly describe its syntax as an argument against using Ruby as a teaching instrument.
¹I've since grown to love it, but as a beginner this was very much not the case.
There are two things about syntax that I think are actually objective. One is that, when beginners read their own source code that isn't working, they often have more of a tendency to read what they intended to write instead of what they actually wrote, especially when it comes to punctuation symbols.
This means that, when the indentation is right, but there's a missing -- or extra -- brace or semicolon, it can be very, very difficult problem for a beginner to even see. It's also possible for a beginner to write a program with many instances of brace/semicolon issues, giving a frustrating (and sometimes bewildering) boatload of syntax errors.
The second problem is that it's difficult to remember the meaning of symbols. This is true not just for beginners, but also for experts learning a new language with different symbols. This means that the number of symbols in a language should be kept to a minimum. Furthermore, where possible, symbols identical to those used in other languages, or in mathematics, should be used. Where a language has novel ideas that don't exist in other languages, those ideas should usually be expressed by keywords, not symbols.
Ruby fails at this. See [1] for an example. I don't mean to pick on this particular project, rather this file is typical of Ruby code. The file contains the following symbols which seem to be used differently from any language I'm familiar with: Less-than sign used in class declaration, use of colons for thing(s) that are neither dictionary literals nor labels, "absolute value" bars in e.g. { |p| p.id }, shift-left operator used in class declaration, question mark used for something besides ternary operator, lines without side effects like "true" and "false" sprinkled throughout the code (is there some "empty operator" that's applied to these lines to give them side effects?).
My point is that neither a beginner, nor an expert in non-Ruby languages, can understand the above code without constantly consulting the documentation for the unfamiliar syntax elements (and good luck figuring out how to search for "meaning of -> operator in Ruby" without knowing what the -> operator is actually called!) Whereas most Python programs read like pseudocode and can be reasonably well interpreted even by someone quite unfamiliar with the language.
Good languages address that problem by limiting the number of symbols, and making the meaning of symbols as simple and intuitive as possible. Ruby fails utterly on both counts.
I think these facts should be simple and obvious to anyone who's ever attempted to learn either Ruby or Python, but I guess this is HN, where an amazing number of people think Ruby is the bees' knees for no reason I can make sense of.
[1] https://github.com/gitlabhq/gitlabhq/blob/2a8aa7429b6f489acd...
Thanks for the detailed reply. Those are all good points.
It's worth pointing out that a lot of Ruby's oddities (specifically :symbols, predicate_functions?, and implicit returns) are stolen from various Lisp dialects— which is also true of a lot of significant semantic/cultural differences between Ruby and Python.
So you could argue that the syntax differences are just a surface form of the underlying semantic differences. But that's kind of cheating (except for the implicit returns, which is a straight-up semantic difference). Maybe the better point to draw is that there is a background (Lisp) in which its syntactic quirks make sense. As an expert, the fact that that background is an unusual one is a negative for intuitiveness. But as a beginner, with no backing in Algolesque languages, does it really make that much of a difference?
Of course, none of that gets into the plain syntactic quirks— ->(pointy){lambdas}, {|block|syntax}, and so forth. But every language¹ has some of those— good luck making sense of Python decorators when starting out, or for that matter list comprehensions. Or non-paren-enclosed-tuples. Ruby's are used more heavily, but that seems more like a cultural difference than a syntactic difference— generally Python favors readability ahead of 'elegance', and Ruby vice-versa, which extends to making heavier use of special syntactic forms.
¹Except Lisp dialects, ironically! But even there, `(there are ,still some . peculiarities).
In short, it hasn't managed to live up to the immense amount of hype that once surrounded it.
Those issues, combined with many other languages now offering web frameworks that are far better than Rails, have caused a lot of developers and organizations to completely abandon it and apps written using it. Few people and organizations have time and other resources to dedicate toward something that is a liability, especially when the alternatives are so plentiful and better these days.
If a Rails developer were to move to another framework, which ones would you recommend and why?