Tomorrow evening I'm going to do a presentation about Fantom and Tales to the SEAJUG (Seattle Java User Group).

The presentation is a total of up to 2 hours, and usually has about 30-50 attendees.

I'm planning to talk/demo "all" of the Fantom features in pretty good details, along with some code examples, some using fansh, some using the command line, some in the IDE and maybe even show-off fanzy.net a bit too.

Hopefully that fits in ~1 hour+ then there is Q&A and if time allows I'd like to demo Tales a bit too for ~20 minutes.

They are recording this, so for better or worth it will be on-line on vimeo afterward.

I've made my slide with a cool little tool called "s5", which makes your slide just plain CSS/HTML, you just play it fullscreen in the browser, all open standard, lightweight, and easy to put on-line obviously.

Anyway My slides are here (one slide missing right now about DSL, naming, logging and localization ):

http://www.colar.net/fantompres/s5-blank/fantom.html (works best in FF or chrome)

The little ? icons next to each bullet point can be "hovered" with the cursor for more infos/leads on what I'm going to talk about.

Some of the examples (HTMLized) that go along are here:

http://www.colar.net/fantompres/html/

If anybody wants to have a look and has any feedback, it's definitely welcome.

cool. Let us know once the video is up.

Page 11. Mouseover on ActorPool:

No Shared Mutable State under any circumstances

That's strong statement. And it's false. There's at least sys::Unsafe. Also there's possibility of race condition which isn't even tracked as bug.

"No Shared Mutable State" is a practice encouraged by standard library. It's not an enforced rule.

Went fairly well overall. I would say about 40+ attendees.

People seem quite interested and almost all stayed until the end.

Few issues I had where:

• I ran way short on time(1h:45) and only was able to go through half what I wanted to to ... however the presentation is all online, so hopefully they'll have a further look if interested. I've never presented before so I under-estimated how long it takes, and it's an open Q&A during presentation, and there where quite a few.
• When trying to demo stuff in fansh, I ran in a few issues. Fansh just doesn't work nearly the same as Fan. In particular a lot of things that would give a compiler error are "accepted" in fansh. In retrospect I would not have used it.

Overall people where quite interested, except maybe the (few) scala converts :)

There is a video here:

http://vimeo.com/20257517

I made a couple mistakes, but sent corrections in a email to the mailing list the next day.

Also I only had time to cover about half of what I wanted to .. kind of a Fantom 101 :)

Now that I got a chance to look at it, I guess it's kinda painful :)

Some questions I was asked and wasn't sure how to answer:

• What would happen if you have two pods with the same name (exception ? / error ?/ nothing ?)
• What would happens if say PodA depends sys 1.0 and PodB depends sys 1.1 ?

What would happen if you have two pods with the same name (exception ? / error ?/ nothing ?)

It depends on the Env you are using. In the case of the BootEnv which is the default it is impossible because there can be only one lib/fan/foo.pod file. In the case of the PathEnv it is deliberately designed to have a priority order so the first one found is used. If you did want to throw an exception it would be pretty trivial to use a custom Env for that purpose.

What would happens if say PodA depends sys 1.0 and PodB depends sys 1.1 ?

Depending on what version of sys you had, one would not load since its required dependency would not be met. Although eventually I would say for a public API where stability is should be the norm, we would want a convention of declaring your depends as "1+" or something like that.

Out of curiosity, what happens if you have some custom foo pod and PodA depends on foo 1.0 and PodB depends on foo 1.1?

I assumed pods with the same name but different versions could both be loaded and coexist in the case of, well, basically any pod but sys, but maybe that's not a safe assumption?

I assumed pods with the same name but different versions could both be loaded and coexist in the case of, well, basically any pod but sys, but maybe that's not a safe assumption?

The Envs we ship with Fantom do not allow that - only one version of a pod is loaed into memory at one time.

Although the lower level hooks allow that sort of thing (for example if you ran pods as OSGI bundles)

Huh. Is that a deliberate design decision?

It seems to me that it would be a sensible default in terms of robustness; if I code my pod to work with version 1.1 of foo and 1.2 of bar it would be great to know I didn't have to worry about backwards compatibility because I'd always have exactly those versions loaded...I guess the drawback is that such a dependency system could get resource-intensive?

Huh. Is that a deliberate design decision?

It is.

The biggest problem with loading multiple versions of the same pod is that foo can leak objects from its dependencies to bar which expects a different version. That's something that is impossible to check statically in Fantom (you could use Obj return value). Hiding internal classes via classloader mechanism has its own problems.

It is a nasty problem that can't be easily avoided - and it is generally ignored in all popular languages. Even functional languages usually use some kind of global namespace which produce "versioning" headaches. A notable exception is Newspeak which forbids global state and forces all dependencies to be explicit at the class level.

The current design works well for smaller projects. I am still unsure how will it scale though.