The Go Future

Since my focus over the last 30+ years of developing and managing software solutions has been centered on small enterprise oriented teams (1-10 non-genius developers).  To maximize the productivity of these small teams, it is highly beneficial to limit the needed areas of expertise and ensure that any area of expertise has more than one expert (and hence lower the risk of loss of critical team members).  In this Web world, HTML(5) & CSS are a given, as is SQL (and possibly some No SQL solutions), but to support Web 2.0, iOS, Android, and WinMobile7+ apps natively, the team needs to maintain expertise in: Java, JavaScript, Objective C, C# and a bunch of libraries in each language.

Ericsson, Gladwell, and others are promoting the "10000 hours to expertise" theory.  I personally probably have 10000 hours developing Java since I have been using it non-stop for development for the last 16 years, but true Java mastery requires mastery over the ever changing landscape of the 3rd party libraries, so I don't feel like an expert.  I also have about 5000 hours working w/ GWT and have been hired as a GWT "expert", yet I am still learning from other's code each time I see some.  All of this is my basis for stating that:

    Maintaining expertise across 4 languages and their libraries with
    redundancy with anything less than 12 developers is probably not
    possible from a practical (hiring an initial 8 experts and financial)
    perspective.

One of my favorite managers had a saying:

    There are sometimes technical solutions for management problems, and
    there are always management solutions for technical problems, but
    given the choice always go with the technical solution, because
    people are much harder to change!

I bring this up, because I don't think there is a small team management solution that requires 4 language expertise.  IMO, the only solution is a technical one of a single language.  For a single language solution to be viable, the developer community has to believe the language is either way "cool" or is the "future" as the "Next Big Language (NBL)", so that they are motivated to learn it.

Right now, with: GWT, mGWT, GWT-PhoneGap, PhoneGap, and the Java eco system; IMO, Java is the best choice.  But Java is, and probably never was, "cool" (it was approachable, due to its GC, and held out the promise of "write once, run everywhere").

Which brings us to the characteristics of the "Next Big Language (NBL)".  I'll start with Steve Yegge's 2007 NBL blog posting:

    Rule #1: C-like syntax

    Rule #2: Dynamic typing with optional static types.

    Rule #3: Performance

    Rule #4: Tools (IDEs)

    Rule #5: Kitchen Sink:
        1. Object-literal syntax for arrays and hashes
        2. Array slicing and other intelligent collection operators
        3. Perl 5 compatible regular expression literals
        4. Destructuring bind (e.g. x, y = returnTwoValues())
        5. Function literals and first-class, non-broken closures
        6. Standard OOP with classes, instances, interfaces, polymorphism, etc.
        7. Visibility quantifiers (public/private/protected)
        8. Iterators and generators
        9. List comprehensions
       10. Namespaces and packages
       11. Cross-platform GUI
       12. Operator overloading
       13. Keyword and rest parameters
       14. First-class parser and AST support
       15. Static typing and duck typing
       16. Type expressions and statically checkable semantics
       17. Solid string and collection libraries
       18. Strings and streams act like collections

    Rule #6: Multi-Platform

Now http://www.bluwiki.com/go/Nbl adds the following to Rule #5:

       19. Garbage Collected
       20. Continuations, call/cc
       21. Hygienic Macros
       22. Threading

While I don't fully agree with #2 or all of #5, I would add / change the following:

    Rule #6: Multi-Platform - Not just JVM, & .Net's CLR, but native Windows, OSX, Linux, and
                support (possibly non-native) for iOS, Android, WinMobile7+ and JavaScript! 

        #5, 19: Garbage Collected elevated to #7 as:
    
    Rule #7: Automatic memory management (options for both automatic reference
                counting and a mark and sweep generational garbage collector).

    Rule #8: Built in Immutability support w/ serialization
    
    Rule #9: CSP only style threading.


The keys to successful adoption of the NBL, is a mix of:

    1) Easy adoption thru existing code integration (JVM, CLR, and JavaScript support)
    2) The promise of easy non-VM deployments, and
    3) The promise of a single language (mostly *1*) for:
        a) Rich Desktop App (*1*)
        b) Rich Web App (Web 2.0)
        c) Headless Server Apps
        d) iOS Apps (*1*)
        e) Android Apps (*1*)
        f) WinMobile7+ Apps (*1*)

*1* - The ability of Native-Browser Hybrid apps (such as PhoneGap or an embedded browser on the desktop e.g. embedded IE or better still: Chromium Embedded Framework - CEF) allow for a minimum of platform dependent language/coding.

IMO, there are currently only three languages that meet enough of the criteria listed above to possibly be the NBL:

    1) Fantom - http://fantom.org/
        While it already targets the JVM, CLR, and JavaScript and supports
        Immutability & CSP, it does not have a large company pushing it and
        eating its own dog food!

    2) Dart- http://dartlang.org/
        Dart at first glace looks like a strong contender, but the initial
        marketing/promotion that targeted (the relatively common cross
        browser JavaScript) and the immediate disadvantage it would place
        Microsoft's Internet Explorer left Dart in a bad PR space.  This bad
        PR and the fact that it does not interoperate with the JVM or address
        the real current problem of the "Mobile Platform Profusion" means it
        has a real up-hill battle in becoming the NBL!

    3) Go - http://golang.org/
        Go is "cool", it was designed to produce native code while supporting
        multiple targets, and its threading/concurrency model is inherently
        CSP.  It is open source, yet backed by Google, and Google is using it,
        eating its own dog food!  While its syntax is a little alien to C/Java
        developers it does not feel immediately alien, and the underlying
        concepts provide incredible power (two of my favorites are
        Duck Typing, "perspective" method binding to types).

If there is any chance of Go becoming the Next Big Language (NBL) it has to provide both a clear technical advantage and be relatively easy to adopt slowly.

IMO, to accomplish the "successful adoption ... mix", eventually Go will need:

    1) JVM target.
    2) CLR target.
    3) Android (Dalvik?) target.
    4) iOS target.
    5) WinMobile7+ (CLR?) target.
    6) GWT/JavaScript target/integration.
    7) IDE support (both Eclipse and IDEA).
    8) Chromium Embedded Framework - CEF bindings.
    9) Enterprise centric libraries, specifically something like ODBC/JDBC and Message Queues.

I propose that these needs be provided in phases:

    Phase 1:
    
        a) JVM target w/ ability to call Java code painlessly so that
            existing Java code bases (or any JVM language that conforms
            to Java's calling objects and conventions) can be fronted by Go.
        b) GWT/JavaScript target/integration for Go in the browsers
            to provide a Go UI in Web 2.0 world.
        c) PhoneGap bridge, something like "gwt-phonegap" and "mgwt" to
            support disconnected Hybrid Mobile Apps.
        d) IDE support (both Eclipse and IDEA) for all the above.
        
        ** At the end of Phase 1, for many development efforts, in addition
            to HTML5, CSS, and SQL (or noSQL), expertise is needed in Go and Java.
            

    Phase 2:
    
        a) Enterprise centric libraries, specifically something like
            ODBC/JDBC and Message Queues to allow for the elimination
            if the use of the JVM target for green field development.
        b) Chromium Embedded Framework - CEF bindings, to provide
            simple limited native support for Rich Desktop Apps
            (utilizing a PhoneGap like plug-in model communicating
            over browser-native asynchronous textual communication
            channel).

        ** At the end of Phase 2, for nearly all development efforts
            (all those not needing additional native support for either
            the mobile or desktop environments), only expertise in
            HTML5, CSS, SQL, and Go would be needed.
            

    Phase 3:
    
        a) CLR target w/ ability to call .Net code painlessly so that
            existing C# code bases (or any CLR language that conforms
            to C#'s calling objects and conventions) can be fronted by Go.
        b) Native Android support (*3*).
        c) Native iOS support (*3).
        d) Native WinMobile7+ support (*3*).

        ** At the end of Phase 3, IMO, any development efforts would only
            need expertise in a sub-set of: HTML5, CSS, SQL, and Go!
    
        *3* - This code would consist of three primary areas:
            1) Native GUI Widget interfaces (similar to SWT).
            2) GUI abstraction layer that is the LCD across all
                three platforms utilizing interfaces implemented
                in "1) Native GUI Widget interfaces".
            3) A navigational layer to allow for coding a common
                navigational model along the lines of GWT's MVP
                with page tokens.