FAQ
Go is very stubborn in its idealism. We all know that TLS is bad, except
when it isn't. I'm building a Go project that will, possibly across
different machines, deliver HTTP requests, perform out-of-band work, and
manage long-running connections. These tasks will be performed
concurrently, and it would be immensely useful for debugging or auditing to
build a logging framework that noted what role + task is being performed in
its standard prefix.

In other languages, each thread would have a context (and therefore
logger), which would be propagated by default in new threads. This doesn't
seem possible in Go. I understand that I could require every class in the
entire codebase to contain a pointer to a logger which gets passed around,
but that's a fairly straw-man argument. Forcing every developer in the
codebase to manually bootstrap their way into logging conventions is
madness.

What reasonable options do I have, where I can lay the foundations for the
codebase so that future developers can use the logging library without
being intimately familiar with the implementation?

Thanks,
Thomas

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Archos at Aug 13, 2013 at 6:33 pm
    https://blog.mozilla.org/services/2013/04/30/introducing-heka/
    https://github.com/mozilla-services/heka

    http://dendrite.io/
    https://github.com/onemorecloud/dendrite

    El martes, 13 de agosto de 2013 18:41:11 UTC+1, thomas....@gmail.com
    escribió:
    Go is very stubborn in its idealism. We all know that TLS is bad, except
    when it isn't. I'm building a Go project that will, possibly across
    different machines, deliver HTTP requests, perform out-of-band work, and
    manage long-running connections. These tasks will be performed
    concurrently, and it would be immensely useful for debugging or auditing to
    build a logging framework that noted what role + task is being performed in
    its standard prefix.

    In other languages, each thread would have a context (and therefore
    logger), which would be propagated by default in new threads. This doesn't
    seem possible in Go. I understand that I could require every class in the
    entire codebase to contain a pointer to a logger which gets passed around,
    but that's a fairly straw-man argument. Forcing every developer in the
    codebase to manually bootstrap their way into logging conventions is
    madness.

    What reasonable options do I have, where I can lay the foundations for the
    codebase so that future developers can use the logging library without
    being intimately familiar with the implementation?

    Thanks,
    Thomas
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Archos at Aug 13, 2013 at 6:37 pm
    I also had bookmarked this one, which looks interesting:

    https://github.com/cloudfoundry/loggregator

    El martes, 13 de agosto de 2013 19:33:45 UTC+1, Archos escribió:
    https://blog.mozilla.org/services/2013/04/30/introducing-heka/
    https://github.com/mozilla-services/heka

    http://dendrite.io/
    https://github.com/onemorecloud/dendrite

    El martes, 13 de agosto de 2013 18:41:11 UTC+1, thomas....@gmail.comescribió:
    Go is very stubborn in its idealism. We all know that TLS is bad, except
    when it isn't. I'm building a Go project that will, possibly across
    different machines, deliver HTTP requests, perform out-of-band work, and
    manage long-running connections. These tasks will be performed
    concurrently, and it would be immensely useful for debugging or auditing to
    build a logging framework that noted what role + task is being performed in
    its standard prefix.

    In other languages, each thread would have a context (and therefore
    logger), which would be propagated by default in new threads. This doesn't
    seem possible in Go. I understand that I could require every class in the
    entire codebase to contain a pointer to a logger which gets passed around,
    but that's a fairly straw-man argument. Forcing every developer in the
    codebase to manually bootstrap their way into logging conventions is
    madness.

    What reasonable options do I have, where I can lay the foundations for
    the codebase so that future developers can use the logging library without
    being intimately familiar with the implementation?

    Thanks,
    Thomas
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Daniel Heath at Aug 13, 2013 at 11:43 pm
    I use a dependency injector (minimal implementation at
    github.com/99designs/goodies/depinject ).

    Every bit of code that needs logging can ask the service container for a
    logger.

    You can then create different logger types (eg HttpLogger) which back onto
    the same logs with different prefixes, and depend on those types in your
    code.

    On Wednesday, August 14, 2013 3:41:11 AM UTC+10, thomas....@gmail.com wrote:

    Go is very stubborn in its idealism. We all know that TLS is bad, except
    when it isn't. I'm building a Go project that will, possibly across
    different machines, deliver HTTP requests, perform out-of-band work, and
    manage long-running connections. These tasks will be performed
    concurrently, and it would be immensely useful for debugging or auditing to
    build a logging framework that noted what role + task is being performed in
    its standard prefix.

    In other languages, each thread would have a context (and therefore
    logger), which would be propagated by default in new threads. This doesn't
    seem possible in Go. I understand that I could require every class in the
    entire codebase to contain a pointer to a logger which gets passed around,
    but that's a fairly straw-man argument. Forcing every developer in the
    codebase to manually bootstrap their way into logging conventions is
    madness.

    What reasonable options do I have, where I can lay the foundations for the
    codebase so that future developers can use the logging library without
    being intimately familiar with the implementation?

    Thanks,
    Thomas
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 13, '13 at 5:41p
activeAug 13, '13 at 11:43p
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase