On Mon, Jul 12, 2010 at 6:41 PM, Dibyendu Majumdar <[email protected]> wrote: > Hi, > > I am thinking of creating a Google Go type language which can run on > the JVM. The goal is to keep to the features supported efficiently in > Java but (taking inspiration from Go), reduce the verbosity in the > language, and perhaps add some concurrency features to the language. > > The key ideas that I would like to implement in the new language are: > - static type inference (I am aware of the arguments for/against but > on balance prefer to support this, while allowing explicit type > declarations where needed). > - channels - add syntactic support for creating either a synchronous > or buffered queue (using standard Java concurrency library) > - maps - syntactic support for hash maps > - tasks - syntactic support for submitting tasks to a thread pool - > using the concurrency library > - convention over boilerplate - like Go, if an identifier starts with > a capital, make it automatically public, else private, and use similar > techniques to reduce boilerplate stuff > - static methods should not have to be declared in a class - to > automatically create a default class per package to hold static > methods - there may be better ways of doing this though. > > Features that I am not planning to implement: > - Go interfaces > - Ability to select on channels > - Or any thing else that does not map directly to a feature in Java.
I like your list. I'd also love to see a Go for JVM that doesn't introduce a giant runtime library, if possible. There are too many JVM languages that bring along all their baggage and their implementers' choices about what libraries to use (and what libraries in the JDK don't pass muster). I started the Mirah language to scratch that itch of a clean, feature-rich, type-inferred language that I could run anywhere without any library dependencies to cope with. The last bullet you provide is perhaps the most important, and represents the guiding principle of Mirah. Perhaps there's some synergy to be had? Common codebases to be shared? I'm guessing the large part of what you want to do will be compiler/language-related with potential for very limited runtime library dependencies. A first simple step might be to take the Go syntax and see how much you can map to Java directly. Direct memory access (which I believe is still in there, right?) might be tough, but the basic constructs of the language may map well. Have you started any exploration yet? - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
