Forgot your password?
typodupeerror
Databases Programming Software IT

MagLev, Ruby VM on Gemstone OODB, Wows RailsConf 132

Posted by kdawson
from the rails-oh-i-get-it dept.
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."
This discussion has been archived. No new comments can be posted.

MagLev, Ruby VM on Gemstone OODB, Wows RailsConf

Comments Filter:
  • I'm sorry... (Score:5, Insightful)

    by Anonymous Coward on Sunday June 01, 2008 @12:03AM (#23614609)
    What?
    • Re:I'm sorry... (Score:5, Informative)

      by corsec67 (627446) on Sunday June 01, 2008 @12:06AM (#23614615) Homepage Journal
      Agreed, I develop in Ruby on Rails full-time, and I barely understood 1/3 of that summary.

      OODB = Object Oriented Database (possibly a OODB type of model) helps in translating that from specialist to mere geek.
      • by Santana (103744)
        Then maybe you've just been too busy for keeping up with the news.

        http://www.infoq.com/news/2008/04/maglev-gemstone-builds-ruby [infoq.com]

        and I'm not even a Rails developer, just a Ruby enthusiast.
      • OODB, oh oh (Score:3, Interesting)

        by Tablizer (95088)
        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?
        • by DarkOx (621550)
          Not really OODB, while I agree with you is a fad in that they are more interesting then useful (so far anyway) but they are not what Codd was aiming to fix.

          I am way to young to have been their but I do recall the history portions of my computer science education. Hey even in engineering like disiplines those who don't know their history are doomed to repeat it. What existed before RDBs at least in the saleable world were table systems based on flat files with no integrity checking and implemented without
        • A step backwards? A fad? How exactly is designing a database capable of doing things that RDBMS cannot (or cannot do easily, that does not matter) supposed to be "a step backwards"? There are tasks for which using an RDBMS is simply inadequate, but since the problem still does not fit into memory, you still need some form of database (if we define "database" as a piece of software capable of handling a big amount of data that does not force you to think how yo store it and lets you do the creative work).

          W

          • by nuzak (959558)
            You're arguing with Tablizer here. Visit the page in his sig and, well, you'll get the idea what he's about. He used to be a lot worse.

            Anyway, an OODBMS can express relations just fine; they're just not usually locked in to a fixed schema. What gave Codd fits was that early OODBs didn't even have so much of a formal schema mechanism (and some still don't) so you'd have to query by following a graph and no other way. Really good OODBs have a solid meta-model you can target for queries, and thus implement
          • by Ed Avis (5917)

            What are those "problematic ideas" you are taling about and how does an RDBMS help us with analyzing large tree and/or graph datasets, knowledge bases and other forms of data that does not fit the relational model?
            How does an object-oriented database system help with them?
            • How does an object-oriented database system help with them?

              Usually by allowing to run arbitrary algorithms on the server side (or in-process, in case of embedded OODBMS), often in a natively compiled language (like Allegro Common Lisp in case of AllegroCache, which has *very* high performance), without client-to-server roundtrips, without impedance mismatches, without forcing you to express the idea with relational operators only.

              If you can't express the algorithm with sorts and joins, you have to do cost

              • Re: (Score:2, Interesting)

                by Ed Avis (5917)
                A relational database system usually allows you to write stored procedures to do the data manipulation entirely in the server without roundtrips. That's not the issue. What matters is your second point 'forcing you to express the idea with relational operators only'. Sometimes relational operators are a good fit for the data model and, if you twist your neurons in the right way to think of the problem relationally, allow you a much higher-level way to express an algorithm than procedural code, while keep
                • Re: (Score:2, Interesting)

                  by regebro (636069)
                  "What efficiency advantages do they have over naive 'fetch record; do something; fetch another record' procedural code for dealing with large amounts of data?"

                  Efficiency I don't know. But with a good OODB you do not "fetch record, do something, write start over". You just do it. In your typical ZODB application there is no difference between doing something on objects in memory and doing it on objects stored in the database. The only difference is that the objects inherit from a persistent subclass.

                  The bene
          • Re: (Score:2, Insightful)

            by Tablizer (95088)
            What are those "problematic ideas" you are taling about and how does an RDBMS help us with analyzing large tree and/or graph datasets, knowledge bases and other forms of data that does not fit the relational model?

            It is possible to add declarative tree/graph traversal to a query language, and Oracle does a little bit of this. Plus, "node hopping", if needed, can be done in a relational database just as well as a non-relational one. Its just that existing implementations are not optimized for them. But tha
        • by regebro (636069)
          I've used ZODB for almost ten years, and in dynamic languages like Python OODB is fantastic. In static languages it must be a pain. :)
    • OODB - Open Office Databases?
    • by YodaYid (1049908)
      It looks like it's a way to make Ruby on Rails faster, using some technology that was designed for SmallTalk.
    • Great Ruby news (Score:5, Informative)

      by Santana (103744) on Sunday June 01, 2008 @12:56AM (#23614799) Homepage
      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.)
      • I thought everyone using Ruby on Rails was going back to Ruby. Perhaps RoR interest is still going strong.
        • I thought everyone using Ruby on Rails was going back to Ruby. Perhaps RoR interest is still going strong.


          There is still plenty of RoR interest, plus MagLev is just as relevant to a lot of what people leave RoR for.
    • Re:I'm sorry... (Score:4, Informative)

      by ESqVIP (782999) on Sunday June 01, 2008 @01:55AM (#23614989)

      Indeed, incredibly poor summary.

      Basically, GemStone, a company which has been working on large-scale object-oriented database systems [wikipedia.org] and a Smalltalk implementation (GemStone/S) for decades, has decided to support Ruby on their infrastructure. Turns out Ruby is indeed quite similar to Smalltalk, and some microbenchmarks already show them as being 8~60x faster than MRI (the main Ruby 1.8 implementation). Should those numbers remain consistent, this will be an incredibly fast implementation of a popular scripting language, surpassing by Python, PHP, Lua, and other Ruby implementations in raw numbers.

      This might be a massive push for Ruby/Rails on "enterprise" systems. And if they succeed, this could also be one interesting step reviving the popularity of OODBMSs.

      • by xiaomai (904921)
        Any idea if this maglev stuff is free (as in speech)? It looks like it might just be a closed-source commercial offering?
        • Re: (Score:2, Informative)

          by ESqVIP (782999)

          Definitely not. They've been talking about a free-gratis version, and there's chance they will open some of their standard library (possibly sharing part of it with Rubinius, since both have a similar goal of writing as much as possible directly in Ruby), but you shouldn't expect them opening their VM or OODB stuff anytime soon.

          But well, if anything, they show how far open implementations of dynamic languages can get performance-wise. The current breed of languages has always lagged behind the old ones (l

        • Any idea if this maglev stuff is free (as in speech)? It looks like it might just be a closed-source commercial offering?

          "GemStone is still pondering a pricing model for MagLev. Bob Walker did state that there will be a free version available."

      • Re:I'm sorry... (Score:5, Informative)

        by pnagel (107544) on Sunday June 01, 2008 @05:13AM (#23615605)

        Basically, GemStone, a company which has been working on large-scale object-oriented database systems [wikipedia.org] and a Smalltalk implementation (GemStone/S)

        You make it sound as if the object oriented database and the Smalltalk implementation are two separate products. Which is a common misconception.

        To oversimplify, GemStone's Smalltalk VM is an OODB. It adds the following features to the language:
            1) Begin transaction, commit transaction, abort transaction.
            2) All of your process space, your global variables, your datastructures etc. are persisted. You can switch power-cycle your computer and have the same program running as used to run before.

        I'm sure they did the same for Ruby with maglev.

        This approach cuts out layers and layers of persistence crap. Bye bye object-relational persistence mapping crud.
        • by Unoti (731964)

          You can switch power-cycle your computer and have the same program running as used to run before.

          The especially great thing about this is that when our Rails apps barf, the only recourse is to reboot rails. Now the clusterfuckery can be persisted!

          Ruby on Rails is delightful to develop in. But deploying it across something that gets hammered a lot is a nightmare. Say what you will, but scaling up Python or PHP is way easier.

          Quote of the day (actually I see this dozens of times per day): "Twitter retu

      • by Ant P. (974313)
        60 TIMES faster? As in 1.6% runtime? Wow, that's big enough to make me actually pay attention to ruby... up until now the one thing I keep hearing from everyone about it is that it's a nice language but ridiculously slow.
  • by Marbleless (640965) on Sunday June 01, 2008 @12:06AM (#23614617)
    >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! ;)
  • Sad . . . (Score:5, Funny)

    by Anonymous Coward on Sunday June 01, 2008 @12:10AM (#23614631)
    > 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.
  • WTF ?! (Score:1, Informative)

    by Anonymous Coward
    That has got to be the worst summary line I've ever read in the history of slashdot.
  • Shot in the dark (Score:4, Insightful)

    by smitty_one_each (243267) * on Sunday June 01, 2008 @12:24AM (#23614685) Homepage Journal
    "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?
    • by noidentity (188756) on Sunday June 01, 2008 @04:46AM (#23615541)
      Just yesterday I was working on SuperCollider, hooking it with OilRig, implemented with SuperTanker, using ConcreteRoad as the substrate. I had some problems with the DeepSea module, but it was really due to RadioAntenna. You're confused? These are just the names of some database libraries, nothing to do with what their names imply.
    • 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.
      Well at least you got the conference right, I thought the RAILS configuration file got wowed somehow!
  • by stockmaster (574940) on Sunday June 01, 2008 @01:17AM (#23614871) Homepage
    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...
    • Re: (Score:2, Interesting)

      Doubtful. When people have scalability problems it's not ruby, it's rails. Web applications don't need much cpu but they do need to use memory in a reasonably efficient manner - something that rails cannot currently do.
    • by TubeSteak (669689)

      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.

      "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" means that they're going to keep their proprietary solution to themselves and make lots of money.

      Gemstone has spent a lot of time optimizing their code, are they just going to give that away for free?

      • Re: (Score:1, Troll)

        by crawling_chaos (23007)
        You mean that when you pay someone to write software you get a product that scales and is documented and all of the other crap that most open source programmers seem to actively sneer at, because that kind of work seems menial and boring to them? Perish the thought!
    • by dkf (304284)

      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.

      Well, without in any way detracting from the technical prowess of the Gemstone folks - sounds like they know their stuff with OODBs - beating the default implementation Ruby on the performance front isn't that hard. Certainly traditionally, Ruby was slow by all independent measures such as the Language Shootout [debian.org].

      I suppose this does beg the questions: does the Gemstone-based system do better in the shootout benchmarks? If so, by how much? And since there's often tradeoffs between optimizations and (frequentl

  • Ruby Shootout (Score:5, Interesting)

    by cryptoluddite (658517) on Sunday June 01, 2008 @01:18AM (#23614873)

    The MagLev VM, although only partially implemented, so far outperforms MRI 1.8.
    Being 'faster than 1.8' is a pretty weak claim compared to the competition:

    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 .NET/CLR which started out trying to do everything and ended up doing few things well.
    • by Santana (103744)

      Being 'faster than 1.8' is a pretty weak claim compared to the competition:

      Well, Matz's Ruby (or MRI) is still _the_ reference, so it makes sense to compare to it. What is really missing is how fast Maglev is. This blog post [obiefernandez.com] talks about 8x to 60x faster, which is impressive.

      • The news of the conference says they have 36 of 43(?) tests 'running significantly faster'. Ruby 1.9 has 38 tests running 'significantly faster'. So some guys' blog about results he didn't even see is pretty doubtful.

        An 8x-60x faster is probably a few numerical benchmarks or possibly something like a regex implementation, and even if true won't have much impact on Ruby overall performance (since you don't use Ruby or Smalltalk for numerical work anyway).

        Still, Smalltalk VMs are very advanced and the added
        • Re: (Score:1, Insightful)

          by Anonymous Coward
          "precedence" is not sane - it's a complicated set of exceptions that make a programing language more complicated to implement, but don't really gain anything. If the only thing you can think of against smalltalk is not implementing mathematical precedence rules, then you're scratching at straws.

          Ruby's syntax is not better than smalltalk - it's more complicated. the only thing "better" about it, is that it sometimes vaguely resembles C syntax.

          If you spent ten minute with Smalltalk's syntax you'd realise th
          • Ruby's syntax is not better than smalltalk - it's more complicated. the only thing "better" about it, is that it sometimes vaguely resembles C syntax.

            Smalltalk's syntax is not complicated enough. Algol syntax has dominated for 60 years. If you think having a C-like syntax is a flaw then you are not thinking rationally.

            "precedence" is not sane - it's a complicated set of exceptions that make a programing language more complicated to implement, but don't really gain anything.

            So they teach math using hungarian notation in schools... where exactly? Our natural languages contain precedence and all sorts of complicated syntax that we are hardwired to understand. Smalltalk fails because it wants to be 'pure' and 'simple' in places where that is not an advantage.

            • 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
            • So they teach math using hungarian notation in schools

              Sorry for the lecture in Central-European geography, but you were thinking of Polish notation [wikipedia.org].

              Hungarian [wikipedia.org] is something different altogether. You don't want to know.

    • I was one of the few who saw MagLev run against MRI before RailsConf, and the author of the shootout you're referencing. Ruby 1.9 is faster than 1.8. JRuby is faster than 1.8. MagLev is not only faster than 1.8, it blows 1.8 out of the water. Just to give you an example, in a few tests, Ruby 1.8 takes about 20 seconds to execute them, while MagLev takes about a second. The new shootout will be published soon [antoniocangiano.com] and it'll include MagLev. By doing this, we'll have a fair comparison on multiple operating systems
      • Re:Ruby Shootout (Score:4, Interesting)

        by cryptoluddite (658517) on Sunday June 01, 2008 @05:40AM (#23615695)
        I took a look at some more of the benchmarks and they are pretty much universally meaningless once you throw in a good optimizing VM. For instance translating the method benchmark into Java and having it loop 2^31 times instead of 6 million times and Java is 29,000 times faster than Ruby 2.8.

        Adding a simple global+=1 to the method body makes Java only 16,000 times faster than Ruby 2.8.

        Replacing the +1 with global*=5 makes the Java version only 536 times faster than Ruby 2.8.

        These are the kinds of optimizations MagLev is doing, and they don't translate into anywhere near the gains in actual code. So you see, you really need to rethink your tests. Even for something seemingly ok like modifying a global can depend on how it is modified and what the VM can optimize (+1 vs *5). Frankly I would just test these different Ruby implementations using the regular shootout [debian.org] code, since these have been designed not to be optimized out.
        • These tests were not implemented by me and are considered âoestandardâ in the Ruby community (they come from Yarv's repository). However, you have a valid point, also raised by Anonymous, so I'll manually modify the ones that are subject to artificial gains due optimization and "laziness" of the VM. And as I mentioned before, I'll add some extra tests of my own which won't be subject to this sort of flaw.
          • by Santana (103744)

            These tests were not implemented by me and are considered âoestandardâ in the Ruby community (they come from Yarv's repository).

            Where there's a common misconception. YARV's tests were not supposed to be used for benchmarking Ruby, according to its author [grayproductions.net]:

            Benchmark tests: Some people using YARV's bnechmarks I wrote. But I didn't write these codes to measure "Ruby's general benchmark test", but to measure speed-up ratio on YARV. It's means that I wrote codes what YARV optimizes. We must prep

            • Santana, perhaps I shouldn't have said "standard". What I meant was that Yarv is not the only implementation that adopts them (e.g. they are in Rubinius' repository as well). In my new shootout I'll introduce more general benchmark tests that should remove the advantages from any VM that specifically targets these micro-tests.
    • by cytg.net (912690)
      "What is cool is how well the Java-based Ruby implementations do: JRuby and XRuby." - If im not mistaken, the new market attention of java isnt java, its opening up the jvm to get rid of the "j" and embrace all those other pesky languages as well, offer them a reliable industry proven robust vm. Changes are cometh' ..
    • by Duwke (586308)
      What about ruby.net using the DLR (Microsoft's Dynamic Language Runtime)? It was my understanding that the CLR was not well suited for dynamic languages as your post likely confirms. Hence, this is why they created the new runtime.
  • Neither the summary nor TFA inspired me with awe. Guess I'm losing it.
    • by stickytar (96286)
      i wish i had mod points for you. i'm with you on this one.
    • by n3tcat (664243)
      It's because they chose to constantly reference trains. Nobody plays with trains anymore. They're past the point where they can be considered "old skool" and are now just a dead hobby. Now if they had gone with Warhammer 40k references, people would get all excited about the new Warp Storm VM system!
  • by OldManAndTheC++ (723450) on Sunday June 01, 2008 @01:46AM (#23614963)
    Avi Bryant gave a fascinating talk [railsconf.blip.tv] about bringing technology developed for Smalltalk into the Ruby world at RailsConf 2007. Apropos of nothing, he bears an uncanny resemblance to Jeremy Davies [imdb.com] (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.
  • 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?
  • by MrMista_B (891430) on Sunday June 01, 2008 @02:04AM (#23615023)
    From Wikipedia (yeah it's not a source that's reliable at all, but this is the internet): http://en.wikipedia.org/wiki/Maglev [wikipedia.org]

    "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*
    • by yukster (586300)
      Uh, it's called Ruby on RAILS... like a train. MagLev is a really really fast train. Seems like a pretty sensible name to me.
      • So ruby has gone off the rails?
        • by raynet (51803)
          Noh, but instead it will use one big ass rail rather than two lean ones and cost of fortune to run.
        • by Yetihehe (971185)
          No, now it transcended and is above all earthly rails.
        • by cytg.net (912690)
          railguns in quake IS the shit though ..
          • by cytg.net (912690)
            also, sexual references like
            .."I've nailed her"
            really could do with a penis transplant, perhaps like
            .."I've railed her"
            cause the former really isnt that flattering to the auther is it?.. perhaps she also laughed out loud at your 'tool'?
            ..
            ..anyway, have a ticket!
    • You can do it with Python: http://xkcd.com/353// [xkcd.com]
    • It's a joke, really. Ruby on Rails. MagLev trains are faster than normal trains, so Ruby on MagLev should be faster. It's faster rails. That said, it would be great if the headline and summary were rewritten to make this understandable.
      • by cytg.net (912690)
        well, obviously, if the rails are moving at speed x the same direction as the train .. you would gain x speed total wouldnt you?
      • Re: (Score:3, Funny)

        by Sique (173459)
        With regular trains reaching 575 km/h (357 mph) and the world record for MagLevs being 581 km/h (361 mph), there is really no difference in speed for both technologies.
    • by cytg.net (912690)
      mm..right .. when was the last time you saw code implement zero gravity in reality? oh yea ..

      NEO
      Do you always look at it
      encoded?

      CYPHER
      Have to. The image
      translators sort of work
      for the construct programs
      but there's way too much
      information to decode the
      Matrix. You get used to
      it, though. Your brain
      does the translating. I
      don't even see the code.
      All I see is blonde,
      b
    • by oldhack (1037484)
      Compupter world became a media world, and now we all talk like jibbering marketing (cheap shot half-intended) idiots. Some subsectors apparently more idiotic than others. Price paid for going "mainstream".
  • You mean like the open source Zope [zope.org] (written in Python), invented over 10 years ago [wikipedia.org]? Great, now I can tie my open source language to a closed-source object store.

  • news that matters? (Score:5, Insightful)

    by nguy (1207026) on Sunday June 01, 2008 @06:00AM (#23615775)
    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.
    • by pnagel (107544)

      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.

      That's changing.

      You can download GemStone/S 64 Web Edition for free, and use it free (for commercial use, too!). Only when your database grows beyond about 2 gigs, you need to get a license, which is about $7000 a year.

      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.

      They haven't incorporated ruby into GemStone/S to make it attractive; they haven't incorporated it into GemStone/S at all.

      Maglev is a distinct product.

      • Re: (Score:3, Insightful)

        by angdraug (518388)

        You can download GemStone/S 64 Web Edition for free, and use it free (for commercial use, too!). Only when your database grows beyond about 2 gigs, you need to get a license, which is about $7000 a year.

        Nowhere near good enough. $7000 a year is the exact outrage the previous poster was talking about. And 2 gigs is not much if you consider that it has to hold all your objects and their fleas. Not to mention that it's not really free (as in freedom) until it can be found in Debian/main.

      • Re: (Score:3, Interesting)

        by nguy (1207026)
        That's changing.

        Evidently not.

        You can download GemStone/S 64 Web Edition for free, and use it free (for commercial use, too!). Only when your database grows beyond about 2 gigs, you need to get a license, which is about $7000 a year.

        It's that sort of bullshit that killed systems like Smalltalk in the market. Companies like Gemstone will still be able to extract money from their captive audience for a couple of decades, but mainstream platforms are eating away at their market share, year after year.

        The only

This is a good time to punt work.

Working...