I was a bit surprised about the age, and wondering where it fits into the timeline, so I put together the following list (years corresponding to the "appeared" indication taken from Wikipedia). (There will likely be nicer lists elsewhere..)
Ruby was first released in 1995, development started in 1993. So, both numbers are right. "Ruby's birthday" is traditionally the start of development. The most interesting info is: Ruby and Python are both not influenced by Java.
An easy answer to the question: "Why didn't they just steal that from Java?"
* Threads without GIL (which also requires an explicit memory model)
* concurrency libraries
* Garbage collectors that scale to hundreds of gigabytes worth heap, are parallel and concurrent
* JIT that performs within a small factor of C code
* Tooling support, especially profilers and debuggers are lousy and frequently break in my experience
* bytecode weaving/AST transforms at runtime. The whole refinements thing could have been done more cleanly with callsite and method entry/exit hooking
Talking about MRI here. I know rubinius and JRuby exist and offer some of those features
The creation/creators of Java are not responsible for most of the things you listed. They are attributable to HotSpot, built by the fine folks that brought you the best-of-breed Smalltalk implementation half a decade after Java's release.
HotSpot wasn't released until 1999. Prior to that Java did not have a JIT. Java used to be very slow compared to compiled code and HotSpot was a BIG DEAL when it was released in '99.
GC that scales to hundreds of gb? Do you mean Azul, the proprietary and expensive JVM implementation?
G1GC for dozens of GB, Azul (for now) for hundreds and in the future there'll be Shenandoah.
You're right that those features provided by hotspot. But it is the reference implementation for the JVM after all.
The point remains that the java ecosystem - which includes tooling like eclipse/netbeans/yourkit and JVM implementations - provides the things I've listed that I find lacking in ruby.
Real (presumably, that means native) threads are an implementation detail and not a language feature, and both Ruby and Python use native threads in the current main implementation (and Ruby, and I believe Python, also have implementations that use native threads without a GIL/GVL.)
In both languages threads are an added after-thought and no, I disagree with you - multithreading is not an implementation detail. For example, why do you think classes in Java are immutable?
Also, I consider the standard library to be a part of the core language, because it is. Python doesn't have many concurrency primitives that are commonly used in Java, even really common ones, like AtomicReference or CountDownLatch. Heck, it doesn't even have volatile variables, let alone ForkJoinPool or other niceties. What's actually in the standard library? Well, the multiprocessing library is now baked in for doing "process-based threading", which really means stuff based on fork() that is unportable, because the language implementors gave up on threads a long time ago.
It doesn't stop at concurrency primitives though. For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work.
Add to that libraries like NumPy/Scipy that are basically unportable, or Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version, or the myriad other libraries in the ecosystem all written for CPython and expecting a GIL. Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.
> In both languages threads are an added after-thought
So?
> no, I disagree with you - multithreading is not an implementation detail.
Threading is a language feature, not an implementation detail. Whether threads are implemented by way of native threads on the underlying platform (as in JRuby, current CPython or MRI), or green threads in the runtime (as in old MRI, etc.), and, in the latter case, whether the green threads are mapped to native threads on an N:1 (as in old MRI) or M:N (as in the main Erlang implementation) model are implementation details.
> For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work.
Sure, it could, since you could obviously (at the cost of making interop harder) write a Python implementation with its own garbage collector that ran on the JVM or CLR. You might choose to sacrifice portability for better interop with the languages the platform was designed for, but that's a choice.
> Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version
Seems to me that's a problem either with Django or the pure python MySQL driver, but not with the Python language.
> Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.
Perhaps; I'm less familiar with Python's other implementations than with Ruby's (particular JRuby) which is definitely usable, and definitely uses native threads without a GIL.
MRI has native threads a GIL, but you can already release the GIL and run freely in native extensions.
And this is _not_ a property of native vs. green threading. (And shows how shallow the comparison is, given the number of languages that implement green threads mapped to native threads nowadays.)
> Python's standard library additions and syntactical choices were strongly influenced by Java in some cases: the logging package,[27] introduced in version 2.3,[28] the threading package for multithreaded applications,[29] the SAX parser, introduced in 2.0, and the decorator syntax that uses @,[30] added in version 2.4[31]
I think the new enums in python 3.4 are based on java enums(module for dynamic typing, for example I beleive comparing them to ints or adding them if they have int values will fail at run time as opposed to compile time) as opposed to enum as an alias for integers.
Of course Ruby and Python are influenced by Java (there is hardly a maintained language that has not been). Not the initial release perhaps, but don't you think that Ruby has evolved over the 19 years since Java was released? This release alone has been influenced by Java (Generational garbage collection enhancing performance by as much as 100% in some cases)
A question for you is why do you care? If a Java programmer tries to rib you saying that Java is better because x feature was influenced or 'stolen' from Java, just laugh at them and tell them then C++ must be 'better' than Java huh?
(I'm ignoring languages that are used only in a particular context, like R, shells, proof assistants; I made an exception for TeX and PostScript as these seemed particularly important.)
In this day of software developers seemingly needing to keep up with the latest technologies, it is interesting to realize that the languages I use most often are decades old.
1975 (ok, release was 1977). Was in active development/production work in 1977. The DOD standardized on Ada in 1986 (I think). I was in the Army then writing Ada (and using Wang - remember Wang?).
Ada is still in use today. Besides the military, there are a lot of "mission critical" systems written in Ada.
> For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy.
In computer science classes, the best professors do inspire you to see the joy of an elegant algorithm. But I can't remember any class in which the joy of language was ever espoused (when I was a student, we learned C, then C++, then Java). It wasn't until I learned Ruby did I grok that writing and reading code could be something of a joy.
I had a great programming languages prof who managed to instill a love of languages themselves in me. He gave a lecture entitled "Scheme as the Ultimate Programming Language", and his love for Scheme was pretty clear throughout multiple classes I had with him. I didn't ever find a practical use for Scheme per se, but his passion stuck with me, and when I discovered Ruby and how it took some of the more clever naming conventions from Scheme, that gave me the push I needed to really dig in and learn Ruby, which is now my favorite language to code in. Matz has definitely managed to fulfill his goal and make programming using Ruby a joy for thousands of programmers. Thanks Matz, and congrats to the entire Ruby community!
Ruby code always makes us sad, as we have to spend all day deciphering the abusive metamagic DSLs that some devs think are cool to use and abuse. Creative is fine on a canvas, less so when you are having to debug some special turd of an app from a Ruby only developer.
DSLs, APIs, design patterns... there are endless metalanguages to learn on top of the programming languages we already know. Just because you can't wrap your head around DSLs as a different kind of API doesn't mean there's "abuse" going on. Ruby is pretty clearly designed to support DSLs, and being able to use a full-fledged programming language within your DSL-based config files is an incredibly powerful tool.
Speaking from my experience, learning Ruby made programming more fun, elegant, and productive. Thanks Matz! Though sometimes overblown and even cultish at times, the Ruby community transformed expectations about what a language can be. The spill-over benefits have been tremendous to almost everyone. UPDATE: I wanted to thank not just Matz but everyone who made the language easy to learn and the community welcoming.
> Ruby 2.1 has many improvements including speedup without severe incompatibilities. You can use this on Rails and some applications, and get more comfortable experience.
Since the changelog is very large I'm still interested in what speedups are part of this release. Anyone?
There are huge performance improvements in Ruby 2.1.0 as compared to Ruby 2.0.0, I have seen as much as a 2x improvement in real world settings, and they have to with Ruby now having a generational garbage collector:
Well what's stopping you? Stop regretting and pick up a book!
I don't have much love for C# but if your fundamentals are sound you won't have too much difficulty picking up a new language. 6 months ago I wouldn't have known an NSMutableArray from a bar of soap, a couple of books and some elbow grease later and I'm beta testing my first iOS app for the app store (with a ruby backend : D). And I am far from one of those "polyglot" hyper programming geniuses.
Stop regretting, start working, and keep going. This time next year you'll have another arrow for your bow. It's not rocket science, believe me.
Is it really that hard to switch platforms/languages? Learning a new language should not be so difficult, particularly once you've become familiar with a few.
There are so many factors influencing language and API popularity that it's silly to try to bet it all on one language/platform or vendor at any time in your life. Why not just enjoy the ones you use, and when they are no longer of use (for whatever political, technical or personal reasons), switch to something else?
In all fairness, if you don't anticipate a switch many years before you have to make it, you could get caught flat-footed. I personally have taken jobs where I didn't have any primary experience in the platform, but it was for, essentially, pocket change. I would hate to get dependent on a six-figure income predicated on knowing, say, enterprise Java, then suddenly find that nobody's hiring enterprise Java guys anymore and having to take a huge pay cut. Sure I could find a job. That doesn't mean it won't suck.
Does it need to be a "majority"? There are applications being written now, in Ruby, that are intended to still be maintained 20 years from now. Will the "new hot language" be something other than Ruby in 20 years? Well, yeah, by definition.
The majority of the web isn't powered by Ruby now. We have a hodgepodge of PHP, C#, Java, Perl, static, Node, Rails and other Ruby frameworks, Python, any I missed?
People have been proclaiming the death of Java for how long now? And it's still going strong. I'd argue that Ruby will last even longer than Java because it's a nicer language and has more room to grow. Ruby you can port to other runtimes, Java, why bother? It won't outlive the JVM.
The only thing I think that could replace Ruby is Lisp. Maybe in 10 more years Racket will where Ruby is today. I doubt it. By that time, Ruby will be where Java is.
No. It isn't now, it hasn't ever been, and I would be surprised if anyone expected it to be so.
The more important question is: will it still be possible to earn a respectable crust doing web development in Ruby in twenty years time? Any person who claims to know the answer to that one is a liar.
By then we'll probably have decided it's a good idea to develop a JSON serialisation for HTML, and we'll all be writing client side web code 3 layers of code generators eventually targetting JavaScript, backed by a .js library that implements an Android VM
Fantastic. This release has all the fixes I'd been waiting on before going to production; I'll be deploying this week. Great work ruby-core and thank you as always. Twenty-one years, wow, time flies!
This update is important because of the BigDecimal division bug in the bigdecimal gem that ships with 2.1.0 causes incorrect calculations when the denominator is less than 1.
It's definitely worth really digging into (get the PickAxe book--it's incredible!). Even if you never use it for a real project, you'll learn new ways of approaching problems that can be used in other languages.
My first programming language. I haven't written a line of it in years, but it made programming feel fun and made me want to learn more. Shout-out to Chris Pine's "Learn to Program" tutorial.
Are you really sure you want it? I tried running 2.0 in Windows for a while, and found enough gem compatibility issues that I don't think it's worth the trouble. I switched to 1.9.3, and almost every gem that was broken in Windows on 2.0 started working again.