Update: For the last few months, Asana has moved from
The two main things that were slowing down our development:
too much remaining research-level work to make the compiler
output more performant code
lack of tool support
We're *not* a framework company, so we didn't want to devote
years to this work at the expense of building our product. We're
still using the framework primitives we developed for the
language -- most importantly, systems for reactively recomputing
our UI and synchronizing changes with the server -- we're just no
longer using the slightly nicer syntax (and functional style)
that Lunascript provided.
Long term, we may revive the Lunascript compiler. We think this
may be especially appealing once we shift from focusing Asana as
a single product to Asana as a platform. But for the immediate
future, we're focused on releasing our first product at the
expense of continuing work on Lunascript proper.
My self have started a couple of these overambitious projects, without realizing the amount of work it takes to get something in production level. Sure you can cover the base functionality pretty quickly, but it is the edge cases and polishing and making a robust solution that actually take the most time.
Sometimes these over-ambitious projects, succeed (Linux is the prime example), but usually they do because there is a huge need in the market for such product.
Perhaps Lunascript is something more 'interesting in paper, but not that great in practice'.
It's tempting to replace your language entirely and compile down to something else, but IMHO this sort of thing shows that's a very dangerous play that generally succeeds big or fails big, usually the latter. Incremental expansion of an existing language, even with something as powerful as a syntax preprocessor (that ideally compiles to results that are themselves manipulable language constructs like closures or simple values passed in an idiomatic way), is generally the way to go; most of the win, hardly any of the risk. Something like StratifiedJS or something, if I understand it properly, adding meaningful additional syntax without trying to be its own independent language: http://onilabs.com/stratifiedjs Or, from the sounds of it, the way this language ultimately went.
Linux was not that ambitious to start with. That's why it succeeded: while everyone else was waiting for Hurd or AT&T-free BSD, Linux was rapidly gaining momentum.
Reactive / dataflow languages are just perfect for UI binding, and in data-intensive applications (think things like insurance quotes, finance) they can minimize the amount of kludgy UI update logic. The language I wrote was called Gravity (because it kept on sucking in responsibility), and compiled to .NET, which was very easy because it could just use Reflection.Emit and DynamicMethod.
With an in-process debugger I wrote, and the state storage mechanism it used (a bit like a Smalltalk image but with the code referred to via an intranet http URL, so it was really small, less than 60K usually), it had other powerful features, like migrating an app session from one machine to another (think of a helpdesk investigating a problem), playback of the entire application session (for testing or fault reproduction), or post-mortem investigation of the heap.
These kinds of features are very hard to get if you just take what a host language gives you and try and build a DSL on top of it. I understand why many people shy away from it, but the productivity advantages can be substantial, sustainable and strategic. The grammar and semantics of the Gravity language I developed for this were very similar to a subset of C#, except with more SQL-like null handling. That can minimize the learning and unfamiliarity overhead without losing a lot of that advantage. If I were doing a startup today, and it involved the same kinds of challenges, I'd still take a similar approach - and as a compiler engineer in my day job, I don't have illusions as to the depth of the technical problems around production-ready languages and tooling.