#2344 Questions about Fantom future

andrey Wed 10 Sep 2014

Hello, fellow fantomers!

I discovered Fan(tom) back in 2008 and immediately felt in love. My idea was about Fantom to become main programming language in the company (Xored) for most of our development efforts, that’s why we also initiated F4 IDE development and done something useful.

Long story short, we did not manage internally Fantom to become mainstream but this is not because of Fantom, which is great, but because of number of another reasons. Anyway I was always looking at Fantom, which we used anyway in a bunch of small project.

Now it is 2014 and I’m behind a hard decision on main programming language for the next big thing (a huge project potentially expecting tens of man-years efforts). We definitely need to target both JVM and JavaScript, and I definitely know such language will not be neither Scala, Clojure nor Java (despite Java8 things, etc).

It’s another story why I’m contrary to Scala and Clojure, which are both amazing languages/concepts, but I have many reasons not to use them for development of company’s next big thing.

So after 6 years of looking at JVM languages evolution, I’m still very pro-Fantom despite Fantom development (as a language and as an ecosystem) has been stalled.

Recently, I quickly re-looked at “alternatives”, which are progressing (Kotlin and Ceylon), but was not inspired with them. I can spell many concrete small things, which I like more in Kotlin or Ceylon comparing to Fantom or spell some things which I’d be happy to see in Fantom. However looking from 10,000 feets on the whole things I think that Fantom language, runtime, and concepts is still better balanced for practical engineering.

I have no alternatives in mind besides start development with Fantom, the only thing which stops me is Fantom future. Obviously if we seriously rely on the language we’d be happy to see language/ecosystem evolution as well as contribute to such an evolution.

So the first set of question I have is Brian, Andy, and community welcomes idea about potential next round of language evolution, or everyone is fine with current status? Is there any resources ecosystem willing to contribute? And a question to Brian and Andy about their thoughts on future evolution and if this is something the language creators would like to drive, or if there are no time to be involved in some other form like coordinate, mentor, etc?

There were many things for potential evolution on forum, which are being discussed and developed further may lead to better language or even the best practical language around.

At the moment, personally I’m dreaming about improvements in following areas (but this is only dump of my current needs, which are also evolve in time):

Value Types.

Similar to JVM discussions http://cr.openjdk.java.net/~jrose/values/values-0.html, https://blogs.oracle.com/jrose/entry/value\_types\_in\_the\_vm or http://www.slideshare.net/howarddgreen/objectlayout. We’re going to do serious data crunching, and there is a nice blog on this at Mechanical Sympathy http://mechanical-sympathy.blogspot.ru/2012/10/compact-off-heap-structurestuples-in.html regarding off heap data structures, performance improvements in order of magnitude, and there are successful implementation of these approaches like for example: SBE, which shows performance improvements up to 30 times comparing to Google’s protobuf.

This shall play nicely with JavaScript as well, which is proved by LLJS and emscripten. It’s hard to achieve such goal on library level, but compiler and language extension may do this work very well. It would be very interesting to hear about Brian's experience with Axon and performance issues on this topic.

Better Concurrency/Async Programming.

This days I would like to see most (all) of my code executing asynchronously. Which means I would like to start millions of logical execution contexts within my application on a single VM. Current Fantom’s actor model is not expressive enough to develop fully async applications (just imagine complex actor-only application). There can be many approaches to this topic, like CSP (Go-alike) communication channels and lightweight tasks, async/await (C# alike) keywords, etc… Anyway all of such approaches would need compiler support.

Better Immutability.

There is a huge room for improvements like

  • Immutable (persistent) collection in runtime library.
  • Better immutable classes, I guess many refused const classes when they are const or used Unsafe, because of language reasons.
  • Const fields/locals outside of const class (Scala’s val).

Better modularization.

Pods are good but I hope for more developments in this area. Currently all pods are loaded with single root classloader, which prevents using different versions of pod within one application and pod unloading. This also prevent correct use of pods within application containers like OSGi, Servlet, vert.x, etc — all modern containers are class-loader per component.

For example in F4, we made a custom version of Fantom runtime which is pod per classloader, and this is main reason why it takes a time for F4 to upgrade internal Fantom runtime -> we need to backport these changes to the new Fantom versions. On the JavaScript side current situation is even worse, and it would be great to improve things in favor of CommonJS modules, or anything else.

Language.

Restart discussions on other language topics like generics, tuples, union types, pattern matching, etc.

I'd be happy to know community thoughts on starting with Fantom for a big project and as a result relying on Fantom for the next decade, as well as community thoughts on language evolution and if there are people considering their future with Fantom seriously.

Thank you very much, Andrey Xored Software Inc

tomcl Wed 10 Sep 2014

Great list of language issues.

My thoughts on the gen topics, looking at previous discussion and my POV:

generics - yes must be improved a bit one way or another. Maybe do not need full-blooded generics.

tuples - not proven, they don't seem to fit well. Could as easily be happy with very lightweight anonymous classes used for return types - special syntax making this look good.

union types - nice

pattern matching - nice - maybe answer depends on how union types are done

And interesting (not surprising) to hear Fantom still wins cf other post-Java languages. That also (in spite of my Ceylon post recently) is my opinion.

My concern about long-term Fantom is that it maybe is not exciting enough to attract enough of a user base. Now actually "not exciting" means "is a more capable gen purpose language". But I'm not sure that wins PR battles. And without user base it will die.

My other concern is short-term. Fantom has good tooling. Very nice packaged cmd line tools + F4. But...

It is a real pain setting everything up for the first time on a standard win 64 bit system. It should not be. But I found it was, others here have found it was.

Multiple Java versions. Multiple Fantom cmd line versions. Multiple F4 versions.

There should be shrink-wrapped installer that will check for Java dependencies, deal with them nicely asking to install if needed, install right versions of cmd line tools and F4, deal with the JVM linkage. Maybe just for win 64bit win7 and win8 since that now must be 90% of users - and linux users can take care for themselves!

And, there are a few little issues with F4 like the fact that run will run whether build succeeds or fails... Not a big deal, except off-putting to newbies. But Fantom needs to be on-putting to newbies.

best wishes, Tom

PS - THANK YOU for F4. a lot of work and a very nice product, without which Fantom would be less.

rasa Wed 10 Sep 2014

I was really looking for this kind of topic. As I'm a newbie to Fantom, I didn't want to start it by myself but this topic appeared at the right time.

What concerns myself and if I'm not wrong, this language is being developed by only two developers and it appears that they are brothers. Other popular JVM languages are supported by large companies/teams: Java->Oracle, Ceylon->RedHat, Kotlin->JetBrains, Groovy->GoPivotal i.e. VMware, Scala->École Polytechnique Fédérale de Lausanne. What will happen when Andy and Brian decide that they got tired of programming? I think that some large company should embrace further language development as soon as possible and make marketing for it. Maybe, the Xored could carry the torch?

@andrey, you forgot to mention Groovy&Grails. Do they fit your needs?

Next, about language improvements. Although I'm fan of minimalism it is very difficult to stick to this principle. Look what happens with the Kotlin development right now. They are under big pressure of the community to add many new feataures: constructs, operators etc. Will they resist, we'll see. And yes, I would also like to see some new features in Fantom. Some of them I have already mention in my previous posts, e.g. pod version support (modularization support as @andrey wrote), pattern matching, support for smaller number types as 64-bit is inappropriate for e.g. image processing etc. Contrary to @tomcl, I would like to see tuples in Fantom as I find them very usable. And also contrary to @tomcl, I had no problem during setting up Fantom and F4 under Win7 64bit. I believe him that he or some other people had hard time to set everything up correctly but I have opposite experience.

Besides new features, Fantom has some serious problems. It lacks bigger Android support, bigger community, better IDE support, books, blogs, success stories, marketing promotion.

SlimerDude Wed 10 Sep 2014

Hi Andrey,

a question to Brian and Andy about their thoughts on future evolution

Ha ha! I'd imagine Brain and Andy were hoping their work was almost done! :)

Anyway, this topic seems to be about a future Fantom 1.1 or 2.0 release, so here are my quick (and harsh) thoughts:

Get Rid of DSLs

Firstly, ditch DSLs. Really.

The syntax is awkward, they only parse strings into objects, and currently I can't see them doing much more than a good static fromStr() method.

Ivan's excellent article on Exploring Fantom DSLs highlights that their usage is limited by their partial integration with the compiler. Which brings me to:

Introduce Compilation Pre-processing

This takes over where DSLs left off. Introduce a dedicated step in the compilation process where Fantom code could be altered before being finalised / emitted. Then similar to Java's Project Lombok and JSR 269 any part of Fantom code could be instrumented.

Why?

Because then it becomes easy to create, implement and experiment with your own annotations / keywords at a system level.

Rather than endless discussions on the pro's and con's of potentially introducing a new system annotation - you could just write it yourself!

A good example would be the once keyword. Personally, I don't like it. It is a fantastic idea and saves on boilerplate code... but to me it's not core. It's not core enough to warrant being a reserved Fantom keyword. (I think I've used it twice!)

But if we had compilation pre-processing, then I could write a pod with a @Once facet that performs the same instrumentation that the once keyword does. Then I could have the same once functionality but without it being part of Fantom.

Now, the fate of once has already been decided. But as soon as you start opening up ideas for language features, lots of similar concepts will be argued. Some people will be for, and others against. But if you could write a library / pod to achieve the same then the argument becomes a mute point; if people really want it then they implement it themselves.

It would also free up Brain and Andy's time to concentrate on more obvious core concepts!

Other

are people considering their future with Fantom seriously.

Hmmm... I'd like to think I am.

Steve.

brian Wed 10 Sep 2014

Hi Andrey,

Glad to hear you are still interested in Fantom! You guys have been quiet.

We still invest a ton of time in Fantom, although as you've seen its mostly been API improvements, not core language features. That is keeping with my philosophy that good APIs tend to provide productivity more than language features since most language have such crappy APIs :) There is tons of things that go into a typical application these days, and having clean libraries to glue functionality together is still in my opinion the most important thing a platform can provide. We still have a ways to go on libraries, but its coming. We have many high quality libraries we've developed commercially that we will open source at some point too.

I would say still the most critical issue for Fantom is IDE support. And what you guys have done with F4 is probably the most important community contribution so far. Since a good IDE is desired by most developers (all the non VI/emacs guys :)

I still think there is plenty to do improve the language itself, but I like that we've given it a few years to gel. What we have works really well. And its given us time for new languages like Go, Swift, etc to come along to see what is working well in other languages.

Regarding your specific features:

  • value types: we do very serious number crunching in SkySpark and I've been pretty pleased with performance; but would love to see value types. But that is going to have to wait until JVM gets support which realistically isn't for years. First up would be switching to Java 8 invokedynamic (which I haven't tested to see what kind of performance improvements we would get)
  • concurrency/immutability: I would very much like to continue improving this
  • modularization: I personally despise the OSGi model and think that sort of complexity is better warranted with multiple processes then multiple classloaders in the same VM; but I don't want to force that decision on everybody - that was the goal of pluggable Env so that you can build your own. So I would help you to add hooks as needed. regarding JS modularity there wasn't really anything available when we started, but I would welcome discussing that
  • generics: I do want generics, but I really want them to work with a simple design and not require a PhD to understand. I've been watching Go to see what might come of generics there since on many fronts they have similar design philosophy

Our own business has been very successful and continues to grow the ecosystem of Fantom developers. So now is actually a good time to start thinking about what the next raft of features might be. But once again my priorities would be:

  1. What key libraries are we missing and how do we get production quality for both Java and JS. We still aren't where I'd like to be with fwt in JS for example
  2. How we can we continue to make F4 awesome, or potentially get that level of polish in other IDEs
  3. Carefully select the most important languages features and design them cleanly into the language. Although I do want to continue to add features, I want to be conservative and move slowly so that we don't end up with a kitchen sink language. For example it was over a year long discussion to finally come up with an elegant it-block design that solved our immutable class constructor problem - but I think it was well worth the effort that everybody put into that

andrey Fri 12 Sep 2014

Hi folks!

Awesome, thank you very much for your replies, which adds a lot of optimism! I’ll selectively reply on a few things below, but it looks like this conversation can grow into many interesting topics.

Fantom is great because it is practice-oriented. Fantom is here just to “get our stuff done”. This is a motivation of the language creators, and this is a thing which attracted me to the language (I believe most of people here was attracted by practical aspects of Fantom). This practical orientation of the language is very attractive. We choose the language because we understand it’s benefits and we really need it — not because of popularity or PR. Honest, cool.

When engineers asking me “why do you use Fantom — this language is not popular and maybe never become popular”, I respond “I do not care, if there will be only hundred persons in the world using Fantom, that’s OK”. And this is true: fantom is a wonderful tool, and we’re all focused on our shit we’re doing with this tool.

It is normal if you have a perfect hammer and do not care if you do not see such a hammer in every store. You do not make efforts to visit every shop or scream on every square about how beautiful hammer you have. You just happy and do your stuff.

Fortunately (or not) @brian and @andy had a similar motivation: create a perfect hammer for own needs and get stuff done using it. That’s wonderful, and that’s attracted me and many other engineers.

That does not mean I do not care to tell people how Fantom is great, speaking about language features, or I do not want to contribute. I want to and I do, but again: I will not cry if Fantom will not spread the world.

Let’s fix that most of people here considering Fantom as a “Tool”, not as a “Product”. Of course a tool can be a product, but tool will become a product when critical mass of people will think about Fantom as a Product putting more efforts in productizing Fantom, which assumes “marketing” and other stuff.

From @rasa list:

Other popular JVM languages are supported by large companies/teams: Java->Oracle, Ceylon->RedHat, Kotlin->JetBrains, Groovy->GoPivotal i.e. VMware, Scala->École Polytechnique Fédérale de Lausanne.

Size of team is less relevant, but they think of their languages as a Products. Definitely Scala is a Product (due to natures of Universities), Ceylon looks more like a Product - I did not see and significant usage of it as a tool. Kotlin looks like shifting from Tool to Product.

Initially I was thinking JetBrains is following @brian and @andy and working on next language for themselves — just to deliver better IDEs faster, but recently I heard “they created Kotlin to sell more IDEs because of Kotlin” (which looks like bullshit, and I hope do not reflect reality). Anyway “marketing” Kotlin ahead of significant usage is a “product mode”. BTW Fantom was in the same Product mode before SkySpark.

Until now I was thinking of Fantom as tool is OK, but read @tomcl:

My concern about long-term Fantom is that it maybe is not exciting enough to attract enough of a user base. Now actually "not exciting" means "is a more capable gen purpose language". But I'm not sure that wins PR battles. And without user base it will die.

Two things, first Fantom is not involved in PR battles. Consider it fine-crafted exclusive hand-made thing. Why the hell it need to go into PR battles with mass-product? Key Fantom players (I mean @brian first of all) do not benefit from such PR (at least such benefits is not clear in short-middle terms). The same is true for other people who can contribute, like F4, frameworks, infrastructure, etc. But…

Second thing “And without user base it will die.” sounds dangerous. Is this true? Is everyone share such vision? If this is true, we have to change this. We need to change our vision on Fantom as a tool and start thinking of it as a Product.

I’m pretty sure @brian and SkyFoundry will be alive and OK if Fantom die — SkyFoundry is self-sufficient in this aspect. I was thinking the same way — if our business will significantly rely on Fantom and it will die — not a big deal, we’re fine to go as long as we need, since @brian and @andy already did tremendous job, so we can fix and improve things alone (yes, Fantom is very clear and perfectly designed).

But now I’m changing mind. Consider Gosu. Gosu reminds Fantom in some ways (as a language). But it was close-sourced internal Guidewire’s language from 2002, and open sourced in 2010. I believe they did benefit a lot from productive language before 2010, and heavily relied on it, but current situation is opposite.

It do not looks like open souring helped, because they lost a moment. Even in 2010 it was too late. They employ expensive engineers fixing language, libraries, working on IDE and tooling. And it looks like company backing Gosu is alone with their efforts.

Above sounds scaring, but I do not want to scare anybody, finally we’re all brave. But I tend to agree with @tomcl: if we see downtrend ecosystem grows — that sucks and we can end as Gosu, with a few teams using and evolve Fantom internally and as other languages evolve faster, people finally would like to switch to the new languages… Even for a brilliant team it would be hard to impossible to compete with vibrant ecosystem and collaborative innovation.

So I do agree it’s very important to work on language, PR, and ecosystem if we rely on a language and we want to succeed with Fantom long-term.

I’m very appreciate reply from @brian, and @brian message makes me happy and more confident. I’m very honest I do not see alternative to Fantom, the only concern is the language future and if we all will be able to add required critical mass to the ecosystem and help @brian and language to take off to the moon.

From Xored’s side I’m sure we’ll get back to F4 very soon. Once we re-start eating our own dogfood, F4 shall evolve fast. There are many things to implement besides improving quality and usability. We need good debugging, we want to develop native Java/JS classes, we want to import and fix existing libraries with once click, etc, etc. I think F4 gears will start rolling in near future.

And a few words to @SlimerDude: I’m supporting every line of your message, thank you Steve. Guys, thanks you again, and please sorry for long reply. I want to say more, and it’s a pleasure to hear and learn more from all of you.

Andrey.

brian Fri 12 Sep 2014

Hi Andrey,

Great comments. I agree Fantom is an elegant tool for getting shit done :)

There are pros and cons to how your market a programming language and build an ecosystem. Size of the ecosystem does bring with it a certain critical mass, but I don't think a smaller pool of high quality developers is such a bad thing - especially during the first decade of a language's existence. I think its more about the right people then the number of people.

And if anyone has tried to hack the compiler itself or any of the core libraries, I think you will find that Fantom is not some imposing mess of code that takes you years to figure out. Its pretty easy to become proficient in any of the subsystems.

Look forward to hearing more from you Andrey!

rasa Sun 14 Sep 2014

@andrey

Note that there is a fresh new Gosu plugin for IDEA 13, released at 24.07.2014. On the other side, creator of Fantom plugin for IDEA, @drorb, didn't posted at this forum since 2009. In fact, he made only a few posts at that year and then left this community. I've tried recently to run his plugin on IDEA v9 and didn't managed to use it for anything he declared in plugin specs. Now I'm scraping my head thinking that maybe its is due I used to ran IDEA on JRE 8 - the version of JRE that made me problem with F4 too.

You didn't answer what drives you away from Groovy/Grails?

If we take a look at the sites that compare JVM languages we'll see that Fantom is being recognized as a language with two main features: portability and elegance of core libraries. There's nothing to say about second claim but great. First claim is no more true. Fantom is portable only to JVM and JavaScript. C# is out of the game if I'm not wrong. E.g., Kotlin and Scala are portable to JVM and JS too, so portability is no more advantage of Fantom.

Despite what's being said about Fantom's pros/cons on the web, what attracted me to Fantom as a newbie are:

  1. literals for dates and URIs
  2. almost no generics
  3. simple collections
  4. speed compared to Java!!!
  5. elegant I/O
  6. Actors

2,3,4,5 were not explicitly mentioned at your home page!

What turns me off:

  1. low Java interoperability
  2. not so good IDE support
  3. lack of primitives
  4. too few examples, blogs etc. (newcomers prefer this kind of language introduction)

@brian

And if anyone has tried to hack the compiler itself or any of the core libraries, I think you will find that Fantom is not some imposing mess of code that takes you years to figure out.

I hope you don't expect raising user base to be consisted only of hackers?

ac413 Wed 15 Oct 2014

I agree with many of those suggestions. Due to the limits of technology, embedded systems have used only C for the past 30 years. But I really think embedded systems could be a huge future for Fantom, since embedded programming has finally caught up to the PC market price/hardware wise. The room is there for a more friendly language to replace C/C++ used in microwaves, TVs, and most importantly, the internet of things!

Arduino helped, but still only uses C and in a not very compatible way either. C# does have a few boards that run .net, "tessel.io" is another platform that runs Node.js, but they both cost 3 times the price of the competition! They also both use platform specific wiring, making them not very compatible with other boards.

"uJ", "Avian", and "NanoVM" are all shrunken virtual machines based on the JVM. This means it is already possible to run Java on an Arduino Mega clone board that cost only $15. Since Arduino is largely used by hobbyists and schools, it only makes sense to support a fresh, new, well-organized, language like Fantom, instead of a hacked, pretend version of C, that is called the Arduino IDE.

I really think it is time to take advantage of ARM Cortex M4 processors, as they run at 84MHz up to 180Mhz, and cost only $11 for a fully assembled board. This means one could use Fantom to create an open source Gameboy, a voice controlled robot, or a wifi enabled, home automation system. It is really an untapped opportunity in terms of what will be the new standard language for the internet of things. I vote for Fantom!

SlimerDude Mon 17 Nov 2014

Woah, Andrey! I think you've written more in this topic than I have in the entire Fantom forum! :D It's good to hear some Fantom enthusiasm coming through!

Some thoughts...

In terms of user base, yes, I would like to see Fantom become more popular. (If only so my friends stop picking on me!)

I like Fantom because I'm lazy. I can write less and achieve more...

Until that is, I need 3rd party interoperability. Be it for a database (e.g. Redis), monitoring tool (e.g. New Relic) or web framework (e.g. Web Sockets), there's just not a lot of dedicated Fantom pods / libraries out there.

And that must be a turn off for other lazy developers. For example, a new comer to Fantom with a requirement to link to a Cassandra database probably isn't going to use Fantom - because currently he also needs to write the Cassandra client.

Why the hell it need to go into PR battles with mass-product? Fantom players do not benefit from such PR.

The way I see it, PR brings users, and users (hopefully!) write pods and libraries to 3rd party clients... which means I don't have to!

So I do agree it’s very important to work on language, PR, and ecosystem if we rely on a language and we want to succeed with Fantom long-term.

There's been a lot of prior effort into the language which (to me) has stabilised quite nicely. The language still has room for improvement (which is why this forum exists!) but it'd be nice to work on the PR and ecosystem a bit more. Which is easier said than done!

As an aside, Android and embedded systems do seem to be a reoccurring theme, so it'd be nice to hear of some experimentation in those fields.

That's all from me for now!

Steve.

LightDye Tue 18 Nov 2014

Restart discussions on other language topics like generics, tuples, union types, pattern matching, etc.

Quite frequently when I present Fantom to fellow developers, they get disappointed by the lack of user generics. I know it has been discussed before and I know it is a complex change to they type system, but having generics can certainly attract more developers to Fantom.

Recently, I quickly re-looked at “alternatives”, which are progressing (Kotlin and Ceylon), but was not inspired with them.

I feel the same. When compared to Fantom, pretty much every other language's syntax looks dull to me, except maybe Apple's Swift.

"is a more capable gen purpose language". But I'm not sure that wins PR battles. And without user base it will die.

I don't know what PR battles are, but definitely agree on the other statement and that is actually my main concern about Fantom, more than user generics or any other language feature or its ecosystem.

Since mobile devices and apps are still enjoying a boom, being able to write mobile apps in Fantom, for both iOS and Android devices or at least one of the two, would definitely help growing its user base, I think.

The other thing that concerns me quite a lot is that there is little activity on this forum recently and the code/pods sharing seems to be stalled (except for your impressive set of libraries SlimerDude). I wish I could contribute pods as well but I lack the knowledge and capacity.

tomcl Tue 18 Nov 2014

I encourage students to use Fantom in projects. My experience:

Less experienced students find aspects of the language difficult. It is not that it is really difficult but has less copious tutorials at all levels than say Java.

More experienced students tend to have a favourite Java library and within the limited timescale of a project stick to Java to use this rather than trying to interoperate.

Fantom is nice: about as pleasant syntactically as python, but with the big advantage of static typing and stronger semantics. There are people who see static typing as unnecessary - not me. I want compilers to do as much work as possible. That is not an argument for Scala - types should make programming easier, and type complexity does not always do that.

I don't think adding extra features (generics etc) will necessarily make Fantom a lot more productive. But I guess they are needed to stop experienced programmers dismissing it. When once given a sweet - it is difficult for programmers to give it up.

I can't sell Fantom as a good language for concurrency even though it is that in situations (quite a lot) where an actor framework is appropriate. The problem is that "pure" actors, and the impure bits needed to make things work OK, are not easy to explain.

One way of looking at this is that for an experienced Fantom programmer the language is really very nice. Could be better, as always, but well engineered, highly productive and fun. It beats the other offerings. For a new programmer the language is not so intuitive - I found it easy because of a functional language background - but many do not have that. The material for new programmers is not as good as for other (less attractive but more popular) languages. Good IDEs (only really F4) are not easy to get sorted out initially, nor is getting started with them well documented across all versions and OSes.

SlimerDude Thu 20 Nov 2014

From Tomcl:

students have a favourite Java library and stick to Java to use this

I was in the same position when I first moved to Fantom - which is why I started writing my own! Which Java libraries do they use? Or rather, which libraries does Fantom still lack?

From LightDye:

I don't know what PR battles are

Public Relations (PR) - it's about publicising Fantom, getting it more well known.

writing mobile apps in Fantom, for iOS and Android devices would definitely help grow its user base

Yeah, I think so too. It just takes someone to have a serious bash to see where the pain points are.

I wish I could contribute pods but I lack the knowledge and capacity.

Capacity is always hard to find. Knowledge is something we all should be able to help with.

the code/pods sharing seems to be stalled (except for your impressive set of libraries SlimerDude)

Thanks! So, on the plus side there are some 80 odd libraries listed on the Status302 Repo including the 31 I advertise on Fantom-Factory. As far as building scalable (and traditional) web applications go, I think Fantom now has a good offering.

I take testing seriously too and was happy to see Fancordion listed on the official Concordion website. Wins like these maybe little, but they all help spread the word!

tomcl Mon 24 Nov 2014

From Tomcl:

students have a favourite Java library and stick to Java to use this

I was in the same position when I first moved to Fantom - which is why I started writing my own! Which Java libraries do they use? Or rather, which libraries does Fantom still lack?

javafx.animation - specifically javafx.animation.timeline

keilw Tue 25 Nov 2014

Well first of all Fantom avoided some of the mistakes of Java by sticking to just ONE Duration type (while Java 8 now has 2 and 2 other Date/Time APIs types ;-O) and it got excellent language level support for Units, too.

Some of the new JSRs like 354 (Money) or 363 (successor to 275 which obviously inspired Fantom a lot being created by a former EG member;-) ) couldn't hurt. In many cases Fantom should be able to use them, but in some native support might be worth a shot.

Login or Signup to reply.