Slashdot Mirror
MagLev, Ruby VM on Gemstone OODB, Wows RailsConf
murphee ends along a report from InfoQ: "Gemstone demoed [MagLev,] their Ruby VM built on their GemStone S64 VM, to an ecstatic audience. Gemstone's Smalltalk VM allows OODBs of up to 17 PetaBytes, with none of the old ActiveRecord nonsense: the data is persisted transparently. The Gemstone OODB also takes care of any distribution, allowing the Ruby VM and data to scale across many servers (Cheerio, memcached!). There's also an earlier quite technical interview with Gemstone's Bob Walker and Avi Bryant about MagLev."
What?
>Gemstone demoed [MagLev,] their Ruby VM built on their GemStone S64 VM, to an ecstatic audience.
...
;)
An audience that needs
a) to buy some vowels, and
b) to find significant others to get ecstatic about!
--I thought I was wrong once, but I was mistaken.
> murphee ends along a report from InfoQ
I am sorry to hear of murphee's death, and hope that no more lives are claimed by this report's incomprehensibility.
I didn't even know this was a topic being discussed. In other news, git is cool.
That has got to be the worst summary line I've ever read in the history of slashdot.
"MagLev, Ruby VM on Gemstone OODB, Wows RailsConf"
Some magnetic levitation involving rubies, VM (Ware?), more gems, object oriented databases (didn't they die?), World of Warcraft, rails (magnetic levitation again?), and, finally, conference.
Doesn't the Lameness Filter usually take care of this sort of thing?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Independent results will be coming soon, as outlined here.
After I was confused by the headline I thought to myself, "Well the summary will clarify all that up for me"
After I read the summary I thought to myself, "I still don't understand and I'll be damed if me and the four Pale Ales in mah belly give a good Goddamn to RTFA!"
--I'm not talking about dance lessons. I'm talking about putting a brick through the other guy's windshield.-
Just so you know, gemstone isn't exactly new, it might be as old, or older than some of those Oracle products and have been running in production environments for years. Just because you've never heard of it doesn't mean it's brand new. There's quite a few old financial companies running on smalltalk systems built by gemstone. Unfortunately, much of Smalltalk's history has been closed-source. Even the GPL Squeak was late to the game (1997). Fortunately, smalltalk is a pretty simple language so it's actually relatively easy to get a very good stable VM implementation in a short time.
Maglev is the long awaited (by Rubyists at least) Ruby VM (virtual machine) developed by Gemstone, who also develop an OODB (use Wikipedia for this one, you can do it).
Railsconf is a good opportunity for Gemstone to show off their object persistence, since it would benefit Ruby on Rails (which uses O/RM that may not be necessary any more.)
The best way to predict the future is to invent it
You may want to google gemstone and "avi bryant".
Google is a fantastic resource to ease your ignorance.
Remember just because you haven't heard of it doesn't mean it doesn't exit.
evil is as evil does
It is new. Its never been used in conjunction with ruby before, but thats not really that important. I was really talking about my comfort level with the product. I never want to be the largest user of a closed source product. Who uses it? Under what kind of loads? How many servers?
Well.. maybe. Or Maybe not. But Definitely not sort of.
This talk was one of the highlights of the conference. At the talk, they showed performance benchmarks that included running several things as much as 117x as fast as the default Ruby interpreter that is in use by most Rails installations today. The fact that it's built on this commercial-grade Gemstone platform that has been used for years for high-performance production Smalltalk applications just adds to its credibility.
One of the reasons this is exciting is that many Ruby/Rails programmers have suffered from the criticism that their platform is elegant and fast to develop in, but that it doesn't scale well. MagLev sure looked like it could go a long way toward addressing those concerns. And since it hits Ruby right at the VM level, it is potentially useful to anyone running any kind of Ruby app whether on Rails or not.
Of course, we'll see when it's done...
Ruby 1.9: 3.32x
XRuby: 1.43x
JRuby: 1.32x
Ruby 1.8: 1.0x
Rubinius: 0.73x
Ruby.NET: 0.56x
What is cool is how well the Java-based Ruby implementations do: JRuby and XRuby. JRuby was the only Ruby implementation that did not have any tests error. For a VM that is supposedly so hostile to dynamic languages, those implementations were faster and more reliable than the actual Ruby VM and cleaned the floor with the CLR/.NET implementation. And the next version of Java should have stack allocations and invokedynamic bytecode and other optimizations.
What this shows to me is, first do one thing well (Java), then figure out how to grow it. In contrast to
k, found his blog where he describes gemstone a little better. Still sounds limited. There is still only one data store in gemstone according to the blog post. Can it be scaled beyond that? How? I've never heard of any big website using gemstone. If it was open, I'd be more willing to kick its tires, knowing that small problems could be fixed and a community might arise around it. I'm less confident about the same happening around a closed source product that isn't in wide use by large data driven websites.
I try to limit my ignorance when ever possible, so if anything is wrong ( other than the grammar/speling) feel free to correct.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Neither the summary nor TFA inspired me with awe. Guess I'm losing it.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Well yeah, ruby is new to gemstone. But only a few years ago Java was a closed source product too. Closed source vendors like Gemstone are taking notice of Ruby because Ruby is beginning to make significant inroads to the enterprise world. A few large enterprises may take notice of Gemstone and be their customers much like Java in its early days. Java did have its problems too, but I don't see how an open source implementation would have improved it's likelihood of survival. Version 1.0 of any product, closed or open, is going to have a few rough edges.
its a single data cloud instance on a distributed data system, in that respect its similar to products like Amazons SDB and Google's BigTable systems. The data is virtualised across a number of data stores. A lot of telecos use gemstone, its used a lot in financials. Its a True OODBMS which is exactly the model that the ORM layers in frameworks like rails are attempting to simulate on a relational database. OODBMS systems match the datamodel of modern web frameworks closer than any relational system every will do. Other Commercial OODBMS systems are system such as ObjectStore, POET, there a few opensource ones such as GOODS
Avi Bryant gave a fascinating talk about bringing technology developed for Smalltalk into the Ruby world at RailsConf 2007. Apropos of nothing, he bears an uncanny resemblance to Jeremy Davies (Daniel Faraday on "Lost").
Basically he's saying that many of the performance issues with the much-maligned Ruby VM were solved years ago in Smalltalk implementations, and that Ruby ought to incorporate those ideas. Maglev is a big step in this direction.
Soylent Green is peoplicious!
Further research on gemstone's scalability sounds promising. Still have reservations, and would still like to have a non press release review of its capabilities by an independant third party.
Well.. maybe. Or Maybe not. But Definitely not sort of.
I've used Zope a bit (which is Python based, see zope.org), but haven't touched Ruby or Rails yet. This seems to be an alternative to an object-relational mapper for Rails. Since Zope has used an object database from day 1 (iirc), I'd tend to think it would be better and/or cleaner. Anyone that's used both care to compare the two?
-chris
From Wikipedia (yeah it's not a source that's reliable at all, but this is the internet): http://en.wikipedia.org/wiki/Maglev
"Magnetic levitation, maglev, or magnetic suspension is a method by which an object is suspended with no support other than magnetic fields. The electromagnetic force is used to counteract the effects of the gravitational force."
If they're doing *that* with code, I'll be hell of impressed. If not, that's a pretty strange way to brand your project/product/language/whatever that is. Seriously, I'm sure it's awesome, but what is it with all these things (MagLev, Ruby, etc) trying to sound cool by appropriating names of other, already well-established 'things'?
Or next am I going to be using "Ice-cream, Santa Claus on Purple Monkey OODB with Cowboy Hat and Kitchen Fork to PWN the OMGWTFBBQ on the MBA with the XKCD in the Ballroom with the Candlestick"?
Seriously, these names are getting silly.
Not that 'Linux' or 'Ubuntu' or 'MySQL' sound any less silly to people not familiar with them, but at least they're not likely to be confusing or confused for something else.
*/minirant*
I thought the OODBMS fad was finally dead. OODB's resurrect many of the problematic ideas that drove Dr. Codd to formulate relational to begin with. Thus, they could be considered a step backwards. But this would start a paradigm Holy War here and we don't want that, do we?
Table-ized A.I.
I don't use an ORM to simulate an OODBMS. I use an ORM so that I have a system with both Object Oriented and Relational programming models and can use either one when appropriate. There are a lot of people who don't understand the value of Relational programming, and they think that those of us using RDBMS's would really prefer OODBMS's if only we could see the light...
Drink the kool-aid is more like.
I have yet to see a problem simple enough that I would choose to use an OODBMS over an RDBMS while simultaneously being interesting enough that I would bother working on it in the first place.
But maybe I'm just being grumpy. Bah.
JP Morgan uses Gemstone/S behind it's financial systems. I'd say that's a fairly major user. As I understand it MagLev is basically the Gemstone/S Smalltalk VM extended to understand Ruby bytecodes. They (Gemstone) state that the same VM can run Smalltalk, indeed Ruby will be able to talk to Smalltalk objects transparently. The only real questions are how much more complex does Ruby make the VM (Smalltalk VMs are absurdly simple), and what does this complexity do to stability (Smalltalk VMs typically stand up to enormous abuse)? Given the scalability of Gemstone, I don't see MagLev being absurdly scalable as being much of a surprise.
Perhaps you have yet to really understand how an object model that isn't driven by the constraints of the underlying RDMS can make the problem simpler. In particular, the use of a well designed Containers class with well designed efficient enumerators can often make what is a very complex SQL query into a fairly simple combination of select: and inject:into: messages, where you get back a Collection of the objects you want. I see RDMS as being best at fairly simple problems, or for problems where the structure of the data is better understood than the relationships between the objects. And I hate all that overhead you have to manage to get the data into a RDMS.
Perhaps there is more than one way to do it...
You mean like the open source Zope (written in Python), invented over 10 years ago? Great, now I can tie my open source language to a closed-source object store.
Gemstone is a proprietary implementation of Smalltalk and an associated object database. Who does it matter to whether they incorporate a RubyVM into their system or not?
Gemstone also stands for the failure of a particular kind of business model. These people (and others) had a mature OO programming language that was orders of magnitude faster than Ruby, had object persistence, had a great IDE, and supported distributed programming over 15 years ago, and they pissed it all away by making it too expensive and too proprietary.
Because the Smalltalk vendors were greedy and squabbling among themselves, modern OOP arrived more than a decade later in in much poorer form.
I suppose hiding their Smalltalk heritage by calling their system "Gemstone/S" and being forced to incorporate Ruby in order to make their platform attractive is the ultimate indignity.
The first language I learned was BASIC. (I almost learned 8080 assembler and half-learned TI calculator about a year before that, but didn't quite get there.)
After that, I started learning 6800 assembler the bottom-up way (playing with a prototyping board with a monitor/debug ROM). Wired a BASIC onto the board, but I wanted a high-level language. I took Pascal and ForTran at the same time, IIRC, at the local college, and the professor mentioned that I might be able to find a FORTH to load onto it. (He also recommended a floppy drive, which recommendation I studiously ignored.) I got a listing of a 6800 implementation of fig-FORTH and loaded it by hand (saved it to tape). Learned CoBOL and RPG (Report Program Generator, not Role Playing Game) in the meantime.
I thought I understood programming after that. Went to the big U and ended up in CS. (Stupid move.) Learned C and became unable to program in a timely manner. Had to re-implement FORTH in 6809 to finally graduate.
I'm not sure whether it was C that screwed me up or FORTH.
I know I can't program CoBOL any more, and I know that I have lost more than one job because of the time I spent learning to use the tools of C to build modular programs in college. Can't program CoBOL because it's just too much work to convince myself to keep track of all the games you have to play to emulate locality of reference in CoBOL to get UI screens to respond reasonably to user input. I also have problems working with legacy C source code built by high-school-grads who are untrained in modularization, etc., and are plenty willing to burn themselves out keeping track of thousands of globals while churning out close to a thousand lines of C a day. (Copy-paste and change a few globals that should have been parameters, etc.) The code the other guys wrote reminded me of nothing more than CoBOL. Couldn't compete, either, when the managers wanted me to pump out the same number of the same kinds of lines and somehow "add in" the value of my advanced degree.
(huh? This industry is crazy. Mad. Kind of like the rest of the world, I guess.)
I like FORTH. I don't really know much about Smalltalk, except what I may have absorbed studying Objective C and playing with Squeak, but I don't buy it when anyone argues in favor of complicated languages. It seems to me that they (you?) are primarily arguing the equivalent of that C should be written like CoBOL, according to some baroque set of inherited rules that probably had more to do with the tools that were once (but are no longer being) commonly used than with the problem being solved.
So, what are you saying? Is high-school algebra, with its precedence rules, the best algebra, just because modern mathematicians have used it for a long time (until, of course, they dig into the really useful stuff)?
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
that slashdot has really gone downhill. Next thing I'll hear is that you all have girlfriends.
>here is still only one data store in gemstone according to the blog post. Can it be scaled beyond that?
You mean beyond the 17 petrabytes it supports now?
>How?
You add more instances (servers). Any modification made to any server will propogate to the other servers.
>I've never heard of any big website using gemstone.
So? Why should I care whether you have heard of something or not? Why is that relevant?
Have you ever heard of seaside? Smalltalk? Dabbledb?
>If it was open, I'd be more willing to kick its tires, knowing that small problems could be fixed and a community might arise around it.
More than likely there will be a free and limited version you can try. Till then you can try this
http://seaside.gemstone.com/
evil is as evil does
Squeak is most definitely not GPL. It was under a special Apple Open Source license thingy for a while (maybe the APL itself, I don't know) and has now been relicensed under an MIT/X11 license. The squeak community is actually very hostile to the GPL, so you'll see most projects under MIT/X11.
"I may not have morals, but I have standards."
One man's impedance mismatch is another man's layer of abstraction or "protocol".
An OODBMS is fine for a program to use to work on a problem (possibly a "large" one) in a more efficient manner.
But an RDBMS is often more convenient to chuck the results to, so that many different entities (programs, people, etc) can _easily_ do stuff with them.
You could have a central OODBMS to do that sort of stuff - but if you're going to have to take an "overhead" hit anyway, might be preferable to use a popular RDBMS because lots more stuff can talk to it.
Squeak is image-based. The GPL could be seen as applying to an *entire* squeak system, including everything added on thereafter. The legal theory of that is fairly preposterous, but you can see why they're philosophically a little bit down on the idea.
Done with slashdot, done with nerds, getting a life.
Sorry for the lecture in Central-European geography, but you were thinking of Polish notation.
Hungarian is something different altogether. You don't want to know.
I used Gemstone back in the Smalltalk days. It is very nice technology, but also very expensive and proprietary. It is the ultimate vendor lock-in. I won't touch it with a 10-foot pole.
Fewer warts than ruby, and fast runtimes already exist. ;)
;)
The problem is that OODBMs aren't as easy to query using arbitrary queries. You can't easily say "Give me all sales in the last 6 months with totals > $100,000".
It does seem that Gemstone supports a RDBMS bridge, so for OLAP style operations, you can extract the needed data to a RDBMS for further processing/reporting/querying. Of course, perhaps something like a Map/Reduce process could be used to extract data as well.
This also will not necessarily replace MemCache. Gemstone is a database, and still persists to disk. So latency/contenion issues still apply.
It looks like offer something called "GemFire" that runs on top of Gemstone that may provide this kind of caching.
One thing to also remember, is that Gemstone/S is probably not cheap. It has "Enterprise" all over it...
Can't believe that was modded as a troll. So the company isn't new, there were plenty of other comments that had never heard of the company or its product either. I was wrong, not trolling. More importantly, I think the post made a good pont on the differences between open source products and closed source. I, and others, are more willing to kick the tires of an open source product. Closed source has a more difficult time proving itself
Well.. maybe. Or Maybe not. But Definitely not sort of.
What I'm objecting to is the loss of SQL and PL-SQL that occurs with OORDBMS's. Relational programming is an extra tool in the toolbox, and a very valuable one for the issues that surround large or complex datasets. Relational programming provides a proof/set theory/mathematical view of your data that is mostly orthogonal to how Object systems want you to think about data. Using an OORDBMS eliminates a whole way of thinking about data.Exactly my point. Don't wedge yourself into a corner down the road where an integration that requires SQL can't possibly work just because you chose an OODBMS.
This is not entirely true.
The Gemstone system is *not* a shared nothing system. Object persistence between VMs *relies upon* a *single* shared block device.
The system can scale, to a point, with a large commercial SAN system. Even data replication, etc. relies upon a SAN vendor providing this functionality.
At the end of the day, this is *not* a fully distributed system, and has substantial scalability issues *at the very high end*.
MagLev is super cool, and may provide an excellent Ruby implementation if they comform to the Rubinius RubySpecs.
Perhaps most importantly, it will provide an excellent bit of competition for the open source Ruby implementations.
To have a right to do a thing is not at all the same as to be right in doing it
Fowler's Patterns of Enterprise Application Architecture can provide some guidance the various means of doing that if you're not clear. Actually, you did describe two of the common ways of doing that, but you definitely overestimated the complexity of using those approaches.
If the additional effort of mapping the objects into tables causes you to value a simpler and more focused model... is that really a bad thing? In my experience, it's a very good thing.