FAQ
I'm going to assume that main() in go modules is treated specially and is
not a conventional function. If you know for sure that I'm mistaken, then
the remainder of this note is not worth reading and you're welcome to
disillusion me immediately.

If main() is treated specially, whether by the runtime or the compiler,
then I'd like to suggest that we drop its syntax altogether and replace it
with the simpler:

{
...
}

form, where "func main()" is simply discarded. Not only, but I also
suggest that we can have as many of these in one or more "main" modules as
we want to run concurrently and that the Go environment be altered to treat
each as a top-level goroutine.

I appreciate this is a Go-2 type of suggestion and I'm more curious about
its viability than to actually see it implemented. I do think that the
traditional idea of a main() function, however, is an anachronism in Go and
seeing it dropped would appeal to my sense of aesthetics.

Lucio.

--

Search Discussions

  • David Symonds at Nov 29, 2012 at 6:54 am
    main is just a regular function. The only specialness is that the
    linker will arrange for the main function of the "main package" to be
    invoked to start the program. You can have a main function in any of
    your packages, and even multiple packages that declare themselves to
    be "package main".


    Dave.

    --
  • Lucio at Nov 29, 2012 at 7:03 am
    Hm, I need to phrase things more carefully...

    What I'm thinking is that one cannot extend the concept of goroutines to
    the outermost level because of the inherited C syntax for a main()
    function. If we toss that idea and adopt a simpler syntax, we can presume
    that the presence of multiple functions at the outer level are intended to
    execute concurrently.

    The similarity between inner functions and main() is actually me putting a
    red-herring in my own path.

    Lucio.
    On Thursday, 29 November 2012 08:54:43 UTC+2, David Symonds wrote:

    main is just a regular function. The only specialness is that the
    linker will arrange for the main function of the "main package" to be
    invoked to start the program. You can have a main function in any of
    your packages, and even multiple packages that declare themselves to
    be "package main".


    Dave.
    --
  • Yy at Nov 29, 2012 at 9:41 am

    On 29 November 2012 08:03, Lucio wrote:

    What I'm thinking is that one cannot extend the concept of goroutines to
    the outermost level because of the inherited C syntax for a main()
    function. If we toss that idea and adopt a simpler syntax, we can presume
    that the presence of multiple functions at the outer level are intended to
    execute concurrently.

    I don't see any problem with launching goroutines from the main function.
    It makes easier to understand the program logic. But if the intention is to
    launch goroutines from the outermost level I would use the syntax we
    already have instead of adding a new case for braces (which would not be
    the most searchable characters). ie. I would simply allow to use the go
    statement there.

    Then, you would be able to define your functions and then launch all of
    them in consecutive statements, or you could use a single go func(){...} if
    you only want one "main function".


    --
    - yiyus || JGL .

    --
  • Roger peppe at Nov 29, 2012 at 10:07 am

    On 29 November 2012 06:54, David Symonds wrote:
    main is just a regular function. The only specialness is that the
    linker will arrange for the main function of the "main package" to be
    invoked to start the program. You can have a main function in any of
    your packages, and even multiple packages that declare themselves to
    be "package main".
    you can also have code that calls it: http://play.golang.org/p/G85PA0S1e4

    automatically running several mains concurrently would not
    be a good idea - main is often used to set up global variables.
    for instance, the flag package would be totally broken in
    this circumstance.

    --
  • Jan Mercl at Nov 29, 2012 at 7:10 am

    On Thu, Nov 29, 2012 at 7:50 AM, Lucio wrote:
    If main() is treated specially, whether by the runtime or the compiler, then
    I'd like to suggest that we drop its syntax altogether and replace it with
    the simpler:

    {
    ...
    }
    It's a bit simpler typographically, but IMO makes for unnecessarily
    added cognitive load.
    form, where "func main()" is simply discarded. Not only, but I also suggest
    that we can have as many of these in one or more "main" modules as we want
    to run concurrently and that the Go environment be altered to treat each as
    a top-level goroutine.
    With such setup the program initialization order is no more derivable.
    I appreciate this is a Go-2 type of suggestion and I'm more curious about
    its viability than to actually see it implemented. I do think that the
    traditional idea of a main() function, however, is an anachronism in Go and
    seeing it dropped would appeal to my sense of aesthetics.
    `main()` is IMO not an anachronism but a necessity.

    -j

    --
  • Lucio at Nov 29, 2012 at 7:12 am
    I may sound unnecessarily confrontational, but that's not the idea: (a) the
    simpler syntax will take a little getting used to, I don't think anyone
    will find it confusing - it is a judgement call; (b) I presume that the
    initialisation order would intentionally not be deterministic in the use of
    my suggestion, in a sense I think that's an advantage as one can force a
    sequence if necessary; (c) in my understanding of Go, init() is the
    necessary function, not main().

    Lucio.
    On Thursday, 29 November 2012 09:04:42 UTC+2, Jan Mercl wrote:

    On Thu, Nov 29, 2012 at 7:50 AM, Lucio <lucio...@gmail.com <javascript:>>
    wrote:
    If main() is treated specially, whether by the runtime or the compiler, then
    I'd like to suggest that we drop its syntax altogether and replace it with
    the simpler:

    {
    ...
    }
    It's a bit simpler typographically, but IMO makes for unnecessarily
    added cognitive load.
    form, where "func main()" is simply discarded. Not only, but I also suggest
    that we can have as many of these in one or more "main" modules as we want
    to run concurrently and that the Go environment be altered to treat each as
    a top-level goroutine.
    With such setup the program initialization order is no more derivable.
    I appreciate this is a Go-2 type of suggestion and I'm more curious about
    its viability than to actually see it implemented. I do think that the
    traditional idea of a main() function, however, is an anachronism in Go and
    seeing it dropped would appeal to my sense of aesthetics.
    `main()` is IMO not an anachronism but a necessity.

    -j
    --
  • Miguel Pignatelli at Nov 29, 2012 at 10:02 am
    How would you communicate between the different "top-level" goroutines?

    M;

    On 29/11/12 07:12, Lucio wrote:
    I may sound unnecessarily confrontational, but that's not the idea: (a)
    the simpler syntax will take a little getting used to, I don't think
    anyone will find it confusing - it is a judgement call; (b) I presume
    that the initialisation order would intentionally not be deterministic
    in the use of my suggestion, in a sense I think that's an advantage as
    one can force a sequence if necessary; (c) in my understanding of Go,
    init() is the necessary function, not main().

    Lucio.

    On Thursday, 29 November 2012 09:04:42 UTC+2, Jan Mercl wrote:

    On Thu, Nov 29, 2012 at 7:50 AM, Lucio <lucio...@gmail.com
    <javascript:>> wrote:
    If main() is treated specially, whether by the runtime or the
    compiler, then
    I'd like to suggest that we drop its syntax altogether and
    replace it with
    the simpler:

    {
    ...
    }
    It's a bit simpler typographically, but IMO makes for unnecessarily
    added cognitive load.
    form, where "func main()" is simply discarded. Not only, but I
    also suggest
    that we can have as many of these in one or more "main" modules
    as we want
    to run concurrently and that the Go environment be altered to
    treat each as
    a top-level goroutine.
    With such setup the program initialization order is no more derivable.
    I appreciate this is a Go-2 type of suggestion and I'm more
    curious about
    its viability than to actually see it implemented. I do think that the
    traditional idea of a main() function, however, is an anachronism in Go and
    seeing it dropped would appeal to my sense of aesthetics.
    `main()` is IMO not an anachronism but a necessity.

    -j

    --
    --
  • Lucio at Nov 29, 2012 at 10:12 am
    Unless I'm being an idiot (don't be afraid of calling me one), I'd say
    through global variables. Init() is still there to prepare the ground
    where necessary.

    Lucio.
    On Thursday, 29 November 2012 12:02:24 UTC+2, emepyc wrote:

    How would you communicate between the different "top-level" goroutines?

    --
  • Peter at Nov 29, 2012 at 12:03 pm
    I think you're trying to remove too much syntax from go, and it will result
    in confusion.

    Simply searching for init() will tell you everything that's set up in a
    package. If that involves several go routines then they'll be listed there,
    for inspection.
    Contrast to the case where braces without "func" are littered around the
    package. Sure, you could grep for "^{", but you'd *also* have to search for
    init().

    Similarly, main() is usually a good place to get an overview of what's
    going on. Not having any distinction between purely background tasks and
    the *main* entry point just seems annoying.
    If your program genuinely involved (say) 3 concurrent, equally important
    tasks, then having "func main(){ go f1(); go f2(); go f3(); }" seems a good
    way of communicating that to the reader.

    On the whole, although your idea edges towards making things more regular
    and general, I fear that it would allow unnecessarily confusing programs to
    be written.
    On Thursday, 29 November 2012 10:12:25 UTC, Lucio wrote:

    Unless I'm being an idiot (don't be afraid of calling me one), I'd say
    through global variables. Init() is still there to prepare the ground
    where necessary.

    Lucio.
    On Thursday, 29 November 2012 12:02:24 UTC+2, emepyc wrote:

    How would you communicate between the different "top-level" goroutines?
    --
  • Lucio De Re at Nov 29, 2012 at 12:09 pm
    I was onlt suggesting that the string "func main()" be dropped, not
    the "func" keyword. I'm sorry if I created confusion.

    Lucio.
    On 11/29/12, Peter wrote:
    I think you're trying to remove too much syntax from go, and it will result

    in confusion.

    Simply searching for init() will tell you everything that's set up in a
    package. If that involves several go routines then they'll be listed there,

    for inspection.
    Contrast to the case where braces without "func" are littered around the
    package. Sure, you could grep for "^{", but you'd *also* have to search for

    init().

    Similarly, main() is usually a good place to get an overview of what's
    going on. Not having any distinction between purely background tasks and
    the *main* entry point just seems annoying.
    If your program genuinely involved (say) 3 concurrent, equally important
    tasks, then having "func main(){ go f1(); go f2(); go f3(); }" seems a good

    way of communicating that to the reader.

    On the whole, although your idea edges towards making things more regular
    and general, I fear that it would allow unnecessarily confusing programs to

    be written.
    On Thursday, 29 November 2012 10:12:25 UTC, Lucio wrote:

    Unless I'm being an idiot (don't be afraid of calling me one), I'd say
    through global variables. Init() is still there to prepare the ground
    where necessary.

    Lucio.
    On Thursday, 29 November 2012 12:02:24 UTC+2, emepyc wrote:

    How would you communicate between the different "top-level" goroutines?
    --
  • Minux at Nov 29, 2012 at 1:43 pm

    On Thu, Nov 29, 2012 at 8:08 PM, Lucio De Re wrote:

    I was onlt suggesting that the string "func main()" be dropped, not
    the "func" keyword. I'm sorry if I created confusion.
    Another problem:

    this is possible to import a package called "main", and in that case, the
    user will
    know that func main() in the imported package won't execute, however, if
    it's written
    as you suggested, the user might think it's also executed (because it is a
    special
    case, not a normal func happen to be called "main").

    --
  • Lucio De Re at Nov 29, 2012 at 2:58 pm
    I don't think I like the original idea of bypassing main in an
    imported package; I didn't think about it, but I ee how it would make
    sense and be useful, but it is odd. I actually prefer the alternative,
    where main() is never executed without it being invoked, no matter
    where it occurs :-)

    Purely at a theoretical level, I think main cannot be both a special
    and a normal case. Dropping the identifier highlights the
    inconsistency.

    I mentioned that I thought all {} functions might want to be top-level
    goroutines, no matter which package they appear in. I don't know that
    to be useful, but I like to think that it's consistent and
    predictable.

    You can still have as many "func main()" declarations as you like and
    their behaviour will be consistent with "main" having no special
    properties.

    Lucio.

    --
  • Bryanturley at Nov 29, 2012 at 4:13 pm
    Initialization at the lowest level has to be serial for sanity.
    It is a chicken/egg problem, that is why there is one main.

    --
  • Kevin Gillette at Nov 29, 2012 at 6:06 pm
    http://play.golang.org/p/7EDc3OvAm3

    As mentioned, main is callable. func main of the main package is an entry
    point to the program in the post-init phase, but is otherwise not "special".

    If discarding the func syntax as you propose is to have merit when combined
    with your proposal of any number of main funcs, then it should have merit
    if it were applied to the plethora of identically-named functions we
    already have: init functions. To measure the merit of the idea, in my eyes,
    requires two criteria: 1) does it save enough code to be worth
    deregularizing the syntax? Another way of measuring this: have there been
    (m)any complaints about all the "boiler plate" that people have to write
    for init functions? 2) if #1 isn't a *resounding* 'yes', then does
    discarding the syntax actually improve code comprehension? (can the average
    programmer, especially those new to Go, understand that that package-level
    anonymous block is actually a function, and is special nature and behavior
    of that function implied by the syntax?)

    If #1 isn't overwhelmingly 'yes', or #2 isn't at least 'yes' on all points,
    then I don't think the discarded syntax proposal has much merit. If the
    co-proposal for any number of "concurrent mains" isn't accepted, then I
    don't think there's enough justification in the world to remove what
    amounts to _exactly_ 12 bytes per program of boiler plate code.

    Regarding concurrent mains: if other packages besides main are allowed to
    have main funcs, it will essentially be like the init phase behaved in r60:
    goroutines launched during init would not be run until the init phase was
    over -- main funcs would be like these delayed goroutines. Aside from that,
    many existing projects wanting to take advantage of such a feature (in lieu
    of starting a constant number of goroutines from within a go1 main func)
    will start moving a bit of the code from main() into an init function that
    otherwise would not have existed (making the proposed syntax savings
    somewhat moot). init functions are run serially, and before main, and the
    main package's init function(s) are guaranteed to run after all other
    package's init functions (because nothing can depend on package main), and
    so init will essentially become the new "main" for these apps, since they
    will likely still need some kind of synchronization around parsing program
    args and whatnot. Afaict, init functions in package main in go1 only serve
    an organizational purpose -- unlike in other libraries, they do not do
    anything that the app programmer can't put in package main. I imagine that
    the majority of apps intending to use multiple mains will need to add an
    init function, or use some other kind of synchronization (like sync.Once),
    since control over concurrency (in exchange for some convenience) will be
    pulled out from under them.
    On Thursday, November 29, 2012 7:50:25 AM UTC-7, Lucio wrote:

    I don't think I like the original idea of bypassing main in an
    imported package; I didn't think about it, but I ee how it would make
    sense and be useful, but it is odd. I actually prefer the alternative,
    where main() is never executed without it being invoked, no matter
    where it occurs :-)

    Purely at a theoretical level, I think main cannot be both a special
    and a normal case. Dropping the identifier highlights the
    inconsistency.

    I mentioned that I thought all {} functions might want to be top-level
    goroutines, no matter which package they appear in. I don't know that
    to be useful, but I like to think that it's consistent and
    predictable.

    You can still have as many "func main()" declarations as you like and
    their behaviour will be consistent with "main" having no special
    properties.

    Lucio.
    --
  • Kevin Gillette at Nov 29, 2012 at 6:59 pm
    Also, if you drop the func syntax for main, the question would arise: why
    not drop all other "superfluous syntax"?

    func x() string { return "yes" } // why have empty parentheses for an
    empty param list? why have the func keyword when not defining anonymous
    functions? why have braces if the func only has one statement? ditto with
    most control structures.

    y := x() // why have empty parentheses when passing zero args?

    (obviously, since functions are first class values, parentheses-lacking
    function calls would make function-value-assignment ambiguous)

    var a int = 5 // why have the var keyword?
    b := 6 // why have the colon?

    Before long, you realize the language is becoming perl. Go emphasizes the
    readability of code above many other concerns, which is why the language
    has a lot of syntactical consistency at the expense of single-digit
    keystroke savings at various places that other languages would have readily
    allowed for.

    --
  • Rémy Oudompheng at Nov 29, 2012 at 7:22 am

    On 2012/11/29 Lucio write:
    I'm going to assume that main() in go modules is treated specially and is
    not a conventional function. If you know for sure that I'm mistaken, then
    the remainder of this note is not worth reading and you're welcome to
    disillusion me immediately.

    If main() is treated specially, whether by the runtime or the compiler, then
    I'd like to suggest that we drop its syntax altogether and replace it with
    the simpler:

    {
    ...
    }

    form, where "func main()" is simply discarded. Not only, but I also suggest
    that we can have as many of these in one or more "main" modules as we want
    to run concurrently and that the Go environment be altered to treat each as
    a top-level goroutine.
    Your syntax suggestion suggests that the code in the braces executes
    before init() but means exactly the contrary, and looks really
    confusing to me. Also, what if someone says:

    {
    a, b := 1, 1
    {
    println(a)
    }
    {
    println(b)
    }
    }

    Is that three goroutines?

    Launching goroutines in the desired packages looks more explicit.

    Rémy.

    --
  • Lucio at Nov 29, 2012 at 8:49 am
    We probably have covered the interesting bits of the conversation, but your
    questions are irresistible :-)

    I always assumed that func main() {} would be invoked after all init()s
    have completed. I intended for {} (or {}...{}) to do likewise.

    And I intended for {} to be permitted only at the outermost level. Your
    example would be rejected.

    Lucio.

    On Thursday, 29 November 2012 09:22:36 UTC+2, Rémy Oudompheng wrote:

    On 2012/11/29 Lucio <lucio...@gmail.com <javascript:>> write:
    I'm going to assume that main() in go modules is treated specially and is
    not a conventional function. If you know for sure that I'm mistaken, then
    the remainder of this note is not worth reading and you're welcome to
    disillusion me immediately.

    If main() is treated specially, whether by the runtime or the compiler, then
    I'd like to suggest that we drop its syntax altogether and replace it with
    the simpler:

    {
    ...
    }

    form, where "func main()" is simply discarded. Not only, but I also suggest
    that we can have as many of these in one or more "main" modules as we want
    to run concurrently and that the Go environment be altered to treat each as
    a top-level goroutine.
    Your syntax suggestion suggests that the code in the braces executes
    before init() but means exactly the contrary, and looks really
    confusing to me. Also, what if someone says:

    {
    a, b := 1, 1
    {
    println(a)
    }
    {
    println(b)
    }
    }

    Is that three goroutines?

    Launching goroutines in the desired packages looks more explicit.

    Rémy.
    --
  • Minux at Nov 29, 2012 at 9:04 am

    On Thu, Nov 29, 2012 at 2:50 PM, Lucio wrote:

    I'm going to assume that main() in go modules is treated specially and is
    not a conventional function. If you know for sure that I'm mistaken, then
    the remainder of this note is not worth reading and you're welcome to
    disillusion me immediately.

    If main() is treated specially, whether by the runtime or the compiler,
    then I'd like to suggest that we drop its syntax altogether and replace it
    with the simpler:

    {
    ...
    }

    form, where "func main()" is simply discarded. Not only, but I also
    suggest that we can have as many of these in one or more "main" modules as
    we want to run concurrently and that the Go environment be altered to treat
    each as a top-level goroutine.
    Why not just start goroutines from init() if you multiple top-level
    goroutines?
    (I'm not sure what you mean by top-level goroutine, does it mean that if
    any of them ends, the whole program terminates?)

    --
  • Lucio at Nov 29, 2012 at 10:18 am

    (I'm not sure what you mean by top-level goroutine, does
    it mean that if any of them ends, the whole program terminates?)
    I'm OK with a majority opinion, my own is that the last one to exit
    terminates the program.

    Much as I see some resistance to the {} syntax, it is merely the deletion
    of the noise words "func main()" from the existing syntax. As for search,
    gofmt could be trusted to put the opening and closing brace at the
    beginning of a line, and even the entire "function" at the end of the
    module, so that's a bit of a straw man.

    I started with just dropping the noise words and then the obviousness that
    a single main() is an artificial limitation struck me. From there, to
    figuring out that multiple outer-level functions ought to be concurrent
    didn't take long.

    Are we bikeshedding, or just getting repetitive?

    Lucio.

    --
  • Filip Zaludek at Nov 29, 2012 at 12:09 pm
    "func main()" is not noise, because you can call main() recursivelly.

    -f

    --
  • Carlos Castillo at Nov 30, 2012 at 1:33 am
    "func main()" also lets you search (or grep) for your program's entry
    point, whereas finding an open brace does not.
    On Thursday, November 29, 2012 2:25:27 AM UTC-8, Filip Zaludek wrote:


    "func main()" is not noise, because you can call main() recursivelly.

    -f
    --
  • Minux at Nov 30, 2012 at 7:16 pm

    On Friday, November 30, 2012, Carlos Castillo wrote:

    "func main()" also lets you search (or grep) for your program's entry
    point, whereas finding an open brace does not.
    you can grep for '^{', so this is not a problem as it seems.

    --
  • Kyle Lemons at Nov 30, 2012 at 8:24 pm
    unless someone does
    /* main */ {

    ;-)

    On Fri, Nov 30, 2012 at 2:16 PM, minux wrote:

    On Friday, November 30, 2012, Carlos Castillo wrote:

    "func main()" also lets you search (or grep) for your program's entry
    point, whereas finding an open brace does not.
    you can grep for '^{', so this is not a problem as it seems.

    --

    --
  • Rui Maciel at Nov 29, 2012 at 12:43 pm

    On 11/29/2012 06:50 AM, Lucio wrote:
    If main() is treated specially, whether by the runtime or the compiler,
    then I'd like to suggest that we drop its syntax altogether and replace it
    with the simpler:

    {
    ...
    }

    form, where "func main()" is simply discarded.
    This makes the code needlessly unreadable.

    Not only, but I also
    suggest that we can have as many of these in one or more "main" modules as
    we want to run concurrently and that the Go environment be altered to treat
    each as a top-level goroutine.
    This would worsen the readability problem even further, and in multiple
    aspects.

    The main function is unambiguous, and it's quite clear and straight
    forward, as is running a bunch of go statements within the main
    function. What problem do you believe would solve by implementing this
    change in order to justify this level of obfuscation?


    Rui Maciel

    --
  • Kyle Lemons at Nov 29, 2012 at 4:20 pm

    On Wed, Nov 28, 2012 at 10:50 PM, Lucio wrote:

    I'm going to assume that main() in go modules is treated specially and is
    not a conventional function. If you know for sure that I'm mistaken, then
    the remainder of this note is not worth reading and you're welcome to
    disillusion me immediately.

    I won't say that main is treated specially, because it is by the linker,
    but it is not treated specially as a function. For instance, you are
    perfectly allowed to import a main package from somewhere else and call its
    main() function, and in fact I have seen this done by tests in order to
    simulate stdin -to- stdout interaction for an interactive binary.

    If main() is treated specially, whether by the runtime or the compiler,
    then I'd like to suggest that we drop its syntax altogether and replace it
    with the simpler:

    {
    ...
    }

    form, where "func main()" is simply discarded. Not only, but I also
    suggest that we can have as many of these in one or more "main" modules as
    we want to run concurrently and that the Go environment be altered to treat
    each as a top-level goroutine.

    I appreciate this is a Go-2 type of suggestion and I'm more curious about
    its viability than to actually see it implemented. I do think that the
    traditional idea of a main() function, however, is an anachronism in Go and
    seeing it dropped would appeal to my sense of aesthetics.

    Lucio.

    --

    --
  • ⚛ at Nov 30, 2012 at 8:31 pm

    On Thursday, November 29, 2012 7:50:23 AM UTC+1, Lucio wrote:

    ... form, where "func main()" is simply discarded. Not only, but I also
    suggest that we can have as many of these in one or more "main" modules as
    we want to run concurrently and that the Go environment be altered to treat
    each as a top-level goroutine.

    I appreciate this is a Go-2 type of suggestion and I'm more curious about
    its viability than to actually see it implemented. I do think that the
    traditional idea of a main() function, however, is an anachronism in Go and
    seeing it dropped would appeal to my sense of aesthetics.
    - In my opinion, this suggestion isn't solving any actual problem. The text
    "func main() {" is just a few keystrokes per Go program.

    - Each top-level declaration in Go (func, var, ...) starts with a keyword.
    Starting a top-level declaration with the character "{" goes against the
    rule mentioned in the previous sentence.

    - Go programs are designed to compile quickly. The parser can quickly
    determine the type of a top-level declaration from the 1st word of the
    declaration. Replacing "func main {...}" with "{...}" isn't improving the
    parser nor the compiler in any way.

    - Starting multiple goroutines right at the beginning of the execution a Go
    program goes against the fact that, typically, many Go programs first need
    to read some input data (command line arguments, files, ...) from the
    environment in which the program is running. New goroutines are created
    after reading some input data.

    - "go someFunc()" is a statement that is executed when the instruction
    pointer reaches the statement. The typical case, in my opinion, is that
    starting new goroutines isn't state-less (that is: the program needs to
    reach a particular state to start a goroutine).

    --
  • Nobinds at Dec 1, 2012 at 12:49 am
    Not seeing the point of this suggestion at all. Even a good IDE can
    automatically put in your main function.

    --
  • Andrew Gerrand at Dec 2, 2012 at 9:11 am
    But then how would I do this?

    http://play.golang.org/p/LZrEsZD1Mw

    Andrew

    --

Related Discussions

People

Translate

site design / logo © 2017 Grokbase