Hi guys. Several people asked several times the differences between the two "new" serializers Fuel and StOMP. Runar wrote several blog posts about it: http://blog.epigent.com/2011/07/new-smalltalk-object-serializers-fuel.html http://blog.epigent.com/2011/07/comparing-speed-of-stomp-and-fuel.html http://blog.epigent.com/2011/07/fuel-and-stomp-best-of-both.html So I would like to give you my point of view as a Fuel developer. Which are the main differences between Fuel and StOMP? 1) Portability. What that means? "portability" is too wide to just talk without details. For me, portability in this case means two things: portable format and portable code. Portable format: In a dialect/language XXX be able to materialize a stream which was serialized in a dialect/language YYY. Portable code: That the code of the serializer can also work in another dialect/language (not necessary including portable format). Fuel will does not do focus in portable format. At least, we will not do extra effort to support that. Regarding portable code, it is not Fuel first goal to be portable to other dialects but it is not that difficult anyway. In fact, Fuel has been even ported to Newspeak. In the contrary to Fuel, StOMP wants to be portable in both ways, format and code. But of course, it is difficult to find portable representation of certain objects like BlockClosure, MethodContext, Class, Trait, etc. StOMP do not deal which such objects due to the lack of those portable representations. In Fuel, we can serialize those objects but not in a portable way. So...next differences are: 2) In Fuel we want to be able to correctly serialize *any* kind of object. 3) Fuel will try to get the fastest way to serialize or materialize an object. StOMP will use the most fastest available while trying to generate a portable representation. 4) Another important difference is that Fuel is faster in materialization and StOMP in serialization. Why? Because a tool build on top of Fuel will be used for code management and loading is done much more times than saving (think as in parcels). Notice that this doesn't mean we are slow in serialization. We are faster than most of the serializers, but not as much as StOMP. What are the reasons of the differences in performance? because of their design and internals. It is a trade-off. To be faster at materialization, we do some extra work in serialization. StOMP does not do extra optimization for materialization and hence serialization is faster. What is that "extra" we do? Ok, we have wrote a whole paper for IWST 2011 so I won't repeat myself. I will let you know when we get the notifications of the paper so that we can make it public. Regarding your excellent paragraph: "But... A partial solution would be to use an intermediate format for *serialization*. This format would support fast serialization, and therefore be similar to StOMP's format. The intermediate format would for example be used when a user needs to quickly commit changes to a database. Later, the intermediate format could be transformed to a format that is better optimized for *deserialization*. This transformation would typically be done as a background task. The deserializer would be able to (transparently) understand both the intermediate format and the optimized format." I can just tell you that it is an excellent idea and we talked with Martin about it, but I am not sure about how easier it would be. Maybe it is just easier to have 2 serializers with 2 different goals :) Regarding "To me it appears like StOMP has better support for serialization/deserialization "hook" methods<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/hook-methods>, class renaming<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/renaming> and shape changing<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/shapechangers>. Hopefully, Fuel can learn from StOMP in this field." I totally agree. StOMP's hook methods are awesome and we want to have the same in Fuel. In fact, check the issue tracker and you will see several open issues regarding this :) I think class renaming and shape changing are fine in Fuel. Finally, notice that we are not "competitors". We have sent several private emails between us and Masashi UMEZAWA and we are trying to share as much as possible. -- Mariano http://marianopeck.wordpress.com